ReverseEngineering

Stack Canary / NX / ASLR Stack Canary حفاظت از استک چی هست؟ یک مقدار تصادفی بین:

local variables saved RBP return address

قبل از ret چک میشه اگر تغییر کرده باشه: * stack smashing detected * برنامه کرش میکند چرا مهمه؟ دیگر نمیتونید مستقیم:

buf → RIP

رو overwrite کنید راه‌های دور زدن:

Leak Canary فرمت استرینگ out-of-bounds read Partial overwrite

بعضی وقت‌ها فقط LSB قابل کنترله Logic bug اصلا به RIP دست نمیزنید NX / DEP Non-Executable Stack یعنی چی؟ استک قابل اجرا نیست شِل‌کد روی استک اجرا نمیشه نتیجه مستقیم:

buffer → shellcode → RIP

ROP ret2libc ret2win

ASLR Address Space Layout Randomization چی رندوم میشه؟

Stack Heap libc mmap

چی ثابت میمونه؟ باینری اگر PIE نباشه چرا مهمه؟ آدرس‌ ها هر بار فرق میکنن:

system = 0x7f....

   (هر اجرا فرق داره) راه دور زدن:

Leak یک آدرس puts@got printf

محاسبه offset:

libc_base = leaked_puts - puts_offset

پیدا کردن:

system /bin/sh

معمولا اینها رو دارید: Canary NX ASLR ولی: یک info leak هم هست یا overflow کنترل‌ شده

Leak → ROP → ret2libc

Stack Canary / NX / ASLR Stack Canary Stack Protection What is it? A random value between:

local variables saved RBP return address Checked before ret

If changed: * stack smashing detected * Program crashes Why is it important? You can no longer directly overwrite:

buf → RIP

Workarounds:

Leak Canary Format string out-of-bounds read Partial overwrite

Sometimes only LSB is controllable Logic bug You don't touch RIP at all NX / DEP Non-Executable Stack What does it mean? Stack is not executable Shellcode cannot be executed on the stack Direct result:

buffer → shellcode → RIP ROP ret2libc ret2win

ASLR Address Space Layout Randomization What is being randomized?

Stack Heap libc mmap

What remains constant? Binary if not PIE Why does it matter? Addresses are different every time:

system = 0x7f....

(different for each implementation) Workaround:

Leak an address puts@got printf

Calculate offset:

libc_base = leaked_puts - puts_offset

Find:

system /bin/sh

Usually you have these:

Canary NX ASLR

But: There is also an info leak or controlled overflow

Leak → ROP → ret2libc

@reverseengine

Code explanation Here you can clearly see that the buffer is 16 bytes because it is from rbp to rbp-0x10 and because strcpy does not do any length check, if the input is long, the stack can be corrupted Checking the user input path This is very important if the input is taken directly from argv or fgets or read or gets and goes directly to strcpy, the vulnerability is almost certain Example execution

./a.out $(python3 -c "print('A'*200)")

If the program crashes, it means our diagnosis was correct @reverseengine

بخش چهاردهم بافر اورفلو

کشف بافر اورفلو در مهندسی معکوس با ابزارهای IDA و Ghidra و r2 توی این قسمت یاد میگیریم وقتی یک فایل باینری  باز میکنید  چطور بفهمید توش بافر اورفلو هست یا نه یعنی بدون داشتن سورس و فقط با آنالیز تابع‌ ها ورودی‌ های خطرناک و مسیرهای حساس رو پیدا کنی فقط بررسی باینری انجام میدیم هیچ اکسپلویت واقعی نوشته نمیشه کاملا امنه تشخیص توابع خطرناک در باینری این یکی از سریع‌ترین روش‌ هاست اگه جایی تابع‌ هایی مثل strcpy sprintf gets memcpy بدون سایز مشخص وجود داشته باشه احتمال بافر اورفلو زیاده ما یک باینری ساده برای آموزش استفاده میکنیم که توش strcpy و gets استفاده شده تا فقط مفهوم کشف آسیب‌ پذیری رو تمرین کنیم file.c

#include <stdio.h> #include <string.h> void read_name() {     char name[32];     gets(name);     printf("hello %s\n", name); } void copy_data(char *s) {     char buf[16];     strcpy(buf, s);     puts("done copy"); } int main(int argc, char **argv) {     if (argc > 1)         copy_data(argv[1]);     read_name();     return 0; }

باز کردن باینری در IDA یا Ghidra وقتی فایل را داخل IDA باز میکنید دنبال اسم توابع خطرناک بگردید مثال اگه توی view functions ببینید gets یا strcpy هست همین خودش زنگ خطره بعد برید داخل خود تابع و نگاه کند سایز بافر چقدره و ورودی از کجا میاد وقتی دیدید strcpy(buf s) و buf اندازه ثابت داره ولی طول s از ورودی کاربر میاد خیلی احتمال بافر اورفلو هست این الگو یکی از کلاسیک ترین نشونه هاشه دیدن فریم تابع و محل بافر توی disassembly دنبال دستوراتی مثل

sub rsp alloca

اینا مکان ساختن فضای لوکال روی استک رو نشون میدن مثال اسمبلی تابع copy_data وقتی disassemble کنیم تقریبا چیزی شبیه این میبینیم

push rbp mov rbp, rsp sub rsp, 0x20 mov rax, rdi lea rdx, [rbp-0x10] mov rsi, rax call strcpy

توضیح کد اینجا واضح میبینید که بافر 16 بایته چون از rbp تا rbp-0x10 فاصله داره و چون strcpy هیچ چک طولی نمیکنه اگه ورودی طولانی بیاد استک میتونه خراب بشه چک کردن مسیر ورودی کاربر این خیلی مهمه اگه ورودی مستقیم از argv یا fgets یا read یا gets گرفته بشه و همون مستقیم به strcpy بره آسیب‌پذیری تقریبا قطعی میشه نمونه اجرا

./a.out $(python3 -c "print('A'*200)")

اگر برنامه کرش کرد یعنی تشخیص ما درست بوده

Part 14 Buffer Overflow

Detecting Buffer Overflow in Reverse Engineering with IDA, Ghidra and r2 tools In this section, we will learn how to find out if there is a buffer overflow when you open a binary file That is, without having the source and only by analyzing the functions, you can find dangerous inputs and sensitive paths. We only do binary inspection. No real exploits can be written. It is completely safe Detecting dangerous functions in binary This is one of the fastest methods If there are functions like strcpy sprintf gets memcpy without a specified size, the probability of buffer overflow is high We will use a simple binary for training in which strcpy and gets are used to practice the concept of vulnerability detection file.c

#include <stdio.h> #include <string.h> void read_name() { char name[32]; gets(name); printf("hello %s\n", name); } void copy_data(char *s) { char buf[16]; strcpy(buf, s); puts("done copy"); } int main(int argc, char **argv) { if (argc > 1) copy_data(argv[1]); read_name(); return 0; }

Opening a binary in IDA or Ghidra When you open a file in IDA, look for the names of dangerous functions For example, if you see gets or strcpy in the view functions, that's a red flag. Then go inside the function itself and look at the buffer size and where the input comes from. When you see strcpy(buf s) and buf has a fixed size, but the length s comes from the user input, it's very likely a buffer overflow. This pattern is one of the most classic signs. Seeing the function frame and buffer location. In disassembly, look for commands like

sub rsp alloca

These show where to create local space on the stack. For example, the assembly of the copy_data function, when we disassemble it, we see something like this:

push rbp mov rbp, rsp sub rsp, 0x20 mov rax, rdi lea rdx, [rbp-0x10] mov rsi, rax call strcpy

Block Redo & Undo To Achieve Legacy IDA https://github.com/tmr232/BRUTAL-IDA @reverseengine

Rust reversing helper script https://github.com/cha5126568/rust-reversing-helper @reverseengine

Writing an iOS Kernel Exploit from Scratch https://secfault-security.com/blog/chain3.html @reverseengine

Exploiting an Envoy heap vulnerability https://blog.envoyproxy.io/exploiting-an-envoy-heap-vulnerability-96173d41792 @reverseengine

https://www.synacktiv.com/en/publications/breaking-the-beestation-inside-our-pwn2own-2025-exploit-journey @reverseengine

WEIZZ: Automatic Grey-Box Fuzzing for Structured Binary Formats Slides: https://andreafioraldi.github.io/assets/weizz-issta2020-slides.pdf Video: https://www.youtube.com/watch?v=MOeUqlFtgwE Article: https://andreafioraldi.github.io/assets/weizz-issta2020.pdf Code: https://github.com/andreafioraldi/weizz-fuzzer @reverseengine

Process Injection using DInvoke https://rastamouse.me/blog/process-injection-dinvoke @reverseengine

Split 64 bits sep-firmware images https://github.com/matteyeux/pysep @reverseengine

Updates on ThiefQuest, the Quickly-Evolving macOS Malware https://blog.trendmicro.com/trendlabs-security-intelligence/updates-on-thiefquest-the-quickly-evolving-macos-malware @reverseengine

Piercing the Veil: Android Code Deobfuscation https://www.youtube.com/watch?v=lmHkfKXuN4A @reverseengine

Singularity - Stealthy Linux Kernel Rootkit https://blog.kyntra.io/Singularity-A-final-boss-linux-kernel-rootkit https://github.com/MatheuZSecurity/Singularity?tab=readme-ov-file#installation

Linux rootkita explained https://www.wiz.io/blog/linux-rootkits-explained-part-1-dynamic-linker-hijacking @reverseengine

LazyHook is a stealthy API hooking framework that bypasses Host Intrusion Prevention Systems (HIPS) through call stack spoofing. By leveraging CPU-level hardware breakpoints and Vectored Exception Handling, it executes arbitrary code as if it originated from trusted, Microsoft-signed modules—completely fooling behavioral analysis engines that rely on call stack inspection and module origin verification.

Evade behavioral analysis by executing malicious code within trusted Microsoft call stacks Uses hardware breakpoints + VEH to hijack legitimate functions and spoof module origins │ 1. Target Function Call │ ↓ │ 2. CPU Debug Register Triggers (DR0-DR3) │ │ ↓ │ 3. EXCEPTION_SINGLE_STEP Raised │ │ ↓ │ 4. VEH Handler Intercepts Exception │ │ ↓ │ 5. Execution Redirected to Hook Function │ │ ↓ │ 6. CallOriginal() Temporarily Disables Breakpoint │ ↓ │ 7. Original Function Executes │ │ ↓ │ 8. Breakpoint Re-enabled

#callstackspoofing #edr

Reverse engineering of a crypto stealer https://medium.com/@beardr3d/reverse-engineering-of-a-crypto-stealer-e768f0c20853 @reverseengine

How to Reverse-Engineer (with AI) an old Demoscene Exe https://medium.com/@kevin.drapel/how-to-reverse-engineer-with-ai-an-old-demoscene-exe-part-1-07e22e48b0c2 @reverseengine

Decoding Brickstorms Garble string https://medium.com/walmartglobaltech/decoding-brickstorms-garble-strings-b0a60828b3cc @reverseengine