Fuzzing guiado por cobertura
Faça o alvo real executar sob feedback, com o oráculo pretendido e um ciclo de vida reprodutível. Um binário de fuzzing em execução ou um corpus crescente não estabelece alcance útil do alvo: "O valor de corpus count é um indicador ruim para verificar quão boa é a cobertura" (AFL++ Fuzzing in Depth §3.g).
Selecione a pista real
Leia o ponto de entrada do alvo, grafo de construção, funcionalidades habilitadas, tempo de execução/arquitetura, decodificador e propriedade. Identifique quais módulos alvo recebem instrumentação e o que muda sob a construção de fuzzing; um caminho instrumentado apenas pelo driver ou uma funcionalidade habilitada apenas em seu wrapper pode perder a implementação pretendida. As opções de funcionalidade do cargo-fuzz "controlam o crate fuzz_targets" até serem encaminhadas, e o libFuzzer separa a instrumentação (-fsanitize=fuzzer-no-link) da vinculação de seu main() (Rust Fuzz Book guide, Cargo features, LLVM libFuzzer, Fuzzer Usage).
Use o produtor e o proprietário da construção existentes e adequados. Escolha apenas a referência de execução aplicável:
| Alvo | Leia |
|---|---|
| Código nativo/binário, AFL++ ou libFuzzer | Executores nativos |
| Go ou Rust | Go e Rust |
| Extensões Python/nativas ou JVM | Python e JVM |
| Domínios de propriedade C++ com FuzzTest | C++ FuzzTest |
| Node.js (CJS, ESM, TypeScript via Jest) | Node.js com Jazzer.js |
Código de aplicativo no navegador não possui rota de cobertura dentro do processo: Jazzer.js coloca "Outros runtimes ou suporte para navegador" fora do escopo (Jazzer.js architecture, Constraints). Roteie a exploração de interface do navegador para a skill que gerencia sequências de eventos de UI.
Verifique os pré-requisitos e a ajuda instalada da versão selecionada antes de alterar a configuração. As referências registram um snapshot de origem datado, não uma promessa de que toda versão/plataforma suporta as mesmas flags. Invoke dentro da autoridade existente do usuário; esta skill não autoriza instalações, edições de alvo ou gastos externos.
Execute um piloto informativo finito
Estabeleça o modo de descoberta, a instrumentação do alvo relevante, a reinicialização de estado e um oráculo funcional antes de adicionar workers. A reprodução de seed do Go, a regressão do Jazzer, a regressão do Jest do Jazzer.js e o modo de unidade do FuzzTest diferem de seus modos de descoberta: go test simples executa seeds "muito parecido com um teste de unidade", "Jazzer opera em modo de regressão a menos que o modo de fuzzing esteja explicitamente habilitado", Jazzer.js no padrão do Jest é "regression", e o modo de unidade do FuzzTest executa "sem sanitizer e instrumentação 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).
Observe a admissão do decodificador, operação pretendida, efeitos bem-sucedidos e avaliações de propriedade separadamente da cobertura do motor; a mutação de byte de um formato comprimido pode deixar "virtualmente todas as entradas geradas inválidas para uncompress" (Google structure-aware fuzzing guide, Example: Compression). Diagnostique formatos rejeitados, estado oculto ou dependências não atendidas usando alcance, reinicialização e feedback. Selecione feedback de dicionário/comparação ou mutação estrutural contra um bloqueador demonstrado; cada um altera uma parte diferente da busca (AFL++ CmpLog, Google structure-aware fuzzing guide).
Mantenha os controles por entrada, tempo de fuzzing, tempo real, worker/CPU e memória distintos; inclua o custo de configuração/repetição no envelope autorizado. AFL++ -V é "(somente tempo de fuzzing!)" e -E é "um número aproximado de execuções totais"; nenhum é tempo de CPU agregado do processo (AFL++ selected-ref CLI source, usage text). Go -timeout não limita a fase de fuzzing (Go and Rust). Use saídas próprias separadas e limpeza limitada de processos próprios; libFuzzer diz sobre caminhos exatos de artefatos "Não use o mesmo caminho para vários processos paralelos" (LLVM libFuzzer, Options). Consulte bugfinding-campaign para decisões de alocação.
Interprete e retenha evidências
Preserve exatamente a entrada/argumentos tipados, construção/configuração/instrumentação, estado inicial ou sequência, comando/limites, saída bruta do motor, contadores de alvo/propriedade e material de repetição emitido. O estado entre invocações e as diferenças de ciclo de vida podem invalidar a reprodução em um único arquivo: Go exige que "o estado de um alvo de fuzzing não deve persistir além do final de cada chamada", e o padrão PER_TEST do Jazzer é "mais propenso a preservar estado não intencionalmente entre execuções de teste de fuzzing" (Go fuzzing, Suggestions, Jazzer Lifecycle implementation).
Retorne o que realmente executou, a propriedade observada, o uso de recursos, candidatos e omissões. Distinga descoberta de regressão, cobertura de alcance semântico e falha candidata de atribuição de produto. Use corpus-evolution para retenção/troca compatível, failure-reduction para redução preservando testemunhas e evidence-based-triage para atribuição. Resultados históricos de seleção de sementes dependem de seu alvo/escalonador; Rebert et al. encontraram uma hipótese "falsa sob o escalonamento ótimo" mas a testaram novamente sob Round-Robin. Não os transforme em promessas universais de vazão ou rendimento (Rebert et al., pp.864,871,873).
Para execuções concretas enganosas e correções, leia erros comuns. Nenhum novo framework específico para alvo decorre desta skill.