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

One Byte to rule them all - The new iOS kernel exploitation technique that turns a one-byte controlled heap overflow directly into a read/write primitive

https://googleprojectzero.blogspot.com/2020/07/one-byte-to-rule-them-all.html

@reverseengine

با عرض سلام خوش اومدین به هفته 80 از تحلیل CVE ها با برنامه GO-TO CVE این هفته به برسی اسیب پذیری جالبی رو لاراول ورژن 8 تا 11 میپردازیم


🔹CVE : CVE‑2024‑29291
🔹Target: Laravel Framework (Versions 8 – 11)
🔹Type: Credential Exposure / Configuration Analysis (CA)
🔹week : 80


#week_80

Pointer Arithmetic

مهمترین نکته برای Exploit:

a + i
آدرس a + i * sizeof(type)

پس:

double arr[10];

و:

arr + 1

یعنی:

arr + (1 * 8)

نه 1 بایت 8 بایت

همین موضوع برای باگ‌ های زیر مهمه:

Out-of-bounds read/write

Heap corruption

InfoLeak

Pointer Arithmetic

The most important thing for Exploit:

a + i Address a + i * sizeof(type)

So:

double arr[10];

And:

arr + 1

That is:

arr + (1 * 8)

Not 1 byte, 8 bytes

The same thing is important for the following bugs:

Out-of-bounds read/write

Heap corruption

InfoLeak

@reverseengine

Registry Artifact

رجیستری مثل دفترچه‌ی خاطرات ویندوزه
هر برنامه‌ ای یه چیزی توش مینویسه:


مسیر آخرین فایل‌هایی که باز کردید

برنامه‌هایی که اجرا شدن

مسیرهای Run و RunOnce

MRU (Most Recently Used)

کلیدهای موقتی

Component COM Object

Service و Driver
هایی که ساخته شدن


AppCompat / Shim Cache


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



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

Run / RunOnce / Startup Items

اگر برنامه‌ ای رو یه بار فقط تست کنید این مسیرها رو پیدا میکنه لاگش میمونه


AppCompatCache / ShimCache

فقط با اجرا شدن برنامه پر میشه حتی اگه هیچکاری نکرده باشید


MUICache

نرم‌افزار اجرا بشه اسمش اینجا ذخیره میشه

UserAssist


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

RecentDocs

هر فایلی که باز شده باشه اینجا لیست میشه


TypedPaths / OpenSavePidlMRU

وقتی از File Explorer یا Run استفاده بشه اثرش هست

Services / Drivers Keys

اگر برنامه‌ای سرویسی بالا بیاره یا تغییر بده ردپا طولانی مدت میمونه

COM Registration

گاهی ابزارا برای کارکردشون COM Object موقتی میسازن



چجوری کمترشون کنید؟

بدونید که اجرای هر فایل = چند رجیستری جدید

خیلیا فکر نمی‌کنن که حتی run کردن یه exe خالی
AppCompatCache
رو آلوده میکنه


برنامه‌ تون رو طوری طراحی کنید که احتیاج به نوشتن رجیستری نداشته باشه

اگه فقط read-only باشه ردپای کمتری داره

مسیر های پیشبینی‌ نشده استفاده نکنید

مثلاً ساختن key تو HKLM بدون نیاز
حتی از دور معلومه

Temporary Keys

اگه لازم شد کلیدی ساخته بشه
طراحی درست برنامه باید باعث حذف خودکارش بشه

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

COM بیشترین ردپای طولانی‌ مدت رو داره







Registry Artifact

The registry is like a Windows diary

Every program writes something in it:

Paths of the last files you opened

Programs that were run

Run and RunOnce paths

MRU (Most Recently Used)

Temporary keys

Component COM Object

Service and Driver

That were created

AppCompat / Shim Cache

Most of them are not deleted even by deleting the executable file

The most important registry traces that are usually left

Run / RunOnce / Startup Items

If you test a program only once, it will find these paths and log it

AppCompatCache / ShimCache

It is only filled when the program is run, even if you have not done anything

MUICache

When the software is run, its name is stored here

UserAssist

List of user activities with counters

RecentDocs

Every file that has been opened is listed here

TypedPaths / OpenSavePidlMRU

It works when using File Explorer or Run

Services / Drivers Keys

If a program starts or changes a service, it leaves a long-term footprint

COM Registration

Sometimes tools create temporary COM Objects for their work

How to reduce them?

Know that executing each file = several new registries

Many don't think that even running an empty exe pollutes the

AppCompatCache

Design your program so that it doesn't need to write to the registry

If it's read-only, it has a smaller footprint

Don't use unexpected paths

For example, creating a key in HKLM without need

It's obvious even from afar

Temporary Keys

If a key needs to be created

A properly designed program should automatically delete it

Don't work with COM unless you have to

COM has the most long-term footprint

@reverseengine

کنترل واقعی EIP / RIP

لحظه‌ای که مطمئن میشید CPU دقیقا همون کاری رو میکنه که شما میخواید

تا اینجا:

برنامه رو کرش دادید

Offset
دقیق رو پیدا کردید


کنترل EIP/RIP یعنی چی؟

یعنی بتونید تعیین کنی CPU بعدش کجا رو اجرا کنه

اگه بتونی مقدار EIP روی 32 بیت یا RIP روی 64 بیت رو خودتون پر کنید یعنی کنترل جریان اجرا افتاده دست شما


  کنترل ساده

فرض کنی  Offset = 524 بود

یه payload ساده میسازیم:

"A" * 524 + "BBBB"

یا به شکل هگز:

0x42424242

حالا این ورودی رو به برنامه میدید


اگه همه چیز درست باشه توی debugger میبینید:

EIP = 0x42424242 (32 بیت)

یا RIP شامل همون مقدار روی 64 بیت


اگه کارایی که کردید درست بود

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




چند حالت وجود داره:

برنامه قبلش کرش میکنه

احتمالاً:

Offset اشتباهه

یا یه چک امنیتی قبل از رسیدن به RIP فعال میشه


مقدار RIP تغییر نکرد

یعنی:

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

یا overflow روی یه بافر دیگه اتفاق افتاده


فقط کرش بدون کنترل

یعنی کرش دارید ولی کنترل ندارید
این فرق داره با exploit واقعی


تفاوت 32 بیت و 64 بیت اینجا مشخص میشه

روی 32 بیت:

EIP
مستقیم با 4 بایت پر میشه

کنترل گرفتن خیلی واضح تره


روی 64 بیت:

RIP
معمولا کامل overwrite نمیشه


باید با stack alignment RSP و sometimes partial overwrite کار کنید


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



چرا اینا مهمن:

میتونید بپرید به:

شل‌کد

تابع system

gadget
های ROP



یا حتی فقط اجرای یه تابع ساده رو تست کنید


ولی بدون کنترل RIP/EIP هیچکدوم معنی نداره


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

این فرق بین کرش ساده و اکسپلویت واقعیه



Real EIP/RIP Control

The moment you make sure the CPU is doing exactly what you want

So far:

You crashed the program

You found the exact offset

What is EIP/RIP control?

That is, you can determine where the CPU will execute next

If you can fill in the value of EIP on 32 bits or RIP on 64 bits yourself, that means you have control over the execution flow

Simple control

Let's assume Offset = 524

We create a simple payload:

"A" * 524 + "BBBB"

Or in hex:

0x42424242

Now you will see this input to the program

If everything is correct, you will see in the debugger:

EIP = 0x42424242 (32 bits)

Or RIP contains the same value on 64 bits

If what you did was correct

You have taken control of EIP/RIP

There are several cases:

The program crashes before

Probably:

The offset is wrong

Or a security check is activated before reaching RIP

The RIP value has not changed

That is:

The data You didn't reach that register

Or an overflow occurred on another buffer

Just an uncontrolled crash

That means you have a crash but no control

This is different from a real exploit

The difference between 32-bit and 64-bit is clear here

On 32-bit:

EIP
is filled directly with 4 bytes

Taking control is much clearer

On 64-bit:

RIP
usually cannot be completely overwritten

You have to work with stack alignment RSP and sometimes partial overwrite

Here is where exploit writing gets more serious

Why these are important:

You can jump to:

Shellcode

System function

ROP gadgets

Or even just test the execution of a simple function

But without RIP/EIP control, none of that makes sense

Finding Offset is not enough, you have to prove that you can actually set the EIP or RIP value yourself. When you see the value you want sitting in RIP, you have full control over the CPU Taken

This is the difference between a simple crash and a real exploit

@reverseengine