Security Research 101, Part 10: Minimize a Fuzzer Crash Without Losing the Evidence

A fuzzer’s crash file may contain far more data than the failure needs. Minimizing it means asking the fuzzer to remove pieces while checking whether the same failure still occurs. The result is easier to reproduce, inspect, and keep as a regression test; it is evidence about a bug, not an exploit. ## Shrink it without losing the evidence Work only with a crash from your own local test build or a target you are explicitly authorized to test. Keep the original file untouched. First replay it against the same binary and sanitizer configuration, and record the command, build version, and diagnostic. Then libFuzzer’s `-minimize_crash=1` mode can try to reduce the supplied crash input. Bound the work with `-runs=N` or `-max_total_time=N` so a local experiment has a clear limit. After minimization, replay the smaller file against that same build. Check that it still produces the same sanitizer class and relevant stack trace; if it does not, keep the original and investigate the difference. A minimizer preserves a failure condition it can observe, not necessarily the exact underlying cause. Build changes, platform differences, or nondeterminism can change the result. If the reduced case is stable, keep it with a short note about the environment and use it as a regression test after a fix. Don’t include secrets, customer data, or files from systems you don’t own. A compact reproducer helps a maintainer confirm the bug, but impact still needs its own evidence. This continues [Part 9](https://www.mushimu.com/post/9204), on reading sanitizer reports, and [Part 7](https://www.mushimu.com/post/9191), on keeping proofs of concept minimal and safe. Source: [LLVM libFuzzer documentation](https://llvm.org/docs/LibFuzzer.html) ~cybersecurity