https://github.com/googleprojectzero/winafl/blob/master/readme_pt.md
Tag: afl
UEFIfuzzing: UEFI applications and libraries for AFL fuzzing
This edk2 pkg contains UEFI applications used to control AFL fuzzing.
These applications are for use with this version of TriforceAFL.
AFL-Unicorn: fuzz any architecture supported by Unicorn
https://twitter.com/revskills/status/928382801400991744
afl-unicorn let’s you fuzz any piece of binary that can be emulated by Unicorn Engine.
https://github.com/njv299/afl-unicorn
http://www.unicorn-engine.org/
https://hackernoon.com/afl-unicorn-fuzzing-arbitrary-binary-code-563ca28936bf
[…]Unicorn Mode works by implementing the block-edge instrumentation that AFL’s QEMU Mode normally does into Unicorn Engine. Basically, AFL will use block coverage information from any emulated code snippet to drive its input generation. The whole idea revolves around proper construction of a Unicorn-based test harness, as shown in the figure below:
WinAFL: AFL fork for Windows
Excerpt from readme:
[…]
Original AFL code written by Michal Zalewski <lcamtuf@google.com>
Windows fork written and maintained by Ivan Fratric <ifratric@google.com>
Copyright 2016 Google Inc. All Rights Reserved.
[…] Unfortunately, the original AFL does not work on Windows due to very *nix-specific design (e.g. instrumentation, forkserver etc). This project is a fork of AFL that uses different instrumentation approach which works on Windows even for black box binary fuzzing. […] The WinAFL approach: Instead of instrumenting the code at compilation time, WinAFL relies on dynamic instrumentation using DynamoRIO to measure and extract target coverage. This approach has been found to introduce an overhead about 2x compared to the native execution speed, which is comparable to the original AFL in binary instrumentation mode. To improve the process startup time, WinAFL relies heavily on persistant fuzzing mode, that is, executing multiple input samples without restarting the target process. This is accomplished by selecting a target function (that the user wants to fuzz) and instrumenting it so that it runs in a loop. […]
More info:
http://dynamorio.org/
https://github.com/DynamoRIO/dynamorio
https://github.com/ivanfratric/winafl
AFL support added to Linux Kernel
https://twitter.com/lcamtuf/status/734055720010670080
The Linux kernel just got a patch to add AFL support! I don’t believe FreeBSD has such a feature, yet…. 😐
[PATCH] kcov: add AFL-style tracing
AFL uses a fixed-size buffer (typically 64 KiB) where each byte is a counter representing how many times an A -> B branch was taken. Of course, since the buffer is fixed size, it’s a little imprecise in that e.g. two different branches could map to the same counter, but in practice it works well.
See afl:docs/technical_details.txt for more information.
fuzzing OpenPOWER firmware
Stewart Smith of IBM has an interesting new blog post about using afl to fuzz OpenPOWER’s firmware:
https://www.flamingspork.com/blog/2016/05/19/fuzzing-firmware-afl-fuzz-skiboot/
fuzzing tool: afl
Hanno Böck has an article on LWN.net on the fuzzing tool afl, American Fuzzy Lop, created by Michał Zalewski of the Google security team:
AFL is a powerful fuzzer, and the above article is a good introduction. There are some more extensive tutorials on afl site, as well as the Fuzzing Project site. Hanno created the Fuzzing Project, which uses FOSS fuzzers to find and fix defects in core FOSS projects. Besides afl, there’s a Python attempt at a version, for those that prefer Python.
http://lcamtuf.coredump.cx/afl/
http://jwilk.net/software/python-afl
https://fuzzing-project.org/tutorials.html
(I wish there was more widespread usage of AFL in coreboot, tianocore, U-Boot, SeaBIOS, especially now that SMM is inside OVMF now…)
Firmware Security 