Visão Geral

what the fuzz ou wtf é um fuzzer distribuído, guiado por cobertura de código, customizável, multiplataforma e baseado em snapshots, projetado para atacar alvos em modo de usuário e/ou kernel executando no Microsoft Windows ou Linux (experimental, veja linux_mode). A execução do alvo pode ser feita dentro de um emulador com bochscpu (mais lento, mais preciso), dentro de uma VM Windows com as APIs do Windows Hypervisor Platform ou dentro de uma VM Linux com as APIs KVM (mais rápido).

Ele descobriu vulnerabilidades de corrupção de memória em uma ampla gama de softwares: IDA Pro, um jogo AAA popular, o kernel do Windows, o cliente Microsoft RDP, o driver de display NVIDIA GPU, etc.

Binários compilados estão disponíveis nos artefatos do CI ou na seção de Releases tanto para Windows quanto para Linux.

Se você quiser ler mais sobre sua história ou como usá-lo em um alvo real, recomendo dar uma olhada nestas postagens para começar 🔥

• Construindo um novo fuzzer de snapshot e fuzzeando IDA
• Fuzzeando protocolos modernos de jogos UDP com fuzzers baseados em snapshot por Markus Gaasedelen
• Fuzzeando RDPEGFX com "what the fuzz" por Colas Le Guernic, Jérémy Rubert e Anônimo
• Uma jornada para fuzzing de protocolo de rede – Dissecando o protocolo IMAP do Microsoft por Wayne Chin Yick Low
• A seção de Fuzzing de Snapshot do Manual de Testes da Trail Of Bits
• Atacando EDRs Parte 4: Fuzzeando o mecanismo de varredura e emulação do Defender (mpengine.dll) por Manuel Feifel

Uso

A melhor maneira de experimentar os recursos é trabalhar com os módulos fuzzer_hevd / fuzzer_tlv_server. Você pode baixar os arquivos target-hevd.7z / target-tlv_server.7z e extraí-los no diretório targets/. Os arquivos contêm as árvores de diretórios esperadas para cada alvo:

• inputs é a pasta onde seus casos de teste de entrada vão,
• outputs é a pasta onde os arquivos minset atuais são salvos,
• coverage é a pasta onde os arquivos .cov devem estar,
• crashes é onde as falhas são salvas,
• state é onde o dump de memória (mem.dmp), bem como o estado da CPU (regs.json) e o armazenamento de símbolos são armazenados (symbol-store.json). O armazenamento de símbolos é um arquivo JSON simples usado em sistemas Linux para saber onde colocar pontos de interrupção, já que não há suporte para símbolos/dbgeng nessas plataformas. wtf gera este arquivo em tempo de execução sempre que você executa seu alvo no Windows.

O que se segue assume que você baixou o arquivo target-hevd.7z anexado à versão mais recente e o extraiu no diretório targets do seu clone de wtf. Você deve ter wtf/targets/hevd onde encontrará os diretórios inputs / outputs, etc.

Iniciando um nó servidor

O servidor é basicamente o cérebro e mantém o controle de todo o estado: a cobertura de código agregada, o corpus, gera e distribui os casos de teste para o cliente.

É assim que você pode optar por iniciar um nó servidor local:```text wtf.exe master --name hevd --max_len=1028 --runs=10000000

A opção `max_len` é usada para limitar o tamanho do caso de teste gerado, `runs` é o número de casos de teste que serão gerados, `address` especifica onde o **wtf** precisa estar ouvindo, `target` é um diretório com a árvore de diretórios que descrevemos acima (o usuário também pode optar por substituir esses diretórios com `--input` / `--output` / `--crashes`) e `name` especifica o nome do seu  módulo de fuzzing para que o mestre possa invocar sua função geradora, se você tiver definido uma.

<p align='center'>
<img src="https://assets.kitploit.com/production/public/readmes/4699/4a03fc75eed3ed5a92f7f10def697dbf220ae36b0701f05b37759eb432fc0fd9.webp">
</p>

### Nós de fuzzing

Os nós clientes executam um caso de teste que foi gerado e distribuído pelo servidor e comunicam o resultado de volta ao servidor (cobertura de código, resultado, etc.).

É assim que você iniciaria um nó cliente que usa o backend *bochscpu*:```text
wtf.exe fuzz --name hevd --limit 10000000

O subcomando fuzz é usado com a opção name para especificar qual módulo fuzzer precisa ser usado, backend especifica o backend de execução e limit o número máximo de instruções a executar por caso de teste (dependendo do backend, esta opção tem significado diferente).

Executando um caso de teste

Se você quiser executar um caso de teste (ou uma pasta cheia de casos de teste), você pode usar o subcomando run.

É assim que você executaria o caso de teste crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0:``` wtf.exe run --name hevd --limit 10000000 --input crashes\crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0

<p align='center'>
<img src="https://assets.kitploit.com/production/public/readmes/4699/49b3ca8582d6314724e5615c687472499d5f8f41d04c9543c0a6a070c51f56f8.webp">
</p>

### Minimizando um corpus

Para minimizar um corpus, você precisa usar um nó servidor e quantos nós clientes forem necessários, como faria para um trabalho de fuzzing. Você pode simplesmente definir a opção `runs` para 0.

É assim que você minimizaria o corpus em `outputs` para o diretório `minset` (também destaca como você pode substituir os diretórios `inputs` e `outputs`):```
wtf.exe master --name hevd --max_len=1028 --runs=0 --inputs=outputs --outputs=minset

Gerando traços de execução