Ceci est une cible locale simple qu'AFL++ est parfaitement capable de traiter et donnée rapidement en exemple. Litefuzz a été conçu pour faire bien plus en matière de fuzzing réseau et GUI, ce que vous verrez une fois que vous plongerez dedans.

## pourquoi

Oui, un autre fuzzer et qui ne suit pas très bien les tendances et conventions actuelles. Des compromis ont été faits pour répondre à certaines exigences. Ces exigences étant un fuzzer qui fonctionne par défaut sur plusieurs plateformes, qui fuzze à la fois des cibles locales et réseau et qui est très facile à utiliser. Il ne s'agit pas de convaincre qui que ce soit, mais fournissons un peu de contexte. Certaines cibles demandent beaucoup d'efforts pour intégrer des fuzzers comme AFL dans la chaîne de construction. Ce n'est pas un problème car ce fuzzer ne nécessite pas d'instrumentation, sacrifiant la couverture précise obtenue par l'instrumentation pour la facilité et la portabilité. AFL ne supporte pas non plus le fuzzing réseau prêt à l'emploi, et bien qu'il existe des projets basés sur lui qui le font, ils sont loin d'être simples à utiliser et nécessitent généralement plus de modifications de code et de harnais pour fonctionner (histoire similaire avec [Libfuzzer](https://llvm.org/docs/LibFuzzer.html)).

Il ne fait pas de fuzzing parallèle, ni ne supporte des améliorations de vitesse fulgurantes comme celles que [le mode persistant](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) peut offrir, donc il ne peut pas s'approcher de l'échelle des fuzzers dotés de telles capacités. Encore une fois, ce n'est pas un fuzzer de pointe. Mais il ne nécessite pas de code source, de configurer correctement une compilation ou certaines fonctionnalités du système d'exploitation. Il peut même fuzzer certaines GUI de clients réseau et des applications interactives. Il se contente des ressources existantes de nombreuses manières et de nombreuses fonctionnalités comme les mutateurs et la minimisation ont été écrites de zéro.

Il a été conçu pour "fonctionner simplement" et des efforts ont été consacrés à l'automatisation de la configuration et de l'installation pour les quelques dépendances dont il a besoin. Ce fuzzer a été écrit pour servir un but, apporter de la valeur dans de nombreux scénarios et environnements cibles différents et surtout ce pour quoi tous les fuzzers devraient être jugés en fin de compte : la capacité à trouver des bugs. Et **il trouve** des [bugs](https://github.com/sec-tools/beta/blob/main/README.md#trophies). Il ne suppose pas qu'il y a du code source cible, donc il peut couvrir assez bien les logiciels propriétaires. Il peut fonctionner dans le cadre d'une automatisation avec peu de modifications, mais il est conçu pour être amusant à utiliser pour les chercheurs en vulnérabilités. Il est cependant plus utile de le considérer comme un projet de R&D plutôt que comme un produit complet. De plus, il n'y a pas de configuration compliquée où il est légèrement cassé dès la sortie de la boîte ou nécessite plus de travail pour le faire fonctionner sur les systèmes d'exploitation modernes.

Il a été testé fonctionnel sur Ubuntu Linux, Mac et Windows et est livré avec des scripts entièrement fonctionnels qui font presque tout pour vous afin de configurer un environnement prêt à fuzzer.

> **Une fois le script de configuration terminé, il ne faut que quelques minutes pour commencer à fuzzer une multitude de cibles différentes.**

## comment ça marche

**Litefuzz supporte trois modes différents : local, client et serveur.**

Local signifie cibler des binaires locaux, qui sous Linux/Mac sont lancés via un sous-processus avec un support de triage automatique GDB et LLDB respectivement sur les crashes et via [WinAppDbg](https://github.com/MarioVilas/winappdbg) sous Windows. Les crashes sont écrits dans un répertoire de crash local et triés par type d'erreur, tels que les AVs de lecture/écriture ou SIGABRT/SIGSEGV ainsi que les hachages des fichiers. Tous les crashes uniques sont triés pendant qu'il fuzze et ces données avec la sortie de la cible (si disponible) sont également capturées et placées comme artefacts dans le même répertoire. Il est également possible de rejouer les crashes avec `--replay` en fournissant le fichier crashé. En mode client `local`, le répertoire d'entrée doit contenir un message de bienvenue du serveur, une réponse ou autre donnée qu'un client attendrait lors de la connexion à un serveur.

Pour l'instant, un seul "tir" est implémenté pour le fuzzing réseau sans support de session complexe. Le client est lancé via la ligne de commande et débogué de la même manière que lors du fuzzing de fichiers. Un écouteur est configuré pour supporter ce scénario, oui c'est un travail lent et à la limite du manuel mais cela fonctionne. Si un crash est détecté, il est rejoué dans gdb pour obtenir les détails du triage. En mode client `remote`, cela fonctionne de la même manière sauf qu'il n'y a pas de débogage/triage de crash local. En mode serveur *local*, c'est similaire au mode client local et pour le mode serveur `remote`, il se connecte simplement à une cible spécifiée et envoie des données client mutées que l'utilisateur spécifie comme entrées, mais seul un triage simple "pouvons-nous encore nous connecter, sinon il a probablement crashé sur le dernier" est fourni.

Il y a quelques fonctions de mutation écrites de zéro qui font principalement des mutations aléatoires avec une sélection aléatoire d'entrées spécifiées par le drapeau `-i`. Pour le fuzzing de fichiers, sélectionnez simplement le mode local et passez-lui la ligne de commande cible avec FUZZ indiquant où l'application s'attend à trouver le nom de fichier à analyser, par ex. `tcpdump -r FUZZ` ainsi qu'un répertoire d'entrée de "bons fichiers" à muter. Pour le fuzzing de clients réseau, c'est similaire au fuzzing local, mais fournissez également les spécificités de connexion via `-a`. Et si vous voulez fuzzer des serveurs, faites le mode serveur et fournissez un `protocol://address:port` comme pour les clients.

Il fuzze aussi vite que la cible peut consommer les données et sortir, comme c'est le cas pour la plupart des applications CLI ou aussi longtemps que vous avez déterminé qu'il le faut avant que l'exécution locale ou la connexion réseau expire, ce qui peut être beaucoup plus lent. Pas de tours de passe-passe exec ou de noyau ici. Mais bien sûr si vous écrivez un harnais qui analyse l'entrée et sort rapidement, couvrant une partie spécifique de la cible, cela aide aussi. Mais à ce stade, si vous pouvez vous approcher autant de la cible, vous feriez probablement mieux d'utiliser [le mode persistant](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) ou des fonctionnalités similaires que d'autres fuzzers peuvent offrir.

En bref...

### ce qu'il fait
- fonctionne sur linux, windows et mac et supporte py2/py3
- fuzze des binaires CLI/GUI qui lisent depuis des fichiers/stdin
- fuzze des clients et serveurs réseau, open source ou propriétaires, disponibles pour débogage local ou distant
- diff, minimisation, rejeu, tri et auto-triaging des crashes
- trucs divers comme le support TLS, le fuzzing de binaires golang et quelques extras pour Mac
- mute l'entrée avec divers mutateurs intégrés + pyradamsa (Linux)

### ce qu'il ne fait pas
- instrumentation native
- passer à l'échelle avec des jobs concurrents
- fuzzing de session complexe
- surveillance à distance des clients et serveurs (seulement des vérifications de base, ex. connexion)

## prise en charge

Principalement testé sur **Ubuntu Linux 20.04** (22.04 et 21.04 légèrement testés), **Windows 10** et **Mac OS 11** (12 légèrement testé). Le fuzzer et les scripts de configuration peuvent fonctionner sur des versions légèrement plus anciennes ou plus récentes de ces systèmes d'exploitation également, mais la majorité de la recherche, des tests et du développement a eu lieu dans ces environnements. Python3 est supporté et un effort a été fait pour rendre le code compatible avec Python2 également car c'est nécessaire pour le fuzzing sous Windows via [WinAppDbg](https://github.com/MarioVilas/winappdbg).

Les tests de plateforme ont principalement eu lieu sur du matériel Intel, mais les choses semblent fonctionner pour la plupart sur la plateforme M1 d'Apple aussi (exceptions notables étant que sous Linux le plugin exploitable pour GDB n'est probablement pas supporté, ni Pyradamsa). Il y a aussi des scripts de configuration dans setup/ pour automatiser la plupart ou la totalité des tâches et l'installation des dépendances. Il peut généralement fuzzer des binaires natifs sur chaque plateforme, qui sont souvent compilés en C/C++, mais il attrape aussi des crashes pour les binaires Golang (expérimental).

### versions de python

Python3 est supporté pour Linux et Mac tandis que Python2 est requis pour Windows.

Pourquoi Py3 pour Linux et Mac ? Pyautogui, Pyradamsa (Linux uniquement), meilleur support socket sur Mac.

Pourquoi Py2 pour Windows ? Winappdbg nécessite Py2.

### linux

GDB pour le débogage et [exploitable](https://github.com/jfoote/exploitable) pour le triage des crashes. Si c'est un logiciel open source, vous pouvez construire et instrumenter la cible avec [des sanitizers](https://fuzzing-project.org/tutorial2.html) et autres, sinon il y a [des débogueurs mémoire](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption) que nous pouvons charger à l'exécution.

Cette installation, ainsi que les dépendances python et autres éléments utiles, a été automatisée avec [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/linux.sh). Le système d'exploitation recommandé est Ubuntu 20.04 car c'est là où la majorité des tests ont eu lieu.

### mac

Au lieu de gdb, nous utilisons lldb pour le débogage sur OS X car il est inclus avec les outils en ligne de commande XCode. Être administrateur ou dans le groupe développeur devrait vous permettre d'utiliser lldb, mais ce comportement peut différer selon les environnements et versions et vous devrez peut-être l'exécuter avec les privilèges sudo si tout échoue.

La seule chose que vous devrez faire manuellement est de désactiver SIP (en recovery, via cmd+R ou utilisez des astuces vmware fusion). Sinon, l'auto-tri échouera lors du fuzzing sur l'OS de Tim Apple.

Presque toute la configuration a été automatisée avec le script [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/mac.sh), vous pouvez donc simplement l'exécuter pour un démarrage rapide.

### windows

[WinAppDbg](https://github.com/MarioVilas/winappdbg) est utilisé pour le débogage sous Windows avec la légère réserve que le fuzzing stdin n'est pas supporté.

Comme les configurations automatisées pour les autres systèmes d'exploitation, chocolatey aide à automatiser l'installation des paquets sous Windows. Exécutez [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/windows.bat) dans le répertoire racine de litefuzz en tant qu'Administrateur pour automatiser les installations. Cela installera les outils de débogage et autres dépendances pour que les choses se passent bien.

### cibles

Ceci est une liste des types de cibles qui ont été testés et sont généralement supportés.

* Applications CLI/GUI locales qui analysent des formats de fichiers ou stdin
  - support de débogage
* Client réseau CLI/GUI local qui analyse les réponses du serveur
  - support de débogage pour les CLI
  - support de débogage limité pour les GUI
* Serveur réseau CLI local qui analyse les requêtes client
  - support de débogage (attention : doit pouvoir s'exécuter en tant qu'exécutable autonome, sinon peut être traité comme *distant*)
* Serveur réseau GUI local qui analyse les requêtes client
  - théoriquement supporté, non testé
* Client réseau CLI/GUI distant qui analyse les réponses du serveur
  - aucun support de débogage
* Serveur réseau CLI/GUI distant qui analyse les requêtes client
  - aucun support de débogage
  - exception sur Mac avec l'utilisation des fonctionnalités `attach` ou `reportcrash`

Encore une fois, le fuzzer peut s'exécuter et supporter des applications, clients et serveurs locaux sur Linux, Mac et Windows et bien sûr peut fuzzer des éléments distants indépendamment de la plateforme cible.

### triage

* Applications CLI/GUI locales qui analysent des formats de fichiers ou stdin
  - exécuter l'application, attraper les signaux, reproduire en l'exécutant à nouveau dans un débogueur avec le crashé
* Client réseau CLI/GUI local qui analyse les réponses du serveur
  - exécuter l'application, attraper les signaux, reproduire en l'exécutant à nouveau dans un débogueur avec le crashé
* Serveur réseau GUI/CLI local qui analyse les requêtes client
  - exécuter l'application dans un débogueur, attraper les signaux, reproduire en l'exécutant à nouveau dans un débogueur avec le crashé
* Client réseau CLI/GUI distant qui analyse les réponses du serveur
  - aucune visibilité, collecter les crashes depuis le côté distant
  - peut écrire manuellement des scripts de support pour aider au triage
* Serveur réseau CLI/GUI distant qui analyse les requêtes client
  - aucune visibilité, collecter les crashes depuis le côté distant
  - peut écrire manuellement des scripts de support pour aider au triage
  - exception sur Mac avec les options `attach` et `reportcrash`, qui peuvent être utilisées pour activer certaines capacités de triage

## pour commencer

La plupart de la configuration sur les différentes plateformes a été automatisée avec les scripts dans le répertoire [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup).

Exécutez-les simplement depuis la racine de litefuzz et cela devrait vous faire gagner beaucoup de temps et aider à activer une partie de ce qui est nécessaire pour les déploiements automatisés. Il est utile d'utiliser une VM pour configurer un OS propre et un environnement de fuzzing car, entre autres, ses capacités d'instantané sont pratiques.

Voir [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md) pour les détails.

> **Après l'installation, référez-vous à l'exemple de fuzzing de latex2rtf dans la section initiale pour un démarrage rapide ou plongez dans toutes les options de ligne de commande et d'autres exemples détaillés dans ce README.**

### docker

Vous pouvez exécuter litefuzz en utilisant Docker avec le `Dockerfile` sans installer de dépendances localement. C'est particulièrement utile pour des tests rapides ou si vous voulez éviter d'installer des dépendances sur votre système.

Le Dockerfile fonctionne à la fois :
- **Depuis le dépôt** - Utilise les fichiers locaux (plus rapide, inclut les modifications locales)
- **Autonome** - Peut être construit depuis n'importe quel répertoire (clone depuis GitHub)```bash
# Build the Docker image (from any directory with Dockerfile)
docker build -t litefuzz:latest .

# Run litefuzz
docker run --rm litefuzz:latest python3 litefuzz.py --help

Cela va :
- Fuzzer latex2rtf avec 1000 itérations
- Utiliser le débogage du tas (option `-z`)
- Sauvegarder les crashs dans le répertoire `./crashes` de votre hôte
- Utiliser les fichiers d'entrée intégrés du dépôt à `/litefuzz/input/tex`

Si vous souhaitez utiliser vos propres fichiers d'entrée depuis l'hôte :```bash
# Create input directory with your test files
mkdir -p input/tex crashes
# Add your test files to input/tex/
cp your-test.tex input/tex/

# Run fuzzing with your input files
docker run --rm \
  -v $(pwd)/input:/litefuzz/input \
  -v $(pwd)/crashes:/tmp/crashes \
  litefuzz:latest \
  python3 litefuzz.py -l -c "latex2rtf FUZZ" -i /litefuzz/input/tex -o /tmp/crashes -n 1000 -z

Cela exécutera pytest pour `test_litefuzz.py` dans le répertoire principal et fournira les résultats PASS/FAIL une fois le test terminé.

#### tests de plantage d'applications
Quelques exemples d'applications boguées pour tester les capacités de plantage et de triage sur les différentes plateformes se trouvent dans le dossier `test`.

- (a) déréférencement de pointeur nul
- (b) division par zéro
- (c) débordement de tas
- (d-gui) bogue de chaîne de format dans une interface graphique
- (e) débordement de tampon dans le client
- (f) débordement de tampon dans le serveur

Ils sont automatiquement construits lors de l'installation et vous pouvez les exécuter en ligne de commande, dans un débogueur ou les utiliser comme cibles de fuzzing.

**Si vous exécutez sur la ligne de commande Windows, vérifiez `Observateur d'événements -> Journaux Windows -> Application` pour voir les plantages.**

## options
Il existe une multitude d'options et de fonctionnalités pour tirer parti de divers scénarios cibles. Voici une brève explication et quelques exemples pour vous aider à comprendre comment les utiliser.

### répertoire des plantages
`-o` vous permet de spécifier un répertoire de plantages autre que celui par défaut, qui est le dossier crashes/ dans le chemin local. On peut l'utiliser pour gérer les dossiers de plantages pour plusieurs exécutions de fuzzing simultanées pour différentes applications en même temps.

### mode insulate
`-u` isole l'application cible du processus de fuzzing normal, par ex. exécutions ou envoi de paquets à répétition et vérification des plantages. Ce mode a plutôt été conçu pour les applications clientes interactives, par ex. Postman où vous pouvez script à l'intérieur de l'application pour répéter les connexions pour le fuzzing client. La cible est exécutée dans un débogueur, le fuzzer est mis en pause pour laisser à l'utilisateur le temps de cliquer sur quelques boutons ou de configurer la cible pour qu'elle s'exécute automatiquement, l'utilisateur reprend et maintenant vous effectuez du fuzzing sur des clients réseau interactifs.

`litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z`

Le mode insulate + rafraîchissement peut être utilisé pour les clients interactifs, par ex. exécuter FileZilla dans un débogueur, mais continuer à appuyer sur F5 pour le faire se reconnecter au serveur à chaque nouvelle itération. De plus, le fuzzing des serveurs locaux CLI/GUI ne sont démarrés et exécutés qu'une seule fois dans un débogueur pour rendre le processus un peu plus efficace.

`--key` vous permet également d'envoyer des touches lors du fuzzing de cibles interactives, comme le fuzzing de l'analyse par FileZilla des réponses du serveur FTP en envoyant « rafraîchir la connexion » avec F5.

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc`

Remarque : le mode insulate n'a été testé que sur Linux et n'est pas pris en charge sur Windows.

### délai d'attente
`-x secs` vous permet de spécifier un temps mort. En pratique, cela ressemble plus à « temps approximatif entre les itérations » pour les cibles CLI et à un temps mort réel pour les GUI.

### mutateurs
`--mutator N` spécifie quel mutateur utiliser pour le fuzzing. Si l'option n'est pas fournie, un choix aléatoire parmi la liste des mutateurs disponibles est effectué pour chaque itération de fuzzing.

Ces mutateurs ont été écrits de toutes pièces (à l'exception de Radamsa bien sûr). Et bien qu'ils aient été largement testés et aient bien résisté pendant des millions d'itérations, ils peuvent parfois comporter des bogues subtils, mais cela ne devrait généralement pas affecter la fonctionnalité.```
FLIP_MUTATOR = 1
HIGHLOW_MUTATOR = 2
INSERT_MUTATOR = 3
REMOVE_MUTATOR = 4
CARVE_MUTATOR = 5
OVERWRITE_MUTATOR = 6
RADAMSA_MUTATOR = 7

### pause
Appuyez sur ctrl+c pour mettre en pause le processus de fuzzing. Si vous souhaitez reprendre, choisissez `y` ou `n` pour arrêter. Cette fonctionnalité fonctionne correctement sur toutes les plateformes, mais peut être moins fiable lors du fuzzing d'applications GUI.

### réutilisation des crashes pour la recherche de variantes

`-e` active le mode de réutilisation. Cela signifie que si des crashes ont été trouvés lors de l'exécution du fuzzing, ils seront utilisés comme entrées pour un deuxième cycle de fuzzing, ce qui peut aider à débusquer encore plus de bugs. Combinez avec `-z` pour des bugs `-ez` ! Da-duph.

L'exemple suivant fuzz antiword avec 100000 itérations, puis démarre une autre exécution avec le même nombre d'itérations et les mêmes options pour réutiliser les crashes comme entrée afin d'essayer d'extraire encore plus de bugs.

`litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez`

(ou on pourrait copier manuellement les crashes dans un répertoire d'entrée pour contrôler directement les itérations de l'exécution de réutilisation)

`litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z`

note : ce mode n'est pris en charge que pour les applications locales.

### assistants de débogage mémoire
`-z` active Electric Fence (ou le débogage glib malloc comme solution de repli) sous Linux, Guard Malloc sous Mac et PageHeap sous Windows. De plus, `-zz` peut être utilisé pour désactiver PageHeap après l'avoir activé pour une application. Si vous voulez simplement l'activer/désactiver sans démarrer le fuzzer, omettez simplement le drapeau `-i`. Lors de l'installation de Windows, [gsudo](https://github.com/gerardog/gsudo) est installé et peut être utilisé pour exécuter des commandes élevées en ligne de commande, comme activer PageHeap pour les cibles.

`sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z`

`sudo litefuzz -l -c "notepad FUZZ" -zz`

Sous Linux, des assistants spécifiques peuvent être choisis. Par exemple, au lieu d'utiliser simplement glib malloc comme solution de repli, on peut le sélectionner.

`litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc`

Le débogueur malloc par défaut Electric Fence est excellent, mais il ne fonctionne pas avec toutes les cibles. Vous pouvez tester la cible avec EF et si elle plante, sélectionnez l'assistant glibc à la place.

### vérification de la sortie en direct de la cible
Si vous fuzzez des applications locales sous Linux ou Mac, vous pouvez `cat /tmp/litefuzz/RUN_ID/fuzz.out` pour vérifier la dernière sortie standard de la cible. `RUN_ID` est affiché dans la zone d'information STATS lorsque le fuzzing commence. En cas de crash, la sortie standard est également capturée dans le répertoire des crashes sous forme de fichier `.out`. La sortie standard/erreur globale va également dans `/tmp/litefuzz/out` à des fins de débogage pour toutes les cibles de fuzzing, à l'exception des modes isolé ou serveur local dont la sortie du débogueur va dans `/tmp/litefuzz/RUN_ID/out`.

Winappdbg ne supporte pas nativement la capture de la sortie standard des cibles (à ma connaissance), donc cet artefact n'est pas disponible sous Windows.

### modes client et serveur
Si le serveur peut être exécuté localement simplement en exécutant le binaire (avec ou sans quelques drapeaux et configuration), vous pouvez passer sa ligne de commande avec `-c` et il sera démarré, fuzzé et tué avec une nouvelle exécution à chaque itération. L'idée ici est d'échanger la vitesse contre la capacité à éviter ces bugs ennuyeux qui ne se déclenchent qu'après que la mémoire de la cible soit dans un "certain état", ce qui peut conduire à des faux positifs. Même principe pour le fuzzing local de clients réseau. Il supporte même les connexions TLS, générant des certificats à la volée (permettant à l'utilisateur de fournir un certificat client lors du fuzzing d'un serveur qui en demande un, et le fuzzing du certificat lui-même sont d'autres idées ici).

Le support de débogage n'est pas fourni par Litefuzz lors du fuzzing de clients et serveurs distants, donc la configuration côté distant est à la charge de l'utilisateur. Pour les serveurs, nous vérifions simplement si le serveur a cessé de répondre et notons la charge utile précédente comme étant le crash. Cela fonctionne bien pour les connexions TCP, mais nous n'avons pas tout à fait ce luxe pour les services UDP, donc la surveillance du serveur distant est laissée soit à la fonctionnalité ReportCrash (disponible sur Mac), soit à l'exécution de la cible dans un débogueur (via le mode serveur local ou manuellement), soit à la création de scripts de support personnalisés. De plus, certains serveurs peuvent redémarrer automatiquement ou autrement récupérer après un crash, mais il peut y avoir des signes de cela dans les logs ou d'autres artefacts sur le système de fichiers qui peuvent être analysés par des scripts de support écrits pour une cible particulière.

### exemples de réseau local

`litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z`

(ouvrez Wireshark et capturez la réponse d'une 
d, cliquez droit sur Simple Network Management Protocol -> Export Packet Bytes -> resp.bin)

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z`

`litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z`

**notes rapides**
- Les sockets UDP peuvent se comporter un peu bizarrement sur Mac + Py2, donc seul Mac + Py3 a été testé et supporté
- Le fuzzing de clients réseau local sous Windows peut être bogué et doit être considéré comme expérimental pour le moment

### exemples de réseau distant

Fuzzer des clients et serveurs distants est un peu plus difficile : nous n'avons pas de débogage local et nous nous appuyons sur la détection d'un arrêt de l'interaction entre les deux parties sur le réseau pour attraper les crashes. De plus, comme nous sommes censément aveugles à ce qui se passe à l'autre bout, le fuzzing se termine lorsque le client ou le serveur cesse de répondre et doit être redémarré manuellement après que le client ou le serveur soit restauré à un état normal (non crashé) sauf si l'utilisateur a configuré des scripts côté distant pour gérer ce processus.

UDP complique encore les choses. Même l'envoi d'un paquet de test pour voir s'il y a un service à l'écoute sur un port UDP ne garantit pas une réponse. Il est donc possible de fuzzer à distance des clients et serveurs réseau, mais il y a un compromis sur la visibilité.

#### client

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100`

Le mode client est plus délicat ici car il est difficile de dire si un client a réellement planté donc il ne se reconnecte pas ou si la danse envoi/réception est simplement décalée, car différents clients peuvent gérer les connexions comme ils le souhaitent. Notez également que ce n'est qu'un exemple et que le fuzzing de clients distants par nature est délicat et doit être considéré comme quelque peu expérimental.

#### serveur

Les avantages et inconvénients du fuzzing d'un serveur localement ou à distance peuvent vous aider à décider comment aborder une cible lorsque les deux options sont disponibles.

Fondamentalement, fuzzer avec le serveur dans un débogueur sera plus lent mais vous pourrez obtenir des logs de crash avec le triage automatique, alors que fuzzer le serveur en mode distant (même en le pointant vers localhost) sera beaucoup plus rapide en moyenne, mais vous perdez la haute visibilité et les capacités de triage basées sur le débogueur, mais cela vous donnera le temps de redémarrer manuellement le serveur après chaque crash pour continuer avant qu'il ne se ferme (serveurs TCP uniquement, la fonctionnalité ne supporte pas les serveurs basés sur UDP).

**Shoutcast**

`./sc_serv ...`

`litefuzz -s -a localhost:8000 -i input/shouts -n 10000`

**SSHesame**

`sshesame`

`litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05`

**FTP**

`litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000`

**DNS**

`coredns -dns.port 10000`

`litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

ou

`litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

##### TLS

`litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000````
...
@ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining)

[!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

Chaque paquet est consommé dans un tableau, un index aléatoire est muté et rejoué pour fuzzer la cible.

`litefuzz -lk -c "ssh -T test@localhost -p 2222" -a tcp://localhost:2222 -i input/ssh -o crashes/ssh -p -n 250000 -z glibc`

Et vous pouvez vérifier la sortie de la cible pour la dernière itération.```
cat /tmp/litefuzz/out
kex_input_kexinit: discard proposal: string is too large
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: string is too large

... and others like

ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: unknown or unsupported key type

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.

Bad packet length 1869636974.
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect

Le fuzzer divise chaque ligne en sa propre réponse FTP pour tenter de fuzzer la gestion d'une session par un client. Il n'y a cependant aucune garantie qu'un client se comporte ou agisse de manière à ne pas permettre la bonne exécution d'une session, donc quelques essais et erreurs ainsi qu'un réglage fin des cas de test de session tout en exécutant Wireshark peuvent être utiles pour comprendre les différences d'interaction entre les cibles.

`litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z`

Cela peut également être combiné avec *-u* pour isoler des cibles réseau GUI comme FileZilla.

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc`

### attachement à un processus
Si la cible génère un nouveau processus lors de la connexion, on peut spécifier le nom d'un processus (ou pid) auquel s'attacher après qu'une connexion a été établie avec le serveur. Cela est pratique dans les cas où, par exemple, launchd écoute sur un port et ne lance le processus de traitement qu'une fois qu'un client est connecté. C'est une fonctionnalité qui brouille un peu la frontière entre le fuzzing local et distant, car techniquement le fuzzer est en mode distant, mais on spécifie l'adresse cible comme localhost et on lui demande de s'attacher à un processus.

`./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000`

note : actuellement, cette fonctionnalité n'est prise en charge que sur Mac (LLDB) et pour le fuzzing réseau, bien que si elle était implémentée, elle fonctionnerait correctement aussi sur Linux (GDB).

### artefacts de crash
Lorsqu'un crash est rencontré pendant le fuzzing, il est rejoué dans un débogueur pour produire des artefacts de débogage et des informations de regroupement. Les informations varient d'une plateforme à l'autre, mais généralement un fichier texte est produit avec une trace de pile, des informations sur les registres, des éléments de type `!exploitable` (lorsque disponibles) et d'autres informations de base.

**Les vidages mémoire** peuvent être activés sur Windows en passant `--memdump` ou désactivés avec `--nomemdump`, de manière similaire au contrôle des débogueurs malloc via `-z` et `-zz` respectivement. Si activé, le vidage sera également chargé dans le débogueur console (cdbg) et la sortie de l'analyse de crash `!analyze -v` est capturée dans un journal d'analyse de crash de vidage mémoire supplémentaire. Winappdbg possède déjà une analyse de type !exploitable que nous obtenons dans l'analyse de crash initiale, donc nous faisons simplement !analyze ici.

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump`

ou pour désactiver les vidages mémoire pour une application

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump`

En plus du triage automatique des crashes, des diffs binaires/chaînes (selon le cas) et la sortie standard de la cible (dépendant de la plateforme/cible) sont également produits, ainsi que bien sûr des fichiers de reproduction.

Pour le fuzzing local, les artefacts incluent généralement des diffs, la sortie standard (linux/mac uniquement), le fichier de reproduction, ainsi que le journal de crash et le fichier d'informations.```
$ ls crashes/latex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

Pour le fuzzing à distance, les artefacts peuvent varier en fonction des options choisies, mais incluent souvent des diffs, un fichier de réplication (repro) et/ou un dossier de fichiers de réplication (si l'entrée est une session avec plusieurs paquets), la réplication de l'itération de fuzzing précédente (pour éviter de perdre un bug au cas où il s'agirait en fait du crasher, car le fuzzing à distance a ses défis) ainsi qu'un journal de crash ou un fichier d'informations succinctes.```
ls crashes/serverd
REMOTE_SERVER_testbox.1_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_PREV_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diff
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diffs
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.txt
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.zz

ls crashes/serverd/REMOTE_SERVER_localhost_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_1.zz	REMOTE_SERVER_localhost_NNNN_2.zz
REMOTE_SERVER_testbox.1_NNNN_3.zz	REMOTE_SERVER_localhost_NNNN_4.zz

Jetez un œil à sa version minimisée.```
GET /admin.cgi?mode=debug&option=a
Authorization:s YWRtaW46Y2hhbmdlbWU
Referer:admin.cgi

**exemples de minimisation**

`litefuzz -l -c "latex2rtf FUZZ" -m test.tex -z`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a "tcp://localhost:8000" -m repro.http`

**exemple supermin**```
litefuzz -l -c "latex2rtf FUZZ" -mm crashes/latex2rtf/test.tex -z
...
[+] starting minimization

@ 582/582 (1 new crashes, 1145 -> 582 bytes, ~0:00:00 remaining)  

[+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes

[+] supermin activated, continuing...

@ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555557c57d to 300 bytes
...
[+] reduced crash @ pc=555555562170 to 17 bytes

@ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining)

[+] achieved maximum minimization @ 17 bytes (test.min.tex)

[RESULTS]
completed (17) iterations with 2 new crashes found

#### Énumération des gestionnaires de fichiers sur Ubuntu```
$ cat /usr/share/applications/defaults.list
[Default Applications]
application/csv=libreoffice-calc.desktop
application/excel=libreoffice-calc.desktop
application/msexcel=libreoffice-calc.desktop
application/msword=libreoffice-writer.desktop
application/ogg=rhythmbox.desktop
application/oxps=org.gnome.Evince.desktop
application/postscript=org.gnome.Evince.desktop
....

**fuzz du déchiffrement gpg via stdin avec vérification des erreurs de tas** (Mac)

`litefuzz -l -c "gpg --decrypt" -i test-gpg -o crashes-gpg -z`

**fuzz de l'application Books** (Mac GUI)

`litefuzz -l -c "/System/Applications/Books.app/Contents/MacOS/Books FUZZ" -i test-epub -t "/Users/test/Library/Containers/com.apple.iBooksX/Data" -x 8 -n 100000 -z`

note : `-z` active ici [Guard Malloc](https://www.manpagez.com/man/3/libgmalloc/) la vérification des erreurs de tas afin de détecter les bugs subtils de corruption du tas

**note Mac**

Certaines cibles GUI peuvent ne pas être tuées après le timeout de chaque itération et devenir non réactives. Pour atténuer cela, vous pouvez exécuter un script qui ressemble à ceci dans un autre terminal pour simplement les tuer périodiquement en lot afin de réduire l'effort manuel et la surveillance, sinon le processus de fuzzing peut être affecté.```
#!/bin/bash
ps -Af | grep -ie "$1" | awk '{print $2}' | xargs kill -9

*/Users/test* (exemple pour la première partie du chemin où les fichiers temporaires sont passés à l'application GUI locale, FUZZ devient un chemin lors de l'exécution) a été choisi car vous avez besoin d'une chaîne unique pour tuer les processus, et si vous utilisez uniquement le nom du processus, cela tuera le processus de fuzzing car il contient aussi le nom du processus.

**énumération des gestionnaires de fichiers sur Windows**

L'utilisation du script [AssocQueryString](https://github.com/sec-tools/WindowsFileHandlerEnumeration/) avec la commande *assoc* permet de mapper les extensions de fichiers aux applications par défaut.```
C:\> .\AssocQueryString.ps1
...
.hlp :: C:\Windows\winhlp32.exe
.hta :: C:\Windows\SysWOW64\mshta.exe
.htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.icc :: C:\Windows\system32\colorcpl.exe
.icm :: C:\Windows\system32\colorcpl.exe
.imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe
.img :: C:\Windows\Explorer.exe
.inf :: C:\Windows\system32\NOTEPAD.EXE
.ini :: C:\Windows\system32\NOTEPAD.EXE
.iso :: C:\Windows\Explorer.exe

#### client local

**fuzz client SNMP sur localhost (Linux)**

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

#### client distant

**fuzz un client FTP distant (Linux)**

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -n 100`

remarque : selon la cible, le fuzzing du client peut nécessiter l'écoute sur un port privilégié (1-1024). Dans ce cas, sous Linux vous pouvez soit utiliser `setcap cap_net_bind_service=+ep` sur l'interpréteur Python, soit utiliser sudo lors de l'exécution du fuzzer ; sous Mac, utilisez simplement sudo, et sous Windows, vous pouvez exécuter le fuzzer en tant qu'Administrateur pour éviter toute erreur d'autorisation refusée.

### serveur

#### coup d'œil rapide```
litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id:     4001
cmdline:    ./sc_serv shoutcast.conf
address:    tcp://localhost:8000
crash dir:  crashes/shoutcast
input dir:  input/shoutcast
inputs:     3
iterations: 1000
mutator:    random(mutators)

@ 1000/1000 (1 crashes, 7 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (1) unique crashes and 7 dups
>> check crashes/shoutcast for more details

# trophies

Litefuzz a trouvé des crashes dans divers logiciels tels que...

* antiword
* AppleScript (OS X)
* ArangoDB VelocyPack
* Avast authenticode-parser
* Avast RetDec
* BBC Audio Waveform
* ColorSync (OS X)
* Dynamsoft BarcodeReader
* eot2ttf
* evernote2md
* faad2
* Facebook's Origami Studio
* FontForge
* ForestDB
* Gifsicle
* GPUJPEG
* GPAC Multimedia Framework
* Google Draco
* Google Quipper
* GoPro GPR
* GtkRadiant
* IIPImage Server
* John The Ripper
* Kyoto Cabinet
* latex2rtf
* libMeshb
* libembroidery
* libsndfile
* Lion Vector Graphics (lvg)
* L-SMASH
* mp3-decoder
* MindNode
* minimp4
* MiniWeb Server
* MLpack
* Nvidia Data Center GPU Manager
* Numbers (OS X)
* OpenJPEG
* OpenOrienteering Mapper
* OSM Express
* Pages (OS X)
* PBRT-Parser
* Pixar USD
* Remote Apple Events (OS X)
* Samsung rlottie
* Samsung ThorVG
* Shoutcast Server
* Silo
* syslog (OS X)
* Tencent NCNN
* TinyXML2
* UEFITool
* Ulfius Web Framework
* zlib

# FAQ

## comment ce projet est-il né ?
Le fuzzing est amusant ! Et il est agréable de réaliser des projets qui adoptent un point de vue anticonformiste, selon lequel les fuzzers n'ont pas toujours besoin de suivre les approches modernes ou populaires pour atteindre l'objectif final de trouver des bugs. Que vous soyez proche du matériel nu, que vous obteniez une couverture de code sur tous les chemins ou que vous optimisiez simplement la rapidité et la flexibilité, la manière fondamentale d'invalider les hypothèses, etc. Quelle que soit la forme que cela prend, profitez-en.

## ce projet est-il activement maintenu ?
Ne vous attendez pas à un support actif ou à une maintenance du projet. N'hésitez pas à le forker pour ajouter de nouvelles fonctionnalités ou corriger des bugs, etc. Vous pouvez même soumettre une PR pour des choses mineures, mais ne vous attendez pas à des réponses ou à un dépannage. Il n'est pas prévu que le développement sur ce dépôt soit actif.

## comment savoir si le fuzzer fonctionne bien et l'avez-vous mesuré par rapport à d'autres ?
Le but de Litefuzz est de trouver des bugs sur plusieurs plateformes. Et il le fait. Honnêtement, la capacité à le comparer à fuzzerX ou fuzzerY n'a tout simplement pas été retenue. Certains compromis ont été faits et acceptés dès le départ, voir [#intro](https://github.com/sec-tools/litefuzz/blob/HEAD/README.md#intro) pour plus de détails.

## que changeriez-vous si vous deviez le réécrire aujourd'hui ?
Il fonctionne plutôt bien tel quel et a été testé sur une tonne de cibles et de scénarios différents. Cela dit, il pourrait bénéficier d'une standardisation sur un système plus modulaire et basé sur des plugins, où le passage d'une cible à une plateforme ne nécessiterait pas autant de vérifications supplémentaires dans le code opérationnel, etc. Bien sûr, avoir des tests plus formels et un système de déploiement qui le testerait sur les systèmes d'exploitation compatibles créerait un environnement plus facile à travailler lors de changements dans les fonctions de base. Il est passé d'un petit projet ambitieux à quelque chose d'un peu plus grand assez rapidement.

## quelle est la stabilité de litefuzz ?
La ligne de commande, l'interface graphique, le fuzzing réseau (principalement sur Linux et Mac), la minimisation, etc. ont été testés assez minutieusement et devraient être globalement solides. Certaines fonctionnalités plus exotiques comme le fuzzing réseau avec interface graphique isolée, le support de ReportCrash pour Mac et d'autres fonctionnalités de niche doivent être considérées comme expérimentales.

## y a-t-il des scénarios non supportés pour litefuzz ?
Quelques-uns, oui. Mais la plupart sont soit des scénarios peu courants qui sont bogués, nécessitent plus de temps et de recherche pour être bien réalisés, ou ne fonctionnent tout simplement pas pour des raisons liées à la plateforme. Beaucoup d'entre eux se terminent explicitement par un message « non supporté » lorsque vous essayez de les exécuter avec ces options, et certaines mises en garde ont été mentionnées dans les sections ci-dessus lors de la description des différentes fonctionnalités. Parmi les plus nuancés, le mode repro sur les applications *isolées* n'est pas supporté, et les tests sur les applications Mac utilisant la fonction d'isolement ont été limités. Pyautogui semble bien fonctionner sur Linux et Windows, mais sur Mac, il n'a pas été très fiable, donc considérez-le comme fonctionnellement non supporté. De plus, le fuzzing client sur Windows peut être un peu moins fiable que d'autres modes sur d'autres plateformes.

Il peut y avoir quelques cas particuliers ici et là, mais les scénarios de fuzzing local et réseau les plus courants ont été testés et fonctionnent. Ah, ce sont les joies de l'écriture d'outils multiplateformes : gratifiant, mais il est difficile de faire fonctionner parfaitement tout le temps. Dans l'ensemble, le fuzzing sur Linux/Mac semble plus stable et supporte plus de fonctionnalités, surtout parce qu'il a été beaucoup plus testé en fuzzing réseau que sur Windows, mais un effort a été fait pour qu'au moins les bases soient disponibles sur Win32 avec quelques extras.

N'hésitez pas à forker ce fuzzer et à apporter ces améliorations, à supporter ce qui ne l'est pas actuellement, etc., ou à soumettre des PR pour des choses mineures mais utiles.

## quelles garanties sont données pour ce projet ou son code ?
Absolument aucune. Mais c'est plutôt amusant de fuzzer et de le voir vous donner des bugs.

## auteur / références
- [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/HEAD/jbrown3264%5BNOSPAM%5Dgmail)
- [Présentation pour le fuzzing macOS](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)