┌──────────────┐ ← High Addresses
│ Stack │ ← Contains Local Variables, Return Addresses
├──────────────┤

│ Heap │ ← Contains Dynamic Objects (malloc/new)
├────────────────────────────────────

│ BSS & Data │ ← Global/static variables

├───────────────────────┘ ← Lower addresses

Exploits usually occur in the Stack or Heap

🧨 Most important types of bugs in Binary Exploitation

Type of vulnerability:

Buffer Overflow
Writing more data than allowed into the buffer can overwrite the Return Address

Stack-based Overflow Overflow
The stack is usually used to control EIP/RIP

Heap Overflow
Overflow in the heap causes malloc structures to fail

Use-After-Free
Using a pointer after freeing causes control over freed memory

Format String Bug
Unsafe use of printf can cause memory leak or write

Integer Overflow/Underflow
Causes memory allocation or bypass errors Checks are

Double Free
Freeing a pointer twice leads to heap corruption

🧭 General steps of Binary Exploitation:

Create a crash Bug Trigger:

Make the program crash with specific input

For example, overflow the buffer with a very long string

Analyze the bug:

Use gdb, pwndbg, gef, or radare2

Understand what exactly was overwritten, what registers are controllable, and what the execution flow is like

Leak Security Information:

To bypass ASLR or PIE, you need to leak addresses

For example, you use a format string to print pointers

Build Payload Exploit:

For example, build a ROP chain or Shellcode

Carefully change the Return Address to your gadgets or shellcode

Bypass Protections:

Modern browsers and binaries have protections such as:

ASLR
Addresses are randomized, you need to leak

NX / DEP
Stack is not executable, you should use ROP

Canary
Overflow protection should be leaked or bypassed

PIE / RELRO
Hardening GOT/PLT control

Taking ultimate control:

Usually an exploit ends in one of the following:

Executing Shellcode and getting a shell 🐚

Executing ROP chain to execute system commands

Changing program behavior in favor of the attacker

🧰 Important tools in Binary Exploitation

Most used tools:

gdb + pwndbg or gef
Debugging and crash and memory analysis

radare2, Ghidra, IDA Pro
Binary reverse engineering

ROPgadget, ROPPER
Finding ROP gadgets

pwntools
Quickly building exploits with Python

angr, Qiling
Symbolic analysis or advanced emulation

checksec Checking binary protections

🧪 Very simple classic Stack Overflow example

Vulnerable code:

#include <stdio.h>
#include <string.h>

void vuln() {
char buf[64];
gets(buf); // ❌ Insecure
printf("You said: %s\n", buf);
}

int main() {
vuln();
return 0;
}

If you give more than 64 bytes in input, you can overwrite the Return Address and send the program to your shellcode address instead of returning to main


@reverseengine

I made a Flipper Zero BadUSB alternative with an ESP32-S3 to automate my PC https://www.xda-developers.com/made-flipper-zero-badusb-alternative-esp32/

CVE-2025-43300

Poc:
Rce iOS 18.6.10

https://github.com/b1n4r1b01/n-days/blob/main/CVE-2025-43300.md?fbclid=IwZXh0bgNhZW0CMTEAAR4GEIShnUYvwBjuHqzKsE0ZjoimJ4zjWfLEYN3vmc7t6BYAlALJtqLQ630Oaw_aem_fsraRT0BI9kfRhL89TRepw

@reverseengine

Exploiting Retbleed CPU vulnerability by @_MatteoRizzo and @theflow0


https://bughunters.google.com/blog/6243730100977664/exploiting-retbleed-in-the-real-world

Windows X86-64 System Call Table (XP/2003/Vista/7/8/10/11 and Server)

https://j00ru.vexillium.org/syscalls/nt/64/

Part 6 Buffer Overflow

Understanding the Crash and the Structure of the Function Frame on the Stack

In this part, we are going to see what exactly happens behind the scenes when a buffer overflow causes a crash. After this part, we should
understand why overwriting data on the stack changes the return address.
What are the components of a function frame?
And how can these components be viewed and analyzed with gdb.

When a function is called in C, the system creates a space on the stack for that function. We call this space the function frame. Each frame contains these parts.

Local variables of the function

Parameter values

Saved RBP or base pointer
for return

Saved return address
which the function returns to after the function completes

If more data is written to the local buffer than the limit, these important values ​​are overwritten in the frame
And as a result, the program crashes on return or jumps to the wrong address

This code helps us see the function frame and crash and analyze it in gdb

#include <stdio.h>
#include <string.h>

void crash(char *input) {
char buffer[16];
printf("address of buffer: %p\n", buffer);
strcpy(buffer, input);
printf("done copying\n");
}

int main(int argc, char **argv) {
if (argc < 2) {
printf("usage: %s input\n", argv[0]);
return 1;
}
crash(argv[1]);
printf("returned safely\n");
return 0;
}

Execution and analysis commands

gcc -g file4.c -o file4

gdb --args ./file4 $(python3 -c "print('A'*40)")

After running the program in gdb, perform these steps

break crash

run

info frame

x/32x $rbp

x/32x $rsp

Here you can see that the buffer is below the saved RBP

Every byte you write out of the buffer will eventually reach the saved RBP and then the return address

To view the crash

continue

The program crashes with a segmentation fault error

See the return path with the following command

backtrace

And check the last return address with this command

info registers rip

Full explanation

When executing the crash function, the system first saves the current RBP

Then it moves the RSP down to provide the necessary space for local variables

In this new buffer space, Yes
When we write data larger than the buffer size, first the data is written to local variables, then to RBP, and then to the return address
At the moment the function wants to return, the wrong value is read from the stack and RIP jumps to the wrong address, which causes a segmentation fault

Interesting part

You can see the difference before and after the overflow in gdb with this command

Before strcpy
x/32x $rbp-32

After strcpy
x/32x $rbp-32

You can see that the A bytes have filled all the space between the buffer and the return address

This is the reason for the program crash

@reverseengine