Lab

Exploit Chain Visualizer

Step-by-step visualization of buffer overflow exploitation with defense mechanisms.

Educational security demonstration

Watch how a stack buffer overflow progresses from vulnerability to code execution, and how modern defenses can stop the attack at each stage.

What this is

A visual walkthrough of how stack buffer overflow exploits work, from the initial vulnerability through control flow hijacking to arbitrary code execution.

What you'll learn

  • How buffer overflows corrupt the stack
  • Why return addresses are valuable targets
  • How defenses like ASLR, DEP, and canaries work

Exploit Chain

Full attack progression from vulnerability discovery to shell access.

Vulnerability

Unbounded copy into stack buffer

Overflow

Write past buffer boundary

Overwrite RIP

Corrupt saved return address

Hijack Control

Function returns to attacker address

Code Execution

Shellcode or ROP chain runs

Stage 0 of 5

Defense Mechanisms

Enable mitigations to see how they block the exploit at different stages.

All defenses off

Current Stage

Waiting to start

Click "Play Chain" to step through a stack buffer overflow exploit, or use "Step" to advance one stage at a time.

Stack Frame

Local vars [ buffer[16] ]
Canary 0xDEADBEEF
Saved RBP 0x7fff1234
Saved RIP 0x401156

Stack grows downward. RIP (return address) is the attacker's target.

Attack Payload / Code

C / Python
// Payload will appear here during exploit chain

Understanding the Attack

Why Stack Overflows Work

In C, functions store local variables and return addresses on the stack. When a buffer is allocated, writing past its boundary corrupts adjacent memory - including the return address that controls where execution goes when the function returns.

The Attacker's Goal

By overwriting the return address with a controlled value, an attacker redirects program execution to arbitrary code - either shellcode placed in the buffer itself, or a chain of existing code fragments (ROP gadgets).

Defense in Depth

Modern systems layer multiple defenses: stack canaries detect corruption, ASLR randomizes addresses, and DEP prevents executing data as code. Each defense can be bypassed individually, but together they make exploitation significantly harder.

Real-World Impact

Buffer overflows have been exploited for decades - from the Morris Worm (1988) to modern zero-days. Understanding them is essential for writing secure code and evaluating system security.

Defense Mechanisms Explained

Bounds Checking Prevents at Stage 2

Using safe string functions (strncpy, snprintf) that take a maximum length parameter. The overflow never happens because copies are truncated to buffer size. This is the most effective defense - prevent the bug entirely.

Stack Canary Detects at Stage 4

A random value placed between local variables and the return address. Before returning, the function checks if the canary was modified. Bypass: Info leak to read canary value, or overwrite via non-adjacent write.

ASLR Complicates at Stage 5

Randomizes the base addresses of stack, heap, and libraries on each execution. Attacker cannot predict where to jump without additional information. Bypass: Info leak, brute force (32-bit), or partial overwrite.

DEP / NX Blocks at Stage 5

Marks memory pages as either writable or executable, but not both. Shellcode on the stack cannot execute because the stack is non-executable. Bypass: Return-Oriented Programming (ROP) chains existing executable code.

Keyboard shortcuts
  • Space Play / Pause chain
  • Step forward
  • R Reset chain
  • 1-4 Toggle defense (Bounds, Canary, ASLR, DEP)
Security model (30 seconds)

This tool runs entirely in your browser. No code is executed, no memory is actually corrupted - this is a pure visualization of concepts. No data is sent to any server.

Further reading