کنترل واقعی 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

Process Injection using DInvoke

https://rastamouse.me/blog/process-injection-dinvoke

@reverseengine

WEIZZ: Automatic Grey-Box Fuzzing for Structured Binary Formats

Slides: https://andreafioraldi.github.io/assets/weizz-issta2020-slides.pdf

Video: https://www.youtube.com/watch?v=MOeUqlFtgwE

Article: https://andreafioraldi.github.io/assets/weizz-issta2020.pdf

Code: https://github.com/andreafioraldi/weizz-fuzzer

@reverseengine

Breaking the BeeStation: Inside Our Pwn2Own 2025 Exploit Journey

https://www.synacktiv.com/en/publications/breaking-the-beestation-inside-our-pwn2own-2025-exploit-journey

@reverseengine

Exploiting an Envoy heap vulnerability

https://blog.envoyproxy.io/exploiting-an-envoy-heap-vulnerability-96173d41792

@reverseengine