Fuzzing test using Afl-fuzz (American Fuzzy Lop) (ii)--detailed instructions for use (README.txt)

Not fully translated from: Http://lcamtuf.coredump.cx/afl/README.txt
Reprint please indicate the source.

The notes, which are readily translated, have yet to be collated. AFL algorithm

1) Load the initial test cases provided by the user into the queue;
2) Get the next test input file from the queue;
3) try to trim (trim) The test case (volume) to the minimum while maintaining the program behavior;
4) using the traditional fuzzy test strategy of the various existing research methods, repeat the variation file;
5) If the generated mutation results can drive a new state transition (via a pile record), the test case is added to the queue;
6) Move to step 2nd.

The test cases that have been discovered are also periodically replaced by new test cases that drive higher code coverage, or are removed with minimal measures driven by a number of other interpolation piles.

As a side effect of the fuzzy test step (side effect), the tool generates relatively small, self-contained test case corpus. These are very useful.

Because of these measures, the AFL can perform better than a blind fuzz or a code-coverage-driven tool. using the AFL to insert a pile into a program

In the case of the source code of the test program, the AFL can be used instead of GCC or clang as a compiler, and the AFL piles have a very low performance impact. Coupled with other Afl-fuzz performance optimizations, most programs can be quickly fuzzed and even faster than traditional tools.

The configuration of the recompile target program may vary depending on the program, but the common steps are:

$ CC=/PATH/TO/AFL/AFL-GCC./configure $ make clean all

For C + + programs, set to cxx=/path/to/afl/afl-g++

Programs that compile on clang can be set up in the same way, such as Afl-clang and afl-clang++. Clang users can also choose to take advantage of the high-performance plug-in mode mentioned by LLVM_MODE/README.LLVM.

When testing the Lib library, you need to find or write a simple program, from stdin or read data from a file, into the Lib library being tested. Therefore, it is important to connect the Lib library of the inserted pile to the executable in a static manner. Or make sure that the correct. so file is loaded (via Ld_library_path) while the program is running. The simplest option is to use static compilation, usually in the following ways:

$ CC=/PATH/TO/AFL/AFL-GCC./configure--disable-shared

When setting afl_harden=1 with the Make command, you can promote CC Automation code hardening options, making it easier to detect simple memory bugs. Libdislocator is an AFL-provided helper Lib (see Libdislocator/readme.dislocator for details), which can help uncover heap crashes. the binary program is inserted into the pile

In the absence of source code, you can use the "User space emulation" mode in Qumu to insert a pile into the binary. Specific operation:

$ CD Qemu_mode
$./build_qemu_support.sh

For instructions and notes on QEMU piles, see Qemu_mode/readme.qemu Choosing an initial test case

For normal operation, Fuzzer requires one or more good initial files containing the test input data, with two basic rules:
1) Reduce the size of the file. Files below 1kB are ideal, though not strictly required. As to why the initial file size will affect the test results, see Perf_tips.txt;
2) It is necessary to use multiple test cases only if each test case is capable of driving different functions in the program. There is no point in using 50 different images in the AFL Fuzz Image processing Lib library.

A very good test case can be found in the testcases/directory of this tool as the initial seed file.

If you have a larger data corpus, you can use the Afl-cmin tool to identify a subset of files that are different (drivers walk different code paths), that is, minimal set processing. fuzzy testing of binary system

Use the Afl-fuzz tool to fuzz the target binaries. Before running, you need read-only permissions for the directory that contains the initial test cases, the separate directories are used to store the findings in the test process, and the path to the binaries being tested.

For the target binaries that receive input directly from the stdin, the common syntax is

$./afl-fuzz-i Testcase_dir-o Findings_dir/path/to/program [...]

Where the params is tested by the program to accept command-line arguments.

If the input is read from a file, the @@ 标记 is used on the command line, and Afl-fuzz will replace "@@ 标记 with the test sample under the test sample directory (Testcase_dir) when it is actually executed. The corresponding commands are:

$./afl-fuzz-i Testcase_dir-o Findings_dir/path/to/program @@

You can use the-f parameter to write data that has already been mutated to a specific file. This is particularly useful for requirements that require specific file name extensions to be specified.

There are no piles. Binary can be fuzz by QEMU mode (add-q parameter on the command line) or in traditional blind fuzz mode (specified with the-n parameter).
You can use-t and-m to rewrite the default timeout and memory limit during program execution. However, it is rare to have this requirement (including in compilers and video codecs, etc.).

Some measures to optimize fuzzing performance See Perf_tips.txt

Afl-fuzz starting from the array fuzz, it may take a few days. But it produces a cleaner test case. If you want fast and dirty results in a short time, you can use Zzuf and other traditional fuzzy test tools (add-D parameters). Output Interpretation

From Status_screen.txt, you can find the meanings of the fields in the explicit interface and monitor the health of the program being tested. In the interface if any of the fields are red Gaoliangxian, you can check this file to confirm the situation.

The fuzzing process will continue to know that users are pressing CTRL-C, and even if they want to fuzzer a test of a queue cycle, it can take a few hours to a week.
There are three subdirectories in the output directory, namely:

-queue/ test Cases for each of the different execution paths, including all user-supplied initialization test case files. This is the composite corpus mentioned earlier. You can use the Afl-cmin tool to tighten the size of the corpus before using it to any program. This tool will look for smaller test set files (keep the same code, Edge overlay).

-crashes/ can lead to test cases where the test program obtains the uniqueness of a deadly signal (fatal signal) (such as SIGSEGV, Sigill, SIGABRT, etc.).

-hangs/ A unique test case that can cause the test program to time out. The default time limit. After the execution time limit exceeds the default of 1 seconds or the value set with the-t parameter, the test case is recorded in this folder. These values can also be set using Afl_hang_tmout, but this is often rarely required.

Crashes and hangs are considered unique if the associated execution path contains any state transitions that are not included in the records related to the errors previously recorded. If a single bug can be triggered by multipath, the count calculation will be temporarily inflated, but will gradually become less in subsequent operations.

Crashes and hangs have file names associated with parent nodes and queue nodes that are not faulted. This can help with debugging.

When crash cannot be reproduced using Afl-fuzz, the most likely cause is that the same memory limit is not set. You can try the following commands:

$ limit_mb=50
$ (ulimit-sv $[limit_mb <<);/path/to/tested_binary ...)

In the above command, the change LIMIT_MB parameter matches the-m parameter.

Any work that already exists for the output directory can be re-recovered:

$./afl-fuzz-i--O existing_output_dir [...]

If Gnuplot is installed, you can use Afl-plot to generate some beautiful pictures for the program you are fuzzing, see http://lcamtuf.coredump.cx/afl/plot/. Parallel Fuzzy testing

Each Afl-fuzz instance consumes only one CPU core. This is important to make use of parallelization in multicore systems to increase the utilization of hardware.
The parallel fuzzing mode also provides a simple way of interfacing to other test tools, including the symbol execution tool. See Parallel_fuzzing.txt Test dictionary (fuzzing dictionaries) for details

By default, AFL is better suited for fuzzing of compact data formats, including images, multimedia, compressed data, regular expression syntax, or shell scripts, and support is not good for cumbersome, redundant data such as Html,sql and JavaScript.

To avoid the hassle of building grammatical-sensitive tools, Afl-fuzz provides a way to relate symbols to language keywords, magic headers, or other special symbols and target data types. The fuzzing process of the dictionary can be selected. Using the method above to reconstruct the underlying syntax is currently under development. See:
Http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html

If you want to use the above features, you first need to create a dictionary for one or both of the formats described in Dictionaries/readme.dictionaries, and then specify it with the-x parameter option in the command. (Some common dictionaries are already available in subdirectories).

Afl-fuzz has no way to provide a more complex description of the underlying syntax (syntax), but Fuzzer will probably solve some of the problems by inserting feedback from the piles. See:
Http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html

In addition, even in the absence of a detailed dictionary, Afl-fuzz will attempt to extract the existing syntax identifier from the input corpus by observing the form of a pile. These work are valid for some types of parsing and syntax, but not as well as the pattern specified by the-x parameter mentioned above.

If the dictionary is very rare, another option is to have the AFL run for a while, and then use identity (token) to capture the library as the AFL tool. For details, see Libtokencap/readme.tokencap crash Classification (Crash triage)

Crash classifications based on code coverage can often generate small datasets that can be quickly and manually categorized, or using simple gdb or valgrind scripts. Each crash is also traceable to its corresponding non-crash test case in the queue, which makes it easier to diagnose errors.

Some fuzzing-out crash are difficult to quickly assess their availability, and require a lot of debugging and code analysis work. To help solve this problem, Afl-fuzz supports a more original "Crash exploration" mode, specifically specified in the command with the-c parameter.

In this mode, Fuzzer uses one or more crash test cases as input, and then uses a feedback-driven fuzzing strategy to quickly enumerate all code paths that can reach the point of collapse.

A sample generated in the compilation that does not cause a crash will be discarded, and the test input without triggering a new path will be discarded as well.
The output is a small corpus (corpus) that contains a crash sample, which can be quickly checked for how much control can be done by the crash point, or whether it is possible to read through the bounds and view information in other memory.

To minimize the test set, you can still use the Afl-tmin tool:

$./afl-tmin-i Test_case-o Minimized_result--/path/to/program [...]

This tool also applies to the crash sample set and the normal sample set, and in crash mode, it is received in the form of a plug-in and a non-insertion pile binary. In non-crash mode, minimizing processing relies on the standard AFL piles, which makes it easier to make files without changing the execution path.
Another feature recently added to the AFL is the Afl-analyze tool. This tool, in the case of a test input, executes the driver, attempts to change the bytes continuously, and then observes the behavior of the program being tested. The code for the more important (critical) section area (sections) is then labeled with color, which often allows you to quickly see the complex file format. More details: technical_details.txt