The purpose of this exercise is to identify where bottlenecks appear in a real-world application. For this we will use perf and American Fuzzy Lop (AFL).

First, let's compile AFL and all related tools. We initialize / update a few environment variables to make them more accessible.

$ git clone https://github.com/google/AFL
 
$ pushd AFL
$ make -j $(nproc)
 
$ export PATH="${PATH}:$(pwd)"
$ export AFL_PATH="$(pwd)"
$ popd

Now, check that it worked:

$ afl-fuzz --help
$ afl-gcc --version

The program under test will be fuzzgoat, a vulnerable program made for the express purpose of illustrating fuzzer behaviour. To prepare the program for fuzzing, the source code has to be compiled with afl-gcc. afl-gcc is a wrapper over gcc that statically instruments the compiled program. This analysis code that is introduced is leveraged by afl-fuzz to track what branches are taken during execution. In turn, this information is used to guide the input mutation procedure.

$ git clone https://github.com/fuzzstati0n/fuzzgoat.git
 
$ pushd fuzzgoat
$ CC=afl-gcc make
$ popd

If everything went well, we finally have our instrumented binary. Time to run afl. For this, we will use the sample seed files provided by fuzzgoat. Here is how we call afl-fuzz:

• the -i flag specifies the directory containing the initial seed
• the -o flag specifies the active workspace for the afl instance
• -- separates the afl flag from the binary invocation command
• everything following the -- separator is how the target binary would normally be invoked in bash; the only difference is that the input file name will be replaced by @@

$ afl-fuzz -i fuzzgoat/in -o afl_output -- ./fuzzgoat/fuzzgoat @@

If you look in the afl_output/ directory, you will see a few files and directories; here is what they are:

• .cur_input : current input that is tested; replaces @@ in the program invocation.
• fuzzer_stats : statistics generated by afl, updated every few seconds by overwriting the old ones.
• fuzz_bitmap : a 64KB array of counters used by the program instrumentation to report newly found paths. For every branch instruction, a hash is computed based on its address and the destination address. This hash is used as an offset into the 64KB map.
• plot_data : time series that can be used with programs such as gnuplut to create visual representations of the fuzzer's performance over time.
• queue : backups of all the input files that increased code coverage at that time. Note that some of the newer files may provide the same coverage as some of the old, and then some. The reason why the old ones are not removed when this happens is that checking that would be a pain and would bog down the fuzzing process.
• hangs : inputs that caused the process to execute past a timeout limit (20ms by default).
• crashes : files that generate crashes. If you want to search for bugs and not just test for coverage increase, you should compile your binary with a sanitizer (e.g.: ASAN).

$ perf record -e <event> <command recorded> 

$ perf record -e cycles afl-fuzz -i ./fuzzgoat/in -o afl_out -- ./fuzzgoat/fuzzgoat @@ #and let it run for a few minutes
$ perf report   #to print the recorded info

As a result you should get a report showing a list of the most used functions. Make sure to add a ss of it.