بعد از کنترل RIP چی کار میکنیم؟

پرش به کد خودمون

تا اینجا:

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

Offset دقیق داریم

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


سوال مهم الان اینه:

حالا RIP رو کنترل کردیم باید بذاریمش کجا؟



اینجا دو مسیر اصلی داریم




مسیر کلاسیک: اجرای کد خودمون Shellcode

ایده:

یه تیکه کد اسمبلی مینویسید

داخل ورودی برنامه تزریقش میکنید

RIP رو میپرونید روی همون کد


به این کد میگن Shellcode

مشکل کجاست؟

روی سیستم‌های قدیمی این روش خیلی راحت جواب میداد اما سیستم‌های جدید یه سد بزرگ دارن به اسم:

NX Non-Executable Memory


یعنی:

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

CPU اجازه اجرای کد از اونجا رو نمیده


پس حتی اگه RIP رو بفرستید روی استک برنامه کرش میکنه نه اینکه کدتون اجرا بشه


What do we do after controlling RIP?

Jump to our own code

So far:

The program has crashed

We have the exact offset

We also got the RIP / EIP control

The important question now is:

Now that we have controlled RIP, where should we put it?

Here we have two main paths

Classic path: Execute our own code Shellcode

The idea:

You write a piece of assembly code

You inject it into the program input

You run RIP on that code

This code is called Shellcode

Where is the problem?

On old systems, this method worked very easily, but new systems have a big barrier called:

NX Non-Executable Memory

That is:

The stack and heap are only for data

The CPU does not allow executing code from there

So even if you send RIP on the stack, the program will crash, not your code will be executed

@reverseengine

Stack Frames Advanced

ضروری‌ترین بخش برای Exploit + ROP

هدف:

کامپایلر دقیقا چه چیزهایی رو داخل استک ذخیره میکنه

Saved RBP


Return Address


Local Variables

Padding / Alignment


Call-preserved registers

متغیر های محلی چجوری روی استک قرار میگیرن؟

کد C:

int func(int x) {
int a = 5;
int b = x + 3;
return a + b;
}

کامپایل با -O0:

push rbp
mov rbp, rsp
sub rsp, 16 ; allocate space for a, b
mov DWORD PTR [rbp-4], 5
mov eax, DWORD PTR [rbp+16] ; x
add eax, 3
mov DWORD PTR [rbp-8], eax
mov eax, DWORD PTR [rbp-4]
add eax, DWORD PTR [rbp-8]
leave
ret

نکته مهم برای اکسپلویت:

لوکال‌ها همیشه از آدرس‌های:

rbp - 4

rbp - 8

rbp - 0x10




شروع میشن

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




Stack Frames Advanced

The most essential part for Exploit + ROP

Objective:

What exactly does the compiler store on the stack

Saved RBP

Return Address

Local Variables

Padding / Alignment

Call-preserved registers

How are local variables placed on the stack?

C code:

int func(int x) {

int a = 5;

int b = x + 3;

return a + b;
}

Compile with -O0:

push rbp
mov rbp, rsp
sub rsp, 16 ; allocate space for a, b
mov DWORD PTR [rbp-4], 5
mov eax, DWORD PTR [rbp+16] ; x
add eax, 3
mov DWORD PTR [rbp-8], eax
mov eax, DWORD PTR [rbp-4]
add eax, DWORD PTR [rbp-8]
leave
ret

Important note for exploit:

Locals always start at:

rbp - 4

rbp - 8

rbp - 0x10



This is exactly where the buffer overflow occurs

@reverseengine

.NET – 7 Decompiler Compared 2025

https://blog.ndepend.com/in-the-jungle-of-net-decompilers

@reverseengine

The FLARE team's open-source tool to identify capabilities in executable files

https://github.com/fireeye/capa

@reverseengine

Tools to process ARM's Machine Readable Architecture Specification

https://github.com/alastairreid/mra_tools

@reverseengine

WinDbg Basics for Malware Analysis

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

@reverseengine

🎯 Week 81 — CVE‑2025‑55184 / CVE‑2025‑67779 — React Server Components — Denial of Service

🔹 Week: 81
🔹 CVE: CVE‑2025‑55184 & CVE‑2025‑67779
🔹 Type: Denial of Service (Infinite Loop during deserialization of malicious HTTP requests)
🔹 Impact: Server hang and 100% CPU consumption via a single malicious request to any Server Function endpoint, leading to complete service denial.
🔹 Fixed in: React v19.0.3, v19.1.4, v19.2.3 (and corresponding react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack packages)
🔹 Action: Upgrade affected packages immediately. Note: Only applications using React Server Components are vulnerable.

#week_81

این یک شوخیه، ناراحت نشید، رفقا 😂🩶

This is a joke, don't be upset, buddies 😂🤍

Reverse Engineering and Patching IoT with Ghidra

Part 1:
https://www.coalfire.com/The-Coalfire-Blog/April-2020/With-IoT-Common-Devices-Pose-New-Threats

Part 2:
https://www.coalfire.com/The-Coalfire-Blog/April-2020/Reverse-Engineering-and-Patching-with-Ghidra

@reverseengine

Intezer Analyze Ghidra Plugin

https://github.com/intezer/analyze-community-ghidra-plugin

@reverseengine

Weaponizing Windows Syscalls as Modern, 32-bit Shellcode (DEF CON 30)

@reverseengine

Attacking the IPsec Standards in Encryption-only Configurations

https://eprint.iacr.org/2007/125.pdf

@reverseengine

Malicious-PixelCode

@reverseengine

Malicious PixelCode Delivery Technique

https://github.com/S3N4T0R-0X0/Malicious-PixelCode

@reverseengine

Windows Kernel Exploitation Fundamentals

@reverseengine

UEFI scanner brings Microsoft Defender ATP protection to a new level

https://www.microsoft.com/security/blog/2020/06/17/uefi-scanner-brings-microsoft-defender-atp-protection-to-a-new-level

@reverseengine

OSX.EvilQuest Uncovered analyzing a new piece of mac ransomware and more!

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

@reverseengine

efiSeek for Ghidra

https://github.com/DSecurity/efiSeek

@reverseengine

How to unc0ver a 0-day in 4 hours or less

https://googleprojectzero.blogspot.com/2020/07/how-to-unc0ver-0-day-in-4-hours-or-less.html

@reverseengine