Interactive Visualization

Buffer Overflow

Watch how writing past the bounds of a buffer corrupts adjacent memory, overwrites the return address, and hijacks execution flow.

Normal operation. No overflow detected. Buffer is within bounds.
Current Scenario
A vulnerable C function calls gets(buffer) with a 16-byte buffer on the stack. The stack contains local variables, the saved frame pointer, and the return address. Input that fits within 16 bytes is safe; anything longer overwrites adjacent memory.
Stack Memory (grows downward)
Execution Log
[INIT] Program loaded. Stack frame allocated.
[INIT] Buffer: 16 bytes at 0xBFFF0010
[INIT] Return address: 0x08048456 (main+42)
Stack Layout Explained

Buffer (16 bytes) — Space allocated for user input.

Guard variable — Local variable that can be corrupted.

Saved EBP — Previous frame pointer.

Return Address — Where execution jumps when function returns. The attacker's target.

How buffer overflows work

A buffer overflow occurs when a program writes more data to a buffer than it can hold. Because the stack stores local variables, saved registers, and return addresses in adjacent memory, overflowing a buffer can overwrite these critical values.

In a classic stack-based overflow, the attacker crafts input that is just long enough to reach the return address, then overwrites it with the address of their malicious code (shellcode). When the vulnerable function returns, instead of jumping back to the caller, execution jumps to the attacker's code.

The key vulnerability is using unsafe functions like gets(), strcpy(), or sprintf() that don't check input length. Modern defenses include stack canaries, ASLR (Address Space Layout Randomization), DEP/NX (non-executable stack), and using safe alternatives like fgets() and strncpy().

In the visualization above, notice how the "safe" input stays within the buffer boundary, while the overflow attack writes past it, corrupting the guard variable, saved frame pointer, and ultimately the return address — giving the attacker control of the program's execution.