🎭 Code Virtualization (VM-Based Protection)

اینجا دیگه سطح دفاعی میره روی مغز سیستم! 😅

پکرهایی مثل VMProtect و Themida از این تکنیک استفاده میکنن
ایده‌ش اینه که:

🔹 به‌جای اینکه برنامه‌ی اصلی به زبان ماشین CPU اجرا بشه
🔹 کد به دستورالعمل‌های یک CPU مجازی Custom VM تبدیل میشه

یعنی چی؟
یعنی برنامه یه Interpreter تو خودش داره که دستورالعمل‌های عجیب و غریب خودش رو اجرا میکنه
هر دستورالعمل واقعی CPU مثل MOV, ADD, CALL تبدیل میشه به یه سری دستور خیالی مثل:

VM_INST_01

VM_INST_A3

VM_INST_FF


و فقط همون ماشین مجازی می‌فهمه که اینا یعنی چی




1️⃣ ساختار کار

اول Bytecode مخصوص VM ساخته میشه

بعد کد اصلی پاک یا رمزنگاری میشه

VM Interpreter
کد رو یکی یکی میخونه و معادلش رو روی CPU واقعی اجرا میکنه





2️⃣ چرا سخت میشه تحلیل کرد؟

چون شما به جای x86 واقعی با یک زبان عجیب و غریب طرفی

هر برنامه حتی هر بخش از برنامه میتونه VM خودش رو داشته باشه

دیگه دیباگرهای معمولی x64dbg، OllyDbg، IDA ساده بی‌فایده میشن





3️⃣ ترکیب با Anti-Debug

خیلی وقتا VMProtect فقط VM نمیاره بلکه Anti-Debug رو هم باهاش قاطی میکنه
📌 یعنی همزمان:

کد غیرقابل فهم میشه Obfuscation شدید

و دیباگرها هم نمیتونن راحت attach شن




4️⃣ روش‌های Devirtualization

اینجا هم هنر مهندسی معکوس میاد وسط 😎

برای شکستن VM-Based Protection باید:

اول VM Handlerها رو پیدا کرد تابع‌هایی که هر دستور رو اجرا میکنن

بعد معادل دستورهای VM رو Map کرد به دستورهای واقعی CPU

در نهایت یک Decompiler اختصاصی نوشت تا دوباره کد اصلی برگرده


این دقیقا همون چیزیه که توی تحلیلگرهای بزرگ مثل IDA با پلاگین‌های مخصوص یا ابزارهای شخصی‌سازی شده استفاده میشه





🎭 Code Virtualization (VM-Based Protection)

This is where defensive techniques go straight for the brain of the system! 😅 Packers like VMProtect and Themida use this approach

The idea is simple but brutal:
🔹 Instead of running the original program directly on the CPU

🔹 The code is transformed into instructions of a custom virtual CPU (VM)




What does that mean?

The program has an interpreter inside itself that executes strange custom instructions

So instead of normal x86 opcodes like MOV, ADD, CALL, you end up with something like:

VM_INST_01
VM_INST_A3
VM_INST_FF

…and only the built-in VM knows what those mean




1️⃣ How it works (basic structure):

1 The original code is translated into custom VM bytecode


2 The original instructions are either removed or encrypted


3 The VM interpreter reads the bytecode one by one and executes the equivalent operation on the real CPU






2️⃣ Why is it so hard to analyze?

Because you’re no longer looking at real x86 instructions—you’re dealing with an entirely made-up language

Different sections of the program may even use different VMs

Normal debuggers like x64dbg, OllyDbg, or vanilla IDA become useless





3️⃣ Often combined with Anti-Debugging

VMProtect doesn’t just virtualize code—it usually mixes in anti-debugging tricks as well

📌 So at the same time:

The code becomes unreadable heavy obfuscation

Debuggers can’t easily attach or step through





4️⃣ Devirtualization the reverse-engineer’s art 😎


To break VM-based protection, the reverse engineer has to:

1 Identify the VM handlers functions that execute each custom instruction


2 Map those VM instructions back to real CPU instructions


3 Build or noscript a custom decompiler to reconstruct the original logic



This is exactly what advanced reverse engineers do with IDA plugins or their own custom tools

Data Structures
در اسمبلی
اینجاست که مهندسی معکوس تازه رنگ و بوی واقعی میگیره چون اکثر برنامه‌ها فقط جمع و تفریق عدد نیستن با ساختار داده‌ها کار میکنن



📌 چرا مهمه؟

وقتی دارید به یه باینری نگاه میکنید به ندرت می‌بینید فقط با متغیر ساده سروکار داشته باشه معمولا یه Struct یا Array پشت قضیه هست باید بلد باشید از روی دسترسی‌های حافظه حدس بزنید ساختار داده چی بوده





1 Array

توی اسمبلی فقط یه بلوک پشت سر هم از حافظه‌ست

هر عنصر طبق اندازه نوع داده آدرس‌دهی میشه


📖 مثال:

int arr[5] = {1,2,3,4,5};

اسمبلی معادل تقریبی:

mov eax, [ebp-10h] ; arr[0]
mov eax, [ebp-0Ch] ; arr[1]
mov eax, [ebp-08h] ; arr[2]

یا اگر با Index:

mov eax, [ebx+ecx*4] ; arr[ecx]

2 Struct

Struct در اسمبلی فقط یه سری داده پشت سر همه

تفاوتش با Array اینه که هر فیلد اندازه و نوع متفاوت داره


📖 مثال:

struct user {
int age;
char name[20];
};

اسمبلی معادل:

mov eax, [ebx] ; age
movzx ecx, byte ptr [ebx+4] ; name[0]
movzx edx, byte ptr [ebx+5] ; name[1]

👉 اینجا ebx همون آدرس پایه Struct هست بعد با Offset میریم سراغ فیلدها




3 Nested Structures

یه Struct داخل Struct دیگه → همون ایده ولی Offset بزرگ‌تر




4 Pointers به Struct یا Array

وقتی دیدید یه متغیر بارها مثل [eax+4] یا [eax+8] خونده میشه خیلی وقتا یعنی اون متغیر در واقع Pointer به یه Struct یا Array هست




🌟 نکته کاربردی در RE

تو IDA و ابزارهای دیگه می‌تونید خودتون Struct تعریف کنی و روی حافظه Map کنی اینطوری بجای [ebx+8] می‌بینید user.age. هم فهمش راحت‌تر میشه هم بعدا سریعتر تحلیل میکنید




🔹 تمرین پیشنهادی:

یه Struct ساده توی C تعریف کنید مثلا id و salary برای کارمند

یه Array از اون Struct بسازید

struct employee {
int id;
int salary;
};

توی باینری ببینید چطور بهشون دسترسی پیدا میکنه




🧩 Data Structures in Assembly

This is where reverse engineering really gets interesting—because most real programs aren’t just adding and subtracting numbers They’re working with data structures




📌 Why does it matter?

When you’re looking at a binary you rarely see only simple variables Most of the time there’s an array or a struct hidden behind the memory accesses
You need to learn how to guess the original structure just by watching how memory is accessed




1️⃣ Arrays

In assembly, an array is just a continuous block of memory. Each element is accessed by offset = base + index * element_size

📖 Example in C:

int arr[5] = {1,2,3,4,5};

Assembly (rough idea):

mov eax, [ebp-10h] ; arr[0]
mov eax, [ebp-0Ch] ; arr[1]
mov eax, [ebp-08h] ; arr[2]

Or with an index register:

mov eax, [ebx+ecx*4] ; arr[ecx]

2️⃣ Structs

A struct in assembly is just a block of memory with different fields at fixed offsets
The difference from arrays: fields can have different sizes/types

📖 Example in C:

struct user {
int age;
char name[20];
};

Assembly (approximate):

mov eax, [ebx] ; user.age
movzx ecx, byte ptr [ebx+4] ; user.name[0]
movzx edx, byte ptr [ebx+5] ; user.name[1]

👉 Here ebx is the base address of the struct, and each field is accessed by offset




3️⃣ Nested Structures

You can have a struct inside another struct
Same idea—but the offsets get larger as fields accumulate




4️⃣ Pointers to Arrays/Structs

If you see the same base register accessed multiple times with different small offsets:

mov eax, [eax+4]
mov ecx, [eax+8]

…it’s a strong hint that the variable is actually a pointer to a struct or array




🌟 Practical RE Tip

In IDA (or Ghidra), you can define your own struct types and map them onto memory
So instead of:

[ebx+8]

you’ll see something like:

user.age

This makes analysis faster and much more readable




🔹 Suggested Exercise

1Write a C struct, e.g.:

struct employee {
int id;
int salary;
};

2 Create an array of employees



3 Compile it, then in IDA/x64dbg watch how the compiler generates memory accesses

Reverse Engineering For Hackers

Ghidra CheatSheet

Reverse Engineering flutter apps
about dart VM and tools

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 رو دوباره استفاده کنه و از 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

وقتی 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.

Binary Comparison using radiff2

https://youtu.be/RsI8hNhsi_U

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

dalvikus

A modern Android reverse engineering and modification toolkit built with Compose Multiplatform, available for windows, linux & mac.

https://github.com/loerting/dalvikus.git

🎯 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

🧠 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 واقعی هستن
مثال:

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

وقتی سورس کد رو ببینی یه switch ساده خیلی راحت و خوناس ولی وقتی کامپایل میشه کامپایلر معمولا برای سرعت یه جدول پرش Jump Table درست میکنه برای کسی که داره مهندسی معکوس میکنه اگه ندونه این چیه کد خیلی عجیب و ترسناک به نظر میاد




شکل سورس کد

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