Lion Cipher Lab
Fuzz a buggy parser with AFL++ and watch it find the crash
- AppSec / DevSecOps
- Advanced
- ~60 min
- Free · no account required
Why it matters
A huge share of the worst security bugs — the memory-corruption ones behind remote code execution — live in code that parses untrusted input: file formats, network packets, config blobs. You cannot find those by clicking around or reading the code once; the triggering input is some specific byte pattern no human would think to type. A coverage-guided fuzzer finds them for you: it mutates inputs, watches which new code each mutation reaches, and keeps the mutations that explore deeper, drilling automatically toward the corner that crashes. Doing this once — seeing a crash fall out of a program…
What you'll learn
- what coverage-guided fuzzing is and why it beats blind fuzzing
- compiling an instrumented target with afl-cc
- running an AFL++ campaign and reading its status screen
- triaging a crash: reproducing it and inspecting the crashing input
- recognising a stack buffer overflow from a length-unchecked parser
- knowing when a fuzzer will NOT find the bug (magic/checksum gates)
- pro workflow: ASAN builds, cmplog, corpus/crash minimization, parallel fuzzing
Steps in this lab
- What 'coverage-guided fuzzing' actually means
- When you'd reach for this — and when you would not
- Start the AFL++ container
- Write the deliberately-buggy parser
- Compile it WITH instrumentation using afl-cc
- Give it a seed and start fuzzing
- Triage the crash — reproduce it and read the input
- When it does NOT help — magic gates and closed blobs
- The way a pro runs this differently