Merge pull request #1191 from llzmb/docs_quality_assurance

Docs content - quality assurance

12 files changed, 627 insertions, 469 deletions

diff --git a/docs/FAQ.md b/docs/FAQ.md
index 34ed4cf5..7869ee61 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -8,32 +8,47 @@ If you find an interesting or important question missing, submit it via
 <details>
   <summary id="what-is-the-difference-between-afl-and-aflplusplus">What is the difference between AFL and AFL++?</summary><p>
 
-  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.
-
-  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).
+  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.
+
+  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).
 </p></details>
 
 <details>
   <summary id="where-can-i-find-tutorials">Where can I find tutorials?</summary><p>
 
-  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).
 </p></details>
 
 <details>
   <summary id="what-is-an-edge">What is an "edge"?</summary><p>
 
   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 entrypoint (which can be be entered by multiple other basic blocks) and runs linearly without branching or jumping to other addresses (except at the end).
+  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).
 
   ```
   function() {
@@ -55,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
@@ -70,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.
 </p></details>
 
 ## Targets
@@ -81,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).
@@ -92,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).
 </p></details>
 
 <details>
   <summary id="how-can-i-fuzz-a-gui-program">How can I fuzz a GUI program?</summary><p>
 
-  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).
 </p></details>
 
 ## Performance
@@ -108,25 +129,33 @@ If you find an interesting or important question missing, submit it via
 <details>
   <summary id="how-can-i-improve-the-fuzzing-speed">How can I improve the fuzzing speed?</summary><p>
 
-  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).
 </p></details>
 
 <details>
   <summary id="why-is-my-stability-below-100percent">Why is my stability below 100%?</summary><p>
 
-  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 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 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).
 </p></details>
 
 ## Troubleshooting
@@ -134,7 +163,8 @@ If you find an interesting or important question missing, submit it via
 <details>
   <summary id="i-got-a-weird-compile-error-from-clang">I got a weird compile error from clang.</summary><p>
 
-  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
@@ -148,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++.
 </p></details>
\ No newline at end of file
diff --git a/docs/INSTALL.md b/docs/INSTALL.md
index cfa20dea..906d3f8e 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,26 +14,29 @@ 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
 sudo apt-get install -y build-essential python3-dev automake git flex bison libglib2.0-dev libpixman-1-dev python3-setuptools
 # 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 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
 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,24 @@ 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,23 +76,27 @@ 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)
+* LLVM_CONFIG - if your distro doesn't use the standard name for llvm-config
+  (e.g., Debian)
 
 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"
@@ -96,33 +109,35 @@ 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
     MacOS X.
-  - Some non-portable, platform-specific code may be incompatible with the
-    AFL forkserver. If you run into any problems, set `AFL_NO_FORKSRV=1` in the
+  - Some non-portable, platform-specific code may be incompatible with the AFL++
+    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
@@ -135,14 +150,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
@@ -150,4 +167,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
+[http://www.spy-hill.com/help/apple/SharedMemory.html](http://www.spy-hill.com/help/apple/SharedMemory.html)
+for documentation for these settings and how to make them permanent.
\ No newline at end of file
diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md
index e0d5a1c9..2da61cc4 100644
--- a/docs/afl-fuzz_approach.md
+++ b/docs/afl-fuzz_approach.md
@@ -37,7 +37,7 @@ superior to blind fuzzing or coverage-only tools.
 
 ## Understanding the status screen
 
-This chapter provides an overview of the status screen - plus tips for
+This section provides an overview of the status screen - plus tips for
 troubleshooting any warnings and red text shown in the UI.
 
 For the general instruction manual, see [README.md](../README.md).
@@ -103,8 +103,8 @@ will be allowed to run for months.
 
 There's one important thing to watch out for: if the tool is not finding new
 paths within several minutes of starting, you're probably not invoking the
-target binary correctly and it never gets to parse the input files we're
-throwing at it; other possible explanations are that the default memory limit
+target binary correctly and it never gets to parse the input files that are
+thrown at it; other possible explanations are that the default memory limit
 (`-m`) is too restrictive and the program exits after failing to allocate a
 buffer very early on; or that the input files are patently invalid and always
 fail a basic header check.
@@ -172,10 +172,9 @@ processed path is not "favored" (a property discussed later on).
 The section provides some trivia about the coverage observed by the
 instrumentation embedded in the target binary.
 
-The first line in the box tells you how many branch tuples we have already hit,
-in proportion to how much the bitmap can hold. The number on the left describes
-the current input; the one on the right is the value for the entire input
-corpus.
+The first line in the box tells you how many branch tuples already were hit, in
+proportion to how much the bitmap can hold. The number on the left describes the
+current input; the one on the right is the value for the entire input corpus.
 
 Be wary of extremes:
 
@@ -194,7 +193,7 @@ Be wary of extremes:
 
 The other line deals with the variability in tuple hit counts seen in the
 binary. In essence, if every taken branch is always taken a fixed number of
-times for all the inputs we have tried, this will read `1.00`. As we manage to
+times for all the inputs that were tried, this will read `1.00`. As we manage to
 trigger other hit counts for every branch, the needle will start to move toward
 `8.00` (every bit in the 8-bit map hit), but will probably never reach that
 extreme.
@@ -244,9 +243,10 @@ now. It tells you about the current stage, which can be any of:
   together two random inputs from the queue at some arbitrarily selected
   midpoint.
 - sync - a stage used only when `-M` or `-S` is set (see
-  [parallel_fuzzing.md](parallel_fuzzing.md)). No real fuzzing is involved, but
-  the tool scans the output from other fuzzers and imports test cases as
-  necessary. The first time this is done, it may take several minutes or so.
+  [fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores)).
+  No real fuzzing is involved, but the tool scans the output from other fuzzers
+  and imports test cases as necessary. The first time this is done, it may take
+  several minutes or so.
 
 The remaining fields should be fairly self-evident: there's the exec count
 progress indicator for the current stage, a global exec counter, and a benchmark
@@ -255,8 +255,8 @@ to another, but the benchmark should be ideally over 500 execs/sec most of the
 time - and if it stays below 100, the job will probably take very long.
 
 The fuzzer will explicitly warn you about slow targets, too. If this happens,
-see the [perf_tips.md](perf_tips.md) file included with the fuzzer for ideas on
-how to speed things up.
+see the [best_practices.md#improving-speed](best_practices.md#improving-speed)
+for ideas on how to speed things up.
 
 ### Findings in depth
 
@@ -295,9 +295,9 @@ exceed it by a margin sufficient to be classified as hangs.
   +-----------------------------------------------------+
 ```
 
-This is just another nerd-targeted section keeping track of how many paths we
-have netted, in proportion to the number of execs attempted, for each of the
-fuzzing strategies discussed earlier on. This serves to convincingly validate
+This is just another nerd-targeted section keeping track of how many paths were
+netted, in proportion to the number of execs attempted, for each of the fuzzing
+strategies discussed earlier on. This serves to convincingly validate
 assumptions about the usefulness of the various approaches taken by afl-fuzz.
 
 The trim strategy stats in this section are a bit different than the rest. The
@@ -339,16 +339,16 @@ fuzzing yet. The same stat is also given for "favored" entries that the fuzzer
 really wants to get to in this queue cycle (the non-favored entries may have to
 wait a couple of cycles to get their chance).
 
-Next, we have the number of new paths found during this fuzzing section and
-imported from other fuzzer instances when doing parallelized fuzzing; and the
-extent to which identical inputs appear to sometimes produce variable behavior
-in the tested binary.
+Next is the number of new paths found during this fuzzing section and imported
+from other fuzzer instances when doing parallelized fuzzing; and the extent to
+which identical inputs appear to sometimes produce variable behavior in the
+tested binary.
 
 That last bit is actually fairly interesting: it measures the consistency of
 observed traces. If a program always behaves the same for the same input data,
 it will earn a score of 100%. When the value is lower but still shown in purple,
 the fuzzing process is unlikely to be negatively affected. If it goes into red,
-you may be in trouble, since AFL will have difficulty discerning between
+you may be in trouble, since AFL++ will have difficulty discerning between
 meaningful and "phantom" effects of tweaking the input file.
 
 Now, most targets will just get a 100% score, but when you see lower figures,
@@ -397,7 +397,8 @@ comparing it to the number of logical cores on the system.
 
 If the value is shown in green, you are using fewer CPU cores than available on
 your system and can probably parallelize to improve performance; for tips on how
-to do that, see [parallel_fuzzing.md](parallel_fuzzing.md).
+to do that, see
+[fuzzing_in_depth.md:3c) Using multiple cores](fuzzing_in_depth.md#c-using-multiple-cores).
 
 If the value is shown in red, your CPU is *possibly* oversubscribed, and running
 additional fuzzers may not give you any benefits.
@@ -425,8 +426,7 @@ There are three subdirectories created within the output directory and updated
 in real-time:
 
 - queue/   - test cases for every distinctive execution path, plus all the
-             starting files given by the user. This is the synthesized corpus
-             mentioned in section 2.
+             starting files given by the user. This is the synthesized corpus.
 
              Before using this corpus for any other purposes, you can shrink
              it to a smaller size using the afl-cmin tool. The tool will find
@@ -447,8 +447,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
 
@@ -468,6 +468,8 @@ cd ../../
 sudo make install
 ```
 
+To learn more about remote monitoring and metrics visualization with StatsD, see
+[rpc_statsd.md](rpc_statsd.md).
 
 ### Addendum: status and plot files
 
@@ -505,8 +507,8 @@ 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_version`       - the version of AFL used
+- `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
 
@@ -523,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`,
@@ -536,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/best_practices.md b/docs/best_practices.md
index 18096851..96c6e3c2 100644
--- a/docs/best_practices.md
+++ b/docs/best_practices.md
@@ -19,7 +19,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 target with dlopen instrumented libraries
 
@@ -48,11 +49,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
 
@@ -61,87 +67,126 @@ 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
+- 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.
+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
 
-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
 
-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.
+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.
+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)
 
-     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
 
      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 b1dfd309..7b4e0516 100644
--- a/docs/custom_mutators.md
+++ b/docs/custom_mutators.md
@@ -1,16 +1,16 @@
 # Custom Mutators in AFL++
 
 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
+For now, we support C/C++ library and Python module, collectively named as the
 custom mutator.
 
-There is also experimental support for Rust in `custom_mutators/rust`.
-Please refer to that directory for documentation.
-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 (<yakdan@code-intelligence.de>)
+- C/C++ library (`*.so`): Khaled Yakdan from Code Intelligence
+  (<yakdan@code-intelligence.de>)
 - Python module: Christian Holler from Mozilla (<choller@mozilla.com>)
 
 ## 1) Introduction
@@ -21,13 +21,17 @@ fuzzing by using libraries that perform mutations according to a given grammar.
 
 The custom mutator is passed to `afl-fuzz` via the `AFL_CUSTOM_MUTATOR_LIBRARY`
 or `AFL_PYTHON_MODULE` environment variable, and must export a fuzz function.
-Now AFL also supports multiple custom mutators which can be specified in the same `AFL_CUSTOM_MUTATOR_LIBRARY` environment variable like this.
+Now AFL++ also supports multiple custom mutators which can be specified in the
+same `AFL_CUSTOM_MUTATOR_LIBRARY` environment variable like this.
+
 ```bash
 export AFL_CUSTOM_MUTATOR_LIBRARY="full/path/to/mutator_first.so;full/path/to/mutator_second.so"
 ```
-Please see [APIs](#2-apis) and [Usage](#3-usage) for detail.
 
-The custom mutation stage is set to be the first non-deterministic stage (right before the havoc stage).
+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).
 
 Note: If `AFL_CUSTOM_MUTATOR_ONLY` is set, all mutations will solely be
 performed with the custom mutator.
@@ -35,6 +39,7 @@ performed with the custom mutator.
 ## 2) APIs
 
 C/C++:
+
 ```c
 void *afl_custom_init(afl_state_t *afl, unsigned int seed);
 unsigned int afl_custom_fuzz_count(void *data, const unsigned char *buf, size_t buf_size);
@@ -53,6 +58,7 @@ void afl_custom_deinit(void *data);
 ```
 
 Python:
+
 ```python
 def init(seed):
     pass
@@ -101,7 +107,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):
 
@@ -110,27 +117,26 @@ 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):
 
     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):
 
@@ -142,21 +148,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):
 
@@ -168,8 +174,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
 
@@ -177,8 +183,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
@@ -189,8 +195,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
@@ -202,21 +209,21 @@ trimmed input. Here's a quick API description:
 - `trim` (optional)
 
     This method is called for each trimming operation. It doesn't have any
-    arguments because we already have the initial buffer from `init_trim` and we
-    can memorize the current state in the data variables. This can also save
+    arguments because there is already the initial buffer from `init_trim` and
+    we can memorize the current state in the data variables. This can also save
     reparsing steps for each iteration. It should return the trimmed input
     buffer.
 
 - `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 builtin default trimming routine.
+and trigger a fallback to the built-in default trimming routine.
 
 ### Environment Variables
 
@@ -224,11 +231,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`
 
@@ -264,22 +270,27 @@ In case your setup is different, set the necessary variables like this:
 ### Custom Mutator Preparation
 
 For C/C++ mutators, the source code must be compiled as a shared object:
+
 ```bash
 gcc -shared -Wall -O3 example.c -o example.so
 ```
-Note that if you specify multiple custom mutators, the corresponding functions will
-be called in the order in which they are specified. e.g first `post_process` function of
-`example_first.so` will be called and then that of `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., the first
+`post_process` function of `example_first.so` will be called and then that of
+`example_second.so`.
 
 ### Run
 
 C/C++
+
 ```bash
 export AFL_CUSTOM_MUTATOR_LIBRARY="/full/path/to/example_first.so;/full/path/to/example_second.so"
 afl-fuzz /path/to/program
 ```
 
 Python
+
 ```bash
 export PYTHONPATH=`dirname /full/path/to/example.py`
 export AFL_PYTHON_MODULE=example
@@ -288,8 +299,8 @@ afl-fuzz /path/to/program
 
 ## 4) Example
 
-Please see [example.c](../custom_mutators/examples/example.c) and
-[example.py](../custom_mutators/examples/example.py)
+See [example.c](../custom_mutators/examples/example.c) and
+[example.py](../custom_mutators/examples/example.py).
 
 ## 5) Other Resources
 
@@ -297,4 +308,4 @@ Please 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 c1c70ec5..c45f4ab9 100644
--- a/docs/env_variables.md
+++ b/docs/env_variables.md
@@ -59,9 +59,9 @@ fairly broad use of environment variables instead:
     otherwise.
 
   - By default, the wrapper appends `-O3` to optimize builds. Very rarely, this
-    will cause problems in programs built with -Werror, simply because `-O3`
-    enables more thorough code analysis and can spew out additional warnings. To
-    disable optimizations, set `AFL_DONT_OPTIMIZE`. However, if `-O...` and/or
+    will cause problems in programs built with -Werror, because `-O3` enables
+    more thorough code analysis and can spew out additional warnings. To disable
+    optimizations, set `AFL_DONT_OPTIMIZE`. However, if `-O...` and/or
     `-fno-unroll-loops` are set, these are not overridden.
 
   - Setting `AFL_HARDEN` automatically adds code hardening options when invoking
@@ -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).
@@ -109,7 +109,7 @@ fairly broad use of environment variables instead:
     - `AFL_USE_MSAN=1` - activates the memory sanitizer (uninitialized memory)
     - `AFL_USE_TSAN=1` - activates the thread sanitizer to find thread race
       conditions
-    - `AFL_USE_UBSAN=1` - activates the undefined behaviour sanitizer
+    - `AFL_USE_UBSAN=1` - activates the undefined behavior sanitizer
 
   - `TMPDIR` is used by afl-as for temporary files; if this variable is not set,
     the tool defaults to /tmp.
@@ -307,7 +307,7 @@ checks or alter some of the more exotic semantics of the tool:
     (`-i in`). This is an important feature to set when resuming a fuzzing
     session.
 
-  - Setting `AFL_CRASH_EXITCODE` sets the exit code AFL treats as crash. For
+  - Setting `AFL_CRASH_EXITCODE` sets the exit code AFL++ treats as crash. For
     example, if `AFL_CRASH_EXITCODE='-1'` is set, each input resulting in a `-1`
     return code (i.e. `exit(-1)` got called), will be treated as if a crash had
     occurred. This may be beneficial if you look for higher-level faulty
@@ -319,8 +319,8 @@ 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
-    XML or other highly flexible structured input. Please see
+    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).
 
   - Setting `AFL_CYCLE_SCHEDULES` will switch to a different schedule every time
@@ -336,7 +336,7 @@ checks or alter some of the more exotic semantics of the tool:
   - Setting `AFL_DISABLE_TRIM` tells afl-fuzz not to trim test cases. This is
     usually a bad idea!
 
-  - `AFL_EXIT_ON_SEED_ISSUES` will restore the vanilla afl-fuzz behaviour which
+  - `AFL_EXIT_ON_SEED_ISSUES` will restore the vanilla afl-fuzz behavior which
     does not allow crashes or timeout seeds in the initial -i corpus.
 
   - `AFL_EXIT_ON_TIME` causes afl-fuzz to terminate if no new paths were found
@@ -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
@@ -553,26 +553,26 @@ The QEMU wrapper used to instrument binary-only code supports several settings:
     and sub in x86 and x86_64. This is an alias of `AFL_COMPCOV_LEVEL=1` when
     `AFL_COMPCOV_LEVEL` is not specified.
 
-  - With `AFL_QEMU_FORCE_DFL` you force QEMU to ignore the registered signal
+  - With `AFL_QEMU_FORCE_DFL`, you force QEMU to ignore the registered signal
     handlers of the target.
 
   - When the target is i386/x86_64, you can specify the address of the function
     that has to be the body of the persistent loop using
     `AFL_QEMU_PERSISTENT_ADDR=start addr`.
 
-  - With `AFL_QEMU_PERSISTENT_GPR=1` QEMU will save the original value of
+  - With `AFL_QEMU_PERSISTENT_GPR=1`, QEMU will save the original value of
     general purpose registers and restore them in each persistent cycle.
 
   - Another modality to execute the persistent loop is to specify also the
-    `AFL_QEMU_PERSISTENT_RET=end addr` env variable. With this variable
+    `AFL_QEMU_PERSISTENT_RET=end addr` environment variable. With this variable
     assigned, instead of patching the return address, the specified instruction
     is transformed to a jump towards `start addr`.
 
-  - With `AFL_QEMU_PERSISTENT_RETADDR_OFFSET` you can specify the offset from
+  - With `AFL_QEMU_PERSISTENT_RETADDR_OFFSET`, you can specify the offset from
     the stack pointer in which QEMU can find the return address when `start
     addr` is hit.
 
-  - With `AFL_USE_QASAN` you can enable QEMU AddressSanitizer for dynamically
+  - With `AFL_USE_QASAN`, you can enable QEMU AddressSanitizer for dynamically
     linked binaries.
 
   - The underlying QEMU binary will recognize any standard "user space
@@ -583,86 +583,89 @@ The QEMU wrapper used to instrument binary-only code supports several settings:
 
 The FRIDA wrapper used to instrument binary-only code supports many of the same
 options as `afl-qemu-trace`, but also has a number of additional advanced
-options. These are listed in brief below (see [here](../frida_mode/README.md)
-for more details). These settings are provided for compatibiltiy with QEMU mode,
-the preferred way to configure FRIDA mode is through its
-[scripting](../frida_mode/Scripting.md) support.
+options. These are listed in brief below (see
+[frida_mode/README.md](../frida_mode/README.md) for more details). These
+settings are provided for compatibility with QEMU mode, the preferred way to
+configure FRIDA mode is through its [scripting](../frida_mode/Scripting.md)
+support.
 
 * `AFL_FRIDA_DEBUG_MAPS` - See `AFL_QEMU_DEBUG_MAPS`
 * `AFL_FRIDA_DRIVER_NO_HOOK` - See `AFL_QEMU_DRIVER_NO_HOOK`. When using the
-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.
-* `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`.
+  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`.
 * `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 [frida_mode/Scripting.md](../frida_mode/Scripting.md) for details.
 * `AFL_FRIDA_OUTPUT_STDOUT` - Redirect the standard output of the target
-application to the named file (supersedes the setting of `AFL_DEBUG_CHILD`)
+  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 simply because a new path is
-found does not mean a new block needs to be compiled. It could simply be that
-the existing blocks instrumented have been executed in a different order.
+  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/features.md b/docs/features.md
index 35a869a9..431d9eb1 100644
--- a/docs/features.md
+++ b/docs/features.md
@@ -1,10 +1,10 @@
 # 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)|
+| 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        |                  |
@@ -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
@@ -30,16 +30,16 @@ 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
 
 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 290c9bec..5434a22c 100644
--- a/docs/fuzzing_binary-only_targets.md
+++ b/docs/fuzzing_binary-only_targets.md
@@ -12,18 +12,19 @@ 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 is the "native" solution to the program. It is available in the
+### QEMU mode
+
+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 +38,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 +51,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 +73,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:
@@ -84,16 +86,17 @@ 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
+### 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
@@ -104,16 +107,16 @@ For additional instructions and caveats, see
 [frida_mode/README.md](../frida_mode/README.md).
 
 If possible, you should use the persistent mode, see
-[qemu_frida/README.md](../qemu_frida/README.md). The mode is approximately 2-5x
-slower than compile-time instrumentation, and is less conducive to
-parallelization. But for binary-only fuzzing, it gives a huge speed improvement
-if it is possible to use.
+[instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md).
+The mode is approximately 2-5x slower than compile-time instrumentation, and is
+less conducive to parallelization. But for binary-only fuzzing, it gives a huge
+speed improvement if it is possible to use.
 
 If you want to fuzz a binary-only library, then you can fuzz it with frida-gum
 via frida_mode/. You will have to write a harness to call the target function in
 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.
@@ -129,8 +132,7 @@ Unicorn is a fork of QEMU. The instrumentation is, therefore, very similar. In
 contrast to QEMU, Unicorn does not offer a full system or even userland
 emulation. Runtime environment and/or loaders have to be written from scratch,
 if needed. On top, block chaining has been removed. This means the speed boost
-introduced in the patched QEMU Mode of AFL++ cannot simply be ported over to
-Unicorn.
+introduced in the patched QEMU Mode of AFL++ cannot be ported over to Unicorn.
 
 For non-Linux binaries, you can use AFL++'s unicorn_mode which can emulate
 anything you want - for the price of speed and user written scripts.
@@ -149,11 +151,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).
@@ -170,9 +172,11 @@ 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 than the solutions
+native to AFL++ but don't always work.
 
 ### ZAFL
+
 ZAFL is a static rewriting platform supporting x86-64 C/C++,
 stripped/unstripped, and PIE/non-PIE binaries. Beyond conventional
 instrumentation, ZAFL's API enables transformation passes (e.g., laf-Intel,
@@ -199,13 +203,13 @@ 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 we can do with Dyninst is taking every basic block and put AFL++'s
-instrumentation code in there - and then save the binary. Afterwards, we can
-just fuzz the newly saved target binary with afl-fuzz. Sounds great? It is. The
-issue though - it is a non-trivial problem to insert instructions, which change
+So, what you can do with Dyninst is taking every basic block and putting AFL++'s
+instrumentation code in there - and then save the binary. Afterwards, just fuzz
+the newly saved target binary with afl-fuzz. Sounds great? It is. The issue
+though - it is a non-trivial problem to insert instructions, which change
 addresses in the process space, so that everything is still working afterwards.
 Hence, more often than not binaries crash when they are run.
 
@@ -275,7 +279,6 @@ There are many binary-only fuzzing frameworks. Some are great for CTFs but don't
 work with large binaries, others are very slow but have good path discovery,
 some are very hard to set-up...
 
-
 * Jackalope:
   [https://github.com/googleprojectzero/Jackalope](https://github.com/googleprojectzero/Jackalope)
 * Manticore:
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 251bbc1d..aaceb600 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -1,7 +1,7 @@
 # Fuzzing with AFL++
 
 The following describes how to fuzz with a target if source code is available.
-If you have a binary-only target, please go to
+If you have a binary-only target, go to
 [fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md).
 
 Fuzzing source code is a three-step process:
@@ -106,9 +106,9 @@ You can select the mode for the afl-cc compiler by:
 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
+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
@@ -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 penalty. 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,14 +151,14 @@ 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)
+* [instrumentation/README.llvm.md#6) AFL++ Context Sensitive Branch Coverage](../instrumentation/README.llvm.md#6-afl-context-sensitive-branch-coverage)
+* [instrumentation/README.llvm.md#7) AFL++ N-Gram Branch Coverage](../instrumentation/README.llvm.md#7-afl-n-gram-branch-coverage)
 
 AFL++ performs "never zero" counting in its bitmap. You can read more about this
 here:
-* [instrumentation/README.neverzero.md](../instrumentation/README.neverzero.md)
+* [instrumentation/README.llvm.md#8-neverzero-counters](../instrumentation/README.llvm.md#8-neverzero-counters)
 
 ### c) Selecting sanitizers
 
@@ -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.
 
@@ -175,11 +175,11 @@ 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
+* MSAN = Memory SANitizer, finds read access to uninitialized memory, e.g., 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
+* UBSAN = Undefined Behavior SANitizer, finds instances where - by the C and C++
+  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
@@ -196,24 +196,24 @@ The following sanitizers have built-in support in AFL++:
   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
+It is possible to further modify the behavior 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
+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,
-HMAC, etc. then modify the source code so that checks for these values are
+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:
+products by eliminating these checks within these AFL++ specific blocks:
 
 ```
 #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION
@@ -244,21 +244,22 @@ Then build the target. (Usually with `make`)
 
 **NOTES**
 
-1. sometimes configure and build systems are fickle and do not like stderr
+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).
+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
+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
@@ -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
@@ -302,13 +304,13 @@ 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 :-).
+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!
+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:
 
@@ -354,12 +356,15 @@ 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:
+
 `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.
@@ -369,8 +374,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
@@ -380,8 +385,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!
 
@@ -391,7 +396,7 @@ to be used in fuzzing! :-)
 
 ## 3. Fuzzing the target
 
-In this final step we fuzz the target. There are not that many important options
+In this final step, fuzz the target. There are not that many important options
 to run the target - unless you want to use many CPU cores/threads for the
 fuzzing, which will make the fuzzing much more useful.
 
@@ -413,35 +418,38 @@ 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 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.
+
+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.
+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
 [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
+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).
@@ -457,15 +465,17 @@ 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++ simply 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).
+All labels are explained in
+[afl-fuzz_approach.md#understanding-the-status-screen](afl-fuzz_approach.md#understanding-the-status-screen).
 
 ### b) Keeping memory use and timeouts in check
 
@@ -488,8 +498,8 @@ 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.
+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
@@ -503,7 +513,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,14 +532,14 @@ 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
 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
@@ -547,17 +557,16 @@ 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!
 
 ### 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, ...)
-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
@@ -609,14 +618,14 @@ e.g., `afl-plot out/default /srv/www/htdocs/plot`.
 
 ### f) Stopping fuzzing, restarting fuzzing, adding new seeds
 
-To stop an afl-fuzz run, simply press Control-C.
+To stop an afl-fuzz run, 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:
+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
@@ -649,7 +658,7 @@ 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
+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
@@ -659,15 +668,15 @@ 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
+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.
 
 ### 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
+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
+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)
@@ -722,7 +731,7 @@ just for AFL++).
 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
+  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.
@@ -800,7 +809,6 @@ then color-codes the input based on which sections appear to be critical, and
 which are not; while not bulletproof, it can often offer quick insights into
 complex file formats.
 
-
 ## 5. CI fuzzing
 
 Some notes on CI fuzzing - this fuzzing is different to normal fuzzing campaigns
diff --git a/docs/ideas.md b/docs/ideas.md
index 325e7031..52b07c26 100644
--- a/docs/ideas.md
+++ b/docs/ideas.md
@@ -1,58 +1,57 @@
 # 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
 
 ## 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/))
+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 through 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 877dfab2..d5e67f75 100644
--- a/docs/important_changes.md
+++ b/docs/important_changes.md
@@ -1,55 +1,57 @@
 # Important changes in AFL++
 
-This document lists important changes in AFL++, for example, major behaviour changes.
+This document lists important changes in AFL++, for example, major behavior
+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 behaviours:
+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 behaviours:
+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 behaviours:
+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
     with the value given being the maximum timeout. The original meaning of
     "skipping timeouts instead of abort" is now inherent to the -t option.
 
-With AFL++ 3.00 we introduced changes that break some previous AFL and AFL++
-behaviours and defaults:
+With AFL++ 3.00, we introduced changes that break some previous AFL and AFL++
+behaviors and defaults:
   * There are no llvm_mode and gcc_plugin subdirectories anymore and there is
     only one compiler: afl-cc. All previous compilers now symlink to this one.
     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 got new options like snapshotting, instrumenting specific
-    shared libraries, etc. Additionally QEMU 5.1 supports more CPU targets so
-    this is really worth it.
+  * 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.
   * 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
-    * -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
+    * 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
     * a caching of test cases can now be performed and can be modified by
-      editing config.h for TESTCASE_CACHE or by specifying the env variable
-      `AFL_TESTCACHE_SIZE` (in MB). Good values are between 50-500 (default: 50).
+      editing config.h for TESTCASE_CACHE or by specifying the environment
+      variable `AFL_TESTCACHE_SIZE` (in MB). Good values are between 50-500
+      (default: 50).
     * -M mains do not perform trimming
   * examples/ got renamed to utils/
   * libtokencap/ libdislocator/ and qdbi_mode/ were moved to utils/
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