Embedded Exploit Development & Reverse Engineering Lab

Stack: x86 · ARM · C · GDB · Ghidra Timeline: May 2025 – Aug 2025

A binary-exploitation and reverse-engineering lab built around binaries you compile yourself. Each target isolates one memory-safety class; each ships a working exploit, a mitigation analysis, and a patched build that the exploit can no longer beat. The offense → defense loop is enforced by regression tests in CI.

⚠️ Scope & ethics. Every binary here is compiled from source in this repo, reads only from stdin, and runs locally. The exploits target those binaries and nothing else. This is a training lab for learning how memory-corruption bugs and mitigations work — the same material taught by pwn.college and CTF pwn tracks. Don't point these techniques at software you don't own or aren't authorized to test.

---

Targets and exploits

Target	Bug class	Exploit	Primitive taught
stack_overflow.c	stack buffer overflow	solve_stack.py	control saved RIP → ret2win
stack_overflow.c	(same)	rop_chain.py	ROP: control RDI via pop rdi; ret
format_string.c	format string	solve_format.py	stack info-leak (canary/ptr class)
integer_overflow.c	integer overflow	(write-up)	under-allocation → heap overflow

Full analysis with stack diagrams, offset derivation, and the patch for each is in writeups/.

Mitigations, side by side

make checksec builds everything and reports the enabled protections. The vulnerable and patched builds are compiled from near-identical source so the only meaningful difference is the mitigation posture:

BINARY                   NX       CANARY      PIE      RELRO
----------------------------------------------------------------
vuln_stack_overflow      NX:off   Canary:off  PIE:off  RELRO:some
safe_stack_overflow      NX:on    Canary:on   PIE:on   RELRO:some

The write-ups explain how each mitigation (ASLR, NX, stack canaries, PIE, FORTIFY, RELRO) changes what the attacker must do.

Layout

targets/     vulnerable C sources (built with mitigations OFF)
patched/     remediated sources    (built with mitigations ON)
exploits/    pwntools exploits, deterministic (no-PIE addresses)
analysis/    checksec.sh mitigation reporter
writeups/    per-bug analysis + concrete patch
tests/       pytest: exploits fire on vuln builds, fail on patched

Quick start

pip install -r requirements.txt      # pwntools + pytest
sudo apt-get install gcc make binutils

make all         # build vulnerable + patched targets
make checksec    # show the mitigation table above

python3 exploits/solve_stack.py      # ret2win
python3 exploits/rop_chain.py        # ROP argument control
python3 exploits/solve_format.py     # format-string leak

make test        # regression suite (also runs in CI)

Exploits are deterministic because the vulnerable targets are -no-pie (code addresses are fixed) and the leaked cookie is a data value — no ASLR wrangling needed. On a hardened target you'd first leak an address; the write-ups cover that path.

Reverse-engineering workflow

The RE half of the resume bullet — recovering attack surface from stripped binaries and firmware — uses:

• Ghidra for decompilation of stripped binaries; rename recovered functions, trace protocol/crypto logic, and map the reachable input surface.
• GDB (with pwndbg/gef) for dynamic confirmation: break on the vulnerable call, inspect the stack at overflow, and derive offsets with cyclic.
• objdump/readelf for gadget discovery and mitigation inspection (see analysis/checksec.sh).

make produces symbol-bearing builds for learning; strip them (strip build/*) to practice the same recovery on a stripped target.

ARM note

The concepts port directly to AArch64 (link-register overwrite instead of a saved return address; gadget hunting in libc the same way). Cross-compile a target with aarch64-linux-gnu-gcc and run under qemu-aarch64 to extend the lab; the write-ups flag where the mechanics differ.

License

MIT — see LICENSE.