Phase 08 - Vulnerability Research, Fuzzing, and Reverse Engineering
Duration: 8 weeks (Months 17-18)
Objective: discover, minimize, explain, fix, test, and responsibly report vulnerabilities in
owned lab software or authorized open-source projects.
Deep guides: WARMUP.md explains harness quality, crash-to-impact reasoning, minimization, patches, variants, and disclosure; HITCHHIKERS-GUIDE.md provides the safe fuzzing campaign and triage workflow.
CVE practice: CVE Casebook maps Heartbleed, Log4Shell, runc container-boundary failures, and ingress-nginx CVE-2025-1974 into safe toy reproductions, patch invariants, variant analysis, fleet response, and detections. Use the analysis template for every public case.
Safety Boundary
Work only on purpose-built targets, CTF binaries, or open-source projects whose policy permits the work. Stop at minimum proof. This phase does not teach persistence, stealth, credential theft, real-world intrusion, or deployment of weaponized exploits.
Required Theory
- Memory corruption and logic vulnerability classes; preconditions, reachability, mitigations, exploitability uncertainty, and severity.
- Coverage-guided, mutation, generation, structure-aware, stateful, differential, and snapshot fuzzing.
- libFuzzer, AFL++, sanitizers (ASan, UBSan, MSan, TSan), corpus design, dictionaries, coverage, deduplication, minimization, flaky crashes, and resource exhaustion.
- Binary loading, symbols, control/data flow, calling conventions, decompilation, dynamic debugging, patch diffing, and source/binary correlation.
- Root cause, variant analysis, secure parser design, patch review, regression tests, CVE lifecycle, embargoes, VRP rules, and research writing.
8-Week Lab Sequence
| Week | Lab | Deliverable |
|---|---|---|
| 1 | toy binary parser fuzzing | harness, corpus, coverage baseline, three seeded bugs |
| 2 | image/chunk parser | structure-aware inputs, dictionary, minimized crashes |
| 3 | local protocol state machine | in-process/stateful harness, timeout and nondeterminism controls |
| 4 | sanitizer triage | deduplication, root-cause traces, exploitability caveats, patches |
| 5 | regression and variant analysis | tests for root cause plus related code-path checklist |
| 6 | reverse simple stripped binaries | function map, data structures, behavior report, debugger evidence |
| 7 | patch-diff analysis | security-relevant changes, affected versions, detection and backport plan |
| 8 | authorized open-source review | scoped component review and disclosure package or documented no-findings report |
Runnable lab portfolio
- Crash Triage, Minimization, Patch, and Regression
- Stateful Protocol Fuzzer Model
- Security Patch and Variant Analyzer
The labs cover stateless and stateful fuzzing, reproducible minimization, strict patches, regression conversion, and systematic variant search.
CTF-style challenges may be used to practice debugging and mitigation concepts, but portfolio artifacts should emphasize engineering analysis and fixes rather than exploit payloads.
Capstone - Vulnerability Research Package
Select a non-trivial parser or protocol component and produce:
- documented scope and authorization;
- reproducible build with sanitizer configuration;
- harness, seed corpus, dictionary, and coverage report;
- minimized crashing input and evidence manifest;
- root-cause and reachability analysis;
- patch and regression test;
- variant-analysis results;
- secure coding guidance;
- disclosure-style vendor report;
- public-safe blog post and 15-minute conference talk.
If no original defect is found, the capstone still passes with a rigorous coverage-gap analysis, harness contribution, and documented negative result. Fabricating novelty is an automatic failure.
Tools and Sources
clang/LLVM, libFuzzer, AFL++, sanitizers, GDB/LLDB, Ghidra, objdump/readelf equivalents, coverage tools, debugger scripting, OSS-Fuzz documentation, The Fuzzing Book, Practical Binary Analysis, project source/history, public CVE patches, and compiler/ABI specifications.
Measures
- Harness is deterministic, fast enough for sustained testing, and contains no false crash oracle.
- Each crash is minimized, deduplicated, and converted into a regression test.
- Report separates crash, security boundary, reachability, controllability, and demonstrated impact.
- Patch addresses root cause rather than only the triggering input.
- Disclosure package can be reproduced by the maintainer from a clean environment.
Evaluation Checklist
- Choose an appropriate fuzz boundary and explain why.
- Improve coverage through harness/corpus work rather than run time alone.
- Triage a sanitizer trace to root cause.
- Read enough assembly/decompiler output to validate source assumptions.
- Perform patch and variant analysis without publishing unsafe detail prematurely.
- Handle duplicate, disputed severity, embargo, and coordinated release professionally.
Common Mistakes and Interview Questions
Mistakes: fuzzing a CLI subprocess when an in-process API exists, counting crashes as unique bugs, ignoring timeouts/leaks, overclaiming exploitability, fixing the symptom, retaining sensitive samples, and publishing before coordination.
Questions: design a harness for a stateful parser; triage a heap-use-after-free; assess a patch for variants; compare sanitizers; explain why coverage plateaued; write a maintainer-friendly report; decide whether a crash is security-relevant.
Portfolio and Stretch
Publish harnesses upstream where welcomed, patches, tests, sanitized research notes, and talks. Stretch: grammar-aware fuzzing, differential implementations, custom mutator, persistent mode, symbolic-execution-assisted seed generation, kernel/interface fuzzing only in specialized isolated labs, or a responsible CVE process.