Lines Matching +full:gtk +full:- +full:doc +full:- +full:tools
1 # The afl-fuzz approach
3 AFL++ is a brute-force fuzzer coupled with an exceedingly simple but rock-solid
4 instrumentation-guided genetic algorithm. It uses a modified form of edge
5 coverage to effortlessly pick up subtle, local-scale changes to program control
8 Note: If you are interested in a more current up-to-date deep dive how AFL++
10 [https://blog.ritsec.club/posts/afl-under-hood/](https://blog.ritsec.club/posts/afl-under-hood/)
14 1) Load user-supplied initial test cases into the queue.
21 4) Repeatedly mutate the file using a balanced and well-researched variety of
30 have been obsoleted by newer, higher-coverage finds; and undergo several other
31 instrumentation-driven effort minimization steps.
34 self-contained corpus of interesting test cases. These are extremely useful for
35 seeding other, labor- or resource-intensive testing regimes - for example, for
36 stress-testing browsers, office applications, graphics suites, or closed-source
37 tools.
39 The fuzzer is thoroughly tested to deliver out-of-the-box performance far
40 superior to blind fuzzing or coverage-only tools.
44 This section provides an overview of the status screen - plus tips for
53 always means "consult this doc" :-)
61 - For GNOME Terminal, go to `Edit > Profile` preferences, select the "colors"
62 tab, and from the list of built-in schemes, choose "white on black".
63 - For the MacOS X Terminal app, open a new window using the "Pro" scheme via the
70 side effects - sorry about that.
80 The top line shows you which mode afl-fuzz is running in (normal: "american
82 AFL++. Next to the version is the banner, which, if not set with -T by hand,
83 will either show the binary name being fuzzed, or the -M/-S main/secondary name
90 +----------------------------------------------------+
95 +----------------------------------------------------+
98 This section is fairly self-explanatory: it tells you how long the fuzzer has
112 (`-m`) is too restrictive and the program exits after failing to allocate a
117 red warning in this section, too :-)
122 +-----------------------+
127 +-----------------------+
131 - that is, the number of times the fuzzer went over all the interesting test
139 To help make the call on when to hit `Ctrl-C`, the cycle counter is color-coded.
141 are still being made in subsequent rounds, then blue when that ends - and
147 unique faults. The test cases, crashes, and hangs can be explored in real-time
149 [#interpreting-output](#interpreting-output).
154 +-------------------------------------+
157 +-------------------------------------+
170 +--------------------------------------+
173 +--------------------------------------+
185 - Absolute numbers below 200 or so suggest one of three things: that the program
187 linked against a non-instrumented copy of the target library); or that it is
190 - Percentages over 70% may very rarely happen with very complex programs that
191 make heavy use of template-generated code. Because high bitmap density makes
202 `8.00` (every bit in the 8-bit map hit), but will probably never reach that
211 +-------------------------------------+
216 +-------------------------------------+
219 This part gives you an in-depth peek at what the fuzzer is actually doing right
222 - calibration - a pre-fuzzing stage where the execution path is examined to
225 - trim L/S - another pre-fuzzing stage where the test case is trimmed to the
228 - bitflip L/S - deterministic bit flips. There are L bits toggled at any given
229 time, walking the input file with S-bit increments. The current L/S variants
231 - arith L/8 - deterministic arithmetics. The fuzzer tries to subtract or add
232 small integers to 8-, 16-, and 32-bit values. The stepover is always 8 bits.
233 - interest L/8 - deterministic value overwrite. The fuzzer has a list of known
234 "interesting" 8-, 16-, and 32-bit values to try. The stepover is 8 bits.
235 - extras - deterministic injection of dictionary terms. This can be shown as
236 "user" or "auto", depending on whether the fuzzer is using a user-supplied
237 dictionary (`-x`) or an auto-created one. You will also see "over" or
240 - havoc - a sort-of-fixed-length cycle with stacked random tweaks. The
243 assorted dictionary-related operations (if a dictionary is supplied in the
245 - splice - a last-resort strategy that kicks in after the first full queue cycle
249 - sync - a stage used only when `-M` or `-S` is set (see
250 [fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores)).
255 The remaining fields should be fairly self-evident: there's the exec count
259 time - and if it stays below 100, the job will probably take very long.
262 see the [best_practices.md#improving-speed](best_practices.md#improving-speed)
268 +--------------------------------------+
273 +--------------------------------------+
290 +-----------------------------------------------------+
299 +-----------------------------------------------------+
302 This is just another nerd-targeted section keeping track of how many paths were
305 assumptions about the usefulness of the various approaches taken by afl-fuzz.
316 enable with -D)".
323 +---------------------+
330 +---------------------+
339 instrumentation-guided approach taken by afl-fuzz.
343 really wants to get to in this queue cycle (the non-favored entries may have to
361 - The use of uninitialized memory in conjunction with some intrinsic sources of
364 - Attempts to manipulate persistent resources, such as left over temporary files
366 double-check to make sure the program isn't bailing out prematurely. Running
369 - Hitting some functionality that is actually designed to behave randomly.
372 - Multiple threads executing at once in semi-random order. This is harmless when
375 * Use afl-clang-fast from [instrumentation](../instrumentation/) - it uses a
376 thread-local tracking model that is less prone to concurrency issues,
378 `./configure` options include `--without-threads`, `--disable-pthreads`, or
379 `--disable-openmp`.
382 - In persistent mode, minor drops in the "stability" metric can be normal,
383 because not all the code behaves identically when re-entered; but major dips
385 subsequent iterations (e.g., due to incomplete clean-up or reinitialization of
405 [fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores).
411 are ready to run, but not how resource-hungry they may be. It also doesn't
415 If you want a more accurate measurement, you can run the `afl-gotcpu` utility
420 See [#understanding-the-status-screen](#understanding-the-status-screen) for
425 The fuzzing process will continue until you press Ctrl-C. At a minimum, you want
430 in real-time:
432 - queue/ - test cases for every distinctive execution path, plus all the
436 it to a smaller size using the afl-cmin tool. The tool will find
439 - crashes/ - unique test cases that cause the tested program to receive a fatal
443 - hangs/ - unique test cases that cause the tested program to time out. The
445 larger of 1 second and the value of the -t parameter. The value can
446 be fine-tuned by setting AFL_HANG_TMOUT, but this is rarely
450 involve any state transitions not seen in previously-recorded faults. If a
455 non-faulting queue entries. This should help with debugging.
460 active fuzzing task using afl-plot. For an example of how this looks like, see
463 You can also manually build and install afl-plot-ui, which is a helper utility
464 for showing the graphs generated by afl-plot in a graphical window using GTK.
468 sudo apt install libgtk-3-0 libgtk-3-dev pkg-config
481 found in a machine-readable format in the fuzzer_stats file in the output
484 - `start_time` - unix time indicating the start time of afl-fuzz
485 - `last_update` - unix time corresponding to the last update of this file
486 - `run_time` - run time in seconds to the last update of this file
487 - `fuzzer_pid` - PID of the fuzzer process
488 - `cycles_done` - queue cycles completed so far
489 - `cycles_wo_finds` - number of cycles without any new paths found
490 - `time_wo_finds` - longest time in seconds no new path was found
491 - `execs_done` - number of execve() calls attempted
492 - `execs_per_sec` - overall number of execs per second
493 - `corpus_count` - total number of entries in the queue
494 - `corpus_favored` - number of queue entries that are favored
495 - `corpus_found` - number of entries discovered through local fuzzing
496 - `corpus_imported` - number of entries imported from other instances
497 - `max_depth` - number of levels in the generated data set
498 - `cur_item` - currently processed entry number
499 - `pending_favs` - number of favored entries still waiting to be fuzzed
500 - `pending_total` - number of all entries waiting to be fuzzed
501 - `corpus_variable` - number of test cases showing variable behavior
502 - `stability` - percentage of bitmap bytes that behave consistently
503 - `bitmap_cvg` - percentage of edge coverage found in the map so far
504 - `saved_crashes` - number of unique crashes recorded
505 - `saved_hangs` - number of unique hangs encountered
506 - `last_find` - seconds since the last find was found
507 - `last_crash` - seconds since the last crash was found
508 - `last_hang` - seconds since the last hang was found
509 - `execs_since_crash` - execs since the last crash was found
510 - `exec_timeout` - the -t command line value
511 - `slowest_exec_ms` - real time of the slowest execution in ms
512 - `peak_rss_mb` - max rss usage reached during fuzzing in MB
513 - `edges_found` - how many edges have been found
514 - `var_byte_count` - how many edges are non-deterministic
515 - `afl_banner` - banner text (e.g., the target name)
516 - `afl_version` - the version of AFL++ used
517 - `target_mode` - default, persistent, qemu, unicorn, non-instrumented
518 - `command_line` - full command line used for the fuzzing session
524 can turn this into a nice progress report with the included `afl-plot` tool.