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

The core of Apple is PPL (Apple's Page Protection Layer): Breaking the XNU kernel's kernel

https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html

@reverseengine