گرفتن Offset و کنترل‌ کردن EIP/RIP

جایی که میفهمید واقعا میتونید برنامه رو هک کنید یا نه

وقتی فهمیدید برنامه چطوری کرش میکنه قدم بعد اینه که مشخص کنید ورودی شما دقیقا کجای استک یا رجیستر ها میشینه
این یعنی باید بفهمید دقیقا کدوم کاراکتر از ورودی باعث شده EIP/RIP یا جریان اجرای برنامه از دست بره

به این میگن Offset

Offset یعنی چی؟

مفهومش ساده‌ست:

چندتا کاراکتر از شروع ورودی لازم دارید تا برسید به نقطه‌ای که برنامه کرش میکنه؟

مثلاً اگه با 2000 تا A برنامه خراب شد و توی EIP شده 0x41414141 خب میفهمید A اثر کرده

ولی اینکه کدوم A؟
کدوم کاراکتر دقیقا روی EIP نشسته؟

اینجاست که Offset معنی پیدا میکنه




فاز گرفتن Fuzzing ساده

اول یه ورودی بلند به برنامه میدید چیزی مثل:

python -c "print('A' * 5000)"

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

مثلا:

RIP = 0x41414141 عالیه

RIP شده یه چیز رندوم باز هم قابل بررسیه


اصلا ورودی ما اثری نذاشته پس بافر مربوطه جای دیگه‌ ست


وقتی مطمئن شدیم داده‌ ی ما وارد مسیر برنامه شده میریم مرحله بعد




ساخت Pattern یکتا الگو تصادفی

برای اینکه بفهمیم کدوم قسمت دقیقا روی EIP/RIP نشسته از یه الگوی یکتا استفاده میکنیم نه AAAAA….

ابزار هایی مثل:

msf-pattern_create

gef pattern create

pwndbg pattern create

یک رشته مثلا 3000 کاراکتری میسازن که هیچ بخشش شبیه بخش دیگه نیست

چیزی شبیه:

Aa0Aa1Aa2Aa3Bb0Bb1Bb2...

این رشته رو میفرستید به برنامه برنامه خراب میشه حالا EIP/RIP رو نگاه میکنید

فرض کند توی RIP دیدید:

0x39654138

حالا باید ببینید این بخش از الگو دقیقا چندمین بایت بود؟




پیدا کردن Offset

از ابزار پیدا کردن offset استفاده میکنیم

msf-pattern_offset -q 39654138

یا داخل gdb/gef:

pattern offset 0x39654138

بهتون میگه مثلا:

"Offset = 524"



یعنی کاراکتر شماره 524 از ورودی دقیقا روی EIP/RIP نشسته

و این دقیقا پایه همه‌ ی کارهای بعدیه




چرا مهمه؟
وقتی Offset رو دارید یعنی:

میتونید با ورودیتون مستقیما روی جریان اجرای برنامه بشینید

بعد

از 0 تا Offset هرچی میخواید پد میذارید

از Offset به بعد آدرس‌ها یا ROP chain یا شل‌کدتون رو قرار میدید


از این لحظه به بعد کنترل با شمائه نه با برنامه


بعد از تحلیل کرش باید بفهمید دقیقا چند بایت طول میکشه تا ورودیتون برسه به جایی مثل EIP یا RIP این کار با ساختن یه الگو یکتا و پیدا کردن Offset انجام میشه
وقتی Offset رو پیدا کنید یعنی حتما تونستید جریان اجرای برنامه رو در اختیار بگیرید و این نقطه شروع اکسپلویت‌نویسیه





Getting Offset and Controlling EIP/RIP

Where you can really hack your program

Once you understand how your program crashes, the next step is to determine exactly where your input sits on the stack or registers

This means you need to figure out exactly which character of the input caused the EIP/RIP or program execution flow to be lost

This is called Offset

What does Offset mean?

The concept is simple:

How many characters from the start of the input do you need to get to the point where the program crashes?

For example, if the program crashes with 2000 A and the EIP is 0x41414141, then you know that A has taken effect

But which A?

Which character exactly sits on the EIP?

This is where Offset comes into play

Simple Fuzzing

First, you would see a long input to the program, something like:

python -c "print('A' * 5000)"

The goal is to create a crash and see if your input has entered the registers or not

For example:

RIP = 0x41414141 is great

RIP is a random thing that can still be checked

Our input has not left any trace at all, so the corresponding buffer is somewhere else

Once we are sure that our data has entered the program path, we move on to the next step

Create a unique random pattern

To find out which part exactly sits on EIP/RIP, we use a unique pattern, not AAAAA….

Tools like:

msf-pattern_create

gef pattern create

pwndbg pattern create

They create a string of, say, 3000 characters, where no part is the same as another

Something like:

Aa0Aa1Aa2Aa3Bb0Bb1Bb2...

You send this string to the program, the program crashes, now you look at EIP/RIP

Suppose you saw in RIP:

0x39654138

Now you need to see exactly what byte this part of the pattern was?

Finding Offset

We use the offset finder tool

msf-pattern_offset -q 39654138

or in gdb/gef:

pattern offset 0x39654138

It tells you something like:

"Offset = 524"

That means character number 524 from the input is exactly on the EIP/RIP

And this is exactly the basis for all the following work

Why is it important?
When you have the Offset, it means:

You can sit directly on the program execution flow with your input

Then

You pad anything you want from 0 to Offset

From Offset onwards, you put the addresses or ROP chain or your shellcode

From this point on, you are in control, not the program

After analyzing the crash, you need to figure out exactly how many bytes it takes for your input to reach somewhere like EIP or RIP. This is done by creating a unique pattern and finding the Offset

When you find the Offset, it means you have definitely been able to take control of the program execution flow and this is the starting point for exploit writing

@reverseengine

RustHound-CE 2.4.5

https://github.com/g0h4n/RustHound-CE

ابزار جمع‌آوری BloodHound که به زبان Rust نوشته شده و قابلیت کامپایل متقابل داره با لینوکس، ویندوز و macOS سازگاره پس تمام فایل‌های JSON قابل تجزیه و تحلیل توسط BloodHound Community Edition رو تولید میکنه

دستورالعمل‌ ها:

نصب از cargo

cargo install rusthound-ce

دستورالعمل‌ ها:

rusthound-ce -i 192.168.1.10 -d domain.local -u user@domain.local -p 'pass' -z

RustHound-CE 2.4.5

https://github.com/g0h4n/RustHound-CE

The BloodHound collection tool, written in Rust and cross-compiled, is compatible with Linux, Windows, and macOS. Therefore, it produces all JSON files that can be parsed by BloodHound Community Edition.

Instructions:

install from cargo

cargo install rusthound-ce

Instructions:

rusthound-ce -i 192.168.1.10 -d domain.local -u user@domain.local -p 'pass' -z

@reverseengine

Brickstorm Backdoor

https://www.cisa.gov/sites/default/files/2025-12/malware-analysis-report-brickstorm-backdoor.pdf

@reverseengine

UAFuzz: Binary-level Directed Fuzzing for Use-After-Free Vulnerabilities

https://github.com/strongcourage/uafuzz

@reverseengine

Linux Kernel Runtime Guard

https://github.com/openwall/lkrg

@reverseengine

IDA Pro Tips to Add to Your Bag of Tricks

https://swarm.ptsecurity.com/ida-pro-tips

@reverseengine

Fuzzing the Windows API for AV Evasion

https://winternl.com/fuzzing-the-windows-api-for-av-evasion

@reverseengine

Attack Secure Boot of SEP

https://github.com/windknown/presentations/raw/master/Attack_Secure_Boot_of_SEP.pdf

@reverseengine

Reverse-engineering and analysis of SanDisk High Endurance microSDXC card

https://ripitapart.com/2020/07/16/reverse-engineering-and-analysis-of-sandisk-high-endurance-microsdxc-card

@reverseengine

ASM Visualizer

https://asm.diveintosystems.org

@reverseengine

From Support Ticket to Zero Day

https://horizon3.ai/attack-research/attack-blogs/from-support-ticket-to-zero-day

@reverseengine

Article: Removing Kernel Callbacks Using Signed Drivers
https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers

Code: Enumerating and removing kernel callbacks using signed vulnerable drivers
https://github.com/br-sn/CheekyBlinder

@reverseengine

Reverse Engineering Starling Bank (Part I): Obfuscation Techniques https://hot3eed.github.io/2020/07/30/starling_p1_obfuscations.html

Reverse Engineering Starling Bank (Part II): Jailbreak & Debugger Detection, Weaknesses & Mitigations
https://hot3eed.github.io/2020/08/02/starling_p2_detections_mitigations.html

@reverseengine

A gentle introduction into ARM assembly

https://www.shadowinfosec.io/2018/05/a-gentle-introduction-into-arm-assembly.html

@reverseengine

Memory Layout: Arrays, Structs, Pointers

مهمترین بخش برای Exploit, InfoLeak، ROP، UAF، heap overflow



آرایه‌ها (Arrays) داخل حافظه چگونه ذخیره میشن؟

آرایه همیشه contiguous پشت سر هم داخل استک یا هیپ ذخیره میشه

مثال:

int a[5] = {1,2,3,4,5};

داخل حافظه:

a[0] → offset 0
a[1] → offset 4
a[2] → offset 8
a[3] → offset 12
a[4] → offset 16

نکته Exploit:

اگر بافر آرایه باشه اورفلو مستقیم وارد متغیر های محلی RBP Return Address میشه





Memory Layout: Arrays, Structs, Pointers

The most important part for Exploit, InfoLeak, ROP, UAF, heap overflow

How are Arrays stored in memory?

Arrays are always stored contiguously in the stack or heap

Example:

int a[5] = {1,2,3,4,5};

In memory:

a[0] → offset 0
a[1] → offset 4
a[2] → offset 8
a[3] → offset 12
a[4] → offset 16


Exploit Tip:

If the buffer is an array, the overflow goes directly into the local variables RBP Return Address

@reverseengine

پاکسازی ردپای سیستم‌ فایلی FileSystem Artifacts

FileSystem Artifact

هرچی میسازید باز میکنید Extract میکنید حتی فقط لمس میکنید روی NTFS یه اثر میذاره
ردپای سیستم فایل دقیقا همین اثرات رو داره:

MFT Records

USN Journal

Zone.Identifier

ADS Alternate Data Streams

Prefetch

Recent Files

Jump Lists

ShellBags

Thumbnails

یعنی حتی اگه فایلتوتو پاک کنید باز از این طرف و اون طرف لو میرید


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

MFT Entries

هر فایلی که ساخته کپی Extract بشه
تو Master File Table رکوردش میمونه

USN Journal

تقریبا قابل حذف نیست و همه تغییرات فایل رو log می‌نه

Zone.Identifier

وقتی فایلی از اینترنت میاد حتی از ابزار خودتون ویندوز میگه این از اینترنت اومده روش Alternate Data Stream میزاره


گاهی ابزارا config یا متادیتا رو تو ADS ذخیره میکنن

Prefetch

هر فایل اجرایی که اجرا شد یه PF ساخت میشه

Jump Lists Recent Items

وقتی یه فایل باز یا اجرا میشه اینجا لیست میشه

Thumbnail Cache

اگه فایل تصویری باز شده باشه preview ش ذخیره میشه

Temp / Roaming / LocalLow

ابزا را هزار جور اثر ریز تو مسیر های جانبی میذارن


هیچ روش مخربی توضیح نمیدم  فقط اصول حرفه‌ای و پاک



فایلی که نمیخواید اثر بذاره اصلا روی دیسک نسازید

تا میتونید memory-only کار کنید

Extract نکنید مگر مجبور باشید

بیشترین ردپا ها از همینه:

zip → Extract → اجرا → حذف →
پایان

اما ردپاها باقی

Prefetch-aware رفتار کنه

اجرای فایل‌ های با اسم random، Prefetch لو بره سناریو های قانون باید بدونید چیزی که اجرا میکنید اثر long-term میذاره

Zone.Identifier رو چک کنید

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

Temp رو حواست باشه

کلی ابزار خودشون فایل temp درست میکنن بدون اینکه شما بفهمید

تغییرات جانبی مثل Thumbnail و JumpList رو پیشبینی کنید

چیزی که Preview میزنید یا Open میکنید احتمالا Thumbnail میسازه





File System Artifacts Cleanup

FileSystem Artifact

Everything you create, open, extract, even just touch leaves an impact on NTFS

File system footprints have exactly the same effects:

MFT Records

USN Journal

Zone.Identifier

ADS Alternate Data Streams

Prefetch

Recent Files

Jump Lists

ShellBags

Thumbnails

That is, even if you delete your file, it will still be visible from here and there

The most common footprints that are usually left

MFT Entries

Every file that is created, copied, extracted

Its record is left in the Master File Table

USN Journal

It is almost impossible to delete and does not log all file changes

Zone.Identifier

When a file comes from the Internet, even from your own tool, Windows says that it came from the Internet, it uses the Alternate Data Stream method

Sometimes tools store config or metadata in ADS

Prefetch

Every file  The executable that is run will create a PF

Jump Lists Recent Items

When a file is opened or executed, it will be listed here

Thumbnail Cache

If an image file is opened, its preview will be saved

Temp / Roaming / LocalLow

Tools leave a thousand kinds of small traces in side paths

I will not explain any destructive methods, just professional and clean principles

Do not create a file that you do not want to affect on the disk at all

So that you can work memory-only

Do not extract unless you have to

Most traces are like this:

zip → Extract → Run → Delete →
End

But traces remain

Behave Prefetch-aware

Executing files with random names, Prefetch will be leaked
Legal scenarios, you should know that what you are executing has a long-term effect

Check Zone.Identifier

If you move a file, you should know that Windows even marks the Internet resource

Watch Temp

All tools  They create temp files without you knowing

Anticipate side effects like Thumbnails and JumpLists

Anything you Preview or Open will probably create a Thumbnail

@reverseengine