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

Set of antianalysis techniques found in malware

https://github.com/hasherezade/antianalysis_demos

@reverseengine

Binary instrumentation framework based on FRIDA

https://github.com/Ch0pin/medusa

@reverseengine

Python noscripts to help analzye go binaries in radare2. Basically this is a port of the IDA pro noscript golang_load_assist to r2

https://github.com/f0rki/r2-go-helpers

@reverseengine

Low-Level Process Hunting on macOS

https://objective-see.com/blog/blog_0x4A.html

@reverseengine

JVM Reverse Engineering

https://medium.com/@Oscar404/jvm-reverse-engineering-99a12fd59eeb

@reverseengine

Reverse-Engineering Android APKs with JADX

https://blog1.neuralengineer.org/reverse-engineering-android-apks-with-jadx-ebded67ceb8f

@reverseengine

Decoding Brickstorms Garble strings

https://medium.com/walmartglobaltech/decoding-brickstorms-garble-strings-b0a60828b3cc

@reverseengine

How to Reverse-Engineer (with AI) an old Demoscene Exe

https://medium.com/@kevin.drapel/how-to-reverse-engineer-with-ai-an-old-demoscene-exe-part-1-07e22e48b0c2

@reverseengine

Reverse engineering of a crypto stealer

https://medium.com/@beardr3d/reverse-engineering-of-a-crypto-stealer-e768f0c20853

@reverseengine

LazyHook is a stealthy API hooking framework that bypasses Host Intrusion Prevention Systems (HIPS) through call stack spoofing. By leveraging CPU-level hardware breakpoints and Vectored Exception Handling, it executes arbitrary code as if it originated from trusted, Microsoft-signed modules—completely fooling behavioral analysis engines that rely on call stack inspection and module origin verification.

Evade behavioral analysis by executing malicious code within trusted Microsoft call stacks
Uses hardware breakpoints + VEH to hijack legitimate functions and spoof module origins

│ 1. Target Function Call
│ ↓
│ 2. CPU Debug Register Triggers (DR0-DR3) │
│ ↓
│ 3. EXCEPTION_SINGLE_STEP Raised │
│ ↓
│ 4. VEH Handler Intercepts Exception │
│ ↓
│ 5. Execution Redirected to Hook Function │
│ ↓
│ 6. CallOriginal() Temporarily Disables Breakpoint
│ ↓
│ 7. Original Function Executes │
│ ↓
│ 8. Breakpoint Re-enabled

#callstackspoofing #edr

X86-64 Assembly Language Programming with Ubuntu

@reverseengine

Linux rootkits explained

https://www.wiz.io/blog/linux-rootkits-explained-part-1-dynamic-linker-hijacking

@reverseengine

Singularity - Stealthy Linux Kernel Rootkit

https://blog.kyntra.io/Singularity-A-final-boss-linux-kernel-rootkit

https://github.com/MatheuZSecurity/Singularity?tab=readme-ov-file#installation

Piercing the Veil: Android Code Deobfuscation

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

@reverseengine

Updates on ThiefQuest, the Quickly-Evolving macOS Malware

https://blog.trendmicro.com/trendlabs-security-intelligence/updates-on-thiefquest-the-quickly-evolving-macos-malware

@reverseengine

Split 64 bits sep-firmware images

https://github.com/matteyeux/pysep

@reverseengine