Descripción general

what the fuzz o wtf es un fuzzer distribuido, guiado por cobertura de código, personalizable, basado en instantáneas y multiplataforma, diseñado para atacar objetivos en modo usuario y/o núcleo que se ejecuten en Microsoft Windows o Linux (experimental, consulte linux_mode). La ejecución del objetivo se puede realizar dentro de un emulador con bochscpu (el más lento, el más preciso), dentro de una máquina virtual de Windows con las APIs de la Plataforma de Hipervisor de Windows o dentro de una máquina virtual de Linux con las APIs de KVM (la más rápida).

Ha descubierto vulnerabilidades de corrupción de memoria en una amplia gama de software: IDA Pro, un popular juego AAA, el kernel de Windows, el cliente RDP de Microsoft, el controlador de pantalla GPU de NVIDIA, etc.

Los binarios compilados están disponibles tanto desde los artefactos de CI como desde la sección de Lanzamientos para Windows y Linux.

Si desea leer más sobre su historia o cómo usarlo en un objetivo real, recomiendo echar un vistazo a estas publicaciones para comenzar 🔥

• Construyendo un nuevo fuzzer de instantáneas y fuzzing de IDA
• Fuzzing de protocolos modernos de juegos UDP con fuzzers basados en instantáneas por Markus Gaasedelen
• Fuzzing de RDPEGFX con "what the fuzz" por Colas Le Guernic, Jérémy Rubert y Anonymous
• Un viaje al fuzzing de protocolos de red – Diseccionando el protocolo de cliente IMAP de Microsoft por Wayne Chin Yick Low
• La sección de Fuzzing de instantáneas del Manual de pruebas de Trail of Bits
• Atacando EDRs Parte 4: Fuzzing del motor de escaneo y emulación de Defender (mpengine.dll) por Manuel Feifel

Uso

La mejor manera de probar las características es trabajar con los módulos fuzzer_hevd / fuzzer_tlv_server. Puede descargar los archivos target-hevd.7z / target-tlv_server.7z y extraerlos en el directorio targets/. Los archivos contienen los árboles de directorios esperados para cada objetivo:

• inputs es la carpeta donde se colocan los casos de prueba de entrada,
• outputs es la carpeta donde se guardan los archivos del minset actual,
• coverage es la carpeta donde se espera que estén los archivos .cov,
• crashes es donde se guardan los fallos,
• state es donde se almacenan el volcado de memoria (mem.dmp), el estado de la CPU (regs.json) y el almacén de símbolos (symbol-store.json). El almacén de símbolos es un simple archivo JSON que se utiliza en sistemas Linux para saber dónde colocar puntos de interrupción, ya que no hay soporte para símbolos / dbgeng en esas plataformas. wtf genera este archivo en tiempo de ejecución cada vez que se ejecuta el objetivo en Windows.

Lo que sigue asume que ha descargado el archivo target-hevd.7z adjunto a la última versión y lo ha extraído en el directorio targets de su clon de wtf. Debería tener wtf/targets/hevd en el que encontrará los directorios inputs / outputs, etc.

Iniciando un nodo servidor

El servidor es básicamente el cerebro y realiza un seguimiento de todo el estado: la cobertura de código agregada, el corpus, genera y distribuye los casos de prueba al cliente.

Así es como podría elegir lanzar un nodo servidor local:```text wtf.exe master --name hevd --max_len=1028 --runs=10000000

La opción `max_len` se utiliza para limitar el tamaño del caso de prueba generado, `runs` es el número de casos de prueba que generará, `address` especifica dónde debe escuchar **wtf**, `target` es un directorio con el árbol de directorio que describimos anteriormente (el usuario también puede optar por sobrescribir esos directorios con `--input` / `--output` / `--crashes`) y `name` especifica el nombre de tu módulo de fuzzing para que el maestro pueda invocar tu función generadora si has definido una.

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

### Nodos de fuzzing

Los nodos cliente ejecutan un caso de prueba que ha sido generado y distribuido por el servidor y comunican el resultado de vuelta al servidor (cobertura de código, resultado, etc.).

Así es como iniciarías un nodo cliente que utiliza el backend *bochscpu*:

wtf client --address localhost:26001 --corpus /tmp/corpus --crashes /tmp/crashes

wtf.exe fuzz --name hevd --limit 10000000
```
El subcomando `fuzz` se utiliza con la opción `name` para especificar qué módulo de fuzzing debe usarse, `backend` especifica el backend de ejecución y `limit` el número máximo de instrucciones a ejecutar por caso de prueba (dependiendo del backend, esta opción tiene un significado diferente).

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

### Ejecutar un caso de prueba

Si desea ejecutar un caso de prueba (o una carpeta llena de casos de prueba), puede usar el subcomando `run`.

Así es como se ejecutaría el caso de prueba `crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0`:

```bash
$AFL_BASE/afl-fuzz -S secondary_instance -i /path/to/seeds -o output_dir ./program

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>

### Minseting a corpus

Para minset un corpus, necesitas usar un nodo servidor y tantos nodos cliente como necesites, igual que harías para un trabajo de fuzzing. Puedes simplemente establecer las opciones `runs` a 0.