Project 12: Fuzzing with AFL++

Expanded deep-dive guide for Project 12 from the Binary Analysis sprint.

Quick Reference

Attribute Value
Difficulty Level 3: Advanced
Time Estimate 2-3 weeks
Main Programming Language C (for harnesses), Shell
Alternative Programming Languages Python (for orchestration)
Coolness Level Level 4: Hardcore Tech Flex
Business Potential 3. The “Service & Support” Model
Knowledge Area Vulnerability Discovery / Fuzzing
Software or Tool AFL++, libFuzzer, Address Sanitizer
Main Book “The Fuzzing Book” (online)

1. Learning Objectives

  1. Build a working implementation with reproducible outputs.
  2. Justify key design choices with binary-analysis principles.
  3. Produce an evidence-backed report of findings and limitations.
  4. Document hardening or next-step improvements.

2. All Theory Needed (Per-Concept Breakdown)

This project depends on concepts from the main sprint primer: loader semantics, control/data-flow recovery, runtime observation, and mitigation-aware vulnerability reasoning. Before implementation, restate the project’s core assumptions in your own words and define how you will validate them.

3. Project Specification

3.1 What You Will Build

Fuzzing campaigns that automatically discover crashes and vulnerabilities in binary programs.

3.2 Functional Requirements

  1. Accept the target binary/input and validate format assumptions.
  2. Produce analyzable outputs (console report and/or artifacts).
  3. Handle malformed inputs safely with explicit errors.

3.3 Non-Functional Requirements

  • Reproducibility: same input should produce equivalent findings.
  • Safety: unknown samples run only in isolated lab contexts.
  • Clarity: separate facts, hypotheses, and inferred conclusions.

3.4 Expanded Project Brief

  • File: P12-fuzzing-with-afl.md

  • Main Programming Language: C (for harnesses), Shell
  • Alternative Programming Languages: Python (for orchestration)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Vulnerability Discovery / Fuzzing
  • Software or Tool: AFL++, libFuzzer, Address Sanitizer
  • Main Book: “The Fuzzing Book” (online)

What you’ll build: Fuzzing campaigns that automatically discover crashes and vulnerabilities in binary programs.

Why it teaches binary analysis: Fuzzing is how most modern vulnerabilities are found. Understanding fuzzing means understanding what makes programs crash.

Core challenges you’ll face:

  • Writing harnesses → maps to calling the target function
  • Preparing corpus → maps to good starting inputs
  • Triaging crashes → maps to which crashes are exploitable?
  • Binary-only fuzzing → maps to QEMU mode, Frida

Resources for key challenges:

Key Concepts:

  • Coverage-Guided Fuzzing: AFL++ docs
  • Sanitizers: LLVM sanitizer docs
  • Persistent Mode: AFL++ performance docs

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: C programming, Projects 1-3

Real World Outcome

Deliverables:

  • Analysis output or tooling scripts
  • Report with control/data flow notes

Validation checklist:

  • Parses sample binaries correctly
  • Findings are reproducible in debugger
  • No unsafe execution outside lab ```bash

    Compile target with instrumentation

    $ afl-gcc -o target target.c

Prepare input corpus

$ mkdir in out $ echo “test” > in/seed1

Start fuzzing

$ afl-fuzz -i in -o out ./target @@

AFL++ output:

american fuzzy lop ++4.00c

┌─ process timing ─────────────────────────────────────┐

│ run time : 0 days, 0 hrs, 23 min, 45 sec │

│ last new find : 0 days, 0 hrs, 0 min, 12 sec │

├─ overall results ────────────────────────────────────┤

│ cycles done : 847 │

│ corpus count : 234 │

│saved crashes : 3 (!) │ ← Found bugs!

│ saved hangs : 0 │

└──────────────────────────────────────────────────────┘

Triage crashes

$ for crash in out/crashes/*; do ./target “$crash” 2>&1 | head -5 done


#### Hints in Layers
Writing a harness:
```c
// For AFL++
int main(int argc, char **argv) {
    if (argc < 2) return 1;

    FILE *f = fopen(argv[1], "r");
    if (!f) return 1;

    char buf[1024];
    size_t len = fread(buf, 1, sizeof(buf), f);
    fclose(f);

    // Call the function we want to fuzz
    parse_input(buf, len);
    return 0;
}

// For libFuzzer
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    parse_input((char*)data, size);
    return 0;
}

AFL++ modes:

  • Source mode: Compile with afl-gcc/afl-clang-fast
  • QEMU mode: Fuzz binaries without source (-Q flag)
  • Frida mode: Alternative for binary-only
  • Persistent mode: Faster fuzzing with loop

Sanitizers (compile with these for better crash detection):

# Address Sanitizer (memory bugs)
clang -fsanitize=address,fuzzer target.c

# Undefined Behavior Sanitizer
clang -fsanitize=undefined,fuzzer target.c

Learning milestones:

  1. Fuzz simple target → Find obvious crashes
  2. Write custom harness → Fuzz specific functions
  3. Triage crashes → Determine exploitability
  4. Fuzz binary-only → No source code available

The Core Question You Are Answering

“How do we automatically generate millions of test inputs to stress-test software and uncover crashes, memory corruption, and security vulnerabilities—faster than any human could manually test?”

This project introduces coverage-guided fuzzing, a technique that uses code coverage feedback to intelligently generate inputs that explore new execution paths. You’ll learn how fuzzers like AFL++ combine random mutation with evolutionary algorithms to find bugs that have eluded traditional testing for years.

Concepts You Must Understand First

  1. Coverage-Guided Fuzzing vs. Dumb Fuzzing
    • Dumb fuzzing: random inputs, no feedback (fast but inefficient)
    • Coverage-guided: monitors code coverage, prioritizes inputs that reach new code
    • Evolutionary algorithm: “interesting” inputs mutated to find more code

    Guiding Questions:

    • Why does code coverage feedback make fuzzing 10-100x more effective?
    • What’s the difference between edge coverage and block coverage?
    • How does AFL++ track which inputs discovered new paths?

    Book References:

    • “The Fuzzing Book” (online) - Chapter: Coverage-Based Fuzzing
    • “Fuzzing: Brute Force Vulnerability Discovery” by Sutton, Greene, Amini - Chapter 4: Feedback-Driven Fuzzing
  2. Code Instrumentation and Compile-Time Hooking
    • How afl-gcc/afl-clang inject coverage tracking code into binaries
    • Shared memory bitmap: fast communication between target and fuzzer
    • Hash collisions and edge coverage vs. exact hit count

    Guiding Questions:

    • What assembly instructions does AFL++ insert at each basic block?
    • Why use shared memory instead of file I/O for coverage feedback?
    • What happens when two different edges hash to the same bitmap index?

    Book References:

    • AFL++ Technical Whitepaper
    • “Practical Binary Analysis” by Dennis Andriesse - Chapter 11: Dynamic Binary Instrumentation (similar techniques)
  3. Genetic Algorithms in Fuzzing
    • Mutation strategies: bit flips, byte replacements, arithmetic operations
    • Crossover/splicing: combining parts of two interesting inputs
    • Fitness function: how “interesting” is this input? (new coverage? speed?)

    Guiding Questions:

    • Why does AFL++ keep a queue of “interesting” inputs instead of just one?
    • How does deterministic mutation differ from havoc mutation?
    • What makes an input worth saving to the corpus?

    Book References:

    • “The Fuzzing Book” - Chapter: Mutation-Based Fuzzing
    • “The Fuzzing Book” - Chapter: Grammar-Based Fuzzing (advanced: structured inputs)
  4. Sanitizers (ASan, UBSan, MSan)
    • AddressSanitizer (ASan): detects buffer overflows, use-after-free
    • UndefinedBehaviorSanitizer (UBSan): catches signed integer overflow, null deref
    • MemorySanitizer (MSan): finds uninitialized memory reads

    Guiding Questions:

    • Why doesn’t a buffer overflow always cause an immediate crash?
    • How does ASan detect a 1-byte overflow that doesn’t corrupt anything critical?
    • What’s the performance cost of running with sanitizers?

    Book References:

    • LLVM Sanitizer Documentation
    • “The Fuzzing Book” - Chapter: Fuzzing with Grammars (discusses sanitizers)
    • Google AddressSanitizer Wiki
  5. Harness Design
    • Isolating the target function from I/O, state, and external dependencies
    • Persistent mode: fuzz in-process loop (1000x faster than fork-exec)
    • Shared memory fuzzing: even faster communication

    Guiding Questions:

    • Why is fork-exec fuzzing slower than persistent mode?
    • What state needs to be reset between iterations in persistent mode?
    • When would you NOT use persistent mode?

    Book References:

    • AFL++ Documentation - Persistent Mode
    • “The Fuzzing Book” - Chapter: Fuzzing APIs
  6. Corpus Distillation and Minimization
    • Corpus: collection of “interesting” inputs that trigger unique paths
    • Minimization: reducing input size while preserving path coverage
    • Why smaller inputs = faster fuzzing

    Guiding Questions:

    • Why does AFL++ automatically minimize crash inputs?
    • How can you merge multiple fuzzer output directories?
    • What’s the trade-off between corpus size and fuzzing speed?

    Book References:

    • AFL++ Documentation - Corpus Management
    • “The Fuzzing Book” - Chapter: Reducing Failure-Inducing Inputs
  7. Binary-Only Fuzzing (QEMU Mode)
    • When source code isn’t available (proprietary software, firmware)
    • QEMU user-mode emulation: CPU-level instrumentation
    • Performance cost: 2-5x slower than source-based fuzzing

    Guiding Questions:

    • How does AFL++ instrument a binary without recompiling?
    • Why is QEMU mode slower than compile-time instrumentation?
    • When would you use Frida mode instead of QEMU mode?

    Book References:

    • AFL++ Documentation - Binary-Only Fuzzing
    • QEMU User Mode Documentation
  8. Crash Triage and Exploitability
    • Not all crashes are exploitable (assertion failures, null deref in safe context)
    • Stack traces, registers, and memory dumps to understand root cause
    • Exploitability scoring: can an attacker control RIP/EIP?

    Guiding Questions:

    • What’s the difference between a DoS crash and RCE crash?
    • How do you deduplicate crashes (same bug, different inputs)?
    • What makes a heap overflow more exploitable than a stack overflow?

    Book References:

    • “The Fuzzing Book” - Chapter: Debugging and Fixing Bugs
    • “Practical Malware Analysis” by Sikorski & Honig - Chapter 7: Analyzing Malicious Windows Programs (crash analysis)
    • “Hacking: The Art of Exploitation” by Jon Erickson - Chapter 0x300: Exploitation (exploitability)
  9. Fuzzing State Machines and Protocols
    • Stateful fuzzing: multiple requests in sequence (login → action → logout)
    • Protocol fuzzing: maintaining valid structure while mutating fields
    • Grammar-based fuzzing for structured inputs (JSON, XML, network protocols)

    Guiding Questions:

    • How do you fuzz a server that requires authentication?
    • Why is completely random data ineffective for JSON parsing?
    • How do you maintain protocol structure while still finding bugs?

    Book References:

    • “The Fuzzing Book” - Chapter: Fuzzing APIs
    • “The Fuzzing Book” - Chapter: Grammars and Parse Trees
    • “Fuzzing: Brute Force Vulnerability Discovery” - Chapter 11: Protocol Fuzzing
  10. Parallelization and Distributed Fuzzing
    • Running multiple fuzzer instances for better coverage
    • Master/slave architecture: instances share discoveries
    • Syncing corpus between fuzzers

    Guiding Questions:

    • Why does running 10 fuzzers give you more than 10x throughput?
    • How do AFL++ instances communicate discovered paths?
    • What’s the optimal number of fuzzer instances for your CPU cores?

    Book References:

    • AFL++ Documentation - Parallelization
    • “The Fuzzing Book” - Chapter: Fuzzing with Grammars (scaling)

Questions to Guide Your Design

  1. How do you design a good seed corpus for your target?
    • Should seeds be minimal? Diverse? Cover all features?
    • Where do you get seeds? (valid test files, documentation examples, web scraping)
    • How many seeds is optimal? (1? 100? 10,000?)
  2. What’s your strategy for persistent mode harness design?
    • What state needs reset (globals, heap, file descriptors)?
    • How do you handle memory leaks in persistent mode?
    • When does cumulative state pollution become a problem?
  3. How do you prioritize which crashes to investigate first?
    • Stack smashing vs. heap corruption vs. null deref
    • Unique crash traces vs. duplicates
    • Consider: exploitability, severity, ease of fix
  4. When should you use AFL++ vs. libFuzzer?
    • AFL++: standalone binaries, fork-exec model, binary-only support
    • libFuzzer: in-process fuzzing, better for libraries/APIs, faster
    • Which for: file parser? Network server? Library function?
  5. How do you fuzz a program that requires specific input structure?
    • Use AFL++’s custom mutators? Grammar-based fuzzer?
    • Pre-process inputs to fix checksums/lengths?
    • Or just let fuzzer learn structure through feedback?
  6. What metrics tell you fuzzing is “done” or needs a different approach?
    • No new paths in N hours?
    • Diminishing returns on exec/sec?
    • Coverage plateau?
  7. How would you fuzz a network server with AFL++?
    • Harness that reads from file and sends to socket?
    • Preeny/AFL++’s network mode?
    • Consider: connection handling, state, timeouts
  8. What’s your approach for triaging hundreds of crash files?
    • Automated deduplication (stack hash, crash hash)
    • Minimization to reduce noise
    • Scripted triage: GDB automation, register dumps
    • Prioritization based on exploitability signals

Thinking Exercise

Exercise 1: Understanding Coverage Feedback

Consider this simple function:

void parse(char *input) {
    if (input[0] == 'A') {
        if (input[1] == 'B') {
            if (input[2] == 'C') {
                crash();  // Bug!
            }
        }
    }
}

Questions:

  1. Starting with seed “XXX”, what mutations will AFL++ try?
  2. How many generations to reach “ABC” (on average)?
  3. Why would dumb fuzzing (pure random) take millions of tries?
  4. Draw the coverage map evolution as AFL++ discovers A, AB, ABC.

Exercise 2: Designing a Harness

You need to fuzz this library function:

int process_image(uint8_t *data, size_t len) {
    // Parses image header, processes pixels
    // Maintains internal state in global variables
    return 0;
}

Tasks:

  1. Write an AFL++ harness (file-based).
  2. Convert to persistent mode harness.
  3. What global state needs resetting?
  4. How do you handle if process_image crashes?

Exercise 3: Crash Triage

AFL++ found a crash with this input: AAAAAAAAAAAAAAAAAAAAAAAAAAAA... (100 A’s)

GDB shows:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004141414141 in ?? ()

Questions:

  1. What type of vulnerability is this?
  2. Is it likely exploitable? Why?
  3. What register likely contains 0x4141414141414141?
  4. How would you confirm this is a buffer overflow vs. use-after-free?
  5. What’s the next step: minimize input, write exploit, or file bug report?

Exercise 4: Optimizing Fuzzing Performance

Your fuzzer shows these stats:

exec speed: 150/sec
corpus count: 4500
last new path: 6 hours ago
stability: 95%

Questions:

  1. Is 150 exec/sec good or bad? (Depends on target complexity)
  2. What does low stability (95%) indicate?
  3. What would you try to increase exec/sec?
  4. When should you stop fuzzing this campaign?

Exercise 5: Sanitizer Output Analysis

ASan reports:

==1234==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000018
READ of size 4 at 0x602000000018
    #0 0x4005a3 in parse_header /src/parser.c:45
    #1 0x4006f2 in main /src/main.c:12

0x602000000018 is located 0 bytes to the right of 24-byte region
allocated by:
    #0 0x7f8b2e in malloc
    #1 0x4005f3 in parse_header /src/parser.c:42

Interpret this:

  1. What line contains the bug?
  2. What was the allocation size?
  3. How many bytes did the read overflow by?
  4. Is this a write or read overflow? (Check severity)
  5. What fix would you apply?

The Interview Questions They’ll Ask

  1. “Explain how AFL++’s coverage-guided fuzzing works.”
    • Expected Answer: AFL++ instruments the binary to track which edges (basic block transitions) are hit. It maintains a bitmap of discovered edges. For each input, it checks if new edges are hit. If yes, the input is “interesting” and saved to corpus for mutation. AFL++ mutates interesting inputs (bit flips, arithmetic, splicing) and repeats. Over time, it evolves inputs that explore deeper into the program, finding crashes in rare paths.
  2. “What’s the difference between afl-gcc, afl-clang-fast, and afl-qemu?”
    • Expected Answer: afl-gcc: compile-time instrumentation via GCC plugin, slower compilation. afl-clang-fast: uses LLVM passes for instrumentation, faster and better optimization. afl-qemu: binary-only fuzzing via CPU emulation, no source needed but 2-5x slower. Use clang-fast when you have source, QEMU when you don’t.
  3. “Why is persistent mode faster than fork-exec mode?”
    • Expected Answer: Fork-exec mode spawns a new process for every input (high overhead: process creation, loading binary, linking libraries). Persistent mode runs target in a loop within same process—just one fork, then thousands of iterations. Can achieve 1000x speedup. Trade-off: must ensure state is reset between iterations to avoid cumulative bugs.
  4. “What’s AddressSanitizer and why use it with AFL++?”
    • Expected Answer: ASan is a compiler instrumentation that detects memory errors (buffer overflows, use-after-free, double-free). It adds “red zones” around allocations and checks every memory access. With AFL++, ASan catches subtle bugs that don’t immediately crash—turning silent corruption into loud crashes. Performance cost: 2x slowdown, but worth it for bug detection.
  5. “You’ve been fuzzing for 24 hours with no new paths. What do you do?”
    • Expected Answer: (1) Check coverage—have you plateaued at low coverage? (2) Improve seed corpus—add diverse valid inputs. (3) Try custom mutator for structured data. (4) Use dictionary for magic bytes/keywords. (5) Try grammar-based fuzzing for complex formats. (6) Check if target is doing input validation that rejects most mutations. (7) Consider if you’ve found all easy bugs—might need symbolic execution or manual analysis for deeper bugs.
  6. “How do you triage 500 crash files from a fuzzing campaign?”
    • Expected Answer: (1) Deduplicate: Use AFL++’s afl-cmin or crash hash (stack trace hash) to group duplicates. (2) Minimize: Use afl-tmin to reduce crash inputs to minimal size. (3) Exploitability: Prioritize based on crash type (RIP control > heap overflow > null deref). (4) Automate: Script GDB to dump registers/backtrace for each unique crash. (5) Categorize: File bugs by root cause. (6) Fix: Start with most severe/exploitable.
  7. “What’s the difference between edge coverage and block coverage?”
    • Expected Answer: Block coverage: which basic blocks executed (e.g., blocks A, B, C). Edge coverage: which transitions between blocks (A→B, B→C). Edge coverage is more precise—same blocks can be hit via different paths. Example: if(x) {A();} else {B();} C(); has edges (start→A→C) and (start→B→C). AFL++ uses edge coverage to discover these different paths.
  8. “How would you fuzz a closed-source binary?”
    • Expected Answer: Use AFL++’s QEMU mode (-Q flag) or Frida mode. QEMU emulates the binary and instruments at CPU instruction level. Slower than source-based but works without source. Steps: (1) afl-fuzz -Q -i in -o out ./binary @@. (2) Ensure binary isn’t stripped (or use -Q -m none). (3) May need to adjust timeouts for slower execution. (4) Alternative: use Intel PT for hardware-based tracing (faster than QEMU).
  9. “Explain the concept of a ‘deterministic’ vs. ‘havoc’ stage in AFL++.”
    • Expected Answer: Deterministic: AFL++ tries systematic mutations—every bit flip, byte flip, arithmetic operations at every position. Thorough but slow. Havoc: random chaotic mutations—multiple random changes per input, stacked mutations, splicing. Fast exploration. AFL++ does deterministic first for new inputs, then switches to havoc. Deterministic finds “obvious” bugs, havoc finds complex multi-condition bugs.
  10. “You found a crash but the minimized input is still 10KB. Why might minimization fail to shrink it further?”
    • Expected Answer: (1) Bug requires multiple conditions spread across input. (2) Checksum/length field must match—removing bytes breaks validity. (3) Complex state machine—need valid sequence to reach crash. (4) Minimizer’s algorithm limitation (greedy approach can get stuck). Solutions: (1) Manual analysis to understand trigger. (2) Use structure-aware minimization. (3) Binary search on input chunks. (4) Check if crash is stable—does it reproduce consistently?

Books That Will Help

Topic Book Chapter/Section Why It Matters
Fuzzing Fundamentals “The Fuzzing Book” by Andreas Zeller et al. (online) Chapter: Coverage-Based Fuzzing Comprehensive introduction to fuzzing concepts
Mutation Strategies “The Fuzzing Book” Chapter: Mutation-Based Fuzzing How fuzzers generate new inputs
Grammar-Based Fuzzing “The Fuzzing Book” Chapter: Fuzzing with Grammars Structured input fuzzing (JSON, XML)
Reducing Inputs “The Fuzzing Book” Chapter: Reducing Failure-Inducing Inputs Input minimization techniques
Professional Fuzzing “Fuzzing: Brute Force Vulnerability Discovery” by Sutton, Greene, Amini Ch. 4: Feedback-Driven Fuzzing Industry perspective on fuzzing
Protocol Fuzzing “Fuzzing: Brute Force Vulnerability Discovery” Ch. 11: Network Protocol Fuzzing Fuzzing stateful systems
Binary Instrumentation “Practical Binary Analysis” by Dennis Andriesse Ch. 11: Dynamic Binary Instrumentation How instrumentation works (Pin, DynamoRIO, similar to AFL++)
Memory Corruption “Hacking: The Art of Exploitation” by Jon Erickson Ch. 0x300: Exploitation Understanding crashes fuzzers find
Buffer Overflows “Hacking: The Art of Exploitation” Ch. 0x350: Buffer Overflows What makes crashes exploitable
Shellcode and Payloads “Hacking: The Art of Exploitation” Ch. 0x500: Shellcode Exploitation after finding crash
Heap Exploitation “Computer Systems: A Programmer’s Perspective” by Bryant & O’Hallaron Ch. 9.9: Dynamic Memory Allocation Understanding heap bugs fuzzers find
Memory Safety “Computer Systems: A Programmer’s Perspective” Ch. 9.11: Common Memory-Related Bugs Types of vulnerabilities fuzzing discovers
Program Optimization “Computer Systems: A Programmer’s Perspective” Ch. 5: Optimizing Program Performance Understanding fuzzer performance
Crash Analysis “Practical Malware Analysis” by Sikorski & Honig Ch. 9: OllyDbg (debugging crashes) Triaging fuzzer-discovered crashes
GDB for Triage “The Art of Debugging with GDB, DDD, and Eclipse” by Matloff & Salzman Entire book Automating crash analysis
Sanitizers Google AddressSanitizer Documentation All sections Using ASan/MSan/UBSan with fuzzers
LLVM Sanitizers LLVM Sanitizer Documentation All sections Understanding sanitizer output
AFL++ Technical Details AFL++ Official Documentation All sections Comprehensive AFL++ usage guide
Parallel Fuzzing AFL++ Documentation Parallelization section Scaling fuzzing campaigns
QEMU Internals QEMU User Mode Documentation Technical documentation Understanding binary-only fuzzing
Libfuzzer libFuzzer Tutorial by Google Full tutorial Alternative in-process fuzzing

Common Pitfalls and Debugging

Problem 1: “Your interpretation does not match runtime behavior”

  • Why: Static analysis can hide runtime-resolved addresses, lazy binding, and input-dependent branches.
  • Fix: Reproduce the path with debugger or tracer, then compare static assumptions against live register/memory state.
  • Quick test: Run the same sample through both your static workflow and a debugger transcript, and confirm control-flow decisions align.

Problem 2: “Tool output is inconsistent across machines”

  • Why: ASLR, tool version drift, and different binary build flags (PIE, RELRO, symbols stripped) change observed addresses and metadata.
  • Fix: Pin tool versions, capture checksec/metadata, and document environment assumptions in your report.
  • Quick test: Re-run analysis in a container or VM with pinned tools and compare hashes of generated outputs.

Problem 3: “Analysis accidentally executes unsafe code”

  • Why: Dynamic workflows run binaries in host context without sufficient isolation.
  • Fix: Use disposable snapshots, no-network execution, and non-privileged users for all unknown samples.
  • Quick test: Validate isolation controls first (network disabled, snapshot active, unprivileged user), then execute sample.

Definition of Done

  • Core functionality works on reference inputs
  • Edge cases are tested and documented
  • Results are reproducible (same binary, same tools, same report output)
  • Analysis notes clearly separate observations, assumptions, and conclusions
  • Lab safety controls were applied for any dynamic execution

4. Solution Architecture

Input Artifact -> Parse/Decode -> Analysis Engine -> Validation Layer -> Report

Design each stage so intermediate artifacts are inspectable (JSON/text/notes), which makes debugging and peer review much easier.

5. Implementation Phases

Phase 1: Foundation

  • Define input assumptions and format checks.
  • Produce a minimal golden output on one known sample.

Phase 2: Core Functionality

  • Implement full analysis pass for normal cases.
  • Add validation against an external ground-truth tool.

Phase 3: Hard Cases and Reporting

  • Add malformed/edge-case handling.
  • Finalize report template and reproducibility notes.

6. Testing Strategy

  • Unit-level checks for parser/decoder helpers.
  • Integration checks against known binaries/challenges.
  • Regression tests for previously failing cases.

7. Extensions & Challenges

  • Add automation for batch analysis and comparative reports.
  • Add confidence scoring for each major finding.
  • Add export formats suitable for CI/security pipelines.

8. Production Reflection

Map your project output to a production analogue: what reliability, observability, and security controls would be required to run this continuously in an engineering organization?