Aperçu

what the fuzz ou wtf est un fuzzer distribué, guidé par la couverture de code, personnalisable, basé sur des instantanés, multiplateforme, conçu pour attaquer des cibles en mode utilisateur et/ou noyau s'exécutant sur Microsoft Windows ou Linux (expérimental, voir linux_mode). L'exécution de la cible peut se faire dans un émulateur avec bochscpu (le plus lent, le plus précis), dans une VM Windows avec les API Windows Hypervisor Platform ou dans une VM Linux avec les API KVM (le plus rapide).

Il a découvert des vulnérabilités de corruption mémoire dans un large éventail de logiciels : IDA Pro, un jeu AAA populaire, le noyau Windows, le client RDP Microsoft, le pilote d'affichage GPU NVIDIA, etc.

Les binaires compilés sont disponibles soit via les artefacts CI, soit dans la section Releases pour Windows et Linux.

Si vous souhaitez en savoir plus sur son histoire ou comment l'utiliser sur une cible réelle, je vous recommande de consulter ces articles pour commencer 🔥

• Construction d'un nouveau fuzzer par instantané et fuzzing d'IDA
• Fuzzing des protocoles de jeux UDP modernes avec des fuzzers par instantané par Markus Gaasedelen
• Fuzzing de RDPEGFX avec "what the fuzz" par Colas Le Guernic, Jérémy Rubert, et Anonymous
• Un voyage dans le fuzzing de protocoles réseau – Dissection du protocole client IMAP Microsoft par Wayne Chin Yick Low
• La section Snapshot Fuzzing du Testing Handbook de Trail Of Bits
• Attaquer les EDRs Partie 4 : Fuzzing du moteur d'analyse et d'émulation de Defender (mpengine.dll) par Manuel Feifel

Utilisation

La meilleure façon d'essayer les fonctionnalités est de travailler avec les modules fuzzer_hevd / fuzzer_tlv_server. Vous pouvez télécharger les archives target-hevd.7z / target-tlv_server.7z et les extraire dans le répertoire targets/. Les archives contiennent les arborescences de répertoires attendues pour chaque cible :

• inputs est le dossier où sont placés vos cas de test d'entrée,
• outputs est le dossier où sont sauvegardés les fichiers minset actuels,
• coverage est le dossier où les fichiers .cov doivent se trouver,
• crashes est le dossier où les crashes sont sauvegardés,
• state est le dossier où sont stockés le dump mémoire (mem.dmp), l'état du CPU (regs.json) et le magasin de symboles (symbol-store.json). Le magasin de symboles est un simple fichier JSON utilisé sur les systèmes Linux pour savoir où placer les points d'arrêt, car il n'y a pas de support pour les symboles / dbgeng sur ces plateformes. wtf génère ce fichier à l'exécution chaque fois que vous exécutez votre cible sur Windows.

Ce qui suit suppose que vous avez téléchargé le fichier target-hevd.7z joint à la dernière version, et que vous l'avez extrait dans le répertoire targets de votre clone de wtf. Vous devriez avoir wtf/targets/hevd dans lequel vous trouverez les répertoires inputs / outputs, etc.

Démarrage d'un nœud serveur

Le serveur est essentiellement le cerveau et garde la trace de tout l'état : la couverture de code agrégée, le corpus, il génère et distribue les cas de test au client.

Voici comment vous pourriez lancer un nœud serveur local :```text wtf.exe master --name hevd --max_len=1028 --runs=10000000

L'option `max_len` est utilisée pour limiter la taille du cas de test généré, `runs` est le nombre de cas de test qui seront générés, `address` spécifie où **wtf** doit écouter, `target` est un répertoire contenant l'arborescence de répertoires que nous avons décrite ci-dessus (l'utilisateur peut également choisir de remplacer ces répertoires avec `--input` / `--output` / `--crashes`) et `name` spécifie le nom de votre module de fuzzing afin que le maître puisse invoquer votre fonction génératrice si vous en avez défini une.

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

### Nœuds de fuzzing

Les nœuds clients exécutent un cas de test qui a été généré et distribué par le serveur et communiquent le résultat au serveur (couverture de code, résultat, etc.).

Voici comment démarrer un nœud client qui utilise le backend *bochscpu* :```text
wtf.exe fuzz --name hevd --limit 10000000

La sous-commande fuzz est utilisée avec l'option name pour spécifier quel module de fuzzing doit être utilisé, backend spécifie le backend d'exécution et limit le nombre maximum d'instructions à exécuter par testcase (selon le backend, cette option a une signification différente).

Exécution d'un test-case

Si vous souhaitez exécuter un test-case (ou un dossier rempli de test-cases), vous pouvez utiliser la sous-commande run.

Voici comment exécuter le test-case 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>

### Minset d'un corpus

Pour minseter un corpus, vous devez utiliser un nœud serveur et autant de nœuds clients que nécessaire, comme pour un job de fuzzing. Vous pouvez simplement définir l'option `runs` à 0.