fuzzing-obstacles

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

代码库通常包含阻碍有效覆盖的反模糊测试模式。校验和、全局状态（如基于时间种子的PRNG）以及验证检查可能会阻止模糊测试工具探索更深层的代码路径。本技术展示了如何修改被测系统（SUT）的代码，在模糊测试期间绕过这些障碍，同时保留生产环境中的行为。

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:

Checksums: The fuzzer must guess correct hash values (astronomically unlikely)
Global state: Same input produces different behavior across runs (breaks determinism)
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)

概念	描述
SUT修补	修改被测系统以使其更适合模糊测试
条件编译	根据编译时标记表现出不同行为的代码
模糊测试构建模式	启用模糊测试特定修补的特殊构建配置
误报	模糊测试中发现的、在生产环境中不会出现的崩溃
确定性	相同输入始终产生相同行为（对模糊测试至关重要）

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

任务	C/C++	Rust
检查是否为模糊测试构建	`#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION`	`cfg!(fuzzing)`
模糊测试期间跳过检查	`#ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION return -1; #endif`	`if !cfg!(fuzzing) { return Err(...) }`
常见障碍	校验和、PRNG、基于时间的逻辑	校验和、PRNG、基于时间的逻辑
支持的模糊测试工具	libFuzzer、AFL++、LibAFL、honggfuzz	cargo-fuzz、libFuzzer

Step-by-Step

分步指南

Step 1: Identify the Obstacle

步骤1：识别障碍

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

运行模糊测试工具并分析覆盖率，找出无法访问的代码。常见模式：

查找在深层处理前的校验和/哈希验证逻辑
检查对
```
rand()
```
、
```
time()
```
或带系统种子的
```
srand()
```
的调用
找出拒绝大多数输入的验证函数
识别在不同运行中初始化不同的全局状态

辅助工具：

覆盖率报告（参见覆盖率分析技术）
使用
```
-fprofile-instr-generate
```
进行性能分析
手动检查入口点代码

Step 2: Add Conditional Compilation

步骤2：添加条件编译

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:

rust

// 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

修改障碍逻辑，使其在模糊测试构建期间绕过检查。

C/C++示例：

// 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示例：

rust

// 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

步骤3：验证覆盖率提升

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

步骤4：评估误报风险

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

适用场景： 哈希/校验和完全阻碍模糊测试工具推进

之前：

uint32_t computed = hash_function(data, size);
if (computed != expected_checksum) {
    return ERROR_INVALID_HASH;
}
process_data(data, size);

之后：

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);

误报风险： 低 - 如果数据处理不依赖校验和的正确性

Pattern: Deterministic PRNG Seeding

模式：确定性PRNG种子

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

适用场景： 非确定性随机状态导致无法复现问题

之前：

void initialize() {
    srand(time(NULL));  // Different seed each run
}

之后：

void initialize() {
#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION
    srand(12345);  // Fixed seed for fuzzing
#else
    srand(time(NULL));
#endif
}

误报风险： 低 - 模糊测试工具可使用固定种子探索所有代码路径

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

适用场景： 必须跳过验证，但下游代码存在假设

之前（危险）：

#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!

之后（安全）：

#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

误报风险： 已缓解 - 提供安全默认值而非直接跳过

Pattern: Bypass Complex Format Validation

模式：绕过复杂格式验证

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

Rust Example:

rust

// Before: Multiple validation stages
pub fn parse_message(data: &[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: &[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

适用场景： 多阶段验证使生成有效输入几乎不可能

Rust示例：

rust

// Before: Multiple validation stages
pub fn parse_message(data: &[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: &[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)
}

误报风险： 中 - 反序列化必须能优雅处理格式错误的数据

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

技巧	作用
保留低成本验证	魔术字节和大小检查可引导模糊测试工具，且开销不大
为PRNG使用固定种子	使行为具有确定性，同时探索所有代码路径
增量修补	一次跳过一个障碍，衡量覆盖率影响
添加防御性默认值	跳过验证时提供安全的回退值
记录所有修补	后续维护者需要了解模糊测试与生产环境的差异

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.

OpenSSL： 使用

FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

修改加密算法行为。例如，在crypto/cmp/cmp_vfy.c中，模糊测试期间会放宽某些签名检查，以允许更深入地探索证书验证逻辑。

ogg crate（Rust）： 使用

cfg!(fuzzing)

在模糊测试期间跳过校验和验证。这使模糊测试工具无需花费精力猜测正确的校验和，即可探索音频处理代码。

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.

应用修补后，量化改进程度：

行覆盖率： 使用
```
llvm-cov
```
或
```
cargo-cov
```
查看新增的可访问行
基本块覆盖率： 比行覆盖率更细粒度
函数覆盖率： 现在可访问的函数增加了多少？
语料库大小： 模糊测试工具是否生成了更多样化的输入？

有效的修补通常可使覆盖率提升10-50%甚至更多。

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

障碍修补可与以下技术配合使用：

语料库播种： 提供可通过初始解析的有效输入
字典： 帮助模糊测试工具学习魔术字节和常见值
结构感知模糊测试： 对复杂格式使用protobuf或语法定义
测试套改进： 更好的测试套有时可完全避免障碍

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.

bash

undefined

libFuzzer在编译期间自动定义

FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

。

bash

undefined

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

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


**集成技巧：**
- 宏会自动定义，通常无需手动定义
- 使用`#ifdef`检查宏
- 与 sanitizer 结合以检测新可访问代码中的漏洞

AFL++

AFL++ also defines

FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

when using its compiler wrappers.

bash

undefined

AFL++在使用其编译器包装器时也会定义

FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

。

bash

undefined

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


**集成技巧：**
- 使用`afl-clang-fast`或`afl-clang-lto`自动定义宏
- 持久模式测试套从障碍修补中获益最多
- 考虑使用`AFL_LLVM_LAF_ALL`进行额外的输入到状态转换

honggfuzz

honggfuzz also supports the macro when building targets.

bash

undefined

honggfuzz在构建目标时也支持该宏。

bash

undefined

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

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


**集成技巧：**
- 使用`hfuzz-clang`或`hfuzz-clang++`包装器
- 宏可用于条件编译
- 与honggfuzz的反馈驱动模糊测试结合使用

cargo-fuzz (Rust)

cargo-fuzz automatically sets the

fuzzing

cfg option during builds.

bash

undefined

cargo-fuzz在构建期间自动设置

fuzzing

cfg选项。

bash

undefined

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

cargo fuzz run fuzz_target_name


**集成技巧：**
- 在生产构建中使用`cfg!(fuzzing)`进行运行时检查
- 使用`#[cfg(fuzzing)]`进行编译时条件编译
- `fuzzing` cfg仅在`cargo fuzz`构建中设置，常规`cargo build`中不设置
- 可通过`RUSTFLAGS="--cfg fuzzing"`手动启用以进行测试

LibAFL

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

bash

undefined

LibAFL对C/C++编写的目标支持该宏。

bash

undefined

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

clang++ -g -fsanitize=address -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION
target.cc -c -o target.o


**集成技巧：**
- 手动定义宏或使用编译器标记
- 与libFuzzer的使用方式相同
- 在构建自定义基于LibAFL的模糊测试工具时很有用

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

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

技术	应用方式
libfuzzer	自动定义 `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION`
aflpp	通过编译器包装器支持该宏
honggfuzz	使用该宏进行条件编译
cargo-fuzz	为Rust条件编译设置 `cfg!(fuzzing)`

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

技术	关系
fuzz-harness-writing	更好的测试套可避免障碍；修补可实现更深层次的探索
coverage-analysis	使用覆盖率识别障碍并衡量修补效果
corpus-seeding	种子语料库可帮助无需修补即可克服障碍
dictionary-generation	字典有助于处理魔术字节，但无法解决校验和或复杂验证问题

主要外部资源

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.

OpenSSL模糊测试文档 OpenSSL的模糊测试基础设施展示了

FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION

的大规模应用。该项目使用此宏修改加密验证、证书解析和其他安全关键代码路径，以实现更深入的模糊测试，同时保持生产环境的正确性。

LibFuzzer标记文档 LLVM官方的libFuzzer文档，包括模糊测试工具如何定义编译器宏以及如何有效使用它们。涵盖与sanitizer和覆盖率插桩的集成。

Rust cfg属性参考 Rust条件编译的完整参考，包括

cfg!(fuzzing)

和

cfg!(test)

。解释编译时与运行时条件编译的区别及最佳实践。

fuzzing-obstacles

Original

Translation

Overcoming Fuzzing Obstacles

克服模糊测试障碍

Overview

概述

Key Concepts

核心概念

When to Apply

适用场景

Quick Reference

快速参考

Step-by-Step

分步指南

Step 1: Identify the Obstacle

步骤1：识别障碍

Step 2: Add Conditional Compilation

步骤2：添加条件编译

Step 3: Verify Coverage Improvement

步骤3：验证覆盖率提升

Step 4: Assess False Positive Risk

步骤4：评估误报风险

Common Patterns

常见模式

Pattern: Bypass Checksum Validation

模式：绕过校验和验证

Pattern: Deterministic PRNG Seeding

模式：确定性PRNG种子

Pattern: Careful Validation Skip

模式：谨慎跳过验证

Pattern: Bypass Complex Format Validation

模式：绕过复杂格式验证

Advanced Usage

高级用法

Tips and Tricks

技巧与窍门

Real-World Examples

实际案例

Measuring Patch Effectiveness

衡量修补效果

Combining with Other Techniques

与其他技术结合

Anti-Patterns

反模式

Tool-Specific Guidance

工具特定指南

libFuzzer

libFuzzer

C++ compilation

C++ compilation

The macro is usually defined automatically by -fsanitize=fuzzer

The macro is usually defined automatically by -fsanitize=fuzzer

AFL++

AFL++

Compilation with AFL++ wrappers

Compilation with AFL++ wrappers

The macro is defined automatically by afl-clang-fast

The macro is defined automatically by afl-clang-fast

honggfuzz

honggfuzz

Compilation

Compilation

cargo-fuzz (Rust)

cargo-fuzz (Rust)

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

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

Run fuzz target

Run fuzz target

LibAFL

LibAFL

Compilation

Compilation

Troubleshooting

故障排除

Related Skills

相关技术

Tools That Use This Technique

使用本技术的工具

Related Techniques