Project 12: Use-After-Free Demonstrator

A demonstration of use-after-free vulnerabilities and exploitation—showing how freed memory can be reallocated and abused to achieve code execution.

Quick Reference

Attribute Value
Primary Language C
Alternative Languages Python (for exploit)
Difficulty Level 4: Expert
Time Estimate 3-4 weeks
Knowledge Area Exploit Awareness / Heap Exploitation
Tooling GDB, heap visualization tools
Prerequisites Projects 3, 6, 8, heap internals

What You Will Build

A demonstration of use-after-free vulnerabilities and exploitation—showing how freed memory can be reallocated and abused to achieve code execution.

Why It Matters

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

Core Challenges

  • Understanding heap reuse → maps to how freed chunks are recycled
  • Controlling freed data → maps to timing and allocation order
  • Hijacking control flow → maps to overwriting function pointers
  • Heap grooming → maps to manipulating heap state

Key Concepts

  • Heap Chunk Lifecycle: glibc malloc internals
  • Fastbin/Tcache: Modern allocator optimizations
  • Type Confusion: Reusing memory as different type

Real-World Outcome

$ ./uaf_demo

=== Use-After-Free Demonstration ===

Step 1: Allocate object with function pointer
  Object at 0x55a0001234a0
  object->callback = 0x55a000001234 (good_function)

Step 2: Free the object
  Freed object (but pointer still exists!)
  Dangling pointer: 0x55a0001234a0

Step 3: Allocate new data of same size
  New allocation at: 0x55a0001234a0 (same address!)
  Writing "AAAA" + evil_function address...

Step 4: Call the dangling pointer's callback
  Calling object->callback()...

*** HIJACKED ***
evil_function() called!
This would be shellcode in a real exploit.

=== Exploitation Successful ===

Understanding what happened:
1. Original object freed, but pointer kept
2. New allocation reused same memory
3. Attacker data overwrote function pointer
4. Calling original pointer's method = calling attacker's code

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
  • “The Shellcoder’s Handbook”