Forwarded from Fuzzing ZONE
Fuzzing Binary Applications
https://medium.com/@anotherik/fuzzing-binary-applications-part-1-from-concepts-to-a-toy-fuzzer-1adb097acefe
@FUZZ0x
https://medium.com/@anotherik/fuzzing-binary-applications-part-1-from-concepts-to-a-toy-fuzzer-1adb097acefe
@FUZZ0x
Medium
Fuzzing Binary Applications — Part 1: From Concepts to a Toy Fuzzer
Exploring the foundations of fuzzing and building a mini fuzzer to see how programs break under malformed input.
Tail Recursion
وقتی فراخوانی بازگشتی اخرین عملیاتیه که تابع انجام میده
مثال
مزیت Tail Recursion
کامپایلر میتونه stack frame رو دوباره استفاده کنه و از overflow جلوگیری کنه
در اسمبلی دیگه push/pop مکرر برای هر call لازم نیست (بهینهسازی میشه)
اسمبلی نمونه برای Tail Recursion
تفاوت کلیدی: jmp fact_tail به جای call fact_tail → stack frame تکرار نمیشه
Tail Recursion
When the recursive call is the last operation performed by the function
Example
Advantage of Tail Recursion
The compiler can reuse the stack frame and prevent overflow
In assembly, repeated push/pop for each call is no longer necessary (optimized)
Sample assembly for Tail Recursion
Key difference: jmp fact_tail instead of call fact_tail → stack frame is not repeated
وقتی فراخوانی بازگشتی اخرین عملیاتیه که تابع انجام میده
مثال
int fact_tail(int n, int acc){
if (n >= 1) return acc;
return fact_tail(n-1, n*acc);
}
مزیت Tail Recursion
کامپایلر میتونه stack frame رو دوباره استفاده کنه و از overflow جلوگیری کنه
در اسمبلی دیگه push/pop مکرر برای هر call لازم نیست (بهینهسازی میشه)
اسمبلی نمونه برای Tail Recursion
fact_tail:
cmp edi, 1
jle .Lbase
imul esi, edi ; acc = n * acc
sub edi, 1
jmp fact_tail ; tail call (jmp به جای call)
.Lbase:
mov eax, esi
ret
تفاوت کلیدی: jmp fact_tail به جای call fact_tail → stack frame تکرار نمیشه
Tail Recursion
When the recursive call is the last operation performed by the function
Example
int fact_tail(int n, int acc){
if (n >= 1) return acc;
return fact_tail(n-1, n*acc);
}
Advantage of Tail Recursion
The compiler can reuse the stack frame and prevent overflow
In assembly, repeated push/pop for each call is no longer necessary (optimized)
Sample assembly for Tail Recursion
fact_tail:
cmp edi, 1
jle .Lbase
imul esi, edi ; acc = n * acc
sub edi, 1
jmp fact_tail ; tail call (jmp instead of call)
.Lbase:
mov eax, esi
ret
Key difference: jmp fact_tail instead of call fact_tail → stack frame is not repeated
👍2🔥1
ReverseEngineering
Tail Recursion وقتی فراخوانی بازگشتی اخرین عملیاتیه که تابع انجام میده مثال int fact_tail(int n, int acc){ if (n >= 1) return acc; return fact_tail(n-1, n*acc); } مزیت Tail Recursion کامپایلر میتونه stack frame رو دوباره استفاده کنه و از…
وقتی jmp به جای call میبینیم تقریبا مطمئنیم که tail recursion optimization انجام شده و استک فریم تکراری ساخته نمیشه
When we see jmp instead of call, we are almost certain that tail recursion optimization has been performed and duplicate stack frames are not created.
When we see jmp instead of call, we are almost certain that tail recursion optimization has been performed and duplicate stack frames are not created.
👍2
root module (xposed-based) to bypass SSL Pinning in Android apps
https://github.com/Xposed-Modules-Repo/com.simo.ssl.killer/releases/tag/1-1.0.2
https://github.com/Xposed-Modules-Repo/com.simo.ssl.killer/releases/tag/1-1.0.2
dalvikus
A modern Android reverse engineering and modification toolkit built with Compose Multiplatform, available for windows, linux & mac.
https://github.com/loerting/dalvikus.git
A modern Android reverse engineering and modification toolkit built with Compose Multiplatform, available for windows, linux & mac.
https://github.com/loerting/dalvikus.git
GitHub
GitHub - loerting/dalvikus: Android reverse-engineering tool / smali editor
Android reverse-engineering tool / smali editor. Contribute to loerting/dalvikus development by creating an account on GitHub.
Forwarded from GO-TO CVE
CVE-2024-12877-week-66.pdf
1002 KB
🎯 CVE-2024-12877 Review – GiveWP goes unserialize()… Hello RCE! ⚡️🔥
Hello hackers, bug hunters, and curious minds! Welcome to Episode 66 of the GO-TO CVE series! 🎙💻
This week we’re cracking open a classic PHP Object Injection inside GiveWP, one of the most popular WordPress donation plugins. 🕳🐘
🔹 Week: 66
🔹 CVE: CVE-2024-12877
🔹 Type: PHP Object Injection
🔹 Target: GiveWP (WordPress Plugin)
📌 What’s the story?
GiveWP uses PHP’s notorious unserialize() on user input. That means attackers can drop in a crafted serialized payload, and PHP will happily invoke magic methods like __wakeup() — executing attacker-controlled logic without warning.
👾 What’s the impact?
Remote Code Execution (RCE) 🚀
Sensitive data theft (donors, users, configs) 🕵️♂️
Privilege escalation across WordPress 🔑
Full server compromise ☠️
💡 Lesson learned: Regex checks won’t save you. The real fix? Never unserialize untrusted input.
📬 Stay tuned with GO-TO CVE for a fresh bug every week:
👉 https://news.1rj.ru/str/GOTOCVE
#week_66
Hello hackers, bug hunters, and curious minds! Welcome to Episode 66 of the GO-TO CVE series! 🎙💻
This week we’re cracking open a classic PHP Object Injection inside GiveWP, one of the most popular WordPress donation plugins. 🕳🐘
🔹 Week: 66
🔹 CVE: CVE-2024-12877
🔹 Type: PHP Object Injection
🔹 Target: GiveWP (WordPress Plugin)
📌 What’s the story?
GiveWP uses PHP’s notorious unserialize() on user input. That means attackers can drop in a crafted serialized payload, and PHP will happily invoke magic methods like __wakeup() — executing attacker-controlled logic without warning.
👾 What’s the impact?
Remote Code Execution (RCE) 🚀
Sensitive data theft (donors, users, configs) 🕵️♂️
Privilege escalation across WordPress 🔑
Full server compromise ☠️
💡 Lesson learned: Regex checks won’t save you. The real fix? Never unserialize untrusted input.
📬 Stay tuned with GO-TO CVE for a fresh bug every week:
👉 https://news.1rj.ru/str/GOTOCVE
#week_66
❤2
Forwarded from Fuzzing ZONE
Meet the women of Conti ransomware group.
https://fixupx.com/IntCyberDigest/status/1961359540961550338
@FUZZ0x
https://fixupx.com/IntCyberDigest/status/1961359540961550338
@FUZZ0x
🧵 Thread • FixupX
International Cyber Digest (@IntCyberDigest)
Meet the women of Conti ransomware group. 💅
❤3💅2
🧠 Devirtualization (شکستن Virtual Machine Protection)
وقتی یه نرمافزار با VMProtect / Themida / Custom VM محافظت شده باشه مهندسی معکوس میره سمت Devirtualization
اینجاست که تحلیلگر باید VM رو مهندسی معکوس کنه
1️⃣ شناسایی VM Entry Points
اولین قدم اینه که بفهمیم برنامه از کجا وارد ماشین مجازی میشه
📌 معمولاً یک سری Prologue ثابت وجود داره:
Push کردن یه سری مقادیر روی استک
پرش به یک Interpreter مرکزی
2️⃣ پیدا کردن VM Handlers
هر دستور VM توسط یه Handler اجرا میشه
این Handlerها مثل opcodeهای CPU واقعی هستن
مثال:
اینجا باید همه Handlerها شناسایی بشن معمولا صدها تا هستن
3️⃣ ساخت Mapping بین VM و CPU واقعی
وقتی Handlerها رو شناسایی کردی باید یک جدول معادلسازی درست کنی
مثلا:
VM Opcode Real Instruction توضیح
4️⃣ ابزارها و روشها برای Devirtualization
Dynamic Tracing → اجرای VM و لاگ گرفتن از دستورها
Static Analysis → پیدا کردن Handlerها در دیساسمبلر
Plugins → مثل [IDA Hex-Rays Devirtualizer Plugins]
Custom Tools → نوشتن Decompiler اختصاصی برای بازسازی کد اصلی
5️⃣ چالشها
Obfuscation روی VM Handlerها
استفاده از چند VM مختلف در یک برنامه
درهمریختگی عمدی Junk Code, Fake Opcodes
Self-Modifying Code
داخل خود VM
🧠 Devirtualization (Breaking VM-Based Protections)
When a binary is protected by VMProtect / Themida / custom VM, reverse engineering becomes about understanding and emulating a fake CPU inside the program
1️⃣ Identify VM Entry Points
The first step is to locate where the real code switches into virtualized code execution
🔍 Typical signs:
A prologue pattern: pushing multiple values/contexts on the stack
A jump or call into a central interpreter function
Execution stops making sense in x86 and looks like dispatcher loops
2️⃣ Locate VM Handlers
Each VM opcode is processed by a handler just like x86 instructions are decoded by the CPU
Example mapping idea:
👉 In practice, there may be hundreds of handlers, sometimes with junk code or mixed execution
3️⃣ Build an Opcode → Real Instruction Mapping
Once you identify handlers you need to build a translation table between VM opcodes and real CPU instructions
📖 Example mapping table:
VM Opcode Real Instruction Meaning
This mapping becomes the foundation of your decompiler/devirtualizer
4️⃣ Methods & Tools for Devirtualization
Dynamic Tracing → Run the VM, log executed opcodes + their effects
Static Analysis → Identify handler functions inside the disassembler
Plugins → Tools like IDA/Ghidra devirtualizer plugins research versions exist
Custom Tools → Write your own noscript/decompiler to rebuild the original logic from VM bytecode
5️⃣ Key Challenges
Obfuscated Handlers → Each handler may have junk code, opaque predicates
Multiple VMs → Some binaries use different VM engines for different functions
Fake Opcodes → Inserted to confuse analysis no-ops, misleading behavior
Self-Modifying Code → The VM engine may rewrite itself in memory at runtime
🔹 Realistic Workflow for an Analyst
1 Find VM entry → identify the dispatcher loop
2 Extract VM bytecode stream
3 Reverse engineer handler functions → document them
4 Build mapping table (opcode → real instruction)
5 Automate devirtualization with a noscript/decompiler
6 Reconstruct original program logic
⚡ In practice:
Analysts often combine dynamic tracing + static reversing
Full automation is rare—usually a mix of noscripting and manual work
VMProtect / Themida add anti-debugging and obfuscation layers on top making this even harder
وقتی یه نرمافزار با VMProtect / Themida / Custom VM محافظت شده باشه مهندسی معکوس میره سمت Devirtualization
اینجاست که تحلیلگر باید VM رو مهندسی معکوس کنه
1️⃣ شناسایی VM Entry Points
اولین قدم اینه که بفهمیم برنامه از کجا وارد ماشین مجازی میشه
📌 معمولاً یک سری Prologue ثابت وجود داره:
Push کردن یه سری مقادیر روی استک
پرش به یک Interpreter مرکزی
2️⃣ پیدا کردن VM Handlers
هر دستور VM توسط یه Handler اجرا میشه
این Handlerها مثل opcodeهای CPU واقعی هستن
مثال:
VM_OP_01 → ADD
VM_OP_02 → MOV
VM_OP_03 → JMP
اینجا باید همه Handlerها شناسایی بشن معمولا صدها تا هستن
3️⃣ ساخت Mapping بین VM و CPU واقعی
وقتی Handlerها رو شناسایی کردی باید یک جدول معادلسازی درست کنی
مثلا:
VM Opcode Real Instruction توضیح
0x12 MOV EAX, EBX کپی مقدار رجیستر
0x34 ADD ECX, 5 جمع ثابت با رجیستر
0x56 JMP addr پرش به آدرس
4️⃣ ابزارها و روشها برای Devirtualization
Dynamic Tracing → اجرای VM و لاگ گرفتن از دستورها
Static Analysis → پیدا کردن Handlerها در دیساسمبلر
Plugins → مثل [IDA Hex-Rays Devirtualizer Plugins]
Custom Tools → نوشتن Decompiler اختصاصی برای بازسازی کد اصلی
5️⃣ چالشها
Obfuscation روی VM Handlerها
استفاده از چند VM مختلف در یک برنامه
درهمریختگی عمدی Junk Code, Fake Opcodes
Self-Modifying Code
داخل خود VM
🧠 Devirtualization (Breaking VM-Based Protections)
When a binary is protected by VMProtect / Themida / custom VM, reverse engineering becomes about understanding and emulating a fake CPU inside the program
1️⃣ Identify VM Entry Points
The first step is to locate where the real code switches into virtualized code execution
🔍 Typical signs:
A prologue pattern: pushing multiple values/contexts on the stack
A jump or call into a central interpreter function
Execution stops making sense in x86 and looks like dispatcher loops
2️⃣ Locate VM Handlers
Each VM opcode is processed by a handler just like x86 instructions are decoded by the CPU
Example mapping idea:
VM_OP_01 → ADD
VM_OP_02 → MOV
VM_OP_03 → JMP
👉 In practice, there may be hundreds of handlers, sometimes with junk code or mixed execution
3️⃣ Build an Opcode → Real Instruction Mapping
Once you identify handlers you need to build a translation table between VM opcodes and real CPU instructions
📖 Example mapping table:
VM Opcode Real Instruction Meaning
0x12 MOV EAX, EBX copy register
0x34 ADD ECX, 5 add immediate constant
0x56 JMP addr unconditional jump
This mapping becomes the foundation of your decompiler/devirtualizer
4️⃣ Methods & Tools for Devirtualization
Dynamic Tracing → Run the VM, log executed opcodes + their effects
Static Analysis → Identify handler functions inside the disassembler
Plugins → Tools like IDA/Ghidra devirtualizer plugins research versions exist
Custom Tools → Write your own noscript/decompiler to rebuild the original logic from VM bytecode
5️⃣ Key Challenges
Obfuscated Handlers → Each handler may have junk code, opaque predicates
Multiple VMs → Some binaries use different VM engines for different functions
Fake Opcodes → Inserted to confuse analysis no-ops, misleading behavior
Self-Modifying Code → The VM engine may rewrite itself in memory at runtime
🔹 Realistic Workflow for an Analyst
1 Find VM entry → identify the dispatcher loop
2 Extract VM bytecode stream
3 Reverse engineer handler functions → document them
4 Build mapping table (opcode → real instruction)
5 Automate devirtualization with a noscript/decompiler
6 Reconstruct original program logic
⚡ In practice:
Analysts often combine dynamic tracing + static reversing
Full automation is rare—usually a mix of noscripting and manual work
VMProtect / Themida add anti-debugging and obfuscation layers on top making this even harder
❤3🦄1
وقتی سورس کد رو ببینی یه switch ساده خیلی راحت و خوناس ولی وقتی کامپایل میشه کامپایلر معمولا برای سرعت یه جدول پرش Jump Table درست میکنه برای کسی که داره مهندسی معکوس میکنه اگه ندونه این چیه کد خیلی عجیب و ترسناک به نظر میاد
شکل سورس کد
شکل اسمبلی سادهسازی شده
و جدول پرش jump_table چیزی شبیه اینه:
یعنی:
نکته در مهندسی معکوس
وقتی توی IDA یا Ghidra میری و یه jmp [eax*4 + something] میبینی این تقریبا قطعیه که switch-case هست
IDA معمولا خودش تشخیص میده و نشون میده switch jump ولی اگه نشناسه باید دستی جدول رو بازسازی کنی
4 Default Case
اگه مقدار خارج از بازه باشه مثلا x = 1000 یه پرش شرطی قبلش هست که میفرسته به default case
چرا مهمه توی RE؟
خیلی وقتا توابع مهم برنامه توی همین switch ها صدا زده میشن مثلا پروتکل شبکه یا پارسر فایل اگه ندونی این switch بوده فکر میکنی یه سری پرش عجیبغریب توی کده
🔹 تمرین پیشنهادی:
یه کد C با switch بزرگ مثلا 10 case بنویس
با optimization روشن مثلا gcc -O2 کامپایل کن
توی IDA یا Ghidra ببین چطور Jump Table ساخته میشه
🎛 Switch-Case → Jump Table in Assembly
1 High-Level C Code
At source level this is very readable
2 Compiled Assembly Pattern
A compiler (with optimization enabled) usually transforms this into a jump table for speed:
And the jump table looks like:
So execution flow is:
The default_case is handled by the ja check before the jump
3 Why It Looks Scary in RE
When you see something like:
in IDA/Ghidra/x64dbg, it may look like black magic if you don’t know jump tables.
But in reality:
eax = switch variable
*4 = size of each entry (32-bit addresses)
0x123456 = base address of the jump table
IDA often auto-detects this and shows it as a switch jump
But sometimes it fails → then you need to manually reconstruct the table
4 Why It Matters in RE
Switch tables often dispatch major program logic
Protocol parsers, interpreters, network handlers, file format decoders → almost always implemented as switches
If you don’t recognize it, the function looks like a random mess of indirect jumps
🔹 Practical Exercise
1 Write a C program with a large switch 10+ cases
2 Compile with optimizations e.g. gcc -O2 test.c -o test
3 Open in IDA or Ghidra
4 Look for the jmp [reg*4 + offset] pattern
5 Try to map back cases manually to confirm you can identify jump tables
شکل سورس کد
switch(x) {
case 1: func1(); break;
case 2: func2(); break;
case 3: func3(); break;
default: func_default(); break;
}
شکل اسمبلی سادهسازی شده
cmp eax, 3 ; x <= 3 ?
ja default_case ; اگر بزرگتر بود برو به default
jmp dword ptr [eax*4 + jump_table] ; بپر به آدرس مورد نظر
و جدول پرش jump_table چیزی شبیه اینه:
jump_table:
dd loc_case1
dd loc_case2
dd loc_case3
یعنی:
اگه eax = 0 → پرش به case1
اگه eax = 1 → پرش به case2
اگه eax = 2 → پرش به case3
نکته در مهندسی معکوس
وقتی توی IDA یا Ghidra میری و یه jmp [eax*4 + something] میبینی این تقریبا قطعیه که switch-case هست
IDA معمولا خودش تشخیص میده و نشون میده switch jump ولی اگه نشناسه باید دستی جدول رو بازسازی کنی
4 Default Case
اگه مقدار خارج از بازه باشه مثلا x = 1000 یه پرش شرطی قبلش هست که میفرسته به default case
چرا مهمه توی RE؟
خیلی وقتا توابع مهم برنامه توی همین switch ها صدا زده میشن مثلا پروتکل شبکه یا پارسر فایل اگه ندونی این switch بوده فکر میکنی یه سری پرش عجیبغریب توی کده
🔹 تمرین پیشنهادی:
یه کد C با switch بزرگ مثلا 10 case بنویس
با optimization روشن مثلا gcc -O2 کامپایل کن
توی IDA یا Ghidra ببین چطور Jump Table ساخته میشه
🎛 Switch-Case → Jump Table in Assembly
1 High-Level C Code
switch (x) {
case 1: func1(); break;
case 2: func2(); break;
case 3: func3(); break;
default: func_default(); break;
}
At source level this is very readable
2 Compiled Assembly Pattern
A compiler (with optimization enabled) usually transforms this into a jump table for speed:
cmp eax, 3 ; is x <= 3 ?
ja default_case ; if greater, jump to default
jmp dword ptr [eax*4 + jump_table] ; indirect jump
And the jump table looks like:
jump_table:
dd loc_case1
dd loc_case2
dd loc_case3
So execution flow is:
eax = 0 → jump to case1
eax = 1 → jump to case2
eax = 2 → jump to case3
The default_case is handled by the ja check before the jump
3 Why It Looks Scary in RE
When you see something like:
jmp dword ptr [eax*4 + 0x123456]
in IDA/Ghidra/x64dbg, it may look like black magic if you don’t know jump tables.
But in reality:
eax = switch variable
*4 = size of each entry (32-bit addresses)
0x123456 = base address of the jump table
IDA often auto-detects this and shows it as a switch jump
But sometimes it fails → then you need to manually reconstruct the table
4 Why It Matters in RE
Switch tables often dispatch major program logic
Protocol parsers, interpreters, network handlers, file format decoders → almost always implemented as switches
If you don’t recognize it, the function looks like a random mess of indirect jumps
🔹 Practical Exercise
1 Write a C program with a large switch 10+ cases
2 Compile with optimizations e.g. gcc -O2 test.c -o test
3 Open in IDA or Ghidra
4 Look for the jmp [reg*4 + offset] pattern
5 Try to map back cases manually to confirm you can identify jump tables
💋3
Tools you should know :
1 - radare2 :
official website :
https://rada.re/n/
github :
https://github.com/radareorg
2 - Ghidra :
official website :
https://ghidra-sre.org/
github :
https://github.com/NationalSecurityAgency/ghidra
3 - IDA Free / IDA Pro (Hex-Rays) :
https://hex-rays.com
4 - Cutter :
official website :
https://cutter.re/
github :
https://github.com/rizinorg/cutter
5 - iaito :
official website :
https://rada.re/n/iaito.html
github :
https://github.com/radareorg/iaito
6 - reflutter :
https://github.com/ptswarm/reFlutter
7 - Blutter :
https://github.com/worawit/blutter
8 - Apktool :
official website :
https://apktool.org/
github :
https://github.com/iBotPeaches/Apktool
9 - Jadx-gui :
https://github.com/skylot/jadx
10 - dnSpy :
https://github.com/dnSpy/dnSpy
11 - Binary Ninja :
https://binary.ninja/
12 - x64dbg :
https://x64dbg.com/
1 - radare2 :
official website :
https://rada.re/n/
github :
https://github.com/radareorg
2 - Ghidra :
official website :
https://ghidra-sre.org/
github :
https://github.com/NationalSecurityAgency/ghidra
3 - IDA Free / IDA Pro (Hex-Rays) :
https://hex-rays.com
4 - Cutter :
official website :
https://cutter.re/
github :
https://github.com/rizinorg/cutter
5 - iaito :
official website :
https://rada.re/n/iaito.html
github :
https://github.com/radareorg/iaito
6 - reflutter :
https://github.com/ptswarm/reFlutter
7 - Blutter :
https://github.com/worawit/blutter
8 - Apktool :
official website :
https://apktool.org/
github :
https://github.com/iBotPeaches/Apktool
9 - Jadx-gui :
https://github.com/skylot/jadx
10 - dnSpy :
https://github.com/dnSpy/dnSpy
11 - Binary Ninja :
https://binary.ninja/
12 - x64dbg :
https://x64dbg.com/
❤1
For building and debugging regex (Regular Expression)
For Building Visit :
https://pythex.org/
For regex cheat sheet visit :
https://www.debuggex.com/cheatsheet/regex/python
For Building Visit :
https://pythex.org/
For regex cheat sheet visit :
https://www.debuggex.com/cheatsheet/regex/python
pythex.org
Pythex: a Python regular expression editor
Pythex is a real-time regular expression editor for Python, a quick way to test your regular expressions.
❤1
https://youtu.be/LMNGT68iibE
How to make radare2 noscripts and how to use rasm2 (assembler/disassembler) and more
How to make radare2 noscripts and how to use rasm2 (assembler/disassembler) and more
YouTube
learn radare2 noscripting and rasm2 #reverseengineering #noscripting #radare2 #rasm2
This video is a quick guide showing how to make radare2 noscripts (not r2pipe 'python') and how to use rasm2 (assembler/disassembler) also the most used and common radare2 commands
The applied example here is compiled on an android phone (arm64-v8a) using…
The applied example here is compiled on an android phone (arm64-v8a) using…
❤1