AFL
Version 2.57b (2020-06-30)
Ursprünglich entwickelt von Michal Zalewski [email protected].
Sehen Sie sich QuickStartGuide.txt an, wenn Sie keine Zeit haben, diese Datei zu lesen.
Fuzzing ist eine der wirkungsvollsten und bewährtesten Strategien zur Identifizierung von Sicherheitsproblemen in realer Software. Es ist für die überwiegende Mehrheit der bisher in sicherheitskritischer Software gefundenen Fehler bei der Remote-Codeausführung und Rechteausweitung verantwortlich.
Leider ist auch das Fuzzing relativ oberflächlich; Blinde, zufällige Mutationen machen es sehr unwahrscheinlich, bestimmte Codepfade im getesteten Code zu erreichen, sodass einige Schwachstellen völlig außerhalb der Reichweite dieser Technik bleiben.
Es gab zahlreiche Versuche, dieses Problem zu lösen. Einer der ersten Ansätze – Pionierarbeit leistete Tavis Ormandy – ist die Korpusdestillation. Die Methode basiert auf Coverage-Signalen, um eine Teilmenge interessanter Seeds aus einem riesigen, qualitativ hochwertigen Korpus von Kandidatendateien auszuwählen und sie dann mit herkömmlichen Mitteln zu fuzzeln. Der Ansatz funktioniert außerordentlich gut, erfordert jedoch die einfache Verfügbarkeit eines solchen Korpus. Darüber hinaus liefern Blockabdeckungsmessungen nur ein sehr vereinfachtes Verständnis des Programmstatus und sind auf lange Sicht weniger nützlich, um den Fuzzing-Aufwand zu steuern.
Andere, anspruchsvollere Forschungen konzentrierten sich auf Techniken wie die Programmflussanalyse („konkolische Ausführung“), die symbolische Ausführung oder die statische Analyse. Alle diese Methoden sind in experimentellen Umgebungen äußerst vielversprechend, weisen jedoch in der Praxis tendenziell Probleme mit der Zuverlässigkeit und Leistung auf – und bieten derzeit keine brauchbare Alternative zu „dummen“ Fuzzing-Techniken.
American Fuzzy Lop ist ein Brute-Force-Fuzzer, gepaart mit einem überaus einfachen, aber absolut soliden, instrumentengesteuerten genetischen Algorithmus. Es verwendet eine modifizierte Form der Kantenabdeckung, um subtile, lokale Änderungen des Programmkontrollflusses mühelos zu erfassen.
Etwas vereinfacht lässt sich der Gesamtalgorithmus wie folgt zusammenfassen:
Vom Benutzer bereitgestellte erste Testfälle in die Warteschlange laden,
Nehmen Sie die nächste Eingabedatei aus der Warteschlange.
Versuchen Sie, den Testfall auf die kleinste Größe zu reduzieren, die das gemessene Verhalten des Programms nicht verändert.
Ändern Sie die Datei wiederholt mit einer ausgewogenen und gut erforschten Vielfalt traditioneller Fuzzing-Strategien.
Wenn eine der generierten Mutationen zu einem neuen, von der Instrumentierung aufgezeichneten Zustandsübergang führte, fügen Sie die mutierte Ausgabe als neuen Eintrag in der Warteschlange hinzu.
Gehen Sie zu 2.
Die entdeckten Testfälle werden auch regelmäßig ausgesondert, um diejenigen zu eliminieren, die durch neuere Funde mit höherer Abdeckung überholt wurden; und mehrere andere instrumentierungsgesteuerte Schritte zur Aufwandsminimierung durchlaufen.
Als Nebenergebnis des Fuzzing-Prozesses erstellt das Tool einen kleinen, in sich geschlossenen Korpus interessanter Testfälle. Diese sind äußerst nützlich für die Einführung anderer arbeits- oder ressourcenintensiver Testverfahren – beispielsweise für Stresstests von Browsern, Büroanwendungen, Grafiksuiten oder Closed-Source-Tools.
Der Fuzzer wurde gründlich getestet, um eine Out-of-the-Box-Leistung zu liefern, die Blind-Fuzzing oder reinen Coverage-Tools weit überlegen ist.
Wenn Quellcode verfügbar ist, kann die Instrumentierung von einem Begleittool eingefügt werden, das als Drop-in-Ersatz für gcc oder clang in jedem Standard-Build-Prozess für Code von Drittanbietern fungiert.
Die Instrumentierung hat einen recht bescheidenen Einfluss auf die Leistung; In Verbindung mit anderen von AFL-Fuzz implementierten Optimierungen können die meisten Programme genauso schnell oder sogar schneller als mit herkömmlichen Tools Fuzzing durchgeführt werden.
Der richtige Weg zum Neukompilieren des Zielprogramms kann je nach den Besonderheiten des Build-Prozesses variieren, aber ein nahezu universeller Ansatz wäre:
$ CC=/path/to/afl/afl-gcc ./configure
$ make clean all Für C++-Programme möchten Sie auch CXX=/path/to/afl/afl-g++ festlegen.
Die Clang-Wrapper (afl-clang und afl-clang++) können auf die gleiche Weise verwendet werden; Clang-Benutzer können sich auch für die Nutzung eines leistungsstärkeren Instrumentierungsmodus entscheiden, wie in llvm_mode/README.llvm beschrieben.
Beim Testen von Bibliotheken müssen Sie ein einfaches Programm finden oder schreiben, das Daten aus stdin oder aus einer Datei liest und an die getestete Bibliothek übergibt. In einem solchen Fall ist es wichtig, diese ausführbare Datei mit einer statischen Version der instrumentierten Bibliothek zu verknüpfen oder sicherzustellen, dass die richtige .so-Datei zur Laufzeit geladen wird (normalerweise durch Festlegen LD_LIBRARY_PATH ). Die einfachste Option ist ein statischer Build, der normalerweise möglich ist über:
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared Wenn Sie beim Aufruf von „make“ AFL_HARDEN=1 festlegen, aktiviert der CC-Wrapper automatisch Code-Härtungsoptionen, die das Erkennen einfacher Speicherfehler erleichtern. Libdislocator, eine in AFL enthaltene Hilfsbibliothek (siehe libdislocator/README.dislocator), kann ebenfalls dabei helfen, Probleme mit der Heap-Beschädigung aufzudecken.
PS. ASAN-Benutzern wird empfohlen, die Datei „notes_for_asan.txt“ auf wichtige Vorbehalte zu überprüfen.
Wenn der Quellcode NICHT verfügbar ist, bietet der Fuzzer experimentelle Unterstützung für die schnelle, spontane Instrumentierung von Black-Box-Binärdateien. Dies wird mit einer Version von QEMU erreicht, die im weniger bekannten „User Space Emulation“-Modus läuft.
QEMU ist ein von AFL getrenntes Projekt, aber Sie können die Funktion bequem erstellen, indem Sie Folgendes tun:
$ cd qemu_mode
$ ./build_qemu_support.shWeitere Anweisungen und Vorsichtsmaßnahmen finden Sie unter qemu_mode/README.qemu.
Der Modus ist etwa zwei- bis fünfmal langsamer als die Instrumentierung zur Kompilierungszeit, eignet sich weniger für die Parallelisierung und kann einige andere Besonderheiten aufweisen.
Um ordnungsgemäß zu funktionieren, benötigt der Fuzzer eine oder mehrere Startdateien, die ein gutes Beispiel für die Eingabedaten enthalten, die normalerweise von der Zielanwendung erwartet werden. Es gibt zwei Grundregeln:
Halten Sie die Dateien klein. Unter 1 kB ist ideal, aber nicht unbedingt notwendig. Eine Diskussion darüber, warum Größe wichtig ist, finden Sie in perf_tips.txt.
Verwenden Sie mehrere Testfälle nur, wenn sie sich funktional voneinander unterscheiden. Es macht keinen Sinn, fünfzig verschiedene Urlaubsfotos zu verwenden, um eine Bildbibliothek aufzupeppen.
Viele gute Beispiele für Startdateien finden Sie im Unterverzeichnis testcases/, das mit diesem Tool geliefert wird.
PS. Wenn ein großer Datenbestand für die Überprüfung verfügbar ist, können Sie das Dienstprogramm afl-cmin verwenden, um eine Teilmenge funktional unterschiedlicher Dateien zu identifizieren, die unterschiedliche Codepfade in der Zielbinärdatei ausführen.
Der Fuzzing-Prozess selbst wird vom Dienstprogramm afl-fuzz ausgeführt. Dieses Programm benötigt ein schreibgeschütztes Verzeichnis mit ersten Testfällen, einen separaten Ort zum Speichern seiner Ergebnisse sowie einen Pfad zur zu testenden Binärdatei.
Für Zielbinärdateien, die Eingaben direkt von stdin akzeptieren, lautet die übliche Syntax:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]Verwenden Sie bei Programmen, die Eingaben aus einer Datei entgegennehmen, „@@“, um die Position in der Befehlszeile des Ziels zu markieren, an der der Name der Eingabedatei platziert werden soll. Der Fuzzer wird dies für Sie ersetzen:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@Sie können auch die Option -f verwenden, um die mutierten Daten in eine bestimmte Datei zu schreiben. Dies ist nützlich, wenn das Programm eine bestimmte Dateierweiterung oder ähnliches erwartet.
Nicht instrumentierte Binärdateien können im QEMU-Modus (fügen Sie -Q in der Befehlszeile hinzu) oder in einem herkömmlichen Blind-Fuzzer-Modus (geben Sie -n an) Fuzzing werden.
Sie können -t und -m verwenden, um das Standard-Timeout und das Speicherlimit für den ausgeführten Prozess zu überschreiben. Zu den seltenen Beispielen für Ziele, bei denen diese Einstellungen möglicherweise geändert werden müssen, gehören Compiler und Videodecoder.
Tipps zur Optimierung der Fuzzing-Leistung werden in perf_tips.txt besprochen.
Beachten Sie, dass afl-fuzz mit der Durchführung einer Reihe deterministischer Fuzzing-Schritte beginnt, die mehrere Tage dauern können, aber in der Regel zu sauberen Testfällen führen. Wenn Sie sofort schnelle und schmutzige Ergebnisse erzielen möchten – ähnlich wie bei zzuf und anderen herkömmlichen Fuzzern – fügen Sie der Befehlszeile die Option -d hinzu.
Informationen zur Interpretation der angezeigten Statistiken und zur Überwachung des Prozesszustands finden Sie in der Datei status_screen.txt. Lesen Sie unbedingt diese Datei, insbesondere wenn UI-Elemente rot hervorgehoben sind.
Der Fuzzing-Vorgang wird fortgesetzt, bis Sie Strg-C drücken. Sie möchten dem Fuzzer mindestens erlauben, einen Warteschlangenzyklus abzuschließen, der zwischen ein paar Stunden und etwa einer Woche dauern kann.
Im Ausgabeverzeichnis werden drei Unterverzeichnisse erstellt und in Echtzeit aktualisiert:
queue/ – Testfälle für jeden einzelnen Ausführungspfad, plus alle vom Benutzer angegebenen Startdateien. Dies ist das in Abschnitt 2 erwähnte synthetisierte Korpus. Bevor Sie dieses Korpus für andere Zwecke verwenden, können Sie es mit dem Tool afl-cmin auf eine kleinere Größe verkleinern. Das Tool findet eine kleinere Teilmenge von Dateien mit gleichwertiger Kantenabdeckung.
Abstürze/ – einzigartige Testfälle, die dazu führen, dass das getestete Programm ein schwerwiegendes Signal empfängt (z. B. SIGSEGV, SIGILL, SIGABRT). Die Einträge werden nach dem empfangenen Signal gruppiert.
hängt/ – einzigartige Testfälle, die zu einer Zeitüberschreitung des getesteten Programms führen. Das Standardzeitlimit, bevor etwas als hängengeblieben eingestuft wird, beträgt 1 Sekunde oder den Wert des Parameters -t, je nachdem, welcher Wert größer ist. Der Wert kann durch Festlegen von AFL_HANG_TMOUT feinabgestimmt werden, dies ist jedoch selten erforderlich.
Abstürze und Hänge gelten als „einzigartig“, wenn die zugehörigen Ausführungspfade Zustandsübergänge beinhalten, die bei zuvor aufgezeichneten Fehlern nicht aufgetreten sind. Wenn ein einzelner Fehler auf mehreren Wegen erreicht werden kann, kommt es zu Beginn des Prozesses zu einer gewissen Inflation, die jedoch schnell nachlassen sollte.
Die Dateinamen für Abstürze und Hänge werden mit übergeordneten, nicht fehlerhaften Warteschlangeneinträgen korreliert. Dies sollte beim Debuggen helfen.
Wenn Sie einen von afl-fuzz gefundenen Absturz nicht reproduzieren können, liegt die wahrscheinlichste Ursache darin, dass Sie nicht das gleiche Speicherlimit festlegen, das vom Tool verwendet wird. Versuchen:
$ LIMIT_MB=50
$ ( ulimit -Sv $[LIMIT_MB << 10] ; /path/to/tested_binary ... )Ändern Sie LIMIT_MB so, dass es mit dem an afl-fuzz übergebenen Parameter -m übereinstimmt. Ändern Sie unter OpenBSD auch -Sv in -Sd.
Jedes vorhandene Ausgabeverzeichnis kann auch zum Fortsetzen abgebrochener Jobs verwendet werden. versuchen:
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]Wenn Sie gnuplot installiert haben, können Sie mit afl-plot auch einige hübsche Diagramme für jede aktive Fuzzing-Aufgabe erstellen. Ein Beispiel dafür finden Sie unter http://lcamtuf.coredump.cx/afl/plot/.
Jede Instanz von afl-fuzz belegt ungefähr einen Kern. Dies bedeutet, dass auf Multicore-Systemen eine Parallelisierung erforderlich ist, um die Hardware vollständig auszunutzen. Tipps zum Fuzzen eines gemeinsamen Ziels auf mehreren Kernen oder mehreren vernetzten Maschinen finden Sie unter parallel_fuzzing.txt.
Der parallele Fuzzing-Modus bietet auch eine einfache Möglichkeit, AFL mit anderen Fuzzern, symbolischen oder konkolischen Ausführungs-Engines usw. zu verbinden. Tipps finden Sie auch hier im letzten Abschnitt von parallel_fuzzing.txt.
Standardmäßig ist die afl-fuzz-Mutations-Engine für kompakte Datenformate optimiert – beispielsweise Bilder, Multimedia, komprimierte Daten, reguläre Ausdruckssyntax oder Shell-Skripte. Es ist etwas weniger geeignet für Sprachen mit besonders ausführlicher und redundanter Wortwahl – insbesondere einschließlich HTML, SQL oder JavaScript.
Um den Aufwand beim Erstellen syntaxbewusster Tools zu vermeiden, bietet afl-fuzz eine Möglichkeit, den Fuzzing-Prozess mit einem optionalen Wörterbuch aus Sprachschlüsselwörtern, magischen Headern oder anderen speziellen Tokens zu versehen, die mit dem Zieldatentyp verknüpft sind – und diese zur Rekonstruktion zu verwenden die zugrunde liegende Grammatik für unterwegs:
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
Um diese Funktion nutzen zu können, müssen Sie zunächst ein Wörterbuch in einem der beiden Formate erstellen, die in Wörterbüchern/README.dictionaries beschrieben werden. und richten Sie dann den Fuzzer über die Option -x in der Befehlszeile darauf.
(In diesem Unterverzeichnis sind auch bereits mehrere gängige Wörterbücher enthalten.)
Es gibt keine Möglichkeit, strukturiertere Beschreibungen der zugrunde liegenden Syntax bereitzustellen, aber der Fuzzer wird wahrscheinlich einiges davon allein aufgrund des Instrumentierungs-Feedbacks herausfinden. Das funktioniert tatsächlich in der Praxis, sagen wir:
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
PS. Auch wenn kein explizites Wörterbuch angegeben ist, versucht afl-fuzz, vorhandene Syntax-Tokens im Eingabekorpus zu extrahieren, indem es die Instrumentierung während deterministischer Byte-Flips sehr genau beobachtet. Dies funktioniert für einige Arten von Parsern und Grammatiken, ist jedoch bei weitem nicht so gut wie der -x-Modus.
Wenn es wirklich schwierig ist, an ein Wörterbuch zu kommen, besteht eine andere Möglichkeit darin, AFL eine Weile laufen zu lassen und dann die Token-Capture-Bibliothek zu verwenden, die als Begleitdienstprogramm mit AFL geliefert wird. Siehe hierzu libtokencap/README.tokencap.
Die auf Abdeckung basierende Gruppierung von Abstürzen erzeugt normalerweise einen kleinen Datensatz, der schnell manuell oder mit einem sehr einfachen GDB- oder Valgrind-Skript analysiert werden kann. Jeder Absturz kann auch auf den übergeordneten, nicht abstürzenden Testfall in der Warteschlange zurückgeführt werden, was die Fehlerdiagnose erleichtert.
Allerdings muss man sich darüber im Klaren sein, dass es schwierig sein kann, einige Fuzzing-Abstürze ohne großen Debugging- und Codeanalyseaufwand schnell auf ihre Ausnutzbarkeit hin zu beurteilen. Um diese Aufgabe zu unterstützen, unterstützt afl-fuzz einen einzigartigen „Crash Exploration“-Modus, der mit dem Flag -C aktiviert wird.
In diesem Modus nimmt der Fuzzer einen oder mehrere abstürzende Testfälle als Eingabe und verwendet seine rückkopplungsgesteuerten Fuzzing-Strategien, um sehr schnell alle Codepfade aufzulisten, die im Programm erreicht werden können, während es gleichzeitig im Absturzzustand bleibt.
Mutationen, die nicht zu einem Absturz führen, werden abgelehnt; Dies gilt auch für alle Änderungen, die sich nicht auf den Ausführungspfad auswirken.
Die Ausgabe ist ein kleiner Dateikorpus, der sehr schnell untersucht werden kann, um festzustellen, wie viel Kontrolle der Angreifer über die fehlerhafte Adresse hat oder ob es möglich ist, einen anfänglichen Lesevorgang außerhalb der Grenzen zu umgehen – und zu sehen, was sich darunter verbirgt .
Oh, noch etwas: Probieren Sie zur Minimierung von Testfällen afl-tmin aus. Die Bedienung des Tools ist denkbar einfach:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]Das Tool funktioniert sowohl mit abstürzenden als auch mit nicht abstürzenden Testfällen. Im Absturzmodus werden instrumentierte und nicht instrumentierte Binärdateien problemlos akzeptiert. Im nicht abstürzenden Modus verlässt sich der Minimierer auf die Standard-AFL-Instrumentierung, um die Datei einfacher zu machen, ohne den Ausführungspfad zu ändern.
Der Minimierer akzeptiert die Syntax -m, -t, -f und @@ in einer mit afl-fuzz kompatiblen Weise.
Eine weitere neue Ergänzung zu AFL ist das Tool afl-analyze. Es nimmt eine Eingabedatei, versucht, Bytes nacheinander umzudrehen, und beobachtet das Verhalten des getesteten Programms. Anschließend wird die Eingabe farblich kodiert, basierend darauf, welche Abschnitte kritisch erscheinen und welche nicht. Obwohl es nicht kugelsicher ist, kann es oft schnelle Einblicke in komplexe Dateiformate bieten. Weitere Informationen zur Funktionsweise finden Sie am Ende von „technical_details.txt“.
Fuzzing ist eine wunderbare und wenig genutzte Technik, um nicht abstürzende Design- und Implementierungsfehler zu entdecken. Es wurden einige interessante Fehler gefunden, indem die Zielprogramme so geändert wurden, dass sie abort() aufrufen, wenn beispielsweise:
Zwei Bignum-Bibliotheken erzeugen unterschiedliche Ausgaben, wenn sie dieselben vom Fuzzer generierten Eingaben erhalten.
Eine Bildbibliothek erzeugt unterschiedliche Ausgaben, wenn sie aufgefordert wird, dasselbe Eingabebild mehrmals hintereinander zu dekodieren.
Eine Serialisierungs-/Deserialisierungsbibliothek erzeugt keine stabilen Ausgaben, wenn vom Fuzzer bereitgestellte Daten iterativ serialisiert und deserialisiert werden.
Eine Komprimierungsbibliothek erzeugt eine Ausgabe, die nicht mit der Eingabedatei übereinstimmt, wenn sie aufgefordert wird, einen bestimmten Blob zu komprimieren und dann zu dekomprimieren.
Die Durchführung dieser oder ähnlicher Plausibilitätsprüfungen nimmt in der Regel sehr wenig Zeit in Anspruch; Wenn Sie der Betreuer eines bestimmten Pakets sind, können Sie diesen Code mit #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION (ein Flag, das auch mit libfuzzer geteilt wird) oder #ifdef __AFL_COMPILER (dieses ist nur für AFL) bedingt machen.
Bitte beachten Sie, dass Fuzzing, ähnlich wie viele andere rechenintensive Aufgaben, Ihre Hardware und das Betriebssystem belasten kann. Insbesondere:
Ihre CPU wird heiß und muss ausreichend gekühlt werden. Wenn die Kühlung nicht ausreicht oder nicht mehr richtig funktioniert, wird die CPU-Geschwindigkeit in den meisten Fällen automatisch gedrosselt. Insbesondere beim Fuzzen auf weniger geeigneter Hardware (Laptops, Smartphones usw.) ist es jedoch nicht völlig ausgeschlossen, dass etwas explodiert.
Gezielte Programme beanspruchen möglicherweise unberechenbar Gigabyte Arbeitsspeicher oder füllen den Speicherplatz mit Junk-Dateien. AFL versucht, grundlegende Speicherbeschränkungen durchzusetzen, kann jedoch nicht jedes mögliche Missgeschick verhindern. Die Quintessenz ist, dass Sie sich nicht auf Systeme konzentrieren sollten, bei denen die Aussicht auf Datenverlust kein akzeptables Risiko darstellt.
Fuzzing erfordert Milliarden von Lese- und Schreibvorgängen im Dateisystem. Auf modernen Systemen wird dies normalerweise stark zwischengespeichert, was zu relativ bescheidenen „physischen“ E/A-Vorgängen führt – es gibt jedoch viele Faktoren, die diese Gleichung ändern können. Es liegt in Ihrer Verantwortung, auf mögliche Probleme zu achten. Bei sehr hohem I/O-Aufwand kann sich die Lebensdauer vieler Festplatten und SSDs verkürzen.
Eine gute Möglichkeit, Festplatten-I/O unter Linux zu überwachen, ist der Befehl „iostat“:
$ iostat -d 3 -x -k [...optional disk ID...]Hier sind einige der wichtigsten Vorbehalte für AFL:
AFL erkennt Fehler, indem es prüft, ob der erste erzeugte Prozess aufgrund eines Signals (SIGSEGV, SIGABRT usw.) stirbt. Bei Programmen, die benutzerdefinierte Handler für diese Signale installieren, muss der entsprechende Code möglicherweise auskommentiert werden. Ebenso können Fehler in der untergeordneten Verarbeitung, die durch das Fuzzed-Ziel erzeugt werden, der Erkennung entgehen, es sei denn, Sie fügen manuell Code hinzu, um dies zu erkennen.
Wie jedes andere Brute-Force-Tool bietet der Fuzzer nur eine begrenzte Abdeckung, wenn Verschlüsselung, Prüfsummen, kryptografische Signaturen oder Komprimierung verwendet werden, um das eigentliche zu testende Datenformat vollständig zu umhüllen.
Um dies zu umgehen, können Sie die relevanten Prüfungen auskommentieren (siehe „experimental/libpng_no_checksum/“ als Inspiration); Wenn dies nicht möglich ist, können Sie auch einen Postprozessor schreiben, wie in experimentell/post_library/ erklärt.
Bei ASAN und 64-Bit-Binärdateien gibt es einige unglückliche Kompromisse. Dies ist nicht auf ein spezifisches Verschulden von afl-fuzz zurückzuführen; Tipps finden Sie unter „notes_for_asan.txt“.
Es gibt keine direkte Unterstützung für Fuzzing-Netzwerkdienste, Hintergrund-Daemons oder interaktive Apps, für deren Funktion eine Interaktion mit der Benutzeroberfläche erforderlich ist. Möglicherweise müssen Sie einfache Codeänderungen vornehmen, damit sie sich traditioneller verhalten. Preeny bietet möglicherweise auch eine relativ einfache Option – siehe: https://github.com/zardus/preeny
Einige nützliche Tipps zum Ändern netzwerkbasierter Dienste finden Sie auch unter: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL gibt keine für Menschen lesbaren Abdeckungsdaten aus. Wenn Sie die Abdeckung überwachen möchten, verwenden Sie afl-cov von Michael Rash: https://github.com/mrash/afl-cov
Gelegentlich erheben sich empfindungsfähige Maschinen gegen ihre Schöpfer. Wenn Ihnen dies passiert, konsultieren Sie bitte http://lcamtuf.coredump.cx/prep/.
Darüber hinaus finden Sie unter INSTALL plattformspezifische Tipps.
Viele der Verbesserungen an afl-fuzz wären ohne Feedback, Fehlerberichte oder Patches von:
Jann Horn Hanno Boeck
Felix Groebert Jakub Wilk
Richard W. M. Jones Alexander Cherepanov
Tom Ritter Hovik Manucharyan
Sebastian Roschke Eberhard Mattes
Padraig Brady Ben Laurie
@dronesec Luca Barbato
Tobias Ospelt Thomas Jarosch
Martin Carpenter Mudge Zatko
Joe Zbiciak Ryan Govostes
Michael Rash William Robinet
Jonathan Gray Filipe Cabecinhas
Nico Weber Jodie Cunningham
Andrew Griffiths Parker Thompson
Jonathan Neuschfer Tyler Nighswander
Ben Nagy Samir Aguiar
Aidan Thornton Aleksandar Nikolich
Sam Hakim Laszlo Szekeres
David A. Wheeler Turo Lamminen
Andreas Stieger Richard Godbee
Louis Dassy teor2345
Alex Moneger Dmitry Vyukov
Keegan McAllister Kostya Serebryany
Richo Healey Martijn Bogaard
rc0r Jonathan Foote
Christian Holler Dominique Pelle
Jacek Wielemborek Leo Barnes
Jeremy Barnes Jeff Trull
Guillaume Endignoux ilovezfs
Daniel Godas-Lopez Franjo Ivancic
Austin Seipp Daniel Komaromy
Daniel Binderman Jonathan Metzman
Vegard Nossum Jan Kneschke
Kurt Roeckx Marcel Bohme
Van-Thuan Pham Abhik Roychoudhury
Joshua J. Drake Toby Hutton
Rene Freingruber Sergey Davidoff
Sami Liedes Craig Young
Andrzej Jackowski Daniel Hodson
Danke schön!
Fragen? Anliegen? Fehlerberichte? Bitte verwenden Sie GitHub.
Es gibt auch eine Mailingliste für das Projekt; Um beizutreten, senden Sie eine E-Mail an [email protected]. Wenn Sie lieber zuerst die Archive durchsuchen möchten, versuchen Sie es mit: https://groups.google.com/group/afl-users.
