fuzzing-obstacles

fuzzing-obstacles

Catalogue généré le 2026-05-11

En une phrase

TechniquesRecueil forde patchingtechniques pour contourner les "blocages" qui empêchent un fuzzer d'avancer (checksums, horloges aléatoires, validations trop strictes) — en patchant temporairement le code topour overcomequ'il fuzzingdevienne obstacles."fuzzable".

Quand l'utiliser

• UseQuand when checksums, global state, or other barriers blockton fuzzer progress.stagne et ne trouve plus rien (la couverture ne grimpe plus).

Quand ton code vérifie un checksum (CRC, SHA) et rejette tout en entrée. Quand ton code utilise time() ou random() (résultat différent à chaque run = fuzzer perdu). Quand une validation très stricte bloque toutes les entrées du fuzzer. Quand ton code fait des requêtes réseau ou écrit dans une vraie base de données.

Comment l'invoquer

• Slash command : /fuzzing-obstacles (si exposé dans ton CLI)
• Phrases déclencheurs (texte) : voir"fuzzing lablocker", description"checksum complètebypass ci-dessousfor fuzzing", "anti-fuzzing patterns"
• Auto-invocation : surSur demande explicite

Description complètedétaillée

TechniquesPlein forde patchingprogrammes contiennent des patterns "anti-fuzzing" sans le faire exprès. Par exemple, un format de fichier vérifie son checksum avant traitement : le fuzzer doit deviner la bonne valeur du checksum pour chaque entrée mutée — astronomiquement improbable. Résultat : 99,99 % des entrées sont rejetées immédiatement et le fuzzer n'explore jamais le vrai code.

Autres obstacles classiques : du code toqui overcomedépend fuzzingde obstacles.l'horloge Usesystème when(time() checksums,renvoie globalune state,valeur ordifférente otherà barrierschaque blockexécution, donc le fuzzer progress.perd le sens du "même input = même résultat"), des générateurs aléatoires non-déterministes, des appels réseau, ou des validations cryptographiques très strictes. Tous ces patterns "cassent" la boucle de feedback du fuzzer.

La solution proposée par cette skill : la compilation conditionnelle. Tu ajoutes des #ifdef FUZZING autour des morceaux problématiques pour les désactiver uniquement quand on compile pour fuzzer. En production, le code reste 100 % normal. En fuzzing, les checksums sont court-circuités, l'horloge renvoie une valeur fixe, le random est seedé de façon déterministe. D'un coup, le fuzzer voit du progrès et trouve des bugs. C'est une technique reconnue, indispensable pour fuzzer du code "réel".

Pour aller plus loin

Overcoming

Pour Fuzzingles Obstaclesexemples

Codebasesconcrets, oftenoptions containde anti-fuzzingconfiguration et 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:

Checksums: The fuzzer must guess correct hash values (astronomically unlikely) Global state: Same input produces different behavior across runs (breaks determinism)

(extrait —avancés, voir le SKILL.md complet pour la suite)original.

Source

• Plugin : trailofbits/testing-handbook-skills
• Nom interne : fuzzing-obstacles
• Fichier : /home/thymon/.claude/plugins/cache/trailofbits/testing-handbook-skills/1.0.1/skills/fuzzing-obstacles/SKILL.md