From c31f4646cbd00f591dad3258c08ff8e56aa94420 Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Sun, 21 Nov 2021 21:11:52 +0100
Subject: Clean up docs folder

---
 utils/aflpp_driver/README.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

(limited to 'utils/aflpp_driver/README.md')

diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md
index 30e2412f..4560be2b 100644
--- a/utils/aflpp_driver/README.md
+++ b/utils/aflpp_driver/README.md
@@ -7,15 +7,15 @@ targets.
 
 Just do `afl-clang-fast++ -o fuzz fuzzer_harness.cc libAFLDriver.a [plus required linking]`.
 
-You can also sneakily do this little trick: 
+You can also sneakily do this little trick:
 If this is the clang compile command to build for libfuzzer:
   `clang++ -o fuzz -fsanitize=fuzzer fuzzer_harness.cc -lfoo`
 then just switch `clang++` with `afl-clang-fast++` and our compiler will
 magically insert libAFLDriver.a :)
 
-To use shared-memory testcases, you need nothing to do.
-To use stdin testcases give `-` as the only command line parameter.
-To use file input testcases give `@@` as the only command line parameter.
+To use shared-memory test cases, you need nothing to do.
+To use stdin test cases, give `-` as the only command line parameter.
+To use file input test cases, give `@@` as the only command line parameter.
 
 IMPORTANT: if you use `afl-cmin` or `afl-cmin.bash` then either pass `-`
 or `@@` as command line parameters.
@@ -30,8 +30,8 @@ are to be fuzzed in qemu_mode. So we compile them with clang/clang++, without
 
 `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`.
 
-
 Then just do (where the name of the binary is `fuzz`):
+
 ```
 AFL_QEMU_PERSISTENT_ADDR=0x$(nm fuzz | grep "T LLVMFuzzerTestOneInput" | awk '{print $1}')
 AFL_QEMU_PERSISTENT_HOOK=/path/to/aflpp_qemu_driver_hook.so afl-fuzz -Q ... -- ./fuzz`
@@ -40,4 +40,4 @@ AFL_QEMU_PERSISTENT_HOOK=/path/to/aflpp_qemu_driver_hook.so afl-fuzz -Q ... -- .
 if you use afl-cmin or `afl-showmap -C` with the aflpp_qemu_driver you need to
 set the set same AFL_QEMU_... (or AFL_FRIDA_...) environment variables.
 If you want to use afl-showmap (without -C) or afl-cmin.bash then you may not
-set these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`.
+set these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`.
\ No newline at end of file
-- 
cgit 1.4.1


From c85e0dc4f0e0a6deedfb7318292e1939503a10c2 Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Thu, 2 Dec 2021 20:37:21 +0100
Subject: Remove the word "we"

---
 TODO.md                                    |  2 +-
 docs/afl-fuzz_approach.md                  | 27 +++++++++++++--------------
 docs/custom_mutators.md                    |  4 ++--
 docs/fuzzing_binary-only_targets.md        |  8 ++++----
 docs/fuzzing_in_depth.md                   |  2 +-
 frida_mode/DEBUGGING.md                    |  2 +-
 instrumentation/README.instrument_list.md  |  2 +-
 unicorn_mode/samples/c/COMPILE.md          |  2 +-
 unicorn_mode/samples/persistent/COMPILE.md |  4 ++--
 unicorn_mode/samples/speedtest/README.md   |  2 +-
 utils/aflpp_driver/README.md               |  2 +-
 utils/autodict_ql/readme.md                |  2 +-
 utils/qbdi_mode/README.md                  |  5 +++--
 13 files changed, 32 insertions(+), 32 deletions(-)

(limited to 'utils/aflpp_driver/README.md')

diff --git a/TODO.md b/TODO.md
index 77fb080f..b8ac22ef 100644
--- a/TODO.md
+++ b/TODO.md
@@ -20,7 +20,7 @@ qemu_mode/frida_mode:
  - non colliding instrumentation
  - rename qemu specific envs to AFL_QEMU (AFL_ENTRYPOINT, AFL_CODE_START/END,
    AFL_COMPCOV_LEVEL?)
- - add AFL_QEMU_EXITPOINT (maybe multiple?), maybe pointless as we have
+ - add AFL_QEMU_EXITPOINT (maybe multiple?), maybe pointless as there is
    persistent mode
 
 
diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md
index 3e4faaec..242104f7 100644
--- a/docs/afl-fuzz_approach.md
+++ b/docs/afl-fuzz_approach.md
@@ -103,8 +103,8 @@ will be allowed to run for months.
 
 There's one important thing to watch out for: if the tool is not finding new
 paths within several minutes of starting, you're probably not invoking the
-target binary correctly and it never gets to parse the input files we're
-throwing at it; other possible explanations are that the default memory limit
+target binary correctly and it never gets to parse the input files that are
+thrown at it; other possible explanations are that the default memory limit
 (`-m`) is too restrictive and the program exits after failing to allocate a
 buffer very early on; or that the input files are patently invalid and always
 fail a basic header check.
@@ -172,10 +172,9 @@ processed path is not "favored" (a property discussed later on).
 The section provides some trivia about the coverage observed by the
 instrumentation embedded in the target binary.
 
-The first line in the box tells you how many branch tuples we have already hit,
-in proportion to how much the bitmap can hold. The number on the left describes
-the current input; the one on the right is the value for the entire input
-corpus.
+The first line in the box tells you how many branch tuples already were hit, in
+proportion to how much the bitmap can hold. The number on the left describes the
+current input; the one on the right is the value for the entire input corpus.
 
 Be wary of extremes:
 
@@ -194,7 +193,7 @@ Be wary of extremes:
 
 The other line deals with the variability in tuple hit counts seen in the
 binary. In essence, if every taken branch is always taken a fixed number of
-times for all the inputs we have tried, this will read `1.00`. As we manage to
+times for all the inputs that were tried, this will read `1.00`. As we manage to
 trigger other hit counts for every branch, the needle will start to move toward
 `8.00` (every bit in the 8-bit map hit), but will probably never reach that
 extreme.
@@ -295,9 +294,9 @@ exceed it by a margin sufficient to be classified as hangs.
   +-----------------------------------------------------+
 ```
 
-This is just another nerd-targeted section keeping track of how many paths we
-have netted, in proportion to the number of execs attempted, for each of the
-fuzzing strategies discussed earlier on. This serves to convincingly validate
+This is just another nerd-targeted section keeping track of how many paths were
+netted, in proportion to the number of execs attempted, for each of the fuzzing
+strategies discussed earlier on. This serves to convincingly validate
 assumptions about the usefulness of the various approaches taken by afl-fuzz.
 
 The trim strategy stats in this section are a bit different than the rest. The
@@ -339,10 +338,10 @@ fuzzing yet. The same stat is also given for "favored" entries that the fuzzer
 really wants to get to in this queue cycle (the non-favored entries may have to
 wait a couple of cycles to get their chance).
 
-Next, we have the number of new paths found during this fuzzing section and
-imported from other fuzzer instances when doing parallelized fuzzing; and the
-extent to which identical inputs appear to sometimes produce variable behavior
-in the tested binary.
+Next is the number of new paths found during this fuzzing section and imported
+from other fuzzer instances when doing parallelized fuzzing; and the extent to
+which identical inputs appear to sometimes produce variable behavior in the
+tested binary.
 
 That last bit is actually fairly interesting: it measures the consistency of
 observed traces. If a program always behaves the same for the same input data,
diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md
index 7d362950..4018d633 100644
--- a/docs/custom_mutators.md
+++ b/docs/custom_mutators.md
@@ -204,8 +204,8 @@ trimmed input. Here's a quick API description:
 - `trim` (optional)
 
     This method is called for each trimming operation. It doesn't have any
-    arguments because we already have the initial buffer from `init_trim` and we
-    can memorize the current state in the data variables. This can also save
+    arguments because there is already the initial buffer from `init_trim` and
+    we can memorize the current state in the data variables. This can also save
     reparsing steps for each iteration. It should return the trimmed input
     buffer.
 
diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md
index 2d57d0dc..c3204212 100644
--- a/docs/fuzzing_binary-only_targets.md
+++ b/docs/fuzzing_binary-only_targets.md
@@ -201,10 +201,10 @@ target at load time and then let it run - or save the binary with the changes.
 This is great for some things, e.g. fuzzing, and not so effective for others,
 e.g. malware analysis.
 
-So, what we can do with Dyninst is taking every basic block and put AFL++'s
-instrumentation code in there - and then save the binary. Afterwards, we can
-just fuzz the newly saved target binary with afl-fuzz. Sounds great? It is. The
-issue though - it is a non-trivial problem to insert instructions, which change
+So, what you can do with Dyninst is taking every basic block and putting AFL++'s
+instrumentation code in there - and then save the binary. Afterwards, just fuzz
+the newly saved target binary with afl-fuzz. Sounds great? It is. The issue
+though - it is a non-trivial problem to insert instructions, which change
 addresses in the process space, so that everything is still working afterwards.
 Hence, more often than not binaries crash when they are run.
 
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 4d2884f6..92b3cf86 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -391,7 +391,7 @@ to be used in fuzzing! :-)
 
 ## 3. Fuzzing the target
 
-In this final step we fuzz the target. There are not that many important options
+In this final step, fuzz the target. There are not that many important options
 to run the target - unless you want to use many CPU cores/threads for the
 fuzzing, which will make the fuzzing much more useful.
 
diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md
index b703ae43..207a48bf 100644
--- a/frida_mode/DEBUGGING.md
+++ b/frida_mode/DEBUGGING.md
@@ -95,7 +95,7 @@ gdb \
 ```
 
 Note:
-- We have to manually set the `__AFL_PERSISTENT` environment variable which is
+- You have to manually set the `__AFL_PERSISTENT` environment variable which is
   usually passed by `afl-fuzz`.
 - Setting breakpoints etc. is likely to interfere with FRIDA and cause spurious
   errors.
diff --git a/instrumentation/README.instrument_list.md b/instrumentation/README.instrument_list.md
index b412b600..3ed64807 100644
--- a/instrumentation/README.instrument_list.md
+++ b/instrumentation/README.instrument_list.md
@@ -128,4 +128,4 @@ Note that whitespace is ignored and comments (`# foo`) are supported.
 ### 3b) UNIX-style pattern matching
 
 You can add UNIX-style pattern matching in the "instrument file list" entries.
-See `man fnmatch` for the syntax. We do not set any of the `fnmatch` flags.
\ No newline at end of file
+See `man fnmatch` for the syntax. Do not set any of the `fnmatch` flags.
\ No newline at end of file
diff --git a/unicorn_mode/samples/c/COMPILE.md b/unicorn_mode/samples/c/COMPILE.md
index 7da140f7..4e3cf568 100644
--- a/unicorn_mode/samples/c/COMPILE.md
+++ b/unicorn_mode/samples/c/COMPILE.md
@@ -19,4 +19,4 @@ was built in case you want to rebuild it or recompile it for any reason.
 
 The pre-built binary (persistent_target_x86_64) was built using -g -O0 in gcc.
 
-We then load the binary and execute the main function directly.
+Then load the binary and execute the main function directly.
diff --git a/unicorn_mode/samples/persistent/COMPILE.md b/unicorn_mode/samples/persistent/COMPILE.md
index 9f2ae718..5e607aef 100644
--- a/unicorn_mode/samples/persistent/COMPILE.md
+++ b/unicorn_mode/samples/persistent/COMPILE.md
@@ -3,7 +3,7 @@
 This shows a simple persistent harness for unicornafl in C.
 In contrast to the normal c harness, this harness manually resets the unicorn
 state on each new input.
-Thanks to this, we can rerun the test case in unicorn multiple times, without
+Thanks to this, you can rerun the test case in unicorn multiple times, without
 the need to fork again.
 
 ## Compiling sample.c
@@ -25,4 +25,4 @@ was built in case you want to rebuild it or recompile it for any reason.
 The pre-built binary (persistent_target_x86_64.bin) was built using -g -O0 in
 gcc.
 
-We then load the binary and we execute the main function directly.
\ No newline at end of file
+Then load the binary and execute the main function directly.
\ No newline at end of file
diff --git a/unicorn_mode/samples/speedtest/README.md b/unicorn_mode/samples/speedtest/README.md
index 3c1184a2..496d75cd 100644
--- a/unicorn_mode/samples/speedtest/README.md
+++ b/unicorn_mode/samples/speedtest/README.md
@@ -44,7 +44,7 @@ was built in case you want to rebuild it or recompile it for any reason.
 
 The pre-built binary (simple_target_x86_64.bin) was built using -g -O0 in gcc.
 
-We then load the binary and execute the main function directly.
+Then load the binary and execute the main function directly.
 
 ## Addresses for the harness:
 To find the address (in hex) of main, run:
diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md
index 4560be2b..d534cd7f 100644
--- a/utils/aflpp_driver/README.md
+++ b/utils/aflpp_driver/README.md
@@ -25,7 +25,7 @@ or `@@` as command line parameters.
 Note that you can use the driver too for frida_mode (`-O`).
 
 aflpp_qemu_driver is used for libfuzzer `LLVMFuzzerTestOneInput()` targets that
-are to be fuzzed in qemu_mode. So we compile them with clang/clang++, without
+are to be fuzzed in qemu_mode. So compile them with clang/clang++, without
 -fsantize=fuzzer or afl-clang-fast, and link in libAFLQemuDriver.a:
 
 `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`.
diff --git a/utils/autodict_ql/readme.md b/utils/autodict_ql/readme.md
index a28f1725..491ec85b 100644
--- a/utils/autodict_ql/readme.md
+++ b/utils/autodict_ql/readme.md
@@ -37,7 +37,7 @@ sudo apt install build-essential libtool-bin python3-dev python3 automake git vi
 ```
 The usage of Autodict-QL is pretty easy. But let's describe it as:
 
-1. First of all, you need to have CodeQL installed on the system. we make this possible with `build-codeql.sh` bash script. This script will install CodeQL completety and will set the required environment variables for your system.
+1. First of all, you need to have CodeQL installed on the system. We make this possible with `build-codeql.sh` bash script. This script will install CodeQL completety and will set the required environment variables for your system.
 Do the following :
 ```shell
 # chmod +x codeql-build.sh
diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md
index cd59fb9c..c8d46fca 100755
--- a/utils/qbdi_mode/README.md
+++ b/utils/qbdi_mode/README.md
@@ -131,7 +131,8 @@ int target_func(char *buf, int size) {
 
 This could be built to `libdemo.so`.
 
-Then we should load the library in template.cpp and find the `target` function address.
+Then load the library in template.cpp and find the `target` function address:
+
 ```c
     void *handle = dlopen(lib_path, RTLD_LAZY);
 	..........................................
@@ -140,7 +141,7 @@ Then we should load the library in template.cpp and find the `target` function a
     p_target_func = (target_func)dlsym(handle, "target_func");
 ```
 
-then we read the data from file and call the function in `fuzz_func`
+Then read the data from file and call the function in `fuzz_func`:
 
 ```c
 QBDI_NOINLINE int fuzz_func() {
-- 
cgit 1.4.1


From 6eab6a55af74754cd0229012f1c9543c0c3cb2a7 Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Sat, 4 Dec 2021 21:14:50 +0100
Subject: Fix spelling of "FRIDA mode" and "QEMU mode"

---
 TODO.md                             |  2 +-
 docs/INSTALL.md                     |  4 ++--
 docs/features.md                    |  8 ++++----
 docs/fuzzing_binary-only_targets.md | 35 ++++++++++++++++++-----------------
 docs/important_changes.md           |  8 ++++----
 instrumentation/README.llvm.md      |  2 +-
 qemu_mode/libqasan/README.md        |  2 +-
 utils/README.md                     |  2 +-
 utils/afl_untracer/README.md        |  2 +-
 utils/aflpp_driver/README.md        |  4 ++--
 utils/qbdi_mode/README.md           |  2 +-
 11 files changed, 36 insertions(+), 35 deletions(-)

(limited to 'utils/aflpp_driver/README.md')

diff --git a/TODO.md b/TODO.md
index 04f3abab..e6b095fc 100644
--- a/TODO.md
+++ b/TODO.md
@@ -16,7 +16,7 @@
 
 ## Further down the road
 
-qemu_mode/frida_mode:
+QEMU mode/FRIDA mode:
  - non colliding instrumentation
  - rename qemu specific envs to AFL_QEMU (AFL_ENTRYPOINT, AFL_CODE_START/END,
    AFL_COMPCOV_LEVEL?)
diff --git a/docs/INSTALL.md b/docs/INSTALL.md
index 08d3283e..9d1309fe 100644
--- a/docs/INSTALL.md
+++ b/docs/INSTALL.md
@@ -23,7 +23,7 @@ sudo apt-get install -y build-essential python3-dev automake git flex bison libg
 # try to install llvm 11 and install the distro default if that fails
 sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang
 sudo apt-get install -y gcc-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-plugin-dev libstdc++-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-dev
-sudo apt-get install -y ninja-build # for qemu_mode
+sudo apt-get install -y ninja-build # for QEMU mode
 git clone https://github.com/AFLplusplus/AFLplusplus
 cd AFLplusplus
 make distrib
@@ -33,7 +33,7 @@ sudo make install
 It is recommended to install the newest available gcc, clang and llvm-dev
 possible in your distribution!
 
-Note that "make distrib" also builds instrumentation, qemu_mode, unicorn_mode
+Note that "make distrib" also builds instrumentation, QEMU mode, unicorn_mode
 and more. If you just want plain AFL++, then do "make all". However, compiling
 and using at least instrumentation is highly recommended for much better results
 - hence in this case choose:
diff --git a/docs/features.md b/docs/features.md
index fb688a64..06b1bcbe 100644
--- a/docs/features.md
+++ b/docs/features.md
@@ -4,7 +4,7 @@ AFL++ supports llvm from 3.8 up to version 12, very fast binary fuzzing with
 QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full
 *BSD, Mac OS, Solaris and Android support and much, much, much more.
 
-| Feature/Instrumentation  | afl-gcc | llvm      | gcc_plugin | frida_mode(9)    | qemu_mode(10)    |unicorn_mode(10)  |coresight_mode(11)|
+| Feature/Instrumentation  | afl-gcc | llvm      | gcc_plugin | FRIDA mode(9)    | QEMU mode(10)    |unicorn_mode(10)  |coresight_mode(11)|
 | -------------------------|:-------:|:---------:|:----------:|:----------------:|:----------------:|:----------------:|:----------------:|
 | Threadsafe counters      |         |     x(3)  |            |                  |                  |                  |                  |
 | NeverZero                | x86[_64]|     x(1)  |     x      |         x        |         x        |         x        |                  |
@@ -37,9 +37,9 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full
 
 Among others, the following features and patches have been integrated:
 
-* NeverZero patch for afl-gcc, instrumentation, qemu_mode and unicorn_mode which
+* NeverZero patch for afl-gcc, instrumentation, QEMU mode and unicorn_mode which
   prevents a wrapping map value to zero, increases coverage
-* Persistent mode, deferred forkserver and in-memory fuzzing for qemu_mode
+* Persistent mode, deferred forkserver and in-memory fuzzing for QEMU mode
 * Unicorn mode which allows fuzzing of binaries from completely different
   platforms (integration provided by domenukk)
 * The new CmpLog instrumentation for LLVM and QEMU inspired by
@@ -51,7 +51,7 @@ Among others, the following features and patches have been integrated:
   [https://github.com/puppet-meteor/MOpt-AFL](https://github.com/puppet-meteor/MOpt-AFL)
 * LLVM mode Ngram coverage by Adrian Herrera
   [https://github.com/adrianherrera/afl-ngram-pass](https://github.com/adrianherrera/afl-ngram-pass)
-* LAF-Intel/CompCov support for instrumentation, qemu_mode and unicorn_mode
+* LAF-Intel/CompCov support for instrumentation, QEMU mode and unicorn_mode
   (with enhanced capabilities)
 * Radamsa and honggfuzz mutators (as custom mutators).
 * QBDI mode to fuzz android native libraries via Quarkslab's
diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md
index b3d9ca02..15155111 100644
--- a/docs/fuzzing_binary-only_targets.md
+++ b/docs/fuzzing_binary-only_targets.md
@@ -12,18 +12,18 @@ fuzzed with AFL++.
 
 ## TL;DR:
 
-Qemu_mode in persistent mode is the fastest - if the stability is high enough.
+QEMU mode in persistent mode is the fastest - if the stability is high enough.
 Otherwise, try RetroWrite, Dyninst, and if these fail, too, then try standard
-qemu_mode with AFL_ENTRYPOINT to where you need it.
+QEMU mode with `AFL_ENTRYPOINT` to where you need it.
 
-If your target is a library, then use frida_mode.
+If your target is a library, then use FRIDA mode.
 
 If your target is non-linux, then use unicorn_mode.
 
 ## Fuzzing binary-only targets with AFL++
-### Qemu_mode
+### QEMU mode
 
-Qemu_mode is the "native" solution to the program. It is available in the
+QEMU mode is the "native" solution to the program. It is available in the
 ./qemu_mode/ directory and, once compiled, it can be accessed by the afl-fuzz -Q
 command line option. It is the easiest to use alternative and even works for
 cross-platform binaries.
@@ -37,11 +37,12 @@ cd qemu_mode
 ./build_qemu_support.sh
 ```
 
-The following setup to use qemu_mode is recommended:
+The following setup to use QEMU mode is recommended:
+
 * run 1 afl-fuzz -Q instance with CMPLOG (`-c 0` + `AFL_COMPCOV_LEVEL=2`)
 * run 1 afl-fuzz -Q instance with QASAN (`AFL_USE_QASAN=1`)
 * run 1 afl-fuzz -Q instance with LAF (`AFL_PRELOAD=libcmpcov.so` +
-  `AFL_COMPCOV_LEVEL=2`), alternatively you can use frida_mode, just switch `-Q`
+  `AFL_COMPCOV_LEVEL=2`), alternatively you can use FRIDA mode, just switch `-Q`
   with `-O` and remove the LAF instance
 
 Then run as many instances as you have cores left with either -Q mode or - even
@@ -49,16 +50,16 @@ better - use a binary rewriter like Dyninst, RetroWrite, ZAFL, etc.
 
 If [afl-dyninst](https://github.com/vanhauser-thc/afl-dyninst) works for your
 binary, then you can use afl-fuzz normally and it will have twice the speed
-compared to qemu_mode (but slower than qemu persistent mode). Note that several
+compared to QEMU mode (but slower than QEMU persistent mode). Note that several
 other binary rewriters exist, all with their advantages and caveats.
 
-The speed decrease of qemu_mode is at about 50%. However, various options exist
+The speed decrease of QEMU mode is at about 50%. However, various options exist
 to increase the speed:
 - using AFL_ENTRYPOINT to move the forkserver entry to a later basic block in
   the binary (+5-10% speed)
 - using persistent mode
   [qemu_mode/README.persistent.md](../qemu_mode/README.persistent.md) this will
-  result in a 150-300% overall speed increase - so 3-8x the original qemu_mode
+  result in a 150-300% overall speed increase - so 3-8x the original QEMU mode
   speed!
 - using AFL_CODE_START/AFL_CODE_END to only instrument specific parts
 
@@ -71,7 +72,7 @@ conducive to parallelization.
 
 Note that there is also honggfuzz:
 [https://github.com/google/honggfuzz](https://github.com/google/honggfuzz) which
-now has a qemu_mode, but its performance is just 1.5% ...
+now has a QEMU mode, but its performance is just 1.5% ...
 
 If you like to code a customized fuzzer without much work, we highly recommend
 to check out our sister project libafl which supports QEMU, too:
@@ -87,14 +88,14 @@ It is included in AFL++.
 For more information, see
 [qemu_mode/README.wine.md](../qemu_mode/README.wine.md).
 
-### Frida_mode
+### FRIDA mode
 
-In frida_mode, you can fuzz binary-only targets as easily as with QEMU.
-Frida_mode is sometimes faster and sometimes slower than Qemu_mode. It is also
+In FRIDA mode, you can fuzz binary-only targets as easily as with QEMU mode.
+FRIDA mode is sometimes faster and sometimes slower than QEMU mode. It is also
 newer, lacks COMPCOV, and has the advantage that it works on MacOS (both intel
 and M1).
 
-To build frida_mode:
+To build FRIDA mode:
 
 ```shell
 cd frida_mode
@@ -149,11 +150,11 @@ For further information, check out
 
 If the goal is to fuzz a dynamic library, then there are two options available.
 For both, you need to write a small harness that loads and calls the library.
-Then you fuzz this with either frida_mode or qemu_mode and either use
+Then you fuzz this with either FRIDA mode or QEMU mode and either use
 `AFL_INST_LIBS=1` or `AFL_QEMU/FRIDA_INST_RANGES`.
 
 Another, less precise and slower option is to fuzz it with utils/afl_untracer/
-and use afl-untracer.c as a template. It is slower than frida_mode.
+and use afl-untracer.c as a template. It is slower than FRIDA mode.
 
 For more information, see
 [utils/afl_untracer/README.md](../utils/afl_untracer/README.md).
diff --git a/docs/important_changes.md b/docs/important_changes.md
index 203c5a66..d5e67f75 100644
--- a/docs/important_changes.md
+++ b/docs/important_changes.md
@@ -5,8 +5,8 @@ changes.
 
 ## From version 3.00 onwards
 
-With AFL++ 3.13-3.20, we introduce frida_mode (-O) to have an alternative for
-binary-only fuzzing. It is slower than Qemu mode but works on MacOS, Android,
+With AFL++ 3.13-3.20, we introduce FRIDA mode (`-O`) to have an alternative for
+binary-only fuzzing. It is slower than QEMU mode but works on MacOS, Android,
 iOS etc.
 
 With AFL++ 3.15, we introduced the following changes from previous behaviors:
@@ -31,8 +31,8 @@ behaviors and defaults:
     All instrumentation source code is now in the `instrumentation/` folder.
   * The gcc_plugin was replaced with a new version submitted by AdaCore that
     supports more features. Thank you!
-  * qemu_mode got upgraded to QEMU 5.1, but to be able to build this a current
-    ninja build tool version and python3 setuptools are required. qemu_mode also
+  * QEMU mode got upgraded to QEMU 5.1, but to be able to build this a current
+    ninja build tool version and python3 setuptools are required. QEMU mode also
     got new options like snapshotting, instrumenting specific shared libraries,
     etc. Additionally QEMU 5.1 supports more CPU targets so this is really worth
     it.
diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md
index c93cd312..fa025643 100644
--- a/instrumentation/README.llvm.md
+++ b/instrumentation/README.llvm.md
@@ -218,7 +218,7 @@ by Jinghan Wang, et. al.
 
 Note that the original implementation (available
 [here](https://github.com/bitsecurerlab/afl-sensitive)) is built on top of AFL's
-qemu_mode. This is essentially a port that uses LLVM vectorized instructions
+QEMU mode. This is essentially a port that uses LLVM vectorized instructions
 (available from llvm versions 4.0.1 and higher) to achieve the same results when
 compiling source code.
 
diff --git a/qemu_mode/libqasan/README.md b/qemu_mode/libqasan/README.md
index 6a65c12b..41195933 100644
--- a/qemu_mode/libqasan/README.md
+++ b/qemu_mode/libqasan/README.md
@@ -9,7 +9,7 @@ and this runtime is injected via LD_PRELOAD (so works just for dynamically
 linked binaries).
 
 The usage is super simple, just set the env var `AFL_USE_QASAN=1` when fuzzing
-in qemu mode (-Q). afl-fuzz will automatically set AFL_PRELOAD to load this
+in QEMU mode (-Q). afl-fuzz will automatically set AFL_PRELOAD to load this
 library and enable the QASan instrumentation in afl-qemu-trace.
 
 For debugging purposes, we still suggest to run the original QASan as the
diff --git a/utils/README.md b/utils/README.md
index b7eead8e..5f5745b9 100644
--- a/utils/README.md
+++ b/utils/README.md
@@ -16,7 +16,7 @@ Here's a quick overview of the stuff you can find in this directory:
                            different means, e.g., hw debugger
 
   - afl_untracer         - fuzz binary-only libraries much faster but with
-                           less coverage than qemu_mode
+                           less coverage than QEMU mode
 
   - analysis_scripts     - random -o out analysis scripts
 
diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md
index 9f41618f..3fff5f83 100644
--- a/utils/afl_untracer/README.md
+++ b/utils/afl_untracer/README.md
@@ -5,7 +5,7 @@
 afl-untracer is an example skeleton file which can easily be used to fuzz
 a closed source library.
 
-It requires less memory and is x3-5 faster than qemu_mode, however, it is way
+It requires less memory and is x3-5 faster than QEMU mode, however, it is way
 more course grained and does not provide interesting features like compcov or
 cmplog.
 
diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md
index d534cd7f..8b9fe15f 100644
--- a/utils/aflpp_driver/README.md
+++ b/utils/aflpp_driver/README.md
@@ -22,10 +22,10 @@ or `@@` as command line parameters.
 
 ## aflpp_qemu_driver
 
-Note that you can use the driver too for frida_mode (`-O`).
+Note that you can use the driver too for FRIDA mode (`-O`).
 
 aflpp_qemu_driver is used for libfuzzer `LLVMFuzzerTestOneInput()` targets that
-are to be fuzzed in qemu_mode. So compile them with clang/clang++, without
+are to be fuzzed in QEMU mode. So compile them with clang/clang++, without
 -fsantize=fuzzer or afl-clang-fast, and link in libAFLQemuDriver.a:
 
 `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`.
diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md
index c8d46fca..02dd3c74 100755
--- a/utils/qbdi_mode/README.md
+++ b/utils/qbdi_mode/README.md
@@ -2,7 +2,7 @@
 
 NOTE: this code is outdated and first would need to be adapted to the current
 AFL++ versions.
-Try frida_mode or fpicker [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) first, maybe they suite your need.
+Try FRIDA mode or fpicker [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) first, maybe they suite your need.
 
 ## 1) Introduction
 
-- 
cgit 1.4.1


From 139db40cfc243d2de4eb1584e41867e5a44a06f9 Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Sun, 5 Dec 2021 19:31:43 +0100
Subject: Fix usage and punctuation in connection with "then" and "than"

---
 docs/fuzzing_binary-only_targets.md |  2 +-
 docs/fuzzing_in_depth.md            | 32 ++++++++++++++++----------------
 instrumentation/README.llvm.md      |  2 +-
 utils/afl_network_proxy/README.md   |  2 +-
 utils/afl_untracer/README.md        |  2 +-
 utils/aflpp_driver/README.md        | 26 +++++++++++++-------------
 6 files changed, 33 insertions(+), 33 deletions(-)

(limited to 'utils/aflpp_driver/README.md')

diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md
index fd18b5c1..5434a22c 100644
--- a/docs/fuzzing_binary-only_targets.md
+++ b/docs/fuzzing_binary-only_targets.md
@@ -172,7 +172,7 @@ Fore more information, see
 
 ## Binary rewriters
 
-An alternative solution are binary rewriters. They are faster then the solutions
+An alternative solution are binary rewriters. They are faster than the solutions
 native to AFL++ but don't always work.
 
 ### ZAFL
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 29e8f817..aaceb600 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -211,7 +211,7 @@ 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
+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:
 
@@ -244,16 +244,16 @@ 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
+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
@@ -304,8 +304,8 @@ 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()
 
@@ -418,9 +418,9 @@ 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
@@ -498,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
@@ -658,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
@@ -668,13 +668,13 @@ 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
 fuzzers, etc.
diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md
index ca9ce933..d220e52c 100644
--- a/instrumentation/README.llvm.md
+++ b/instrumentation/README.llvm.md
@@ -269,7 +269,7 @@ can set:
 AFL_LLVM_SKIP_NEVERZERO=1
 ```
 
-If the target does not have extensive loops or functions that are called a lot
+If the target does not have extensive loops or functions that are called a lot,
 then this can give a small performance boost.
 
 Please note that the default counter implementations are not thread safe!
diff --git a/utils/afl_network_proxy/README.md b/utils/afl_network_proxy/README.md
index c478319a..c34463e2 100644
--- a/utils/afl_network_proxy/README.md
+++ b/utils/afl_network_proxy/README.md
@@ -1,6 +1,6 @@
 # afl-network-proxy
 
-If you want to run afl-fuzz over the network than this is what you need :)
+If you want to run afl-fuzz over the network, then this is what you need. :)
 Note that the impact on fuzzing speed will be huge, expect a loss of 90%.
 
 ## When to use this
diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md
index cd87998b..da0e0c77 100644
--- a/utils/afl_untracer/README.md
+++ b/utils/afl_untracer/README.md
@@ -15,7 +15,7 @@ Supported is so far Intel (i386/x86_64) and AARCH64.
 
 ### Modify afl-untracer.c
 
-Read and modify afl-untracer.c then `make`.
+Read and modify afl-untracer.c, then `make`.
 To adapt afl-untracer.c to your needs, read the header of the file and then
 search and edit the `STEP 1`, `STEP 2` and `STEP 3` locations.
 
diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md
index 8b9fe15f..c547aaea 100644
--- a/utils/aflpp_driver/README.md
+++ b/utils/aflpp_driver/README.md
@@ -5,20 +5,20 @@
 aflpp_driver is used to compile directly libfuzzer `LLVMFuzzerTestOneInput()`
 targets.
 
-Just do `afl-clang-fast++ -o fuzz fuzzer_harness.cc libAFLDriver.a [plus required linking]`.
+Just do `afl-clang-fast++ -o fuzz fuzzer_harness.cc libAFLDriver.a [plus
+required linking]`.
 
-You can also sneakily do this little trick:
-If this is the clang compile command to build for libfuzzer:
-  `clang++ -o fuzz -fsanitize=fuzzer fuzzer_harness.cc -lfoo`
-then just switch `clang++` with `afl-clang-fast++` and our compiler will
+You can also sneakily do this little trick: If this is the clang compile command
+to build for libfuzzer: `clang++ -o fuzz -fsanitize=fuzzer fuzzer_harness.cc
+-lfoo`, then just switch `clang++` with `afl-clang-fast++` and our compiler will
 magically insert libAFLDriver.a :)
 
-To use shared-memory test cases, you need nothing to do.
-To use stdin test cases, give `-` as the only command line parameter.
-To use file input test cases, give `@@` as the only command line parameter.
+To use shared-memory test cases, you need nothing to do. To use stdin test
+cases, give `-` as the only command line parameter. To use file input test
+cases, give `@@` as the only command line parameter.
 
-IMPORTANT: if you use `afl-cmin` or `afl-cmin.bash` then either pass `-`
-or `@@` as command line parameters.
+IMPORTANT: if you use `afl-cmin` or `afl-cmin.bash`, then either pass `-` or
+`@@` as command line parameters.
 
 ## aflpp_qemu_driver
 
@@ -38,6 +38,6 @@ AFL_QEMU_PERSISTENT_HOOK=/path/to/aflpp_qemu_driver_hook.so afl-fuzz -Q ... -- .
 ```
 
 if you use afl-cmin or `afl-showmap -C` with the aflpp_qemu_driver you need to
-set the set same AFL_QEMU_... (or AFL_FRIDA_...) environment variables.
-If you want to use afl-showmap (without -C) or afl-cmin.bash then you may not
-set these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`.
\ No newline at end of file
+set the set same AFL_QEMU_... (or AFL_FRIDA_...) environment variables. If you
+want to use afl-showmap (without -C) or afl-cmin.bash, then you may not set
+these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`.
\ No newline at end of file
-- 
cgit 1.4.1