fuzzing-obstacleslisted

# Overcoming Fuzzing Obstacles Codebases often contain anti-fuzzing patterns that prevent effective coverage. Checksums, global state (like time-seeded PRNGs), and validation checks can block the fuzzer from exploring deeper code paths. This technique shows how to patch your System Under Test (SUT) to bypass these obstacles during fuzzing while preserving production behavior. ## Overview Many real-world programs were not designed with fuzzing in mind. They may: - Verify checksums or cryptographic hashes before processing input - Rely on global state (e.g., system time, environment variables) - Use non-deterministic random number generators - Perform complex validation that makes it difficult for the fuzzer to generate valid inputs These patterns make fuzzing difficult because: 1. **Checksums:** The fuzzer must guess correct hash values (astronomically unlikely) 2. **Global state:** Same input produces different behavior across runs (breaks determinism) 3. **Complex validation:** The fuzzer spends effort hitting validation failures instead of exploring deeper code The solution is conditional compilation: modify code behavior during fuzzing builds while keeping production code unchanged. ### Key Concepts | Concept | Description | |---------|-------------| | SUT Patching | Modifying System Under Test to be fuzzing-friendly | | Conditional Compilation | Code that behaves differently based on compile-time flags | | Fuzzing Build Mode | Special build configuration that enabl