Toolkits

Preprocessor

This part is implemented based on AFL's LLVM mode, where the distance generation is inspired from Bohme's CCS2017 paper "Directed Greybox Fuzzing" but with our augments in multiple aspects. It consists of the following tools:

1. fot-diffs: This is used in DGF to generate the target sites (lines) for patch testing between two commits. For other scenarios, the target sites can be manually specified.
2. fot-pp/fot-pp++: This is a wrapper of the Clang/Clang++ compiler. It utilizes the LLVM Gold Linker to generate LLVM Bitcode for the target (Program Under Test, or PUT for short) binaries (executables, shared libraries); in addition, it guarantees that the binaries are compiled with debug information. Other options (specified by environment variables) ensure that the compilation is compatible with the compilation during instrumentation. Essentially, this procedure will always succeed as long as the project can be compiled with Clang/Clang++ and can be linked with the Gold linker. The output is the binaries embedded with debug information.
3. libfot-tgt.so: This is a regular LLVM analysis pass that analyzes the generated LLVM Bitcode executable. It generates 1) call graph of the whole binary; 2) the CFG for all the functions in the Bitcode; 3) call site locations; 4) the target functions and target basic blocks (when DGF is applied); 5) function list in the binary. This is implemented as a LLVM opt plugin, the only option passed is -fot-conf=/path/to/llvm.toml which takes a configuration file (e.g., llvm.toml) used throughout the static analysis. For 1), the analysis is based on the result of according to our forked SVF pointer analysis, the output is a yaml file "callgraph.yaml" (thanks to LLVM Yaml serialization/deserialization module).
4. fot-dists: This is used to calculate the (inverse of the) scores of the basicblocks in the exercised binaries. When used in static vulnerability integrated fuzzing, it corresponds to the vulnerability probabilities; when used in DGF, it means the distance.
5. fot-clang/fot-clang++: This is the actual part that does the instrumentation; it is still a wrapper for Clang/Clang++. It involves three built-in categories of instrumentation: 1) basic block transition; 2) basic block scores; 3) function IDs. For 1), this is exactly the same as AFL's LLVM mode instrumentation, by writing to the shared memory with the arithmetic results of previous basic block ID and the current basic block ID (see its technical details). For 2), it collects measures the scores for each basicblocks. For 3), it writes each function ID to another shared memory that store only the function IDs. Different from the other shard memory used for basic blocks, the IDs are maintained by the redis and keep increasing. Each instrumentation information (function name, location, ID) is also kept in redis as a hash table. The output of the instrumentor is the instrumented binary. It accepts one option -fot-conf=/path/to/llvm.toml. This option can be directly appended to the CFLAGS and CXXFLAGS environment variables. For most of the projects, it is a drop-in replacement for Clang/Clang++ driver without any other manual work.
6. fot-funcs: This maps the functions and its IDs, and the distances. It does two things: 1) extract the project function metadata; 2) mapping the function information in the binary with the project function metadata.
7. fot-sem: This can be used as both a standalone tool or a library that generates the mutated variants of the semantic aware seed files. It is based on Antlr4 and presently provides semantic generators for XML/Json/CSS files but can be easily extended to support other file types such as C/C++/Python etc (see a full list at antlr/antlr4-grammars) by providing the "g4" and mutation visitor against the corresponding AST structure. When used by fot-fuzz, it is invoked via a JNI; when used as a standalone tool, it works like radamsa.
8. fot-radamsa: This is a drop-in replacement for radamsa without fot-sem's features. The usage is however more intuitive and it provides finer-grained mutations. This is implemented on top of FOT's core mutation modules.
9. Other tools such as fot-cmin/fot-tmin/fot-showmap etc are inherited from AFL.

Fuzzer

The fuzzer parts actually consists of two major levels: one is the core libraries used for common fuzzing purposes; the other provides our default dynamic fuzzing implementations.

The core libraries include multiple modules:

• common I/O utilities
• seed generation utilities
• seed mutations
• seed queue operations
• monitored executions, including executor and the feedback collector
• seed scoring utilities
• synchronization utilities
• other common fuzzing for state bookkeeping
• fuzzing configuration utilities
• ...

There are two built-in fuzzing tools built on top of these modules:

• fot-simp: the fuzzer run in single-thread mode. This simulates the behaviors of afl-fuzz.
• fot-fuzz: the fuzzer that can run in multi-threaded mode. This is different from the other multi-threaded fuzzing tools such as libFuzzer or honggfuzz since we provide an overall manager ("conductor") to synchronize all the mutation traces. The generated seeds from each fuzzing worker is passed to the conductor in a message passing style (see the figure below).

Complementary toolchain

• fot-ui: This works with FOT's fuzzer by grabbing the snapshot of the current fuzzing status and analyzing the results. It provides web-UI to display the basic fuzzing information such as found crashes, execution speed, etc. It also provides coverage statistics, fuzzing trending when required.
• fot-replay: This runs on the generated seeds that can lead to abnormal behaviors such as crashes or time-outs. It utilizes GDB (or LLDB) to triage the crashes.
• fot-report: This additionally analyzes the crashes, and report statistics during fuzzing.