ReverseEngineering

Kernel Reverse Engineering Syscalls Drivers Kernel Debugging تحلیل کد سطح کرنل یعنی کار با درایورها و syscallها ابزارها روش ها متفاوت و خطرناکن بنابر این باید فقط برای درک و دفاع انجام بشه نه سو استفاده مثال: با یک درایور نمونه open-source کار کن: build کن داخل VM نصب کنید و با WinDbg یا kgdb دیباگ کنید تا ببینید syscall چطور پارامترها رو میگذرونه تمرکز روی فهم API و کنترل‌ فلو نه ایجاد exploit دیتکشن درایور های unsigned یا درایور هایی که اقدام به رجیستر کردن syscall های جدید میکنن رفتار های غیر عادی مثل تغییر مستقیم ساختار های کرنل یا نصب hook های غیر معمول میتیگیشن محدود کردن نصب درایورهای ناشناس (signature enforcement) استفاده از HVCI/Kernel Patch Protection مانیتورینگ تغییرات کرنل و هشدار به‌ موقع مشاهده ماژول/درایور جدید یا نوشتن در مناطق حساس Kernel Reverse Engineering Syscalls Drivers Kernel Debugging Kernel-level code analysis means working with drivers and syscalls. Tools and methods are different and dangerous, so it should only be done for understanding and defense, not for exploitation. Example: Work with an open-source sample driver: build it, install it inside a VM, and debug it with WinDbg or kgdb to see how the syscall passes parameters. Focus on understanding the API and control flow, not creating exploits. Detection Unsigned drivers or drivers that attempt to register new syscalls. Anomalies such as directly modifying kernel structures or installing unusual hooks. Mitigation Restricting installation of unknown drivers (signature enforcement). Use HVCI/Kernel Patch Protection. Monitoring kernel changes and alerting when new modules/drivers are detected or written to sensitive areas @reverseengine

بخش هفتم بافر اورفلو

یافتن آفست دقیق بین ابتدای بافر و saved return address و دیدن قبل و بعد strcpy با الگوی غیرتکراری فایل تولید الگو توضیح این فایل یک الگوی غیرتکراری تولید می کند تا با مقدار بازگشتی که روی استک می بینیم بتوانیم آفست را حساب کنیم فایل file4_pattern.py

#!/usr/bin/env python3 # simple cyclic pattern generator import sys alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" nums = "abcdefghijklmnopqrstuvwxyz" digits = "0123456789" def pattern(n): out = [] for a in alpha: for b in nums: for c in digits: out.append(a+b+c) if len("".join(out)) >= n: return "".join(out)[:n] return "".join(out)[:n] if name == "main": n = int(sys.argv[1]) if len(sys.argv)>1 else 200 print(pattern(n)) دستور

ات اجرا برای یافتن آفست و دیدن قبل و بعد strcpy تولید الگو و اجرای فایل با الگو به عنوان ورودی

python3 file4_pattern.py 200 > pat.txt

gcc -g file4.c -o file4

gdb --args ./file4 $(cat pat.txt)

# در gdb

break crash run x/32x $rbp-32 # strcpy قبل از next # strcpy اجرای کامل x/32x $rbp-32 # strcpy بعد از continue # تا کرش اگر لازمه

پیدا کردن مقدار overwrite شده توضیح بعد از کرش یا بعد از دیدن در gdb مقدار 8 بایتی که در محل return address افتاده رو بردارید و به صورت رشته hex بخونید مثال دستور داخل gdb برای دیدن 8 بایت در محل return address x/gx $rbp+8 توضیح فایل محاسبه آفست این فایل یک تابع ساده برای پیدا کردن موقعیت یک رشته کوچیک داخل الگوی تولید شده میسازه فایل file4_find_offset.py

#!/usr/bin/env python3 import sys from file4_pattern import pattern def find(sub, total=200): p = pattern(total) idx = p.find(sub) return idx if name == "main": # ورودی sub به صورت بایت hex یا رشته باید به درستی فرمت شود sub = sys.argv[1] # اگر hex داده شد تبدیل کن if sub.startswith("0x"): raw = bytes.fromhex(sub[2:]) sub = raw.decode('latin-1') print(find(sub, int(sys.argv[2]) if len(sys.argv)>2 else 200)) Part

7 Buffer Overflow Finding the exact offset between the beginning of the buffer and the saved return address and seeing before and after strcpy with a non-repeating pattern Pattern generation file Explanation This file generates a non-repeating pattern so that we can calculate the offset with the return value we see on the stack File file4_pattern.py

#!/usr/bin/env python3 # simple cyclic pattern generator import sys alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" nums = "abcdefghijklmnopqrstuvwxyz" digits = "0123456789" def pattern(n): out = [] for a in alpha: for b in nums: for c in digits: out.append(a+b+c) if len("".join(out)) >= n: return "".join(out)[:n] return "".join(out)[:n] if name == "main": n = int(sys.argv[1]) if len(sys.argv)>1 else 200 print(pattern(n)) Execut

ion commands to find offset and see before and after strcpy Generate pattern and execute file with pattern as input

python3 file4_pattern.py 200 > pat.txt

gcc -g file4.c -o file4

gdb --args ./file4 $(cat pat.txt)

# in gdb

break crash run x/32x $rbp-32 # strcpy before next # strcpy complete execution x/32x $rbp-32 # strcpy after continue # until crash if necessary

Finding overwritten value Explanation After crash or after seeing in gdb, take the 8 bytes that are in the return address and write them as Read hex string Example of gdb command to see 8 bytes at return address

x/gx $rbp+8

File description Calculate offset This file creates a simple function to find the position of a small string within the generated pattern File file4_find_offset.py

#!/usr/bin/env python3 import sys from file4_pattern import pattern def find(sub, total=200): p = pattern(total) idx = p.find(sub) return idx if name == "main": # Sub input as hex bytes or string must be formatted properly sub = sys.argv[1] # Convert if given hex if sub.startswith("0x"): raw = bytes.fromhex(sub[2:]) sub = raw.decode('latin-1') print(find(sub, int(sys.argv[2]) if len(sys.argv)>2 else 200)) @rever

seengine

Devirtualization روش‌های دفاع/تحلیلی وقتی با VM-based obfuscation روبه‌رو میشید باید بفهمید چه الگویی برای برگردوندن pseudocode استفاده میکنن راه‌ حل‌ ها معمولا ترکیبی از آنالیز ایستا برای شناسایی و آنالیز دینامیک برای تقلید اجرای VM هستن مثال: trace گرفتن از اجرای برنامه و استخراج sequence ای از دستورات dispatche مثل opcode های VM و دسته‌ بندی‌ شون بدون اینکه بخواید قفل‌‌ ها رو بشکنید فقط ساختار دستورها رو ببینید دیتکشن الگوهای تکراری در dispatcher که به opcodeهای مشخص اشاره میکنن مقادیر ثابت جدول‌های ترجمه که در runtime خونده و استفاده میشن میتیگیشن محقق: مستندسازی دقیق از رفتار runtime و نگهداری traces برای تحلیل‌های بعدی توسعه‌دهنده: اگر از VM استفاده میکنی لاگ‌های داخلی برای تیم خودت نگه دار تا در troubleshooting بهت کمک کنه Devirtualization Defense/Analysis Methods When faced with VM-based obfuscation, you need to understand what pattern they are using to return pseudocode. Solutions are usually a combination of static analysis to identify and dynamic analysis to mimic VM execution Example: Trace Taking a program execution and extracting a sequence of dispatcher instructions Like VM opcodes and their categories without trying to break the locks, just see the instruction structure Detection Repeated patterns in dispatcher that point to specific opcodes Constant values of translation tables that are read and used at runtime Mitigation Researcher: Accurately document runtime behavior and maintain traces for later analysis Developer: If you use VM, keep internal logs for your team to help you troubleshoot @reverseengine

https://github.com/EvilBytecode/GoDefender @reverseengine

https://github.com/AgentSmithers/x64DbgMCPServer @reverseengine

Levering Generative AI to Reverse Engineering XLoader https://research.checkpoint.com/2025/generative-ai-for-reverse-engineering @reverseengine

WoW64 internals https://wbenny.github.io/2018/11/04/wow64-internals.html @reverseengine

این پروژه یک وایت بورد در IDA در اختیارتون میزاره که میتونید داخلش هر چیزی که خواستید رو طراحی کنید This project provides you with a whiteboard in IDA where you can design anything you want https://github.com/idkhidden/DrawIDA @reverseengine

IDA Generating signatures for Nim and other non-C programming languages https://hex-rays.com/blog/plugin-focus-generating-signatures-for-nim-and-other-non-c-programming-languages @reverseengine

ring 0 x86_64 CPU opcode fuzzer https://github.com/gaidardzhiev/ring0fuzzer @FUZZ0x

Virtualization-based Obfuscation Devirtualization و Kernel RE (فقط نرم‌افزار) Virtualization-based Obfuscation VMProtect / Themida یه لایه مجازی‌ ساز داخل باینری میذارن: کد اصلی تبدیل میشه به دستورالعمل‌ های مخصوص VM و یه انجین در زمان اجرا اونا رو اجرا میکنه سخت میشه بفهمید اصل منطق چیه مثال: نمونه open-source که با ابزار obfuscator ساده بسته‌ بندی شده رو باز کنید و ببینید بخش dispatcher چطور بین بلاک‌ ها سوئیچ میکنه فقط ببینید و ساختار جدول پرش رو تحلیل کنید نه حذف حفاظ دیتکشن (چی باید نگاه کنید) وجود یک حلقه dispatcher که با جدول‌ ایندکس‌ ها بلاک‌ ها رو اجرا میکنه الگو های ثابت decode/dispatch در چند تا تابع کاهش شدید خوانایی pseudocode اما افزایش پیچیدگی CFG میتیگیشن (مدافع/توسعه‌دهنده) برای توسعه‌دهندگان: از Obfuscation‌ فقط وقتی لازم باشه استفاده کنید و مستندات داخلی رو نگه‌ دارید آنالیزور/مدافع: ترکیب آنالیز ایستا و دینامیک لاگ‌ گیری runtime و trace گرفتن از dispatcher کمک میکنه تا بفهمید VM چه دستورات منطقی‌ ای اجرا میکنه Virtualization-based Obfuscation Devirtualization and Kernel RE (software only) Virtualization-based Obfuscation VMProtect / Themida Puts a virtualization layer inside the binary: the original code is converted to VM-specific instructions and an engine executes them at runtime. It is difficult to understand the logic behind it. Example: Open the open-source example packaged with a simple obfuscator tool and see how the dispatcher section switches between blocks. Just look and analyze the jump table structure, not remove the protection. Detection (what to look for) Presence of a dispatcher loop that executes blocks with index tables. Constant decode/dispatch patterns in several functions. Severely reduces pseudocode readability but increases CFG complexity. Mitigation (Defender/Developer) For developers: Use Obfuscation only when necessary and keep internal documentation. Analyzer/Defender: Analysis combination Static and dynamic runtime logging and dispatcher tracing help you understand what logical commands the VM is executing. @reverseengine

نشونه ها داخل دیس‌ اسمبلی push rbp + mov rbp, rsp فریم ساخته شده sub rsp, x متغیر محلی وجود داره دسترسی به [rbp - offset] استفاده از متغیر محلی روی استک call معمولا Non-leaf (به جز Tail-call) نبودن RBP و کار فقط با RSP خروجی کامپایلر بهینه‌ سازی شده است Symbols inside the disassembly

push rbp + mov rbp, rsp Frame created

sub rsp, x Local variable exists

Access to [rbp - offset] Use local variable on stack

Call is usually Non-leaf (except Tail-call)

No RBP and only works with RSP Compiler output is optimized

@reverseengine

تابع‌هایی که از stack frame استفاده نمیکنن (Leaf بدون Prologue) پس این قسمت کلیدی هست مثال C:

int add5(int x) { return x + 5; }

اسمبلی بهینه کامپایلر (O2):

add5: lea eax, [rdi + 5] ret

چرا اینجا push rbp و mov rbp, rsp نداریم؟ چون: تابع هیچ متغیر محلی نداره تابع تابع دیگری رو فرانمیخونه (leaf) مقدار برگشتی(return address) فقط در رجیستر‌ها محاسبه میشه نتیجه: کامپایلر stack frame نمیسازه Functions that do not use stack frame (Leaf without Prologue) So this is the key part C example:

int add5(int x) { return x + 5; }

Compiler optimized assembly (O2):

add5: lea eax, [rdi + 5] ret

Why don't we have push rbp and mov rbp, rsp here? Because: The function has no local variables The function does not call another function (leaf) The return value (return address) is calculated only in registers Result: The compiler does not create a stack frame @reverseengine

UPX و نمونه‌ های پیچیده‌ تر فایل اصلی فشرده یا رمز میشه و Loader موقع اجرا محتوا رو آنپک میکنه  پس static analysis اغلب بی‌ فایده‌ ست تا وقتی که unpack شدن انجام بشه یه فایل ممکنه کوچیک باشه ولی وقتی اجرا میکنی ناگهان یه قسمت بزرگ از کد تو حافظه ظاهر میشه  یعنی packed بوده مثل اینکه یه جعبه بسته رو باز کنی و داخلش یه چیز دیگه باشه مثال: تو header یا با نگاه کردن به اندازه امضا میتونید بفهمید packed هست در اجرای برنامه میبینید بخش ههای جدیدی توی حافظه ساخته میشه  علامت unpacking دیتکشن امضا های packer شناخته‌ شده توی header افزایش ناگهانی بخش‌های اجرایی در حافظه بعد از لانچ رفتار loader در runtime که حافظه رو مینویسه و بعد jump به بخش جدید میزنه میتیگیشن اجرا در sandbox/VM با مانیتورینگ کامل (فایل شبکه پروسس) تا رفتار after-unpack دیده بشه برای سازمان‌ ها: امضای فایل‌ ها و بررسی integrity قبل از اجرا و quarantine کردن فایل‌ های مشکوک UPX and more complex examples The original file is compressed or encrypted and the Loader unpacks the content at runtime, so static analysis is often useless until unpacking is done A file may be small, but when you run it, a large chunk of code suddenly appears in memory, meaning it was packed, like opening a closed box and there's something else inside Example: You can tell it's packed in the header or by looking at the size of the signature. When running the program, you'll see new sections being created in memory, a sign of unpacking Detection Known packer signatures in the header Sudden increase in executable sections in memory after launch Loader behavior at runtime that writes memory and then jumps to a new section Mitigation Run in a sandbox/VM with full monitoring (process network file) to see after-unpack behavior For organizations: file signing and integrity checking before execution and quarantining suspicious files @reverseengine

Windows Heap Exploitation - From Heap Overflow to Arbitrary R/W https://mrt4ntr4.github.io/Windows-Heap-Exploitation-dadadb/ @reverseengine

Update on Attacks by Threat Group APT-C-60 https://blogs.jpcert.or.jp/en/2025/11/APT-C-60_update.html @reverseengine

Roadmap Malware Analysis C C++ Reverse engineering for beginners book and other corses Assembly Windows Internals Win32 Api Python Malware analysis professional course Zero2automated course Sans for 610 practical malware analysis book Malware analysis cookbook book Mastering malware analysis packtpub book این رودمپ رو خیلی وقت پیش خودم نوشتم برای دوستانی که میخان تحلیل بدافزار انجام بدن استفاده کنن خیلیا رو دیدم به اسم خودشون زدن😂 I wrote this roadmap a long time ago for my friends who want to do malware analysis to use. I saw many people calling it their own😂 @reverseengine

Control-flow flattening و Junk Code توضیح: کد ساده رو طوری مینویسن یا تبدیل میکنن که ترتیب منطقیش معلوم نباشه با جدول پریدن‌ ها و کلی شاخه بی‌ ربط یا کلی کد بی‌ فایده junk میزنن تا تشخیص الگوریتم سخت شه یادتونه یه if ساده چقدر خوندنش راحته؟ بعضی‌ها اون if رو میکوبن توی یه جدول پریدن و چند تا case اضافه میکنن دیگه شبیه لابیرنت میشه همین کار باعث میشه خوندن جریان برنامه سخت شه مثال: در CFG میبینید به‌ جای چند شاخه ساده کلی بلاک کوچک و پرش بین جدول‌ هاست این یعنی control-flow flattening یا اضافه کردن کد بی‌ ربط دیتکشن گراف کنترل جریان خیلی تودرتو و شاخه‌ های زیاد توابع خیلی طولانی پر از jumps و switch-like tables کدهایی که ظاهرا کاری نمیکنن ولی اجرا‌ میشن میتیگیشن آنالیزور: ترکیب static و dynamic analysis یعنی هم disasm ببینید هم اجرا کن تا بفهمید کد واقعی کدیه که در runtime فعال میشه توسعه‌دهنده: مستند سازی و unit test تا اگر مجبور به obfuscation شدید حداقل تیمتون بتونه نگهش داره Control-flow flattening and Junk Code Explanation: They write or transform simple code in such a way that its logical order is not clear, with jump tables and a lot of irrelevant branches or a lot of useless code, making it difficult to understand the algorithm Remember how easy a simple if is to read? Some people throw that if in a table, jump and add a few cases, and it becomes like a labyrinth, which makes it difficult to read the program flow. Example: In CFG, instead of a few simple branches, you see a whole bunch of small blocks and jumps between tables. This means control-flow flattening or adding irrelevant code. Detection The control flow graph is very nested and has many branches. Very long functions full of jumps and switch-like tables. Code that doesn't seem to do anything but is executed. Mitigation Analyzer: A combination of static and dynamic analysis, meaning you can see both disasm and execute it to understand that the real code is the code that will be activated at runtime. Developer: Documentation and unit testing so that if you have to obfuscate, at least your team can maintain it. @reverseengine

رمزنگاری/انکدینگ رشته‌ها String encryption برنامه‌ ها رشته‌های متنی مثل پیام‌ها، URLها، کلیدها) رو توی فایل به‌صورت رمز یا انکد نگه میدارن و فقط موقع اجرا بازشون میکنن تا کسی با نگاه کردن توی باینری پیداشون نکنه توضیح: دیدی یه باینری اصلا رشته‌ای نداره؟ احتمالا سازنده‌ ش رشته‌ها رو قفل کرده یعنی مثلا «hello» تو فایل نیست چون یه تابع موقع اجرا میاد و بازش میکنه این کار براشون میتونه یه جور حفاظتی باشه یا تلاش برای مخفی کاری مثال: تو دیس‌ اسمبلر میبینید هیچ رشته خوانایی نیست اما یه تابع هست که چند باره حافظه رو میسازه و داده‌ ها رو تبدیل میکنه احتمالا رشته‌ها در runtime ساخته میشن دیتکشن نبودن رشته‌های خوانا در بخش .rdata/.rodata توابعی که مکررا حافظه allo/free میکنن و روی بافر ها عملیات بیت/بایت انجام میدن آنتروپی بالای بخش داده‌ ها میتیگیشن (مدافع/برنامه‌نویس) مدافع: monitor فراخوانی‌ هایی که رشته‌ ها رو در runtime میسازن و بررسی الگوهای غیرعادی توسعه‌دهنده: از لاگینگ و کانفیگ امن استفاده کنید تا نیاز به رمزنگاری بی‌ دلیل رشته‌ ها کم بشه String encryption Programs store text strings (such as messages, URLs, keys) in a file as a password or encoding and only open them at runtime so that no one can find them by looking in the binary Explanation: Did you see that a binary doesn't have a string at all? The creator probably locked the strings, meaning "hello" is not in the file because a function comes in and opens it at runtime. This could be a form of protection or an attempt at hiding. Example: In the disassembler, you see no readable strings, but there is a function that creates memory and converts data several times. The strings are probably created at runtime. Detection No readable strings in the .rdata/.rodata section Functions that repeatedly allocate/free memory and perform bit/byte operations on buffers High entropy in the data section Mitigation (Defender/Programmer) Defender: Monitor calls that create strings at runtime and check for unusual patterns Developer: Use secure logging and configuration to reduce the need for unnecessary string encryption @reverseengine