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 `KEYPASSXC_AFL_PASSWORD` to allow non-interactive operation.
## Prepare Fuzzer Input
To get the fuzzer started, we provide empty password database files (the password is `secret`).
$ cd buildafl
$ mkdir -p findings/testcases
$ cp ../share/empty*.kdbx findings/testcases
The fuzzer works by running KeePassXC with variations of this input, mutated in ways that make the program crash or hang.
This fuzz-tests the `ls` command of the KeePassXC CLI, which loads and decrypts a database file and then lists its contents. The parameters mean:
*`KEYPASSXC_AFL_PASSWORD=secret`: In fuzz test builds, the KeePassXC CLI takes the database password from this environment variable.
*`-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.
