x86 Exploit Lab

A controlled buffer overflow study on x86-64 Linux. A vulnerable C target, a 272-byte payload, 23 bytes of shellcode that spawns a root shell, and a full analysis of the four modern memory protections that defeat this class of attack in production.

What it is

A hands-on security research environment for studying classical stack buffer overflow attacks on x86-64. A vulnerable C program uses strcpy() without bounds checking, letting a crafted payload overflow a 256-byte buffer, overwrite the saved return address, and redirect execution to injected shellcode. Runs in an isolated QEMU VM with ASLR, DEP, and stack canaries disabled for controlled experimentation. Paired with a writeup covering the mechanics of the exploit and the defenses that prevent it.

By the numbers

Architecture

Stack layout (low to high)
  [ Buffer 256 bytes ] -> [ Saved RBP 8 bytes ] -> [ Return Address 8 bytes ]

Exploit payload
  [ NOPs 100 bytes ] -> [ Shellcode 23 bytes ] -> [ Padding 141 bytes ]
                    -> [ Overwrite RBP ] -> [ Overwrite Return -> NOP sled ]

Key features

• 23-byte x86-64 shellcode — Performs execve("/bin/sh", NULL, NULL) via syscall 59. XORs registers to zero, pushes /bin//sh as a 64-bit constant, and triggers the system call.
• NOP sled technique — 100-byte landing zone before the shellcode transforms the precision problem of hitting a single address into a range problem, tolerating up to 32 bytes of stack address variability.
• Environment normalization — Clears all environment variables except a minimal PATH to produce a deterministic stack layout, making the buffer address predictable across different shell environments.
• GDB-guided address discovery — Locates the exact buffer address (0x7fffffffdbd0) and calculates the return address offset (+0x20) that lands inside the NOP sled.
• Comprehensive defense analysis — Covers how stack canaries, ASLR, DEP/NX, and PIE each independently defeat this class of attack, and how techniques like return-oriented programming (ROP) and format string vulnerabilities can sometimes circumvent individual protections.

What makes it stand out

• End-to-end chain, not a snippet — Vulnerable target, payload constructor, hand-written shellcode, and deterministic delivery all in one lab.
• Defense-first writeup — The interesting artifact isn't the exploit, it's the protection analysis explaining why this attack no longer works on any modern system.
• Isolated and reproducible — QEMU VM with explicitly disabled protections makes the experiment controlled, repeatable, and safe.

Stack

Links

• Source: https://github.com/FardinIqbal/x86-exploit-lab