nccgroup/triforceaflAFL/QEMU fuzzing avec émulation du système complet.
Nouveau : pour ceux qui souhaitent jouer avec TriforceAFL et TLSF, Richard Johnson a créé un Dockerfile qui installe les deux (et compile même un noyau Linux pour vous). Il est disponible ici https://hub.docker.com/r/moflow/afl-triforce/tags/.
Autre nouveauté : afl-tmin fonctionne désormais avec le forkserver !
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Ceci est une version patchée d'AFL qui prend en charge le fuzzing système complet avec QEMU. Le QEMU inclus a été mis à jour pour permettre le traçage des branches lors de l'exécution d'un émulateur système pour x86_64. Des instructions supplémentaires ont été ajoutées pour démarrer le forkserver d'AFL, définir les paramètres de fuzz et marquer le début et la fin des cas de test.
Remarque : tous les outils AFL n'ont pas été testés avec les nouvelles modifications. Ces outils ont fait l'objet de quelques tests :
Pour compiler :
make
Pour obtenir une carte de couverture :
echo hello > /tmp/hello
./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello
cat coverage.txt
Pour fuzzer :
egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic
mkdir inputs
echo hello > inputs/hello
./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@
(Remarque : contrairement à l'utilisation de l'option « -Q », vous devez spécifier la ligne de commande complète à afl-qemu-system-trace lorsque vous utilisez l'option « -QQ »).
Pour plus de détails sur l'utilisation de cette version modifiée d'AFL, consultez notre fuzzer d'appels système Linux à l'adresse https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Nouveaux drapeaux AFL : -QQ - utilise qemu en émulation système complet plutôt qu'en mode utilisateur (-Q)
Nouveaux drapeaux QEMU : -aflFile - Le nom du fichier contenant les entrées du fuzzer -aflPanicAddr - Une adresse de la fonction de panic du noyau pour la détection de panic -aflDmesgAddr - Adresse noyau Linux de la fonction de journalisation dmesg pour détecter la journalisation et intercepter les messages de journal
Nouvelles instructions QEMU : 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Démarre le serveur de fork d'AFL. Après ce point, chaque test s'exécutera dans un enfant forké séparé. Si enableTicks est non nul, QEMU réactivera la minuterie du CPU après le fork d'un enfant ; sinon, elle ne sera pas activée. edi=2 getWork(esi=ptr, edx=sz) Remplit ptr[0..sz] avec le prochain cas de test d'entrée. Renvoie la taille réellement remplie (<= sz). edi=3 startWork(esi=ptr) Demande à AFL de commencer le traçage. L'argument pointe vers un tampon contenant deux quadmots donnant les adresses de début et de fin du code à tracer. Les instructions en dehors de cette plage ne sont pas tracées. edi=4 doneWork(esi=exitCode) Indique à AFL que le cas de test est terminé. Si une panic est détectée, AFL arrête immédiatement le cas de test. Sinon, il s'exécute jusqu'à ce que doneWork soit appelé. Le code de sortie spécifié est renvoyé à AFL. (Le code peut, mais ne le fait actuellement pas, appliquer un OU avec la valeur 64 à tous les codes de sortie si des journaux dmesg ont été détectés pendant le cas de test.)
Nouveau pilote de bloc QEMU : -drive filename=privmem: Ce pilote de bloc conserve l'image du disque dans une mémoire en copie à l'écriture (copy-on-write), de sorte que les modifications ne sont jamais persistées sur le disque. Les modifications apportées par un cas de test sont isolées des autres cas de test.
Écrit et maintenu par Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. Tous droits réservés. Distribué selon les termes et conditions de la licence Apache, version 2.0.
Pour les nouvelles versions et des informations supplémentaires, consultez : http://lcamtuf.coredump.cx/afl/
Pour échanger avec d'autres utilisateurs ou être informé des nouvelles fonctionnalités majeures, envoyez un courriel à [email protected].
** Consultez QuickStartGuide.txt si vous n'avez pas le temps de lire ce fichier. **
Le fuzzing est l'une des stratégies les plus puissantes et les plus éprouvées pour identifier les problèmes de sécurité dans les logiciels réels ; il est à l'origine de la grande majorité des bogues d'exécution de code à distance et d'élévation de privilèges découverts à ce jour dans les logiciels critiques pour la sécurité.
Malheureusement, le fuzzing est aussi relativement superficiel ; des mutations aveugles et aléatoires rendent très improbable l'atteinte de certains chemins de code dans le code testé, laissant certaines vulnérabilités totalement hors de portée de cette technique.
Il y a eu de nombreuses tentatives pour résoudre ce problème. L'une des premières approches - initiée par Tavis Ormandy - est la distillation de corpus. La méthode s'appuie sur les signaux de couverture pour sélectionner un sous-ensemble de graines intéressantes à partir d'un corpus massif et de haute qualité de fichiers candidats, puis les fuzzer par des moyens traditionnels. L'approche fonctionne exceptionnellement bien, mais nécessite qu'un tel corpus soit facilement disponible. De plus, les mesures de couverture par blocs ne fournissent qu'une compréhension très simpliste de l'état du programme et sont moins utiles pour guider l'effort de fuzzing sur le long terme.
D'autres recherches plus sophistiquées se sont concentrées sur des techniques telles que l'analyse du flux de programme (« exécution concolique »), l'exécution symbolique ou l'analyse statique. Toutes ces méthodes sont extrêmement prometteuses dans un cadre expérimental, mais tendent à souffrir de problèmes de fiabilité et de performance en usage pratique - et n'offrent actuellement pas d'alternative viable aux techniques de fuzzing « aveugle ».
American Fuzzy Lop est un fuzzer par force brute couplé à un algorithme génétique d'une simplicité extrême mais d'une solidité à toute épreuve, guidé par l'instrumentation. Il utilise une forme modifiée de couverture d'arêtes pour détecter sans effort les changements subtils et localisés du flux de contrôle du programme.
En simplifiant un peu, l'algorithme global peut se résumer ainsi :
Charger les cas de test initiaux fournis par l'utilisateur dans la file d'attente,
Prendre le fichier d'entrée suivant dans la file d'attente,
Tenter de réduire le cas de test à la plus petite taille qui ne modifie pas le comportement mesuré du programme,
Muter le fichier de manière répétée en utilisant une variété équilibrée et bien étudiée de stratégies de fuzzing traditionnelles,
Si l'une des mutations générées a entraîné une nouvelle transition d'état enregistrée par l'instrumentation, ajouter la sortie mutée comme nouvelle entrée dans la file d'attente.
Revenir à l'étape 2.
Les cas de test découverts sont également élagués périodiquement pour éliminer ceux qui ont été rendus obsolètes par des découvertes plus récentes et à couverture plus élevée ; ils subissent également plusieurs autres étapes de minimisation des efforts pilotées par l'instrumentation.
Comme résultat secondaire du processus de fuzzing, l'outil crée un petit corpus autonome de cas de test intéressants. Ceux-ci sont extrêmement utiles pour initialiser d'autres régimes de test exigeants en travail ou en ressources - par exemple, pour les tests de résistance des navigateurs, des applications bureautiques, des suites graphiques ou des outils propriétaires.
Le fuzzer est testé de manière approfondie pour offrir dès sa sortie de boîte des performances de loin supérieures au fuzzing aveugle ou aux outils basés uniquement sur la couverture.
Lorsque le code source est disponible, l'instrumentation peut être injectée par un outil compagnon qui fonctionne comme un remplacement direct de gcc ou clang dans tout processus de compilation standard pour du code tiers.
L'instrumentation a un impact sur les performances relativement modeste ; en conjonction avec les autres optimisations implémentées par afl-fuzz, la plupart des programmes peuvent être fuzzés aussi vite, voire plus vite, qu'avec les outils traditionnels.
La méthode correcte pour recompiler le programme cible peut varier selon les spécificités du processus de compilation, mais une approche quasi universelle serait :
$ CC=/path/to/afl/afl-gcc ./configure $ make clean all
Pour les programmes C++, vous voudrez également définir CXX=/path/to/afl/afl-g++.
Les wrappers clang (afl-clang et afl-clang++) peuvent être utilisés de la même manière ; les utilisateurs de clang peuvent également opter pour un mode d'instrumentation plus performant, comme décrit dans llvm_mode/README.llvm.
Lorsque vous testez des bibliothèques, vous devez trouver ou écrire un programme simple qui lit des données à partir de stdin ou d'un fichier et les transmet à la bibliothèque testée. Dans un tel cas, il est essentiel de lier cet exécutable à une version statique de la bibliothèque instrumentée, ou de vous assurer que le bon fichier .so est chargé au moment de l'exécution (généralement en définissant LD_LIBRARY_PATH). L'option la plus simple est une compilation statique, généralement possible via :
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
Définir AFL_HARDEN=1 lors de l'appel de 'make' amènera le wrapper CC à activer automatiquement les options de durcissement du code qui facilitent la détection des bogues mémoire simples.
PS. Les utilisateurs d'ASAN sont invités à consulter le fichier notes_for_asan.txt pour connaître les mises en garde importantes.
Lorsque le code source n'est PAS disponible, le fuzzer offre un support expérimental pour l'instrumentation rapide et à la volée des binaires en boîte noire. Ceci est accompli avec une version de QEMU fonctionnant dans le mode moins connu d'« émulation d'espace utilisateur ».
QEMU est un projet distinct d'AFL, mais vous pouvez facilement compiler la fonctionnalité en faisant :
$ cd qemu_mode $ ./build_qemu_support.sh
Pour des instructions et des mises en garde supplémentaires, voir qemu_mode/README.qemu.
Ce mode est environ 2 à 5 fois plus lent que l'instrumentation au moment de la compilation, se prête moins bien à la parallélisation et peut présenter d'autres particularités.
Pour fonctionner correctement, le fuzzer nécessite un ou plusieurs fichiers de départ qui contiennent un bon exemple des données d'entrée normalement attendues par l'application ciblée. Il y a deux règles de base :
Gardez les fichiers petits. Moins de 1 ko est idéal, bien que ce ne soit pas strictement nécessaire. Pour une discussion sur l'importance de la taille, voir perf_tips.txt.
N'utilisez plusieurs cas de test que s'ils sont fonctionnellement différents les uns des autres. Il est inutile d'utiliser cinquante photos de vacances différentes pour fuzzer une bibliothèque d'images.
Vous pouvez trouver de nombreux bons exemples de fichiers de départ dans le sous-répertoire testcases/ fourni avec cet outil.
PS. Si un grand corpus de données est disponible pour le criblage, vous pouvez utiliser l'utilitaire afl-cmin pour identifier un sous-ensemble de fichiers fonctionnellement distincts qui exercent différents chemins de code dans le binaire cible.
Le processus de fuzzing lui-même est exécuté par l'utilitaire afl-fuzz. Ce programme nécessite un répertoire en lecture seule contenant les cas de test initiaux, un emplacement séparé pour stocker ses résultats, ainsi qu'un chemin vers le binaire à tester.
Pour les binaires cibles qui acceptent l'entrée directement depuis stdin, la syntaxe habituelle est :
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
Pour les programmes qui prennent l'entrée depuis un fichier, utilisez '@@' pour marquer l'emplacement dans la ligne de commande de la cible où le nom du fichier d'entrée doit être placé. Le fuzzer fera cette substitution pour vous :
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
Vous pouvez également utiliser l'option -f pour que les données mutées soient écrites dans un fichier spécifique. Ceci est utile si le programme attend une extension de fichier particulière ou autre.
Les binaires non instrumentés peuvent être fuzzés en mode QEMU (ajoutez -Q dans la ligne de commande) ou dans un mode traditionnel de fuzzing aveugle (spécifiez -n).
Vous pouvez utiliser -t et -m pour remplacer le délai d'attente et la limite de mémoire par défaut du processus exécuté ; de rares exemples de cibles pouvant nécessiter d'ajuster ces paramètres incluent les compilateurs et les décodeurs vidéo.
Des conseils pour optimiser les performances du fuzzing sont décrits dans perf_tips.txt.
Notez qu'afl-fuzz commence par exécuter une série d'étapes de fuzzing déterministes, qui peuvent prendre plusieurs jours. Si vous voulez des résultats rapides et approximatifs immédiatement, à la manière de zzuf ou honggfuzz, ajoutez l'option -d à la ligne de commande.
Consultez le fichier status_screen.txt pour savoir comment interpréter les statistiques affichées et surveiller la santé du processus. Assurez-vous de consulter ce fichier, surtout si des éléments de l'interface sont surlignés en rouge.
Le processus de fuzzing se poursuivra jusqu'à ce que vous appuyiez sur Ctrl-C. Au minimum, vous voulez laisser le fuzzer terminer un cycle de file d'attente, ce qui peut prendre de quelques heures à une semaine environ.
Trois sous-répertoires sont créés dans le répertoire de sortie et mis à jour en temps réel :
queue/ - cas de test pour chaque chemin d'exécution distinct, plus tous les fichiers de départ fournis par l'utilisateur. C'est le corpus synthétisé mentionné dans la section 2.
Avant d'utiliser ce corpus à d'autres fins, vous pouvez le réduire
à une taille plus petite à l'aide de l'outil afl-cmin. L'outil
trouvera un sous-ensemble plus petit de fichiers offrant une couverture équivalente.
crashes/ - cas de test uniques qui provoquent la réception d'un signal fatal par le programme testé (par exemple, SIGSEGV, SIGILL, SIGABRT). Les entrées sont groupées par signal reçu.
hangs/ - cas de test uniques qui provoquent un dépassement du délai d'attente du programme testé. Notez que lorsque les paramètres de délai d'attente par défaut (agressifs) sont en vigueur, cela peut être légèrement bruité en raison des pics de latence et d'autres phénomènes naturels.
Les crashes et les blocages sont considérés comme « uniques » si les chemins d'exécution associés impliquent des transitions d'état non observées dans les fautes précédemment enregistrées. Si un même bogue peut être atteint de plusieurs manières, il y aura une certaine inflation du comptage au début du processus, mais celle-ci devrait rapidement diminuer.
Les noms de fichiers des crashes et des blocages sont corrélés avec les entrées parentes, non fautives, de la file d'attente. Cela devrait faciliter le débogage.
Lorsque vous ne pouvez pas reproduire un crash trouvé par afl-fuzz, la cause la plus probable est que vous ne définissez pas la même limite de mémoire que celle utilisée par l'outil. Essayez :
$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Modifiez LIMIT_MB pour qu'il corresponde au paramètre -m passé à afl-fuzz. Sur OpenBSD, changez également -Sv en -Sd.
Tout répertoire de sortie existant peut également être utilisé pour reprendre des travaux interrompus ; essayez :
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]
Si vous avez gnuplot installé, vous pouvez également générer de jolis graphiques pour toute tâche de fuzzing active à l'aide d'afl-plot. Pour un exemple de ce à quoi cela ressemble, voir http://lcamtuf.coredump.cx/afl/plot/.
Chaque instance d'afl-fuzz occupe environ un cœur. Cela signifie que sur les systèmes multicœurs, la parallélisation est nécessaire pour utiliser pleinement le matériel. Pour des conseils sur la façon de fuzzer une cible courante sur plusieurs cœurs ou plusieurs machines en réseau, veuillez vous référer à parallel_fuzzing.txt.
Par défaut, le moteur de mutation d'afl-fuzz est optimisé pour les formats de données compacts - par exemple, les images, le multimédia, les données compressées, la syntaxe des expressions régulières ou les scripts shell. Il est quelque peu moins adapté aux langages au verbiage particulièrement verbeux et redondant - notamment HTML, SQL ou JavaScript.
Pour éviter les tracas de la création d'outils sensibles à la syntaxe, afl-fuzz offre un moyen d'initialiser le processus de fuzzing avec un dictionnaire optionnel de mots-clés de langage, d'en-têtes magiques ou d'autres jetons spéciaux associés au type de données ciblé
et de l'utiliser pour reconstruire la grammaire sous-jacente à la volée :
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
Pour utiliser cette fonctionnalité, vous devez d'abord créer un dictionnaire dans l'un des deux formats décrits dans testcases/README.testcases ; puis indiquer ce dictionnaire au fuzzer via l'option -x dans la ligne de commande.
Il n'y a aucun moyen de fournir des descriptions plus structurées de la syntaxe sous-jacente, mais le fuzzer en découvrira probablement une partie en se basant uniquement sur les retours de l'instrumentation. Cela fonctionne réellement en pratique, par exemple :
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
PS. Même lorsqu'aucun dictionnaire explicite n'est fourni, afl-fuzz tentera d'extraire les jetons de syntaxe existants dans le corpus d'entrée en surveillant l'instrumentation de très près lors des inversions de bits déterministes. Cela fonctionne pour certains types d'analyseurs et de grammaires, mais n'est pas aussi performant que le mode -x.
Le regroupement des crashes basé sur la couverture produit généralement un petit ensemble de données qui peut être rapidement trié manuellement ou avec un script GDB ou Valgrind très simple. Chaque crash est également traçable jusqu'à son cas de test parent non crashant dans la file d'attente, ce qui facilite le diagnostic des fautes.
Cela dit, il est important de reconnaître que certains crashes de fuzzing peuvent être difficiles à évaluer rapidement en termes d'exploitabilité sans beaucoup de débogage et d'analyse de code. Pour faciliter cette tâche, afl-fuzz prend en charge un mode très unique d'« exploration de crash » activé avec le drapeau -C.
Dans ce mode, le fuzzer prend un ou plusieurs cas de test crashants comme entrée, et utilise ses stratégies de fuzzing pilotées par les retours pour énumérer très rapidement tous les chemins de code qui peuvent être atteints dans le programme tout en le maintenant dans l'état crashant.
Les mutations qui n'entraînent pas de crash sont rejetées ; il en va de même pour toute modification qui n'affecte pas le chemin d'exécution.
Le résultat est un petit corpus de fichiers qui peut être examiné très rapidement pour voir quel degré de contrôle l'attaquant a sur l'adresse fautive, ou s'il est possible de dépasser une lecture hors limites initiale - et de voir ce qui se trouve en dessous.
Oh, encore une chose : pour la minimisation des cas de test, essayez afl-tmin. L'outil peut être utilisé de manière très simple :
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
L'outil fonctionne aussi bien avec les cas de test crashants que non crashants. En mode crash, il acceptera volontiers les binaires instrumentés et non instrumentés. En mode non crashant, le minimiseur s'appuie sur l'instrumentation AFL standard pour simplifier le fichier sans modifier le chemin d'exécution.
Le minimiseur accepte la syntaxe -m, -t, -f et @@ d'une manière compatible avec afl-fuzz.
Une autre addition récente à AFL est l'outil afl-analyze. Il prend un fichier d'entrée, tente d'inverser séquentiellement les octets et observe le comportement du programme testé. Il code ensuite en couleurs l'entrée en fonction des sections qui semblent critiques et de celles qui ne le sont pas ; bien que ce ne soit pas infaillible, il peut souvent offrir un aperçu rapide des formats de fichiers complexes. Plus d'informations sur son fonctionnement se trouvent vers la fin de technical_details.txt.
Veuillez garder à l'esprit que, comme beaucoup d'autres tâches intensives en calcul, le fuzzing peut mettre à rude épreuve votre matériel et le système d'exploitation. En particulier :
Votre processeur chauffera et aura besoin d'un refroidissement adéquat. Dans la plupart des cas, si le refroidissement est insuffisant ou cesse de fonctionner correctement, la vitesse du processeur sera automatiquement réduite. Cela dit, surtout lorsque vous fuzzez sur du matériel moins adapté (ordinateurs portables, smartphones, etc.), il n'est pas totalement impossible que quelque chose lâche.
Les programmes ciblés peuvent finir par s'accaparer de manière erratique des gigaoctets de mémoire ou remplir l'espace disque de fichiers indésirables. AFL essaie d'imposer des limites de mémoire de base, mais ne peut pas empêcher tous les incidents possibles. En fin de compte, vous ne devriez pas fuzzer sur des systèmes où la perspective d'une perte de données n'est pas un risque acceptable.- Le fuzzing implique des milliards de lectures et d'écritures sur le système de fichiers. Sur les systèmes modernes, elles seront généralement fortement mises en cache, ce qui se traduit par des entrées/sorties "physiques" assez modestes - mais de nombreux facteurs peuvent modifier cette équation. Il vous incombe de surveiller les problèmes potentiels ; avec des entrées/sorties très intensives, la durée de vie de nombreux disques durs et SSD peut être réduite.
Une bonne façon de surveiller les entrées/sorties disque sous Linux est la commande 'iostat' :
$ iostat -d 3 -x -k [...optional disk ID...]
Voici quelques-unes des mises en garde les plus importantes concernant AFL :
AFL détecte les anomalies en vérifiant si le premier processus créé meurt à cause d'un signal (SIGSEGV, SIGABRT, etc.). Les programmes qui installent des gestionnaires personnalisés pour ces signaux peuvent nécessiter la mise en commentaire du code correspondant. De la même manière, les anomalies dans les processus enfants générés par la cible fuzzée peuvent échapper à la détection, sauf si vous ajoutez manuellement du code pour les intercepter.
Comme pour tout autre outil de force brute, le fuzzer offre une couverture limitée si le chiffrement, les sommes de contrôle, les signatures cryptographiques ou la compression sont utilisés pour envelopper entièrement le format de données réel à tester.
Pour contourner ce problème, vous pouvez mettre en commentaire les vérifications correspondantes (voir experimental/libpng_no_checksum/ pour vous inspirer) ; si cela n'est pas possible, vous pouvez également écrire un postprocesseur, comme expliqué dans experimental/post_library/.
Il existe certains compromis regrettables avec ASAN et les binaires 64 bits. Cela n'est dû à aucun défaut spécifique d'afl-fuzz ; consultez notes_for_asan.txt pour des conseils.
Il n'existe pas de prise en charge directe pour le fuzzing des services réseau, des démons en arrière-plan ou des applications interactives qui nécessitent une interaction avec l'interface utilisateur pour fonctionner. Vous devrez peut-être apporter de simples modifications de code pour qu'ils se comportent de manière plus traditionnelle. Preeny peut également offrir une option relativement simple - voir : https://github.com/zardus/preeny
Quelques conseils utiles pour modifier les services réseau sont également disponibles sur : https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL ne génère pas de données de couverture lisibles par un humain. Si vous souhaitez surveiller la couverture, utilisez afl-cov de Michael Rash : https://github.com/mrash/afl-cov
Au-delà de cela, consultez INSTALL pour des conseils spécifiques à chaque plateforme.
Une grande partie des améliorations apportées à afl-fuzz n'aurait pas été possible sans les retours, les rapports de bogues ou les correctifs de :
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
Merci !
Des questions ? Des préoccupations ? Des rapports de bogues ? L'auteur peut généralement être joint à l'adresse [email protected].
Il existe également une liste de diffusion pour le projet ; pour y adhérer, envoyez un courriel à [email protected]. Ou, si vous préférez d'abord consulter les archives, essayez :
https://groups.google.com/group/afl-users
PS. Si vous souhaitez soumettre du code brut à intégrer au projet, veuillez noter que le copyright sur la majeure partie d'AFL est revendiqué par Google. Bien que vous conserviez le copyright sur vos contributions, ils demandent aux contributeurs d'accepter au préalable une simple CLA (accord de licence de contributeur) :
https://cla.developers.google.com/clas
Désolé pour la gêne occasionnée. Bien entendu, aucune CLA n'est requise pour les demandes de fonctionnalités ou les rapports de bogues.