رمزنگاری/انکدینگ رشته‌ ها String Encryption


برنامه‌ ها رشته‌های متنی مثل پیام‌ها، URLها، کلیدها رو توی فایل به‌صورت رمز یا انکد نگه میدارن و فقط موقع اجرا بازشون میکنن تا کسی با نگاه کردن توی باینری پیداشون نکنه

توضیح:
دیدید یه باینری اصلا رشته‌ای نداره؟ احتمالا سازنده‌ ش رشته‌ها رو قفل کرده یعنی مثلا «hello» تو فایل نیست چون یه تابع موقع اجرا میاد و بازش میکنه این کار براشون میتونه یه جور حفاظتی باشه یا تلاش برای مخفی کاری

مثال:
تو دیس‌ اسمبلر میبینید هیچ رشته خوانایی نیست اما یه تابع هست که چند باره حافظه رو میسازه و داده‌ ها رو تبدیل میکنه احتمالا رشته‌ها در runtime ساخته میشن

دیتکشن

نبودن رشته‌های خوانا در بخش .rdata/.rodata

توابعی که مکررا حافظه allo/free میکنن و روی بافر ها عملیات بیت/بایت انجام میدن

بی نظمی بالای بخش داده‌ ها


میتیگیشن (مدافع/برنامه‌نویس)

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

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




String Encryption

Programs store text strings (such as messages, URLs, keys) in a file as a password or encoding and only open them at runtime so that no one can find them by looking in the binary

Explanation:
Did you see that a binary doesn't have a string at all? The creator probably locked the strings, meaning "hello" is not in the file because a function comes in and opens it at runtime. This could be a form of protection or an attempt at hiding.

Example:
In the disassembler, you see no readable strings, but there is a function that creates memory and converts data several times. The strings are probably created at runtime.

Detection

No readable strings in the .rdata/.rodata section

Functions that repeatedly allocate/free memory and perform bit/byte operations on buffers

High entropy in the data section

Mitigation (Defender/Programmer)

Defender: Monitor calls that create strings at runtime and check for unusual patterns

Developer: Use secure logging and configuration to reduce the need for unnecessary string encryption

@reverseengine

Control-flow flattening و Junk Code

توضیح:
کد ساده رو طوری مینویسن یا تبدیل میکنن که ترتیب منطقیش معلوم نباشه با جدول پریدن‌ ها و کلی شاخه بی‌ ربط یا کلی کد بی‌ فایده junk میزنن تا تشخیص الگوریتم سخت شه


یادتونه یه if ساده چقدر خوندنش راحته؟ بعضی‌ها اون if رو میکوبن توی یه جدول پریدن و چند تا case اضافه میکنن دیگه شبیه لابیرنت میشه همین کار باعث میشه خوندن جریان برنامه سخت شه

مثال:
در CFG میبینید به‌ جای چند شاخه ساده کلی بلاک کوچک و پرش بین جدول‌ هاست این یعنی control-flow flattening یا اضافه کردن کد بی‌ ربط

دیتکشن

گراف کنترل جریان خیلی تودرتو و شاخه‌ های زیاد

توابع خیلی طولانی پر از jumps و switch-like tables

کدهایی که ظاهرا کاری نمیکنن ولی اجرا‌ میشن


میتیگیشن

آنالیزور: ترکیب static و dynamic analysis یعنی هم disasm ببینید هم اجرا کن تا بفهمید کد واقعی کدیه که در runtime فعال میشه

توسعه‌دهنده: مستند سازی و unit test تا اگر مجبور به obfuscation شدید حداقل تیمتون بتونه نگهش داره


Control-flow flattening and Junk Code

Explanation:
They write or transform simple code in such a way that its logical order is not clear, with jump tables and a lot of irrelevant branches or a lot of useless code, making it difficult to understand the algorithm

Remember how easy a simple if is to read? Some people throw that if in a table, jump and add a few cases, and it becomes like a labyrinth, which makes it difficult to read the program flow.

Example:
In CFG, instead of a few simple branches, you see a whole bunch of small blocks and jumps between tables. This means control-flow flattening or adding irrelevant code.

Detection

The control flow graph is very nested and has many branches.

Very long functions full of jumps and switch-like tables.

Code that doesn't seem to do anything but is executed.

Mitigation

Analyzer: A combination of static and dynamic analysis, meaning you can see both disasm and execute it to understand that the real code is the code that will be activated at runtime.

Developer: Documentation and unit testing so that if you have to obfuscate, at least your team can maintain it.


@reverseengine

Roadmap Malware Analysis

C

C++

Reverse engineering for beginners book and other corses

Assembly

Windows Internals

Win32 Api

Python

Malware analysis professional course

Zero2automated course

Sans for 610

practical malware analysis book

Malware analysis cookbook book

Mastering malware analysis packtpub book


این رودمپ رو خیلی وقت پیش خودم نوشتم برای دوستانی که میخان تحلیل بدافزار انجام بدن استفاده کنن

I wrote this roadmap a long time ago for my friends who want to do malware analysis to use

@reverseengine

Update on Attacks by Threat Group APT-C-60


https://blogs.jpcert.or.jp/en/2025/11/APT-C-60_update.html

@reverseengine

Windows Heap Exploitation - From Heap Overflow to Arbitrary R/W

https://mrt4ntr4.github.io/Windows-Heap-Exploitation-dadadb

@reverseengine

UPX
و نمونه‌ های پیچیده‌ تر

فایل اصلی فشرده یا رمز میشه و Loader موقع اجرا محتوا رو آنپک میکنه  پس static analysis اغلب بی‌ فایده‌ ست تا وقتی که unpack شدن انجام بشه


یه فایل ممکنه کوچیک باشه ولی وقتی اجرا میکنی ناگهان یه قسمت بزرگ از کد تو حافظه ظاهر میشه  یعنی packed بوده مثل اینکه یه جعبه بسته رو باز کنی و داخلش یه چیز دیگه باشه

مثال:
تو header یا با نگاه کردن به اندازه امضا میتونید بفهمید packed هست در اجرای برنامه میبینید بخش ههای جدیدی توی حافظه ساخته میشه  علامت unpacking

دیتکشن

امضا های packer شناخته‌ شده توی header

افزایش ناگهانی بخش‌های اجرایی در حافظه بعد از لانچ

رفتار loader در runtime که حافظه رو مینویسه و بعد jump به بخش جدید میزنه


میتیگیشن

اجرا در sandbox/VM با مانیتورینگ کامل (فایل شبکه پروسس) تا رفتار after-unpack دیده بشه

برای سازمان‌ ها: امضای فایل‌ ها و بررسی integrity قبل از اجرا و quarantine کردن فایل‌ های مشکوک



UPX and more complex examples

The original file is compressed or encrypted and the Loader unpacks the content at runtime, so static analysis is often useless until unpacking is done

A file may be small, but when you run it, a large chunk of code suddenly appears in memory, meaning it was packed, like opening a closed box and there's something else inside

Example:
You can tell it's packed in the header or by looking at the size of the signature. When running the program, you'll see new sections being created in memory, a sign of unpacking

Detection

Known packer signatures in the header

Sudden increase in executable sections in memory after launch

Loader behavior at runtime that writes memory and then jumps to a new section

Mitigation

Run in a sandbox/VM with full monitoring (process network file) to see after-unpack behavior

For organizations: file signing and integrity checking before execution and quarantining suspicious files

@reverseengine

تابع‌هایی که از stack frame استفاده نمیکنن (Leaf بدون Prologue)

پس این قسمت کلیدی هست


مثال C:

int add5(int x) {
return x + 5;
}

اسمبلی بهینه کامپایلر (O2):

add5:
lea eax, [rdi + 5]
ret

چرا اینجا push rbp و mov rbp, rsp نداریم؟

چون:

تابع هیچ متغیر محلی نداره

تابع تابع دیگری رو فرانمیخونه (leaf)

مقدار برگشتی(return address) فقط در رجیستر‌ها محاسبه میشه

نتیجه: کامپایلر stack frame نمیسازه


Functions that do not use stack frame (Leaf without Prologue)

So this is the key part

C example:

int add5(int x) {
return x + 5;
}

Compiler optimized assembly (O2):

add5:
lea eax, [rdi + 5]
ret

Why don't we have push rbp and mov rbp, rsp here?

Because:

The function has no local variables

The function does not call another function (leaf)

The return value (return address) is calculated only in registers

Result: The compiler does not create a stack frame

@reverseengine

نشونه ها داخل دیس‌ اسمبلی

push rbp + mov rbp, rsp
فریم ساخته شده


sub rsp, x متغیر محلی وجود داره


دسترسی به [rbp - offset]
استفاده از متغیر محلی روی استک

call
معمولا Non-leaf (به جز Tail-call)


نبودن RBP و کار فقط با RSP
خروجی کامپایلر بهینه‌ سازی شده است


Symbols inside the disassembly

push rbp + mov rbp, rsp Frame created

sub rsp, x Local variable exists

Access to [rbp - offset]
Use local variable on stack

Call is usually Non-leaf (except Tail-call)

No RBP and only works with RSP
Compiler output is optimized

@reverseengine

Virtualization-based Obfuscation Devirtualization و Kernel RE
(فقط نرم‌افزار)

Virtualization-based Obfuscation VMProtect / Themida


یه لایه مجازی‌ ساز داخل باینری میذارن: کد اصلی تبدیل میشه به دستورالعمل‌ های مخصوص VM و یه انجین در زمان اجرا اونا رو اجرا میکنه سخت میشه بفهمید اصل منطق چیه

مثال:
نمونه open-source که با ابزار obfuscator ساده بسته‌ بندی شده رو باز کنید و ببینید بخش dispatcher چطور بین بلاک‌ ها سوئیچ میکنه فقط ببینید و ساختار جدول پرش رو تحلیل کنید نه حذف حفاظ

دیتکشن (چی باید نگاه کنید)

وجود یک حلقه dispatcher که با جدول‌ ایندکس‌ ها بلاک‌ ها رو اجرا میکنه

الگو های ثابت decode/dispatch در چند تا تابع

کاهش شدید خوانایی pseudocode اما افزایش پیچیدگی CFG


میتیگیشن (مدافع/توسعه‌دهنده)

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

آنالیزور/مدافع: ترکیب آنالیز ایستا و دینامیک لاگ‌ گیری runtime و trace گرفتن از dispatcher کمک میکنه تا بفهمید VM چه دستورات منطقی‌ ای اجرا میکنه




Virtualization-based Obfuscation Devirtualization and Kernel RE
(software only)

Virtualization-based Obfuscation VMProtect / Themida

Puts a virtualization layer inside the binary: the original code is converted to VM-specific instructions and an engine executes them at runtime. It is difficult to understand the logic behind it.

Example:
Open the open-source example packaged with a simple obfuscator tool and see how the dispatcher section switches between blocks. Just look and analyze the jump table structure, not remove the protection.

Detection (what to look for)

Presence of a dispatcher loop that executes blocks with index tables.

Constant decode/dispatch patterns in several functions.

Severely reduces pseudocode readability but increases CFG complexity.

Mitigation (Defender/Developer)

For developers: Use Obfuscation only when necessary and keep internal documentation.

Analyzer/Defender: Analysis combination Static and dynamic runtime logging and dispatcher tracing help you understand what logical commands the VM is executing.

@reverseengine

IDA Generating signatures for Nim and other non-C programming languages

https://hex-rays.com/blog/plugin-focus-generating-signatures-for-nim-and-other-non-c-programming-languages

@reverseengine

این پروژه یک وایت بورد در IDA در اختیارتون میزاره که میتونید داخلش هر چیزی که خواستید رو طراحی کنید

This project provides you with a whiteboard in IDA where you can design anything you want

https://github.com/idkhidden/DrawIDA

@reverseengine

WoW64 internals

https://wbenny.github.io/2018/11/04/wow64-internals.html

@reverseengine

Levering Generative AI to Reverse Engineering XLoader

https://research.checkpoint.com/2025/generative-ai-for-reverse-engineering

@reverseengine

Devirtualization
روش‌های دفاع/تحلیلی


وقتی با VM-based obfuscation روبه‌رو میشید باید بفهمید چه الگویی برای برگردوندن pseudocode استفاده میکنن راه‌ حل‌ ها معمولا ترکیبی از آنالیز ایستا برای شناسایی و آنالیز دینامیک برای تقلید اجرای VM هستن

مثال:
trace
گرفتن از اجرای برنامه و استخراج sequence ای از دستورات dispatche
مثل opcode های VM و دسته‌ بندی‌ شون بدون اینکه بخواید قفل‌‌ ها رو بشکنید فقط ساختار دستورها رو ببینید

دیتکشن

الگوهای تکراری در dispatcher که به opcodeهای مشخص اشاره میکنن

مقادیر ثابت جدول‌های ترجمه که در runtime خونده و استفاده میشن


میتیگیشن

محقق: مستندسازی دقیق از رفتار runtime و نگهداری traces برای تحلیل‌های بعدی

توسعه‌دهنده: اگر از VM استفاده میکنی لاگ‌های داخلی برای تیم خودت نگه دار تا در troubleshooting بهت کمک کنه


Devirtualization
Defense/Analysis Methods

When faced with VM-based obfuscation, you need to understand what pattern they are using to return pseudocode. Solutions are usually a combination of static analysis to identify and dynamic analysis to mimic VM execution

Example:
Trace
Taking a program execution and extracting a sequence of dispatcher instructions

Like VM opcodes and their categories without trying to break the locks, just see the instruction structure

Detection

Repeated patterns in dispatcher that point to specific opcodes

Constant values of translation tables that are read and used at runtime

Mitigation

Researcher: Accurately document runtime behavior and maintain traces for later analysis

Developer: If you use VM, keep internal logs for your team to help you troubleshoot


@reverseengine

بخش هفتم بافر اورفلو

یافتن آفست دقیق بین ابتدای بافر و saved return address و دیدن قبل و بعد strcpy با الگوی غیر تکراری

فایل تولید الگو توضیح
این فایل یک الگوی غیر تکراری تولید میکنه تا با مقدار برگشتی که روی استک میبینیم بتونیم آفست رو حساب کنیم

فایل file4_pattern.py

#!/usr/bin/env python3
# simple cyclic pattern generator
import sys
alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
nums = "abcdefghijklmnopqrstuvwxyz"
digits = "0123456789"
def pattern(n):
out = []
for a in alpha:
for b in nums:
for c in digits:
out.append(a+b+c)
if len("".join(out)) >= n:
return "".join(out)[:n]
return "".join(out)[:n]

if name == "main":
n = int(sys.argv[1]) if len(sys.argv)>1 else 200
print(pattern(n))

دستورات اجرا برای یافتن آفست و دیدن قبل و بعد strcpy
تولید الگو و اجرای فایل با الگو به عنوان ورودی

python3 file4_pattern.py 200 > pat.tx

t
gcc -g file4.c -o fil

e4
gdb --args ./file4 $(cat pat.txt)

# در gdb

break crash
run
x/32x $rbp-32 # strcpy قبل از
next # strcpy اجرای کامل
x/32x $rbp-32 # strcpy بعد از
continue # تا کرش اگر لازمه


پیدا کردن مقدار overwrite شده توضیح
بعد از کرش یا بعد از دیدن در gdb مقدار 8 بایتی که در محل return address افتاده رو بردارید و به صورت رشته hex بخونید

مثال دستور داخل gdb برای دیدن 8 بایت در محل return address

x/gx $rbp+8

توضیح فایل محاسبه آفست
این فایل یک تابع ساده برای پیدا کردن موقعیت یک رشته کوچیک داخل الگوی تولید شده میسازه

فایل file4_find_offset.py

#!/usr/bin/env python3
import sys
from file4_pattern import pattern

def find(sub, total=200):
p = pattern(total)
idx = p.find(sub)
return idx

if name == "main":
# ورودی sub به صورت بایت hex یا رشته باید به درستی فرمت شود
sub = sys.argv[1]
# اگر hex داده شد تبدیل کن
if sub.startswith("0x"):
raw = bytes.fromhex(sub[2:])
sub = raw.decode('latin-1')
print(find(sub, int(sys.argv[2]) if len(sys.argv)>2 else 200))

Part 7 Buffer Overflow

Finding the exact offset between the beginning of the buffer and the saved return address and seeing before and after strcpy with a non-repeating pattern

Pattern generation file Explanation
This file generates a non-repeating pattern so that we can calculate the offset with the return value we see on the stack

File file4_patte run.py

#!/usr/bin/env python3
# simple cyclic pattern generator
import sys
alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
nums = "abcdefghijklmnopqrstuvwxyz"
digits = "0123456789"
def pattern(n):
out = []
for a in alpha:
for b in nums:
for c in digits:
out.append(a+b+c)
if len("".join(out)) >= n:
return "".join(out)[:n]
return "".join(out)[:n]

if name == "main":
n = int(sys.argv[1]) if len(sys.argv)>1 else 200
print(pattern(n))

Execution commands to find offset and see before and after strcpy
Generate pattern and execute file with pattern as input

python3 file4_pattern.py 200 >pat.txt
gcc -g file4.
c -o file4
gdb --args ./file4 $(cat pat.txt)

# in gdb

break crash

run

x/32x $rbp-32 # strcpy before

next # strcpy complete execution

x/32x $rbp-32 # strcpy after

continue # until crash if necessary

Finding overwritten value Explanation
After crash or after seeing in gdb, take the 8 bytes that are in the return address and write them as Read hex string

Example of gdb command to see 8 bytes at

return address

x/gx $rbp+8

File denoscription Calculate offset

This file creates a simple function to find the position of a small string within the generated pattern

File file4_find_offset.py

#!/usr/bin/env python3
import sys
from file4_pattern import pattern

def find(sub, total=200):
p = pattern(total)
idx = p.find(sub)
return idx

if name == "main":
# Sub input as hex bytes or string must be formatted properly
sub = sys.argv[1]
# Convert if given hex
if sub.startswith("0x"):
raw = bytes.fromhex(sub[2:])
sub = raw.decode('latin-1')
print(find(sub, int(sys.argv[2]) if len(sys.argv)>2 else 200))

@reverseengine

Kernel Reverse Engineering Syscalls Drivers Kernel Debugging


تحلیل کد سطح کرنل یعنی کار با درایورها و syscall ها ابزار ها روش ها متفاوت و خطرناکن بنابر این باید فقط برای درک و دفاع انجام بشه نه سو استفاده

مثال:
با یک درایور نمونه open-source کار کن: build کن داخل VM نصب کنید و با WinDbg یا kgdb دیباگ کنید تا ببینید syscall چطور پارامترها رو میگذرونه تمرکز روی فهم API و کنترل‌ فلو نه ایجاد exploit

دیتکشن

درایور های unsigned یا درایور هایی که اقدام به رجیستر کردن syscall های جدید میکنن

رفتار های غیر عادی مثل تغییر مستقیم ساختار های کرنل یا نصب hook های غیر معمول


میتیگیشن

محدود کردن نصب درایورهای ناشناس (signature enforcement) استفاده از HVCI/Kernel Patch Protection

مانیتورینگ تغییرات کرنل و هشدار به‌ موقع مشاهده ماژول/درایور جدید یا نوشتن در مناطق حساس

Kernel Reverse Engineering Syscalls Drivers Kernel Debugging

Kernel-level code analysis means working with drivers and syscalls. Tools and methods are different and dangerous, so it should only be done for understanding and defense, not for exploitation.

Example:
Work with an open-source sample driver: build it, install it inside a VM, and debug it with WinDbg or kgdb to see how the syscall passes parameters. Focus on understanding the API and control flow, not creating exploits.

Detection

Unsigned drivers or drivers that attempt to register new syscalls.

Anomalies such as directly modifying kernel structures or installing unusual hooks.

Mitigation

Restricting installation of unknown drivers (signature enforcement). Use HVCI/Kernel Patch Protection.

Monitoring kernel changes and alerting when new modules/drivers are detected or written to sensitive areas

@reverseengine

ARM64 Reversing and Exploitation Part 2 Use After Free | 8kSec Blogs


https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free

@reverseengine