Fuzzing involves sending malformed, random, or "mutated" data to a program to see if it crashes. A crash usually means a memory corruption vulnerability (Segment Fault), which might be exploitable.
Coverage-Guided Fuzzing
Old fuzzers just sent random garbage.
Modern fuzzers (AFL - American Fuzzy Lop) instrumentation the code.
If a random input triggers a NEW code path (an `if` statement that was never taken before), AFL saves that input and uses it as a seed for further mutation.
This allows it to dive deep into complex formats like JPEG or PDF without knowing the format spec.
1. The Process
1. Corpus: Collect valid samples (e.g., 100 valid JPEG files).
2. Compile: Compile the target program with `afl-gcc` to add the instrumentation.
3. Fuzz: Run `afl-fuzz -i input_dir -o output_dir ./program @@`.
4. Wait: Let it run for 24 hours (or weeks).
5. Triage: Check the `crashes/` folder. Replay them in GDB to analyze the bug.
2. Dumb vs Smart Fuzzing
Dumb (Mutation): Flipping bits randomly. Simple, fast.
Smart (Generation): Understanding the protocol (e.g., HTTP needs "Methods" and "Headers"). Slower, but reaches deeper logic states.
3. Cloud Fuzzing
Google runs "ClusterFuzz" on 25,000 cores continuously fuzzing Chrome and open-source projects. This is why bugs are found and patched so quickly in modern browsers.
How to start
Start with `libFuzzer` (integrated into LLVM/Clang). Write a small function `LLVMFuzzerTestOneInput(data, size)` that calls your library's API. Compile and run.