From 7a8e4018a59fdabef395ca730d6e73f95e8daaed Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 17:13:12 +0100 Subject: Change the word "env var" to "environment variable" --- docs/features.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/features.md') diff --git a/docs/features.md b/docs/features.md index 35a869a9..fb688a64 100644 --- a/docs/features.md +++ b/docs/features.md @@ -19,8 +19,8 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full | Snapshot LKM Support | | (x)(8) | (x)(8) | | (x)(5) | | | | Shared Memory Test cases | | x | x | x86[_64]/arm64 | x | x | | -1. default for LLVM >= 9.0, env var for older version due an efficiency bug in - previous llvm versions +1. default for LLVM >= 9.0, environment variable for older version due an + efficiency bug in previous llvm versions 2. GCC creates non-performant code, hence it is disabled in gcc_plugin 3. with `AFL_LLVM_THREADSAFE_INST`, disables NeverZero 4. with pcguard mode and LTO mode for LLVM 11 and newer -- cgit 1.4.1 From 6eab6a55af74754cd0229012f1c9543c0c3cb2a7 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sat, 4 Dec 2021 21:14:50 +0100 Subject: Fix spelling of "FRIDA mode" and "QEMU mode" --- TODO.md | 2 +- docs/INSTALL.md | 4 ++-- docs/features.md | 8 ++++---- docs/fuzzing_binary-only_targets.md | 35 ++++++++++++++++++----------------- docs/important_changes.md | 8 ++++---- instrumentation/README.llvm.md | 2 +- qemu_mode/libqasan/README.md | 2 +- utils/README.md | 2 +- utils/afl_untracer/README.md | 2 +- utils/aflpp_driver/README.md | 4 ++-- utils/qbdi_mode/README.md | 2 +- 11 files changed, 36 insertions(+), 35 deletions(-) (limited to 'docs/features.md') diff --git a/TODO.md b/TODO.md index 04f3abab..e6b095fc 100644 --- a/TODO.md +++ b/TODO.md @@ -16,7 +16,7 @@ ## Further down the road -qemu_mode/frida_mode: +QEMU mode/FRIDA mode: - non colliding instrumentation - rename qemu specific envs to AFL_QEMU (AFL_ENTRYPOINT, AFL_CODE_START/END, AFL_COMPCOV_LEVEL?) diff --git a/docs/INSTALL.md b/docs/INSTALL.md index 08d3283e..9d1309fe 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -23,7 +23,7 @@ sudo apt-get install -y build-essential python3-dev automake git flex bison libg # try to install llvm 11 and install the distro default if that fails sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang sudo apt-get install -y gcc-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-plugin-dev libstdc++-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-dev -sudo apt-get install -y ninja-build # for qemu_mode +sudo apt-get install -y ninja-build # for QEMU mode git clone https://github.com/AFLplusplus/AFLplusplus cd AFLplusplus make distrib @@ -33,7 +33,7 @@ sudo make install 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 +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: diff --git a/docs/features.md b/docs/features.md index fb688a64..06b1bcbe 100644 --- a/docs/features.md +++ b/docs/features.md @@ -4,7 +4,7 @@ AFL++ supports llvm from 3.8 up to version 12, very fast binary fuzzing with QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full *BSD, Mac OS, Solaris and Android support and much, much, much more. -| Feature/Instrumentation | afl-gcc | llvm | gcc_plugin | frida_mode(9) | qemu_mode(10) |unicorn_mode(10) |coresight_mode(11)| +| Feature/Instrumentation | afl-gcc | llvm | gcc_plugin | FRIDA mode(9) | QEMU mode(10) |unicorn_mode(10) |coresight_mode(11)| | -------------------------|:-------:|:---------:|:----------:|:----------------:|:----------------:|:----------------:|:----------------:| | Threadsafe counters | | x(3) | | | | | | | NeverZero | x86[_64]| x(1) | x | x | x | x | | @@ -37,9 +37,9 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full Among others, the following features and patches have been integrated: -* NeverZero patch for afl-gcc, instrumentation, qemu_mode and unicorn_mode which +* NeverZero patch for afl-gcc, instrumentation, QEMU mode and unicorn_mode which prevents a wrapping map value to zero, increases coverage -* Persistent mode, deferred forkserver and in-memory fuzzing for qemu_mode +* Persistent mode, deferred forkserver and in-memory fuzzing for QEMU mode * Unicorn mode which allows fuzzing of binaries from completely different platforms (integration provided by domenukk) * The new CmpLog instrumentation for LLVM and QEMU inspired by @@ -51,7 +51,7 @@ Among others, the following features and patches have been integrated: [https://github.com/puppet-meteor/MOpt-AFL](https://github.com/puppet-meteor/MOpt-AFL) * LLVM mode Ngram coverage by Adrian Herrera [https://github.com/adrianherrera/afl-ngram-pass](https://github.com/adrianherrera/afl-ngram-pass) -* LAF-Intel/CompCov support for instrumentation, qemu_mode and unicorn_mode +* LAF-Intel/CompCov support for instrumentation, QEMU mode and unicorn_mode (with enhanced capabilities) * Radamsa and honggfuzz mutators (as custom mutators). * QBDI mode to fuzz android native libraries via Quarkslab's diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index b3d9ca02..15155111 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -12,18 +12,18 @@ fuzzed with AFL++. ## TL;DR: -Qemu_mode in persistent mode is the fastest - if the stability is high enough. +QEMU mode in persistent mode is the fastest - if the stability is high enough. Otherwise, try RetroWrite, Dyninst, and if these fail, too, then try standard -qemu_mode with AFL_ENTRYPOINT to where you need it. +QEMU mode with `AFL_ENTRYPOINT` to where you need it. -If your target is a library, then use frida_mode. +If your target is a library, then use FRIDA mode. If your target is non-linux, then use unicorn_mode. ## Fuzzing binary-only targets with AFL++ -### Qemu_mode +### QEMU mode -Qemu_mode is the "native" solution to the program. It is available in the +QEMU mode is the "native" solution to the program. It is available in the ./qemu_mode/ directory and, once compiled, it can be accessed by the afl-fuzz -Q command line option. It is the easiest to use alternative and even works for cross-platform binaries. @@ -37,11 +37,12 @@ cd qemu_mode ./build_qemu_support.sh ``` -The following setup to use qemu_mode is recommended: +The following setup to use QEMU mode is recommended: + * run 1 afl-fuzz -Q instance with CMPLOG (`-c 0` + `AFL_COMPCOV_LEVEL=2`) * run 1 afl-fuzz -Q instance with QASAN (`AFL_USE_QASAN=1`) * run 1 afl-fuzz -Q instance with LAF (`AFL_PRELOAD=libcmpcov.so` + - `AFL_COMPCOV_LEVEL=2`), alternatively you can use frida_mode, just switch `-Q` + `AFL_COMPCOV_LEVEL=2`), alternatively you can use FRIDA mode, just switch `-Q` with `-O` and remove the LAF instance Then run as many instances as you have cores left with either -Q mode or - even @@ -49,16 +50,16 @@ better - use a binary rewriter like Dyninst, RetroWrite, ZAFL, etc. If [afl-dyninst](https://github.com/vanhauser-thc/afl-dyninst) works for your binary, then you can use afl-fuzz normally and it will have twice the speed -compared to qemu_mode (but slower than qemu persistent mode). Note that several +compared to QEMU mode (but slower than QEMU persistent mode). Note that several other binary rewriters exist, all with their advantages and caveats. -The speed decrease of qemu_mode is at about 50%. However, various options exist +The speed decrease of QEMU mode is at about 50%. However, various options exist to increase the speed: - using AFL_ENTRYPOINT to move the forkserver entry to a later basic block in the binary (+5-10% speed) - using persistent mode [qemu_mode/README.persistent.md](../qemu_mode/README.persistent.md) this will - result in a 150-300% overall speed increase - so 3-8x the original qemu_mode + result in a 150-300% overall speed increase - so 3-8x the original QEMU mode speed! - using AFL_CODE_START/AFL_CODE_END to only instrument specific parts @@ -71,7 +72,7 @@ conducive to parallelization. Note that there is also honggfuzz: [https://github.com/google/honggfuzz](https://github.com/google/honggfuzz) which -now has a qemu_mode, but its performance is just 1.5% ... +now has a QEMU mode, but its performance is just 1.5% ... If you like to code a customized fuzzer without much work, we highly recommend to check out our sister project libafl which supports QEMU, too: @@ -87,14 +88,14 @@ It is included in AFL++. For more information, see [qemu_mode/README.wine.md](../qemu_mode/README.wine.md). -### Frida_mode +### FRIDA mode -In frida_mode, you can fuzz binary-only targets as easily as with QEMU. -Frida_mode is sometimes faster and sometimes slower than Qemu_mode. It is also +In FRIDA mode, you can fuzz binary-only targets as easily as with QEMU mode. +FRIDA mode is sometimes faster and sometimes slower than QEMU mode. It is also newer, lacks COMPCOV, and has the advantage that it works on MacOS (both intel and M1). -To build frida_mode: +To build FRIDA mode: ```shell cd frida_mode @@ -149,11 +150,11 @@ For further information, check out If the goal is to fuzz a dynamic library, then there are two options available. For both, you need to write a small harness that loads and calls the library. -Then you fuzz this with either frida_mode or qemu_mode and either use +Then you fuzz this with either FRIDA mode or QEMU mode and either use `AFL_INST_LIBS=1` or `AFL_QEMU/FRIDA_INST_RANGES`. Another, less precise and slower option is to fuzz it with utils/afl_untracer/ -and use afl-untracer.c as a template. It is slower than frida_mode. +and use afl-untracer.c as a template. It is slower than FRIDA mode. For more information, see [utils/afl_untracer/README.md](../utils/afl_untracer/README.md). diff --git a/docs/important_changes.md b/docs/important_changes.md index 203c5a66..d5e67f75 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -5,8 +5,8 @@ changes. ## From version 3.00 onwards -With AFL++ 3.13-3.20, we introduce frida_mode (-O) to have an alternative for -binary-only fuzzing. It is slower than Qemu mode but works on MacOS, Android, +With AFL++ 3.13-3.20, we introduce FRIDA mode (`-O`) to have an alternative for +binary-only fuzzing. It is slower than QEMU mode but works on MacOS, Android, iOS etc. With AFL++ 3.15, we introduced the following changes from previous behaviors: @@ -31,8 +31,8 @@ behaviors and defaults: All instrumentation source code is now in the `instrumentation/` folder. * 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 + * 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. diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index c93cd312..fa025643 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -218,7 +218,7 @@ by Jinghan Wang, et. al. Note that the original implementation (available [here](https://github.com/bitsecurerlab/afl-sensitive)) is built on top of AFL's -qemu_mode. This is essentially a port that uses LLVM vectorized instructions +QEMU mode. This is essentially a port that uses LLVM vectorized instructions (available from llvm versions 4.0.1 and higher) to achieve the same results when compiling source code. diff --git a/qemu_mode/libqasan/README.md b/qemu_mode/libqasan/README.md index 6a65c12b..41195933 100644 --- a/qemu_mode/libqasan/README.md +++ b/qemu_mode/libqasan/README.md @@ -9,7 +9,7 @@ and this runtime is injected via LD_PRELOAD (so works just for dynamically linked binaries). The usage is super simple, just set the env var `AFL_USE_QASAN=1` when fuzzing -in qemu mode (-Q). afl-fuzz will automatically set AFL_PRELOAD to load this +in QEMU mode (-Q). afl-fuzz will automatically set AFL_PRELOAD to load this library and enable the QASan instrumentation in afl-qemu-trace. For debugging purposes, we still suggest to run the original QASan as the diff --git a/utils/README.md b/utils/README.md index b7eead8e..5f5745b9 100644 --- a/utils/README.md +++ b/utils/README.md @@ -16,7 +16,7 @@ Here's a quick overview of the stuff you can find in this directory: different means, e.g., hw debugger - afl_untracer - fuzz binary-only libraries much faster but with - less coverage than qemu_mode + less coverage than QEMU mode - analysis_scripts - random -o out analysis scripts diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md index 9f41618f..3fff5f83 100644 --- a/utils/afl_untracer/README.md +++ b/utils/afl_untracer/README.md @@ -5,7 +5,7 @@ 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 +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. diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md index d534cd7f..8b9fe15f 100644 --- a/utils/aflpp_driver/README.md +++ b/utils/aflpp_driver/README.md @@ -22,10 +22,10 @@ or `@@` as command line parameters. ## aflpp_qemu_driver -Note that you can use the driver too for frida_mode (`-O`). +Note that you can use the driver too for FRIDA mode (`-O`). aflpp_qemu_driver is used for libfuzzer `LLVMFuzzerTestOneInput()` targets that -are to be fuzzed in qemu_mode. So compile them with clang/clang++, without +are to be fuzzed in QEMU mode. So compile them with clang/clang++, without -fsantize=fuzzer or afl-clang-fast, and link in libAFLQemuDriver.a: `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`. diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md index c8d46fca..02dd3c74 100755 --- a/utils/qbdi_mode/README.md +++ b/utils/qbdi_mode/README.md @@ -2,7 +2,7 @@ NOTE: this code is outdated and first would need to be adapted to the current AFL++ versions. -Try frida_mode or fpicker [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) first, maybe they suite your need. +Try FRIDA mode or fpicker [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) first, maybe they suite your need. ## 1) Introduction -- cgit 1.4.1 From bb506de0b809f97a4221ee1b6e040dcb5f9ca56a Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sun, 5 Dec 2021 19:04:45 +0100 Subject: Fix various missed issues - 1st run --- custom_mutators/gramatron/README.md | 43 ++++----- dictionaries/README.md | 20 ++-- docs/afl-fuzz_approach.md | 11 ++- docs/custom_mutators.md | 2 +- docs/env_variables.md | 2 +- docs/features.md | 4 +- utils/autodict_ql/readme.md | 180 ++++++++++++++++++++++-------------- utils/libdislocator/README.md | 29 +++--- 8 files changed, 168 insertions(+), 123 deletions(-) (limited to 'docs/features.md') diff --git a/custom_mutators/gramatron/README.md b/custom_mutators/gramatron/README.md index 5e10f97b..8aa0cc44 100644 --- a/custom_mutators/gramatron/README.md +++ b/custom_mutators/gramatron/README.md @@ -1,17 +1,17 @@ # GramaTron GramaTron is a coverage-guided fuzzer that uses grammar automatons to perform -grammar-aware fuzzing. Technical details about our framework are available -in the [ISSTA'21 paper](https://nebelwelt.net/files/21ISSTA.pdf). -The artifact to reproduce the experiments presented in the paper are present -in `artifact/`. Instructions to run a sample campaign and incorporate new -grammars is presented below: +grammar-aware fuzzing. Technical details about our framework are available in +the [ISSTA'21 paper](https://nebelwelt.net/files/21ISSTA.pdf). The artifact to +reproduce the experiments presented in the paper are present in `artifact/`. +Instructions to run a sample campaign and incorporate new grammars is presented +below: -# Compiling +## Compiling Execute `./build_gramatron_mutator.sh`. -# Running +## Running You have to set the grammar file to use with `GRAMATRON_AUTOMATION`: @@ -23,26 +23,27 @@ export GRAMATRON_AUTOMATION=grammars/ruby/source_automata.json afl-fuzz -i in -o out -- ./target ``` -# Adding and testing a new grammar +## Adding and testing a new grammar -- Specify in a JSON format for CFG. Examples are correspond `source.json` files +- Specify in a JSON format for CFG. Examples are correspond `source.json` files. - Run the automaton generation script (in `src/gramfuzz-mutator/preprocess`) which will place the generated automaton in the same folder. -``` -./preprocess/prep_automaton.sh [stack_limit] + ``` + ./preprocess/prep_automaton.sh [stack_limit] -E.g., ./preprocess/prep_automaton.sh ~/grammars/ruby/source.json PROGRAM -``` + E.g., ./preprocess/prep_automaton.sh ~/grammars/ruby/source.json PROGRAM + ``` -- If the grammar has no self-embedding rules then you do not need to pass the - stack limit parameter. However, if it does have self-embedding rules then you +- If the grammar has no self-embedding rules, then you do not need to pass the + stack limit parameter. However, if it does have self-embedding rules, then you need to pass the stack limit parameter. We recommend starting with `5` and - then increasing it if you need more complexity -- To sanity-check that the automaton is generating inputs as expected you can use the `test` binary housed in `src/gramfuzz-mutator` + then increasing it if you need more complexity. +- To sanity-check that the automaton is generating inputs as expected, you can + use the `test` binary housed in `src/gramfuzz-mutator`. -``` -./test SanityCheck + ``` + ./test SanityCheck -E.g., ./test SanityCheck ~/grammars/ruby/source_automata.json -``` \ No newline at end of file + E.g., ./test SanityCheck ~/grammars/ruby/source_automata.json + ``` \ No newline at end of file diff --git a/dictionaries/README.md b/dictionaries/README.md index f3b8a9e5..0b3b4d90 100644 --- a/dictionaries/README.md +++ b/dictionaries/README.md @@ -2,17 +2,17 @@ (See [../README.md](../README.md) for the general instruction manual.) -This subdirectory contains a set of dictionaries that can be used in -conjunction with the -x option to allow the fuzzer to effortlessly explore the -grammar of some of the more verbose data formats or languages. +This subdirectory contains a set of dictionaries that can be used in conjunction +with the -x option to allow the fuzzer to effortlessly explore the grammar of +some of the more verbose data formats or languages. -These sets were done by Michal Zalewski, various contributors, and imported -from oss-fuzz, go-fuzz and libfuzzer. +These sets were done by Michal Zalewski, various contributors, and imported from +oss-fuzz, go-fuzz and libfuzzer. Custom dictionaries can be added at will. They should consist of a reasonably-sized set of rudimentary syntax units that the fuzzer will then try -to clobber together in various ways. Snippets between 2 and 16 bytes are -usually the sweet spot. +to clobber together in various ways. Snippets between 2 and 16 bytes are usually +the sweet spot. Custom dictionaries can be created in two ways: @@ -34,9 +34,9 @@ In the file mode, every name field can be optionally followed by @, e.g.: `keyword_foo@1 = "foo"` Such entries will be loaded only if the requested dictionary level is equal or -higher than this number. The default level is zero; a higher value can be set -by appending @ to the dictionary file name, like so: +higher than this number. The default level is zero; a higher value can be set by +appending @ to the dictionary file name, like so: `-x path/to/dictionary.dct@2` -Good examples of dictionaries can be found in xml.dict and png.dict. +Good examples of dictionaries can be found in xml.dict and png.dict. \ No newline at end of file diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md index 01888935..2da61cc4 100644 --- a/docs/afl-fuzz_approach.md +++ b/docs/afl-fuzz_approach.md @@ -468,7 +468,8 @@ cd ../../ sudo make install ``` -To learn more about remote monitoring and metrics visualization with StatsD, see [rpc_statsd.md](rpc_statsd.md). +To learn more about remote monitoring and metrics visualization with StatsD, see +[rpc_statsd.md](rpc_statsd.md). ### Addendum: status and plot files @@ -524,9 +525,9 @@ into each of them or deploy scripts to read the fuzzer statistics. Using `AFL_STATSD` (and the other related environment variables `AFL_STATSD_HOST`, `AFL_STATSD_PORT`, `AFL_STATSD_TAGS_FLAVOR`) you can automatically send metrics to your favorite StatsD server. Depending on your StatsD server, you will be -able to monitor, trigger alerts, or perform actions based on these metrics (e.g: -alert on slow exec/s for a new build, threshold of crashes, time since last -crash > X, etc.). +able to monitor, trigger alerts, or perform actions based on these metrics +(e.g.: alert on slow exec/s for a new build, threshold of crashes, time since +last crash > X, etc.). The selected metrics are a subset of all the metrics found in the status and in the plot file. The list is the following: `cycle_done`, `cycles_wo_finds`, @@ -537,6 +538,6 @@ the plot file. The list is the following: `cycle_done`, `cycles_wo_finds`, definitions can be found in the addendum above. When using multiple fuzzer instances with StatsD, it is *strongly* recommended -to setup the flavor (AFL_STATSD_TAGS_FLAVOR) to match your StatsD server. This +to setup the flavor (`AFL_STATSD_TAGS_FLAVOR`) to match your StatsD server. This will allow you to see individual fuzzer performance, detect bad ones, see the progress of each strategy... \ No newline at end of file diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 2f632e1f..7b4e0516 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -276,7 +276,7 @@ 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 +will be called in the order in which they are specified. E.g., the first `post_process` function of `example_first.so` will be called and then that of `example_second.so`. diff --git a/docs/env_variables.md b/docs/env_variables.md index 0952b960..c45f4ab9 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -585,7 +585,7 @@ The FRIDA wrapper used to instrument binary-only code supports many of the same options as `afl-qemu-trace`, but also has a number of additional advanced options. These are listed in brief below (see [frida_mode/README.md](../frida_mode/README.md) for more details). These -settings are provided for compatibiltiy with QEMU mode, the preferred way to +settings are provided for compatibility with QEMU mode, the preferred way to configure FRIDA mode is through its [scripting](../frida_mode/Scripting.md) support. diff --git a/docs/features.md b/docs/features.md index 06b1bcbe..431d9eb1 100644 --- a/docs/features.md +++ b/docs/features.md @@ -1,7 +1,7 @@ # Important features of AFL++ AFL++ supports llvm from 3.8 up to version 12, very fast binary fuzzing with -QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full +QEMU 5.1 with laf-intel and redqueen, FRIDA mode, unicorn mode, gcc plugin, full *BSD, Mac OS, Solaris and Android support and much, much, much more. | Feature/Instrumentation | afl-gcc | llvm | gcc_plugin | FRIDA mode(9) | QEMU mode(10) |unicorn_mode(10) |coresight_mode(11)| @@ -30,7 +30,7 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full versions that write to a file to use with afl-fuzz' `-x` 8. the snapshot LKM is currently unmaintained due to too many kernel changes coming too fast :-( -9. frida mode is supported on Linux and MacOS for Intel and ARM +9. FRIDA mode is supported on Linux and MacOS for Intel and ARM 10. QEMU/Unicorn is only supported on Linux 11. Coresight mode is only available on AARCH64 Linux with a CPU with Coresight extension diff --git a/utils/autodict_ql/readme.md b/utils/autodict_ql/readme.md index 789cd152..f61026b7 100644 --- a/utils/autodict_ql/readme.md +++ b/utils/autodict_ql/readme.md @@ -2,21 +2,35 @@ ## What is this? -`Autodict-QL` is a plugin system that enables fast generation of Tokens/Dictionaries in a handy way that can be manipulated by the user (unlike The LLVM Passes that are hard to modify). This means that autodict-ql is a scriptable feature which basically uses CodeQL (a powerful semantic code analysis engine) to fetch information from a code base. +`Autodict-QL` is a plugin system that enables fast generation of +Tokens/Dictionaries in a handy way that can be manipulated by the user (unlike +The LLVM Passes that are hard to modify). This means that autodict-ql is a +scriptable feature which basically uses CodeQL (a powerful semantic code +analysis engine) to fetch information from a code base. -Tokens are useful when you perform fuzzing on different parsers. The AFL++ `-x` switch enables the usage of dictionaries through your fuzzing campaign. If you are not familiar with Dictionaries in fuzzing, take a look [here](https://github.com/AFLplusplus/AFLplusplus/tree/stable/dictionaries) . +Tokens are useful when you perform fuzzing on different parsers. The AFL++ `-x` +switch enables the usage of dictionaries through your fuzzing campaign. If you +are not familiar with Dictionaries in fuzzing, take a look +[here](https://github.com/AFLplusplus/AFLplusplus/tree/stable/dictionaries). -## Why CodeQL ? +## Why CodeQL? -We basically developed this plugin on top of the CodeQL engine because it gives the user scripting features, it's easier and it's independent of the LLVM system. This means that a user can write his CodeQL scripts or modify the current scripts to improve or change the token generation algorithms based on different program analysis concepts. +We basically developed this plugin on top of the CodeQL engine because it gives +the user scripting features, it's easier and it's independent of the LLVM +system. This means that a user can write his CodeQL scripts or modify the +current scripts to improve or change the token generation algorithms based on +different program analysis concepts. ## CodeQL scripts -Currently, we pushed some scripts as defaults for Token generation. In addition, we provide every CodeQL script as an standalone script because it's easier to modify or test. +Currently, we pushed some scripts as defaults for Token generation. In addition, +we provide every CodeQL script as an standalone script because it's easier to +modify or test. -Currently we provided the following CodeQL scripts : +Currently we provided the following CodeQL scripts: -`strcmp-str.ql` is used to extract strings that are related to the `strcmp` function. +`strcmp-str.ql` is used to extract strings that are related to the `strcmp` +function. `strncmp-str.ql` is used to extract the strings from the `strncmp` function. @@ -24,13 +38,18 @@ Currently we provided the following CodeQL scripts : `litool.ql` extracts Magic numbers as Hexadecimal format. -`strtool.ql` extracts strings with uses of a regex and dataflow concept to capture the string comparison functions. If `strcmp` is rewritten in a project as Mystrcmp or something like strmycmp, then this script can catch the arguments and these are valuable tokens. +`strtool.ql` extracts strings with uses of a regex and dataflow concept to +capture the string comparison functions. If `strcmp` is rewritten in a project +as Mystrcmp or something like strmycmp, then this script can catch the arguments +and these are valuable tokens. -You can write other CodeQL scripts to extract possible effective tokens if you think they can be useful. +You can write other CodeQL scripts to extract possible effective tokens if you +think they can be useful. ## Usage -Before you proceed to installation make sure that you have the following packages by installing them: +Before you proceed to installation make sure that you have the following +packages by installing them: ```shell sudo apt install build-essential libtool-bin python3-dev python3 automake git vim wget -y @@ -38,66 +57,91 @@ sudo apt install build-essential libtool-bin python3-dev python3 automake git vi The usage of Autodict-QL is pretty easy. But let's describe it as: -1. First of all, you need to have CodeQL installed on the system. We make this possible with `build-codeql.sh` bash script. This script will install CodeQL completety and will set the required environment variables for your system. -Do the following: - -```shell -# chmod +x codeql-build.sh -# ./codeql-build.sh -# source ~/.bashrc -# codeql -``` - -Then you should get: - -```shell -Usage: codeql ... -Create and query CodeQL databases, or work with the QL language. - -GitHub makes this program freely available for the analysis of open-source software and certain other uses, but it is -not itself free software. Type codeql --license to see the license terms. - - --license Show the license terms for the CodeQL toolchain. -Common options: - -h, --help Show this help text. - -v, --verbose Incrementally increase the number of progress messages printed. - -q, --quiet Incrementally decrease the number of progress messages printed. -Some advanced options have been hidden; try --help -v for a fuller view. -Commands: - query Compile and execute QL code. - bqrs Get information from .bqrs files. - database Create, analyze and process CodeQL databases. - dataset [Plumbing] Work with raw QL datasets. - test Execute QL unit tests. - resolve [Deep plumbing] Helper commands to resolve disk locations etc. - execute [Deep plumbing] Low-level commands that need special JVM options. - version Show the version of the CodeQL toolchain. - generate Generate formatted QL documentation. - github Commands useful for interacting with the GitHub API through CodeQL. -``` - -2. Compile your project with CodeQL: For using the Autodict-QL plugin, you need to compile the source of the target you want to fuzz with CodeQL. This is not something hard. - - First you need to create a CodeQL database of the project codebase, suppose we want to compile `libxml` with codeql. Go to libxml and issue the following commands: - - `./configure --disable-shared` - - `codeql create database libxml-db --language=cpp --command=make` - - Now you have the CodeQL database of the project :-) -3. The final step is to update the CodeQL database you created in step 2 (Suppose we are in `aflplusplus/utils/autodict_ql/` directory): - - `codeql database upgrade /home/user/libxml/libxml-db` +1. First of all, you need to have CodeQL installed on the system. We make this + possible with `build-codeql.sh` bash script. This script will install CodeQL + completety and will set the required environment variables for your system. + Do the following: + + ```shell + # chmod +x codeql-build.sh + # ./codeql-build.sh + # source ~/.bashrc + # codeql + ``` + + Then you should get: + + ```shell + Usage: codeql ... + Create and query CodeQL databases, or work with the QL language. + + GitHub makes this program freely available for the analysis of open-source software and certain other uses, but it is + not itself free software. Type codeql --license to see the license terms. + + --license Show the license terms for the CodeQL toolchain. + Common options: + -h, --help Show this help text. + -v, --verbose Incrementally increase the number of progress messages printed. + -q, --quiet Incrementally decrease the number of progress messages printed. + Some advanced options have been hidden; try --help -v for a fuller view. + Commands: + query Compile and execute QL code. + bqrs Get information from .bqrs files. + database Create, analyze and process CodeQL databases. + dataset [Plumbing] Work with raw QL datasets. + test Execute QL unit tests. + resolve [Deep plumbing] Helper commands to resolve disk locations etc. + execute [Deep plumbing] Low-level commands that need special JVM options. + version Show the version of the CodeQL toolchain. + generate Generate formatted QL documentation. + github Commands useful for interacting with the GitHub API through CodeQL. + ``` + +2. Compile your project with CodeQL: For using the Autodict-QL plugin, you need + to compile the source of the target you want to fuzz with CodeQL. This is not + something hard. + - First you need to create a CodeQL database of the project codebase, suppose + we want to compile `libxml` with codeql. Go to libxml and issue the + following commands: + - `./configure --disable-shared` + - `codeql create database libxml-db --language=cpp --command=make` + - Now you have the CodeQL database of the project :-) +3. The final step is to update the CodeQL database you created in step 2 + (Suppose we are in `aflplusplus/utils/autodict_ql/` directory): + - `codeql database upgrade /home/user/libxml/libxml-db` 4. Everything is set! Now you should issue the following to get the tokens: - - `python3 autodict-ql.py [CURRECT_DIR] [CODEQL_DATABASE_PATH] [TOKEN_PATH]` - - example : `python3 /home/user/AFLplusplus/utils/autodict_ql/autodict-ql.py $PWD /home/user/libxml/libxml-db tokens` - - This will create the final `tokens` dir for you and you are done, then pass the tokens path to AFL++'s `-x` flag. + - `python3 autodict-ql.py [CURRECT_DIR] [CODEQL_DATABASE_PATH] [TOKEN_PATH]` + - example: `python3 /home/user/AFLplusplus/utils/autodict_ql/autodict-ql.py + $PWD /home/user/libxml/libxml-db tokens` + - This will create the final `tokens` dir for you and you are done, then + pass the tokens path to AFL++'s `-x` flag. 5. Done! ## More on dictionaries and tokens -Core developer of the AFL++ project Marc Heuse also developed a similar tool named `dict2file` which is a LLVM pass which can automatically extract useful tokens, in addition with LTO instrumentation mode, this dict2file is automatically generates token extraction. `Autodict-QL` plugin gives you scripting capability and you can do whatever you want to extract from the Codebase and it's up to you. In addition it's independent from LLVM system. -On the other hand, you can also use Google dictionaries which have been made public in May 2020, but the problem of using Google dictionaries is that they are limited to specific file formats and specifications. For example, for testing binutils and ELF file format or AVI in FFMPEG, there are no pre-built dictionaries, so it is highly recommended to use `Autodict-QL` or `Dict2File` features to automatically generate dictionaries based on the target. - -I've personally prefered to use `Autodict-QL` or `dict2file` rather than Google dictionaries or any other manually generated dictionaries as `Autodict-QL` and `dict2file` are working based on the target. -In overall, fuzzing with dictionaries and well-generated tokens will give better results. - -There are 2 important points to remember : - -- If you combine `Autodict-QL` with AFL++ cmplog, you will get much better code coverage and hence better chances to discover new bugs. -- Do not forget to set `AFL_MAX_DET_EXTRAS` at least to the number of generated dictionaries. If you forget to set this environment variable, then AFL++ uses just 200 tokens and use the rest of them only probabilistically. So this will guarantee that your tokens will be used by AFL++. \ No newline at end of file +Core developer of the AFL++ project Marc Heuse also developed a similar tool +named `dict2file` which is a LLVM pass which can automatically extract useful +tokens, in addition with LTO instrumentation mode, this dict2file is +automatically generates token extraction. `Autodict-QL` plugin gives you +scripting capability and you can do whatever you want to extract from the +Codebase and it's up to you. In addition it's independent from LLVM system. On +the other hand, you can also use Google dictionaries which have been made public +in May 2020, but the problem of using Google dictionaries is that they are +limited to specific file formats and specifications. For example, for testing +binutils and ELF file format or AVI in FFMPEG, there are no pre-built +dictionaries, so it is highly recommended to use `Autodict-QL` or `Dict2File` +features to automatically generate dictionaries based on the target. + +I've personally preferred to use `Autodict-QL` or `dict2file` rather than Google +dictionaries or any other manually generated dictionaries as `Autodict-QL` and +`dict2file` are working based on the target. In overall, fuzzing with +dictionaries and well-generated tokens will give better results. + +There are 2 important points to remember: + +- If you combine `Autodict-QL` with AFL++ cmplog, you will get much better code + coverage and hence better chances to discover new bugs. +- Do not forget to set `AFL_MAX_DET_EXTRAS` at least to the number of generated + dictionaries. If you forget to set this environment variable, then AFL++ uses + just 200 tokens and use the rest of them only probabilistically. So this will + guarantee that your tokens will be used by AFL++. \ No newline at end of file diff --git a/utils/libdislocator/README.md b/utils/libdislocator/README.md index 64a5f14c..7150c205 100644 --- a/utils/libdislocator/README.md +++ b/utils/libdislocator/README.md @@ -10,8 +10,8 @@ heap-related security bugs in several ways: subsequent PROT_NONE page, causing most off-by-one reads and writes to immediately segfault, - - It adds a canary immediately below the allocated buffer, to catch writes - to negative offsets (won't catch reads, though), + - It adds a canary immediately below the allocated buffer, to catch writes to + negative offsets (won't catch reads, though), - It sets the memory returned by malloc() to garbage values, improving the odds of crashing when the target accesses uninitialized data, @@ -19,35 +19,34 @@ heap-related security bugs in several ways: - It sets freed memory to PROT_NONE and does not actually reuse it, causing most use-after-free bugs to segfault right away, - - It forces all realloc() calls to return a new address - and sets - PROT_NONE on the original block. This catches use-after-realloc bugs, + - It forces all realloc() calls to return a new address - and sets PROT_NONE + on the original block. This catches use-after-realloc bugs, - - It checks for calloc() overflows and can cause soft or hard failures - of alloc requests past a configurable memory limit (AFL_LD_LIMIT_MB, + - It checks for calloc() overflows and can cause soft or hard failures of + alloc requests past a configurable memory limit (AFL_LD_LIMIT_MB, AFL_LD_HARD_FAIL). - Optionally, in platforms supporting it, huge pages can be used by passing USEHUGEPAGE=1 to make. - - Size alignment to `max_align_t` can be enforced with AFL_ALIGNED_ALLOC=1. - In this case, a tail canary is inserted in the padding bytes at the end - of the allocated zone. This reduce the ability of libdislocator to detect + - Size alignment to `max_align_t` can be enforced with AFL_ALIGNED_ALLOC=1. In + this case, a tail canary is inserted in the padding bytes at the end of the + allocated zone. This reduce the ability of libdislocator to detect off-by-one bugs but also it make slibdislocator compliant to the C standard. Basically, it is inspired by some of the non-default options available for the OpenBSD allocator - see malloc.conf(5) on that platform for reference. It is -also somewhat similar to several other debugging libraries, such as gmalloc -and DUMA - but is simple, plug-and-play, and designed specifically for fuzzing -jobs. +also somewhat similar to several other debugging libraries, such as gmalloc and +DUMA - but is simple, plug-and-play, and designed specifically for fuzzing jobs. Note that it does nothing for stack-based memory handling errors. The -fstack-protector-all setting for GCC / clang, enabled when using AFL_HARDEN, can catch some subset of that. The allocator is slow and memory-intensive (even the tiniest allocation uses up -4 kB of physical memory and 8 kB of virtual mem), making it completely unsuitable -for "production" uses; but it can be faster and more hassle-free than ASAN / MSAN -when fuzzing small, self-contained binaries. +4 kB of physical memory and 8 kB of virtual mem), making it completely +unsuitable for "production" uses; but it can be faster and more hassle-free than +ASAN / MSAN when fuzzing small, self-contained binaries. To use this library, run AFL++ like so: -- cgit 1.4.1