From 4b3ba3e51adda9b179bf349bb7cb1664ea8995d9 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sat, 7 Aug 2021 20:25:03 +0200 Subject: Edit FAQ Changes: - Edit FAQ. - Add history. - Add best practices. --- docs/best_practices.md | 103 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 docs/best_practices.md (limited to 'docs/best_practices.md') diff --git a/docs/best_practices.md b/docs/best_practices.md new file mode 100644 index 00000000..e08ae6ab --- /dev/null +++ b/docs/best_practices.md @@ -0,0 +1,103 @@ +# Best practices + +## Improvements + +### 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. Use the [AFL++ snapshot module](https://github.com/AFLplusplus/AFL-Snapshot-LKM) (x2 speed increase). + 4. If you do not use shmem persistent mode, use `AFL_TMPDIR` to put the input file directory on a tempfs location, see [docs/env_variables.md](docs/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! [README.md:3.b) Using multiple cores/threads](../README.md#b-using-multiple-coresthreads). + +### Improving stability + +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. + +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. + +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. + + 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 + + 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! + + 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+!): + [http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) + + Only exclude those functions from instrumentation that provide no value for coverage - that is if it does not process any fuzz data directly or indirectly (e.g. hash maps, thread management etc.). + If however a function directly or indirectly handles fuzz data, then you should not put the function in a deny instrumentation list and rather live with the instability it comes with. + + 4. Recompile the target + + Recompile, fuzz it, be happy :) + + This link explains this process for [Fuzzbench](https://github.com/google/fuzzbench/issues/677). + +## Targets + +### 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. + +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. + +### Fuzzing a network service + +The short answer is - you cannot, at least not "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). + +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 +to emulate the network. This is also much faster than the real network would be. +See [utils/socket_fuzzing/](../utils/socket_fuzzing/). + +There is an outdated AFL++ branch that implements networking if you are +desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - +however a better option is AFLnet ([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) +which allows you to define network state with different type of data packets. \ No newline at end of file -- cgit 1.4.1 From 105454e51c975065a9c0f22d0f5fd21176f959a3 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sun, 15 Aug 2021 21:31:44 +0200 Subject: Update best_practices.md --- docs/best_practices.md | 106 ++++++++++++++++++++++++++++--------------------- 1 file changed, 61 insertions(+), 45 deletions(-) (limited to 'docs/best_practices.md') diff --git a/docs/best_practices.md b/docs/best_practices.md index e08ae6ab..6e514003 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -1,18 +1,69 @@ # Best practices +## Contents + +### Targets + + * [Fuzzing a GUI program](#fuzzing-a-gui-program) + * [Fuzzing a network service](#fuzzing-a-network-service) + +### Improvements + + * [Improving speed](#improving-speed) + * [Improving stability?](#improving-stability) + +## Targets + +### Fuzzing a binary-only target + +For a comprehensive guide, see [binaryonly_fuzzing.md](binaryonly_fuzzing.md). + +### 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. + +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. + +### Fuzzing a network service + +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). + +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 +to emulate the network. This is also much faster than the real network would be. +See [utils/socket_fuzzing/](../utils/socket_fuzzing/). + +There is an outdated AFL++ branch that implements networking if you are +desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - +however a better option is AFLnet ([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) +which allows you to define network state with different type of data packets. + ## Improvements -### Improving speed +### 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. Use the [AFL++ snapshot module](https://github.com/AFLplusplus/AFL-Snapshot-LKM) (x2 speed increase). - 4. If you do not use shmem persistent mode, use `AFL_TMPDIR` to put the input file directory on a tempfs location, see [docs/env_variables.md](docs/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! [README.md:3.b) Using multiple cores/threads](../README.md#b-using-multiple-coresthreads). +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. Use the [AFL++ snapshot module](https://github.com/AFLplusplus/AFL-Snapshot-LKM) (x2 speed increase). +4. If you do not use shmem persistent mode, use `AFL_TMPDIR` to put the input file directory on a tempfs location, see [docs/env_variables.md](docs/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! [README.md:3.b) Using multiple cores/threads](../README.md#b-using-multiple-coresthreads). -### Improving stability +### Improving stability 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. @@ -65,39 +116,4 @@ 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). - -## Targets - -### 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. - -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. - -### Fuzzing a network service - -The short answer is - you cannot, at least not "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). - -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 -to emulate the network. This is also much faster than the real network would be. -See [utils/socket_fuzzing/](../utils/socket_fuzzing/). - -There is an outdated AFL++ branch that implements networking if you are -desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - -however a better option is AFLnet ([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) -which allows you to define network state with different type of data packets. \ No newline at end of file + This link explains this process for [Fuzzbench](https://github.com/google/fuzzbench/issues/677). \ No newline at end of file -- cgit 1.4.1 From b28b46daeb0933de3c887d5abb5f18abcb891ed5 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Mon, 16 Aug 2021 15:57:44 +0200 Subject: Update best_practices.md --- docs/best_practices.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs/best_practices.md') diff --git a/docs/best_practices.md b/docs/best_practices.md index 6e514003..23fa237d 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -4,13 +4,14 @@ ### Targets + * [Fuzzing a binary-only target](#fuzzing-a-binary-only-target) * [Fuzzing a GUI program](#fuzzing-a-gui-program) * [Fuzzing a network service](#fuzzing-a-network-service) ### Improvements * [Improving speed](#improving-speed) - * [Improving stability?](#improving-stability) + * [Improving stability](#improving-stability) ## Targets -- cgit 1.4.1 From f6fbbf8150c8a41b7cd40a2413b1c6f66b24c6c8 Mon Sep 17 00:00:00 2001 From: Kuang-che Wu Date: Sun, 10 Oct 2021 21:03:43 +0800 Subject: Fix document paths. --- README.md | 8 ++++---- docs/best_practices.md | 6 +++--- docs/branches.md | 2 +- docs/env_variables.md | 4 ++-- docs/fuzzing_expert.md | 4 ++-- docs/interpreting_output.md | 4 ++-- docs/known_limitations.md | 4 ++-- docs/parallel_fuzzing.md | 2 +- docs/rpc_statsd.md | 4 ++-- docs/triaging_crashes.md | 2 +- instrumentation/README.laf-intel.md | 5 ++--- instrumentation/README.llvm.md | 2 +- 12 files changed, 23 insertions(+), 24 deletions(-) (limited to 'docs/best_practices.md') diff --git a/README.md b/README.md index 76ef8448..1a22dd12 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ You are free to copy, modify, and distribute AFL++ with attribution under the te Here is some information to get you started: -* For releases, please see the [Releases](https://github.com/AFLplusplus/AFLplusplus/releases) tab and [branches](docs/branches.md). Also take a look at the list of [major behaviour changes in AFL++](docs/behaviour_changes.md). +* For releases, please see the [Releases](https://github.com/AFLplusplus/AFLplusplus/releases) tab and [branches](docs/branches.md). Also take a look at the list of [major changes in AFL++](docs/important_changes.md). * If you want to use AFL++ for your academic work, check the [papers page](https://aflplus.plus/papers/) on the website. * To cite our work, look at the [Cite](#cite) section. * For comparisons, use the fuzzbench `aflplusplus` setup, or use `afl-clang-fast` with `AFL_LLVM_CMPLOG=1`. You can find the `aflplusplus` default configuration on Google's [fuzzbench](https://github.com/google/fuzzbench/tree/master/fuzzers/aflplusplus). @@ -67,7 +67,7 @@ A common way to do this would be: 2. Get a small but valid input file that makes sense to the program. When fuzzing verbose syntax (SQL, HTTP, etc), create a dictionary as described -in [dictionaries/README.md](../dictionaries/README.md), too. +in [dictionaries/README.md](dictionaries/README.md), too. 3. If the program reads from stdin, run `afl-fuzz` like so: @@ -94,7 +94,7 @@ in [dictionaries/README.md](../dictionaries/README.md), too. 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 notes with other users or to get notified about major new features, send an email to . * Or join the [Awesome Fuzzing](https://discord.gg/gCraWct) Discord server. @@ -191,4 +191,4 @@ If you use AFL++ in scientific work, consider citing [our paper](https://www.use } ``` - \ No newline at end of file + diff --git a/docs/best_practices.md b/docs/best_practices.md index 23fa237d..0708d49d 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -59,10 +59,10 @@ which allows you to define network state with different type of data packets. 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. Use the [AFL++ snapshot module](https://github.com/AFLplusplus/AFL-Snapshot-LKM) (x2 speed increase). -4. If you do not use shmem persistent mode, use `AFL_TMPDIR` to put the input file directory on a tempfs location, see [docs/env_variables.md](docs/env_variables.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! [README.md:3.b) Using multiple cores/threads](../README.md#b-using-multiple-coresthreads). +7. Use your cores! [fuzzing_expert.md:b) Using multiple cores](fuzzing_expert.md#b-using-multiple-cores). ### Improving stability @@ -117,4 +117,4 @@ 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). \ No newline at end of file + This link explains this process for [Fuzzbench](https://github.com/google/fuzzbench/issues/677). diff --git a/docs/branches.md b/docs/branches.md index 1e4ebbb2..98fd6827 100644 --- a/docs/branches.md +++ b/docs/branches.md @@ -7,4 +7,4 @@ The following branches exist: * [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. -For releases, please see the [Releases](https://github.com/AFLplusplus/AFLplusplus/releases) tab. Also take a look at the list of [major behaviour changes in AFL++](behaviour_changes.md). \ No newline at end of file +For releases, please see the [Releases](https://github.com/AFLplusplus/AFLplusplus/releases) tab. Also take a look at the list of [major changes in AFL++](important_changes.md). diff --git a/docs/env_variables.md b/docs/env_variables.md index 0686f1a8..5f5c2510 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -2,7 +2,7 @@ This document discusses the environment variables used by American Fuzzy Lop++ to expose various exotic functions that may be (rarely) useful for power - users or for some types of custom fuzzing setups. See [README.md](README.md) for the general + users or for some types of custom fuzzing setups. See [../README.md](../README.md) for the general instruction manual. Note that most tools will warn on any unknown AFL environment variables. @@ -422,7 +422,7 @@ checks or alter some of the more exotic semantics of the tool: - Setting `AFL_FORCE_UI` will force painting the UI on the screen even if no valid terminal was detected (for virtual consoles) - - If you are using persistent mode (you should, see [instrumentation/README.persistent_mode.md](instrumentation/README.persistent_mode.md)) + - If you are using persistent mode (you should, see [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md)) some targets keep inherent state due which a detected crash testcase does not crash the target again when the testcase is given. To be able to still re-trigger these crashes you can use the `AFL_PERSISTENT_RECORD` variable diff --git a/docs/fuzzing_expert.md b/docs/fuzzing_expert.md index ca884159..ef3f8a4e 100644 --- a/docs/fuzzing_expert.md +++ b/docs/fuzzing_expert.md @@ -613,7 +613,7 @@ switch or honggfuzz. * If you do not use shmem persistent mode, use `AFL_TMPDIR` to point the input file on a tempfs location, see [env_variables.md](env_variables.md) * Linux: Improve 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 more insecure) - you can also just run `sudo afl-persistent-config` * Linux: Running on an `ext2` filesystem with `noatime` mount option will be a bit faster than on any other journaling filesystem - * Use your cores! [3.b) Using multiple cores/threads](#b-using-multiple-coresthreads) + * Use your cores! [b) Using multiple cores](#b-using-multiple-cores) * Run `sudo afl-system-config` before starting the first afl-fuzz instance after a reboot ### The End @@ -625,4 +625,4 @@ This is basically all you need to know to professionally run fuzzing campaigns. If you want to know more, the tons of texts in [docs/](./) will have you covered. Note that there are also a lot of tools out there that help fuzzing with AFL++ -(some might be deprecated or unsupported), see [links_tools.md](links_tools.md). +(some might be deprecated or unsupported), see [tools.md](tools.md). diff --git a/docs/interpreting_output.md b/docs/interpreting_output.md index 54ad76df..327a0ac0 100644 --- a/docs/interpreting_output.md +++ b/docs/interpreting_output.md @@ -1,6 +1,6 @@ # Interpreting output -See the [docs/status_screen.md](docs/status_screen.md) file for information on +See the [status_screen.md](status_screen.md) file for information on how to interpret the displayed stats and monitor the health of the process. Be sure to consult this file especially if any UI elements are highlighted in red. @@ -68,4 +68,4 @@ cd utils/plot_ui make cd ../../ sudo make install -``` \ No newline at end of file +``` diff --git a/docs/known_limitations.md b/docs/known_limitations.md index deb539e2..2d8f84a5 100644 --- a/docs/known_limitations.md +++ b/docs/known_limitations.md @@ -15,7 +15,7 @@ Here are some of the most important caveats for AFL: To work around this, you can comment out the relevant checks (see utils/libpng_no_checksum/ for inspiration); if this is not possible, you can also write a postprocessor, one of the hooks of custom mutators. - See [docs/custom_mutators.md](docs/custom_mutators.md) on how to use + See [custom_mutators.md](custom_mutators.md) on how to use `AFL_CUSTOM_MUTATOR_LIBRARY` - There are some unfortunate trade-offs with ASAN and 64-bit binaries. This @@ -33,4 +33,4 @@ Here are some of the most important caveats for AFL: - Occasionally, sentient machines rise against their creators. If this happens to you, please consult [http://lcamtuf.coredump.cx/prep/](http://lcamtuf.coredump.cx/prep/). -Beyond this, see [INSTALL.md](INSTALL.md) for platform-specific tips. \ No newline at end of file +Beyond this, see [INSTALL.md](INSTALL.md) for platform-specific tips. diff --git a/docs/parallel_fuzzing.md b/docs/parallel_fuzzing.md index 90e12e89..e37276a5 100644 --- a/docs/parallel_fuzzing.md +++ b/docs/parallel_fuzzing.md @@ -4,7 +4,7 @@ This document talks about synchronizing afl-fuzz jobs on a single machine or across a fleet of systems. See README.md for the general instruction manual. Note that this document is rather outdated. please refer to the main document -section on multiple core usage [../README.md#Using multiple cores](../README.md#b-using-multiple-coresthreads) +section on multiple core usage [fuzzing_expert.md#Using multiple cores](fuzzing_expert.md#b-using-multiple-cores) for up to date strategies! ## 1) Introduction diff --git a/docs/rpc_statsd.md b/docs/rpc_statsd.md index 288d56cb..9b3d8d40 100644 --- a/docs/rpc_statsd.md +++ b/docs/rpc_statsd.md @@ -50,7 +50,7 @@ Depending on your StatsD server, you will be able to monitor, trigger alerts, or - `librato` - `signalfx` - For more information on environment variables, see [docs/env_variables.md](docs/env_variables.md). + 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. @@ -152,4 +152,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/docs/triaging_crashes.md b/docs/triaging_crashes.md index 1857c4b1..b0015c90 100644 --- a/docs/triaging_crashes.md +++ b/docs/triaging_crashes.md @@ -43,4 +43,4 @@ file, attempts to sequentially flip bytes, and observes the behavior of the tested program. It 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. More info about its operation can be found -near the end of [docs/technical_details.md](docs/technical_details.md). \ No newline at end of file +near the end of [technical_details.md](technical_details.md). diff --git a/instrumentation/README.laf-intel.md b/instrumentation/README.laf-intel.md index 229807e8..789055ed 100644 --- a/instrumentation/README.laf-intel.md +++ b/instrumentation/README.laf-intel.md @@ -3,9 +3,8 @@ ## Introduction This originally is the work of an individual nicknamed laf-intel. -His blog [Circumventing Fuzzing Roadblocks with Compiler Transformations] -(https://lafintel.wordpress.com/) and gitlab repo [laf-llvm-pass] -(https://gitlab.com/laf-intel/laf-llvm-pass/) +His blog [Circumventing Fuzzing Roadblocks with Compiler Transformations](https://lafintel.wordpress.com/) +and gitlab repo [laf-llvm-pass](https://gitlab.com/laf-intel/laf-llvm-pass/) describe some code transformations that help AFL++ to enter conditional blocks, where conditions consist of comparisons of large values. diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 6e210a7c..5b1e60cc 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -2,7 +2,7 @@ (See [../README.md](../README.md) for the general instruction manual.) - (See [README.gcc_plugin.md](../README.gcc_plugin.md) for the GCC-based instrumentation.) + (See [README.gcc_plugin.md](README.gcc_plugin.md) for the GCC-based instrumentation.) ## 1) Introduction -- cgit 1.4.1 From 9325a4fcbb8eb4ed1d71f93de5301bf1a9a68253 Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Sat, 6 Nov 2021 10:28:22 +0100 Subject: http->https --- GNUmakefile | 2 +- GNUmakefile.gcc_plugin | 2 +- GNUmakefile.llvm | 2 +- TODO.md | 1 - afl-cmin.bash | 2 +- afl-plot | 2 +- afl-whatsup | 2 +- docs/Changelog.md | 2 +- docs/INSTALL.md | 2 +- docs/best_practices.md | 2 +- docs/interpreting_output.md | 2 +- docs/known_limitations.md | 2 +- docs/sister_projects.md | 12 ++++++------ docs/technical_details.md | 12 ++++++------ frida_mode/Scripting.md | 2 +- include/afl-as.h | 4 ++-- include/afl-fuzz.h | 2 +- include/afl-prealloc.h | 2 +- include/alloc-inl.h | 2 +- include/cmplog.h | 2 +- include/common.h | 2 +- include/config.h | 2 +- include/debug.h | 2 +- include/forkserver.h | 2 +- include/hash.h | 2 +- include/list.h | 2 +- include/sharedmem.h | 2 +- include/snapshot-inl.h | 2 +- include/types.h | 2 +- instrumentation/README.llvm.md | 2 +- instrumentation/afl-compiler-rt.o.c | 2 +- instrumentation/afl-gcc-pass.so.cc | 2 +- instrumentation/afl-llvm-dict2file.so.cc | 2 +- instrumentation/afl-llvm-lto-instrumentation.so.cc | 2 +- instrumentation/afl-llvm-lto-instrumentlist.so.cc | 2 +- instrumentation/afl-llvm-pass.so.cc | 2 +- instrumentation/afl-llvm-rt-lto.o.c | 2 +- instrumentation/cmplog-instructions-pass.cc | 2 +- instrumentation/cmplog-routines-pass.cc | 2 +- instrumentation/cmplog-switches-pass.cc | 2 +- instrumentation/compare-transform-pass.so.cc | 2 +- instrumentation/split-compares-pass.so.cc | 2 +- instrumentation/split-switches-pass.so.cc | 2 +- qemu_mode/build_qemu_support.sh | 2 +- src/afl-analyze.c | 2 +- src/afl-as.c | 4 ++-- src/afl-cc.c | 2 +- src/afl-common.c | 2 +- src/afl-forkserver.c | 8 ++++---- src/afl-fuzz-bitmap.c | 2 +- src/afl-fuzz-cmplog.c | 2 +- src/afl-fuzz-extras.c | 2 +- src/afl-fuzz-init.c | 4 ++-- src/afl-fuzz-mutators.c | 2 +- src/afl-fuzz-one.c | 2 +- src/afl-fuzz-python.c | 2 +- src/afl-fuzz-queue.c | 2 +- src/afl-fuzz-redqueen.c | 2 +- src/afl-fuzz-run.c | 2 +- src/afl-fuzz-state.c | 2 +- src/afl-fuzz-stats.c | 2 +- src/afl-fuzz.c | 2 +- src/afl-gotcpu.c | 2 +- src/afl-ld-lto.c | 2 +- src/afl-performance.c | 2 +- src/afl-sharedmem.c | 2 +- src/afl-showmap.c | 2 +- src/afl-tmin.c | 2 +- test-instr.c | 2 +- unicorn_mode/build_unicorn_support.sh | 2 +- 70 files changed, 85 insertions(+), 86 deletions(-) (limited to 'docs/best_practices.md') diff --git a/GNUmakefile b/GNUmakefile index 0a6f3950..ad2642f3 100644 --- a/GNUmakefile +++ b/GNUmakefile @@ -10,7 +10,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # For Heiko: diff --git a/GNUmakefile.gcc_plugin b/GNUmakefile.gcc_plugin index bce97b2f..ed2725d7 100644 --- a/GNUmakefile.gcc_plugin +++ b/GNUmakefile.gcc_plugin @@ -17,7 +17,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # #TEST_MMAP=1 PREFIX ?= /usr/local diff --git a/GNUmakefile.llvm b/GNUmakefile.llvm index b802ef16..64e5beb2 100644 --- a/GNUmakefile.llvm +++ b/GNUmakefile.llvm @@ -12,7 +12,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # For Heiko: diff --git a/TODO.md b/TODO.md index 30676312..1d4270b4 100644 --- a/TODO.md +++ b/TODO.md @@ -2,7 +2,6 @@ ## TODO - - AFL_USE_TSAN to docs/env_variables.md after work over - screen update during input2stage - better autodetection of shifting runtime timeout values - Update afl->pending_not_fuzzed for MOpt diff --git a/afl-cmin.bash b/afl-cmin.bash index c77dfbc1..e25ddc74 100755 --- a/afl-cmin.bash +++ b/afl-cmin.bash @@ -11,7 +11,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This tool tries to find the smallest subset of files in the input directory # that still trigger the full range of instrumentation data points seen in diff --git a/afl-plot b/afl-plot index 87b9caae..1ea1fc55 100755 --- a/afl-plot +++ b/afl-plot @@ -12,7 +12,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # get_abs_path() { diff --git a/afl-whatsup b/afl-whatsup index 9c2564c6..10a52f83 100755 --- a/afl-whatsup +++ b/afl-whatsup @@ -12,7 +12,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This tool summarizes the status of any locally-running synchronized # instances of afl-fuzz. diff --git a/docs/Changelog.md b/docs/Changelog.md index cfeb8cc1..7c77a6bf 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -2760,7 +2760,7 @@ sending a mail to . - Updated the documentation and added notes_for_asan.txt. Based on feedback from Hanno Boeck, Ben Laurie, and others. - - Moved the project to http://lcamtuf.coredump.cx/afl/. + - Moved the project to https://lcamtuf.coredump.cx/afl/. ### Version 0.46b: diff --git a/docs/INSTALL.md b/docs/INSTALL.md index 960de1af..cfa20dea 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -150,4 +150,4 @@ sysctl kern.sysv.shmseg=48 sysctl kern.sysv.shmall=98304 ``` -See [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 +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/best_practices.md b/docs/best_practices.md index 0708d49d..5d07dd14 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -108,7 +108,7 @@ Four steps are required to do this and it also requires quite some knowledge of 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+!): - [http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) + [https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) Only exclude those functions from instrumentation that provide no value for coverage - that is if it does not process any fuzz data directly or indirectly (e.g. hash maps, thread management etc.). If however a function directly or indirectly handles fuzz data, then you should not put the function in a deny instrumentation list and rather live with the instability it comes with. diff --git a/docs/interpreting_output.md b/docs/interpreting_output.md index 327a0ac0..4bd705f2 100644 --- a/docs/interpreting_output.md +++ b/docs/interpreting_output.md @@ -56,7 +56,7 @@ Any existing output directory can be also used to resume aborted jobs; try: If you have gnuplot installed, you can also generate some pretty graphs for any active fuzzing task using afl-plot. For an example of how this looks like, -see [http://lcamtuf.coredump.cx/afl/plot/](http://lcamtuf.coredump.cx/afl/plot/). +see [https://lcamtuf.coredump.cx/afl/plot/](https://lcamtuf.coredump.cx/afl/plot/). You can also manually build and install afl-plot-ui, which is a helper utility for showing the graphs generated by afl-plot in a graphical window using GTK. diff --git a/docs/known_limitations.md b/docs/known_limitations.md index 2d8f84a5..a68c0a85 100644 --- a/docs/known_limitations.md +++ b/docs/known_limitations.md @@ -31,6 +31,6 @@ Here are some of the most important caveats for AFL: [https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop](https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop) - Occasionally, sentient machines rise against their creators. If this - happens to you, please consult [http://lcamtuf.coredump.cx/prep/](http://lcamtuf.coredump.cx/prep/). + happens to you, please consult [https://lcamtuf.coredump.cx/prep/](https://lcamtuf.coredump.cx/prep/). Beyond this, see [INSTALL.md](INSTALL.md) for platform-specific tips. diff --git a/docs/sister_projects.md b/docs/sister_projects.md index 5cb3a102..613bc778 100644 --- a/docs/sister_projects.md +++ b/docs/sister_projects.md @@ -15,7 +15,7 @@ instruction manual. Allows fuzz-testing of Python programs. Uses custom instrumentation and its own forkserver. -http://jwilk.net/software/python-afl +https://jwilk.net/software/python-afl ### Go-fuzz (Dmitry Vyukov) @@ -34,7 +34,7 @@ https://github.com/kmcallister/afl.rs Adds AFL-compatible instrumentation to OCaml programs. https://github.com/ocamllabs/opam-repo-dev/pull/23 -http://canopy.mirage.io/Posts/Fuzzing +https://canopy.mirage.io/Posts/Fuzzing ### AFL for GCJ Java and other GCC frontends (-) @@ -54,7 +54,7 @@ some programs to be fuzzed without the fork / execve overhead. (Similar functionality is now available as the "persistent" feature described in [the llvm_mode readme](../instrumentation/README.llvm.md)) -http://llvm.org/docs/LibFuzzer.html +https://llvm.org/docs/LibFuzzer.html ## TriforceAFL (Tim Newsham and Jesse Hertz) @@ -189,7 +189,7 @@ https://github.com/bshastry/afl-sancov Makes it easy to estimate memory usage limits when fuzzing with ASAN or MSAN. -http://jwilk.net/software/recidivm +https://jwilk.net/software/recidivm ### aflize (Jacek Wielemborek) @@ -274,7 +274,7 @@ https://goo.gl/j9EgFf A simple SQL shell designed specifically for fuzzing the underlying library. -http://www.sqlite.org/src/artifact/9e7e273da2030371 +https://www.sqlite.org/src/artifact/9e7e273da2030371 ### Support for Python mutation modules (Christian Holler) @@ -292,7 +292,7 @@ A similar guided approach as applied to fuzzing syscalls: https://github.com/google/syzkaller/wiki/Found-Bugs https://github.com/dvyukov/linux/commit/33787098ffaaa83b8a7ccf519913ac5fd6125931 -http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf +https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf ### Kernel Snapshot Fuzzing using Unicornafl (Security in Telecommunications) diff --git a/docs/technical_details.md b/docs/technical_details.md index b0ca493e..b9d271d9 100644 --- a/docs/technical_details.md +++ b/docs/technical_details.md @@ -161,8 +161,8 @@ features of the underlying data format, as shown in this image: Several practical examples of the results of this algorithm are discussed here: - http://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html - http://lcamtuf.blogspot.com/2014/11/afl-fuzz-nobody-expects-cdata-sections.html + https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html + https://lcamtuf.blogspot.com/2014/11/afl-fuzz-nobody-expects-cdata-sections.html The synthetic corpus produced by this process is essentially a compact collection of "hmm, this does something new!" input files, and can be used to @@ -323,7 +323,7 @@ value of various fuzzing strategies and optimize their parameters so that they work equally well across a wide range of file types. The strategies used by afl-fuzz are generally format-agnostic and are discussed in more detail here: - http://lcamtuf.blogspot.com/2014/08/binary-fuzzing-strategies-what-works.html + https://lcamtuf.blogspot.com/2014/08/binary-fuzzing-strategies-what-works.html It is somewhat notable that especially early on, most of the work done by `afl-fuzz` is actually highly deterministic, and progresses to random stacked @@ -376,7 +376,7 @@ valid grammar for the tested parser. A discussion of how these features are implemented within afl-fuzz can be found here: - http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html + https://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html In essence, when basic, typically easily-obtained syntax tokens are combined together in a purely random manner, the instrumentation and the evolutionary @@ -429,7 +429,7 @@ thrown away. A detailed discussion of the value of this approach can be found here: - http://lcamtuf.blogspot.com/2014/11/afl-fuzz-crash-exploration-mode.html + https://lcamtuf.blogspot.com/2014/11/afl-fuzz-crash-exploration-mode.html The method uses instrumentation feedback to explore the state of the crashing program to get past the ambiguous faulting condition and then isolate the @@ -447,7 +447,7 @@ goes through `execve()`, linking, and libc initialization only once, and is then cloned from a stopped process image by leveraging copy-on-write. The implementation is described in more detail here: - http://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html + https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html The fork server is an integral aspect of the injected instrumentation and simply stops at the first instrumented function to await commands from diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index f6017fad..691b03d1 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -302,7 +302,7 @@ Consider the [following](test/js/test2.c) test code... Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ #include diff --git a/include/afl-as.h b/include/afl-as.h index 3c12c68f..2a2e8ad7 100644 --- a/include/afl-as.h +++ b/include/afl-as.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This file houses the assembly-level instrumentation injected into fuzzed programs. The instrumentation stores XORed pairs of data: identifiers of the @@ -396,7 +396,7 @@ static const u8 *main_payload_32 = "\n"; /* The OpenBSD hack is due to lahf and sahf not being recognized by some - versions of binutils: http://marc.info/?l=openbsd-cvs&m=141636589924400 + versions of binutils: https://marc.info/?l=openbsd-cvs&m=141636589924400 The Apple code is a bit different when calling libc functions because they are doing relocations differently from everybody else. We also need diff --git a/include/afl-fuzz.h b/include/afl-fuzz.h index eaf55fb8..e73ea1a4 100644 --- a/include/afl-fuzz.h +++ b/include/afl-fuzz.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to diff --git a/include/afl-prealloc.h b/include/afl-prealloc.h index fa6c9b70..87bbb1cc 100644 --- a/include/afl-prealloc.h +++ b/include/afl-prealloc.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/alloc-inl.h b/include/alloc-inl.h index c914da5f..0c540330 100644 --- a/include/alloc-inl.h +++ b/include/alloc-inl.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This allocator is not designed to resist malicious attackers (the canaries are small and predictable), but provides a robust and portable way to detect diff --git a/include/cmplog.h b/include/cmplog.h index 878ed60c..1c15d2b8 100644 --- a/include/cmplog.h +++ b/include/cmplog.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/include/common.h b/include/common.h index 2ca44301..e3997aa4 100644 --- a/include/common.h +++ b/include/common.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Gather some functions common to multiple executables diff --git a/include/config.h b/include/config.h index 4630da0c..3aee9b00 100644 --- a/include/config.h +++ b/include/config.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/debug.h b/include/debug.h index f8df5711..feb7f52d 100644 --- a/include/debug.h +++ b/include/debug.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/forkserver.h b/include/forkserver.h index c6f7de00..7af01cb2 100644 --- a/include/forkserver.h +++ b/include/forkserver.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code that implements a forkserver. This is used by the fuzzer as well the other components like afl-tmin. diff --git a/include/hash.h b/include/hash.h index 9319ab95..9bb34ff8 100644 --- a/include/hash.h +++ b/include/hash.h @@ -21,7 +21,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/list.h b/include/list.h index 7ec81cbe..d49e56da 100644 --- a/include/list.h +++ b/include/list.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This allocator is not designed to resist malicious attackers (the canaries are small and predictable), but provides a robust and portable way to detect diff --git a/include/sharedmem.h b/include/sharedmem.h index fdc947f9..93080d0f 100644 --- a/include/sharedmem.h +++ b/include/sharedmem.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/include/snapshot-inl.h b/include/snapshot-inl.h index a18187ef..7234bbaa 100644 --- a/include/snapshot-inl.h +++ b/include/snapshot-inl.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/types.h b/include/types.h index 7b94fb83..e945f0f5 100644 --- a/include/types.h +++ b/include/types.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 5b1e60cc..dbb604f2 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -75,7 +75,7 @@ load modules (you'll see "Service unavailable" when loading afl-llvm-pass.so). To solve all your problems, you can grab pre-built binaries for your OS from: - http://llvm.org/releases/download.html + https://llvm.org/releases/download.html ...and then put the bin/ directory from the tarball at the beginning of your $PATH when compiling the feature and building packages later on. You don't need diff --git a/instrumentation/afl-compiler-rt.o.c b/instrumentation/afl-compiler-rt.o.c index 9acab4e7..b2802a29 100644 --- a/instrumentation/afl-compiler-rt.o.c +++ b/instrumentation/afl-compiler-rt.o.c @@ -9,7 +9,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/afl-gcc-pass.so.cc b/instrumentation/afl-gcc-pass.so.cc index 3b7eb878..df2b6f2a 100644 --- a/instrumentation/afl-gcc-pass.so.cc +++ b/instrumentation/afl-gcc-pass.so.cc @@ -30,7 +30,7 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License - along with this program. If not, see . + along with this program. If not, see . */ diff --git a/instrumentation/afl-llvm-dict2file.so.cc b/instrumentation/afl-llvm-dict2file.so.cc index 0a3e74b9..7c04c0c5 100644 --- a/instrumentation/afl-llvm-dict2file.so.cc +++ b/instrumentation/afl-llvm-dict2file.so.cc @@ -10,7 +10,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-lto. diff --git a/instrumentation/afl-llvm-lto-instrumentation.so.cc b/instrumentation/afl-llvm-lto-instrumentation.so.cc index c2f61d34..cd43b437 100644 --- a/instrumentation/afl-llvm-lto-instrumentation.so.cc +++ b/instrumentation/afl-llvm-lto-instrumentation.so.cc @@ -10,7 +10,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-lto. diff --git a/instrumentation/afl-llvm-lto-instrumentlist.so.cc b/instrumentation/afl-llvm-lto-instrumentlist.so.cc index ee2e5dd3..cf26f912 100644 --- a/instrumentation/afl-llvm-lto-instrumentlist.so.cc +++ b/instrumentation/afl-llvm-lto-instrumentlist.so.cc @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-fast. It tells the compiler to add code roughly equivalent to the bits discussed diff --git a/instrumentation/afl-llvm-pass.so.cc b/instrumentation/afl-llvm-pass.so.cc index 9b7e625e..21ce0cf9 100644 --- a/instrumentation/afl-llvm-pass.so.cc +++ b/instrumentation/afl-llvm-pass.so.cc @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-fast. It tells the compiler to add code roughly equivalent to the bits discussed diff --git a/instrumentation/afl-llvm-rt-lto.o.c b/instrumentation/afl-llvm-rt-lto.o.c index e53785ff..eb346157 100644 --- a/instrumentation/afl-llvm-rt-lto.o.c +++ b/instrumentation/afl-llvm-rt-lto.o.c @@ -6,7 +6,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/cmplog-instructions-pass.cc b/instrumentation/cmplog-instructions-pass.cc index 01a8a637..80af05f0 100644 --- a/instrumentation/cmplog-instructions-pass.cc +++ b/instrumentation/cmplog-instructions-pass.cc @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/cmplog-routines-pass.cc b/instrumentation/cmplog-routines-pass.cc index 1e2610f2..01b7a373 100644 --- a/instrumentation/cmplog-routines-pass.cc +++ b/instrumentation/cmplog-routines-pass.cc @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/cmplog-switches-pass.cc b/instrumentation/cmplog-switches-pass.cc index c42d44fe..aa719013 100644 --- a/instrumentation/cmplog-switches-pass.cc +++ b/instrumentation/cmplog-switches-pass.cc @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/compare-transform-pass.so.cc b/instrumentation/compare-transform-pass.so.cc index 288e8282..a1239040 100644 --- a/instrumentation/compare-transform-pass.so.cc +++ b/instrumentation/compare-transform-pass.so.cc @@ -5,7 +5,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, diff --git a/instrumentation/split-compares-pass.so.cc b/instrumentation/split-compares-pass.so.cc index e63be98c..7c652ca2 100644 --- a/instrumentation/split-compares-pass.so.cc +++ b/instrumentation/split-compares-pass.so.cc @@ -6,7 +6,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, diff --git a/instrumentation/split-switches-pass.so.cc b/instrumentation/split-switches-pass.so.cc index 82f198aa..1e32a31d 100644 --- a/instrumentation/split-switches-pass.so.cc +++ b/instrumentation/split-switches-pass.so.cc @@ -5,7 +5,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, diff --git a/qemu_mode/build_qemu_support.sh b/qemu_mode/build_qemu_support.sh index 84f144be..71453a71 100755 --- a/qemu_mode/build_qemu_support.sh +++ b/qemu_mode/build_qemu_support.sh @@ -19,7 +19,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This script downloads, patches, and builds a version of QEMU with # minor tweaks to allow non-instrumented binaries to be run under diff --git a/src/afl-analyze.c b/src/afl-analyze.c index 09b01541..60cb1434 100644 --- a/src/afl-analyze.c +++ b/src/afl-analyze.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 A nifty utility that grabs an input file and takes a stab at explaining its structure by observing how changes to it affect the execution path. diff --git a/src/afl-as.c b/src/afl-as.c index 9af272f2..b644b82a 100644 --- a/src/afl-as.c +++ b/src/afl-as.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 The sole purpose of this wrapper is to preprocess assembly files generated by GCC / clang and inject the instrumentation bits included from afl-as.h. It @@ -101,7 +101,7 @@ static void edit_params(int argc, char **argv) { /* On MacOS X, the Xcode cctool 'as' driver is a bit stale and does not work with the code generated by newer versions of clang that are hand-built - by the user. See the thread here: http://goo.gl/HBWDtn. + by the user. See the thread here: https://goo.gl/HBWDtn. To work around this, when using clang and running without AFL_AS specified, we will actually call 'clang -c' instead of 'as -q' to diff --git a/src/afl-cc.c b/src/afl-cc.c index 5f77b097..8ff241ba 100644 --- a/src/afl-cc.c +++ b/src/afl-cc.c @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/src/afl-common.c b/src/afl-common.c index 26a0d54b..ec3b2f3f 100644 --- a/src/afl-common.c +++ b/src/afl-common.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Gather some functions common to multiple executables diff --git a/src/afl-forkserver.c b/src/afl-forkserver.c index 80b295e0..b1769bfb 100644 --- a/src/afl-forkserver.c +++ b/src/afl-forkserver.c @@ -19,7 +19,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code that implements a forkserver. This is used by the fuzzer as well the other components like afl-tmin. @@ -351,7 +351,7 @@ static void report_error_and_exit(int error) { /* Spins up fork server. The idea is explained here: - http://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html + https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html In essence, the instrumentation allows us to skip execve(), and just keep cloning a stopped child. So, we just execute once, and then send commands @@ -917,7 +917,7 @@ void afl_fsrv_start(afl_forkserver_t *fsrv, char **argv, MSG_ULIMIT_USAGE " /path/to/fuzzed_app )\n\n" - " Tip: you can use http://jwilk.net/software/recidivm to " + " Tip: you can use https://jwilk.net/software/recidivm to " "quickly\n" " estimate the required amount of virtual memory for the " "binary.\n\n" @@ -1017,7 +1017,7 @@ void afl_fsrv_start(afl_forkserver_t *fsrv, char **argv, MSG_ULIMIT_USAGE " /path/to/fuzzed_app )\n\n" - " Tip: you can use http://jwilk.net/software/recidivm to quickly\n" + " Tip: you can use https://jwilk.net/software/recidivm to quickly\n" " estimate the required amount of virtual memory for the " "binary.\n\n" diff --git a/src/afl-fuzz-bitmap.c b/src/afl-fuzz-bitmap.c index 316067e4..f7b59f25 100644 --- a/src/afl-fuzz-bitmap.c +++ b/src/afl-fuzz-bitmap.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to diff --git a/src/afl-fuzz-cmplog.c b/src/afl-fuzz-cmplog.c index c2e9c80f..6fc926f0 100644 --- a/src/afl-fuzz-cmplog.c +++ b/src/afl-fuzz-cmplog.c @@ -17,7 +17,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/src/afl-fuzz-extras.c b/src/afl-fuzz-extras.c index 584241d4..0f0fe331 100644 --- a/src/afl-fuzz-extras.c +++ b/src/afl-fuzz-extras.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to diff --git a/src/afl-fuzz-init.c b/src/afl-fuzz-init.c index 1170715f..9262d718 100644 --- a/src/afl-fuzz-init.c +++ b/src/afl-fuzz-init.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to @@ -974,7 +974,7 @@ void perform_dry_run(afl_state_t *afl) { MSG_ULIMIT_USAGE " /path/to/binary [...] . + See . This is xoshiro256++ 1.0, one of our all-purpose, rock-solid generators. It has excellent (sub-ns) speed, a state (256 bits) that is large diff --git a/src/afl-sharedmem.c b/src/afl-sharedmem.c index 22fe5a62..7fb8f821 100644 --- a/src/afl-sharedmem.c +++ b/src/afl-sharedmem.c @@ -17,7 +17,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/src/afl-showmap.c b/src/afl-showmap.c index 3826e385..23ec0df0 100644 --- a/src/afl-showmap.c +++ b/src/afl-showmap.c @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 A very simple tool that runs the targeted binary and displays the contents of the trace bitmap in a human-readable form. Useful in diff --git a/src/afl-tmin.c b/src/afl-tmin.c index ce2a0b8f..8ce4bdd5 100644 --- a/src/afl-tmin.c +++ b/src/afl-tmin.c @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 A simple test case minimizer that takes an input file and tries to remove as much data as possible while keeping the binary in a crashing state diff --git a/test-instr.c b/test-instr.c index 13d4eb93..eaae50ef 100644 --- a/test-instr.c +++ b/test-instr.c @@ -7,7 +7,7 @@ Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ #include diff --git a/unicorn_mode/build_unicorn_support.sh b/unicorn_mode/build_unicorn_support.sh index 6c376f8d..f9c0be7f 100755 --- a/unicorn_mode/build_unicorn_support.sh +++ b/unicorn_mode/build_unicorn_support.sh @@ -20,7 +20,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This script downloads, patches, and builds a version of Unicorn with # minor tweaks to allow Unicorn-emulated binaries to be run under -- cgit 1.4.1 From 5ec859cece70ab1b5cd9e0356c4cc3e260d2cbe0 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sat, 20 Nov 2021 15:48:49 +0100 Subject: Clean up docs folder --- README.md | 98 ++++---- docs/best_practices.md | 4 +- docs/branches.md | 11 - docs/fuzzing_expert.md | 630 ---------------------------------------------- docs/fuzzing_in_depth.md | 630 ++++++++++++++++++++++++++++++++++++++++++++++ docs/known_limitations.md | 36 --- docs/limitations.md | 36 +++ docs/sister_projects.md | 319 ----------------------- docs/third_party_tools.md | 33 +++ docs/tools.md | 33 --- 10 files changed, 756 insertions(+), 1074 deletions(-) delete mode 100644 docs/branches.md delete mode 100644 docs/fuzzing_expert.md create mode 100644 docs/fuzzing_in_depth.md delete mode 100644 docs/known_limitations.md create mode 100644 docs/limitations.md delete mode 100644 docs/sister_projects.md create mode 100644 docs/third_party_tools.md delete mode 100644 docs/tools.md (limited to 'docs/best_practices.md') diff --git a/README.md b/README.md index 575a6a1a..b2714787 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ Release version: [3.14c](https://github.com/AFLplusplus/AFLplusplus/releases) GitHub version: 3.15a -Repository: +Repository: [https://github.com/AFLplusplus/AFLplusplus](https://github.com/AFLplusplus/AFLplusplus) AFL++ is maintained by: @@ -18,33 +18,33 @@ AFL++ is maintained by: Originally developed by Michał "lcamtuf" Zalewski. -AFL++ is a superior fork to Google's AFL - more speed, more and better +AFL++ is a superior fork to Google's AFL - more speed, more and better mutations, more and better instrumentation, custom module support, etc. -You are free to copy, modify, and distribute AFL++ with attribution under the +You are free to copy, modify, and distribute AFL++ with attribution under the terms of the Apache-2.0 License. See the [LICENSE](LICENSE) for details. ## Getting started Here is some information to get you started: -* For releases, please see the - [Releases](https://github.com/AFLplusplus/AFLplusplus/releases) tab and - [branches](docs/branches.md). Also take a look at the list of +* For releases, please 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). -* If you want to use AFL++ for your academic work, check the +* If you want to use AFL++ for your academic work, check the [papers page](https://aflplus.plus/papers/) on the website. * To cite our work, look at the [Cite](#cite) section. -* For comparisons, use the fuzzbench `aflplusplus` setup, or use - `afl-clang-fast` with `AFL_LLVM_CMPLOG=1`. You can find the `aflplusplus` - default configuration on Google's +* For comparisons, use the fuzzbench `aflplusplus` setup, or use + `afl-clang-fast` with `AFL_LLVM_CMPLOG=1`. You can find the `aflplusplus` + default configuration on Google's [fuzzbench](https://github.com/google/fuzzbench/tree/master/fuzzers/aflplusplus). -* To get you started with tutorials, go to +* To get you started with tutorials, go to [docs/tutorials.md](docs/tutorials.md). ## Building and installing AFL++ -To have AFL++ easily available with everything compiled, pull the image +To have AFL++ easily available with everything compiled, pull the image directly from the Docker Hub: ```shell @@ -52,39 +52,39 @@ docker pull aflplusplus/aflplusplus 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 [docs/branches.md](docs/branches.md)). You will find your target source +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. To build AFL++ yourself, continue at [docs/INSTALL.md](docs/INSTALL.md). ## Quick start: Fuzzing with AFL++ -*NOTE: Before you start, please read about the [common sense risks of +*NOTE: Before you start, please read about the [common sense risks of fuzzing](docs/common_sense_risks.md).* -This is a quick start for fuzzing targets with the source code available. To +This is a quick start for fuzzing targets with the source code available. To read about the process in detail, see -[docs/fuzzing_expert.md](docs/fuzzing_expert.md). +[docs/fuzzing_in_depth.md](docs/fuzzing_in_depth.md). To learn about fuzzing other targets, see: -* Binary-only targets: +* Binary-only targets: [docs/fuzzing_binary-only_targets.md](docs/fuzzing_binary-only_targets.md) -* Network services: +* Network services: [docs/best_practices.md#fuzzing-a-network-service](docs/best_practices.md#fuzzing-a-network-service) -* GUI programs: +* GUI programs: [docs/best_practices.md#fuzzing-a-gui-program](docs/best_practices.md#fuzzing-a-gui-program) Step-by-step quick start: -1. Compile the program or library to be fuzzed using `afl-cc`. A common way to +1. Compile the program or library to be fuzzed using `afl-cc`. A common way to do this would be: CC=/path/to/afl-cc CXX=/path/to/afl-c++ ./configure --disable-shared make clean all -2. Get a small but valid input file that makes sense to the program. When - fuzzing verbose syntax (SQL, HTTP, etc), create a dictionary as described in +2. Get a small but valid input file that makes sense to the program. When + fuzzing verbose syntax (SQL, HTTP, etc), create a dictionary as described in [dictionaries/README.md](dictionaries/README.md), too. 3. If the program reads from stdin, run `afl-fuzz` like so: @@ -96,51 +96,63 @@ Step-by-step quick start: To add a dictionary, add `-x /path/to/dictionary.txt` to afl-fuzz. - If the program takes input from a file, you can put `@@` in the program's + If the program takes input from a file, you can put `@@` in the program's command line; AFL will put an auto-generated file name in there for you. -4. Investigate anything shown in red in the fuzzer UI by promptly consulting +4. Investigate anything shown in red in the fuzzer UI by promptly consulting [docs/status_screen.md](docs/status_screen.md). -5. You will find found crashes and hangs in the subdirectories `crashes/` and - `hangs/` in the `-o output_dir` directory. You can replay the crashes by - feeding them to the target, e.g.: `cat output_dir/crashes/id:000000,* | - /path/to/tested/program [...program's cmdline...]` You can generate cores or +5. You will find found crashes and hangs in the subdirectories `crashes/` and + `hangs/` in the `-o output_dir` directory. You can replay the crashes by + feeding them to the target, e.g.: `cat output_dir/crashes/id:000000,* | + /path/to/tested/program [...program's cmdline...]` You can generate cores or use gdb directly to follow up the crashes. ## Contact Questions? Concerns? Bug reports? -* The contributors can be reached via +* 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 - notes with other users or to get notified about major new features, send an +* There is a mailing list for the AFL/AFL++ project + ([browse archive](https://groups.google.com/group/afl-users)). To compare + notes with other users or to get notified about major new features, send an email to . * Or join the [Awesome Fuzzing](https://discord.gg/gCraWct) Discord server. +## Branches + +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. + +For releases, please see the [Releases tab](https://github.com/AFLplusplus/AFLplusplus/releases). +Also take a look at the list of [important changes in AFL++](docs/important_changes.md). + ## Help wanted -We have several [ideas](docs/ideas.md) we would like to see in AFL++ to make it -even better. However, we already work on so many things that we do not have the +We have several [ideas](docs/ideas.md) we would like to see in AFL++ to make it +even better. However, we already work on so many things that we do not have the time for all the big ideas. -This can be your way to support and contribute to AFL++ - extend it to do +This can be your way to support and contribute to AFL++ - extend it to do something cool. -For everyone who wants to contribute (and send pull requests), please read our +For everyone who wants to contribute (and send pull requests), please read our [contributing guidelines](CONTRIBUTING.md) before your submit. ## Special thanks -Many of the improvements to the original AFL and AFL++ wouldn't be possible +Many of the improvements to the original AFL and AFL++ wouldn't be possible without feedback, bug reports, or patches from our contributors. -Thank you! (For people sending pull requests - please add yourself to this list +Thank you! (For people sending pull requests - please add yourself to this list :-)
@@ -200,8 +212,8 @@ Thank you! (For people sending pull requests - please add yourself to this list ## Cite -If you use AFL++ in scientific work, consider citing -[our paper](https://www.usenix.org/conference/woot20/presentation/fioraldi) +If you use AFL++ in scientific work, consider citing +[our paper](https://www.usenix.org/conference/woot20/presentation/fioraldi) presented at WOOT'20: Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. “AFL++: Combining incremental steps of fuzzing research”. In 14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association, Aug. 2020. diff --git a/docs/best_practices.md b/docs/best_practices.md index 5d07dd14..7016f08d 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -48,7 +48,7 @@ to emulate the network. This is also much faster than the real network would be. See [utils/socket_fuzzing/](../utils/socket_fuzzing/). There is an outdated AFL++ branch that implements networking if you are -desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - +desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - however a better option is AFLnet ([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) which allows you to define network state with different type of data packets. @@ -62,7 +62,7 @@ which allows you to define network state with different type of data packets. 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_expert.md:b) Using multiple cores](fuzzing_expert.md#b-using-multiple-cores). +7. Use your cores ([fuzzing_in_depth.md:b) Using multiple cores](fuzzing_in_depth.md#b-using-multiple-cores))! ### Improving stability diff --git a/docs/branches.md b/docs/branches.md deleted file mode 100644 index ae147b08..00000000 --- a/docs/branches.md +++ /dev/null @@ -1,11 +0,0 @@ -# Branches - -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. - -For releases, please see the [Releases](https://github.com/AFLplusplus/AFLplusplus/releases) tab. -Also take a look at the list of [important changes in AFL++](important_changes.md). \ No newline at end of file diff --git a/docs/fuzzing_expert.md b/docs/fuzzing_expert.md deleted file mode 100644 index 876c5fbb..00000000 --- a/docs/fuzzing_expert.md +++ /dev/null @@ -1,630 +0,0 @@ -# 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 skip to [#Instrumenting binary-only apps](#Instrumenting binary-only apps) - -Fuzzing source code is a three-step process. - -1. Compile the target with a special compiler that prepares the target to be - fuzzed efficiently. This step is called "instrumenting a target". -2. Prepare the fuzzing by selecting and optimizing the input corpus for the - target. -3. Perform the fuzzing of the target by randomly mutating input and assessing - if a generated input was processed in a new path in the target binary. - -### 1. Instrumenting that target - -#### a) Selecting the best AFL++ compiler for instrumenting the target - -AFL++ comes with a central compiler `afl-cc` that incorporates various different -kinds of compiler targets and and instrumentation options. -The following evaluation flow will help you to select the best possible. - -It is highly recommended to have the newest llvm version possible installed, -anything below 9 is not recommended. - -``` -+--------------------------------+ -| clang/clang++ 11+ is available | --> use LTO mode (afl-clang-lto/afl-clang-lto++) -+--------------------------------+ see [instrumentation/README.lto.md](instrumentation/README.lto.md) - | - | if not, or if the target fails with LTO afl-clang-lto/++ - | - v -+---------------------------------+ -| clang/clang++ 3.8+ is available | --> use LLVM mode (afl-clang-fast/afl-clang-fast++) -+---------------------------------+ see [instrumentation/README.llvm.md](instrumentation/README.llvm.md) - | - | if not, or if the target fails with LLVM afl-clang-fast/++ - | - v - +--------------------------------+ - | gcc 5+ is available | -> use GCC_PLUGIN mode (afl-gcc-fast/afl-g++-fast) - +--------------------------------+ see [instrumentation/README.gcc_plugin.md](instrumentation/README.gcc_plugin.md) and - [instrumentation/README.instrument_list.md](instrumentation/README.instrument_list.md) - | - | if not, or if you do not have a gcc with plugin support - | - v - use GCC mode (afl-gcc/afl-g++) (or afl-clang/afl-clang++ for clang) -``` - -Clickable README links for the chosen compiler: - - * [LTO mode - afl-clang-lto](../instrumentation/README.lto.md) - * [LLVM mode - afl-clang-fast](../instrumentation/README.llvm.md) - * [GCC_PLUGIN mode - afl-gcc-fast](../instrumentation/README.gcc_plugin.md) - * GCC/CLANG modes (afl-gcc/afl-clang) have no README as they have no own features - -You can select the mode for the afl-cc compiler by: - 1. use a symlink to afl-cc: afl-gcc, afl-g++, afl-clang, afl-clang++, - afl-clang-fast, afl-clang-fast++, afl-clang-lto, afl-clang-lto++, - afl-gcc-fast, afl-g++-fast (recommended!) - 2. using the environment variable AFL_CC_COMPILER with MODE - 3. passing --afl-MODE command line options to the compiler via CFLAGS/CXXFLAGS/CPPFLAGS - -MODE can be one of: LTO (afl-clang-lto*), LLVM (afl-clang-fast*), GCC_PLUGIN -(afl-g*-fast) or GCC (afl-gcc/afl-g++) or CLANG(afl-clang/afl-clang++). - -Because no AFL specific command-line options are accepted (beside the ---afl-MODE command), the compile-time tools make fairly broad use of environment -variables, which can be listed with `afl-cc -hh` or by reading [env_variables.md](env_variables.md). - -#### b) Selecting instrumentation options - -The following options are available when you instrument with LTO mode (afl-clang-fast/afl-clang-lto): - - * Splitting integer, string, float and switch comparisons so AFL++ can easier - solve these. This is an important option if you do not have a very good - and large input corpus. This technique is called laf-intel or COMPCOV. - To use this set the following environment variable before compiling the - target: `export AFL_LLVM_LAF_ALL=1` - You can read more about this in [instrumentation/README.laf-intel.md](../instrumentation/README.laf-intel.md) - * A different technique (and usually a better one than laf-intel) is to - instrument the target so that any compare values in the target are sent to - AFL++ which then tries to put these values into the fuzzing data at different - locations. This technique is very fast and good - if the target does not - transform input data before comparison. Therefore this technique is called - `input to state` or `redqueen`. - If you want to use this technique, then you have to compile the target - twice, once specifically with/for this mode by setting `AFL_LLVM_CMPLOG=1`, - and pass this binary to afl-fuzz via the `-c` parameter. - Note that you can compile also just a cmplog binary and use that for both - however there will be a performance penality. - You can read more about this in [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md) - -If you use LTO, LLVM or GCC_PLUGIN mode (afl-clang-fast/afl-clang-lto/afl-gcc-fast) -you have the option to selectively only instrument parts of the target that you -are interested in: - - * To instrument only those parts of the target that you are interested in - create a file with all the filenames of the source code that should be - instrumented. - For afl-clang-lto and afl-gcc-fast - or afl-clang-fast if a mode other than - DEFAULT/PCGUARD is used or you have llvm > 10.0.0 - just put one - filename or function per line (no directory information necessary for - filenames9, and either set `export AFL_LLVM_ALLOWLIST=allowlist.txt` **or** - `export AFL_LLVM_DENYLIST=denylist.txt` - depending on if you want per - default to instrument unless noted (DENYLIST) or not perform instrumentation - unless requested (ALLOWLIST). - **NOTE:** During optimization functions might be inlined and then would not match! - See [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md) - -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) - -AFL++ performs "never zero" counting in its bitmap. You can read more about this -here: - * [instrumentation/README.neverzero.md](../instrumentation/README.neverzero.md) - -#### c) Sanitizers - -It is possible to use sanitizers when instrumenting targets for fuzzing, -which allows you to find bugs that would not necessarily result in a crash. - -Note that sanitizers have a huge impact on CPU (= less executions per second) -and RAM usage. Also you should only run one afl-fuzz instance per sanitizer type. -This is enough because a use-after-free bug will be picked up, e.g. by -ASAN (address sanitizer) anyway when syncing to other fuzzing instances, -so not all fuzzing instances need to be instrumented with ASAN. - -The following sanitizers have built-in support in AFL++: - * ASAN = Address SANitizer, finds memory corruption vulnerabilities like - use-after-free, NULL pointer dereference, buffer overruns, etc. - Enabled with `export AFL_USE_ASAN=1` before compiling. - * MSAN = Memory SANitizer, finds read access to uninitialized memory, eg. - a local variable that is defined and read before it is even set. - Enabled with `export AFL_USE_MSAN=1` before compiling. - * UBSAN = Undefined Behaviour SANitizer, finds instances where - by the - C and C++ standards - undefined behaviour happens, e.g. adding two - signed integers together where the result is larger than a signed integer - can hold. - Enabled with `export AFL_USE_UBSAN=1` before compiling. - * CFISAN = Control Flow Integrity SANitizer, finds instances where the - control flow is found to be illegal. Originally this was rather to - prevent return oriented programming exploit chains from functioning, - in fuzzing this is mostly reduced to detecting type confusion - vulnerabilities - which is however one of the most important and dangerous - C++ memory corruption classes! - Enabled with `export AFL_USE_CFISAN=1` before compiling. - * TSAN = Thread SANitizer, finds thread race conditions. - Enabled with `export AFL_USE_TSAN=1` before compiling. - * LSAN = Leak SANitizer, finds memory leaks in a program. This is not really - a security issue, but for developers this can be very valuable. - Note that unlike the other sanitizers above this needs - `__AFL_LEAK_CHECK();` added to all areas of the target source code where you - find a leak check necessary! - Enabled with `export AFL_USE_LSAN=1` before compiling. - -It is possible to further modify the behaviour of the sanitizers at run-time -by setting `ASAN_OPTIONS=...`, `LSAN_OPTIONS` etc. - the available parameters -can be looked up in the sanitizer documentation of llvm/clang. -afl-fuzz however requires some specific parameters important for fuzzing to be -set. If you want to set your own, it might bail and report what it is missing. - -Note that some sanitizers cannot be used together, e.g. ASAN and MSAN, and -others often cannot work together because of target weirdness, e.g. ASAN and -CFISAN. You might need to experiment which sanitizers you can combine in a -target (which means more instances can be run without a sanitized target, -which is more effective). - -#### d) Modify the target - -If the target has features that make fuzzing more difficult, e.g. -checksums, HMAC, etc. then modify the source code so that checks for these -values are removed. -This can even be done safely for source code used in operational products -by eliminating these checks within these AFL specific blocks: - -``` -#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION - // say that the checksum or HMAC was fine - or whatever is required - // to eliminate the need for the fuzzer to guess the right checksum - return 0; -#endif -``` - -All AFL++ compilers will set this preprocessor definition automatically. - -#### e) Instrument the target - -In this step the target source code is compiled so that it can be fuzzed. - -Basically you have to tell the target build system that the selected AFL++ -compiler is used. Also - if possible - you should always configure the -build system such that the target is compiled statically and not dynamically. -How to do this is described below. - -The #1 rule when instrumenting a target is: avoid instrumenting shared -libraries at all cost. You would need to set LD_LIBRARY_PATH to point to -these, you could accidently type "make install" and install them system wide - -so don't. Really don't. -**Always compile libraries you want to have instrumented as static and link -these to the target program!** - -Then build the target. (Usually with `make`) - -**NOTES** - -1. sometimes configure and build systems are fickle and do not like - stderr output (and think this means a test failure) - which is something - AFL++ likes to do to show statistics. It is recommended to disable AFL++ - instrumentation reporting via `export AFL_QUIET=1`. - -2. sometimes configure and build systems error on warnings - these should be - disabled (e.g. `--disable-werror` for some configure scripts). - -3. in case the configure/build system complains about AFL++'s compiler and - aborts then set `export AFL_NOOPT=1` which will then just behave like the - real compiler. This option has to be unset again before building the target! - -##### 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 -set AR to llvm-ar[-VERSION] and RANLIB to llvm-ranlib[-VERSION] - as is -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 -set AR to llvm-ar[-VERSION] and RANLIB to llvm-ranlib[-VERSION] - as is -described in [instrumentation/README.lto.md](../instrumentation/README.lto.md). - -##### meson - -For meson you have to set the AFL++ compiler with the very first command! -`CC=afl-cc CXX=afl-c++ meson` - -##### other build systems or if configure/cmake didn't work - -Sometimes cmake and configure do not pick up the AFL++ compiler, or the -ranlib/ar that is needed - because this was just not foreseen by the developer -of the target. Or they have non-standard options. Figure out if there is a -non-standard way to set this, otherwise set up the build normally and edit the -generated build environment afterwards manually to point it to the right compiler -(and/or ranlib and ar). - -#### f) Better instrumentation - -If you just fuzz a target program as-is you are wasting a great opportunity for -much more fuzzing speed. - -This variant requires the usage of afl-clang-lto, afl-clang-fast or afl-gcc-fast. - -It is the so-called `persistent mode`, which is much, much faster but -requires that you code a source file that is specifically calling the target -functions that you want to fuzz, plus a few specific AFL++ functions around -it. See [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md) for details. - -Basically if you do not fuzz a target in persistent mode then you are just -doing 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! -Compiling them is as simple as: -``` -afl-clang-fast++ -fsanitize=fuzzer -o harness harness.cpp targetlib.a -``` -You can even use advanced libfuzzer features like `FuzzedDataProvider`, -`LLVMFuzzerMutate()` etc. and they will work! - -The generated binary is fuzzed with afl-fuzz like any other fuzz target. - -Bonus: the target is already optimized for fuzzing due to persistent mode and -shared-memory testcases and hence gives you the fastest speed possible. - -For more information see [utils/aflpp_driver/README.md](../utils/aflpp_driver/README.md) - -### 2. Preparing the fuzzing campaign - -As you fuzz the target with mutated input, having as diverse inputs for the -target as possible improves the efficiency a lot. - -#### a) Collect inputs - -Try to gather valid inputs for the target from wherever you can. E.g. if it is -the PNG picture format try to find as many png files as possible, e.g. from -reported bugs, test suites, random downloads from the internet, unit test -case data - from all kind of PNG software. - -If the input format is not known, you can also modify a target program to write -normal data it receives and processes to a file and use these. - -#### b) Making the input corpus unique - -Use the AFL++ tool `afl-cmin` to remove inputs from the corpus that do not -produce a new path in the target. - -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 `@@`. - -If the target reads from stdin instead, just omit the `@@` as this is the -default. - -This step is highly recommended! - -#### c) Minimizing all corpus files - -The shorter the input files that still traverse the same path -within the target, the better the fuzzing will be. This minimization -is done with `afl-tmin` however it is a long process as this has to -be done for every file: - -``` -mkdir input -cd INPUTS_UNIQUE -for i in *; do - afl-tmin -i "$i" -o "../input/$i" -- bin/target -d @@ -done -``` - -This step can also be parallelized, e.g. with `parallel`. -Note that this step is rather optional though. - -#### Done! - -The INPUTS_UNIQUE/ directory from step b) - or even better the directory input/ -if you minimized the corpus in step c) - is the resulting input corpus directory -to be used in fuzzing! :-) - -### 3. Fuzzing the target - -In this final step we 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. - -If you just use one CPU for fuzzing, then you are fuzzing just for fun and not -seriously :-) - -#### a) Running afl-fuzz - -Before you do even a test run of afl-fuzz execute `sudo afl-system-config` (on -the host if you execute afl-fuzz in a docker container). This reconfigures the -system for optimal speed - which afl-fuzz checks and bails otherwise. -Set `export AFL_SKIP_CPUFREQ=1` for afl-fuzz to skip this check if you cannot -run afl-system-config with root privileges on the host for whatever reason. - -Note there is also `sudo afl-persistent-config` which sets additional permanent -boot options for a much better fuzzing performance. - -Note that both scripts improve your fuzzing performance but also decrease your -system protection against attacks! So set strong firewall rules and only -expose SSH as a network service if you use these (which is highly recommended). - -If you have an input corpus from step 2 then specify this directory with the `-i` -option. Otherwise create a new directory and create a file with any content -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. - -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! -Simply 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 simply 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. - -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 @@` - -Memory limits are not enforced by afl-fuzz by default and the system may run -out of memory. You can decrease the memory with the `-m` option, the value is -in MB. If this is too small for the target, you can usually see this by -afl-fuzz bailing with the message that it could not connect to the forkserver. - -Adding a dictionary is helpful. See the directory [dictionaries/](../dictionaries/) if -something is already included for your data format, and tell afl-fuzz to load -that dictionary by adding `-x dictionaries/FORMAT.dict`. With afl-clang-lto -you have an autodictionary generation for which you need to do nothing except -to use afl-clang-lto as the compiler. You also have the option to generate -a dictionary yourself, see [utils/libtokencap/README.md](../utils/libtokencap/README.md). - -afl-fuzz has a variety of options that help to workaround target quirks like -specific locations for the input file (`-f`), performing deterministic -fuzzing (`-D`) and many more. Check out `afl-fuzz -h`. - -We highly recommend that you set a memory limit for running the target with `-m` -which defines the maximum memory in MB. This prevents a potential -out-of-memory problem for your system plus helps you detect missing `malloc()` -failure 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 quadrouple that. - -By default afl-fuzz never stops fuzzing. To terminate AFL++ simply 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). - -#### b) Using multiple cores - -If you want to seriously fuzz then use as many cores/threads as possible to -fuzz your target. - -On the same machine - due to the design of how AFL++ works - there is a maximum -number of CPU cores/threads that are useful, use more and the overall performance -degrades instead. This value depends on the target, and the limit is between 32 -and 64 cores per machine. - -If you have the RAM, it is highly recommended run the instances with a caching -of the testcases. Depending on the average testcase size (and those found -during fuzzing) and their number, a value between 50-500MB is recommended. -You can set the cache size (in MB) by setting the environment variable `AFL_TESTCACHE_SIZE`. - -There should be one main fuzzer (`-M main-$HOSTNAME` option) and as many secondary -fuzzers (eg `-S variant1`) as you have cores that you use. -Every -M/-S entry needs a unique name (that can be whatever), however the same --o output directory location has to be used for all instances. - -For every secondary fuzzer there should be a variation, e.g.: - * one should fuzz the target that was compiled differently: with sanitizers - activated (`export AFL_USE_ASAN=1 ; export AFL_USE_UBSAN=1 ; - export AFL_USE_CFISAN=1`) - * one or two should fuzz the target with CMPLOG/redqueen (see above), at - least one cmplog instance should follow transformations (`-l AT`) - * one to three fuzzers should fuzz a target compiled with laf-intel/COMPCOV - (see above). Important note: If you run more than one laf-intel/COMPCOV - fuzzer and you want them to share their intermediate results, the main - fuzzer (`-M`) must be one of the them! (Although this is not really - recommended.) - -All other secondaries should be used like this: - * A quarter to a third with the MOpt mutator enabled: `-L 0` - * run with a different power schedule, recommended are: - `fast (default), explore, coe, lin, quad, exploit and rare` - which you can set with e.g. `-p explore` - * a few instances should use the old queue cycling with `-Z` - -Also it is recommended to set `export AFL_IMPORT_FIRST=1` to load testcases -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`. - -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 `-S` name. -Examples are: - * [Fuzzolic](https://github.com/season-lab/fuzzolic) - * [symcc](https://github.com/eurecom-s3/symcc/) - * [Eclipser](https://github.com/SoftSec-KAIST/Eclipser/) - * [AFLsmart](https://github.com/aflsmart/aflsmart) - * [FairFuzz](https://github.com/carolemieux/afl-rb) - * [Neuzz](https://github.com/Dongdongshe/neuzz) - * [Angora](https://github.com/AngoraFuzzer/Angora) - -A long list can be found at [https://github.com/Microsvuln/Awesome-AFL](https://github.com/Microsvuln/Awesome-AFL) - -However you can also sync AFL++ with honggfuzz, libfuzzer with `-entropic=1`, etc. -Just show the main fuzzer (-M) with the `-F` option where the queue/work -directory of a different fuzzer is, e.g. `-F /src/target/honggfuzz`. -Using honggfuzz (with `-n 1` or `-n 2`) and libfuzzer in parallel is highly -recommended! - -#### c) Using multiple machines for fuzzing - -Maybe you have more than one machine you want to fuzz the same target on. -Simply 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 the each follow different paths into the target. You can make - this even more interesting by even giving different seeds to each server. - * regularly (~4h): this ensures that all fuzzing campaigns on the servers - "see" the same thing. It is like fuzzing on a huge server. - * in intervals of 1/10th of the overall expected runtime of the fuzzing you - sync. This tries a bit to combine both. have some individuality of the - paths each campaign on a server explores, on the other hand if one - gets stuck where another found progress this is handed over making it - unstuck. - -The syncing process itself is very simple. -As the `-M main-$HOSTNAME` instance syncs to all `-S` secondaries as well -as to other fuzzers, you have to copy only this directory to the other -machines. - -Lets say all servers have the `-o out` directory in /target/foo/out, and -you created a file `servers.txt` which contains the hostnames of all -participating servers, plus you have an ssh key deployed to all of them, -then run: -```bash -for FROM in `cat servers.txt`; do - for TO in `cat servers.txt`; do - rsync -rlpogtz --rsh=ssh $FROM:/target/foo/out/main-$FROM $TO:target/foo/out/ - done -done -``` -You can run this manually, per cron job - as you need it. -There is a more complex and configurable script in `utils/distributed_fuzzing`. - -#### d) The status of the fuzz campaign - -AFL++ comes with the `afl-whatsup` script to show the status of the fuzzing -campaign. - -Just supply the directory that afl-fuzz is given with the -o option and -you will see a detailed status of every fuzzer in that campaign plus -a summary. - -To have only the summary use the `-s` switch e.g.: `afl-whatsup -s out/` - -If you have multiple servers then use the command after a sync, or you have -to execute this script per server. - -Another tool to inspect the current state and history of a specific instance -is afl-plot, which generates an index.html file and a graphs that show how -the fuzzing instance is performing. -The syntax is `afl-plot instance_dir web_dir`, e.g. `afl-plot out/default /srv/www/htdocs/plot` - -#### e) Stopping fuzzing, restarting fuzzing, adding new seeds - -To stop an afl-fuzz run, simply press Control-C. - -To restart an afl-fuzz run, just reuse the same command line but replace the -`-i directory` with `-i -` or set `AFL_AUTORESUME=1`. - -If you want to add new seeds to a fuzzing campaign you can run a temporary -fuzzing instance, e.g. when your main fuzzer is using `-o out` and the new -seeds are in `newseeds/` directory: -``` -AFL_BENCH_JUST_ONE=1 AFL_FAST_CAL=1 afl-fuzz -i newseeds -o out -S newseeds -- ./target -``` - -#### f) Checking the coverage of the fuzzing - -The `paths found` value is a bad indicator for checking how good the coverage is. - -A better indicator - if you use default llvm instrumentation with at least -version 9 - is to use `afl-showmap` with the collect coverage option `-C` on -the output directory: -``` -$ afl-showmap -C -i out -o /dev/null -- ./target -params @@ -... -[*] Using SHARED MEMORY FUZZING feature. -[*] Target map size: 9960 -[+] Processed 7849 input files. -[+] Captured 4331 tuples (highest value 255, total values 67130596) in '/dev/nul -l'. -[+] A coverage of 4331 edges were achieved out of 9960 existing (43.48%) with 7849 input files. -``` -It is even better to check out the exact lines of code that have been reached - -and which have not been found so far. - -An "easy" helper script for this is [https://github.com/vanhauser-thc/afl-cov](https://github.com/vanhauser-thc/afl-cov), -just follow the README of that separate project. - -If you see that an important area or a feature has not been covered so far then -try to find an input that is able to reach that and start a new secondary in -that fuzzing campaign with that seed as input, let it run for a few minutes, -then terminate it. The main node will pick it up and make it available to the -other secondary nodes over time. Set `export AFL_NO_AFFINITY=1` or -`export AFL_TRY_AFFINITY=1` if you have no free core. - -Note that in nearly all cases you can never reach full coverage. A lot of -functionality is usually dependent on exclusive options that would need individual -fuzzing campaigns each with one of these options set. E.g. if you fuzz a library to -convert image formats and your target is the png to tiff API then you will not -touch any of the other library APIs and features. - -#### g) How long to fuzz a target? - -This is a difficult question. -Basically if no new path is found for a long time (e.g. for a day or a week) -then you can expect that your fuzzing won't be fruitful anymore. -However often this just means that you should switch out secondaries for -others, e.g. custom mutator modules, sync to very different fuzzers, etc. - -Keep the queue/ directory (for future fuzzings of the same or similar targets) -and use them to seed other good fuzzers like libfuzzer with the -entropic -switch or honggfuzz. - -#### h) Improve the speed! - - * Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 speed increase) - * If you do not use shmem persistent mode, use `AFL_TMPDIR` to point the input file on a tempfs location, see [env_variables.md](env_variables.md) - * Linux: Improve 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 more insecure) - you can also just run `sudo afl-persistent-config` - * Linux: Running on an `ext2` filesystem with `noatime` mount option will be a bit faster than on any other journaling filesystem - * Use your cores! [b) Using multiple cores](#b-using-multiple-cores) - * Run `sudo afl-system-config` before starting the first afl-fuzz instance after a reboot - -### The End - -Check out the [FAQ](FAQ.md) if it maybe answers your question (that -you might not even have known you had ;-) ). - -This is basically all you need to know to professionally run fuzzing campaigns. -If you want to know more, the tons of texts in [docs/](./) will have you covered. - -Note that there are also a lot of tools out there that help fuzzing with AFL++ -(some might be deprecated or unsupported), see [tools.md](tools.md). \ No newline at end of file diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md new file mode 100644 index 00000000..5306cbef --- /dev/null +++ b/docs/fuzzing_in_depth.md @@ -0,0 +1,630 @@ +# 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 skip to [#Instrumenting binary-only apps](#Instrumenting binary-only apps) + +Fuzzing source code is a three-step process. + +1. Compile the target with a special compiler that prepares the target to be + fuzzed efficiently. This step is called "instrumenting a target". +2. Prepare the fuzzing by selecting and optimizing the input corpus for the + target. +3. Perform the fuzzing of the target by randomly mutating input and assessing + if a generated input was processed in a new path in the target binary. + +### 1. Instrumenting that target + +#### a) Selecting the best AFL++ compiler for instrumenting the target + +AFL++ comes with a central compiler `afl-cc` that incorporates various different +kinds of compiler targets and and instrumentation options. +The following evaluation flow will help you to select the best possible. + +It is highly recommended to have the newest llvm version possible installed, +anything below 9 is not recommended. + +``` ++--------------------------------+ +| clang/clang++ 11+ is available | --> use LTO mode (afl-clang-lto/afl-clang-lto++) ++--------------------------------+ see [instrumentation/README.lto.md](instrumentation/README.lto.md) + | + | if not, or if the target fails with LTO afl-clang-lto/++ + | + v ++---------------------------------+ +| clang/clang++ 3.8+ is available | --> use LLVM mode (afl-clang-fast/afl-clang-fast++) ++---------------------------------+ see [instrumentation/README.llvm.md](instrumentation/README.llvm.md) + | + | if not, or if the target fails with LLVM afl-clang-fast/++ + | + v + +--------------------------------+ + | gcc 5+ is available | -> use GCC_PLUGIN mode (afl-gcc-fast/afl-g++-fast) + +--------------------------------+ see [instrumentation/README.gcc_plugin.md](instrumentation/README.gcc_plugin.md) and + [instrumentation/README.instrument_list.md](instrumentation/README.instrument_list.md) + | + | if not, or if you do not have a gcc with plugin support + | + v + use GCC mode (afl-gcc/afl-g++) (or afl-clang/afl-clang++ for clang) +``` + +Clickable README links for the chosen compiler: + + * [LTO mode - afl-clang-lto](../instrumentation/README.lto.md) + * [LLVM mode - afl-clang-fast](../instrumentation/README.llvm.md) + * [GCC_PLUGIN mode - afl-gcc-fast](../instrumentation/README.gcc_plugin.md) + * GCC/CLANG modes (afl-gcc/afl-clang) have no README as they have no own features + +You can select the mode for the afl-cc compiler by: + 1. use a symlink to afl-cc: afl-gcc, afl-g++, afl-clang, afl-clang++, + afl-clang-fast, afl-clang-fast++, afl-clang-lto, afl-clang-lto++, + afl-gcc-fast, afl-g++-fast (recommended!) + 2. using the environment variable AFL_CC_COMPILER with MODE + 3. passing --afl-MODE command line options to the compiler via CFLAGS/CXXFLAGS/CPPFLAGS + +MODE can be one of: LTO (afl-clang-lto*), LLVM (afl-clang-fast*), GCC_PLUGIN +(afl-g*-fast) or GCC (afl-gcc/afl-g++) or CLANG(afl-clang/afl-clang++). + +Because no AFL specific command-line options are accepted (beside the +--afl-MODE command), the compile-time tools make fairly broad use of environment +variables, which can be listed with `afl-cc -hh` or by reading [env_variables.md](env_variables.md). + +#### b) Selecting instrumentation options + +The following options are available when you instrument with LTO mode (afl-clang-fast/afl-clang-lto): + + * Splitting integer, string, float and switch comparisons so AFL++ can easier + solve these. This is an important option if you do not have a very good + and large input corpus. This technique is called laf-intel or COMPCOV. + To use this set the following environment variable before compiling the + target: `export AFL_LLVM_LAF_ALL=1` + You can read more about this in [instrumentation/README.laf-intel.md](../instrumentation/README.laf-intel.md) + * A different technique (and usually a better one than laf-intel) is to + instrument the target so that any compare values in the target are sent to + AFL++ which then tries to put these values into the fuzzing data at different + locations. This technique is very fast and good - if the target does not + transform input data before comparison. Therefore this technique is called + `input to state` or `redqueen`. + If you want to use this technique, then you have to compile the target + twice, once specifically with/for this mode by setting `AFL_LLVM_CMPLOG=1`, + and pass this binary to afl-fuzz via the `-c` parameter. + Note that you can compile also just a cmplog binary and use that for both + however there will be a performance penality. + You can read more about this in [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md) + +If you use LTO, LLVM or GCC_PLUGIN mode (afl-clang-fast/afl-clang-lto/afl-gcc-fast) +you have the option to selectively only instrument parts of the target that you +are interested in: + + * To instrument only those parts of the target that you are interested in + create a file with all the filenames of the source code that should be + instrumented. + For afl-clang-lto and afl-gcc-fast - or afl-clang-fast if a mode other than + DEFAULT/PCGUARD is used or you have llvm > 10.0.0 - just put one + filename or function per line (no directory information necessary for + filenames9, and either set `export AFL_LLVM_ALLOWLIST=allowlist.txt` **or** + `export AFL_LLVM_DENYLIST=denylist.txt` - depending on if you want per + default to instrument unless noted (DENYLIST) or not perform instrumentation + unless requested (ALLOWLIST). + **NOTE:** During optimization functions might be inlined and then would not match! + See [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md) + +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) + +AFL++ performs "never zero" counting in its bitmap. You can read more about this +here: + * [instrumentation/README.neverzero.md](../instrumentation/README.neverzero.md) + +#### c) Sanitizers + +It is possible to use sanitizers when instrumenting targets for fuzzing, +which allows you to find bugs that would not necessarily result in a crash. + +Note that sanitizers have a huge impact on CPU (= less executions per second) +and RAM usage. Also you should only run one afl-fuzz instance per sanitizer type. +This is enough because a use-after-free bug will be picked up, e.g. by +ASAN (address sanitizer) anyway when syncing to other fuzzing instances, +so not all fuzzing instances need to be instrumented with ASAN. + +The following sanitizers have built-in support in AFL++: + * ASAN = Address SANitizer, finds memory corruption vulnerabilities like + use-after-free, NULL pointer dereference, buffer overruns, etc. + Enabled with `export AFL_USE_ASAN=1` before compiling. + * MSAN = Memory SANitizer, finds read access to uninitialized memory, eg. + a local variable that is defined and read before it is even set. + Enabled with `export AFL_USE_MSAN=1` before compiling. + * UBSAN = Undefined Behaviour SANitizer, finds instances where - by the + C and C++ standards - undefined behaviour happens, e.g. adding two + signed integers together where the result is larger than a signed integer + can hold. + Enabled with `export AFL_USE_UBSAN=1` before compiling. + * CFISAN = Control Flow Integrity SANitizer, finds instances where the + control flow is found to be illegal. Originally this was rather to + prevent return oriented programming exploit chains from functioning, + in fuzzing this is mostly reduced to detecting type confusion + vulnerabilities - which is however one of the most important and dangerous + C++ memory corruption classes! + Enabled with `export AFL_USE_CFISAN=1` before compiling. + * TSAN = Thread SANitizer, finds thread race conditions. + Enabled with `export AFL_USE_TSAN=1` before compiling. + * LSAN = Leak SANitizer, finds memory leaks in a program. This is not really + a security issue, but for developers this can be very valuable. + Note that unlike the other sanitizers above this needs + `__AFL_LEAK_CHECK();` added to all areas of the target source code where you + find a leak check necessary! + Enabled with `export AFL_USE_LSAN=1` before compiling. + +It is possible to further modify the behaviour of the sanitizers at run-time +by setting `ASAN_OPTIONS=...`, `LSAN_OPTIONS` etc. - the available parameters +can be looked up in the sanitizer documentation of llvm/clang. +afl-fuzz however requires some specific parameters important for fuzzing to be +set. If you want to set your own, it might bail and report what it is missing. + +Note that some sanitizers cannot be used together, e.g. ASAN and MSAN, and +others often cannot work together because of target weirdness, e.g. ASAN and +CFISAN. You might need to experiment which sanitizers you can combine in a +target (which means more instances can be run without a sanitized target, +which is more effective). + +#### d) Modify the target + +If the target has features that make fuzzing more difficult, e.g. +checksums, HMAC, etc. then modify the source code so that checks for these +values are removed. +This can even be done safely for source code used in operational products +by eliminating these checks within these AFL specific blocks: + +``` +#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION + // say that the checksum or HMAC was fine - or whatever is required + // to eliminate the need for the fuzzer to guess the right checksum + return 0; +#endif +``` + +All AFL++ compilers will set this preprocessor definition automatically. + +#### e) Instrument the target + +In this step the target source code is compiled so that it can be fuzzed. + +Basically you have to tell the target build system that the selected AFL++ +compiler is used. Also - if possible - you should always configure the +build system such that the target is compiled statically and not dynamically. +How to do this is described below. + +The #1 rule when instrumenting a target is: avoid instrumenting shared +libraries at all cost. You would need to set LD_LIBRARY_PATH to point to +these, you could accidently type "make install" and install them system wide - +so don't. Really don't. +**Always compile libraries you want to have instrumented as static and link +these to the target program!** + +Then build the target. (Usually with `make`) + +**NOTES** + +1. sometimes configure and build systems are fickle and do not like + stderr output (and think this means a test failure) - which is something + AFL++ likes to do to show statistics. It is recommended to disable AFL++ + instrumentation reporting via `export AFL_QUIET=1`. + +2. sometimes configure and build systems error on warnings - these should be + disabled (e.g. `--disable-werror` for some configure scripts). + +3. in case the configure/build system complains about AFL++'s compiler and + aborts then set `export AFL_NOOPT=1` which will then just behave like the + real compiler. This option has to be unset again before building the target! + +##### 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 +set AR to llvm-ar[-VERSION] and RANLIB to llvm-ranlib[-VERSION] - as is +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 +set AR to llvm-ar[-VERSION] and RANLIB to llvm-ranlib[-VERSION] - as is +described in [instrumentation/README.lto.md](../instrumentation/README.lto.md). + +##### meson + +For meson you have to set the AFL++ compiler with the very first command! +`CC=afl-cc CXX=afl-c++ meson` + +##### other build systems or if configure/cmake didn't work + +Sometimes cmake and configure do not pick up the AFL++ compiler, or the +ranlib/ar that is needed - because this was just not foreseen by the developer +of the target. Or they have non-standard options. Figure out if there is a +non-standard way to set this, otherwise set up the build normally and edit the +generated build environment afterwards manually to point it to the right compiler +(and/or ranlib and ar). + +#### f) Better instrumentation + +If you just fuzz a target program as-is you are wasting a great opportunity for +much more fuzzing speed. + +This variant requires the usage of afl-clang-lto, afl-clang-fast or afl-gcc-fast. + +It is the so-called `persistent mode`, which is much, much faster but +requires that you code a source file that is specifically calling the target +functions that you want to fuzz, plus a few specific AFL++ functions around +it. See [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md) for details. + +Basically if you do not fuzz a target in persistent mode then you are just +doing 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! +Compiling them is as simple as: +``` +afl-clang-fast++ -fsanitize=fuzzer -o harness harness.cpp targetlib.a +``` +You can even use advanced libfuzzer features like `FuzzedDataProvider`, +`LLVMFuzzerMutate()` etc. and they will work! + +The generated binary is fuzzed with afl-fuzz like any other fuzz target. + +Bonus: the target is already optimized for fuzzing due to persistent mode and +shared-memory testcases and hence gives you the fastest speed possible. + +For more information see [utils/aflpp_driver/README.md](../utils/aflpp_driver/README.md) + +### 2. Preparing the fuzzing campaign + +As you fuzz the target with mutated input, having as diverse inputs for the +target as possible improves the efficiency a lot. + +#### a) Collect inputs + +Try to gather valid inputs for the target from wherever you can. E.g. if it is +the PNG picture format try to find as many png files as possible, e.g. from +reported bugs, test suites, random downloads from the internet, unit test +case data - from all kind of PNG software. + +If the input format is not known, you can also modify a target program to write +normal data it receives and processes to a file and use these. + +#### b) Making the input corpus unique + +Use the AFL++ tool `afl-cmin` to remove inputs from the corpus that do not +produce a new path in the target. + +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 `@@`. + +If the target reads from stdin instead, just omit the `@@` as this is the +default. + +This step is highly recommended! + +#### c) Minimizing all corpus files + +The shorter the input files that still traverse the same path +within the target, the better the fuzzing will be. This minimization +is done with `afl-tmin` however it is a long process as this has to +be done for every file: + +``` +mkdir input +cd INPUTS_UNIQUE +for i in *; do + afl-tmin -i "$i" -o "../input/$i" -- bin/target -d @@ +done +``` + +This step can also be parallelized, e.g. with `parallel`. +Note that this step is rather optional though. + +#### Done! + +The INPUTS_UNIQUE/ directory from step b) - or even better the directory input/ +if you minimized the corpus in step c) - is the resulting input corpus directory +to be used in fuzzing! :-) + +### 3. Fuzzing the target + +In this final step we 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. + +If you just use one CPU for fuzzing, then you are fuzzing just for fun and not +seriously :-) + +#### a) Running afl-fuzz + +Before you do even a test run of afl-fuzz execute `sudo afl-system-config` (on +the host if you execute afl-fuzz in a docker container). This reconfigures the +system for optimal speed - which afl-fuzz checks and bails otherwise. +Set `export AFL_SKIP_CPUFREQ=1` for afl-fuzz to skip this check if you cannot +run afl-system-config with root privileges on the host for whatever reason. + +Note there is also `sudo afl-persistent-config` which sets additional permanent +boot options for a much better fuzzing performance. + +Note that both scripts improve your fuzzing performance but also decrease your +system protection against attacks! So set strong firewall rules and only +expose SSH as a network service if you use these (which is highly recommended). + +If you have an input corpus from step 2 then specify this directory with the `-i` +option. Otherwise create a new directory and create a file with any content +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. + +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! +Simply 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 simply 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. + +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 @@` + +Memory limits are not enforced by afl-fuzz by default and the system may run +out of memory. You can decrease the memory with the `-m` option, the value is +in MB. If this is too small for the target, you can usually see this by +afl-fuzz bailing with the message that it could not connect to the forkserver. + +Adding a dictionary is helpful. See the directory [dictionaries/](../dictionaries/) if +something is already included for your data format, and tell afl-fuzz to load +that dictionary by adding `-x dictionaries/FORMAT.dict`. With afl-clang-lto +you have an autodictionary generation for which you need to do nothing except +to use afl-clang-lto as the compiler. You also have the option to generate +a dictionary yourself, see [utils/libtokencap/README.md](../utils/libtokencap/README.md). + +afl-fuzz has a variety of options that help to workaround target quirks like +specific locations for the input file (`-f`), performing deterministic +fuzzing (`-D`) and many more. Check out `afl-fuzz -h`. + +We highly recommend that you set a memory limit for running the target with `-m` +which defines the maximum memory in MB. This prevents a potential +out-of-memory problem for your system plus helps you detect missing `malloc()` +failure 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 quadrouple that. + +By default afl-fuzz never stops fuzzing. To terminate AFL++ simply 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). + +#### b) Using multiple cores + +If you want to seriously fuzz then use as many cores/threads as possible to +fuzz your target. + +On the same machine - due to the design of how AFL++ works - there is a maximum +number of CPU cores/threads that are useful, use more and the overall performance +degrades instead. This value depends on the target, and the limit is between 32 +and 64 cores per machine. + +If you have the RAM, it is highly recommended run the instances with a caching +of the testcases. Depending on the average testcase size (and those found +during fuzzing) and their number, a value between 50-500MB is recommended. +You can set the cache size (in MB) by setting the environment variable `AFL_TESTCACHE_SIZE`. + +There should be one main fuzzer (`-M main-$HOSTNAME` option) and as many secondary +fuzzers (eg `-S variant1`) as you have cores that you use. +Every -M/-S entry needs a unique name (that can be whatever), however the same +-o output directory location has to be used for all instances. + +For every secondary fuzzer there should be a variation, e.g.: + * one should fuzz the target that was compiled differently: with sanitizers + activated (`export AFL_USE_ASAN=1 ; export AFL_USE_UBSAN=1 ; + export AFL_USE_CFISAN=1`) + * one or two should fuzz the target with CMPLOG/redqueen (see above), at + least one cmplog instance should follow transformations (`-l AT`) + * one to three fuzzers should fuzz a target compiled with laf-intel/COMPCOV + (see above). Important note: If you run more than one laf-intel/COMPCOV + fuzzer and you want them to share their intermediate results, the main + fuzzer (`-M`) must be one of the them! (Although this is not really + recommended.) + +All other secondaries should be used like this: + * A quarter to a third with the MOpt mutator enabled: `-L 0` + * run with a different power schedule, recommended are: + `fast (default), explore, coe, lin, quad, exploit and rare` + which you can set with e.g. `-p explore` + * a few instances should use the old queue cycling with `-Z` + +Also it is recommended to set `export AFL_IMPORT_FIRST=1` to load testcases +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`. + +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 `-S` name. +Examples are: + * [Fuzzolic](https://github.com/season-lab/fuzzolic) + * [symcc](https://github.com/eurecom-s3/symcc/) + * [Eclipser](https://github.com/SoftSec-KAIST/Eclipser/) + * [AFLsmart](https://github.com/aflsmart/aflsmart) + * [FairFuzz](https://github.com/carolemieux/afl-rb) + * [Neuzz](https://github.com/Dongdongshe/neuzz) + * [Angora](https://github.com/AngoraFuzzer/Angora) + +A long list can be found at [https://github.com/Microsvuln/Awesome-AFL](https://github.com/Microsvuln/Awesome-AFL) + +However you can also sync AFL++ with honggfuzz, libfuzzer with `-entropic=1`, etc. +Just show the main fuzzer (-M) with the `-F` option where the queue/work +directory of a different fuzzer is, e.g. `-F /src/target/honggfuzz`. +Using honggfuzz (with `-n 1` or `-n 2`) and libfuzzer in parallel is highly +recommended! + +#### c) Using multiple machines for fuzzing + +Maybe you have more than one machine you want to fuzz the same target on. +Simply 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 the each follow different paths into the target. You can make + this even more interesting by even giving different seeds to each server. + * regularly (~4h): this ensures that all fuzzing campaigns on the servers + "see" the same thing. It is like fuzzing on a huge server. + * in intervals of 1/10th of the overall expected runtime of the fuzzing you + sync. This tries a bit to combine both. have some individuality of the + paths each campaign on a server explores, on the other hand if one + gets stuck where another found progress this is handed over making it + unstuck. + +The syncing process itself is very simple. +As the `-M main-$HOSTNAME` instance syncs to all `-S` secondaries as well +as to other fuzzers, you have to copy only this directory to the other +machines. + +Lets say all servers have the `-o out` directory in /target/foo/out, and +you created a file `servers.txt` which contains the hostnames of all +participating servers, plus you have an ssh key deployed to all of them, +then run: +```bash +for FROM in `cat servers.txt`; do + for TO in `cat servers.txt`; do + rsync -rlpogtz --rsh=ssh $FROM:/target/foo/out/main-$FROM $TO:target/foo/out/ + done +done +``` +You can run this manually, per cron job - as you need it. +There is a more complex and configurable script in `utils/distributed_fuzzing`. + +#### d) The status of the fuzz campaign + +AFL++ comes with the `afl-whatsup` script to show the status of the fuzzing +campaign. + +Just supply the directory that afl-fuzz is given with the -o option and +you will see a detailed status of every fuzzer in that campaign plus +a summary. + +To have only the summary use the `-s` switch e.g.: `afl-whatsup -s out/` + +If you have multiple servers then use the command after a sync, or you have +to execute this script per server. + +Another tool to inspect the current state and history of a specific instance +is afl-plot, which generates an index.html file and a graphs that show how +the fuzzing instance is performing. +The syntax is `afl-plot instance_dir web_dir`, e.g. `afl-plot out/default /srv/www/htdocs/plot` + +#### e) Stopping fuzzing, restarting fuzzing, adding new seeds + +To stop an afl-fuzz run, simply press Control-C. + +To restart an afl-fuzz run, just reuse the same command line but replace the +`-i directory` with `-i -` or set `AFL_AUTORESUME=1`. + +If you want to add new seeds to a fuzzing campaign you can run a temporary +fuzzing instance, e.g. when your main fuzzer is using `-o out` and the new +seeds are in `newseeds/` directory: +``` +AFL_BENCH_JUST_ONE=1 AFL_FAST_CAL=1 afl-fuzz -i newseeds -o out -S newseeds -- ./target +``` + +#### f) Checking the coverage of the fuzzing + +The `paths found` value is a bad indicator for checking how good the coverage is. + +A better indicator - if you use default llvm instrumentation with at least +version 9 - is to use `afl-showmap` with the collect coverage option `-C` on +the output directory: +``` +$ afl-showmap -C -i out -o /dev/null -- ./target -params @@ +... +[*] Using SHARED MEMORY FUZZING feature. +[*] Target map size: 9960 +[+] Processed 7849 input files. +[+] Captured 4331 tuples (highest value 255, total values 67130596) in '/dev/nul +l'. +[+] A coverage of 4331 edges were achieved out of 9960 existing (43.48%) with 7849 input files. +``` +It is even better to check out the exact lines of code that have been reached - +and which have not been found so far. + +An "easy" helper script for this is [https://github.com/vanhauser-thc/afl-cov](https://github.com/vanhauser-thc/afl-cov), +just follow the README of that separate project. + +If you see that an important area or a feature has not been covered so far then +try to find an input that is able to reach that and start a new secondary in +that fuzzing campaign with that seed as input, let it run for a few minutes, +then terminate it. The main node will pick it up and make it available to the +other secondary nodes over time. Set `export AFL_NO_AFFINITY=1` or +`export AFL_TRY_AFFINITY=1` if you have no free core. + +Note that in nearly all cases you can never reach full coverage. A lot of +functionality is usually dependent on exclusive options that would need individual +fuzzing campaigns each with one of these options set. E.g. if you fuzz a library to +convert image formats and your target is the png to tiff API then you will not +touch any of the other library APIs and features. + +#### g) How long to fuzz a target? + +This is a difficult question. +Basically if no new path is found for a long time (e.g. for a day or a week) +then you can expect that your fuzzing won't be fruitful anymore. +However often this just means that you should switch out secondaries for +others, e.g. custom mutator modules, sync to very different fuzzers, etc. + +Keep the queue/ directory (for future fuzzings of the same or similar targets) +and use them to seed other good fuzzers like libfuzzer with the -entropic +switch or honggfuzz. + +#### h) Improve the speed! + + * Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 speed increase) + * If you do not use shmem persistent mode, use `AFL_TMPDIR` to point the input file on a tempfs location, see [env_variables.md](env_variables.md) + * Linux: Improve 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 more insecure) - you can also just run `sudo afl-persistent-config` + * Linux: Running on an `ext2` filesystem with `noatime` mount option will be a bit faster than on any other journaling filesystem + * Use your cores! [b) Using multiple cores](#b-using-multiple-cores) + * Run `sudo afl-system-config` before starting the first afl-fuzz instance after a reboot + +### The End + +Check out the [FAQ](FAQ.md) if it maybe answers your question (that +you might not even have known you had ;-) ). + +This is basically all you need to know to professionally run fuzzing campaigns. +If you want to know more, the tons of texts in [docs/](./) will have you covered. + +Note that there are also a lot of tools out there that help fuzzing with AFL++ +(some might be deprecated or unsupported), see [third_party_tools.md](third_party_tools.md). \ No newline at end of file diff --git a/docs/known_limitations.md b/docs/known_limitations.md deleted file mode 100644 index a68c0a85..00000000 --- a/docs/known_limitations.md +++ /dev/null @@ -1,36 +0,0 @@ -# Known limitations & areas for improvement - -Here are some of the most important caveats for AFL: - - - AFL++ detects faults by checking for the first spawned process dying due to - a signal (SIGSEGV, SIGABRT, etc). Programs that install custom handlers for - these signals may need to have the relevant code commented out. In the same - vein, faults in child processes spawned by the fuzzed target may evade - detection unless you manually add some code to catch that. - - - As with any other brute-force tool, the fuzzer offers limited coverage if - encryption, checksums, cryptographic signatures, or compression are used to - wholly wrap the actual data format to be tested. - - To work around this, you can comment out the relevant checks (see - utils/libpng_no_checksum/ for inspiration); if this is not possible, - you can also write a postprocessor, one of the hooks of custom mutators. - See [custom_mutators.md](custom_mutators.md) on how to use - `AFL_CUSTOM_MUTATOR_LIBRARY` - - - There are some unfortunate trade-offs with ASAN and 64-bit binaries. This - isn't due to any specific fault of afl-fuzz. - - - There is no direct support for fuzzing network services, background - daemons, or interactive apps that require UI interaction to work. You may - need to make simple code changes to make them behave in a more traditional - way. Preeny may offer a relatively simple option, too - see: - [https://github.com/zardus/preeny](https://github.com/zardus/preeny) - - Some useful tips for modifying network-based services can be also found at: - [https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop](https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop) - - - Occasionally, sentient machines rise against their creators. If this - happens to you, please consult [https://lcamtuf.coredump.cx/prep/](https://lcamtuf.coredump.cx/prep/). - -Beyond this, see [INSTALL.md](INSTALL.md) for platform-specific tips. diff --git a/docs/limitations.md b/docs/limitations.md new file mode 100644 index 00000000..a68c0a85 --- /dev/null +++ b/docs/limitations.md @@ -0,0 +1,36 @@ +# Known limitations & areas for improvement + +Here are some of the most important caveats for AFL: + + - AFL++ detects faults by checking for the first spawned process dying due to + a signal (SIGSEGV, SIGABRT, etc). Programs that install custom handlers for + these signals may need to have the relevant code commented out. In the same + vein, faults in child processes spawned by the fuzzed target may evade + detection unless you manually add some code to catch that. + + - As with any other brute-force tool, the fuzzer offers limited coverage if + encryption, checksums, cryptographic signatures, or compression are used to + wholly wrap the actual data format to be tested. + + To work around this, you can comment out the relevant checks (see + utils/libpng_no_checksum/ for inspiration); if this is not possible, + you can also write a postprocessor, one of the hooks of custom mutators. + See [custom_mutators.md](custom_mutators.md) on how to use + `AFL_CUSTOM_MUTATOR_LIBRARY` + + - There are some unfortunate trade-offs with ASAN and 64-bit binaries. This + isn't due to any specific fault of afl-fuzz. + + - There is no direct support for fuzzing network services, background + daemons, or interactive apps that require UI interaction to work. You may + need to make simple code changes to make them behave in a more traditional + way. Preeny may offer a relatively simple option, too - see: + [https://github.com/zardus/preeny](https://github.com/zardus/preeny) + + Some useful tips for modifying network-based services can be also found at: + [https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop](https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop) + + - Occasionally, sentient machines rise against their creators. If this + happens to you, please consult [https://lcamtuf.coredump.cx/prep/](https://lcamtuf.coredump.cx/prep/). + +Beyond this, see [INSTALL.md](INSTALL.md) for platform-specific tips. diff --git a/docs/sister_projects.md b/docs/sister_projects.md deleted file mode 100644 index 613bc778..00000000 --- a/docs/sister_projects.md +++ /dev/null @@ -1,319 +0,0 @@ -# Sister projects - -This doc lists some of the projects that are inspired by, derived from, -designed for, or meant to integrate with AFL. See README.md for the general -instruction manual. - -!!! -!!! This list is outdated and needs an update, missing: e.g. Angora, FairFuzz -!!! - -## Support for other languages / environments: - -### Python AFL (Jakub Wilk) - -Allows fuzz-testing of Python programs. Uses custom instrumentation and its -own forkserver. - -https://jwilk.net/software/python-afl - -### Go-fuzz (Dmitry Vyukov) - -AFL-inspired guided fuzzing approach for Go targets: - -https://github.com/dvyukov/go-fuzz - -### afl.rs (Keegan McAllister) - -Allows Rust features to be easily fuzzed with AFL (using the LLVM mode). - -https://github.com/kmcallister/afl.rs - -### OCaml support (KC Sivaramakrishnan) - -Adds AFL-compatible instrumentation to OCaml programs. - -https://github.com/ocamllabs/opam-repo-dev/pull/23 -https://canopy.mirage.io/Posts/Fuzzing - -### AFL for GCJ Java and other GCC frontends (-) - -GCC Java programs are actually supported out of the box - simply rename -afl-gcc to afl-gcj. Unfortunately, by default, unhandled exceptions in GCJ do -not result in abort() being called, so you will need to manually add a -top-level exception handler that exits with SIGABRT or something equivalent. - -Other GCC-supported languages should be fairly easy to get working, but may -face similar problems. See https://gcc.gnu.org/frontends.html for a list of -options. - -## AFL-style in-process fuzzer for LLVM (Kostya Serebryany) - -Provides an evolutionary instrumentation-guided fuzzing harness that allows -some programs to be fuzzed without the fork / execve overhead. (Similar -functionality is now available as the "persistent" feature described in -[the llvm_mode readme](../instrumentation/README.llvm.md)) - -https://llvm.org/docs/LibFuzzer.html - -## TriforceAFL (Tim Newsham and Jesse Hertz) - -Leverages QEMU full system emulation mode to allow AFL to target operating -systems and other alien worlds: - -https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/ - -## WinAFL (Ivan Fratric) - -As the name implies, allows you to fuzz Windows binaries (using DynamoRio). - -https://github.com/ivanfratric/winafl - -Another Windows alternative may be: - -https://github.com/carlosgprado/BrundleFuzz/ - -## Network fuzzing - -### Preeny (Yan Shoshitaishvili) - -Provides a fairly simple way to convince dynamically linked network-centric -programs to read from a file or not fork. Not AFL-specific, but described as -useful by many users. Some assembly required. - -https://github.com/zardus/preeny - -## Distributed fuzzing and related automation - -### roving (Richo Healey) - -A client-server architecture for effortlessly orchestrating AFL runs across -a fleet of machines. You don't want to use this on systems that face the -Internet or live in other untrusted environments. - -https://github.com/richo/roving - -### Distfuzz-AFL (Martijn Bogaard) - -Simplifies the management of afl-fuzz instances on remote machines. The -author notes that the current implementation isn't secure and should not -be exposed on the Internet. - -https://github.com/MartijnB/disfuzz-afl - -### AFLDFF (quantumvm) - -A nice GUI for managing AFL jobs. - -https://github.com/quantumvm/AFLDFF - -### afl-launch (Ben Nagy) - -Batch AFL launcher utility with a simple CLI. - -https://github.com/bnagy/afl-launch - -### AFL Utils (rc0r) - -Simplifies the triage of discovered crashes, start parallel instances, etc. - -https://github.com/rc0r/afl-utils - -### AFL crash analyzer (floyd) - -Another crash triage tool: - -https://github.com/floyd-fuh/afl-crash-analyzer - -### afl-extras (fekir) - -Collect data, parallel afl-tmin, startup scripts. - -https://github.com/fekir/afl-extras - -### afl-fuzzing-scripts (Tobias Ospelt) - -Simplifies starting up multiple parallel AFL jobs. - -https://github.com/floyd-fuh/afl-fuzzing-scripts/ - -### afl-sid (Jacek Wielemborek) - -Allows users to more conveniently build and deploy AFL via Docker. - -https://github.com/d33tah/afl-sid - -Another Docker-related project: - -https://github.com/ozzyjohnson/docker-afl - -### afl-monitor (Paul S. Ziegler) - -Provides more detailed and versatile statistics about your running AFL jobs. - -https://github.com/reflare/afl-monitor - -### FEXM (Security in Telecommunications) - -Fully automated fuzzing framework, based on AFL - -https://github.com/fgsect/fexm - -## Crash triage, coverage analysis, and other companion tools: - -### afl-crash-analyzer (Tobias Ospelt) - -Makes it easier to navigate and annotate crashing test cases. - -https://github.com/floyd-fuh/afl-crash-analyzer/ - -### Crashwalk (Ben Nagy) - -AFL-aware tool to annotate and sort through crashing test cases. - -https://github.com/bnagy/crashwalk - -### afl-cov (Michael Rash) - -Produces human-readable coverage data based on the output queue of afl-fuzz. - -https://github.com/mrash/afl-cov - -### afl-sancov (Bhargava Shastry) - -Similar to afl-cov, but uses clang sanitizer instrumentation. - -https://github.com/bshastry/afl-sancov - -### RecidiVM (Jakub Wilk) - -Makes it easy to estimate memory usage limits when fuzzing with ASAN or MSAN. - -https://jwilk.net/software/recidivm - -### aflize (Jacek Wielemborek) - -Automatically build AFL-enabled versions of Debian packages. - -https://github.com/d33tah/aflize - -### afl-ddmin-mod (Markus Teufelberger) - -A variant of afl-tmin that uses a more sophisticated (but slower) -minimization algorithm. - -https://github.com/MarkusTeufelberger/afl-ddmin-mod - -### afl-kit (Kuang-che Wu) - -Replacements for afl-cmin and afl-tmin with additional features, such -as the ability to filter crashes based on stderr patterns. - -https://github.com/kcwu/afl-kit - -## Narrow-purpose or experimental: - -### Cygwin support (Ali Rizvi-Santiago) - -Pretty self-explanatory. As per the author, this "mostly" ports AFL to -Windows. Field reports welcome! - -https://github.com/arizvisa/afl-cygwin - -### Pause and resume scripts (Ben Nagy) - -Simple automation to suspend and resume groups of fuzzing jobs. - -https://github.com/bnagy/afl-trivia - -### Static binary-only instrumentation (Aleksandar Nikolich) - -Allows black-box binaries to be instrumented statically (i.e., by modifying -the binary ahead of the time, rather than translating it on the run). Author -reports better performance compared to QEMU, but occasional translation -errors with stripped binaries. - -https://github.com/vanhauser-thc/afl-dyninst - -### AFL PIN (Parker Thompson) - -Early-stage Intel PIN instrumentation support (from before we settled on -faster-running QEMU). - -https://github.com/mothran/aflpin - -### AFL-style instrumentation in llvm (Kostya Serebryany) - -Allows AFL-equivalent instrumentation to be injected at compiler level. -This is currently not supported by AFL as-is, but may be useful in other -projects. - -https://code.google.com/p/address-sanitizer/wiki/AsanCoverage#Coverage_counters - -### AFL JS (Han Choongwoo) - -One-off optimizations to speed up the fuzzing of JavaScriptCore (now likely -superseded by LLVM deferred forkserver init - see README.llvm.md). - -https://github.com/tunz/afl-fuzz-js - -### AFL harness for fwknop (Michael Rash) - -An example of a fairly involved integration with AFL. - -https://github.com/mrash/fwknop/tree/master/test/afl - -### Building harnesses for DNS servers (Jonathan Foote, Ron Bowes) - -Two articles outlining the general principles and showing some example code. - -https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop -https://goo.gl/j9EgFf - -### Fuzzer shell for SQLite (Richard Hipp) - -A simple SQL shell designed specifically for fuzzing the underlying library. - -https://www.sqlite.org/src/artifact/9e7e273da2030371 - -### Support for Python mutation modules (Christian Holler) - -now integrated in AFL++, originally from here -https://github.com/choller/afl/blob/master/docs/mozilla/python_modules.txt - -### Support for selective instrumentation (Christian Holler) - -now integrated in AFL++, originally from here -https://github.com/choller/afl/blob/master/docs/mozilla/partial_instrumentation.txt - -### Syzkaller (Dmitry Vyukov) - -A similar guided approach as applied to fuzzing syscalls: - -https://github.com/google/syzkaller/wiki/Found-Bugs -https://github.com/dvyukov/linux/commit/33787098ffaaa83b8a7ccf519913ac5fd6125931 -https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf - - -### Kernel Snapshot Fuzzing using Unicornafl (Security in Telecommunications) - -https://github.com/fgsect/unicorefuzz - -### Android support (ele7enxxh) - -Based on a somewhat dated version of AFL: - -https://github.com/ele7enxxh/android-afl - -### CGI wrapper (floyd) - -Facilitates the testing of CGI scripts. - -https://github.com/floyd-fuh/afl-cgi-wrapper - -### Fuzzing difficulty estimation (Marcel Boehme) - -A fork of AFL that tries to quantify the likelihood of finding additional -paths or crashes at any point in a fuzzing job. - -https://github.com/mboehme/pythia diff --git a/docs/third_party_tools.md b/docs/third_party_tools.md new file mode 100644 index 00000000..ba96d0ce --- /dev/null +++ b/docs/third_party_tools.md @@ -0,0 +1,33 @@ +# Tools that help fuzzing with AFL++ + +Speeding up fuzzing: + * [libfiowrapper](https://github.com/marekzmyslowski/libfiowrapper) - if the function you want to fuzz requires loading a file, this allows using the shared memory testcase feature :-) - recommended. + +Minimization of test cases: + * [afl-pytmin](https://github.com/ilsani/afl-pytmin) - a wrapper for afl-tmin that tries to speed up the process of minimization of a single test case by using many CPU cores. + * [afl-ddmin-mod](https://github.com/MarkusTeufelberger/afl-ddmin-mod) - a variation of afl-tmin based on the ddmin algorithm. + * [halfempty](https://github.com/googleprojectzero/halfempty) - is a fast utility for minimizing test cases by Tavis Ormandy based on parallelization. + +Distributed execution: + * [disfuzz-afl](https://github.com/MartijnB/disfuzz-afl) - distributed fuzzing for AFL. + * [AFLDFF](https://github.com/quantumvm/AFLDFF) - AFL distributed fuzzing framework. + * [afl-launch](https://github.com/bnagy/afl-launch) - a tool for the execution of many AFL instances. + * [afl-mothership](https://github.com/afl-mothership/afl-mothership) - management and execution of many synchronized AFL fuzzers on AWS cloud. + * [afl-in-the-cloud](https://github.com/abhisek/afl-in-the-cloud) - another script for running AFL in AWS. + +Deployment, management, monitoring, reporting + * [afl-utils](https://gitlab.com/rc0r/afl-utils) - a set of utilities for automatic processing/analysis of crashes and reducing the number of test cases. + * [afl-other-arch](https://github.com/shellphish/afl-other-arch) - is a set of patches and scripts for easily adding support for various non-x86 architectures for AFL. + * [afl-trivia](https://github.com/bnagy/afl-trivia) - a few small scripts to simplify the management of AFL. + * [afl-monitor](https://github.com/reflare/afl-monitor) - a script for monitoring AFL. + * [afl-manager](https://github.com/zx1340/afl-manager) - a web server on Python for managing multi-afl. + * [afl-remote](https://github.com/block8437/afl-remote) - a web server for the remote management of AFL instances. + * [afl-extras](https://github.com/fekir/afl-extras) - shell scripts to parallelize afl-tmin, startup, and data collection. + +Crash processing + * [afl-crash-analyzer](https://github.com/floyd-fuh/afl-crash-analyzer) - another crash analyzer for AFL. + * [fuzzer-utils](https://github.com/ThePatrickStar/fuzzer-utils) - a set of scripts for the analysis of results. + * [atriage](https://github.com/Ayrx/atriage) - a simple triage tool. + * [afl-kit](https://github.com/kcwu/afl-kit) - afl-cmin on Python. + * [AFLize](https://github.com/d33tah/aflize) - a tool that automatically generates builds of debian packages suitable for AFL. + * [afl-fid](https://github.com/FoRTE-Research/afl-fid) - a set of tools for working with input data. \ No newline at end of file diff --git a/docs/tools.md b/docs/tools.md deleted file mode 100644 index ba96d0ce..00000000 --- a/docs/tools.md +++ /dev/null @@ -1,33 +0,0 @@ -# Tools that help fuzzing with AFL++ - -Speeding up fuzzing: - * [libfiowrapper](https://github.com/marekzmyslowski/libfiowrapper) - if the function you want to fuzz requires loading a file, this allows using the shared memory testcase feature :-) - recommended. - -Minimization of test cases: - * [afl-pytmin](https://github.com/ilsani/afl-pytmin) - a wrapper for afl-tmin that tries to speed up the process of minimization of a single test case by using many CPU cores. - * [afl-ddmin-mod](https://github.com/MarkusTeufelberger/afl-ddmin-mod) - a variation of afl-tmin based on the ddmin algorithm. - * [halfempty](https://github.com/googleprojectzero/halfempty) - is a fast utility for minimizing test cases by Tavis Ormandy based on parallelization. - -Distributed execution: - * [disfuzz-afl](https://github.com/MartijnB/disfuzz-afl) - distributed fuzzing for AFL. - * [AFLDFF](https://github.com/quantumvm/AFLDFF) - AFL distributed fuzzing framework. - * [afl-launch](https://github.com/bnagy/afl-launch) - a tool for the execution of many AFL instances. - * [afl-mothership](https://github.com/afl-mothership/afl-mothership) - management and execution of many synchronized AFL fuzzers on AWS cloud. - * [afl-in-the-cloud](https://github.com/abhisek/afl-in-the-cloud) - another script for running AFL in AWS. - -Deployment, management, monitoring, reporting - * [afl-utils](https://gitlab.com/rc0r/afl-utils) - a set of utilities for automatic processing/analysis of crashes and reducing the number of test cases. - * [afl-other-arch](https://github.com/shellphish/afl-other-arch) - is a set of patches and scripts for easily adding support for various non-x86 architectures for AFL. - * [afl-trivia](https://github.com/bnagy/afl-trivia) - a few small scripts to simplify the management of AFL. - * [afl-monitor](https://github.com/reflare/afl-monitor) - a script for monitoring AFL. - * [afl-manager](https://github.com/zx1340/afl-manager) - a web server on Python for managing multi-afl. - * [afl-remote](https://github.com/block8437/afl-remote) - a web server for the remote management of AFL instances. - * [afl-extras](https://github.com/fekir/afl-extras) - shell scripts to parallelize afl-tmin, startup, and data collection. - -Crash processing - * [afl-crash-analyzer](https://github.com/floyd-fuh/afl-crash-analyzer) - another crash analyzer for AFL. - * [fuzzer-utils](https://github.com/ThePatrickStar/fuzzer-utils) - a set of scripts for the analysis of results. - * [atriage](https://github.com/Ayrx/atriage) - a simple triage tool. - * [afl-kit](https://github.com/kcwu/afl-kit) - afl-cmin on Python. - * [AFLize](https://github.com/d33tah/aflize) - a tool that automatically generates builds of debian packages suitable for AFL. - * [afl-fid](https://github.com/FoRTE-Research/afl-fid) - a set of tools for working with input data. \ No newline at end of file -- cgit 1.4.1 From 492dbe9fb294dec27e5c2bc7297b36526bb8e61f Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sun, 21 Nov 2021 18:00:01 +0100 Subject: Clean up docs folder --- README.md | 5 +- docs/FAQ.md | 5 +- docs/best_practices.md | 18 +++-- docs/parallel_fuzzing.md | 182 +++++++++++++++++++++++------------------------ qemu_mode/README.md | 5 +- 5 files changed, 109 insertions(+), 106 deletions(-) (limited to 'docs/best_practices.md') diff --git a/README.md b/README.md index b2714787..fcb6b3c9 100644 --- a/README.md +++ b/README.md @@ -132,9 +132,6 @@ The following branches exist: * [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. -For releases, please see the [Releases tab](https://github.com/AFLplusplus/AFLplusplus/releases). -Also take a look at the list of [important changes in AFL++](docs/important_changes.md). - ## Help wanted We have several [ideas](docs/ideas.md) we would like to see in AFL++ to make it @@ -233,4 +230,4 @@ presented at WOOT'20: } ``` -
+ \ No newline at end of file diff --git a/docs/FAQ.md b/docs/FAQ.md index 68ca3bad..34ed4cf5 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -83,7 +83,8 @@ If you find an interesting or important question missing, submit it via 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 [binaryonly_fuzzing.md](binaryonly_fuzzing.md). + To learn how these binaries can be fuzzed, read + [fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md).

@@ -143,7 +144,7 @@ If you find an interesting or important question missing, submit it via Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /prg/tmp/llvm-project/build/bin - clang-13: note: diagnostic msg: + clang-13: note: diagnostic msg: ******************** ``` diff --git a/docs/best_practices.md b/docs/best_practices.md index 7016f08d..5f2d45ed 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -4,20 +4,26 @@ ### Targets - * [Fuzzing a binary-only target](#fuzzing-a-binary-only-target) - * [Fuzzing a GUI program](#fuzzing-a-gui-program) - * [Fuzzing a network service](#fuzzing-a-network-service) +* [Fuzzing a target with source code available](#fuzzing-a-target-with-source-code-available) +* [Fuzzing a binary-only target](#fuzzing-a-binary-only-target) +* [Fuzzing a GUI program](#fuzzing-a-gui-program) +* [Fuzzing a network service](#fuzzing-a-network-service) ### Improvements - * [Improving speed](#improving-speed) - * [Improving stability](#improving-stability) +* [Improving speed](#improving-speed) +* [Improving stability](#improving-stability) ## Targets +### 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). + ### Fuzzing a binary-only target -For a comprehensive guide, see [binaryonly_fuzzing.md](binaryonly_fuzzing.md). +For a comprehensive guide, see +[fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md). ### Fuzzing a GUI program diff --git a/docs/parallel_fuzzing.md b/docs/parallel_fuzzing.md index d24f2837..130cb3ce 100644 --- a/docs/parallel_fuzzing.md +++ b/docs/parallel_fuzzing.md @@ -1,28 +1,28 @@ # Tips for parallel fuzzing -This document talks about synchronizing afl-fuzz jobs on a single machine -or across a fleet of systems. See README.md for the general instruction manual. +This document talks about synchronizing afl-fuzz jobs on a single machine or +across a fleet of systems. See README.md for the general instruction manual. Note that this document is rather outdated. please refer to the main document -section on multiple core usage [fuzzing_expert.md#Using multiple cores](fuzzing_expert.md#b-using-multiple-cores) +section on multiple core usage +[fuzzing_in_depth.md:b) Using multiple cores](fuzzing_in_depth.md#b-using-multiple-cores) for up to date strategies! ## 1) Introduction -Every copy of afl-fuzz will take up one CPU core. This means that on an -n-core system, you can almost always run around n concurrent fuzzing jobs with +Every copy of afl-fuzz will take up one CPU core. This means that on an n-core +system, you can almost always run around n concurrent fuzzing jobs with virtually no performance hit (you can use the afl-gotcpu tool to make sure). -In fact, if you rely on just a single job on a multi-core system, you will -be underutilizing the hardware. So, parallelization is always the right way to -go. +In fact, if you rely on just a single job on a multi-core system, you will be +underutilizing the hardware. So, parallelization is always the right way to go. When targeting multiple unrelated binaries or using the tool in "non-instrumented" (-n) mode, it is perfectly fine to just start up several -fully separate instances of afl-fuzz. The picture gets more complicated when -you want to have multiple fuzzers hammering a common target: if a hard-to-hit -but interesting test case is synthesized by one fuzzer, the remaining instances -will not be able to use that input to guide their work. +fully separate instances of afl-fuzz. The picture gets more complicated when you +want to have multiple fuzzers hammering a common target: if a hard-to-hit but +interesting test case is synthesized by one fuzzer, the remaining instances will +not be able to use that input to guide their work. To help with this problem, afl-fuzz offers a simple way to synchronize test cases on the fly. @@ -30,15 +30,15 @@ cases on the fly. It is a good idea to use different power schedules if you run several instances in parallel (`-p` option). -Alternatively running other AFL spinoffs in parallel can be of value, -e.g. Angora (https://github.com/AngoraFuzzer/Angora/) +Alternatively running other AFL spinoffs in parallel can be of value, e.g. +Angora (https://github.com/AngoraFuzzer/Angora/) ## 2) Single-system parallelization -If you wish to parallelize a single job across multiple cores on a local -system, simply create a new, empty output directory ("sync dir") that will be -shared by all the instances of afl-fuzz; and then come up with a naming scheme -for every instance - say, "fuzzer01", "fuzzer02", etc. +If you wish to parallelize a single job across multiple cores on a local system, +simply create a new, empty output directory ("sync dir") that will be shared by +all the instances of afl-fuzz; and then come up with a naming scheme for every +instance - say, "fuzzer01", "fuzzer02", etc. Run the first one ("main node", -M) like this: @@ -57,18 +57,18 @@ Each fuzzer will keep its state in a separate subdirectory, like so: /path/to/sync_dir/fuzzer01/ -Each instance will also periodically rescan the top-level sync directory -for any test cases found by other fuzzers - and will incorporate them into -its own fuzzing when they are deemed interesting enough. -For performance reasons only -M main node syncs the queue with everyone, the --S secondary nodes will only sync from the main node. +Each instance will also periodically rescan the top-level sync directory for any +test cases found by other fuzzers - and will incorporate them into its own +fuzzing when they are deemed interesting enough. For performance reasons only -M +main node syncs the queue with everyone, the -S secondary nodes will only sync +from the main node. -The difference between the -M and -S modes is that the main instance will -still perform deterministic checks; while the secondary instances will -proceed straight to random tweaks. +The difference between the -M and -S modes is that the main instance will still +perform deterministic checks; while the secondary instances will proceed +straight to random tweaks. -Note that you must always have one -M main instance! -Running multiple -M instances is wasteful! +Note that you must always have one -M main instance! Running multiple -M +instances is wasteful! You can also monitor the progress of your jobs from the command line with the provided afl-whatsup tool. When the instances are no longer finding new paths, @@ -90,18 +90,18 @@ file name. ## 3) Multiple -M mains -There is support for parallelizing the deterministic checks. -This is only needed where +There is support for parallelizing the deterministic checks. This is only needed +where 1. many new paths are found fast over a long time and it looks unlikely that main node will ever catch up, and 2. deterministic fuzzing is actively helping path discovery (you can see this in the main node for the first for lines in the "fuzzing strategy yields" - section. If the ration `found/attemps` is high, then it is effective. It + section. If the ration `found/attempts` is high, then it is effective. It most commonly isn't.) -Only if both are true it is beneficial to have more than one main. -You can leverage this by creating -M instances like so: +Only if both are true it is beneficial to have more than one main. You can +leverage this by creating -M instances like so: ``` ./afl-fuzz -i testcase_dir -o sync_dir -M mainA:1/3 [...] @@ -115,27 +115,26 @@ distribute the deterministic fuzzing across. Note that if you boot up fewer fuzzers than indicated by the second number passed to -M, you may end up with poor coverage. -## 4) Syncing with non-AFL fuzzers or independant instances +## 4) Syncing with non-AFL fuzzers or independent instances -A -M main node can be told with the `-F other_fuzzer_queue_directory` option -to sync results from other fuzzers, e.g. libfuzzer or honggfuzz. +A -M main node can be told with the `-F other_fuzzer_queue_directory` option to +sync results from other fuzzers, e.g. libfuzzer or honggfuzz. -Only the specified directory will by synced into afl, not subdirectories. -The specified directory does not need to exist yet at the start of afl. +Only the specified directory will by synced into afl, not subdirectories. The +specified directory does not need to exist yet at the start of afl. The `-F` option can be passed to the main node several times. ## 5) Multi-system parallelization -The basic operating principle for multi-system parallelization is similar to -the mechanism explained in section 2. The key difference is that you need to -write a simple script that performs two actions: +The basic operating principle for multi-system parallelization is similar to the +mechanism explained in section 2. The key difference is that you need to write a +simple script that performs two actions: - - Uses SSH with authorized_keys to connect to every machine and retrieve - a tar archive of the /path/to/sync_dir/ directory local to - the machine. - It is best to use a naming scheme that includes host name and it's being - a main node (e.g. main1, main2) in the fuzzer ID, so that you can do + - Uses SSH with authorized_keys to connect to every machine and retrieve a tar + archive of the /path/to/sync_dir/ directory local to the + machine. It is best to use a naming scheme that includes host name and it's + being a main node (e.g. main1, main2) in the fuzzer ID, so that you can do something like: ```sh @@ -163,70 +162,70 @@ There are other (older) more featured, experimental tools: However these do not support syncing just main nodes (yet). -When developing custom test case sync code, there are several optimizations -to keep in mind: +When developing custom test case sync code, there are several optimizations to +keep in mind: - - The synchronization does not have to happen very often; running the - task every 60 minutes or even less often at later fuzzing stages is - fine + - The synchronization does not have to happen very often; running the task + every 60 minutes or even less often at later fuzzing stages is fine - - There is no need to synchronize crashes/ or hangs/; you only need to - copy over queue/* (and ideally, also fuzzer_stats). + - There is no need to synchronize crashes/ or hangs/; you only need to copy + over queue/* (and ideally, also fuzzer_stats). - - It is not necessary (and not advisable!) to overwrite existing files; - the -k option in tar is a good way to avoid that. + - It is not necessary (and not advisable!) to overwrite existing files; the -k + option in tar is a good way to avoid that. - There is no need to fetch directories for fuzzers that are not running locally on a particular machine, and were simply copied over onto that system during earlier runs. - - For large fleets, you will want to consolidate tarballs for each host, - as this will let you use n SSH connections for sync, rather than n*(n-1). + - For large fleets, you will want to consolidate tarballs for each host, as + this will let you use n SSH connections for sync, rather than n*(n-1). You may also want to implement staged synchronization. For example, you - could have 10 groups of systems, with group 1 pushing test cases only - to group 2; group 2 pushing them only to group 3; and so on, with group + could have 10 groups of systems, with group 1 pushing test cases only to + group 2; group 2 pushing them only to group 3; and so on, with group eventually 10 feeding back to group 1. - This arrangement would allow test interesting cases to propagate across - the fleet without having to copy every fuzzer queue to every single host. + This arrangement would allow test interesting cases to propagate across the + fleet without having to copy every fuzzer queue to every single host. - You do not want a "main" instance of afl-fuzz on every system; you should run them all with -S, and just designate a single process somewhere within the fleet to run with -M. - - Syncing is only necessary for the main nodes on a system. It is possible - to run main-less with only secondaries. However then you need to find out - which secondary took over the temporary role to be the main node. Look for - the `is_main_node` file in the fuzzer directories, eg. `sync-dir/hostname-*/is_main_node` + - Syncing is only necessary for the main nodes on a system. It is possible to + run main-less with only secondaries. However then you need to find out which + secondary took over the temporary role to be the main node. Look for the + `is_main_node` file in the fuzzer directories, eg. + `sync-dir/hostname-*/is_main_node` It is *not* advisable to skip the synchronization script and run the fuzzers -directly on a network filesystem; unexpected latency and unkillable processes -in I/O wait state can mess things up. +directly on a network filesystem; unexpected latency and unkillable processes in +I/O wait state can mess things up. ## 6) Remote monitoring and data collection -You can use screen, nohup, tmux, or something equivalent to run remote -instances of afl-fuzz. If you redirect the program's output to a file, it will +You can use screen, nohup, tmux, or something equivalent to run remote instances +of afl-fuzz. If you redirect the program's output to a file, it will automatically switch from a fancy UI to more limited status reports. There is also basic machine-readable information which is always written to the fuzzer_stats file in the output directory. Locally, that information can be interpreted with afl-whatsup. -In principle, you can use the status screen of the main (-M) instance to -monitor the overall fuzzing progress and decide when to stop. In this -mode, the most important signal is just that no new paths are being found -for a longer while. If you do not have a main instance, just pick any -single secondary instance to watch and go by that. +In principle, you can use the status screen of the main (-M) instance to monitor +the overall fuzzing progress and decide when to stop. In this mode, the most +important signal is just that no new paths are being found for a longer while. +If you do not have a main instance, just pick any single secondary instance to +watch and go by that. -You can also rely on that instance's output directory to collect the -synthesized corpus that covers all the noteworthy paths discovered anywhere -within the fleet. Secondary (-S) instances do not require any special -monitoring, other than just making sure that they are up. +You can also rely on that instance's output directory to collect the synthesized +corpus that covers all the noteworthy paths discovered anywhere within the +fleet. Secondary (-S) instances do not require any special monitoring, other +than just making sure that they are up. -Keep in mind that crashing inputs are *not* automatically propagated to the -main instance, so you may still want to monitor for crashes fleet-wide -from within your synchronization or health checking scripts (see afl-whatsup). +Keep in mind that crashing inputs are *not* automatically propagated to the main +instance, so you may still want to monitor for crashes fleet-wide from within +your synchronization or health checking scripts (see afl-whatsup). ## 7) Asymmetric setups @@ -238,21 +237,20 @@ It is perhaps worth noting that all of the following is permitted: out_dir//queue/* and writing their own finds to sequentially numbered id:nnnnnn files in out_dir//queue/*. - - Running some of the synchronized fuzzers with different (but related) - target binaries. For example, simultaneously stress-testing several - different JPEG parsers (say, IJG jpeg and libjpeg-turbo) while sharing - the discovered test cases can have synergistic effects and improve the - overall coverage. + - Running some of the synchronized fuzzers with different (but related) target + binaries. For example, simultaneously stress-testing several different JPEG + parsers (say, IJG jpeg and libjpeg-turbo) while sharing the discovered test + cases can have synergistic effects and improve the overall coverage. (In this case, running one -M instance per target is necessary.) - - Having some of the fuzzers invoke the binary in different ways. - For example, 'djpeg' supports several DCT modes, configurable with - a command-line flag, while 'dwebp' supports incremental and one-shot - decoding. In some scenarios, going after multiple distinct modes and then - pooling test cases will improve coverage. + - Having some of the fuzzers invoke the binary in different ways. For example, + 'djpeg' supports several DCT modes, configurable with a command-line flag, + while 'dwebp' supports incremental and one-shot decoding. In some scenarios, + going after multiple distinct modes and then pooling test cases will improve + coverage. - Much less convincingly, running the synchronized fuzzers with different starting test cases (e.g., progressive and standard JPEG) or dictionaries. The synchronization mechanism ensures that the test sets will get fairly - homogeneous over time, but it introduces some initial variability. + homogeneous over time, but it introduces some initial variability. \ No newline at end of file diff --git a/qemu_mode/README.md b/qemu_mode/README.md index d28479d9..c62309a2 100644 --- a/qemu_mode/README.md +++ b/qemu_mode/README.md @@ -217,5 +217,6 @@ them at run time, can be a faster alternative. That said, static rewriting is fraught with peril, because it depends on being able to properly and fully model program control flow without actually executing each and every code path. -Checkout the "Fuzzing binary-only targets" section in our main README.md and -the docs/binaryonly_fuzzing.md document for more information and hints. +Check out +[docs/fuzzing_binary-only_targets.md](../docs/fuzzing_binary-only_targets.md) +for more information and hints. -- cgit 1.4.1 From fce93647cc788683be3d8cca79c4689de4b71c3f Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Wed, 24 Nov 2021 13:24:12 +0100 Subject: Merge "perf_tips.md" into "best_practices.md" and "fuzzing_in_depth.md" --- docs/best_practices.md | 4 +- docs/fuzzing_in_depth.md | 46 +++++++---- docs/perf_tips.md | 209 ----------------------------------------------- 3 files changed, 32 insertions(+), 227 deletions(-) delete mode 100644 docs/perf_tips.md (limited to 'docs/best_practices.md') diff --git a/docs/best_practices.md b/docs/best_practices.md index 5f2d45ed..979849f4 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -64,11 +64,11 @@ which allows you to define network state with different type of data packets. 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. Use the [AFL++ snapshot module](https://github.com/AFLplusplus/AFL-Snapshot-LKM) (x2 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:b) Using multiple cores](fuzzing_in_depth.md#b-using-multiple-cores))! +7. Use your cores ([fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores))! ### Improving stability diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 2365c6fd..869ed212 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -419,7 +419,7 @@ 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): +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. @@ -438,11 +438,6 @@ If you need to stop and re-start the fuzzing, use the same command line options mode!) and switch the input directory with a dash (`-`): `afl-fuzz -i - -o output -- bin/target -d @@` -Memory limits are not enforced by afl-fuzz by default and the system may run out -of memory. You can decrease the memory with the `-m` option, the value is in MB. -If this is too small for the target, you can usually see this by afl-fuzz -bailing with the message that it could not connect to the forkserver. - Adding a dictionary is helpful. See the directory [dictionaries/](../dictionaries/) if something is already included for your data format, and tell afl-fuzz to load that dictionary by adding `-x @@ -472,7 +467,26 @@ is: All labels are explained in [status_screen.md](status_screen.md). -#### b) Using multiple cores +#### b) Keeping memory use and timeouts in check + +Memory limits are not enforced by afl-fuzz by default and the system may run out +of memory. You can decrease the memory with the `-m` option, the value is in MB. +If this is too small for the target, you can usually see this by afl-fuzz +bailing with the message that it could not connect to the forkserver. + +Consider setting low values for `-m` and `-t`. + +For programs that are nominally very fast, but get sluggish for some inputs, you +can also try setting `-t` values that are more punishing than what `afl-fuzz` +dares to use on its own. On fast and idle machines, going down to `-t 5` may be +a viable plan. + +The `-m` parameter is worth looking at, too. Some programs can end up spending a +fair amount of time allocating and initializing megabytes of memory when +presented with pathological inputs. Low `-m` values can make them give up sooner +and not waste CPU time. + +#### c) Using multiple cores If you want to seriously fuzz then use as many cores/threads as possible to fuzz your target. @@ -537,7 +551,7 @@ directory of a different fuzzer is, e.g. `-F /src/target/honggfuzz`. Using honggfuzz (with `-n 1` or `-n 2`) and libfuzzer in parallel is highly recommended! -#### c) Using multiple machines for fuzzing +#### d) Using multiple machines for fuzzing Maybe you have more than one machine you want to fuzz the same target on. Simply start the `afl-fuzz` (and perhaps libfuzzer, honggfuzz, ...) @@ -575,7 +589,7 @@ done You can run this manually, per cron job - as you need it. There is a more complex and configurable script in `utils/distributed_fuzzing`. -#### d) The status of the fuzz campaign +#### e) The status of the fuzz campaign AFL++ comes with the `afl-whatsup` script to show the status of the fuzzing campaign. @@ -593,7 +607,7 @@ afl-plot, which generates an index.html file and a graphs that show how the fuzzing instance is performing. The syntax is `afl-plot instance_dir web_dir`, e.g., `afl-plot out/default /srv/www/htdocs/plot`. -#### e) Stopping fuzzing, restarting fuzzing, adding new seeds +#### f) Stopping fuzzing, restarting fuzzing, adding new seeds To stop an afl-fuzz run, simply press Control-C. @@ -608,7 +622,7 @@ are in `newseeds/` directory: AFL_BENCH_JUST_ONE=1 AFL_FAST_CAL=1 afl-fuzz -i newseeds -o out -S newseeds -- ./target ``` -#### f) Checking the coverage of the fuzzing +#### g) Checking the coverage of the fuzzing The `paths found` value is a bad indicator for checking how good the coverage is. @@ -648,7 +662,7 @@ individual fuzzing campaigns each with one of these options set. E.g., if you fuzz a library to convert image formats and your target is the png to tiff API then you will not touch any of the other library APIs and features. -#### g) How long to fuzz a target? +#### h) How long to fuzz a target? This is a difficult question. Basically if no new path is found for a long time (e.g. for a day or a week) then you can expect that your fuzzing won't be @@ -660,7 +674,7 @@ Keep the queue/ directory (for future fuzzings of the same or similar targets) and use them to seed other good fuzzers like libfuzzer with the -entropic switch or honggfuzz. -#### h) Improve the speed! +#### i) Improve the speed! * Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 speed increase) @@ -675,11 +689,11 @@ or honggfuzz. also just run `sudo afl-persistent-config` * Linux: Running on an `ext2` filesystem with `noatime` mount option will be a bit faster than on any other journaling filesystem -* Use your cores! [b) Using multiple cores](#b-using-multiple-cores) +* Use your cores! [3c) Using multiple cores](#c-using-multiple-cores) * Run `sudo afl-system-config` before starting the first afl-fuzz instance after a reboot -#### i) Going beyond crashes +#### j) Going beyond crashes Fuzzing is a wonderful and underutilized technique for discovering non-crashing design and implementation errors, too. Quite a few interesting bugs have been @@ -703,7 +717,7 @@ conditional with `#ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` (a flag also shared with libfuzzer and honggfuzz) or `#ifdef __AFL_COMPILER` (this one is just for AFL++). -#### j) Known limitations & areas for improvement +#### k) Known limitations & areas for improvement Here are some of the most important caveats for AFL++: diff --git a/docs/perf_tips.md b/docs/perf_tips.md deleted file mode 100644 index 1e8fd4d0..00000000 --- a/docs/perf_tips.md +++ /dev/null @@ -1,209 +0,0 @@ -## Tips for performance optimization - - This file provides tips for troubleshooting slow or wasteful fuzzing jobs. - See README.md for the general instruction manual. - -## 1. Keep your test cases small - -This is probably the single most important step to take! Large test cases do -not merely take more time and memory to be parsed by the tested binary, but -also make the fuzzing process dramatically less efficient in several other -ways. - -To illustrate, let's say that you're randomly flipping bits in a file, one bit -at a time. Let's assume that if you flip bit #47, you will hit a security bug; -flipping any other bit just results in an invalid document. - -Now, if your starting test case is 100 bytes long, you will have a 71% chance of -triggering the bug within the first 1,000 execs - not bad! But if the test case -is 1 kB long, the probability that we will randomly hit the right pattern in -the same timeframe goes down to 11%. And if it has 10 kB of non-essential -cruft, the odds plunge to 1%. - -On top of that, with larger inputs, the binary may be now running 5-10x times -slower than before - so the overall drop in fuzzing efficiency may be easily -as high as 500x or so. - -In practice, this means that you shouldn't fuzz image parsers with your -vacation photos. Generate a tiny 16x16 picture instead, and run it through -`jpegtran` or `pngcrunch` for good measure. The same goes for most other types -of documents. - -There's plenty of small starting test cases in ../testcases/ - try them out -or submit new ones! - -If you want to start with a larger, third-party corpus, run `afl-cmin` with an -aggressive timeout on that data set first. - -## 2. Use a simpler target - -Consider using a simpler target binary in your fuzzing work. For example, for -image formats, bundled utilities such as `djpeg`, `readpng`, or `gifhisto` are -considerably (10-20x) faster than the convert tool from ImageMagick - all while exercising roughly the same library-level image parsing code. - -Even if you don't have a lightweight harness for a particular target, remember -that you can always use another, related library to generate a corpus that will -be then manually fed to a more resource-hungry program later on. - -Also note that reading the fuzzing input via stdin is faster than reading from -a file. - -## 3. Use LLVM persistent instrumentation - -The LLVM mode offers a "persistent", in-process fuzzing mode that can -work well for certain types of self-contained libraries, and for fast targets, -can offer performance gains up to 5-10x; and a "deferred fork server" mode -that can offer huge benefits for programs with high startup overhead. Both -modes require you to edit the source code of the fuzzed program, but the -changes often amount to just strategically placing a single line or two. - -If there are important data comparisons performed (e.g. `strcmp(ptr, MAGIC_HDR)`) -then using laf-intel (see instrumentation/README.laf-intel.md) will help `afl-fuzz` a lot -to get to the important parts in the code. - -If you are only interested in specific parts of the code being fuzzed, you can -instrument_files the files that are actually relevant. This improves the speed and -accuracy of afl. See instrumentation/README.instrument_list.md - -## 4. Profile and optimize the binary - -Check for any parameters or settings that obviously improve performance. For -example, the djpeg utility that comes with IJG jpeg and libjpeg-turbo can be -called with: - -```bash - -dct fast -nosmooth -onepass -dither none -scale 1/4 -``` - -...and that will speed things up. There is a corresponding drop in the quality -of decoded images, but it's probably not something you care about. - -In some programs, it is possible to disable output altogether, or at least use -an output format that is computationally inexpensive. For example, with image -transcoding tools, converting to a BMP file will be a lot faster than to PNG. - -With some laid-back parsers, enabling "strict" mode (i.e., bailing out after -first error) may result in smaller files and improved run time without -sacrificing coverage; for example, for sqlite, you may want to specify -bail. - -If the program is still too slow, you can use `strace -tt` or an equivalent -profiling tool to see if the targeted binary is doing anything silly. -Sometimes, you can speed things up simply by specifying `/dev/null` as the -config file, or disabling some compile-time features that aren't really needed -for the job (try `./configure --help`). One of the notoriously resource-consuming -things would be calling other utilities via `exec*()`, `popen()`, `system()`, or -equivalent calls; for example, tar can invoke external decompression tools -when it decides that the input file is a compressed archive. - -Some programs may also intentionally call `sleep()`, `usleep()`, or `nanosleep()`; -vim is a good example of that. Other programs may attempt `fsync()` and so on. -There are third-party libraries that make it easy to get rid of such code, -e.g.: - - https://launchpad.net/libeatmydata - -In programs that are slow due to unavoidable initialization overhead, you may -want to try the LLVM deferred forkserver mode (see README.llvm.md), -which can give you speed gains up to 10x, as mentioned above. - -Last but not least, if you are using ASAN and the performance is unacceptable, -consider turning it off for now, and manually examining the generated corpus -with an ASAN-enabled binary later on. - -## 5. Instrument just what you need - -Instrument just the libraries you actually want to stress-test right now, one -at a time. Let the program use system-wide, non-instrumented libraries for -any functionality you don't actually want to fuzz. For example, in most -cases, it doesn't make to instrument `libgmp` just because you're testing a -crypto app that relies on it for bignum math. - -Beware of programs that come with oddball third-party libraries bundled with -their source code (Spidermonkey is a good example of this). Check `./configure` -options to use non-instrumented system-wide copies instead. - -## 6. Parallelize your fuzzers - -The fuzzer is designed to need ~1 core per job. This means that on a, say, -4-core system, you can easily run four parallel fuzzing jobs with relatively -little performance hit. For tips on how to do that, see parallel_fuzzing.md. - -The `afl-gotcpu` utility can help you understand if you still have idle CPU -capacity on your system. (It won't tell you about memory bandwidth, cache -misses, or similar factors, but they are less likely to be a concern.) - -## 7. Keep memory use and timeouts in check - -Consider setting low values for `-m` and `-t`. - -For programs that are nominally very fast, but get sluggish for some inputs, -you can also try setting `-t` values that are more punishing than what `afl-fuzz` -dares to use on its own. On fast and idle machines, going down to `-t 5` may be -a viable plan. - -The `-m` parameter is worth looking at, too. Some programs can end up spending -a fair amount of time allocating and initializing megabytes of memory when -presented with pathological inputs. Low `-m` values can make them give up sooner -and not waste CPU time. - -## 8. Check OS configuration - -There are several OS-level factors that may affect fuzzing speed: - - - If you have no risk of power loss then run your fuzzing on a tmpfs - partition. This increases the performance noticably. - Alternatively you can use `AFL_TMPDIR` to point to a tmpfs location to - just write the input file to a tmpfs. - - High system load. Use idle machines where possible. Kill any non-essential - CPU hogs (idle browser windows, media players, complex screensavers, etc). - - Network filesystems, either used for fuzzer input / output, or accessed by - the fuzzed binary to read configuration files (pay special attention to the - home directory - many programs search it for dot-files). - - Disable all the spectre, meltdown etc. security countermeasures in the - kernel if your machine is properly separated: - -``` -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 -``` - In most Linux distributions you can put this into a `/etc/default/grub` - variable. - You can use `sudo afl-persistent-config` to set these options for you. - -The following list of changes are made when executing `afl-system-config`: - - - On-demand CPU scaling. The Linux `ondemand` governor performs its analysis - on a particular schedule and is known to underestimate the needs of - short-lived processes spawned by `afl-fuzz` (or any other fuzzer). On Linux, - this can be fixed with: - -``` bash - cd /sys/devices/system/cpu - echo performance | tee cpu*/cpufreq/scaling_governor -``` - - On other systems, the impact of CPU scaling will be different; when fuzzing, - use OS-specific tools to find out if all cores are running at full speed. - - Transparent huge pages. Some allocators, such as `jemalloc`, can incur a - heavy fuzzing penalty when transparent huge pages (THP) are enabled in the - kernel. You can disable this via: - -```bash - echo never > /sys/kernel/mm/transparent_hugepage/enabled -``` - - - Suboptimal scheduling strategies. The significance of this will vary from - one target to another, but on Linux, you may want to make sure that the - following options are set: - -```bash - echo 1 >/proc/sys/kernel/sched_child_runs_first - echo 1 >/proc/sys/kernel/sched_autogroup_enabled -``` - - Setting a different scheduling policy for the fuzzer process - say - `SCHED_RR` - can usually speed things up, too, but needs to be done with - care. - -- cgit 1.4.1 From a7694e299a331bd8c4826b2402ee68cd6f83d8f9 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 20:45:48 +0100 Subject: Fix punctuation in connection with "however" --- docs/FAQ.md | 10 +++++++--- docs/best_practices.md | 27 ++++++++++++++++++--------- docs/custom_mutators.md | 10 +++++----- docs/fuzzing_in_depth.md | 10 +++++----- docs/important_changes.md | 4 ++-- instrumentation/README.llvm.md | 11 ++++++----- qemu_mode/README.persistent.md | 8 ++++---- qemu_mode/libcompcov/README.md | 8 ++++---- utils/afl_network_proxy/README.md | 13 +++++++------ utils/afl_untracer/README.md | 6 +++--- 10 files changed, 61 insertions(+), 46 deletions(-) (limited to 'docs/best_practices.md') diff --git a/docs/FAQ.md b/docs/FAQ.md index ae4a77dc..49444999 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -12,7 +12,9 @@ If you find an interesting or important question missing, submit it via 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. + 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. @@ -121,8 +123,10 @@ If you find an interesting or important question missing, submit it via 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 accross runs. - Those edges that change are then flagged "unstable". + 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 accross runs. Those edges that + change are then flagged "unstable". The more "unstable" edges, the more difficult for AFL++ to identify valid new paths. diff --git a/docs/best_practices.md b/docs/best_practices.md index 979849f4..15f8870c 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -54,9 +54,11 @@ to emulate the network. This is also much faster than the real network would be. See [utils/socket_fuzzing/](../utils/socket_fuzzing/). There is an outdated AFL++ branch that implements networking if you are -desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - -however a better option is AFLnet ([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) -which allows you to define network state with different type of data packets. +desperate though: +[https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) +- however, a better option is AFLnet +([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) which +allows you to define network state with different type of data packets. ## Improvements @@ -72,13 +74,16 @@ which allows you to define network state with different type of data packets. ### Improving stability -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. +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. -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. +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. @@ -116,8 +121,12 @@ Four steps are required to do this and it also requires quite some knowledge of 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) - Only exclude those functions from instrumentation that provide no value for coverage - that is if it does not process any fuzz data directly or indirectly (e.g. hash maps, thread management etc.). - If however a function directly or indirectly handles fuzz data, then you should not put the function in a deny instrumentation list and rather live with the instability it comes with. + Only exclude those functions from instrumentation that provide no value for + coverage - that is if it does not process any fuzz data directly or + indirectly (e.g. hash maps, thread management etc.). If, however, a + function directly or indirectly handles fuzz data, then you should not put + the function in a deny instrumentation list and rather live with the + instability it comes with. 4. Recompile the target diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 4018d633..fc5ecbf9 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -112,11 +112,11 @@ def deinit(): # optional for Python - `fuzz_count` (optional): - When a queue entry is selected to be fuzzed, afl-fuzz selects the number - of fuzzing attempts with this input based on a few factors. - If however the custom mutator wants to set this number instead on how often - it is called for a specific queue entry, use this function. - This function is most useful if `AFL_CUSTOM_MUTATOR_ONLY` is **not** used. + When a queue entry is selected to be fuzzed, afl-fuzz selects the number of + fuzzing attempts with this input based on a few factors. If, however, the + custom mutator wants to set this number instead on how often it is called + for a specific queue entry, use this function. This function is most useful + if `AFL_CUSTOM_MUTATOR_ONLY` is **not** used. - `fuzz` (optional): diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 92b3cf86..96e709ab 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -131,8 +131,8 @@ The following options are available when you instrument with LTO mode have to compile the target twice, once specifically with/for this mode by setting `AFL_LLVM_CMPLOG=1`, and pass this binary to afl-fuzz via the `-c` parameter. Note that you can compile also just a cmplog binary and use that - for both however there will be a performance penality. You can read more about - this in + for both, however, there will be a performance penality. You can read more + about this in [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md). If you use LTO, LLVM or GCC_PLUGIN mode @@ -151,7 +151,7 @@ only instrument parts of the target that you are interested in: inlined and then would not match! See [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md) -There are many more options and modes available however these are most of the +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) @@ -369,8 +369,8 @@ This step is highly recommended! ### c) Minimizing all corpus files The shorter the input files that still traverse the same path within the target, -the better the fuzzing will be. This minimization is done with `afl-tmin` -however it is a long process as this has to be done for every file: +the better the fuzzing will be. This minimization is done with `afl-tmin`, +however, it is a long process as this has to be done for every file: ``` mkdir input diff --git a/docs/important_changes.md b/docs/important_changes.md index 726de64d..6cd00791 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -15,8 +15,8 @@ With AFL++ 3.15 we introduced the following changes from previous behaviors: With AFL++ 3.14 we introduced the following changes from previous behaviors: * afl-fuzz: deterministic fuzzing it not a default for -M main anymore - * afl-cmin/afl-showmap -i now descends into subdirectories (afl-cmin.bash - however does not) + * afl-cmin/afl-showmap -i now descends into subdirectories (afl-cmin.bash, + however, does not) With AFL++ 3.10 we introduced the following changes from previous behaviors: * The '+' feature of the '-t' option now means to auto-calculate the timeout diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 8133cbe4..d16049fa 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -106,9 +106,10 @@ either setting `AFL_CC_COMPILER=LLVM` or pass the parameter `--afl-llvm` via CFLAGS/CXXFLAGS/CPPFLAGS. The tool honors roughly the same environmental variables as afl-gcc (see -[docs/env_variables.md](../docs/env_variables.md)). This includes AFL_USE_ASAN, -AFL_HARDEN, and AFL_DONT_OPTIMIZE. However AFL_INST_RATIO is not honored as it -does not serve a good purpose with the more effective PCGUARD analysis. +[docs/env_variables.md](../docs/env_variables.md)). This includes +`AFL_USE_ASAN`, `AFL_HARDEN`, and `AFL_DONT_OPTIMIZE`. However, `AFL_INST_RATIO` +is not honored as it does not serve a good purpose with the more effective +PCGUARD analysis. ## 3) Options @@ -125,8 +126,8 @@ For splitting memcmp, strncmp, etc., see Then there are different ways of instrumenting the target: 1. An better instrumentation strategy uses LTO and link time instrumentation. - Note that not all targets can compile in this mode, however if it works it is - the best option you can use. To go with this option, use + Note that not all targets can compile in this mode, however, if it works it + is the best option you can use. To go with this option, use afl-clang-lto/afl-clang-lto++. See [README.lto.md](README.lto.md). 2. Alternatively you can choose a completely different coverage method: diff --git a/qemu_mode/README.persistent.md b/qemu_mode/README.persistent.md index 7210a8cc..ab45860d 100644 --- a/qemu_mode/README.persistent.md +++ b/qemu_mode/README.persistent.md @@ -17,10 +17,10 @@ The start of the persistent loop has to be set with environment variable `AFL_QEMU_PERSISTENT_ADDR`. This address can be the address of whatever instruction. Setting this address to -the start of a function makes the usage simple. If the address is however within -a function, either RET, OFFSET, or EXITS (see below in 2.2, 2.3, 2.6) have to be -set. This address (as well as the RET address, see below) has to be defined in -hexadecimal with the 0x prefix or as a decimal value. +the start of a function makes the usage simple. If the address is, however, +within a function, either RET, OFFSET, or EXITS (see below in 2.2, 2.3, 2.6) +have to be set. This address (as well as the RET address, see below) has to be +defined in hexadecimal with the 0x prefix or as a decimal value. If both RET and EXITS are not set, QEMU will assume that START points to a function and will patch the return address (on stack or in the link register) to diff --git a/qemu_mode/libcompcov/README.md b/qemu_mode/libcompcov/README.md index 6a72f5ff..50f0d802 100644 --- a/qemu_mode/libcompcov/README.md +++ b/qemu_mode/libcompcov/README.md @@ -18,7 +18,7 @@ and this module is not capable to log the coverage in this case. If you have the source code of the fuzzing target you should nto use this library and QEMU but build it with afl-clang-fast and the laf-intel options. -To use this library make sure to preload it with AFL_PRELOAD. +To use this library, make sure to preload it with AFL_PRELOAD. ``` export AFL_PRELOAD=/path/to/libcompcov.so @@ -32,6 +32,6 @@ Level 1 logs just comparison with immediates / read-only memory and level 2 logs all the comparisons. The library make use of https://github.com/ouadev/proc_maps_parser and so it is -Linux specific. However this is not a strict dependency, other UNIX operating -systems can be supported by replacing the code related to the -/proc/self/maps parsing. \ No newline at end of file +Linux specific. However, this is not a strict dependency, other UNIX operating +systems can be supported by replacing the code related to the /proc/self/maps +parsing. \ No newline at end of file diff --git a/utils/afl_network_proxy/README.md b/utils/afl_network_proxy/README.md index 05659c45..d2c00be2 100644 --- a/utils/afl_network_proxy/README.md +++ b/utils/afl_network_proxy/README.md @@ -34,16 +34,17 @@ afl-network-server -i 1111 -m 25M -t 1000 -- /bin/target -f @@ ### on the (afl-fuzz) main node -Just run afl-fuzz with your normal options, however the target should be +Just run afl-fuzz with your normal options, however, the target should be `afl-network-client` with the IP and PORT of the `afl-network-server` and increase the -t value: + ``` afl-fuzz -i in -o out -t 2000+ -- afl-network-client TARGET-IP 1111 ``` -Note the '+' on the -t parameter value. The afl-network-server will take -care of proper timeouts hence afl-fuzz should not. The '+' increases the -timeout and the value itself should be 500-1000 higher than the one on -afl-network-server. + +Note the '+' on the -t parameter value. The afl-network-server will take care of +proper timeouts hence afl-fuzz should not. The '+' increases the timeout and the +value itself should be 500-1000 higher than the one on afl-network-server. ### networking @@ -53,7 +54,7 @@ either. Note that also the outgoing interface can be specified with a '%' for Also make sure your default TCP window size is larger than your MAP_SIZE (130kb is a good value). -On Linux that is the middle value of `/proc/sys/net/ipv4/tcp_rmem` +On Linux that is the middle value of `/proc/sys/net/ipv4/tcp_rmem` ## how to compile and install diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md index ada0c916..9f41618f 100644 --- a/utils/afl_untracer/README.md +++ b/utils/afl_untracer/README.md @@ -5,9 +5,9 @@ afl-untracer is an example skeleton file which can easily be used to fuzz a closed source library. -It requires less memory and is x3-5 faster than qemu_mode however it is way -more course grained and does not provide interesting features like compcov -or cmplog. +It requires less memory and is x3-5 faster than qemu_mode, however, it is way +more course grained and does not provide interesting features like compcov or +cmplog. Supported is so far Intel (i386/x86_64) and AARCH64. -- cgit 1.4.1 From 65c3db86256b3907404623fe1c52e01c9d12ff97 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 21:03:59 +0100 Subject: Fix punctuation in connection with "e.g." --- .github/ISSUE_TEMPLATE/bug_report.md | 5 +++-- CONTRIBUTING.md | 2 +- docs/FAQ.md | 4 ++-- docs/INSTALL.md | 3 ++- docs/afl-fuzz_approach.md | 2 +- docs/best_practices.md | 4 ++-- docs/custom_mutators.md | 7 ++++--- docs/env_variables.md | 22 +++++++++++----------- docs/fuzzing_binary-only_targets.md | 6 +++--- docs/fuzzing_in_depth.md | 32 ++++++++++++++++---------------- docs/ideas.md | 2 +- docs/important_changes.md | 2 +- instrumentation/README.llvm.md | 2 +- instrumentation/README.lto.md | 2 +- utils/README.md | 2 +- utils/afl_network_proxy/README.md | 6 ++++-- 16 files changed, 54 insertions(+), 49 deletions(-) (limited to 'docs/best_practices.md') diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 31152cd2..0d80f4a3 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -8,8 +8,9 @@ assignees: '' --- **IMPORTANT** -1. You have verified that the issue to be present in the current `dev` branch -2. Please supply the command line options and relevant environment variables, e.g. a copy-paste of the contents of `out/default/fuzzer_setup` +1. You have verified that the issue to be present in the current `dev` branch. +2. Please supply the command line options and relevant environment variables, + e.g., a copy-paste of the contents of `out/default/fuzzer_setup`. Thank you for making AFL++ better! diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0268b2e5..0ab4f8ec 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -17,7 +17,7 @@ project, or added a file in a directory we already format, otherwise run: 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, ...). +(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 diff --git a/docs/FAQ.md b/docs/FAQ.md index 49444999..27250415 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -21,7 +21,7 @@ If you find an interesting or important question missing, submit it via 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). + 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).

@@ -123,7 +123,7 @@ If you find an interesting or important question missing, submit it via 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, + 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 accross runs. Those edges that change are then flagged "unstable". diff --git a/docs/INSTALL.md b/docs/INSTALL.md index ab6e735b..c1e22e36 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -69,7 +69,8 @@ These build options exist: * NO_PYTHON - disable python support * 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) +* LLVM_CONFIG - if your distro doesn't use the standard name for llvm-config + (e.g., Debian) e.g.: `make ASAN_BUILD=1` diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md index 242104f7..68f45891 100644 --- a/docs/afl-fuzz_approach.md +++ b/docs/afl-fuzz_approach.md @@ -504,7 +504,7 @@ directory. This includes: - `peak_rss_mb` - max rss usage reached during fuzzing in MB - `edges_found` - how many edges have been found - `var_byte_count` - how many edges are non-deterministic -- `afl_banner` - banner text (e.g. the target name) +- `afl_banner` - banner text (e.g., the target name) - `afl_version` - the version of AFL++ used - `target_mode` - default, persistent, qemu, unicorn, non-instrumented - `command_line` - full command line used for the fuzzing session diff --git a/docs/best_practices.md b/docs/best_practices.md index 15f8870c..6a406bde 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -48,7 +48,7 @@ this with persistent mode [instrumentation/README.persistent_mode.md](../instrum 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 +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 to emulate the network. This is also much faster than the real network would be. See [utils/socket_fuzzing/](../utils/socket_fuzzing/). @@ -123,7 +123,7 @@ Four steps are required to do this and it also requires quite some knowledge of Only exclude those functions from instrumentation that provide no value for coverage - that is if it does not process any fuzz data directly or - indirectly (e.g. hash maps, thread management etc.). If, however, a + indirectly (e.g., hash maps, thread management etc.). If, however, a function directly or indirectly handles fuzz data, then you should not put the function in a deny instrumentation list and rather live with the instability it comes with. diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index fc5ecbf9..6bee5413 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -124,7 +124,7 @@ def deinit(): # optional for Python 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. + so if you are using it, e.g., as a post processing library. Note that a length > 0 *must* be returned! - `describe` (optional): @@ -191,8 +191,9 @@ trimmed input. Here's a quick API description: This method is called at the start of each trimming operation and receives the initial buffer. It should return the amount of iteration steps possible - on this input (e.g. if your input has n elements and you want to remove them - one by one, return n, if you do a binary search, return log(n), and so on). + on this input (e.g., if your input has n elements and you want to remove + them one by one, return n, if you do a binary search, return log(n), and so + on). If your trimming algorithm doesn't allow to determine the amount of (remaining) steps easily (esp. while running), then you can alternatively diff --git a/docs/env_variables.md b/docs/env_variables.md index 715a60cb..771bf157 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -80,9 +80,9 @@ fairly broad use of environment variables instead: Setting `AFL_INST_RATIO` to 0 is a valid choice. This will instrument only the transitions between function entry points, but not individual branches. - Note that this is an outdated variable. A few instances (e.g. afl-gcc) still - support these, but state-of-the-art (e.g. LLVM LTO and LLVM PCGUARD) do not - need this. + Note that this is an outdated variable. A few instances (e.g., afl-gcc) + still support these, but state-of-the-art (e.g., LLVM LTO and LLVM PCGUARD) + do not need this. - `AFL_NO_BUILTIN` causes the compiler to generate code suitable for use with libtokencap.so (but perhaps running a bit slower than without the flag). @@ -319,7 +319,7 @@ checks or alter some of the more exotic semantics of the tool: afl-fuzz), setting `AFL_PYTHON_MODULE` to a Python module can also provide 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 + allows to configure custom mutators which can be very helpful, e.g., fuzzing XML or other highly flexible structured input. For details, see [custom_mutators.md](custom_mutators.md). @@ -449,7 +449,7 @@ checks or alter some of the more exotic semantics of the tool: not crash the target again when the test case is given. To be able to still re-trigger these crashes, you can use the `AFL_PERSISTENT_RECORD` variable with a value of how many previous fuzz cases to keep prio a crash. If set to - e.g. 10, then the 9 previous inputs are written to out/default/crashes as + e.g., 10, then the 9 previous inputs are written to out/default/crashes as RECORD:000000,cnt:000000 to RECORD:000000,cnt:000008 and RECORD:000000,cnt:000009 being the crash case. NOTE: This option needs to be enabled in config.h first! @@ -493,7 +493,7 @@ checks or alter some of the more exotic semantics of the tool: This is especially useful when running multiple instances (`-M/-S` for example). Applied tags are `banner` and `afl_version`. `banner` corresponds to the name of the fuzzer provided through `-M/-S`. `afl_version` - corresponds to the currently running AFL++ version (e.g. `++3.0c`). Default + corresponds to the currently running AFL++ version (e.g., `++3.0c`). Default (empty/non present) will add no tags to the metrics. For more information, see [rpc_statsd.md](rpc_statsd.md). @@ -535,11 +535,11 @@ The QEMU wrapper used to instrument binary-only code supports several settings: - `AFL_DEBUG` will print the found entry point for the binary to stderr. Use this if you are unsure if the entry point might be wrong - but use it - directly, e.g. `afl-qemu-trace ./program`. + directly, e.g., `afl-qemu-trace ./program`. - `AFL_ENTRYPOINT` allows you to specify a specific entry point into the binary (this can be very good for the performance!). The entry point is - specified as hex address, e.g. `0x4004110`. Note that the address must be + specified as hex address, e.g., `0x4004110`. Note that the address must be the address of a basic block. - Setting `AFL_INST_LIBS` causes the translator to also instrument the code @@ -595,7 +595,7 @@ QEMU driver to provide a `main` loop for a user provided `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. * `AFL_FRIDA_INST_JIT` - Enable the instrumentation of Just-In-Time compiled @@ -617,13 +617,13 @@ 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. +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`. * `AFL_FRIDA_INST_UNSTABLE_COVERAGE_FILE` - File to write DynamoRio format -coverage information for unstable edges (e.g. to be loaded within IDA +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. diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index c3204212..a786fd8b 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -113,7 +113,7 @@ 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 the library, use afl-frida.c as a template. -You can also perform remote fuzzing with frida, e.g. if you want to fuzz on +You can also perform remote fuzzing with frida, e.g., if you want to fuzz on iPhone or Android devices, for this you can use [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) as an intermediate that uses AFL++ for fuzzing. @@ -198,8 +198,8 @@ It is at about 80-85% performance. Dyninst is a binary instrumentation framework similar to Pintool and DynamoRIO. However, whereas Pintool and DynamoRIO work at runtime, Dyninst instruments the 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. +This is great for some things, e.g., fuzzing, and not so effective for others, +e.g., malware analysis. 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 diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 96e709ab..4e1e001e 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -167,7 +167,7 @@ allows you to find bugs that would not necessarily result in a crash. Note that sanitizers have a huge impact on CPU (= less executions per second) and RAM usage. Also you should only run one afl-fuzz instance per sanitizer -type. This is enough because a use-after-free bug will be picked up, e.g. by +type. This is enough because a use-after-free bug will be picked up, e.g., by ASAN (address sanitizer) anyway when syncing to other fuzzing instances, so not all fuzzing instances need to be instrumented with ASAN. @@ -179,7 +179,7 @@ The following sanitizers have built-in support in AFL++: local variable that is defined and read before it is even set. Enabled with `export AFL_USE_MSAN=1` before compiling. * UBSAN = Undefined Behavior SANitizer, finds instances where - by the C and C++ - standards - undefined behavior happens, e.g. adding two signed integers + standards - undefined behavior happens, e.g., adding two signed integers together where the result is larger than a signed integer can hold. Enabled with `export AFL_USE_UBSAN=1` before compiling. * CFISAN = Control Flow Integrity SANitizer, finds instances where the control @@ -202,15 +202,15 @@ be looked up in the sanitizer documentation of llvm/clang. afl-fuzz, however, requires some specific parameters important for fuzzing to be set. If you want to set your own, it might bail and report what it is missing. -Note that some sanitizers cannot be used together, e.g. ASAN and MSAN, and -others often cannot work together because of target weirdness, e.g. ASAN and +Note that some sanitizers cannot be used together, e.g., ASAN and MSAN, and +others often cannot work together because of target weirdness, e.g., ASAN and CFISAN. You might need to experiment which sanitizers you can combine in a target (which means more instances can be run without a sanitized target, which is more effective). ### d) Modifying the target -If the target has features that make fuzzing more difficult, e.g. checksums, +If the target has features that make fuzzing more difficult, e.g., checksums, HMAC, etc. then modify the source code so that checks for these values are removed. This can even be done safely for source code used in operational products by eliminating these checks within these AFL++ specific blocks: @@ -250,7 +250,7 @@ Then build the target. (Usually with `make`) reporting via `export AFL_QUIET=1`. 2. sometimes configure and build systems error on warnings - these should be - disabled (e.g. `--disable-werror` for some configure scripts). + disabled (e.g., `--disable-werror` for some configure scripts). 3. in case the configure/build system complains about AFL++'s compiler and aborts then set `export AFL_NOOPT=1` which will then just behave like the @@ -354,7 +354,7 @@ You can find many good examples of starting files in the Use the AFL++ tool `afl-cmin` to remove inputs from the corpus that do not produce a new path in the target. -Put all files from step a) into one directory, e.g. INPUTS. +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: @@ -380,8 +380,8 @@ for i in *; do done ``` -This step can also be parallelized, e.g. with `parallel`. Note that this step is -rather optional though. +This step can also be parallelized, e.g., with `parallel`. Note that this step +is rather optional though. ### Done! @@ -503,7 +503,7 @@ can set the cache size (in MB) by setting the environment variable `AFL_TESTCACHE_SIZE`. There should be one main fuzzer (`-M main-$HOSTNAME` option) and as many -secondary fuzzers (e.g. `-S variant1`) as you have cores that you use. Every +secondary fuzzers (e.g., `-S variant1`) as you have cores that you use. Every -M/-S entry needs a unique name (that can be whatever), however, the same -o output directory location has to be used for all instances. @@ -522,7 +522,7 @@ All other secondaries should be used like this: * a quarter to a third with the MOpt mutator enabled: `-L 0` * run with a different power schedule, recommended are: `fast (default), explore, coe, lin, quad, exploit and rare` which you can set - with e.g. `-p explore` + with, e.g., `-p explore` * a few instances should use the old queue cycling with `-Z` Also, it is recommended to set `export AFL_IMPORT_FIRST=1` to load test cases @@ -547,7 +547,7 @@ A long list can be found at However, you can also sync AFL++ with honggfuzz, libfuzzer with `-entropic=1`, etc. Just show the main fuzzer (-M) with the `-F` option where the queue/work -directory of a different fuzzer is, e.g. `-F /src/target/honggfuzz`. Using +directory of a different fuzzer is, e.g., `-F /src/target/honggfuzz`. Using honggfuzz (with `-n 1` or `-n 2`) and libfuzzer in parallel is highly recommended! @@ -615,8 +615,8 @@ To restart an afl-fuzz run, just reuse the same command line but replace the `-i directory` with `-i -` or set `AFL_AUTORESUME=1`. If you want to add new seeds to a fuzzing campaign you can run a temporary -fuzzing instance, e.g. when your main fuzzer is using `-o out` and the new seeds -are in `newseeds/` directory: +fuzzing instance, e.g., when your main fuzzer is using `-o out` and the new +seeds are in `newseeds/` directory: ``` AFL_BENCH_JUST_ONE=1 AFL_FAST_CAL=1 afl-fuzz -i newseeds -o out -S newseeds -- ./target @@ -665,9 +665,9 @@ then you will not touch any of the other library APIs and features. ### h) How long to fuzz a target? This is a difficult question. Basically if no new path is found for a long time -(e.g. for a day or a week) then you can expect that your fuzzing won't be +(e.g., for a day or a week) then you can expect that your fuzzing won't be fruitful anymore. However, often this just means that you should switch out -secondaries for others, e.g. custom mutator modules, sync to very different +secondaries for others, e.g., custom mutator modules, sync to very different fuzzers, etc. Keep the queue/ directory (for future fuzzings of the same or similar targets) diff --git a/docs/ideas.md b/docs/ideas.md index 325e7031..8193983b 100644 --- a/docs/ideas.md +++ b/docs/ideas.md @@ -32,7 +32,7 @@ Mentor: any ## Support other programming languages Other programming languages also use llvm hence they could (easily?) supported -for fuzzing, e.g. mono, swift, go, kotlin native, fortran, ... +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/)) diff --git a/docs/important_changes.md b/docs/important_changes.md index 6cd00791..82de054f 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -44,7 +44,7 @@ behaviors and defaults: * `-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 + * -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 * a caching of test cases can now be performed and can be modified by diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index d16049fa..ac8f2f2a 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -40,7 +40,7 @@ The idea and much of the initial implementation came from Laszlo Szekeres. ## 2a) How to use this - short -Set the `LLVM_CONFIG` variable to the clang version you want to use, e.g. +Set the `LLVM_CONFIG` variable to the clang version you want to use, e.g.: ``` LLVM_CONFIG=llvm-config-9 make diff --git a/instrumentation/README.lto.md b/instrumentation/README.lto.md index b97e5799..a20175b1 100644 --- a/instrumentation/README.lto.md +++ b/instrumentation/README.lto.md @@ -71,7 +71,7 @@ use an outdated Linux distribution, read the next section. Installing the llvm snapshot builds is easy and mostly painless: In the following line, change `NAME` for your Debian or Ubuntu release name -(e.g. buster, focal, eon, etc.): +(e.g., buster, focal, eon, etc.): ``` echo deb http://apt.llvm.org/NAME/ llvm-toolchain-NAME NAME >> /etc/apt/sources.list diff --git a/utils/README.md b/utils/README.md index b8df0b47..b7eead8e 100644 --- a/utils/README.md +++ b/utils/README.md @@ -13,7 +13,7 @@ Here's a quick overview of the stuff you can find in this directory: - afl_proxy - skeleton file example to show how to fuzz something where you gather coverage data via - different means, e.g. hw debugger + different means, e.g., hw debugger - afl_untracer - fuzz binary-only libraries much faster but with less coverage than qemu_mode diff --git a/utils/afl_network_proxy/README.md b/utils/afl_network_proxy/README.md index d2c00be2..c478319a 100644 --- a/utils/afl_network_proxy/README.md +++ b/utils/afl_network_proxy/README.md @@ -6,7 +6,8 @@ Note that the impact on fuzzing speed will be huge, expect a loss of 90%. ## When to use this 1. when you have to fuzz a target that has to run on a system that cannot - contain the fuzzing output (e.g. /tmp too small and file system is read-only) + contain the fuzzing output (e.g., /tmp too small and file system is + read-only) 2. when the target instantly reboots on crashes 3. ... any other reason you would need this @@ -28,6 +29,7 @@ For most targets this hurts performance though so it is disabled by default. Run `afl-network-server` with your target with the -m and -t values you need. Important is the -i parameter which is the TCP port to listen on. e.g.: + ``` afl-network-server -i 1111 -m 25M -t 1000 -- /bin/target -f @@ ``` @@ -50,7 +52,7 @@ value itself should be 500-1000 higher than the one on afl-network-server. The TARGET can be an IPv4 or IPv6 address, or a host name that resolves to either. Note that also the outgoing interface can be specified with a '%' for -`afl-network-client`, e.g. `fe80::1234%eth0`. +`afl-network-client`, e.g., `fe80::1234%eth0`. Also make sure your default TCP window size is larger than your MAP_SIZE (130kb is a good value). -- cgit 1.4.1 From fc094dee13060fd84e89764a9526c11a55072e4d Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Fri, 3 Dec 2021 11:35:30 +0100 Subject: change dlopen solution --- docs/Changelog.md | 7 ++++++- docs/best_practices.md | 21 +++++++++++++++++++++ instrumentation/SanitizerCoverageLTO.so.cc | 12 ++++++++++++ instrumentation/SanitizerCoveragePCGUARD.so.cc | 12 ++++++++++++ instrumentation/afl-compiler-rt.o.c | 15 ++++++++------- test/test-dlopen.c | 20 ++++++++++++++++++-- 6 files changed, 77 insertions(+), 10 deletions(-) (limited to 'docs/best_practices.md') diff --git a/docs/Changelog.md b/docs/Changelog.md index 103f9f63..be5cac43 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -9,9 +9,14 @@ Want to stay in the loop on major new features? Join our mailing list by sending a mail to . ### Version ++3.15a (dev) - - documentation restructuring, made possible by Google Season of Docs :) + - documentation restructuring, made possible by Google Season of Docs - new binary-only fuzzing mode: coresight_mode for aarch64 CPUs :) thanks to RICSecLab submitting! + - if instrumented libaries are dlopen()'ed after the forkserver you + will now see crashes. before you would have colliding coverage. + we changed this to force fixing a broken setup rather then allowing + ineffective fuzzing. + See docs/best_practices.md how to fix such setups. - afl-fuzz: - cmplog binaries will need to be recompiled for this version (it is better!) diff --git a/docs/best_practices.md b/docs/best_practices.md index 979849f4..18096851 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -5,6 +5,7 @@ ### Targets * [Fuzzing a target with source code available](#fuzzing-a-target-with-source-code-available) +* [Fuzzing a target with dlopen() instrumented libraries](#fuzzing-a-target-with-dlopen-instrumented-libraries) * [Fuzzing a binary-only target](#fuzzing-a-binary-only-target) * [Fuzzing a GUI program](#fuzzing-a-gui-program) * [Fuzzing a network service](#fuzzing-a-network-service) @@ -20,6 +21,26 @@ To learn how to fuzz a target if source code is available, see [fuzzing_in_depth.md](fuzzing_in_depth.md). +### Fuzzing a target with dlopen instrumented libraries + +If a source code based fuzzing target loads instrumented libraries with +dlopen() after the forkserver has been activated and non-colliding coverage +instrumentation is used (PCGUARD (which is the default), or LTO), then this +an issue, because this would enlarge the coverage map, but afl-fuzz doesn't +know about it. + +The solution is to use `AFL_PRELOAD` for all dlopen()'ed libraries to +ensure that all coverage targets are present on startup in the target, +even if accessed only later with dlopen(). + +For PCGUARD instrumentation `abort()` is called if this is detected, for LTO +there will either be no coverage for the instrumented dlopen()'ed libraries or +you will see lots of crashes in the UI. + +Note that this is not an issue if you use the inferiour `afl-gcc-fast`, +`afl-gcc` or`AFL_LLVM_INSTRUMENT=CLASSIC/NGRAM/CTX afl-clang-fast` +instrumentation. + ### Fuzzing a binary-only target For a comprehensive guide, see diff --git a/instrumentation/SanitizerCoverageLTO.so.cc b/instrumentation/SanitizerCoverageLTO.so.cc index bff85a0a..8d7f0c80 100644 --- a/instrumentation/SanitizerCoverageLTO.so.cc +++ b/instrumentation/SanitizerCoverageLTO.so.cc @@ -1289,6 +1289,18 @@ void ModuleSanitizerCoverage::instrumentFunction( if (!Callee) continue; if (callInst->getCallingConv() != llvm::CallingConv::C) continue; StringRef FuncName = Callee->getName(); + if (!FuncName.compare(StringRef("dlopen")) || + !FuncName.compare(StringRef("_dlopen"))) { + + fprintf(stderr, + "WARNING: dlopen() detected. To have coverage for a library " + "that your target dlopen()'s this must either happen before " + "__AFL_INIT() or you must use AFL_PRELOAD to preload all " + "dlopen()'ed libraries!\n"); + continue; + + } + if (FuncName.compare(StringRef("__afl_coverage_interesting"))) continue; Value *val = ConstantInt::get(Int32Ty, ++afl_global_id); diff --git a/instrumentation/SanitizerCoveragePCGUARD.so.cc b/instrumentation/SanitizerCoveragePCGUARD.so.cc index 3574b0e4..92450781 100644 --- a/instrumentation/SanitizerCoveragePCGUARD.so.cc +++ b/instrumentation/SanitizerCoveragePCGUARD.so.cc @@ -851,6 +851,18 @@ bool ModuleSanitizerCoverage::InjectCoverage(Function & F, if (!Callee) continue; if (callInst->getCallingConv() != llvm::CallingConv::C) continue; StringRef FuncName = Callee->getName(); + if (!FuncName.compare(StringRef("dlopen")) || + !FuncName.compare(StringRef("_dlopen"))) { + + fprintf(stderr, + "WARNING: dlopen() detected. To have coverage for a library " + "that your target dlopen()'s this must either happen before " + "__AFL_INIT() or you must use AFL_PRELOAD to preload all " + "dlopen()'ed libraries!\n"); + continue; + + } + if (FuncName.compare(StringRef("__afl_coverage_interesting"))) continue; cnt_cov++; diff --git a/instrumentation/afl-compiler-rt.o.c b/instrumentation/afl-compiler-rt.o.c index 65dafb8c..20f325f3 100644 --- a/instrumentation/afl-compiler-rt.o.c +++ b/instrumentation/afl-compiler-rt.o.c @@ -1418,16 +1418,14 @@ void __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop) { if (start == stop || *start) return; // If a dlopen of an instrumented library happens after the forkserver then - // we have a problem. - // Should we abort()? This way a user would/could find out. - // Currently we just do not instrument that lib, which is invisible. + // we have a problem as we cannot increase the coverage map anymore. if (__afl_already_initialized_forkserver) { fprintf(stderr, - "[-] ERROR: forkserver is already up, but an instrumented dlopen() " - "library loaded afterwards. You must LD_PRELOAD such libraries to " - "be able to fuzz them.\n"); - return; // or should be abort()? + "[-] FATAL: forkserver is already up, but an instrumented dlopen() " + "library loaded afterwards. You must AFL_PRELOAD such libraries to " + "be able to fuzz them or LD_PRELOAD to run outside of afl-fuzz.\n"); + abort(); } @@ -1443,6 +1441,7 @@ void __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop) { /* instrumented code is loaded *after* our forkserver is up. this is a problem. We cannot prevent collisions then :( */ + /* if (__afl_already_initialized_forkserver && __afl_final_loc + 1 + stop - start > __afl_map_size) { @@ -1475,6 +1474,8 @@ void __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop) { } + */ + /* Make sure that the first element in the range is always set - we use that to avoid duplicate calls (which can happen as an artifact of the underlying implementation in LLVM). */ diff --git a/test/test-dlopen.c b/test/test-dlopen.c index d08d9092..b81bab13 100644 --- a/test/test-dlopen.c +++ b/test/test-dlopen.c @@ -5,7 +5,13 @@ int main(int argc, char **argv) { - if (!getenv("TEST_DLOPEN_TARGET")) return 1; + if (!getenv("TEST_DLOPEN_TARGET")) { + + fprintf(stderr, "Error: TEST_DLOPEN_TARGET not set!\n"); + return 1; + + } + void *lib = dlopen(getenv("TEST_DLOPEN_TARGET"), RTLD_LAZY); if (!lib) { @@ -15,8 +21,18 @@ int main(int argc, char **argv) { } int (*func)(int, char **) = dlsym(lib, "main_exported"); - if (!func) return 3; + if (!func) { + + fprintf(stderr, "Error: main_exported not found!\n"); + return 3; + + } + + // must use deferred forkserver as otherwise afl++ instrumentation aborts + // because all dlopen() of instrumented libs must be before the forkserver + __AFL_INIT(); + fprintf(stderr, "Running main_exported\n"); return func(argc, argv); } -- 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 'docs/best_practices.md') 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