¿Qué hace Fuzzing Guiado por Cobertura?
Haz que el objetivo real se ejecute bajo retroalimentación, con el oráculo previsto y un ciclo de vida reproducible. Un binario de fuzzing en ejecución o un corpus en crecimiento no establece un alcance útil del objetivo: "El valor de corpus count es un mal indicador para verificar qué tan buena es la cobertura" (AFL++ Fuzzing in Depth §3.g).
Selecciona el carril real
Lee el punto de entrada del objetivo, el gráfico de compilación, las características habilitadas, el runtime/arquitectura, el decodificador y la propiedad. Identifica qué módulos objetivo reciben instrumentación y qué cambia bajo la compilación de fuzzing; un camino instrumentado solo para el driver o una característica habilitada solo en su envoltorio puede pasar por alto la implementación prevista. Las opciones de características de cargo-fuzz "controlan el crate fuzz_targets" hasta que se reenvían, y libFuzzer separa la instrumentación (-fsanitize=fuzzer-no-link) del enlace de su main() (Rust Fuzz Book guide, Cargo features, LLVM libFuzzer, Fuzzer Usage).
Usa el productor y el propietario de la compilación existentes y adecuados. Elige solo la referencia de ejecución aplicable:
| Objetivo | Leer |
|---|---|
| Código fuente/binario nativo, AFL++ o libFuzzer | Runners nativos |
| Go o Rust | Go y Rust |
| Extensiones Python/nativas o JVM | Python y JVM |
| Dominios de propiedades C++ con FuzzTest | C++ FuzzTest |
| Node.js (CJS, ESM, TypeScript mediante Jest) | Node.js con Jazzer.js |
El código de aplicación del navegador no tiene una ruta guiada por cobertura dentro del proceso: Jazzer.js considera "fuera de alcance" otros runtimes o soporte para navegadores (Jazzer.js architecture, Constraints). Dirige la exploración de UI del navegador a la habilidad que posee las secuencias de eventos de UI.
Verifica los requisitos previos de la versión seleccionada y la ayuda instalada antes de cambiar la configuración. Las referencias registran una instantánea de la fuente fechada, no una promesa de que cada versión/plataforma soporte las mismas banderas. Invoca dentro de la autoridad existente del usuario; esta habilidad no autoriza por sí misma instalaciones, ediciones del objetivo o gastos externos.
Ejecuta un piloto informativo finito
Establece el modo de descubrimiento, la instrumentación relevante del objetivo, el reinicio de estado y un oráculo funcional antes de añadir trabajadores. La reproducción de semillas en Go, la regresión de Jazzer, la regresión de Jest de Jazzer.js y el modo unitario de FuzzTest difieren de sus modos de descubrimiento: go test simple ejecuta semillas "muy parecido a una prueba unitaria", "Jazzer opera en modo de regresión a menos que el modo de fuzzing esté explícitamente habilitado", Jazzer.js bajo Jest usa por defecto "regression", y el modo unitario de FuzzTest se ejecuta "sin sanitizer ni instrumentación de cobertura" (Go fuzzing, Running fuzz tests, Jazzer README, Regression mode, Jazzer.js fuzzing settings, mode, FuzzTest Bazel quickstart, Create and run a fuzz test).
Observa la admisión del decodificador, la operación prevista, los efectos exitosos y las evaluaciones de propiedades por separado de la cobertura del motor; la mutación de bytes de un formato comprimido puede hacer que "virtualmente todas las entradas generadas sean inválidas para uncompress" (Google structure-aware fuzzing guide, Example: Compression). Diagnostica formatos rechazados, estado oculto o dependencias no satisfechas usando alcance, reinicio y retroalimentación. Selecciona retroalimentación de diccionario/comparación o mutación estructural contra un bloqueador demostrado; cada uno cambia una parte diferente de la búsqueda (AFL++ CmpLog, Google structure-aware fuzzing guide).
Mantén distintos los controles por entrada, tiempo de fuzzing, tiempo real, trabajador/CPU y memoria; incluye el costo de configuración/reproducción en el presupuesto autorizado. -V de AFL++ "¡es solo tiempo de fuzzing!" y -E es "un número aprox. de ejecuciones totales"; ninguno es CPU de proceso agregada (AFL++ selected-ref CLI source, usage text). -timeout de Go no limita la fase de fuzzing (Go y Rust). Usa salidas propias separadas y limpieza limitada de procesos propios; libFuzzer dice sobre rutas de artefacto exactas "No uses la misma ruta para varios procesos paralelos" (LLVM libFuzzer, Options). Consulta bugfinding-campaign para decisiones de asignación.
Interpreta y conserva la evidencia
Preserva la entrada exacta/argumentos tipados, la compilación/configuración/instrumentación, el estado inicial o la secuencia, el comando/límites, la salida cruda del motor, los contadores de objetivo/propiedad y el material de reproducción emitido. Las diferencias de estado entre invocaciones y de ciclo de vida pueden invalidar la reproducción en un solo archivo: Go requiere que "el estado de un objetivo de fuzzing no debe persistir más allá del final de cada llamada", y el PER_TEST por defecto de Jazzer tiene "más probabilidades de preservar involuntariamente el estado entre ejecuciones de fuzzing de prueba" (Go fuzzing, Suggestions, Jazzer Lifecycle implementation).
Devuelve lo que realmente se ejecutó, la propiedad observada, el uso de recursos, los candidatos y las omisiones. Distingue el descubrimiento de la regresión, la cobertura del alcance semántico, y el fallo candidato de la atribución al producto. Usa corpus-evolution para el intercambio/retención compatible, failure-reduction para la reducción que preserva la evidencia y evidence-based-triage para la atribución. Los resultados históricos de selección de semillas dependen de su objetivo/planificador; Rebert et al. encontraron una hipótesis "falsa bajo la planificación óptima" pero la probaron de nuevo bajo Round-Robin. No los conviertas en promesas universales de rendimiento o rendimiento (Rebert et al., pp.864,871,873).
Para ejecuciones engañosas concretas y correcciones, lee errores comunes. De esta habilidad no se sigue ningún nuevo framework específico del objetivo.