Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/fuzzing-obstacles
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Techniques for patching code to overcome fuzzing obstacles. Use when checksums, global state, or other barriers block fuzzer progress.
📊 Stats
Stars6,228
Forks540
LanguagePython
LicenseCC-BY-SA-4.0
📦 Ships with trailofbits-skills
</> SKILL.md
fuzzing-obstacles.SKILL.md
---name: fuzzing-obstacles
type: technique
description: >
Techniques for patching code to overcome fuzzing obstacles.
Use when checksums, global state, or other barriers block fuzzer progress.
---# 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.
**False positive risk:** MEDIUM - Deserialization must handle malformed data gracefully
## Advanced Usage
### Tips and Tricks
| Tip | Why It Helps |
|-----|--------------|
| Keep cheap validation | Magic bytes and size checks guide fuzzer without much cost |
| Use fixed seeds for PRNGs | Makes behavior deterministic while exploring all code paths |
| Patch incrementally | Skip one obstacle at a time and measure coverage impact |
| Add defensive defaults | When skipping validation, provide safe fallback values |
| Document all patches | Future maintainers need to understand fuzzing vs. production differences |
### Real-World Examples
**OpenSSL:** Uses `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` to modify cryptographic algorithm behavior. For example, in [crypto/cmp/cmp_vfy.c](https://github.com/openssl/openssl/blob/afb19f07aecc84998eeea56c4d65f5e0499abb5a/crypto/cmp/cmp_vfy.c#L665-L678), certain signature checks are relaxed during fuzzing to allow deeper exploration of certificate validation logic.
**ogg crate (Rust):** Uses `cfg!(fuzzing)` to [skip checksum verification](https://github.com/RustAudio/ogg/blob/5ee8316e6e907c24f6d7ec4b3a0ed6a6ce854cc1/src/reading.rs#L298-L300) during fuzzing. This allows the fuzzer to explore audio processing code without spending effort guessing correct checksums.
### Measuring Patch Effectiveness
After applying patches, quantify the improvement:
1. **Line coverage:** Use `llvm-cov` or `cargo-cov` to see new reachable lines
2. **Basic block coverage:** More fine-grained than line coverage
3. **Function coverage:** How many more functions are now reachable?
4. **Corpus size:** Does the fuzzer generate more diverse inputs?
Effective patches typically increase coverage by 10-50% or more.
### Combining with Other Techniques
Obstacle patching works well with:
- **Corpus seeding:** Provide valid inputs that get past initial parsing
- **Dictionaries:** Help fuzzer learn magic bytes and common values
- **Structure-aware fuzzing:** Use protobuf or grammar definitions for complex formats
- **Harness improvements:** Better harness can sometimes avoid obstacles entirely
## Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|--------------|---------|------------------|
| Skip all validation wholesale | Creates false positives and unstable fuzzing | Skip only specific obstacles that block coverage |
| No risk assessment | False positives waste time and hide real bugs | Analyze downstream code for assumptions |
| Forget to document patches | Future maintainers don't understand the differences | Add comments explaining why patch is safe |
| Patch without measuring | Don't know if it helped | Compare coverage before and after |
| Over-patching | Makes fuzzing build diverge too much from production | Minimize differences between builds |
## Tool-Specific Guidance
### libFuzzer
libFuzzer automatically defines `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` during compilation.
OpenSSL's fuzzing infrastructure demonstrates large-scale use of `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION`. The project uses this macro to modify cryptographic validation, certificate parsing, and other security-critical code paths to enable deeper fuzzing while maintaining production correctness.
**[LibFuzzer Documentation on Flags](https://llvm.org/docs/LibFuzzer.html)**
Official LLVM documentation for libFuzzer, including how the fuzzer defines compiler macros and how to use them effectively. Covers integration with sanitizers and coverage instrumentation.
Complete reference for Rust conditional compilation, including `cfg!(fuzzing)` and `cfg!(test)`. Explains compile-time vs. runtime conditional compilation and best practices.
