تا حالا باینری باز کردی که هیچی توش نبوده باشه جز یه مشت بایت الکی؟ بعد وقتی اجراش کردی وسط RAM یهو کد اصلی ظاهر بشه؟ این همون Self-Modifying Code هست
2 توضیح ساده:
بعضی بدافزارها خودشون رو رمزگذاری میکنن
وقتی اجرا میشن یه Loader کوچیک بخش اصلی رو تو حافظه Decrypt میکنه
نتیجه → فایل روی دیسک چیزی نشون نمیده ولی وسط RAM همه چی اتفاق میوفته
3 نمونه عملی (ساده):
👉 اینجا Payload اصلی فقط بعد از XOR توی RAM زنده میشه
4 بخش جذاب:
مهندس معکوس باید وسط اجرا با Memory Dump یا Breakpoint هوشمند اون لحظهای که کد اصلی ظاهر میشه رو شکار کنه
ابزارهایی مثل Scylla یا x64dbg Dump اینجا هستن
👀 به طور خلاصه: برای همینه که بدافزار نویسا عاشقشن ولی مهندسان معکوس ازش متنفرن
🌀 Self-Modifying Code (SMC)
Ever opened a binary and found nothing but junk bytes or meaningless data?
But once you run it… suddenly the real code magically appears in RAM?
That’s self-modifying code
1️⃣ What’s going on?
Malware (or a protector/packer) encrypts its main code
On disk → the file looks useless
At runtime → a tiny loader decrypts the hidden payload directly into memory
Result → nothing suspicious in the file, everything happens inside RAM
2️⃣ Simple example (Assembly)
3️⃣ Why it’s painful for reverse engineers
Static analysis tools (IDA, Ghidra) only see junk
The real logic only appears after runtime decryption
The analyst has to catch the moment the code is unpacked
4️⃣ How REs fight back
Use breakpoints at decryption loops
Pause execution right after unpacking finishes
Dump the real memory image with tools like:
🔹 x64dbg (Dump Memory feature)
🔹 Scylla / ScyllaHide
🔹 OllyDump / Process Hacker
💡 In short:
Self-modifying code = nothing on disk, everything in RAM
That’s why it’s loved by malware authors and hated by reverse engineers
#BlueTeam
#RedTeam
#ReverseEngineering
#Self_Modifying_Code
2 توضیح ساده:
بعضی بدافزارها خودشون رو رمزگذاری میکنن
وقتی اجرا میشن یه Loader کوچیک بخش اصلی رو تو حافظه Decrypt میکنه
نتیجه → فایل روی دیسک چیزی نشون نمیده ولی وسط RAM همه چی اتفاق میوفته
3 نمونه عملی (ساده):
start:
lea esi, [encrypted_data]
lea edi, [decrypted_data]
mov ecx, size
decrypt_loop:
xor byte [esi], 0xAA
movsb
loop decrypt_loop
jmp decrypted_data
👉 اینجا Payload اصلی فقط بعد از XOR توی RAM زنده میشه
4 بخش جذاب:
مهندس معکوس باید وسط اجرا با Memory Dump یا Breakpoint هوشمند اون لحظهای که کد اصلی ظاهر میشه رو شکار کنه
ابزارهایی مثل Scylla یا x64dbg Dump اینجا هستن
👀 به طور خلاصه: برای همینه که بدافزار نویسا عاشقشن ولی مهندسان معکوس ازش متنفرن
🌀 Self-Modifying Code (SMC)
Ever opened a binary and found nothing but junk bytes or meaningless data?
But once you run it… suddenly the real code magically appears in RAM?
That’s self-modifying code
1️⃣ What’s going on?
Malware (or a protector/packer) encrypts its main code
On disk → the file looks useless
At runtime → a tiny loader decrypts the hidden payload directly into memory
Result → nothing suspicious in the file, everything happens inside RAM
2️⃣ Simple example (Assembly)
start:👉 Here, the payload only exists after XOR — in memory, never on disk
lea esi, [encrypted_data]
lea edi, [decrypted_data]
mov ecx, size
decrypt_loop:
xor byte [esi], 0xAA
movsb
loop decrypt_loop
jmp decrypted_data
3️⃣ Why it’s painful for reverse engineers
Static analysis tools (IDA, Ghidra) only see junk
The real logic only appears after runtime decryption
The analyst has to catch the moment the code is unpacked
4️⃣ How REs fight back
Use breakpoints at decryption loops
Pause execution right after unpacking finishes
Dump the real memory image with tools like:
🔹 x64dbg (Dump Memory feature)
🔹 Scylla / ScyllaHide
🔹 OllyDump / Process Hacker
💡 In short:
Self-modifying code = nothing on disk, everything in RAM
That’s why it’s loved by malware authors and hated by reverse engineers
#BlueTeam
#RedTeam
#ReverseEngineering
#Self_Modifying_Code
❤7