fuzzing-obstacles

Patch code with conditional compilation to bypass checksums and validation blocking fuzzer coverage.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/TECH-HY/SKILLS --skill fuzzing-obstacles-tech-hy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fuzzing-obstacles
Source: https://github.com/TECH-HY/SKILLS/tree/main/skills/fuzzing-obstacles
Command: npx skills add https://github.com/TECH-HY/SKILLS --skill fuzzing-obstacles-tech-hy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Fuzzers often stall when code contains checksums, non-deterministic global state, or complex validation that rejects nearly all generated inputs, leaving large portions of the codebase unreachable and untested. ## Core Features & Use Cases - Conditional Compilation Patterns: Use FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION in C/C++ and cfg!(fuzzing) in Rust to bypass obstacles only during fuzzing builds while preserving production behavior. - Obstacle Identification Workflow: Analyze coverage reports to locate checksum verification, time-seeded PRNGs, and validation gates that block fuzzer progress. - False Positive Risk Management: Apply defensive defaults and partial validation instead of wholesale skipping to avoid crashes that cannot occur in production. - Use Case: A fuzzer targeting a message parser never gets past checksum verification. Patch the check with a conditional compilation guard, rebuild, and confirm coverage expands into the deserialization logic. ## Quick Start Ask the AI to identify what is blocking fuzzer coverage in your target and patch the checksum or validation check using conditional compilation for fuzzing builds.

Frequently Asked Questions about fuzzing-obstacles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I bypass checksum validation during fuzzing?

Wrap the checksum rejection path in a conditional compilation guard so it only runs in production builds. In C/C++ use #ifndef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, and in Rust use if !cfg!(fuzzing), letting the fuzzer reach code beyond the check.

What is FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION used for?

It is a preprocessor macro defined automatically by fuzzing compilers like libFuzzer and AFL++ wrappers. Code checks this macro to alter behavior during fuzzing builds, such as skipping hash verification, while keeping production binaries unchanged.

Does cargo-fuzz support conditional compilation in Rust?

Yes, cargo-fuzz automatically sets the fuzzing cfg option during cargo fuzz builds. Use cfg!(fuzzing) for runtime checks or #[cfg(fuzzing)] for compile-time conditional code; it is not set during regular cargo build.

Why does skipping validation cause false positive crashes in fuzzing?

Downstream code may assume validated properties, such as a nonzero field, so skipping validation creates states impossible in production. Mitigate this by providing safe default values during fuzzing instead of skipping the check entirely.

When should I not patch code to bypass fuzzing obstacles?

Avoid patching when a seed corpus, dictionary, or structure-aware fuzzer can overcome the obstacle, or when validation is simple enough for the fuzzer to learn. Also skip patching if it would introduce too many false positives.