fuzzing-obstacles

$2a

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

Skip this technique when:

• The obstacle can be overcome with a good seed corpus or dictionary

• The validation is simple enough for the fuzzer to learn (e.g., magic bytes)

• You're doing grammar-based or structure-aware fuzzing that handles validation

• Skipping the check would introduce too many false positives

• The code is already fuzzing-friendly

Quick Reference

Task

C/C++

Rust

Check if fuzzing build

#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

cfg!(fuzzing)

Skip check during fuzzing

#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION return -1; #endif

if !cfg!(fuzzing) { return Err(...) }

Common obstacles

Checksums, PRNGs, time-based logic

Checksums, PRNGs, time-based logic

Supported fuzzers

libFuzzer, AFL++, LibAFL, honggfuzz

cargo-fuzz, libFuzzer

Step-by-Step

Step 1: Identify the Obstacle

Run the fuzzer and analyze coverage to find code that's unreachable. Common patterns:

• Look for checksum/hash verification before deeper processing

• Check for calls to rand(), time(), or srand() with system seeds

• Find validation functions that reject most inputs

• Identify global state initialization that differs across runs

Tools to help:

• Coverage reports (see coverage-analysis technique)

• Profiling with -fprofile-instr-generate

• Manual code inspection of entry points

Step 2: Add Conditional Compilation

Modify the obstacle to bypass it during fuzzing builds.

C/C++ Example:

// Before: Hard obstacle

if (checksum != expected_hash) {

    return -1;  // Fuzzer never gets past here

}

// After: Conditional bypass

if (checksum != expected_hash) {

#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

    return -1;  // Only enforced in production

#endif

}

// Fuzzer can now explore code beyond this check

Rust Example:

// Before: Hard obstacle

if checksum != expected_hash {

    return Err(MyError::Hash);  // Fuzzer never gets past here

}

// After: Conditional bypass

if checksum != expected_hash {

    if !cfg!(fuzzing) {

        return Err(MyError::Hash);  // Only enforced in production

    }

}

// Fuzzer can now explore code beyond this check

Step 3: Verify Coverage Improvement

After patching:

• Rebuild with fuzzing instrumentation

• Run the fuzzer for a short time

• Compare coverage to the unpatched version

• Confirm new code paths are being explored

Step 4: Assess False Positive Risk

Consider whether skipping the check introduces impossible program states:

• Does code after the check assume validated properties?

• Could skipping validation cause crashes that cannot occur in production?

• Is there implicit state dependency?

If false positives are likely, consider a more targeted patch (see Common Patterns below).

Common Patterns

Pattern: Bypass Checksum Validation

Use Case: Hash/checksum blocks all fuzzer progress

Before:

uint32_t computed = hash_function(data, size);

if (computed != expected_checksum) {

    return ERROR_INVALID_HASH;

}

process_data(data, size);

After:

uint32_t computed = hash_function(data, size);

if (computed != expected_checksum) {

#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

    return ERROR_INVALID_HASH;

#endif

}

process_data(data, size);

False positive risk: LOW - If data processing doesn't depend on checksum correctness

Pattern: Deterministic PRNG Seeding

Use Case: Non-deterministic random state prevents reproducibility

Before:

void initialize() {

    srand(time(NULL));  // Different seed each run

}

After:

void initialize() {

#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

    srand(12345);  // Fixed seed for fuzzing

#else

    srand(time(NULL));

#endif

}

False positive risk: LOW - Fuzzer can explore all code paths with fixed seed

Pattern: Careful Validation Skip

Use Case: Validation must be skipped but downstream code has assumptions

Before (Dangerous):

#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

if (!validate_config(&config)) {

    return -1;  // Ensures config.x != 0

}

#endif

int32_t result = 100 / config.x;  // CRASH: Division by zero in fuzzing!

After (Safe):

#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

if (!validate_config(&config)) {

    return -1;

}

#else

// During fuzzing, use safe defaults for failed validation

if (!validate_config(&config)) {

    config.x = 1;  // Prevent division by zero

    config.y = 1;

}

#endif

int32_t result = 100 / config.x;  // Safe in both builds

False positive risk: MITIGATED - Provides safe defaults instead of skipping

Pattern: Bypass Complex Format Validation

Use Case: Multi-step validation makes valid input generation nearly impossible

Rust Example:

// Before: Multiple validation stages

pub fn parse_message(data: &#x26;[u8]) -> Result<Message, Error> {

    validate_magic_bytes(data)?;

    validate_structure(data)?;

    validate_checksums(data)?;

    validate_crypto_signature(data)?;

    deserialize_message(data)

}

// After: Skip expensive validation during fuzzing

pub fn parse_message(data: &#x26;[u8]) -> Result<Message, Error> {

    validate_magic_bytes(data)?;  // Keep cheap checks

    if !cfg!(fuzzing) {

        validate_structure(data)?;

        validate_checksums(data)?;

        validate_crypto_signature(data)?;

    }

    deserialize_message(data)

}

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, 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 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:

• Line coverage: Use llvm-cov or cargo-cov to see new reachable lines

• Basic block coverage: More fine-grained than line coverage

• Function coverage: How many more functions are now reachable?

• 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.

# C++ compilation

clang++ -g -fsanitize=fuzzer,address -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION \

    harness.cc target.cc -o fuzzer

# The macro is usually defined automatically by -fsanitize=fuzzer

clang++ -g -fsanitize=fuzzer,address harness.cc target.cc -o fuzzer

Integration tips:

• The macro is defined automatically; manual definition is usually unnecessary

• Use #ifdef to check for the macro

• Combine with sanitizers to detect bugs in newly reachable code

AFL++

AFL++ also defines FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION when using its compiler wrappers.

# Compilation with AFL++ wrappers

afl-clang-fast++ -g -fsanitize=address target.cc harness.cc -o fuzzer

# The macro is defined automatically by afl-clang-fast

Integration tips:

• Use afl-clang-fast or afl-clang-lto for automatic macro definition

• Persistent mode harnesses benefit most from obstacle patching

• Consider using AFL_LLVM_LAF_ALL for additional input-to-state transformations

honggfuzz

honggfuzz also supports the macro when building targets.

# Compilation

hfuzz-clang++ -g -fsanitize=address target.cc harness.cc -o fuzzer

Integration tips:

• Use hfuzz-clang or hfuzz-clang++ wrappers

• The macro is available for conditional compilation

• Combine with honggfuzz's feedback-driven fuzzing

cargo-fuzz (Rust)

cargo-fuzz automatically sets the fuzzing cfg option during builds.

# Build fuzz target (cfg!(fuzzing) is automatically set)

cargo fuzz build fuzz_target_name

# Run fuzz target

cargo fuzz run fuzz_target_name

Integration tips:

• Use cfg!(fuzzing) for runtime checks in production builds

• Use #[cfg(fuzzing)] for compile-time conditional compilation

• The fuzzing cfg is only set during cargo fuzz builds, not regular cargo build

• Can be manually enabled with RUSTFLAGS="--cfg fuzzing" for testing

LibAFL

LibAFL supports the C/C++ macro for targets written in C/C++.

# Compilation

clang++ -g -fsanitize=address -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION \

    target.cc -c -o target.o

Integration tips:

• Define the macro manually or use compiler flags

• Works the same as with libFuzzer

• Useful when building custom LibAFL-based fuzzers

Troubleshooting

Issue

Cause

Solution

Coverage doesn't improve after patching

Wrong obstacle identified

Profile execution to find actual bottleneck

Many false positive crashes

Downstream code has assumptions

Add defensive defaults or partial validation

Code compiles differently

Macro not defined in all build configs

Verify macro in all source files and dependencies

Fuzzer finds bugs in patched code

Patch introduced invalid states

Review patch for state invariants; consider safer approach

Can't reproduce production bugs

Build differences too large

Minimize patches; keep validation for state-critical checks

Related Skills

Tools That Use This Technique

Skill

How It Applies

libfuzzer

Defines FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION automatically

aflpp

Supports the macro via compiler wrappers

honggfuzz

Uses the macro for conditional compilation

cargo-fuzz

Sets cfg!(fuzzing) for Rust conditional compilation

Related Techniques

Skill

Relationship

fuzz-harness-writing

Better harnesses may avoid obstacles; patching enables deeper exploration

coverage-analysis

Use coverage to identify obstacles and measure patch effectiveness

corpus-seeding

Seed corpus can help overcome obstacles without patching

dictionary-generation

Dictionaries help with magic bytes but not checksums or complex validation

Resources

Key External Resources

OpenSSL Fuzzing Documentation

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

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.

Rust cfg Attribute Reference

Complete reference for Rust conditional compilation, including cfg!(fuzzing) and cfg!(test). Explains compile-time vs. runtime conditional compilation and best practices.