Domain-Specific Fuzzing with Waypoints using FuzzFactory

Recently I started learning about Fuzzing using American Fuzzy Lop aka AFL. While reading and improving my skills about coverage-guided fuzzer i.e; AFL, I got know about FuzzFactory which generalizes coverage-guided fuzzing to domain-specific testing goals. FuzzFactory allows users to guide the fuzzer's search process without having to modify anything in AFL's search algorithm.

Entire crux of Fuzzfactory lies on concept called WayPoints i.e; intermediate inputs that are saved during the fuzzing loop. These inputs need not increase code coverage, but they are saved because they make some sort of domain-specific progress. FuzzFactory's LLVM-based domain-specific instrumentation currently supports six domain-specific feedback methods slow, perf, mem, valid, cmp, diff deduced from various fuzzer's.

Lets get try to fuzz XpdfReader using FuzzFactory.

Firstly you need to git clone the FuzzFactory from the official repository and run make in the root project directory. Then compile the xpdfReader using afl-clang-fast and afl-clang-fast++ that supports domain-specific instrumentation. In below example we are using 2 feedback methods i.e; cmp and mem which are defined using WAYPOINTS.

Once cmake is done we should see below screen.

Now lets make the code using support for ASAN. We can see in below output Found domain: cmp or mem and no. of instrumented location for CmpFeedback and MemAllocFeedback.

Once make is done we should see below screen, which means all the binaries are successfully compiled and instrumented with required support for fuzzing.

We can verify same using  by using nm and grep.

Now in order to fuzz using afl-fuzz we need input files aka seeds. So create 2 folder in and out for input files and output files. We copy seed files to in folder.

Then we start the afl-fuzz in Master and Slave mode for task distribution and more executions. The only difference between the -M and -S modes is that the master instance will still perform deterministic checks; while the slaves will proceed straight to random tweaks.

Once the fuzzing starts, we can see the respective folder for each instance is created in the out folder.

Now lets see how many instances of afl-fuzz are we running using screen command.

We can also check the CPU usage using afl-gotcpu.

Using command screen -rd master/slave1/slave2 we can see the current state of fuzzing in each instance. The rest of the fuzzing session is similar to running AFL as usual.

Note :- If exec speed is slow, using afl-cmin we can minimize the size of seed files.

During fuzzing, the following log file is created with verbose output about domain-specific feedback: fuzzfactory.log

For debugging your domain-specific instrumentation, FuzzFactory provides a utility tool called afl-showdsf that analyzes domain-specific feedback from one or more saved inputs. 

Now keep the fuzzer running for time being till you receive some fruitful crashes. (Have Patience)

Happy Fuzzing !!

Reference :- https://github.com/rohanpadhye/FuzzFactory
https://www.youtube.com/watch?v=34A1jtgfgsU