A special "instrumented build" is used that allows the fuzzer to look into the program as it executes. We place it in its own build directory so it doesn't get confused with the production build.
In the source code, special behavior for fuzz testing can be implemented with `#ifdef __AFL_COMPILER`. For example, in fuzz builds, the KeePassXC CLI takes the database password from environment variable `KEEPASSXC_AFL_PASSWORD` to allow non-interactive operation.
*`-i findings/testcases`: The directory which contains the initial fuzzer input.
*`-o findings`: The directory in which to store fuzzer results.
*`-m 2000`: Fuzzer memory (in megabytes). Adjust as required if the fuzzer fails to start up.
*`-t 1000`: Timeout until a hang is detected (in milliseconds).
*`src/cli/keepassxc-cli`: The instrumented executable.
*`ls`: The subcommand we're testing.
*`@@`: The fuzzer replaces this by the name of a file with the generated input.
You may also need `export AFL_SKIP_CPUFREQ=1`.
If KeePassXC crashes or hangs when processing the input, the fuzzer writes the database file (that was used in place of `@@`) to the `findings/crashes` or `findings/hangs` directory, respectively.
To continue where the fuzzer left off, use `-i -`. To start over, remove and re-create the `findings` directory.