Project 10: Return-to-libc Attack Lab

A series of progressively difficult return-to-libc exploits that bypass NX/DEP protection by reusing existing library code instead of injecting shellcode.

Quick Reference

Attribute Value
Primary Language C (targets), Python (exploits)
Alternative Languages Assembly
Difficulty Level 3: Advanced
Time Estimate 2-3 weeks
Knowledge Area Exploit Awareness / NX Bypass
Tooling GDB, pwntools, checksec
Prerequisites Projects 3-5, buffer overflow basics

What You Will Build

A series of progressively difficult return-to-libc exploits that bypass NX/DEP protection by reusing existing library code instead of injecting shellcode.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Finding libc addresses → maps to ASLR considerations
  • Setting up function arguments → maps to calling conventions
  • Chaining multiple calls → maps to return chaining
  • Finding “/bin/sh” string → maps to string gadgets in libc

Key Concepts

  • Calling Conventions: System V ABI for x64
  • GOT/PLT: “Practical Binary Analysis” Ch. 2
  • ASLR: Address Space Layout Randomization

Real-World Outcome

$ cd ret2libc-lab

$ ./level1
Simple ret2libc: NX enabled, no ASLR, no canary
Enter name: [overflow payload with system() address]
$ whoami
pwned

$ ./level2
ret2libc with argument: Must pass correct argument to system()
[payload with gadget: pop rdi; ret + "/bin/sh" addr + system()]
$ id
uid=1000(user) gid=1000(user) groups=1000(user)

$ ./level3
ret2libc with ASLR: Must leak libc address first
[leak puts@got, calculate libc base, call system("/bin/sh")]
$ cat /flag
FLAG{ret2libc_master}

$ ./level4
Full chain: leak + ROP + shell
[complete exploit with info leak and chained calls]

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_SECURE_C_AND_EXPLOIT_AWARENESS.md
  • “Hacking: The Art of Exploitation” by Jon Erickson