fuzzing-obstacles

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 enables fuzzing-specific patches
False Positives	Crashes found during fuzzing that cannot occur in production
Determinism	Same input always produces same behavior (critical for fuzzing)

When to Apply

Apply this technique when:

• The fuzzer gets stuck at checksum or hash verification
• Coverage reports show large blocks of unreachable code behind validation
• Code uses time-based seeds or other non-deterministic global state
• Complex validation makes it nearly impossible to generate valid inputs
• You see the fuzzer repeatedly hitting the same validation failures