In the first phase, individual modules of the software under test, i.e. fractions of coherent code, are fuzz tested independently of the original control flow of the software. Important results of this phase are the identification of potentially vulnerable modules and the collection of crashing arguments for phase three. In the second phase, directed fuzzing attempts to generate so-called navigation input to the original program such that modules previously identified as vulnerable are executed. In the third phase, the fuzzer focuses on triggering a bug or vulnerability in one of these modules by executing the entire software under test with specifically crafted inputs. Those crafted inputs incorporate both the navigation inputs of phase two to steer the programs execution towards potentially vulnerable modules, as well as the knowledge about arguments resulting in crashes from phase one. Each phase relies on the LLVM compiler framework to add its own instrumentation to the software under test.