On June 13, Fortego Engineer Alex Wilson led one of the most engaging tech talks in the history of Fortego. Is that overstating it? Not at all! By the end of his presentation on how to use AFL to fuzz programs, Alex had answered a total of 17 questions (oh yeah, we counted…!) which he answered like a pro. Interested in some of the highlights from his talk? See Alex’s quick list of tips and resources below. You can also read through his presentation deck here.
- What AFL Is: AFL is an excellent, popular, and easy-to-use fuzzer. Get it from here.
- Great Guide: Looking for a guide on how your fuzzing workflow should go? Check out this blog post.
- AFL Derivatives and Forks: There are loads of them. Here’s a nice summary of a lot of them.
- Blackbox Fuzzing: Blackbox fuzzing is providing an input to the program and only observing the final result, whether this be a crash or a normal exit or other behavior. Fuzzing that knows something about the internals of your program is much more effective, and this is known as gray-box fuzzing. We try to bump blackbox fuzzing up to some form of gray-box fuzzing whenever possible.
- AFL Limitations: AFL is not the end-all be-all for fuzzers, but is often used as the benchmark to beat. If you want to fuzz only part of a program and you can’t run it on your own machine as-is, check out the AFL-Unicorn fork (and my presentation deck here!).
- AFL-Unicorn Pros and Cons
- Pros: it allows the user to start and end execution wherever they want in the program, instead of running it end-to-end like normal AFL does. It also can fuzz programs that are difficult to run, such as those for other processors.
- Cons: Execution speed is orders of magnitude slower than normal AFL. It requires a couple days of setup, and the user must be able to reverse engineer and attach a debugger to the program.