From d9e39be4e8dd0242877412d1a17589acc825292e Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 16:49:16 +0100 Subject: Remove the word "simply" --- frida_mode/DEBUGGING.md | 6 +++--- frida_mode/MapDensity.md | 14 +++++++------- frida_mode/README.md | 10 +++++----- frida_mode/Scripting.md | 2 +- 4 files changed, 16 insertions(+), 16 deletions(-) (limited to 'frida_mode') diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md index 9cdc5eb6..b703ae43 100644 --- a/frida_mode/DEBUGGING.md +++ b/frida_mode/DEBUGGING.md @@ -160,9 +160,9 @@ Lastly, if your defect only occurs when using `afl-fuzz` (e.g., when using shared memory mapping being created for it to record its data), it is possible to enable the creation of a core dump for post-mortem analysis. -Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is simply -set to a filename (AFL++ encourages you to set it to the value `core` in any -case since it doesn't want any handler applications getting in the way). +Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is set to a +filename (AFL++ encourages you to set it to the value `core` in any case since +it doesn't want any handler applications getting in the way). Next, set `ulimit -c unlimited` to remove any size limitations for core files. diff --git a/frida_mode/MapDensity.md b/frida_mode/MapDensity.md index b6a96ca0..50f2720f 100644 --- a/frida_mode/MapDensity.md +++ b/frida_mode/MapDensity.md @@ -77,13 +77,13 @@ evenly distributed. We start with a large address and need to discard a large number of the bits to generate a block ID which is within range. But how do we choose the unique bits of the address versus those which are the same for every block? The high bits of -the address may simply be all `0s` or all `1s` to make the address canonical, -the middle portion of the address may be the same for all blocks (since if they -are all within the same binary, then they will all be adjacent in memory), and -on some systems, even the low bits may have poor entropy as some use fixed -length aligned instructions. Then we need to consider that a portion of each -binary may contain the `.data` or `.bss` sections and so may not contain any -blocks of code at all. +the address may be all `0s` or all `1s` to make the address canonical, the +middle portion of the address may be the same for all blocks (since if they are +all within the same binary, then they will all be adjacent in memory), and on +some systems, even the low bits may have poor entropy as some use fixed length +aligned instructions. Then we need to consider that a portion of each binary may +contain the `.data` or `.bss` sections and so may not contain any blocks of code +at all. ### Edge IDs diff --git a/frida_mode/README.md b/frida_mode/README.md index c19280e1..c2b98473 100644 --- a/frida_mode/README.md +++ b/frida_mode/README.md @@ -229,9 +229,9 @@ instances run CMPLOG mode and instrumentation of the binary is less frequent * `AFL_FRIDA_STATS_FILE` - Write statistics information about the code being instrumented to the given file name. The statistics are written only for the child process when new block is instrumented (when the - `AFL_FRIDA_STATS_INTERVAL` has expired). Note that simply because a new path - is found does not mean a new block needs to be compiled. It could simply be - that the existing blocks instrumented have been executed in a different order. + `AFL_FRIDA_STATS_INTERVAL` has expired). Note that just because a new path is + found does not mean a new block needs to be compiled. It could be that the + existing blocks instrumented have been executed in a different order. ``` stats @@ -359,8 +359,8 @@ An example of how to fuzz a dynamic library on OSX is included, see [test/osx-lib](test/osx-lib). This requires the use of a simple test harness executable which will load the library and call a target function within it. The dependent library can either be loaded in using `dlopen` and `dlsym` in a -function marked `__attribute__((constructor()))` or the test harness can simply -be linked against it. It is important that the target library is loaded before +function marked `__attribute__((constructor()))` or the test harness can be +linked against it. It is important that the target library is loaded before execution of `main`, since this is the point where FRIDA mode is initialized. Otherwise, it will not be possible to configure coverage for the test library using `AFL_FRIDA_INST_RANGES` or similar. diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index fcf8a490..fd4282db 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -511,7 +511,7 @@ int main(int argc, char **argv) { ``` There are a couple of obstacles with our target application. Unlike when fuzzing -source code, though, we can't simply edit it and recompile it. The following +source code, though, we can't just edit it and recompile it. The following script shows how we can use the normal functionality of FRIDA to modify any troublesome behavior. -- cgit 1.4.1 From 0ae9b0dff4773c34913d89d8efcab4453552c140 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 17:01:45 +0100 Subject: Remove the word "please" --- README.md | 2 +- docs/custom_mutators.md | 9 +++++---- docs/env_variables.md | 2 +- docs/fuzzing_in_depth.md | 4 ++-- frida_mode/README.md | 4 ++-- instrumentation/README.laf-intel.md | 6 +++--- instrumentation/README.llvm.md | 8 ++++---- unicorn_mode/README.md | 38 ++++++++++++++++++------------------- utils/optimin/README.md | 8 ++++---- 9 files changed, 41 insertions(+), 40 deletions(-) (limited to 'frida_mode') diff --git a/README.md b/README.md index e74c91e5..dbf49b20 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ terms of the Apache-2.0 License. See the [LICENSE](LICENSE) for details. Here is some information to get you started: -* For releases, please see the +* For releases, see the [Releases tab](https://github.com/AFLplusplus/AFLplusplus/releases) and [branches](#branches). Also take a look at the list of [important changes in AFL++](docs/important_changes.md). diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index b1dfd309..2caba560 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -5,7 +5,7 @@ For now, we support C/C++ library and Python module, collectivelly named as the custom mutator. There is also experimental support for Rust in `custom_mutators/rust`. -Please refer to that directory for documentation. +For documentation, refer to that directory. Run ```cargo doc -p custom_mutator --open``` in that directory to view the documentation in your web browser. @@ -25,7 +25,8 @@ Now AFL also supports multiple custom mutators which can be specified in the sam ```bash export AFL_CUSTOM_MUTATOR_LIBRARY="full/path/to/mutator_first.so;full/path/to/mutator_second.so" ``` -Please see [APIs](#2-apis) and [Usage](#3-usage) for detail. + +For details, see [APIs](#2-apis) and [Usage](#3-usage). The custom mutation stage is set to be the first non-deterministic stage (right before the havoc stage). @@ -288,8 +289,8 @@ afl-fuzz /path/to/program ## 4) Example -Please see [example.c](../custom_mutators/examples/example.c) and -[example.py](../custom_mutators/examples/example.py) +See [example.c](../custom_mutators/examples/example.c) and +[example.py](../custom_mutators/examples/example.py). ## 5) Other Resources diff --git a/docs/env_variables.md b/docs/env_variables.md index 6f6110ae..bb7ea70b 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -320,7 +320,7 @@ checks or alter some of the more exotic semantics of the tool: additional mutations. If `AFL_CUSTOM_MUTATOR_ONLY` is also set, all mutations will solely be performed with the custom mutator. This feature allows to configure custom mutators which can be very helpful, e.g. fuzzing - XML or other highly flexible structured input. Please see + XML or other highly flexible structured input. For details, see [custom_mutators.md](custom_mutators.md). - Setting `AFL_CYCLE_SCHEDULES` will switch to a different schedule every time diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 7aabe090..c94590a4 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -1,7 +1,7 @@ # Fuzzing with AFL++ The following describes how to fuzz with a target if source code is available. -If you have a binary-only target, please go to +If you have a binary-only target, go to [fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md). Fuzzing source code is a three-step process: @@ -431,7 +431,7 @@ Run it like `screen -dmS afl-main -- afl-fuzz -M main-$HOSTNAME -i ...` and it will start away in a screen session. To enter this session, type `screen -r afl-main`. You see - it makes sense to name the screen session same as the afl-fuzz -M/-S naming :-) -For more information on screen or tmux please check their documentation. +For more information on screen or tmux, check their documentation. If you need to stop and re-start the fuzzing, use the same command line options (or even change them by selecting a different power schedule or another mutation diff --git a/frida_mode/README.md b/frida_mode/README.md index c2b98473..58519699 100644 --- a/frida_mode/README.md +++ b/frida_mode/README.md @@ -367,8 +367,8 @@ using `AFL_FRIDA_INST_RANGES` or similar. ## Debugging -Please refer to [DEBUGGING.md](DEBUGGING.md) for assistance should you encounter -problems with FRIDA mode. +Should you encounter problems with FRIDA mode, refer to +[DEBUGGING.md](DEBUGGING.md) for assistance. ## To do diff --git a/instrumentation/README.laf-intel.md b/instrumentation/README.laf-intel.md index 3cde10c3..06e653ea 100644 --- a/instrumentation/README.laf-intel.md +++ b/instrumentation/README.laf-intel.md @@ -42,9 +42,9 @@ comparisons. A new experimental feature is splitting floating point comparisons into a series of sign, exponent and mantissa comparisons followed by splitting each of them into 8 bit comparisons when necessary. It is activated with the -`AFL_LLVM_LAF_SPLIT_FLOATS` setting. Please note that full IEEE 754 -functionality is not preserved, that is values of nan and infinity will probably -behave differently. +`AFL_LLVM_LAF_SPLIT_FLOATS` setting. Note that full IEEE 754 functionality is +not preserved, that is values of nan and infinity will probably behave +differently. Note that setting this automatically activates `AFL_LLVM_LAF_SPLIT_COMPARES`. diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 35f38261..8133cbe4 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -119,8 +119,8 @@ If you need just to instrument specific parts of the code, you can the instrument file list which C/C++ files to actually instrument. See [README.instrument_list.md](README.instrument_list.md) -For splitting memcmp, strncmp, etc. please see -[README.laf-intel.md](README.laf-intel.md) +For splitting memcmp, strncmp, etc., see +[README.laf-intel.md](README.laf-intel.md). Then there are different ways of instrumenting the target: @@ -157,8 +157,8 @@ nozero counter default for performance reasons. ## 4) deferred initialization, persistent mode, shared memory fuzzing -This is the most powerful and effective fuzzing you can do. Please see -[README.persistent_mode.md](README.persistent_mode.md) for a full explanation. +This is the most powerful and effective fuzzing you can do. For a full +explanation, see [README.persistent_mode.md](README.persistent_mode.md). ## 5) Bonus feature: 'dict2file' pass diff --git a/unicorn_mode/README.md b/unicorn_mode/README.md index d2b7d16f..ed85e687 100644 --- a/unicorn_mode/README.md +++ b/unicorn_mode/README.md @@ -10,8 +10,8 @@ The CompareCoverage and NeverZero counters features are by Andrea Fioraldi Date: Thu, 2 Dec 2021 17:16:54 +0100 Subject: Change "AFLplusplus" to "AFL++" --- CONTRIBUTING.md | 4 ++-- frida_mode/README.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'frida_mode') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c36ed9d8..0268b2e5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -# How to submit a Pull Request to AFLplusplus +# How to submit a Pull Request to AFL++ All contributions (pull requests) must be made against our `dev` branch. @@ -19,6 +19,6 @@ Regarding the coding style, please follow the AFL style. No camel case at all and use AFL's macros wherever possible (e.g. WARNF, FATAL, MAP_SIZE, ...). -Remember that AFLplusplus has to build and run on many platforms, so +Remember that AFL++ has to build and run on many platforms, so generalize your Makefiles/GNUmakefile (or your patches to our pre-existing Makefiles) to be as generic as possible. diff --git a/frida_mode/README.md b/frida_mode/README.md index 58519699..e88bda8d 100644 --- a/frida_mode/README.md +++ b/frida_mode/README.md @@ -120,9 +120,9 @@ x86 and x64 architectures. Implementation details can be found Dynamic instrumentation is used to augment the target application with similar coverage information to that inserted by `afl-gcc` or `afl-clang`. The shared -library is also linked to the `compiler-rt` component of AFLplusplus to feedback -this coverage information to AFL++ and also provide a fork server. It also makes -use of the FRIDA +library is also linked to the `compiler-rt` component of AFL++ to feedback this +coverage information to AFL++ and also provide a fork server. It also makes use +of the FRIDA [prefetch](https://github.com/frida/frida-gum/blob/56dd9ba3ee9a5511b4b0c629394bf122775f1ab7/gum/gumstalker.h#L115) support to feedback instrumented blocks from the child to the parent using a shared memory region to avoid the need to regenerate instrumented blocks on each -- cgit 1.4.1 From c85e0dc4f0e0a6deedfb7318292e1939503a10c2 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 20:37:21 +0100 Subject: Remove the word "we" --- TODO.md | 2 +- docs/afl-fuzz_approach.md | 27 +++++++++++++-------------- docs/custom_mutators.md | 4 ++-- docs/fuzzing_binary-only_targets.md | 8 ++++---- docs/fuzzing_in_depth.md | 2 +- frida_mode/DEBUGGING.md | 2 +- instrumentation/README.instrument_list.md | 2 +- unicorn_mode/samples/c/COMPILE.md | 2 +- unicorn_mode/samples/persistent/COMPILE.md | 4 ++-- unicorn_mode/samples/speedtest/README.md | 2 +- utils/aflpp_driver/README.md | 2 +- utils/autodict_ql/readme.md | 2 +- utils/qbdi_mode/README.md | 5 +++-- 13 files changed, 32 insertions(+), 32 deletions(-) (limited to 'frida_mode') diff --git a/TODO.md b/TODO.md index 77fb080f..b8ac22ef 100644 --- a/TODO.md +++ b/TODO.md @@ -20,7 +20,7 @@ qemu_mode/frida_mode: - non colliding instrumentation - rename qemu specific envs to AFL_QEMU (AFL_ENTRYPOINT, AFL_CODE_START/END, AFL_COMPCOV_LEVEL?) - - add AFL_QEMU_EXITPOINT (maybe multiple?), maybe pointless as we have + - add AFL_QEMU_EXITPOINT (maybe multiple?), maybe pointless as there is persistent mode diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md index 3e4faaec..242104f7 100644 --- a/docs/afl-fuzz_approach.md +++ b/docs/afl-fuzz_approach.md @@ -103,8 +103,8 @@ will be allowed to run for months. There's one important thing to watch out for: if the tool is not finding new paths within several minutes of starting, you're probably not invoking the -target binary correctly and it never gets to parse the input files we're -throwing at it; other possible explanations are that the default memory limit +target binary correctly and it never gets to parse the input files that are +thrown at it; other possible explanations are that the default memory limit (`-m`) is too restrictive and the program exits after failing to allocate a buffer very early on; or that the input files are patently invalid and always fail a basic header check. @@ -172,10 +172,9 @@ processed path is not "favored" (a property discussed later on). The section provides some trivia about the coverage observed by the instrumentation embedded in the target binary. -The first line in the box tells you how many branch tuples we have already hit, -in proportion to how much the bitmap can hold. The number on the left describes -the current input; the one on the right is the value for the entire input -corpus. +The first line in the box tells you how many branch tuples already were hit, in +proportion to how much the bitmap can hold. The number on the left describes the +current input; the one on the right is the value for the entire input corpus. Be wary of extremes: @@ -194,7 +193,7 @@ Be wary of extremes: The other line deals with the variability in tuple hit counts seen in the binary. In essence, if every taken branch is always taken a fixed number of -times for all the inputs we have tried, this will read `1.00`. As we manage to +times for all the inputs that were tried, this will read `1.00`. As we manage to trigger other hit counts for every branch, the needle will start to move toward `8.00` (every bit in the 8-bit map hit), but will probably never reach that extreme. @@ -295,9 +294,9 @@ exceed it by a margin sufficient to be classified as hangs. +-----------------------------------------------------+ ``` -This is just another nerd-targeted section keeping track of how many paths we -have netted, in proportion to the number of execs attempted, for each of the -fuzzing strategies discussed earlier on. This serves to convincingly validate +This is just another nerd-targeted section keeping track of how many paths were +netted, in proportion to the number of execs attempted, for each of the fuzzing +strategies discussed earlier on. This serves to convincingly validate assumptions about the usefulness of the various approaches taken by afl-fuzz. The trim strategy stats in this section are a bit different than the rest. The @@ -339,10 +338,10 @@ fuzzing yet. The same stat is also given for "favored" entries that the fuzzer really wants to get to in this queue cycle (the non-favored entries may have to wait a couple of cycles to get their chance). -Next, we have the number of new paths found during this fuzzing section and -imported from other fuzzer instances when doing parallelized fuzzing; and the -extent to which identical inputs appear to sometimes produce variable behavior -in the tested binary. +Next is the number of new paths found during this fuzzing section and imported +from other fuzzer instances when doing parallelized fuzzing; and the extent to +which identical inputs appear to sometimes produce variable behavior in the +tested binary. That last bit is actually fairly interesting: it measures the consistency of observed traces. If a program always behaves the same for the same input data, diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 7d362950..4018d633 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -204,8 +204,8 @@ trimmed input. Here's a quick API description: - `trim` (optional) This method is called for each trimming operation. It doesn't have any - arguments because we already have the initial buffer from `init_trim` and we - can memorize the current state in the data variables. This can also save + arguments because there is already the initial buffer from `init_trim` and + we can memorize the current state in the data variables. This can also save reparsing steps for each iteration. It should return the trimmed input buffer. diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index 2d57d0dc..c3204212 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -201,10 +201,10 @@ target at load time and then let it run - or save the binary with the changes. This is great for some things, e.g. fuzzing, and not so effective for others, e.g. malware analysis. -So, what we can do with Dyninst is taking every basic block and put AFL++'s -instrumentation code in there - and then save the binary. Afterwards, we can -just fuzz the newly saved target binary with afl-fuzz. Sounds great? It is. The -issue though - it is a non-trivial problem to insert instructions, which change +So, what you can do with Dyninst is taking every basic block and putting AFL++'s +instrumentation code in there - and then save the binary. Afterwards, just fuzz +the newly saved target binary with afl-fuzz. Sounds great? It is. The issue +though - it is a non-trivial problem to insert instructions, which change addresses in the process space, so that everything is still working afterwards. Hence, more often than not binaries crash when they are run. diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 4d2884f6..92b3cf86 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -391,7 +391,7 @@ to be used in fuzzing! :-) ## 3. Fuzzing the target -In this final step we fuzz the target. There are not that many important options +In this final step, fuzz the target. There are not that many important options to run the target - unless you want to use many CPU cores/threads for the fuzzing, which will make the fuzzing much more useful. diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md index b703ae43..207a48bf 100644 --- a/frida_mode/DEBUGGING.md +++ b/frida_mode/DEBUGGING.md @@ -95,7 +95,7 @@ gdb \ ``` Note: -- We have to manually set the `__AFL_PERSISTENT` environment variable which is +- You have to manually set the `__AFL_PERSISTENT` environment variable which is usually passed by `afl-fuzz`. - Setting breakpoints etc. is likely to interfere with FRIDA and cause spurious errors. diff --git a/instrumentation/README.instrument_list.md b/instrumentation/README.instrument_list.md index b412b600..3ed64807 100644 --- a/instrumentation/README.instrument_list.md +++ b/instrumentation/README.instrument_list.md @@ -128,4 +128,4 @@ Note that whitespace is ignored and comments (`# foo`) are supported. ### 3b) UNIX-style pattern matching You can add UNIX-style pattern matching in the "instrument file list" entries. -See `man fnmatch` for the syntax. We do not set any of the `fnmatch` flags. \ No newline at end of file +See `man fnmatch` for the syntax. Do not set any of the `fnmatch` flags. \ No newline at end of file diff --git a/unicorn_mode/samples/c/COMPILE.md b/unicorn_mode/samples/c/COMPILE.md index 7da140f7..4e3cf568 100644 --- a/unicorn_mode/samples/c/COMPILE.md +++ b/unicorn_mode/samples/c/COMPILE.md @@ -19,4 +19,4 @@ was built in case you want to rebuild it or recompile it for any reason. The pre-built binary (persistent_target_x86_64) was built using -g -O0 in gcc. -We then load the binary and execute the main function directly. +Then load the binary and execute the main function directly. diff --git a/unicorn_mode/samples/persistent/COMPILE.md b/unicorn_mode/samples/persistent/COMPILE.md index 9f2ae718..5e607aef 100644 --- a/unicorn_mode/samples/persistent/COMPILE.md +++ b/unicorn_mode/samples/persistent/COMPILE.md @@ -3,7 +3,7 @@ This shows a simple persistent harness for unicornafl in C. In contrast to the normal c harness, this harness manually resets the unicorn state on each new input. -Thanks to this, we can rerun the test case in unicorn multiple times, without +Thanks to this, you can rerun the test case in unicorn multiple times, without the need to fork again. ## Compiling sample.c @@ -25,4 +25,4 @@ was built in case you want to rebuild it or recompile it for any reason. The pre-built binary (persistent_target_x86_64.bin) was built using -g -O0 in gcc. -We then load the binary and we execute the main function directly. \ No newline at end of file +Then load the binary and execute the main function directly. \ No newline at end of file diff --git a/unicorn_mode/samples/speedtest/README.md b/unicorn_mode/samples/speedtest/README.md index 3c1184a2..496d75cd 100644 --- a/unicorn_mode/samples/speedtest/README.md +++ b/unicorn_mode/samples/speedtest/README.md @@ -44,7 +44,7 @@ was built in case you want to rebuild it or recompile it for any reason. The pre-built binary (simple_target_x86_64.bin) was built using -g -O0 in gcc. -We then load the binary and execute the main function directly. +Then load the binary and execute the main function directly. ## Addresses for the harness: To find the address (in hex) of main, run: diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md index 4560be2b..d534cd7f 100644 --- a/utils/aflpp_driver/README.md +++ b/utils/aflpp_driver/README.md @@ -25,7 +25,7 @@ or `@@` as command line parameters. Note that you can use the driver too for frida_mode (`-O`). aflpp_qemu_driver is used for libfuzzer `LLVMFuzzerTestOneInput()` targets that -are to be fuzzed in qemu_mode. So we compile them with clang/clang++, without +are to be fuzzed in qemu_mode. So compile them with clang/clang++, without -fsantize=fuzzer or afl-clang-fast, and link in libAFLQemuDriver.a: `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`. diff --git a/utils/autodict_ql/readme.md b/utils/autodict_ql/readme.md index a28f1725..491ec85b 100644 --- a/utils/autodict_ql/readme.md +++ b/utils/autodict_ql/readme.md @@ -37,7 +37,7 @@ sudo apt install build-essential libtool-bin python3-dev python3 automake git vi ``` The usage of Autodict-QL is pretty easy. But let's describe it as: -1. First of all, you need to have CodeQL installed on the system. we make this possible with `build-codeql.sh` bash script. This script will install CodeQL completety and will set the required environment variables for your system. +1. First of all, you need to have CodeQL installed on the system. We make this possible with `build-codeql.sh` bash script. This script will install CodeQL completety and will set the required environment variables for your system. Do the following : ```shell # chmod +x codeql-build.sh diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md index cd59fb9c..c8d46fca 100755 --- a/utils/qbdi_mode/README.md +++ b/utils/qbdi_mode/README.md @@ -131,7 +131,8 @@ int target_func(char *buf, int size) { This could be built to `libdemo.so`. -Then we should load the library in template.cpp and find the `target` function address. +Then load the library in template.cpp and find the `target` function address: + ```c void *handle = dlopen(lib_path, RTLD_LAZY); .......................................... @@ -140,7 +141,7 @@ Then we should load the library in template.cpp and find the `target` function a p_target_func = (target_func)dlsym(handle, "target_func"); ``` -then we read the data from file and call the function in `fuzz_func` +Then read the data from file and call the function in `fuzz_func`: ```c QBDI_NOINLINE int fuzz_func() { -- cgit 1.4.1 From bcd81c377d22cf26812127881a8ac15ed9c022ad Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sat, 4 Dec 2021 20:38:00 +0100 Subject: Fix line length and formatting --- CONTRIBUTING.md | 11 ++-- README.md | 26 +++++--- TODO.md | 9 ++- docs/FAQ.md | 82 ++++++++++++++++--------- docs/INSTALL.md | 79 +++++++++++++++--------- docs/afl-fuzz_approach.md | 4 +- docs/best_practices.md | 114 +++++++++++++++++++++++------------ docs/custom_mutators.md | 80 ++++++++++++------------ docs/env_variables.md | 96 ++++++++++++++--------------- docs/fuzzing_binary-only_targets.md | 6 +- docs/fuzzing_in_depth.md | 50 ++++++++------- docs/ideas.md | 55 +++++++++-------- docs/important_changes.md | 29 ++++----- docs/rpc_statsd.md | 73 ++++++++++++++++------ frida_mode/Scripting.md | 20 +++--- instrumentation/README.gcc_plugin.md | 4 +- 16 files changed, 435 insertions(+), 303 deletions(-) (limited to 'frida_mode') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0ab4f8ec..fb13b91a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,10 +15,9 @@ project, or added a file in a directory we already format, otherwise run: ./.custom-format.py -i file-that-you-have-created.c ``` -Regarding the coding style, please follow the AFL style. -No camel case at all and use AFL's macros wherever possible -(e.g., WARNF, FATAL, MAP_SIZE, ...). +Regarding the coding style, please follow the AFL style. No camel case at all +and use AFL's macros wherever possible (e.g., WARNF, FATAL, MAP_SIZE, ...). -Remember that AFL++ has to build and run on many platforms, so -generalize your Makefiles/GNUmakefile (or your patches to our pre-existing -Makefiles) to be as generic as possible. +Remember that AFL++ has to build and run on many platforms, so generalize your +Makefiles/GNUmakefile (or your patches to our pre-existing Makefiles) to be as +generic as possible. \ No newline at end of file diff --git a/README.md b/README.md index 08363149..b70eb1ab 100644 --- a/README.md +++ b/README.md @@ -44,8 +44,8 @@ Here is some information to get you started: ## Building and installing AFL++ -To have AFL++ easily available with everything compiled, pull the image -directly from the Docker Hub: +To have AFL++ easily available with everything compiled, pull the image directly +from the Docker Hub: ```shell docker pull aflplusplus/aflplusplus @@ -53,8 +53,8 @@ docker run -ti -v /location/of/your/target:/src aflplusplus/aflplusplus ``` This image is automatically generated when a push to the stable repo happens -(see [branches](#branches)). You will find your target source -code in `/src` in the container. +(see [branches](#branches)). You will find your target source code in `/src` in +the container. To build AFL++ yourself, continue at [docs/INSTALL.md](docs/INSTALL.md). @@ -120,8 +120,8 @@ Questions? Concerns? Bug reports? * The contributors can be reached via [https://github.com/AFLplusplus/AFLplusplus](https://github.com/AFLplusplus/AFLplusplus). -* Take a look at our [FAQ](docs/FAQ.md). If you find an interesting or - important question missing, submit it via +* Take a look at our [FAQ](docs/FAQ.md). If you find an interesting or important + question missing, submit it via [https://github.com/AFLplusplus/AFLplusplus/discussions](https://github.com/AFLplusplus/AFLplusplus/discussions). * There is a mailing list for the AFL/AFL++ project ([browse archive](https://groups.google.com/group/afl-users)). To compare @@ -133,10 +133,16 @@ Questions? Concerns? Bug reports? The following branches exist: -* [release](https://github.com/AFLplusplus/AFLplusplus/tree/release): the latest release -* [stable/trunk](https://github.com/AFLplusplus/AFLplusplus/): stable state of AFL++ - it is synced from dev from time to time when we are satisfied with its stability -* [dev](https://github.com/AFLplusplus/AFLplusplus/tree/dev): development state of AFL++ - bleeding edge and you might catch a checkout which does not compile or has a bug. *We only accept PRs in dev!!* -* (any other): experimental branches to work on specific features or testing new functionality or changes. +* [release](https://github.com/AFLplusplus/AFLplusplus/tree/release): the latest + release +* [stable/trunk](https://github.com/AFLplusplus/AFLplusplus/): stable state of + AFL++ - it is synced from dev from time to time when we are satisfied with its + stability +* [dev](https://github.com/AFLplusplus/AFLplusplus/tree/dev): development state + of AFL++ - bleeding edge and you might catch a checkout which does not compile + or has a bug. *We only accept PRs in dev!!* +* (any other): experimental branches to work on specific features or testing new + functionality or changes. ## Help wanted diff --git a/TODO.md b/TODO.md index b8ac22ef..04f3abab 100644 --- a/TODO.md +++ b/TODO.md @@ -23,11 +23,10 @@ qemu_mode/frida_mode: - add AFL_QEMU_EXITPOINT (maybe multiple?), maybe pointless as there is persistent mode - ## Ideas - LTO/sancov: write current edge to prev_loc and use that information when - using cmplog or __sanitizer_cov_trace_cmp*. maybe we can deduct by follow - up edge numbers that both following cmp paths have been found and then - disable working on this edge id -> cmplog_intelligence branch - - use cmplog colorization taint result for havoc locations? + using cmplog or __sanitizer_cov_trace_cmp*. maybe we can deduct by follow up + edge numbers that both following cmp paths have been found and then disable + working on this edge id -> cmplog_intelligence branch + - use cmplog colorization taint result for havoc locations? \ No newline at end of file diff --git a/docs/FAQ.md b/docs/FAQ.md index 671957ef..7869ee61 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -8,35 +8,45 @@ If you find an interesting or important question missing, submit it via
What is the difference between AFL and AFL++?

- AFL++ is a superior fork to Google's AFL - more speed, more and better mutations, more and better instrumentation, custom module support, etc. + AFL++ is a superior fork to Google's AFL - more speed, more and better + mutations, more and better instrumentation, custom module support, etc. - American Fuzzy Lop (AFL) was developed by Michał "lcamtuf" Zalewski starting in 2013/2014, and when he left Google end of 2017 he stopped developing it. + American Fuzzy Lop (AFL) was developed by Michał "lcamtuf" Zalewski starting + in 2013/2014, and when he left Google end of 2017 he stopped developing it. At the end of 2019, the Google fuzzing team took over maintenance of AFL, however, it is only accepting PRs from the community and is not developing enhancements anymore. - In the second quarter of 2019, 1 1/2 years later, when no further development of AFL had happened and it became clear there would none be coming, AFL++ was born, where initially community patches were collected and applied for bug fixes and enhancements. - Then from various AFL spin-offs - mostly academic research - features were integrated. - This already resulted in a much advanced AFL. - - Until the end of 2019, the AFL++ team had grown to four active developers which then implemented their own research and features, making it now by far the most flexible and feature rich guided fuzzer available as open source. - And in independent fuzzing benchmarks it is one of the best fuzzers available, e.g., [Fuzzbench Report](https://www.fuzzbench.com/reports/2020-08-03/index.html). + In the second quarter of 2019, 1 1/2 years later, when no further development + of AFL had happened and it became clear there would none be coming, AFL++ was + born, where initially community patches were collected and applied for bug + fixes and enhancements. Then from various AFL spin-offs - mostly academic + research - features were integrated. This already resulted in a much advanced + AFL. + + Until the end of 2019, the AFL++ team had grown to four active developers + which then implemented their own research and features, making it now by far + the most flexible and feature rich guided fuzzer available as open source. And + in independent fuzzing benchmarks it is one of the best fuzzers available, + e.g., [Fuzzbench + Report](https://www.fuzzbench.com/reports/2020-08-03/index.html).

Where can I find tutorials?

- We compiled a list of tutorials and exercises, see [tutorials.md](tutorials.md). + We compiled a list of tutorials and exercises, see + [tutorials.md](tutorials.md).

What is an "edge"?

A program contains `functions`, `functions` contain the compiled machine code. - The compiled machine code in a `function` can be in a single or many `basic blocks`. - A `basic block` is the largest possible number of subsequent machine code - instructions that has exactly one entry point (which can be be entered by + The compiled machine code in a `function` can be in a single or many `basic + blocks`. A `basic block` is the largest possible number of subsequent machine + code instructions that has exactly one entry point (which can be be entered by multiple other basic blocks) and runs linearly without branching or jumping to other addresses (except at the end). @@ -60,7 +70,8 @@ If you find an interesting or important question missing, submit it via Every code block between two jump locations is a `basic block`. - An `edge` is then the unique relationship between two directly connected `basic blocks` (from the code example above): + An `edge` is then the unique relationship between two directly connected + `basic blocks` (from the code example above): ``` Block A @@ -75,8 +86,8 @@ If you find an interesting or important question missing, submit it via Block E ``` - Every line between two blocks is an `edge`. - Note that a few basic block loop to itself, this too would be an edge. + Every line between two blocks is an `edge`. Note that a few basic block loop + to itself, this too would be an edge.

## Targets @@ -86,7 +97,8 @@ If you find an interesting or important question missing, submit it via AFL++ is a great fuzzer if you have the source code available. - However, if there is only the binary program and no source code available, then the standard non-instrumented mode is not effective. + However, if there is only the binary program and no source code available, + then the standard non-instrumented mode is not effective. To learn how these binaries can be fuzzed, read [fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md). @@ -97,15 +109,19 @@ If you find an interesting or important question missing, submit it via The short answer is - you cannot, at least not "out of the box". - For more information on fuzzing network services, see [best_practices.md#fuzzing-a-network-service](best_practices.md#fuzzing-a-network-service). + For more information on fuzzing network services, see + [best_practices.md#fuzzing-a-network-service](best_practices.md#fuzzing-a-network-service).

How can I fuzz a GUI program?

- Not all GUI programs are suitable for fuzzing. If the GUI program can read the fuzz data from a file without needing any user interaction, then it would be suitable for fuzzing. + Not all GUI programs are suitable for fuzzing. If the GUI program can read the + fuzz data from a file without needing any user interaction, then it would be + suitable for fuzzing. - For more information on fuzzing GUI programs, see [best_practices.md#fuzzing-a-gui-program](best_practices.md#fuzzing-a-gui-program). + For more information on fuzzing GUI programs, see + [best_practices.md#fuzzing-a-gui-program](best_practices.md#fuzzing-a-gui-program).

## Performance @@ -113,27 +129,33 @@ If you find an interesting or important question missing, submit it via
How can I improve the fuzzing speed?

- There are a few things you can do to improve the fuzzing speed, see [best_practices.md#improving-speed](best_practices.md#improving-speed). + There are a few things you can do to improve the fuzzing speed, see + [best_practices.md#improving-speed](best_practices.md#improving-speed).

Why is my stability below 100%?

- Stability is measured by how many percent of the edges in the target are "stable". - Sending the same input again and again should take the exact same path through the target every time. - If that is the case, the stability is 100%. + Stability is measured by how many percent of the edges in the target are + "stable". Sending the same input again and again should take the exact same + path through the target every time. If that is the case, the stability is + 100%. If, however, randomness happens, e.g., a thread reading other external data, reaction to timing, etc., then in some of the re-executions with the same data the edge coverage result will be different across runs. Those edges that change are then flagged "unstable". - The more "unstable" edges, the more difficult for AFL++ to identify valid new paths. + The more "unstable" edges, the more difficult for AFL++ to identify valid new + paths. - A value above 90% is usually fine and a value above 80% is also still ok, and even a value above 20% can still result in successful finds of bugs. - However, it is recommended that for values below 90% or 80% you should take countermeasures to improve stability. + A value above 90% is usually fine and a value above 80% is also still ok, and + even a value above 20% can still result in successful finds of bugs. However, + it is recommended that for values below 90% or 80% you should take + countermeasures to improve stability. - For more information on stability and how to improve the stability value, see [best_practices.md#improving-stability](best_practices.md#improving-stability). + For more information on stability and how to improve the stability value, see + [best_practices.md#improving-stability](best_practices.md#improving-stability).

## Troubleshooting @@ -141,7 +163,8 @@ If you find an interesting or important question missing, submit it via
I got a weird compile error from clang.

- If you see this kind of error when trying to instrument a target with afl-cc/afl-clang-fast/afl-clang-lto: + If you see this kind of error when trying to instrument a target with + afl-cc/afl-clang-fast/afl-clang-lto: ``` /prg/tmp/llvm-project/build/bin/clang-13: symbol lookup error: /usr/local/bin/../lib/afl//cmplog-instructions-pass.so: undefined symbol: _ZNK4llvm8TypeSizecvmEv @@ -155,7 +178,8 @@ If you find an interesting or important question missing, submit it via ******************** ``` - Then this means that your OS updated the clang installation from an upgrade package and because of that the AFL++ llvm plugins do not match anymore. + Then this means that your OS updated the clang installation from an upgrade + package and because of that the AFL++ llvm plugins do not match anymore. Solution: `git pull ; make clean install` of AFL++.

\ No newline at end of file diff --git a/docs/INSTALL.md b/docs/INSTALL.md index c1e22e36..08d3283e 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -3,7 +3,8 @@ ## Linux on x86 An easy way to install AFL++ with everything compiled is available via docker: -You can use the [Dockerfile](../Dockerfile) (which has gcc-10 and clang-11 - hence afl-clang-lto is available!) or just pull directly from the Docker Hub: +You can use the [Dockerfile](../Dockerfile) (which has gcc-10 and clang-11 - +hence afl-clang-lto is available!) or just pull directly from the Docker Hub: ```shell docker pull aflplusplus/aflplusplus @@ -13,8 +14,8 @@ docker run -ti -v /location/of/your/target:/src aflplusplus/aflplusplus This image is automatically generated when a push to the stable repo happens. You will find your target source code in /src in the container. -If you want to build AFL++ yourself, you have many options. -The easiest choice is to build and install everything: +If you want to build AFL++ yourself, you have many options. The easiest choice +is to build and install everything: ```shell sudo apt-get update @@ -29,10 +30,13 @@ make distrib sudo make install ``` -It is recommended to install the newest available gcc, clang and llvm-dev possible in your distribution! +It is recommended to install the newest available gcc, clang and llvm-dev +possible in your distribution! -Note that "make distrib" also builds instrumentation, qemu_mode, unicorn_mode and more. -If you just want plain AFL++, then do "make all". However, compiling and using at least instrumentation is highly recommended for much better results - hence in this case choose: +Note that "make distrib" also builds instrumentation, qemu_mode, unicorn_mode +and more. If you just want plain AFL++, then do "make all". However, compiling +and using at least instrumentation is highly recommended for much better results +- hence in this case choose: ```shell make source-only @@ -41,19 +45,25 @@ make source-only These build targets exist: * all: just the main AFL++ binaries -* binary-only: everything for binary-only fuzzing: qemu_mode, unicorn_mode, libdislocator, libtokencap -* source-only: everything for source code fuzzing: instrumentation, libdislocator, libtokencap +* binary-only: everything for binary-only fuzzing: qemu_mode, unicorn_mode, + libdislocator, libtokencap +* source-only: everything for source code fuzzing: instrumentation, + libdislocator, libtokencap * distrib: everything (for both binary-only and source code fuzzing) * man: creates simple man pages from the help option of the programs * install: installs everything you have compiled with the build options above * clean: cleans everything compiled, not downloads (unless not on a checkout) * deepclean: cleans everything including downloads * code-format: format the code, do this before you commit and send a PR please! -* tests: runs test cases to ensure that all features are still working as they should +* tests: runs test cases to ensure that all features are still working as they + should * unit: perform unit tests (based on cmocka) * help: shows these build options -[Unless you are on Mac OS X](https://developer.apple.com/library/archive/qa/qa1118/_index.html), you can also build statically linked versions of the AFL++ binaries by passing the `STATIC=1` argument to make: +[Unless you are on Mac OS +X](https://developer.apple.com/library/archive/qa/qa1118/_index.html), you can +also build statically linked versions of the AFL++ binaries by passing the +`STATIC=1` argument to make: ```shell make STATIC=1 @@ -67,7 +77,8 @@ These build options exist: * PROFILING - compile with profiling information (gprof) * INTROSPECTION - compile afl-fuzz with mutation introspection * NO_PYTHON - disable python support -* NO_SPLICING - disables splicing mutation in afl-fuzz, not recommended for normal fuzzing +* NO_SPLICING - disables splicing mutation in afl-fuzz, not recommended for + normal fuzzing * AFL_NO_X86 - if compiling on non-intel/amd platforms * LLVM_CONFIG - if your distro doesn't use the standard name for llvm-config (e.g., Debian) @@ -76,15 +87,17 @@ e.g.: `make ASAN_BUILD=1` ## MacOS X on x86 and arm64 (M1) -MacOS X should work, but there are some gotchas due to the idiosyncrasies of the platform. -On top of this, we have limited release testing capabilities and depend mostly on user feedback. +MacOS X should work, but there are some gotchas due to the idiosyncrasies of the +platform. On top of this, we have limited release testing capabilities and +depend mostly on user feedback. -To build AFL, install llvm (and perhaps gcc) from brew and follow the general instructions for Linux. -If possible, avoid Xcode at all cost. +To build AFL, install llvm (and perhaps gcc) from brew and follow the general +instructions for Linux. If possible, avoid Xcode at all cost. `brew install wget git make cmake llvm gdb` -Be sure to setup `PATH` to point to the correct clang binaries and use the freshly installed clang, clang++ and gmake, e.g.: +Be sure to setup `PATH` to point to the correct clang binaries and use the +freshly installed clang, clang++ and gmake, e.g.: ``` export PATH="/usr/local/Cellar/llvm/12.0.1/bin/:$PATH" @@ -97,20 +110,20 @@ cd .. gmake install ``` -`afl-gcc` will fail unless you have GCC installed, but that is using outdated instrumentation anyway. -You don't want that. -Note that `afl-clang-lto`, `afl-gcc-fast` and `qemu_mode` are not working on MacOS. +`afl-gcc` will fail unless you have GCC installed, but that is using outdated +instrumentation anyway. You don't want that. Note that `afl-clang-lto`, +`afl-gcc-fast` and `qemu_mode` are not working on MacOS. -The crash reporting daemon that comes by default with MacOS X will cause problems with fuzzing. -You need to turn it off: +The crash reporting daemon that comes by default with MacOS X will cause +problems with fuzzing. You need to turn it off: ``` launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist ``` -The `fork()` semantics on OS X are a bit unusual compared to other unix systems and definitely don't look POSIX-compliant. -This means two things: +The `fork()` semantics on OS X are a bit unusual compared to other unix systems +and definitely don't look POSIX-compliant. This means two things: - Fuzzing will be probably slower than on Linux. In fact, some folks report considerable performance gains by running the jobs inside a Linux VM on @@ -119,11 +132,13 @@ This means two things: forkserver. If you run into any problems, set `AFL_NO_FORKSRV=1` in the environment before starting afl-fuzz. -User emulation mode of QEMU does not appear to be supported on MacOS X, so black-box instrumentation mode (`-Q`) will not work. -However, Frida mode (`-O`) should work on x86 and arm64 MacOS boxes. +User emulation mode of QEMU does not appear to be supported on MacOS X, so +black-box instrumentation mode (`-Q`) will not work. However, Frida mode (`-O`) +should work on x86 and arm64 MacOS boxes. -MacOS X supports SYSV shared memory used by AFL's instrumentation, but the default settings aren't usable with AFL++. -The default settings on 10.14 seem to be: +MacOS X supports SYSV shared memory used by AFL's instrumentation, but the +default settings aren't usable with AFL++. The default settings on 10.14 seem to +be: ```bash $ ipcs -M @@ -136,14 +151,16 @@ shminfo: shmall: 1024 (max amount of shared memory in pages) ``` -To temporarily change your settings to something minimally usable with AFL++, run these commands as root: +To temporarily change your settings to something minimally usable with AFL++, +run these commands as root: ```bash sysctl kern.sysv.shmmax=8388608 sysctl kern.sysv.shmall=4096 ``` -If you're running more than one instance of AFL, you likely want to make `shmall` bigger and increase `shmseg` as well: +If you're running more than one instance of AFL, you likely want to make +`shmall` bigger and increase `shmseg` as well: ```bash sysctl kern.sysv.shmmax=8388608 @@ -151,4 +168,6 @@ sysctl kern.sysv.shmseg=48 sysctl kern.sysv.shmall=98304 ``` -See [https://www.spy-hill.com/help/apple/SharedMemory.html](https://www.spy-hill.com/help/apple/SharedMemory.html) for documentation for these settings and how to make them permanent. \ No newline at end of file +See +[https://www.spy-hill.com/help/apple/SharedMemory.html](https://www.spy-hill.com/help/apple/SharedMemory.html) +for documentation for these settings and how to make them permanent. \ No newline at end of file diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md index fefde029..3804f5a0 100644 --- a/docs/afl-fuzz_approach.md +++ b/docs/afl-fuzz_approach.md @@ -445,8 +445,8 @@ involve any state transitions not seen in previously-recorded faults. If a single bug can be reached in multiple ways, there will be some count inflation early in the process, but this should quickly taper off. -The file names for crashes and hangs are correlated with the parent, non-faulting -queue entries. This should help with debugging. +The file names for crashes and hangs are correlated with the parent, +non-faulting queue entries. This should help with debugging. ## Visualizing diff --git a/docs/best_practices.md b/docs/best_practices.md index 6a406bde..e6b252f6 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -18,7 +18,8 @@ ### Fuzzing a target with source code available -To learn how to fuzz a target if source code is available, see [fuzzing_in_depth.md](fuzzing_in_depth.md). +To learn how to fuzz a target if source code is available, see +[fuzzing_in_depth.md](fuzzing_in_depth.md). ### Fuzzing a binary-only target @@ -27,11 +28,16 @@ For a comprehensive guide, see ### Fuzzing a GUI program -If the GUI program can read the fuzz data from a file (via the command line, a fixed location or via an environment variable) without needing any user interaction, then it would be suitable for fuzzing. +If the GUI program can read the fuzz data from a file (via the command line, a +fixed location or via an environment variable) without needing any user +interaction, then it would be suitable for fuzzing. -Otherwise, it is not possible without modifying the source code - which is a very good idea anyway as the GUI functionality is a huge CPU/time overhead for the fuzzing. +Otherwise, it is not possible without modifying the source code - which is a +very good idea anyway as the GUI functionality is a huge CPU/time overhead for +the fuzzing. -So create a new `main()` that just reads the test case and calls the functionality for processing the input that the GUI program is using. +So create a new `main()` that just reads the test case and calls the +functionality for processing the input that the GUI program is using. ### Fuzzing a network service @@ -40,13 +46,16 @@ Fuzzing a network service does not work "out of the box". Using a network channel is inadequate for several reasons: - it has a slow-down of x10-20 on the fuzzing speed - it does not scale to fuzzing multiple instances easily, -- instead of one initial data packet often a back-and-forth interplay of packets is needed for stateful protocols (which is totally unsupported by most coverage aware fuzzers). +- instead of one initial data packet often a back-and-forth interplay of packets + is needed for stateful protocols (which is totally unsupported by most + coverage aware fuzzers). -The established method to fuzz network services is to modify the source code -to read from a file or stdin (fd 0) (or even faster via shared memory, combine -this with persistent mode [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md) -and you have a performance gain of x10 instead of a performance loss of over -x10 - that is a x100 difference!). +The established method to fuzz network services is to modify the source code to +read from a file or stdin (fd 0) (or even faster via shared memory, combine this +with persistent mode +[instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md) +and you have a performance gain of x10 instead of a performance loss of over x10 +- that is a x100 difference!). If modifying the source is not an option (e.g., because you only have a binary and perform binary fuzzing) you can also use a shared library with AFL_PRELOAD @@ -64,13 +73,25 @@ allows you to define network state with different type of data packets. ### Improving speed -1. Use [llvm_mode](../instrumentation/README.llvm.md): afl-clang-lto (llvm >= 11) or afl-clang-fast (llvm >= 9 recommended). -2. Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 speed increase). -3. Instrument just what you are interested in, see [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md). -4. If you do not use shmem persistent mode, use `AFL_TMPDIR` to put the input file directory on a tempfs location, see [env_variables.md](env_variables.md). -5. Improve Linux kernel performance: modify `/etc/default/grub`, set `GRUB_CMDLINE_LINUX_DEFAULT="ibpb=off ibrs=off kpti=off l1tf=off mds=off mitigations=off no_stf_barrier noibpb noibrs nopcid nopti nospec_store_bypass_disable nospectre_v1 nospectre_v2 pcid=off pti=off spec_store_bypass_disable=off spectre_v2=off stf_barrier=off"`; then `update-grub` and `reboot` (warning: makes the system less secure). -6. Running on an `ext2` filesystem with `noatime` mount option will be a bit faster than on any other journaling filesystem. -7. Use your cores ([fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores))! +1. Use [llvm_mode](../instrumentation/README.llvm.md): afl-clang-lto (llvm >= + 11) or afl-clang-fast (llvm >= 9 recommended). +2. Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 + speed increase). +3. Instrument just what you are interested in, see + [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md). +4. If you do not use shmem persistent mode, use `AFL_TMPDIR` to put the input + file directory on a tempfs location, see + [env_variables.md](env_variables.md). +5. Improve Linux kernel performance: modify `/etc/default/grub`, set + `GRUB_CMDLINE_LINUX_DEFAULT="ibpb=off ibrs=off kpti=off l1tf=off mds=off + mitigations=off no_stf_barrier noibpb noibrs nopcid nopti + nospec_store_bypass_disable nospectre_v1 nospectre_v2 pcid=off pti=off + spec_store_bypass_disable=off spectre_v2=off stf_barrier=off"`; then + `update-grub` and `reboot` (warning: makes the system less secure). +6. Running on an `ext2` filesystem with `noatime` mount option will be a bit + faster than on any other journaling filesystem. +7. Use your cores + ([fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores))! ### Improving stability @@ -78,46 +99,60 @@ For fuzzing a 100% stable target that covers all edges is the best case. A 90% stable target that covers all edges is, however, better than a 100% stable target that ignores 10% of the edges. -With instability, you basically have a partial coverage loss on an edge, with ignored functions you have a full loss on that edges. +With instability, you basically have a partial coverage loss on an edge, with +ignored functions you have a full loss on that edges. There are functions that are unstable, but also provide value to coverage, e.g., init functions that use fuzz data as input. If, however, a function that has nothing to do with the input data is the source of instability, e.g., checking jitter, or is a hash map function etc., then it should not be instrumented. -To be able to exclude these functions (based on AFL++'s measured stability), the following process will allow to identify functions with variable edges. +To be able to exclude these functions (based on AFL++'s measured stability), the +following process will allow to identify functions with variable edges. -Four steps are required to do this and it also requires quite some knowledge of coding and/or disassembly and is effectively possible only with `afl-clang-fast` `PCGUARD` and `afl-clang-lto` `LTO` instrumentation. +Four steps are required to do this and it also requires quite some knowledge of +coding and/or disassembly and is effectively possible only with `afl-clang-fast` +`PCGUARD` and `afl-clang-lto` `LTO` instrumentation. 1. Instrument to be able to find the responsible function(s): - a) For LTO instrumented binaries, this can be documented during compile time, just set `export AFL_LLVM_DOCUMENT_IDS=/path/to/a/file`. - This file will have one assigned edge ID and the corresponding function per line. - - b) For PCGUARD instrumented binaries, it is much more difficult. Here you can either modify the `__sanitizer_cov_trace_pc_guard` function in `instrumentation/afl-llvm-rt.o.c` to write a backtrace to a file if the ID in `__afl_area_ptr[*guard]` is one of the unstable edge IDs. - (Example code is already there). - Then recompile and reinstall `llvm_mode` and rebuild your target. - Run the recompiled target with `afl-fuzz` for a while and then check the file that you wrote with the backtrace information. - Alternatively, you can use `gdb` to hook `__sanitizer_cov_trace_pc_guard_init` on start, check to which memory address the edge ID value is written, and set a write breakpoint to that address (`watch 0x.....`). - - c) In other instrumentation types, this is not possible. - So just recompile with the two mentioned above. - This is just for identifying the functions that have unstable edges. + a) For LTO instrumented binaries, this can be documented during compile + time, just set `export AFL_LLVM_DOCUMENT_IDS=/path/to/a/file`. This file + will have one assigned edge ID and the corresponding function per line. + + b) For PCGUARD instrumented binaries, it is much more difficult. Here you + can either modify the `__sanitizer_cov_trace_pc_guard` function in + `instrumentation/afl-llvm-rt.o.c` to write a backtrace to a file if the + ID in `__afl_area_ptr[*guard]` is one of the unstable edge IDs. (Example + code is already there). Then recompile and reinstall `llvm_mode` and + rebuild your target. Run the recompiled target with `afl-fuzz` for a + while and then check the file that you wrote with the backtrace + information. Alternatively, you can use `gdb` to hook + `__sanitizer_cov_trace_pc_guard_init` on start, check to which memory + address the edge ID value is written, and set a write breakpoint to that + address (`watch 0x.....`). + + c) In other instrumentation types, this is not possible. So just recompile + with the two mentioned above. This is just for identifying the functions + that have unstable edges. 2. Identify which edge ID numbers are unstable. Run the target with `export AFL_DEBUG=1` for a few minutes then terminate. The out/fuzzer_stats file will then show the edge IDs that were identified - as unstable in the `var_bytes` entry. You can match these numbers - directly to the data you created in the first step. - Now you know which functions are responsible for the instability + as unstable in the `var_bytes` entry. You can match these numbers directly + to the data you created in the first step. Now you know which functions are + responsible for the instability 3. Create a text file with the filenames/functions - Identify which source code files contain the functions that you need to remove from instrumentation, or just specify the functions you want to skip for instrumentation. - Note that optimization might inline functions! + Identify which source code files contain the functions that you need to + remove from instrumentation, or just specify the functions you want to skip + for instrumentation. Note that optimization might inline functions! + + Follow this document on how to do this: + [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md). - Follow this document on how to do this: [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md). If `PCGUARD` is used, then you need to follow this guide (needs llvm 12+!): [https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) @@ -132,4 +167,5 @@ Four steps are required to do this and it also requires quite some knowledge of Recompile, fuzz it, be happy :) - This link explains this process for [Fuzzbench](https://github.com/google/fuzzbench/issues/677). + This link explains this process for + [Fuzzbench](https://github.com/google/fuzzbench/issues/677). \ No newline at end of file diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 6bee5413..2a77db82 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -4,13 +4,13 @@ This file describes how you can implement custom mutations to be used in AFL. For now, we support C/C++ library and Python module, collectivelly named as the custom mutator. -There is also experimental support for Rust in `custom_mutators/rust`. -For documentation, refer to that directory. -Run ```cargo doc -p custom_mutator --open``` in that directory to view the -documentation in your web browser. +There is also experimental support for Rust in `custom_mutators/rust`. For +documentation, refer to that directory. Run `cargo doc -p custom_mutator --open` +in that directory to view the documentation in your web browser. Implemented by -- C/C++ library (`*.so`): Khaled Yakdan from Code Intelligence () +- C/C++ library (`*.so`): Khaled Yakdan from Code Intelligence + () - Python module: Christian Holler from Mozilla () ## 1) Introduction @@ -29,7 +29,8 @@ export AFL_CUSTOM_MUTATOR_LIBRARY="full/path/to/mutator_first.so;full/path/to/mu For details, see [APIs](#2-apis) and [Usage](#3-usage). -The custom mutation stage is set to be the first non-deterministic stage (right before the havoc stage). +The custom mutation stage is set to be the first non-deterministic stage (right +before the havoc stage). Note: If `AFL_CUSTOM_MUTATOR_ONLY` is set, all mutations will solely be performed with the custom mutator. @@ -103,7 +104,8 @@ def deinit(): # optional for Python - `init`: - This method is called when AFL++ starts up and is used to seed RNG and set up buffers and state. + This method is called when AFL++ starts up and is used to seed RNG and set + up buffers and state. - `queue_get` (optional): @@ -121,18 +123,17 @@ def deinit(): # optional for Python - `fuzz` (optional): This method performs custom mutations on a given input. It also accepts an - additional test case. - Note that this function is optional - but it makes sense to use it. - You would only skip this if `post_process` is used to fix checksums etc. - so if you are using it, e.g., as a post processing library. + additional test case. Note that this function is optional - but it makes + sense to use it. You would only skip this if `post_process` is used to fix + checksums etc. so if you are using it, e.g., as a post processing library. Note that a length > 0 *must* be returned! - `describe` (optional): When this function is called, it shall describe the current test case, - generated by the last mutation. This will be called, for example, - to name the written test case file after a crash occurred. - Using it can help to reproduce crashing mutations. + generated by the last mutation. This will be called, for example, to name + the written test case file after a crash occurred. Using it can help to + reproduce crashing mutations. - `havoc_mutation` and `havoc_mutation_probability` (optional): @@ -144,21 +145,21 @@ def deinit(): # optional for Python - `post_process` (optional): For some cases, the format of the mutated data returned from the custom - mutator is not suitable to directly execute the target with this input. - For example, when using libprotobuf-mutator, the data returned is in a - protobuf format which corresponds to a given grammar. In order to execute - the target, the protobuf data must be converted to the plain-text format - expected by the target. In such scenarios, the user can define the - `post_process` function. This function is then transforming the data into the - format expected by the API before executing the target. + mutator is not suitable to directly execute the target with this input. For + example, when using libprotobuf-mutator, the data returned is in a protobuf + format which corresponds to a given grammar. In order to execute the target, + the protobuf data must be converted to the plain-text format expected by the + target. In such scenarios, the user can define the `post_process` function. + This function is then transforming the data into the format expected by the + API before executing the target. This can return any python object that implements the buffer protocol and supports PyBUF_SIMPLE. These include bytes, bytearray, etc. - `queue_new_entry` (optional): - This methods is called after adding a new test case to the queue. - If the contents of the file was changed return True, False otherwise. + This methods is called after adding a new test case to the queue. If the + contents of the file was changed, return True, False otherwise. - `introspection` (optional): @@ -170,8 +171,8 @@ def deinit(): # optional for Python The last method to be called, deinitializing the state. -Note that there are also three functions for trimming as described in the -next section. +Note that there are also three functions for trimming as described in the next +section. ### Trimming Support @@ -179,8 +180,8 @@ The generic trimming routines implemented in AFL++ can easily destroy the structure of complex formats, possibly leading to a point where you have a lot of test cases in the queue that your Python module cannot process anymore but your target application still accepts. This is especially the case when your -target can process a part of the input (causing coverage) and then errors out -on the remaining input. +target can process a part of the input (causing coverage) and then errors out on +the remaining input. In such cases, it makes sense to implement a custom trimming routine. The API consists of multiple methods because after each trimming step, we have to go @@ -213,10 +214,10 @@ trimmed input. Here's a quick API description: - `post_trim` (optional) This method is called after each trim operation to inform you if your - trimming step was successful or not (in terms of coverage). If you receive - a failure here, you should reset your input to the last known good state. - In any case, this method must return the next trim iteration index (from 0 - to the maximum amount of steps you returned in `init_trim`). + trimming step was successful or not (in terms of coverage). If you receive a + failure here, you should reset your input to the last known good state. In + any case, this method must return the next trim iteration index (from 0 to + the maximum amount of steps you returned in `init_trim`). Omitting any of three trimming methods will cause the trimming to be disabled and trigger a fallback to the built-in default trimming routine. @@ -227,10 +228,10 @@ Optionally, the following environment variables are supported: - `AFL_CUSTOM_MUTATOR_ONLY` - Disable all other mutation stages. This can prevent broken test cases - (those that your Python module can't work with anymore) to fill up your - queue. Best combined with a custom trimming routine (see below) because - trimming can cause the same test breakage like havoc and splice. + Disable all other mutation stages. This can prevent broken test cases (those + that your Python module can't work with anymore) to fill up your queue. Best + combined with a custom trimming routine (see below) because trimming can + cause the same test breakage like havoc and splice. - `AFL_PYTHON_ONLY` @@ -270,9 +271,10 @@ For C/C++ mutators, the source code must be compiled as a shared object: ```bash gcc -shared -Wall -O3 example.c -o example.so ``` -Note that if you specify multiple custom mutators, the corresponding functions will -be called in the order in which they are specified. e.g first `post_process` function of -`example_first.so` will be called and then that of `example_second.so`. +Note that if you specify multiple custom mutators, the corresponding functions +will be called in the order in which they are specified. e.g first +`post_process` function of `example_first.so` will be called and then that of +`example_second.so`. ### Run @@ -300,4 +302,4 @@ See [example.c](../custom_mutators/examples/example.c) and - [bruce30262/libprotobuf-mutator_fuzzing_learning](https://github.com/bruce30262/libprotobuf-mutator_fuzzing_learning/tree/master/4_libprotobuf_aflpp_custom_mutator) - [thebabush/afl-libprotobuf-mutator](https://github.com/thebabush/afl-libprotobuf-mutator) - [XML Fuzzing@NullCon 2017](https://www.agarri.fr/docs/XML_Fuzzing-NullCon2017-PUBLIC.pdf) - - [A bug detected by AFL + XML-aware mutators](https://bugs.chromium.org/p/chromium/issues/detail?id=930663) + - [A bug detected by AFL + XML-aware mutators](https://bugs.chromium.org/p/chromium/issues/detail?id=930663) \ No newline at end of file diff --git a/docs/env_variables.md b/docs/env_variables.md index 771bf157..3f7bdadb 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -590,79 +590,81 @@ the preferred way to configure FRIDA mode is through its * `AFL_FRIDA_DEBUG_MAPS` - See `AFL_QEMU_DEBUG_MAPS` * `AFL_FRIDA_DRIVER_NO_HOOK` - See `AFL_QEMU_DRIVER_NO_HOOK`. When using the -QEMU driver to provide a `main` loop for a user provided -`LLVMFuzzerTestOneInput`, this option configures the driver to read input from -`stdin` rather than using in-memory test cases. + QEMU driver to provide a `main` loop for a user provided + `LLVMFuzzerTestOneInput`, this option configures the driver to read input from + `stdin` rather than using in-memory test cases. * `AFL_FRIDA_EXCLUDE_RANGES` - See `AFL_QEMU_EXCLUDE_RANGES` * `AFL_FRIDA_INST_COVERAGE_FILE` - File to write DynamoRio format coverage -information (e.g., to be loaded within IDA lighthouse). + information (e.g., to be loaded within IDA lighthouse). * `AFL_FRIDA_INST_DEBUG_FILE` - File to write raw assembly of original blocks -and their instrumented counterparts during block compilation. + and their instrumented counterparts during block compilation. * `AFL_FRIDA_INST_JIT` - Enable the instrumentation of Just-In-Time compiled -code. Code is considered to be JIT if the executable segment is not backed by a -file. + code. Code is considered to be JIT if the executable segment is not backed by + a file. * `AFL_FRIDA_INST_NO_OPTIMIZE` - Don't use optimized inline assembly coverage -instrumentation (the default where available). Required to use -`AFL_FRIDA_INST_TRACE`. + instrumentation (the default where available). Required to use + `AFL_FRIDA_INST_TRACE`. * `AFL_FRIDA_INST_NO_BACKPATCH` - Disable backpatching. At the end of executing -each block, control will return to FRIDA to identify the next block to execute. + each block, control will return to FRIDA to identify the next block to + execute. * `AFL_FRIDA_INST_NO_PREFETCH` - Disable prefetching. By default the child will -report instrumented blocks back to the parent so that it can also instrument -them and they be inherited by the next child on fork, implies -`AFL_FRIDA_INST_NO_PREFETCH_BACKPATCH`. + report instrumented blocks back to the parent so that it can also instrument + them and they be inherited by the next child on fork, implies + `AFL_FRIDA_INST_NO_PREFETCH_BACKPATCH`. * `AFL_FRIDA_INST_NO_PREFETCH_BACKPATCH` - Disable prefetching of stalker -backpatching information. By default the child will report applied backpatches -to the parent so that they can be applied and then be inherited by the next -child on fork. + backpatching information. By default the child will report applied backpatches + to the parent so that they can be applied and then be inherited by the next + child on fork. * `AFL_FRIDA_INST_RANGES` - See `AFL_QEMU_INST_RANGES` * `AFL_FRIDA_INST_SEED` - Sets the initial seed for the hash function used to -generate block (and hence edge) IDs. Setting this to a constant value may be -useful for debugging purposes, e.g., investigating unstable edges. -* `AFL_FRIDA_INST_TRACE` - Log to stdout the address of executed blocks, -implies `AFL_FRIDA_INST_NO_OPTIMIZE`. + generate block (and hence edge) IDs. Setting this to a constant value may be + useful for debugging purposes, e.g., investigating unstable edges. +* `AFL_FRIDA_INST_TRACE` - Log to stdout the address of executed blocks, implies + `AFL_FRIDA_INST_NO_OPTIMIZE`. * `AFL_FRIDA_INST_TRACE_UNIQUE` - As per `AFL_FRIDA_INST_TRACE`, but each edge -is logged only once, requires `AFL_FRIDA_INST_NO_OPTIMIZE`. + is logged only once, requires `AFL_FRIDA_INST_NO_OPTIMIZE`. * `AFL_FRIDA_INST_UNSTABLE_COVERAGE_FILE` - File to write DynamoRio format -coverage information for unstable edges (e.g., to be loaded within IDA -lighthouse). + coverage information for unstable edges (e.g., to be loaded within IDA + lighthouse). * `AFL_FRIDA_JS_SCRIPT` - Set the script to be loaded by the FRIDA scripting -engine. See [here](Scripting.md) for details. + engine. See [here](Scripting.md) for details. * `AFL_FRIDA_OUTPUT_STDOUT` - Redirect the standard output of the target -application to the named file (supersedes the setting of `AFL_DEBUG_CHILD`) + application to the named file (supersedes the setting of `AFL_DEBUG_CHILD`) * `AFL_FRIDA_OUTPUT_STDERR` - Redirect the standard error of the target -application to the named file (supersedes the setting of `AFL_DEBUG_CHILD`) + application to the named file (supersedes the setting of `AFL_DEBUG_CHILD`) * `AFL_FRIDA_PERSISTENT_ADDR` - See `AFL_QEMU_PERSISTENT_ADDR` * `AFL_FRIDA_PERSISTENT_CNT` - See `AFL_QEMU_PERSISTENT_CNT` * `AFL_FRIDA_PERSISTENT_DEBUG` - Insert a Breakpoint into the instrumented code -at `AFL_FRIDA_PERSISTENT_HOOK` and `AFL_FRIDA_PERSISTENT_RET` to allow the user -to detect issues in the persistent loop using a debugger. + at `AFL_FRIDA_PERSISTENT_HOOK` and `AFL_FRIDA_PERSISTENT_RET` to allow the + user to detect issues in the persistent loop using a debugger. * `AFL_FRIDA_PERSISTENT_HOOK` - See `AFL_QEMU_PERSISTENT_HOOK` * `AFL_FRIDA_PERSISTENT_RET` - See `AFL_QEMU_PERSISTENT_RET` * `AFL_FRIDA_SECCOMP_FILE` - Write a log of any syscalls made by the target to -the specified file. + the specified file. * `AFL_FRIDA_STALKER_ADJACENT_BLOCKS` - Configure the number of adjacent blocks - to fetch when generating instrumented code. By fetching blocks in the same - order they appear in the original program, rather than the order of execution - should help reduce locallity and adjacency. This includes allowing us to vector - between adjancent blocks using a NOP slide rather than an immediate branch. + to fetch when generating instrumented code. By fetching blocks in the same + order they appear in the original program, rather than the order of execution + should help reduce locallity and adjacency. This includes allowing us to + vector between adjancent blocks using a NOP slide rather than an immediate + branch. * `AFL_FRIDA_STALKER_IC_ENTRIES` - Configure the number of inline cache entries -stored along-side branch instructions which provide a cache to avoid having to -call back into FRIDA to find the next block. Default is 32. + stored along-side branch instructions which provide a cache to avoid having to + call back into FRIDA to find the next block. Default is 32. * `AFL_FRIDA_STATS_FILE` - Write statistics information about the code being -instrumented to the given file name. The statistics are written only for the -child process when new block is instrumented (when the -`AFL_FRIDA_STATS_INTERVAL` has expired). Note that just because a new path is -found does not mean a new block needs to be compiled. It could be that -the existing blocks instrumented have been executed in a different order. + instrumented to the given file name. The statistics are written only for the + child process when new block is instrumented (when the + `AFL_FRIDA_STATS_INTERVAL` has expired). Note that just because a new path is + found does not mean a new block needs to be compiled. It could be that the + existing blocks instrumented have been executed in a different order. * `AFL_FRIDA_STATS_INTERVAL` - The maximum frequency to output statistics -information. Stats will be written whenever they are updated if the given -interval has elapsed since last time they were written. + information. Stats will be written whenever they are updated if the given + interval has elapsed since last time they were written. * `AFL_FRIDA_TRACEABLE` - Set the child process to be traceable by any process -to aid debugging and overcome the restrictions imposed by YAMA. Supported on -Linux only. Permits a non-root user to use `gcore` or similar to collect a core -dump of the instrumented target. Note that in order to capture the core dump you -must set a sufficient timeout (using `-t`) to avoid `afl-fuzz` killing the -process whilst it is being dumped. + to aid debugging and overcome the restrictions imposed by YAMA. Supported on + Linux only. Permits a non-root user to use `gcore` or similar to collect a + core dump of the instrumented target. Note that in order to capture the core + dump you must set a sufficient timeout (using `-t`) to avoid `afl-fuzz` + killing the process whilst it is being dumped. ## 8) Settings for afl-cmin diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index a786fd8b..b3d9ca02 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -84,7 +84,8 @@ Wine, python3, and the pefile python package installed. It is included in AFL++. -For more information, see [qemu_mode/README.wine.md](../qemu_mode/README.wine.md). +For more information, see +[qemu_mode/README.wine.md](../qemu_mode/README.wine.md). ### Frida_mode @@ -169,7 +170,8 @@ Fore more information, see ## Binary rewriters -An alternative solution are binary rewriters. They are faster then the solutions native to AFL++ but don't always work. +An alternative solution are binary rewriters. They are faster then the solutions +native to AFL++ but don't always work. ### ZAFL ZAFL is a static rewriting platform supporting x86-64 C/C++, diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index d408aa91..9611d6b7 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -259,6 +259,7 @@ Then build the target. (Usually with `make`) #### configure For `configure` build systems this is usually done by: + `CC=afl-clang-fast CXX=afl-clang-fast++ ./configure --disable-shared` Note that if you are using the (better) afl-clang-lto compiler you also have to @@ -268,6 +269,7 @@ described in [instrumentation/README.lto.md](../instrumentation/README.lto.md). #### cmake For `cmake` build systems this is usually done by: + `mkdir build; cd build; cmake -DCMAKE_C_COMPILER=afl-cc -DCMAKE_CXX_COMPILER=afl-c++ ..` Note that if you are using the (better) afl-clang-lto compiler you also have to @@ -307,8 +309,8 @@ it for a hobby and not professionally :-). ### g) libfuzzer fuzzer harnesses with LLVMFuzzerTestOneInput() -libfuzzer `LLVMFuzzerTestOneInput()` harnesses are the defacto standard -for fuzzing, and they can be used with AFL++ (and honggfuzz) as well! +libfuzzer `LLVMFuzzerTestOneInput()` harnesses are the defacto standard for +fuzzing, and they can be used with AFL++ (and honggfuzz) as well! Compiling them is as simple as: @@ -358,8 +360,11 @@ Put all files from step a) into one directory, e.g., INPUTS. If the target program is to be called by fuzzing as `bin/target -d INPUTFILE` the run afl-cmin like this: + `afl-cmin -i INPUTS -o INPUTS_UNIQUE -- bin/target -d @@` -Note that the INPUTFILE argument that the target program would read from has to be set as `@@`. + +Note that the INPUTFILE argument that the target program would read from has to +be set as `@@`. If the target reads from stdin instead, just omit the `@@` as this is the default. @@ -420,22 +425,25 @@ as test data in there. If you do not want anything special, the defaults are already usually best, hence all you need is to specify the seed input directory with the result of step [2a) Collect inputs](#a-collect-inputs): + `afl-fuzz -i input -o output -- bin/target -d @@` -Note that the directory specified with -o will be created if it does not exist. + +Note that the directory specified with `-o` will be created if it does not +exist. It can be valuable to run afl-fuzz in a screen or tmux shell so you can log off, or afl-fuzz is not aborted if you are running it in a remote ssh session where -the connection fails in between. -Only do that though once you have verified that your fuzzing setup works! -Run it like `screen -dmS afl-main -- afl-fuzz -M main-$HOSTNAME -i ...` -and it will start away in a screen session. To enter this session, type -`screen -r afl-main`. You see - it makes sense to name the screen session -same as the afl-fuzz -M/-S naming :-) -For more information on screen or tmux, check their documentation. +the connection fails in between. Only do that though once you have verified that +your fuzzing setup works! Run it like `screen -dmS afl-main -- afl-fuzz -M +main-$HOSTNAME -i ...` and it will start away in a screen session. To enter this +session, type `screen -r afl-main`. You see - it makes sense to name the screen +session same as the afl-fuzz -M/-S naming :-) For more information on screen or +tmux, check their documentation. If you need to stop and re-start the fuzzing, use the same command line options (or even change them by selecting a different power schedule or another mutation mode!) and switch the input directory with a dash (`-`): + `afl-fuzz -i - -o output -- bin/target -d @@` Adding a dictionary is helpful. See the directory @@ -457,12 +465,13 @@ handling in the target. Play around with various -m values until you find one that safely works for all your input seeds (if you have good ones and then double or quadruple that. -By default afl-fuzz never stops fuzzing. To terminate AFL++, press -Control-C or send a signal SIGINT. You can limit the number of executions or -approximate runtime in seconds with options also. +By default afl-fuzz never stops fuzzing. To terminate AFL++, press Control-C or +send a signal SIGINT. You can limit the number of executions or approximate +runtime in seconds with options also. When you start afl-fuzz you will see a user interface that shows what the status is: + ![resources/screenshot.png](resources/screenshot.png) All labels are explained in [status_screen.md](status_screen.md). @@ -528,8 +537,8 @@ All other secondaries should be used like this: Also, it is recommended to set `export AFL_IMPORT_FIRST=1` to load test cases from other fuzzers in the campaign first. -If you have a large corpus, a corpus from a previous run or are fuzzing in -a CI, then also set `export AFL_CMPLOG_ONLY_NEW=1` and `export AFL_FAST_CAL=1`. +If you have a large corpus, a corpus from a previous run or are fuzzing in a CI, +then also set `export AFL_CMPLOG_ONLY_NEW=1` and `export AFL_FAST_CAL=1`. You can also use different fuzzers. If you are using AFL spinoffs or AFL conforming fuzzers, then just use the same -o directory and give it a unique @@ -553,11 +562,10 @@ recommended! ### d) Using multiple machines for fuzzing -Maybe you have more than one machine you want to fuzz the same target on. -Start the `afl-fuzz` (and perhaps libfuzzer, honggfuzz, ...) -orchestra as you like, just ensure that your have one and only one `-M` -instance per server, and that its name is unique, hence the recommendation -for `-M main-$HOSTNAME`. +Maybe you have more than one machine you want to fuzz the same target on. Start +the `afl-fuzz` (and perhaps libfuzzer, honggfuzz, ...) orchestra as you like, +just ensure that your have one and only one `-M` instance per server, and that +its name is unique, hence the recommendation for `-M main-$HOSTNAME`. Now there are three strategies on how you can sync between the servers: * never: sounds weird, but this makes every server an island and has the chance diff --git a/docs/ideas.md b/docs/ideas.md index 8193983b..1a578313 100644 --- a/docs/ideas.md +++ b/docs/ideas.md @@ -1,31 +1,29 @@ # Ideas for AFL++ -In the following, we describe a variety of ideas that could be implemented -for future AFL++ versions. +In the following, we describe a variety of ideas that could be implemented for +future AFL++ versions. ## Analysis software -Currently analysis is done by using afl-plot, which is rather outdated. -A GTK or browser tool to create run-time analysis based on fuzzer_stats, -queue/id* information and plot_data that allows for zooming in and out, -changing min/max display values etc. and doing that for a single run, -different runs and campaigns vs campaigns. -Interesting values are execs, and execs/s, edges discovered (total, when -each edge was discovered and which other fuzzer share finding that edge), -test cases executed. -It should be clickable which value is X and Y axis, zoom factor, log scaling -on-off, etc. +Currently analysis is done by using afl-plot, which is rather outdated. A GTK or +browser tool to create run-time analysis based on fuzzer_stats, queue/id* +information and plot_data that allows for zooming in and out, changing min/max +display values etc. and doing that for a single run, different runs and +campaigns vs campaigns. Interesting values are execs, and execs/s, edges +discovered (total, when each edge was discovered and which other fuzzer share +finding that edge), test cases executed. It should be clickable which value is X +and Y axis, zoom factor, log scaling on-off, etc. Mentor: vanhauser-thc ## WASM Instrumentation Currently, AFL++ can be used for source code fuzzing and traditional binaries. -With the rise of WASM as compile target, however, a novel way of -instrumentation needs to be implemented for binaries compiled to Webassembly. -This can either be done by inserting instrumentation directly into the -WASM AST, or by patching feedback into a WASM VMs of choice, similar to -the current Unicorn instrumentation. +With the rise of WASM as compile target, however, a novel way of instrumentation +needs to be implemented for binaries compiled to Webassembly. This can either be +done by inserting instrumentation directly into the WASM AST, or by patching +feedback into a WASM VMs of choice, similar to the current Unicorn +instrumentation. Mentor: any @@ -34,25 +32,26 @@ Mentor: any Other programming languages also use llvm hence they could (easily?) supported for fuzzing, e.g., mono, swift, go, kotlin native, fortran, ... -GCC also supports: Objective-C, Fortran, Ada, Go, and D -(according to [Gcc homepage](https://gcc.gnu.org/)) +GCC also supports: Objective-C, Fortran, Ada, Go, and D (according to +[Gcc homepage](https://gcc.gnu.org/)) -LLVM is also used by: Rust, LLGo (Go), kaleidoscope (Haskell), flang (Fortran), emscripten (JavaScript, WASM), ilwasm (CIL (C#)) -(according to [LLVM frontends](https://gist.github.com/axic/62d66fb9d8bccca6cc48fa9841db9241)) +LLVM is also used by: Rust, LLGo (Go), kaleidoscope (Haskell), flang (Fortran), +emscripten (JavaScript, WASM), ilwasm (CIL (C#)) (according to +[LLVM frontends](https://gist.github.com/axic/62d66fb9d8bccca6cc48fa9841db9241)) Mentor: vanhauser-thc ## Machine Learning -Something with machine learning, better than [NEUZZ](https://github.com/dongdongshe/neuzz) :-) -Either improve a single mutator thorugh learning of many different bugs -(a bug class) or gather deep insights about a single target beforehand -(CFG, DFG, VFG, ...?) and improve performance for a single target. +Something with machine learning, better than +[NEUZZ](https://github.com/dongdongshe/neuzz) :-) Either improve a single +mutator thorugh learning of many different bugs (a bug class) or gather deep +insights about a single target beforehand (CFG, DFG, VFG, ...?) and improve +performance for a single target. Mentor: domenukk ## Your idea! -Finally, we are open to proposals! -Create an issue at https://github.com/AFLplusplus/AFLplusplus/issues and let's discuss :-) - +Finally, we are open to proposals! Create an issue at +https://github.com/AFLplusplus/AFLplusplus/issues and let's discuss :-) \ No newline at end of file diff --git a/docs/important_changes.md b/docs/important_changes.md index 82de054f..9d4523e8 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -1,6 +1,7 @@ # Important changes in AFL++ -This document lists important changes in AFL++, for example, major behavior changes. +This document lists important changes in AFL++, for example, major behavior +changes. ## From version 3.00 onwards @@ -10,8 +11,8 @@ iOS etc. With AFL++ 3.15 we introduced the following changes from previous behaviors: * Also -M main mode does not do deterministic fuzzing by default anymore - * afl-cmin and afl-showmap -Ci now descent into subdirectories like - afl-fuzz -i does (but note that afl-cmin.bash does not) + * afl-cmin and afl-showmap -Ci now descent into subdirectories like afl-fuzz + -i does (but note that afl-cmin.bash does not) With AFL++ 3.14 we introduced the following changes from previous behaviors: * afl-fuzz: deterministic fuzzing it not a default for -M main anymore @@ -31,22 +32,22 @@ behaviors and defaults: * The gcc_plugin was replaced with a new version submitted by AdaCore that supports more features. Thank you! * qemu_mode got upgraded to QEMU 5.1, but to be able to build this a current - ninja build tool version and python3 setuptools are required. - qemu_mode also got new options like snapshotting, instrumenting specific - shared libraries, etc. Additionally QEMU 5.1 supports more CPU targets so - this is really worth it. + ninja build tool version and python3 setuptools are required. qemu_mode also + got new options like snapshotting, instrumenting specific shared libraries, + etc. Additionally QEMU 5.1 supports more CPU targets so this is really worth + it. * When instrumenting targets, afl-cc will not supersede optimizations anymore if any were given. This allows to fuzz targets build regularly like those for debug or release versions. * afl-fuzz: - * if neither -M or -S is specified, `-S default` is assumed, so more - fuzzers can easily be added later - * `-i` input directory option now descends into subdirectories. It also - does not fatal on crashes and too large files, instead it skips them - and uses them for splicing mutations + * if neither -M or -S is specified, `-S default` is assumed, so more fuzzers + can easily be added later + * `-i` input directory option now descends into subdirectories. It also does + not fatal on crashes and too large files, instead it skips them and uses + them for splicing mutations * -m none is now default, set memory limits (in MB) with, e.g., -m 250 - * deterministic fuzzing is now disabled by default (unless using -M) and - can be enabled with -D + * deterministic fuzzing is now disabled by default (unless using -M) and can + be enabled with -D * a caching of test cases can now be performed and can be modified by editing config.h for TESTCASE_CACHE or by specifying the environment variable `AFL_TESTCACHE_SIZE` (in MB). Good values are between 50-500 diff --git a/docs/rpc_statsd.md b/docs/rpc_statsd.md index 9b3d8d40..003b9c79 100644 --- a/docs/rpc_statsd.md +++ b/docs/rpc_statsd.md @@ -1,18 +1,29 @@ # Remote monitoring and metrics visualization -AFL++ can send out metrics as StatsD messages. For remote monitoring and visualization of the metrics, you can set up a tool chain. For example, with Prometheus and Grafana. All tools are free and open source. +AFL++ can send out metrics as StatsD messages. For remote monitoring and +visualization of the metrics, you can set up a tool chain. For example, with +Prometheus and Grafana. All tools are free and open source. -This enables you to create nice and readable dashboards containing all the information you need on your fuzzer instances. There is no need to write your own statistics parsing system, deploy and maintain it to all your instances, and sync with your graph rendering system. +This enables you to create nice and readable dashboards containing all the +information you need on your fuzzer instances. There is no need to write your +own statistics parsing system, deploy and maintain it to all your instances, and +sync with your graph rendering system. -Compared to the default integrated UI of AFL++, this can help you to visualize trends and the fuzzing state over time. You might be able to see when the fuzzing process has reached a state of no progress and visualize what are the "best strategies" for your targets (according to your own criteria). You can do so without logging into each instance individually. +Compared to the default integrated UI of AFL++, this can help you to visualize +trends and the fuzzing state over time. You might be able to see when the +fuzzing process has reached a state of no progress and visualize what are the +"best strategies" for your targets (according to your own criteria). You can do +so without logging into each instance individually. ![example visualization with Grafana](resources/statsd-grafana.png) -This is an example visualization with Grafana. The dashboard can be imported with [this JSON template](resources/grafana-afl++.json). +This is an example visualization with Grafana. The dashboard can be imported +with [this JSON template](resources/grafana-afl++.json). ## AFL++ metrics and StatsD -StatsD allows you to receive and aggregate metrics from a wide range of applications and retransmit them to a backend of your choice. +StatsD allows you to receive and aggregate metrics from a wide range of +applications and retransmit them to a backend of your choice. From AFL++, StatsD can receive the following metrics: - cur_path @@ -36,35 +47,57 @@ From AFL++, StatsD can receive the following metrics: - var_byte_count - variable_paths -Depending on your StatsD server, you will be able to monitor, trigger alerts, or perform actions based on these metrics (for example: alert on slow exec/s for a new build, threshold of crashes, time since last crash > X, and so on). +Depending on your StatsD server, you will be able to monitor, trigger alerts, or +perform actions based on these metrics (for example: alert on slow exec/s for a +new build, threshold of crashes, time since last crash > X, and so on). ## Setting environment variables in AFL++ -1. To enable the StatsD metrics collection on your fuzzer instances, set the environment variable `AFL_STATSD=1`. By default, AFL++ will send the metrics over UDP to 127.0.0.1:8125. +1. To enable the StatsD metrics collection on your fuzzer instances, set the + environment variable `AFL_STATSD=1`. By default, AFL++ will send the metrics + over UDP to 127.0.0.1:8125. -2. To enable tags for each metric based on their format (banner and afl_version), set the environment variable `AFL_STATSD_TAGS_FLAVOR`. By default, no tags will be added to the metrics. +2. To enable tags for each metric based on their format (banner and + afl_version), set the environment variable `AFL_STATSD_TAGS_FLAVOR`. By + default, no tags will be added to the metrics. The available values are the following: - `dogstatsd` - `influxdb` - `librato` - `signalfx` - - For more information on environment variables, see [env_variables.md](env_variables.md). - Note: When using multiple fuzzer instances with StatsD it is *strongly* recommended to set up `AFL_STATSD_TAGS_FLAVOR` to match your StatsD server. This will allow you to see individual fuzzer performance, detect bad ones, and see the progress of each strategy. + For more information on environment variables, see + [env_variables.md](env_variables.md). -3. Optional: To set the host and port of your StatsD daemon, set `AFL_STATSD_HOST` and `AFL_STATSD_PORT`. The default values are `localhost` and `8125`. + Note: When using multiple fuzzer instances with StatsD it is *strongly* + recommended to set up `AFL_STATSD_TAGS_FLAVOR` to match your StatsD server. + This will allow you to see individual fuzzer performance, detect bad ones, + and see the progress of each strategy. + +3. Optional: To set the host and port of your StatsD daemon, set + `AFL_STATSD_HOST` and `AFL_STATSD_PORT`. The default values are `localhost` + and `8125`. ## Installing and setting up StatsD, Prometheus, and Grafana -The easiest way to install and set up the infrastructure is with Docker and Docker Compose. +The easiest way to install and set up the infrastructure is with Docker and +Docker Compose. -Depending on your fuzzing setup and infrastructure, you may not want to run these applications on your fuzzer instances. This setup may be modified before use in a production environment; for example, adding passwords, creating volumes for storage, tweaking the metrics gathering to get host metrics (CPU, RAM, and so on). +Depending on your fuzzing setup and infrastructure, you may not want to run +these applications on your fuzzer instances. This setup may be modified before +use in a production environment; for example, adding passwords, creating volumes +for storage, tweaking the metrics gathering to get host metrics (CPU, RAM, and +so on). -For all your fuzzing instances, only one instance of Prometheus and Grafana is required. The [statsd exporter](https://registry.hub.docker.com/r/prom/statsd-exporter) converts the StatsD metrics to Prometheus. If you are using a provider that supports StatsD directly, you can skip this part of the setup." +For all your fuzzing instances, only one instance of Prometheus and Grafana is +required. The +[statsd exporter](https://registry.hub.docker.com/r/prom/statsd-exporter) +converts the StatsD metrics to Prometheus. If you are using a provider that +supports StatsD directly, you can skip this part of the setup." -You can create and move the infrastructure files into a directory of your choice. The directory will store all the required configuration files. +You can create and move the infrastructure files into a directory of your +choice. The directory will store all the required configuration files. To install and set up Prometheus and Grafana: @@ -76,6 +109,7 @@ To install and set up Prometheus and Grafana: ``` 2. Create a `docker-compose.yml` containing the following: + ```yml version: '3' @@ -109,7 +143,7 @@ To install and set up Prometheus and Grafana: - "8125:9125/udp" networks: - statsd-net - + grafana: image: grafana/grafana container_name: grafana @@ -134,7 +168,8 @@ To install and set up Prometheus and Grafana: ``` 4. Create a `statsd_mapping.yml` containing the following: - ```yml + + ```yml mappings: - match: "fuzzing.*" name: "fuzzing" @@ -152,4 +187,4 @@ To run your fuzzing instances: AFL_STATSD_TAGS_FLAVOR=dogstatsd AFL_STATSD=1 afl-fuzz -M test-fuzzer-1 -i i -o o [./bin/my-application] @@ AFL_STATSD_TAGS_FLAVOR=dogstatsd AFL_STATSD=1 afl-fuzz -S test-fuzzer-2 -i i -o o [./bin/my-application] @@ ... -``` +``` \ No newline at end of file diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index fd4282db..63ab1718 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -334,8 +334,8 @@ Interceptor.replace(LLVMFuzzerTestOneInput, cm.My_LLVMFuzzerTestOneInput); ### Hooking `main` -Lastly, it should be noted that using FRIDA mode's scripting support to hook -the `main` function is a special case. This is because the `main` function is +Lastly, it should be noted that using FRIDA mode's scripting support to hook the +`main` function is a special case. This is because the `main` function is already hooked by the FRIDA mode engine itself and hence the function `main` (or at least the first basic block already been compiled by Stalker ready for execution). Hence any attempt to use `Interceptor.replace` like in the example @@ -405,22 +405,22 @@ Consider the [following](test/js/test2.c) test code... #include const uint32_t crc32_tab[] = { - 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, + 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, ... - 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d + 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d }; uint32_t crc32(const void *buf, size_t size) { - const uint8_t *p = buf; - uint32_t crc; - crc = ~0U; - while (size--) - crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8); - return crc ^ ~0U; + const uint8_t *p = buf; + uint32_t crc; + crc = ~0U; + while (size--) + crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8); + return crc ^ ~0U; } /* diff --git a/instrumentation/README.gcc_plugin.md b/instrumentation/README.gcc_plugin.md index f251415b..ef38662b 100644 --- a/instrumentation/README.gcc_plugin.md +++ b/instrumentation/README.gcc_plugin.md @@ -1,7 +1,7 @@ # GCC-based instrumentation for afl-fuzz -For the general instruction manual, see [../README.md](../README.md). -For the LLVM-based instrumentation, see [README.llvm.md](README.llvm.md). +For the general instruction manual, see [../README.md](../README.md). For the +LLVM-based instrumentation, see [README.llvm.md](README.llvm.md). This document describes how to build and use `afl-gcc-fast` and `afl-g++-fast`, which instrument the target with the help of gcc plugins. -- cgit 1.4.1 From 3506077fd6f250f3c080b58ea3bae117c3b122da Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sat, 4 Dec 2021 22:28:05 +0100 Subject: Add missing blank lines and remove double blank lines --- custom_mutators/README.md | 1 + custom_mutators/gramatron/README.md | 1 + custom_mutators/libfuzzer/README.md | 4 +++- docs/custom_mutators.md | 8 +++++++- docs/fuzzing_binary-only_targets.md | 3 ++- docs/fuzzing_in_depth.md | 1 - frida_mode/README.md | 1 + unicorn_mode/README.md | 1 - unicorn_mode/samples/c/COMPILE.md | 1 + unicorn_mode/samples/speedtest/README.md | 13 ++++++++++--- utils/afl_untracer/README.md | 8 +++++++- utils/autodict_ql/readme.md | 17 ++++++++++------- utils/qbdi_mode/README.md | 8 ++++---- utils/qemu_persistent_hook/README.md | 2 +- 14 files changed, 48 insertions(+), 21 deletions(-) (limited to 'frida_mode') diff --git a/custom_mutators/README.md b/custom_mutators/README.md index fa877f34..0289e150 100644 --- a/custom_mutators/README.md +++ b/custom_mutators/README.md @@ -15,6 +15,7 @@ In `./rust`, you will find rust bindings, including a simple example in `./rust/ If you use git to clone AFL++, then the following will incorporate our excellent grammar custom mutator: + ```sh git submodule update --init ``` diff --git a/custom_mutators/gramatron/README.md b/custom_mutators/gramatron/README.md index 2ed014cd..5e10f97b 100644 --- a/custom_mutators/gramatron/README.md +++ b/custom_mutators/gramatron/README.md @@ -34,6 +34,7 @@ afl-fuzz -i in -o out -- ./target E.g., ./preprocess/prep_automaton.sh ~/grammars/ruby/source.json PROGRAM ``` + - If the grammar has no self-embedding rules then you do not need to pass the stack limit parameter. However, if it does have self-embedding rules then you need to pass the stack limit parameter. We recommend starting with `5` and diff --git a/custom_mutators/libfuzzer/README.md b/custom_mutators/libfuzzer/README.md index fb3025f2..cb4773b7 100644 --- a/custom_mutators/libfuzzer/README.md +++ b/custom_mutators/libfuzzer/README.md @@ -11,9 +11,11 @@ Note that this is currently a simple implementation and it is missing two featur * Dictionary support To update the source, all that is needed is that FuzzerDriver.cpp has to receive + ``` #include "libfuzzer.inc" ``` + before the closing namespace bracket. It is also libfuzzer.inc where the configuration of the libfuzzer mutations @@ -21,4 +23,4 @@ are done. > Original repository: https://github.com/llvm/llvm-project > Path: compiler-rt/lib/fuzzer/*.{h|cpp} -> Source commit: df3e903655e2499968fc7af64fb5fa52b2ee79bb +> Source commit: df3e903655e2499968fc7af64fb5fa52b2ee79bb \ No newline at end of file diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 0e94ab10..2f632e1f 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -23,6 +23,7 @@ The custom mutator is passed to `afl-fuzz` via the `AFL_CUSTOM_MUTATOR_LIBRARY` or `AFL_PYTHON_MODULE` environment variable, and must export a fuzz function. Now AFL++ also supports multiple custom mutators which can be specified in the same `AFL_CUSTOM_MUTATOR_LIBRARY` environment variable like this. + ```bash export AFL_CUSTOM_MUTATOR_LIBRARY="full/path/to/mutator_first.so;full/path/to/mutator_second.so" ``` @@ -38,6 +39,7 @@ performed with the custom mutator. ## 2) APIs C/C++: + ```c void *afl_custom_init(afl_state_t *afl, unsigned int seed); unsigned int afl_custom_fuzz_count(void *data, const unsigned char *buf, size_t buf_size); @@ -56,6 +58,7 @@ void afl_custom_deinit(void *data); ``` Python: + ```python def init(seed): pass @@ -233,7 +236,6 @@ Optionally, the following environment variables are supported: combined with a custom trimming routine (see below) because trimming can cause the same test breakage like havoc and splice. - - `AFL_PYTHON_ONLY` Deprecated and removed, use `AFL_CUSTOM_MUTATOR_ONLY` instead. @@ -268,9 +270,11 @@ In case your setup is different, set the necessary variables like this: ### Custom Mutator Preparation For C/C++ mutators, the source code must be compiled as a shared object: + ```bash gcc -shared -Wall -O3 example.c -o example.so ``` + Note that if you specify multiple custom mutators, the corresponding functions will be called in the order in which they are specified. e.g. first `post_process` function of `example_first.so` will be called and then that of @@ -279,12 +283,14 @@ will be called in the order in which they are specified. e.g. first ### Run C/C++ + ```bash export AFL_CUSTOM_MUTATOR_LIBRARY="/full/path/to/example_first.so;/full/path/to/example_second.so" afl-fuzz /path/to/program ``` Python + ```bash export PYTHONPATH=`dirname /full/path/to/example.py` export AFL_PYTHON_MODULE=example diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index 15155111..eaed3a91 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -21,6 +21,7 @@ If your target is a library, then use FRIDA mode. If your target is non-linux, then use unicorn_mode. ## Fuzzing binary-only targets with AFL++ + ### QEMU mode QEMU mode is the "native" solution to the program. It is available in the @@ -175,6 +176,7 @@ An alternative solution are binary rewriters. They are faster then the solutions native to AFL++ but don't always work. ### ZAFL + ZAFL is a static rewriting platform supporting x86-64 C/C++, stripped/unstripped, and PIE/non-PIE binaries. Beyond conventional instrumentation, ZAFL's API enables transformation passes (e.g., laf-Intel, @@ -277,7 +279,6 @@ There are many binary-only fuzzing frameworks. Some are great for CTFs but don't work with large binaries, others are very slow but have good path discovery, some are very hard to set-up... - * Jackalope: [https://github.com/googleprojectzero/Jackalope](https://github.com/googleprojectzero/Jackalope) * Manticore: diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 2e030e7b..4a1ddf45 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -808,7 +808,6 @@ then color-codes the input based on which sections appear to be critical, and which are not; while not bulletproof, it can often offer quick insights into complex file formats. - ## 5. CI fuzzing Some notes on CI fuzzing - this fuzzing is different to normal fuzzing campaigns diff --git a/frida_mode/README.md b/frida_mode/README.md index e88bda8d..08f6b891 100644 --- a/frida_mode/README.md +++ b/frida_mode/README.md @@ -141,6 +141,7 @@ instances run CMPLOG mode and instrumentation of the binary is less frequent (only on CMP, SUB and CALL instructions) performance is not quite so critical. ## Advanced configuration options + * `AFL_FRIDA_DRIVER_NO_HOOK` - See `AFL_QEMU_DRIVER_NO_HOOK`. When using the QEMU driver to provide a `main` loop for a user provided `LLVMFuzzerTestOneInput`, this option configures the driver to read input from diff --git a/unicorn_mode/README.md b/unicorn_mode/README.md index 4c95e8f3..ee4a7b22 100644 --- a/unicorn_mode/README.md +++ b/unicorn_mode/README.md @@ -83,7 +83,6 @@ uses slightly older concepts, but describes the general ideas, at: [https://medium.com/@njvoss299/afl-unicorn-fuzzing-arbitrary-binary-code-563ca28936bf](https://medium.com/@njvoss299/afl-unicorn-fuzzing-arbitrary-binary-code-563ca28936bf) - The ['helper_scripts'](./helper_scripts) directory also contains several helper scripts that allow you to dump context from a running process, load it, and hook heap allocations. For details on how to use this check out the follow-up blog post to the one linked above. diff --git a/unicorn_mode/samples/c/COMPILE.md b/unicorn_mode/samples/c/COMPILE.md index 4e3cf568..e5265071 100644 --- a/unicorn_mode/samples/c/COMPILE.md +++ b/unicorn_mode/samples/c/COMPILE.md @@ -6,6 +6,7 @@ This shows a simple harness for unicornafl in C The target can be built using the `make` command. Just make sure you have built unicorn support first: + ```bash cd /path/to/afl/unicorn_mode ./build_unicorn_support.sh diff --git a/unicorn_mode/samples/speedtest/README.md b/unicorn_mode/samples/speedtest/README.md index 496d75cd..bd5ba8d0 100644 --- a/unicorn_mode/samples/speedtest/README.md +++ b/unicorn_mode/samples/speedtest/README.md @@ -35,7 +35,6 @@ cd python TODO: add results here. - ## Compiling speedtest_target.c You shouldn't need to compile simple_target.c since a X86_64 binary version is @@ -46,20 +45,28 @@ The pre-built binary (simple_target_x86_64.bin) was built using -g -O0 in gcc. Then load the binary and execute the main function directly. -## Addresses for the harness: +## Addresses for the harness + To find the address (in hex) of main, run: + ```bash objdump -M intel -D target | grep '
:' | cut -d" " -f1 ``` + To find all call sites to magicfn, run: + ```bash objdump -M intel -D target | grep '$' | cut -d":" -f1 ``` + For malloc callsites: + ```bash objdump -M intel -D target | grep '$' | cut -d":" -f1 ``` + And free callsites: + ```bash objdump -M intel -D target | grep '$' | cut -d":" -f1 -``` +``` \ No newline at end of file diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md index 3fff5f83..cd87998b 100644 --- a/utils/afl_untracer/README.md +++ b/utils/afl_untracer/README.md @@ -28,28 +28,34 @@ To generate the `patches.txt` file for your target library use the The patches.txt file has to be pointed to by `AFL_UNTRACER_FILE`. To easily run the scripts without needing to run the GUI with Ghidra: + ``` /opt/ghidra/support/analyzeHeadless /tmp/ tmp$$ -import libtestinstr.so -postscript ./ghidra_get_patchpoints.java rm -rf /tmp/tmp$$ ``` + The file is created at `~/Desktop/patches.txt` ### Fuzzing Example (after modifying afl-untracer.c to your needs, compiling and creating patches.txt): + ``` LD_LIBRARY_PATH=/path/to/target/library AFL_UNTRACER_FILE=./patches.txt afl-fuzz -i in -o out -- ./afl-untracer ``` + (or even remote via afl-network-proxy). ### Testing and debugging For testing/debugging you can try: + ``` make DEBUG=1 AFL_UNTRACER_FILE=./patches.txt AFL_DEBUG=1 gdb ./afl-untracer ``` + and then you can easily set breakpoints to "breakpoint" and "fuzz". # Background @@ -57,4 +63,4 @@ and then you can easily set breakpoints to "breakpoint" and "fuzz". This idea is based on [UnTracer](https://github.com/FoRTE-Research/UnTracer-AFL) and modified by [Trapfuzz](https://github.com/googleprojectzero/p0tools/tree/master/TrapFuzz). This implementation is slower because the traps are not patched out with each -run, but on the other hand gives much better coverage information. +run, but on the other hand gives much better coverage information. \ No newline at end of file diff --git a/utils/autodict_ql/readme.md b/utils/autodict_ql/readme.md index 491ec85b..789cd152 100644 --- a/utils/autodict_ql/readme.md +++ b/utils/autodict_ql/readme.md @@ -6,12 +6,12 @@ Tokens are useful when you perform fuzzing on different parsers. The AFL++ `-x` switch enables the usage of dictionaries through your fuzzing campaign. If you are not familiar with Dictionaries in fuzzing, take a look [here](https://github.com/AFLplusplus/AFLplusplus/tree/stable/dictionaries) . - ## Why CodeQL ? -We basically developed this plugin on top of the CodeQL engine because it gives the user scripting features, it's easier and it's independent of the LLVM system. This means that a user can write his CodeQL scripts or modify the current scripts to improve or change the token generation algorithms based on different program analysis concepts. +We basically developed this plugin on top of the CodeQL engine because it gives the user scripting features, it's easier and it's independent of the LLVM system. This means that a user can write his CodeQL scripts or modify the current scripts to improve or change the token generation algorithms based on different program analysis concepts. ## CodeQL scripts + Currently, we pushed some scripts as defaults for Token generation. In addition, we provide every CodeQL script as an standalone script because it's easier to modify or test. Currently we provided the following CodeQL scripts : @@ -28,23 +28,26 @@ Currently we provided the following CodeQL scripts : You can write other CodeQL scripts to extract possible effective tokens if you think they can be useful. - ## Usage -Before you proceed to installation make sure that you have the following packages by installing them : +Before you proceed to installation make sure that you have the following packages by installing them: + ```shell sudo apt install build-essential libtool-bin python3-dev python3 automake git vim wget -y ``` + The usage of Autodict-QL is pretty easy. But let's describe it as: 1. First of all, you need to have CodeQL installed on the system. We make this possible with `build-codeql.sh` bash script. This script will install CodeQL completety and will set the required environment variables for your system. -Do the following : +Do the following: + ```shell # chmod +x codeql-build.sh # ./codeql-build.sh # source ~/.bashrc # codeql ``` + Then you should get: ```shell @@ -86,8 +89,8 @@ Commands: - This will create the final `tokens` dir for you and you are done, then pass the tokens path to AFL++'s `-x` flag. 5. Done! - ## More on dictionaries and tokens + Core developer of the AFL++ project Marc Heuse also developed a similar tool named `dict2file` which is a LLVM pass which can automatically extract useful tokens, in addition with LTO instrumentation mode, this dict2file is automatically generates token extraction. `Autodict-QL` plugin gives you scripting capability and you can do whatever you want to extract from the Codebase and it's up to you. In addition it's independent from LLVM system. On the other hand, you can also use Google dictionaries which have been made public in May 2020, but the problem of using Google dictionaries is that they are limited to specific file formats and specifications. For example, for testing binutils and ELF file format or AVI in FFMPEG, there are no pre-built dictionaries, so it is highly recommended to use `Autodict-QL` or `Dict2File` features to automatically generate dictionaries based on the target. @@ -97,4 +100,4 @@ In overall, fuzzing with dictionaries and well-generated tokens will give better There are 2 important points to remember : - If you combine `Autodict-QL` with AFL++ cmplog, you will get much better code coverage and hence better chances to discover new bugs. -- Do not forget to set `AFL_MAX_DET_EXTRAS` at least to the number of generated dictionaries. If you forget to set this environment variable, then AFL++ uses just 200 tokens and use the rest of them only probabilistically. So this will guarantee that your tokens will be used by AFL++. +- Do not forget to set `AFL_MAX_DET_EXTRAS` at least to the number of generated dictionaries. If you forget to set this environment variable, then AFL++ uses just 200 tokens and use the rest of them only probabilistically. So this will guarantee that your tokens will be used by AFL++. \ No newline at end of file diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md index 02dd3c74..08558017 100755 --- a/utils/qbdi_mode/README.md +++ b/utils/qbdi_mode/README.md @@ -9,7 +9,6 @@ Try FRIDA mode or fpicker [https://github.com/ttdennis/fpicker/](https://github. The code in ./qbdi_mode allows you to build a standalone feature that using the QBDI framework to fuzz android native library. - ## 2) Build First download the Android NDK @@ -53,6 +52,7 @@ https://qbdi.quarkslab.com/ ``` For Android x86_64 + ``` https://github.com/QBDI/QBDI/releases/download/v0.7.0/QBDI-0.7.0-android-X86_64.tar.gz ``` @@ -86,7 +86,6 @@ Then run the build.sh this could build the afl-fuzz and also the qbdi template for android x86_64 - ### Example The demo-so.c is an vulnerable library, it has a function for test @@ -160,6 +159,7 @@ QBDI_NOINLINE int fuzz_func() { ``` Just compile it + ``` ./build.sh x86_64 ``` @@ -176,6 +176,7 @@ adb push ../../android-standalone-toolchain-x86_64/sysroot/usr/lib/x86_64-linux- ``` In android adb shell, run the loader to test if it runs + ``` cd /data/local/tmp export LD_LIBRARY_PATH=/data/local/tmp @@ -202,5 +203,4 @@ Now run `afl-fuzz` to fuzz the demo library ./afl-fuzz -i in -o out -- ./loader /data/local/tmp/libdemo.so @@ ``` -![screen1](assets/screen1.png) - +![screen1](assets/screen1.png) \ No newline at end of file diff --git a/utils/qemu_persistent_hook/README.md b/utils/qemu_persistent_hook/README.md index 3f908c22..3bbaef6b 100644 --- a/utils/qemu_persistent_hook/README.md +++ b/utils/qemu_persistent_hook/README.md @@ -16,4 +16,4 @@ mkdir in echo 0000 > in/in ../../afl-fuzz -Q -i in -o out -- ./test -``` +``` \ No newline at end of file -- cgit 1.4.1 From 89df436290c67b1c03122bfe5c68cf4f92e581c0 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sun, 5 Dec 2021 19:03:48 +0100 Subject: Fix broken links - 1st run --- docs/INSTALL.md | 9 ++++---- docs/afl-fuzz_approach.md | 14 ++++++------ docs/env_variables.md | 11 +++++----- docs/fuzzing_binary-only_targets.md | 8 +++---- docs/fuzzing_in_depth.md | 9 ++++---- frida_mode/Scripting.md | 4 ++-- instrumentation/README.llvm.md | 43 ++++++++++++++++++++++++++++++++++++- utils/README.md | 2 +- 8 files changed, 72 insertions(+), 28 deletions(-) (limited to 'frida_mode') diff --git a/docs/INSTALL.md b/docs/INSTALL.md index 9d1309fe..906d3f8e 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -60,10 +60,9 @@ These build targets exist: * unit: perform unit tests (based on cmocka) * help: shows these build options -[Unless you are on Mac OS -X](https://developer.apple.com/library/archive/qa/qa1118/_index.html), you can -also build statically linked versions of the AFL++ binaries by passing the -`STATIC=1` argument to make: +[Unless you are on Mac OS X](https://developer.apple.com/library/archive/qa/qa1118/_index.html), +you can also build statically linked versions of the AFL++ binaries by passing +the `STATIC=1` argument to make: ```shell make STATIC=1 @@ -169,5 +168,5 @@ sysctl kern.sysv.shmall=98304 ``` See -[https://www.spy-hill.com/help/apple/SharedMemory.html](https://www.spy-hill.com/help/apple/SharedMemory.html) +[http://www.spy-hill.com/help/apple/SharedMemory.html](http://www.spy-hill.com/help/apple/SharedMemory.html) for documentation for these settings and how to make them permanent. \ No newline at end of file diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md index a72087c2..01888935 100644 --- a/docs/afl-fuzz_approach.md +++ b/docs/afl-fuzz_approach.md @@ -243,9 +243,10 @@ now. It tells you about the current stage, which can be any of: together two random inputs from the queue at some arbitrarily selected midpoint. - sync - a stage used only when `-M` or `-S` is set (see - [parallel_fuzzing.md](parallel_fuzzing.md)). No real fuzzing is involved, but - the tool scans the output from other fuzzers and imports test cases as - necessary. The first time this is done, it may take several minutes or so. + [fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores)). + No real fuzzing is involved, but the tool scans the output from other fuzzers + and imports test cases as necessary. The first time this is done, it may take + several minutes or so. The remaining fields should be fairly self-evident: there's the exec count progress indicator for the current stage, a global exec counter, and a benchmark @@ -254,8 +255,8 @@ to another, but the benchmark should be ideally over 500 execs/sec most of the time - and if it stays below 100, the job will probably take very long. The fuzzer will explicitly warn you about slow targets, too. If this happens, -see the [perf_tips.md](perf_tips.md) file included with the fuzzer for ideas on -how to speed things up. +see the [best_practices.md#improving-speed](best_practices.md#improving-speed) +for ideas on how to speed things up. ### Findings in depth @@ -396,7 +397,8 @@ comparing it to the number of logical cores on the system. If the value is shown in green, you are using fewer CPU cores than available on your system and can probably parallelize to improve performance; for tips on how -to do that, see [parallel_fuzzing.md](parallel_fuzzing.md). +to do that, see +[fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores). If the value is shown in red, your CPU is *possibly* oversubscribed, and running additional fuzzers may not give you any benefits. diff --git a/docs/env_variables.md b/docs/env_variables.md index 86ebf25c..0952b960 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -583,10 +583,11 @@ The QEMU wrapper used to instrument binary-only code supports several settings: The FRIDA wrapper used to instrument binary-only code supports many of the same options as `afl-qemu-trace`, but also has a number of additional advanced -options. These are listed in brief below (see [here](../frida_mode/README.md) -for more details). These settings are provided for compatibiltiy with QEMU mode, -the preferred way to configure FRIDA mode is through its -[scripting](../frida_mode/Scripting.md) support. +options. These are listed in brief below (see +[frida_mode/README.md](../frida_mode/README.md) for more details). These +settings are provided for compatibiltiy with QEMU mode, the preferred way to +configure FRIDA mode is through its [scripting](../frida_mode/Scripting.md) +support. * `AFL_FRIDA_DEBUG_MAPS` - See `AFL_QEMU_DEBUG_MAPS` * `AFL_FRIDA_DRIVER_NO_HOOK` - See `AFL_QEMU_DRIVER_NO_HOOK`. When using the @@ -627,7 +628,7 @@ the preferred way to configure FRIDA mode is through its coverage information for unstable edges (e.g., to be loaded within IDA lighthouse). * `AFL_FRIDA_JS_SCRIPT` - Set the script to be loaded by the FRIDA scripting - engine. See [here](Scripting.md) for details. + engine. See [frida_mode/Scripting.md](../frida_mode/Scripting.md) for details. * `AFL_FRIDA_OUTPUT_STDOUT` - Redirect the standard output of the target application to the named file (supersedes the setting of `AFL_DEBUG_CHILD`) * `AFL_FRIDA_OUTPUT_STDERR` - Redirect the standard error of the target diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index eaed3a91..fd18b5c1 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -107,10 +107,10 @@ For additional instructions and caveats, see [frida_mode/README.md](../frida_mode/README.md). If possible, you should use the persistent mode, see -[qemu_frida/README.md](../qemu_frida/README.md). The mode is approximately 2-5x -slower than compile-time instrumentation, and is less conducive to -parallelization. But for binary-only fuzzing, it gives a huge speed improvement -if it is possible to use. +[instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md). +The mode is approximately 2-5x slower than compile-time instrumentation, and is +less conducive to parallelization. But for binary-only fuzzing, it gives a huge +speed improvement if it is possible to use. If you want to fuzz a binary-only library, then you can fuzz it with frida-gum via frida_mode/. You will have to write a harness to call the target function in diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 4a1ddf45..29e8f817 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -153,12 +153,12 @@ only instrument parts of the target that you are interested in: There are many more options and modes available, however, these are most of the time less effective. See: -* [instrumentation/README.ctx.md](../instrumentation/README.ctx.md) -* [instrumentation/README.ngram.md](../instrumentation/README.ngram.md) +* [instrumentation/README.llvm.md#6) AFL++ Context Sensitive Branch Coverage](../instrumentation/README.llvm.md#6-afl-context-sensitive-branch-coverage) +* [instrumentation/README.llvm.md#7) AFL++ N-Gram Branch Coverage](../instrumentation/README.llvm.md#7-afl-n-gram-branch-coverage) AFL++ performs "never zero" counting in its bitmap. You can read more about this here: -* [instrumentation/README.neverzero.md](../instrumentation/README.neverzero.md) +* [instrumentation/README.llvm.md#8-neverzero-counters](../instrumentation/README.llvm.md#8-neverzero-counters) ### c) Selecting sanitizers @@ -474,7 +474,8 @@ is: ![resources/screenshot.png](resources/screenshot.png) -All labels are explained in [status_screen.md](status_screen.md). +All labels are explained in +[afl-fuzz_approach.md#understanding-the-status-screen](afl-fuzz_approach.md#understanding-the-status-screen). ### b) Keeping memory use and timeouts in check diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index 63ab1718..ad86fdd3 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -109,8 +109,8 @@ Afl.setPersistentAddress(address); A persistent hook can be implemented using a conventional shared object, sample source code for a hook suitable for the prototype of `LLVMFuzzerTestOneInput` -can be found in [hook/hook.c](hook/hook.c). This can be configured using code -similar to the following. +can be found in [hook/](hook/). This can be configured using code similar to the +following. ```js const path = Afl.module.path; diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index fa025643..ca9ce933 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -234,4 +234,45 @@ are 2-16. It is highly recommended to increase the MAP_SIZE_POW2 definition in config.h to at least 18 and maybe up to 20 for this as otherwise too many map collisions -occur. \ No newline at end of file +occur. + +## 8) NeverZero counters + +In larger, complex, or reiterative programs, the byte sized counters that +collect the edge coverage can easily fill up and wrap around. This is not that +much of an issue - unless, by chance, it wraps just to a value of zero when the +program execution ends. In this case, afl-fuzz is not able to see that the edge +has been accessed and will ignore it. + +NeverZero prevents this behavior. If a counter wraps, it jumps over the value 0 +directly to a 1. This improves path discovery (by a very small amount) at a very +low cost (one instruction per edge). + +(The alternative of saturated counters has been tested also and proved to be +inferior in terms of path discovery.) + +This is implemented in afl-gcc and afl-gcc-fast, however, for llvm_mode this is +optional if multithread safe counters are selected or the llvm version is below +9 - as there are severe performance costs in these cases. + +If you want to enable this for llvm versions below 9 or thread safe counters, +then set + +``` +export AFL_LLVM_NOT_ZERO=1 +``` + +In case you are on llvm 9 or greater and you do not want this behavior, then you +can set: + +``` +AFL_LLVM_SKIP_NEVERZERO=1 +``` + +If the target does not have extensive loops or functions that are called a lot +then this can give a small performance boost. + +Please note that the default counter implementations are not thread safe! + +Support for thread safe counters in mode LLVM CLASSIC can be activated with +setting `AFL_LLVM_THREADSAFE_INST=1`. \ No newline at end of file diff --git a/utils/README.md b/utils/README.md index 5f5745b9..debc86e8 100644 --- a/utils/README.md +++ b/utils/README.md @@ -48,7 +48,7 @@ Here's a quick overview of the stuff you can find in this directory: - defork - intercept fork() in targets - distributed_fuzzing - a sample script for synchronizing fuzzer instances - across multiple machines (see parallel_fuzzing.md). + across multiple machines. - libdislocator - like ASAN but lightweight. -- cgit 1.4.1