Merge pull request #1182 from llzmb/docs_edit_readme_frida_mode_qemu_mode

Edit FRIDA mode and QEMU mode READMEs

7 files changed, 628 insertions, 559 deletions

diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md
index 69663510..9cdc5eb6 100644
--- a/frida_mode/DEBUGGING.md
+++ b/frida_mode/DEBUGGING.md
@@ -1,6 +1,8 @@
+# Debugging
+
 If you are using FRIDA mode and have hit some problems, then this guide may help
 you to diagnose any problems you are encountering. This assumes you have
-followed the [osx-lib](#test/osx-lib) example to start fuzzing your target.
+followed the [osx-lib](test/osx-lib) example to start fuzzing your target.
 
 It should be noted that attempting to debug code using gdb which has been
 instrumented in FRIDA is unlikely to be successful since the debugger will be
@@ -10,69 +12,76 @@ you are very familiar with the implementation of Stalker, the instrumented code
 generated by FRIDA is likely to be very difficult to follow. For this reason,
 the following debugging strategies are outlined below.
 
-By convention below all files should be provided with their path (they are
+By convention, all files below should be provided with their path (they are
 omitted for readability) and all items in `<braces>` are placeholders and should
 be replaced accordingly.
 
-# Select your version
+## Select your version
+
 Test with both the `dev` and `stable` branches of AFL++. The `dev` branch should
 have the very latest version containing any fixes for identified issues. The
 `stable` branch is updated less frequently, but equally might avoid a problem if
 a regression has been introduced into the `dev` branch.
 
-# Enable Diagnostic Information
-- Run your target specifying the `AFL_DEBUG_CHILD=1` environment variable. This
-  will print a lot more diagnostic information to the screen when the target
-  starts up. If you have a simple configuration issue then you will likely see a
-  warning or error message in the output.
+## Enable diagnostic information
+
+Run your target specifying the `AFL_DEBUG_CHILD=1` environment variable. This
+will print a lot more diagnostic information to the screen when the target
+starts up. If you have a simple configuration issue, then you will likely see a
+warning or error message in the output.
+
+## Check your test harness
 
-# Check your Test Harness
 If any of the following steps fail, then there is a problem with your test
-harness, or your target library. Since this is running without FRIDA mode or
+harness or your target library. Since this is running without FRIDA mode or
 `afl-fuzz` that greatly reduces the search area for your defect. This is why it
 is *VERY* important to carry out these basic steps first before taking on the
 additional complexity of debugging with FRIDA mode or `afl-fuzz`.
 
 - Run your harness outside of the fuzzer, passing it a representative seed as
   it's input `./harness <input>`.
-- Pass you harness multiple seeds to check that it is stable when running
+- Pass your harness multiple seeds to check that it is stable when running
   multiple tests as it will when running in fork server mode `./harness <input1>
   <intput2>`.
 - Build your test harness with `CFLAGS=-fsanitize=address` and
   `LDFLAGS=-fsanitize=address`. Then run it again with multiple inputs to check
-  for errors (note that when fuzzing your harness should not be built with any
+  for errors (note that when fuzzing, your harness should not be built with any
   sanitizer options).
 
-# Check the Samples
+## Check the samples
+
 FRIDA mode contains a number of different sample targets in the `test` folder.
-Have a look throught these and find one which is similar to your real target.
+Have a look through these and find one which is similar to your real target.
 Check whether you have any issues running the sample target and make sure you
-compare the command line used to launch the sample with that you are using to
-launch your real target very carefully to check for any differences. If possible
-start with one of these samples and gradually make changes one at a time
-re-testing as you go until you have migrated it to run your own target.
+compare the command line used to launch the sample with the one you are using to
+launch your real target very carefully to check for any differences. If
+possible, start with one of these samples and gradually make changes one at a
+time re-testing as you go until you have migrated it to run your own target.
 
-# FRIDA Mode
-## Basic
-First just try running your target with `LD_PRELOAD=afl-frida-trace.so ./harness
- <input>`. An error here means that your defect occurs when running with just
- FRIDA mode and isn't related to `afl-fuzz`.
+## FRIDA mode
+
+### Basic
+
+First, just try running your target with `LD_PRELOAD=afl-frida-trace.so
+ ./harness <input>`. An error here means that your defect occurs when running
+ with just FRIDA mode and isn't related to `afl-fuzz`.
 
 Now you can try commenting out the implementation of `LLVMFuzzerTestOneInput` so
 that the harness doesn't actually run your target library. This may also aid in
 narrowing down the problem.
+
 ```c
 int LLVMFuzzerTestOneInput(const unsigned char* data, size_t size){
     // fpn_crashme(data, size);
     return 0;
 }
-
 ```
 
-## Persistent Mode
+### Persistent mode
+
 If your target is ok running in basic mode, you can try running it in persistent
 mode (if that is the configuration you are having issues with) as follows (again
-outside of afl-fuzz). This time you will want to run it inside a debugger so
+outside of `afl-fuzz`). This time, you will want to run it inside a debugger so
 that you can use the debugger to send the `SIGCONT` signals (by continuing)
 usually sent by `afl-fuzz` on each iteration.
 
@@ -84,13 +93,15 @@ gdb \
   --ex 'set environment AFL_FRIDA_PERSISTENT_ADDR=<entry_address>' \
   --args ./harness <input>
 ```
-Note we have to manually set the `__AFL_PERSISTENT` environment variable which
-is usually passed by `afl-fuzz`.
 
-Note that setting breakpoints etc is likely to interfere with FRIDA and cause
-spurious errors.
+Note:
+- We 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.
 
 If this is successful, you can try additionally loading the hook library:
+
 ```bash
 gdb \
   --ex 'set environment __AFL_PERSISTENT=1' \
@@ -100,6 +111,7 @@ gdb \
   --ex 'set environment AFL_FRIDA_PERSISTENT_HOOK=frida_hook.so'
   --args ./harness <input>
 ```
+
 Note that the format of the hook used for FRIDA mode is subtly different to that
 used when running in QEMU mode as shown below. Thus the DSO used for the hook is
 not interchangeable.
@@ -112,12 +124,14 @@ void afl_persistent_hook(struct x86_64_regs *regs, uint64_t guest_base,
                          uint8_t *input_buf, uint32_t input_buf_len);
 ```
 
-## ASAN
+### ASAN
+
 It is also possible to enable ASAN (if that is the configuration you are having
-issues with) without having to use `afl-fuzz`. This can be done as follows (note
-that the name of the asan DSO may need to be changed depending on your
-platform). Note that the asan DSO must appear first in the `LD_PRELOAD`
-environment variable:
+issues with) without having to use `afl-fuzz`. This can be done as follows:
+
+Note:
+- The name of the asan DSO may need to be changed depending on your platform.
+- The asan DSO must appear first in the `LD_PRELOAD` environment variable.
 
 ```bash
 LD_PRELOAD=libclang_rt.asan-x86_64.so:afl-frida-trace.so \
@@ -132,29 +146,34 @@ DSO from coverage. Failure to do so will result in ASAN attempting to sanitize
 itself and as a result detecting failures when it attempts to update the shadow
 maps.
 
-# Printf
+## Printf
+
 If you have an idea of where things are going wrong for you, then don't be
 scared to add `printf` statements to either AFL++ or FRIDA mode itself to show
 more diagnostic information. Just be sure to set `AFL_DEBUG=1` and
 `AFL_DEBUG_CHILD=1` when you are testing it.
 
-# Core Dumps
-Lastly, if your defect only occurs when using `afl-fuzz` (e.g. when using
-`CMPLOG` which cannot be tested outside of `afl-fuzz` due to it's need for a
+## Core dumps
+
+Lastly, if your defect only occurs when using `afl-fuzz` (e.g., when using
+`CMPLOG` which cannot be tested outside of `afl-fuzz` due to its need for a
 shared memory mapping being created for it to record its data), it is possible
 to enable the creation of a core dump for post-mortem analysis.
 
-Firstly check your `/proc/sys/kernel/core_pattern` configuration is simply set
-to a filename (AFL++ encourages you to set it to the value 'core' in any case
-since it doesn't want any handler applications getting in the way). Next set
-`ulimit -c unlimited` to remove any size limitations for core files. Lastly,
-when you `afl-fuzz` set the environment variable `AFL_DEBUG=1` to enable the
-creation of the `core` file. The file should be created in the working directory
-of the target application. If there is an existing `core` file aleady there,
-then it may not be overwritten.
+Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is simply
+set to a filename (AFL++ encourages you to set it to the value `core` in any
+case since it doesn't want any handler applications getting in the way).
+
+Next, set `ulimit -c unlimited` to remove any size limitations for core files.
+
+Lastly, when you `afl-fuzz`, set the environment variable `AFL_DEBUG=1` to
+enable the creation of the `core` file. The file should be created in the
+working directory of the target application. If there is an existing `core` file
+already there, then it may not be overwritten.
+
+## Reach out
 
-# Reach out
 Get in touch on discord and ask for help. The groups are pretty active so
 someone may well be able to offer some advice. Better still, if you are able to
-create a minimal reproducer for your problem it will make it easier to diagnose
-the issue.
+create a minimal reproducer for your problem, it will make it easier to diagnose
+the issue.
\ No newline at end of file
diff --git a/frida_mode/MapDensity.md b/frida_mode/MapDensity.md
index f4ae3ace..b6a96ca0 100644
--- a/frida_mode/MapDensity.md
+++ b/frida_mode/MapDensity.md
@@ -1,8 +1,9 @@
-# Map Density
+# Map density
+
+## How coverage works
 
-# How Coverage Works
 The coverage in AFL++ works by assigning each basic block of code a unique ID
-and during execution when transitioning between blocks (e.g. by calls or jumps)
+and during execution when transitioning between blocks (e.g., by calls or jumps)
 assigning each of these edges an ID based upon the source and destination block
 ID.
 
@@ -13,11 +14,12 @@ A single dimensional cumulative byte array is also constructed where each byte
 again represents an individual edge ID, but this time, the value of the byte
 represents a range of how many times that edge has been traversed.
 
-```1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+```
+`1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+`
 
 The theory is that a new path isn't particularly interesting if an edge has been
 traversed `23` instead of `24` times for example, but is interesting if an edge
-has been traversed for the very first time, or the number of times fits within a different bucket.
+has been traversed for the very first time or the number of times fits within a
+different bucket.
 
 After each run, the count of times each edge is hit is compared to the values in
 the cumulative map and if it is different, then the input is kept as a new seed
@@ -27,19 +29,22 @@ This mechanism is described in greater detail in the seminal
 [paper](https://lcamtuf.coredump.cx/afl/technical_details.txt) on AFL by
 [lcamtuf](https://github.com/lcamtuf).
 
-# Collisions
+## Collisions
+
 In black-box fuzzing, we must assume that control may flow from any block to any
-other block, since we don't know any better. Thus for a target with `n` basic
+other block, since we don't know any better. Thus, for a target with `n` basic
 blocks of code, there are `n * n` potential edges. As we can see, even with a
 small number of edges, a very large map will be required so that we have space
 to fit them all. Even if our target only had `1024` blocks, this would require a
 map containing `1048576` entries (or 1Mb in size).
 
-Whilst this may not seem like a lot of memory, it causes problems for two reasons. Firstly, the processing step after each execution must now process much more
-data, and secondly a map this size is unlikely to fit within the L2 cache of the processor. Since this is a very hot code path, we are likely to pay a very heavy
-performance cost.
+Whilst this may not seem like a lot of memory, it causes problems for two
+reasons. Firstly, the processing step after each execution must now process much
+more data, and secondly, a map this size is unlikely to fit within the L2 cache
+of the processor. Since this is a very hot code path, we are likely to pay a
+very heavy performance cost.
 
-Therefore, we must accept that not all edges can have a unique and that
+Therefore, we must accept that not all edges can have a unique ID and that
 therefore there will be collisions. This means that if the fuzzer finds a new
 path by uncovering an edge which was not previously found, but that the same
 edge ID is used by another edge, then it may go completely unnoticed. This is
@@ -47,15 +52,15 @@ obviously undesirable, but equally if our map is too large, then we will not be
 able to process as many potential inputs in the same time and hence not uncover
 edges for that reason. Thus a careful trade-off of map size must be made.
 
-# Block & Edge Numbering
+## Block & edge numbering
+
 Since the original AFL, blocks and edges have always been numbered in the same
-way as we can see from the following C snippet from the whitepaper.
+way as we can see from the following C snippet from the whitepaper:
 
 ```c
-    cur_location = (block_address >> 4) ^ (block_address << 8);
-    shared_mem[cur_location ^ prev_location]++;
-    prev_location = cur_location >> 1;
-
+cur_location = (block_address >> 4) ^ (block_address << 8);
+shared_mem[cur_location ^ prev_location]++;
+prev_location = cur_location >> 1;
 ```
 
 Each block ID is generated by performing a shift and XOR on its address. Then
@@ -63,15 +68,16 @@ the edge ID is calculated as `E = B ^ (B' >> 1)`. Here, we can make two
 observations. In fact, the edge ID is also masked to ensure it is less than the
 size of the map being used.
 
-## Block IDs
+### Block IDs
+
 Firstly, the block ID doesn't have very good entropy. If we consider the address
 of the block, then whilst each block has a unique ID, it isn't necessarily very
 evenly distributed.
 
-We start with a large address, and need to discard a large number of the bits to
+We start with a large address and need to discard a large number of the bits to
 generate a block ID which is within range. But how do we choose the unique bits
-of the address verus those which are the same for every block? The high bits of
-the address may simply be all `0s` or all `1s` to make the address cannonical,
+of the address versus those which are the same for every block? The high bits of
+the address may simply be all `0s` or all `1s` to make the address canonical,
 the middle portion of the address may be the same for all blocks (since if they
 are all within the same binary, then they will all be adjacent in memory), and
 on some systems, even the low bits may have poor entropy as some use fixed
@@ -79,20 +85,22 @@ length aligned instructions. Then we need to consider that a portion of each
 binary may contain the `.data` or `.bss` sections and so may not contain any
 blocks of code at all.
 
-## Edge IDs
+### Edge IDs
+
 Secondly, we can observe that when we generate an edge ID from the source and
 destination block IDs, we perform a right shift on the source block ID. Whilst
 there are good reasons as set out in the whitepaper why such a transform is
-applied, in so doing, we dispose of `1` bit of precious entropy in our source
+applied, in doing so, we dispose of `1` bit of precious entropy in our source
 block ID.
 
 All together, this means that some edge IDs may be more popular than others.
-This means that some portions of the map may be very densly populated with large
-numbers of edges, whilst others may be very sparsely populated, or not populated
-at all.
+This means that some portions of the map may be very densely populated with
+large numbers of edges, whilst others may be very sparsely populated, or not
+populated at all.
+
+## Improvements
 
-# Improvements
-One of the main reaons why this algorithm selected, is performance. All of the
+One of the main reasons why this algorithm selected, is performance. All of the
 operations are very quick to perform and given we may be carrying this out for
 every block of code we execute, performance is critical.
 
@@ -106,23 +114,25 @@ only need to generate this ID once per block and so this ID generation no longer
 needs to be as performant. We can therefore use a hash algorithm to generate
 this ID and therefore ensure that the block IDs are more evenly distributed.
 
-Edge IDs however, can only be determined at run-time. Since we don't know which
+Edge IDs, however, can only be determined at run-time. Since we don't know which
 blocks a given input will traverse until we run it. However, given our block IDs
 are now evenly distributed, generating an evenly distributed edge ID becomes
-simple. Here, the only change we make is to use a rotate operation rather than
-a shift operation so we don't lose a bit of entropy from the source ID.
+simple. Here, the only change we make is to use a rotate operation rather than a
+shift operation so we don't lose a bit of entropy from the source ID.
 
 So our new algorithm becomes:
+
 ```c
-    cur_location = hash(block_address)
-    shared_mem[cur_location ^ prev_location]++;
-    prev_location = rotate(cur_location, 1);
+cur_location = hash(block_address)
+shared_mem[cur_location ^ prev_location]++;
+prev_location = rotate(cur_location, 1);
 ```
 
 Lastly, in the original design, the `cur_location` was always set to `0`, at the
 beginning of a run, we instead set the value of `cur_location` to `hash(0)`.
 
-# Parallel Fuzzing
+## Parallel fuzzing
+
 Another sub-optimal aspect of the original design is that no matter how many
 instances of the fuzzer you ran in parallel, each instance numbered each block
 and so each edge with the same ID. Each instance would therefore find the same
@@ -144,4 +154,4 @@ If only a single new edge is found, and the new path is shared with an instance
 for which that edge collides, that instance may disregard it as irrelevant. In
 practice, however, the discovery of a single new edge, likely leads to several
 more edges beneath it also being found and therefore the likelihood of all of
-these being collisions is very slim.
+these being collisions is very slim.
\ No newline at end of file
diff --git a/frida_mode/README.md b/frida_mode/README.md
index 6c46fe08..c19280e1 100644
--- a/frida_mode/README.md
+++ b/frida_mode/README.md
@@ -1,38 +1,34 @@
-# FRIDA MODE
+# FRIDA mode
 
 The purpose of FRIDA mode is to provide an alternative binary only fuzzer for
-AFL just like that provided by QEMU mode. The intention is to provide a very
+AFL++ just like that provided by QEMU mode. The intention is to provide a very
 similar user experience, right down to the options provided through environment
 variables.
 
-Whilst AFLplusplus already has some support for running on FRIDA [here](https://github.com/AFLplusplus/AFLplusplus/tree/stable/utils/afl_frida)
-this requires the code to be fuzzed to be provided as a shared library, it
-cannot be used to fuzz executables. Additionally, it requires the user to write
-a small harness around their target code of interest.
-FRIDA mode instead takes a different approach to avoid these limitations.
-In Frida mode binary programs are instrumented, similarly to QEMU mode.
+In FRIDA mode, binary programs are instrumented, similarly to QEMU mode.
 
-## Current Progress
+## Current progress
 
-As FRIDA mode is new, it is missing a lot of features. The design is such that it
-should be possible to add these features in a similar manner to QEMU mode and
+As FRIDA mode is new, it is missing a lot of features. The design is such that
+it should be possible to add these features in a similar manner to QEMU mode and
 perhaps leverage some of its design and implementation.
 
-  | Feature/Instrumentation  | frida-mode | Notes                                        |
-  | -------------------------|:----------:|:--------------------------------------------:|
-  | NeverZero                |     x      |                                              |
-  | Persistent Mode          |     x      | (x86/x64/aarch64 only)                       |
-  | LAF-Intel / CompCov      |     -      | (CMPLOG is better 90% of the time)           |
-  | CMPLOG                   |     x      | (x86/x64/aarch64 only)                       |
-  | Selective Instrumentation|     x      |                                              |
-  | Non-Colliding Coverage   |     -      | (Not possible in binary-only instrumentation |
-  | Ngram prev_loc Coverage  |     -      |                                              |
-  | Context Coverage         |     -      |                                              |
-  | Auto Dictionary          |     -      |                                              |
-  | Snapshot LKM Support     |     -      |                                              |
-  | In-Memory Test Cases     |     x      | (x86/x64/aarch64 only)                       |
+| Feature/Instrumentation  | FRIDA mode | Notes                                         |
+| -------------------------|:----------:|:---------------------------------------------:|
+| NeverZero                |     x      |                                               |
+| Persistent Mode          |     x      | (x86/x64/aarch64 only)                        |
+| LAF-Intel / CompCov      |     -      | (CMPLOG is better 90% of the time)            |
+| CMPLOG                   |     x      | (x86/x64/aarch64 only)                        |
+| Selective Instrumentation|     x      |                                               |
+| Non-Colliding Coverage   |     -      | (not possible in binary-only instrumentation) |
+| Ngram prev_loc Coverage  |     -      |                                               |
+| Context Coverage         |     -      |                                               |
+| Auto Dictionary          |     -      |                                               |
+| Snapshot LKM Support     |     -      |                                               |
+| In-Memory Test Cases     |     x      | (x86/x64/aarch64 only)                        |
 
 ## Compatibility
+
 Currently FRIDA mode supports Linux and macOS targets on both x86/x64
 architecture and aarch64. Later releases may add support for aarch32 and Windows
 targets as well as embedded linux environments.
@@ -41,60 +37,58 @@ FRIDA has been used on various embedded targets using both uClibc and musl C
 runtime libraries, so porting should be possible. However, the current build
 system does not support cross compilation.
 
-## Getting Started
+## Getting started
 
-To build everything run `make`. To build for x86 run `make 32`. Note that in
+To build everything, run `make`. To build for x86, run `make 32`. Note that in
 x86 bit mode, it is not necessary for afl-fuzz to be built for 32-bit. However,
-the shared library for frida_mode must be since it is injected into the target
+the shared library for FRIDA mode must be since it is injected into the target
 process.
 
 Various tests can be found in subfolders within the `test/` directory. To use
-these, first run `make` to build any dependencies. Then run `make qemu` or
-`make frida` to run on either QEMU of FRIDA mode respectively. To run frida
-tests in 32-bit mode, run `make ARCH=x86 frida`. When switching between
-architectures it may be necessary to run `make clean` first for a given build
-target to remove previously generated binaries for a different architecture.
+these, first run `make` to build any dependencies. Then run `make qemu` or `make
+frida` to run on either QEMU of FRIDA mode respectively. To run frida tests in
+32-bit mode, run `make ARCH=x86 frida`. When switching between architectures, it
+may be necessary to run `make clean` first for a given build target to remove
+previously generated binaries for a different architecture.
 
 ### Android
 
-In order to build, you need to download the Android SDK.
+In order to build, you need to download the Android SDK:
 
-```
-https://developer.android.com/ndk/downloads
-```
+[https://developer.android.com/ndk/downloads](https://developer.android.com/ndk/downloads)
 
-Then creating locally a standalone chain as follow.
+Then creating locally a standalone chain as follows:
 
-```
-https://developer.android.com/ndk/guides/standalone_toolchain
-```
+[https://developer.android.com/ndk/guides/standalone_toolchain](https://developer.android.com/ndk/guides/standalone_toolchain)
 
 ## Usage
 
-FRIDA mode added some small modifications to `afl-fuzz` and similar tools
-in AFLplusplus. The intention was that it behaves identically to QEMU, but it uses
-the 'O' switch rather than 'Q'. Whilst the options 'f', 'F', 's' or 'S' may have
+FRIDA mode added some small modifications to `afl-fuzz` and similar tools in
+AFL++. The intention was that it behaves identically to QEMU, but it uses the
+'O' switch rather than 'Q'. Whilst the options 'f', 'F', 's' or 'S' may have
 made more sense for a mode powered by FRIDA Stalker, they were all taken, so
-instead we use 'O' in hommage to the [author](https://github.com/oleavr) of
+instead we use 'O' in homage to the [author](https://github.com/oleavr) of
 FRIDA.
 
 Similarly, the intention is to mimic the use of environment variables used by
-QEMU where possible (by replacing `s/QEMU/FRIDA/g`). Accordingly, the
-following options are currently supported:
+QEMU where possible (by replacing `s/QEMU/FRIDA/g`). Accordingly, the following
+options are currently supported:
 
-* `AFL_FRIDA_DEBUG_MAPS` - See `AFL_QEMU_DEBUG_MAPS`
-* `AFL_FRIDA_EXCLUDE_RANGES` - See `AFL_QEMU_EXCLUDE_RANGES`
-* `AFL_FRIDA_INST_RANGES` - See `AFL_QEMU_INST_RANGES`
-* `AFL_FRIDA_PERSISTENT_ADDR` - See `AFL_QEMU_PERSISTENT_ADDR`
-* `AFL_FRIDA_PERSISTENT_CNT` - See `AFL_QEMU_PERSISTENT_CNT`
-* `AFL_FRIDA_PERSISTENT_HOOK` - See `AFL_QEMU_PERSISTENT_HOOK`
-* `AFL_FRIDA_PERSISTENT_RET` - See `AFL_QEMU_PERSISTENT_RET`
+* `AFL_FRIDA_DEBUG_MAPS` - See `AFL_QEMU_DEBUG_MAPS`.
+* `AFL_FRIDA_EXCLUDE_RANGES` - See `AFL_QEMU_EXCLUDE_RANGES`.
+* `AFL_FRIDA_INST_RANGES` - See `AFL_QEMU_INST_RANGES`.
+* `AFL_FRIDA_PERSISTENT_ADDR` - See `AFL_QEMU_PERSISTENT_ADDR`.
+* `AFL_FRIDA_PERSISTENT_CNT` - See `AFL_QEMU_PERSISTENT_CNT`.
+* `AFL_FRIDA_PERSISTENT_HOOK` - See `AFL_QEMU_PERSISTENT_HOOK`.
+* `AFL_FRIDA_PERSISTENT_RET` - See `AFL_QEMU_PERSISTENT_RET`.
 
 To enable the powerful CMPLOG mechanism, set `-c 0` for `afl-fuzz`.
 
 ## Scripting
 
-One of the more powerful features of FRIDA mode is it's support for configuration by JavaScript, rather than using environment variables. For details of how this works see [here](Scripting.md).
+One of the more powerful features of FRIDA mode is it's support for
+configuration by JavaScript, rather than using environment variables. For
+details of how this works, see [Scripting.md](Scripting.md).
 
 ## Performance
 
@@ -118,7 +112,8 @@ FRIDA mode is supported by using `LD_PRELOAD` (`DYLD_INSERT_LIBRARIES` on macOS)
 to inject a shared library (`afl-frida-trace.so`) into the target. This shared
 library is built using the [frida-gum](https://github.com/frida/frida-gum)
 devkit from the [FRIDA](https://github.com/frida/frida) project. One of the
-components of frida-gum is [Stalker](https://medium.com/@oleavr/anatomy-of-a-code-tracer-b081aadb0df8),
+components of frida-gum is
+[Stalker](https://medium.com/@oleavr/anatomy-of-a-code-tracer-b081aadb0df8),
 this allows the dynamic instrumentation of running code for AARCH32, AARCH64,
 x86 and x64 architectures. Implementation details can be found
 [here](https://frida.re/docs/stalker/).
@@ -127,7 +122,8 @@ Dynamic instrumentation is used to augment the target application with similar
 coverage information to that inserted by `afl-gcc` or `afl-clang`. The shared
 library is also linked to the `compiler-rt` component of AFLplusplus to feedback
 this coverage information to AFL++ and also provide a fork server. It also makes
-use of the FRIDA [prefetch](https://github.com/frida/frida-gum/blob/56dd9ba3ee9a5511b4b0c629394bf122775f1ab7/gum/gumstalker.h#L115)
+use of the FRIDA
+[prefetch](https://github.com/frida/frida-gum/blob/56dd9ba3ee9a5511b4b0c629394bf122775f1ab7/gum/gumstalker.h#L115)
 support to feedback instrumented blocks from the child to the parent using a
 shared memory region to avoid the need to regenerate instrumented blocks on each
 fork.
@@ -146,228 +142,237 @@ instances run CMPLOG mode and instrumentation of the binary is less frequent
 
 ## Advanced configuration options
 * `AFL_FRIDA_DRIVER_NO_HOOK` - See `AFL_QEMU_DRIVER_NO_HOOK`. When using the
-QEMU driver to provide a `main` loop for a user provided
-`LLVMFuzzerTestOneInput`, this option configures the driver to read input from
-`stdin` rather than using in-memory test cases.
-* `AFL_FRIDA_INST_COVERAGE_FILE` - File to write DynamoRio format coverage
-information (e.g. to be loaded within IDA lighthouse).
+  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_INST_COVERAGE_FILE` - File to write DynamoRIO format coverage
+  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.
-```
-***
-
-Creating block for 0x7ffff7953313:
-        0x7ffff7953313  mov qword ptr [rax], 0
-        0x7ffff795331a  add rsp, 8
-        0x7ffff795331e  ret
-
-Generated block 0x7ffff75e98e2
-        0x7ffff75e98e2  mov qword ptr [rax], 0
-        0x7ffff75e98e9  add rsp, 8
-        0x7ffff75e98ed  lea rsp, [rsp - 0x80]
-        0x7ffff75e98f5  push rcx
-        0x7ffff75e98f6  movabs rcx, 0x7ffff795331e
-        0x7ffff75e9900  jmp 0x7ffff75e9384
-
-
-***
-```
+  and their instrumented counterparts during block compilation.
+
+  ```
+  ***
+
+  Creating block for 0x7ffff7953313:
+          0x7ffff7953313  mov qword ptr [rax], 0
+          0x7ffff795331a  add rsp, 8
+          0x7ffff795331e  ret
+
+  Generated block 0x7ffff75e98e2
+          0x7ffff75e98e2  mov qword ptr [rax], 0
+          0x7ffff75e98e9  add rsp, 8
+          0x7ffff75e98ed  lea rsp, [rsp - 0x80]
+          0x7ffff75e98f5  push rcx
+          0x7ffff75e98f6  movabs rcx, 0x7ffff795331e
+          0x7ffff75e9900  jmp 0x7ffff75e9384
+
+  ***
+  ```
+
 * `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_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`.
-* `AFL_FRIDA_INST_UNSTABLE_COVERAGE_FILE` - File to write DynamoRio format
-coverage information for unstable edges (e.g. to be loaded within IDA
-lighthouse).
+  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).
 * `AFL_FRIDA_JS_SCRIPT` - Set the script to be loaded by the FRIDA scripting
-engine. See [here](Scripting.md) for details.
+  engine. See [Scipting.md](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_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.
+
+  ```
+  gdb \
+      --ex 'set environment AFL_FRIDA_PERSISTENT_ADDR=XXXXXXXXXX' \
+      --ex 'set environment AFL_FRIDA_PERSISTENT_RET=XXXXXXXXXX' \
+      --ex 'set environment AFL_FRIDA_PERSISTENT_DEBUG=1' \
+      --ex 'set environment AFL_DEBUG_CHILD=1' \
+      --ex 'set environment LD_PRELOAD=afl-frida-trace.so' \
+      --args <my-executable> [my arguments]
+  ```
 
-gdb \
-		--ex 'set environment AFL_FRIDA_PERSISTENT_ADDR=XXXXXXXXXX' \
-		--ex 'set environment AFL_FRIDA_PERSISTENT_RET=XXXXXXXXXX' \
-		--ex 'set environment AFL_FRIDA_PERSISTENT_DEBUG=1' \
-		--ex 'set environment AFL_DEBUG_CHILD=1' \
-		--ex 'set environment LD_PRELOAD=afl-frida-trace.so' \
-		--args <my-executable> [my arguments]
-
-```
 * `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 locality and adjacency. This includes allowing us to vector
+  between adjacent 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.
-```
-stats
------
-Time                  2021-07-21 11:45:49
-Elapsed                                 1 seconds
-
-
-Transitions                    cumulative               delta
------------                    ----------               -----
-total                              753619               17645
-call_imm                             9193 ( 1.22%)        344 ( 1.95%) [       344/s]
-call_reg                                0 ( 0.00%)          0 ( 0.00%) [         0/s]
-call_mem                                0 ( 0.00%)          0 ( 0.00%) [         0/s]
-ret_slow_path                       67974 ( 9.02%)       2988 (16.93%) [      2988/s]
-post_call_invoke                     7996 ( 1.06%)        299 ( 1.69%) [       299/s]
-excluded_call_imm                    3804 ( 0.50%)        200 ( 1.13%) [       200/s]
-jmp_imm                              5445 ( 0.72%)        255 ( 1.45%) [       255/s]
-jmp_reg                             42081 ( 5.58%)       1021 ( 5.79%) [      1021/s]
-jmp_mem                            578092 (76.71%)      10956 (62.09%) [     10956/s]
-jmp_cond_imm                        38951 ( 5.17%)       1579 ( 8.95%) [      1579/s]
-jmp_cond_mem                            0 ( 0.00%)          0 ( 0.00%) [         0/s]
-jmp_cond_reg                            0 ( 0.00%)          0 ( 0.00%) [         0/s]
-jmp_cond_jcxz                           0 ( 0.00%)          0 ( 0.00%) [         0/s]
-jmp_continuation                       84 ( 0.01%)          3 ( 0.02%) [         3/s]
-
-
-Instrumentation
----------------
-Instructions                         7907
-Blocks                               1764
-Avg Instructions / Block                4
-
-
-EOB Instructions
-----------------
-Total                                1763 (22.30%)
-Call Immediates                       358 ( 4.53%)
-Call Immediates Excluded               74 ( 0.94%)
-Call Register                           0 ( 0.00%)
-Call Memory                             0 ( 0.00%)
-Jump Immediates                       176 ( 2.23%)
-Jump Register                           8 ( 0.10%)
-Jump Memory                            10 ( 0.13%)
-Conditional Jump Immediates          1051 (13.29%)
-Conditional Jump CX Immediate           0 ( 0.00%)
-Conditional Jump Register               0 ( 0.00%)
-Conditional Jump Memory                 0 ( 0.00%)
-Returns                               160 ( 2.02%)
-
-
-Relocated Instructions
-----------------------
-Total                                 232 ( 2.93%)
-addsd                                   2 ( 0.86%)
-cmp                                    46 (19.83%)
-comisd                                  2 ( 0.86%)
-divsd                                   2 ( 0.86%)
-divss                                   2 ( 0.86%)
-lea                                   142 (61.21%)
-mov                                    32 (13.79%)
-movsd                                   2 ( 0.86%)
-ucomisd                                 2 ( 0.86%)
-```
+  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.
+
+  ```
+  stats
+  -----
+  Time                  2021-07-21 11:45:49
+  Elapsed                                 1 seconds
+
+
+  Transitions                    cumulative               delta
+  -----------                    ----------               -----
+  total                              753619               17645
+  call_imm                             9193 ( 1.22%)        344 ( 1.95%) [       344/s]
+  call_reg                                0 ( 0.00%)          0 ( 0.00%) [         0/s]
+  call_mem                                0 ( 0.00%)          0 ( 0.00%) [         0/s]
+  ret_slow_path                       67974 ( 9.02%)       2988 (16.93%) [      2988/s]
+  post_call_invoke                     7996 ( 1.06%)        299 ( 1.69%) [       299/s]
+  excluded_call_imm                    3804 ( 0.50%)        200 ( 1.13%) [       200/s]
+  jmp_imm                              5445 ( 0.72%)        255 ( 1.45%) [       255/s]
+  jmp_reg                             42081 ( 5.58%)       1021 ( 5.79%) [      1021/s]
+  jmp_mem                            578092 (76.71%)      10956 (62.09%) [     10956/s]
+  jmp_cond_imm                        38951 ( 5.17%)       1579 ( 8.95%) [      1579/s]
+  jmp_cond_mem                            0 ( 0.00%)          0 ( 0.00%) [         0/s]
+  jmp_cond_reg                            0 ( 0.00%)          0 ( 0.00%) [         0/s]
+  jmp_cond_jcxz                           0 ( 0.00%)          0 ( 0.00%) [         0/s]
+  jmp_continuation                       84 ( 0.01%)          3 ( 0.02%) [         3/s]
+
+
+  Instrumentation
+  ---------------
+  Instructions                         7907
+  Blocks                               1764
+  Avg Instructions / Block                4
+
+
+  EOB Instructions
+  ----------------
+  Total                                1763 (22.30%)
+  Call Immediates                       358 ( 4.53%)
+  Call Immediates Excluded               74 ( 0.94%)
+  Call Register                           0 ( 0.00%)
+  Call Memory                             0 ( 0.00%)
+  Jump Immediates                       176 ( 2.23%)
+  Jump Register                           8 ( 0.10%)
+  Jump Memory                            10 ( 0.13%)
+  Conditional Jump Immediates          1051 (13.29%)
+  Conditional Jump CX Immediate           0 ( 0.00%)
+  Conditional Jump Register               0 ( 0.00%)
+  Conditional Jump Memory                 0 ( 0.00%)
+  Returns                               160 ( 2.02%)
+
+
+  Relocated Instructions
+  ----------------------
+  Total                                 232 ( 2.93%)
+  addsd                                   2 ( 0.86%)
+  cmp                                    46 (19.83%)
+  comisd                                  2 ( 0.86%)
+  divsd                                   2 ( 0.86%)
+  divss                                   2 ( 0.86%)
+  lea                                   142 (61.21%)
+  mov                                    32 (13.79%)
+  movsd                                   2 ( 0.86%)
+  ucomisd                                 2 ( 0.86%)
+  ```
+
 * `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.
-
-## FASAN - Frida Address Sanitizer Mode
-Frida mode also supports FASAN. The design of this is actually quite simple and
+  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.
+
+## FASAN - FRIDA Address Sanitizer mode
+
+FRIDA mode also supports FASAN. The design of this is actually quite simple and
 very similar to that used when instrumenting applications compiled from source.
 
-### Address Sanitizer Basics
+### Address Sanitizer basics
 
 When Address Sanitizer is used to instrument programs built from source, the
 compiler first adds a dependency (`DT_NEEDED` entry) for the Address Sanitizer
-dynamic shared object (DSO). This shared object contains the main logic for Address
-Sanitizer, including setting and managing up the shadow memory. It also provides
-replacement implementations for a number of functions in standard libraries.
-
-These replacements include things like `malloc` and `free` which allows for those
-allocations to be marked in the shadow memory, but also a number of other fuctions.
-Consider `memcpy` for example, this is instrumented to validate the paramters
-(test the source and destination buffers against the shadow memory. This is much
-easier than instrumenting those standard libraries since, first it would require
-you to re-compile them and secondly it would mean that the instrumentation would
-be applied at a more expensive granular level. Lastly, load-widening (typically
-found in highy optimized code) can also make this instrumentation more difficult.
+dynamic shared object (DSO). This shared object contains the main logic for
+Address Sanitizer, including setting and managing up the shadow memory. It also
+provides replacement implementations for a number of functions in standard
+libraries.
+
+These replacements include things like `malloc` and `free` which allows for
+those allocations to be marked in the shadow memory, but also a number of other
+functions. Consider `memcpy`, for example. This is instrumented to validate the
+parameters (test the source and destination buffers against the shadow memory).
+This is much easier than instrumenting those standard libraries, since first, it
+would require you to re-compile them and secondly it would mean that the
+instrumentation would be applied at a more expensive granular level. Lastly,
+load-widening (typically found in highly optimized code) can also make this
+instrumentation more difficult.
 
 Since the DSO is loaded before all of the standard libraries (in fact it insists
 on being first), the dynamic loader will use it to resolve imports from other
 modules which depend on it.
 
-### FASAN Implementation
+### FASAN implementation
+
+FASAN takes a similar approach. It requires the user to add the Address
+Sanitizer DSO to the `AFL_PRELOAD` environment variable such that it is loaded
+into the target. Again, it must be first in the list. This means that it is not
+necessary to instrument the standard libraries to detect when an application has
+provided an incorrect argument to `memcpy`, for example. This avoids issues with
+load-widening and should also mean a huge improvement in performance.
+
+FASAN then adds instrumentation for any instructions which use memory operands
+and then calls into the `__asan_loadN` and `__asan_storeN` functions provided by
+the DSO to validate memory accesses against the shadow memory.
+
+## Collisions
 
-FASAN takes a similar approach. It requires the user to add the Address Sanitizer
-DSO to the `AFL_PRELOAD` environment variable such that it is loaded into the target.
-Again, it must be first in the list. This means that it is not necessary to
-instrument the standard libraries to detect when an application has provided an
-incorrect argument to `memcpy` for example. This avoids issues with load-widening
-and should also mean a huge improvement in performance.
+FRIDA mode has also introduced some improvements to reduce collisions in the
+map. For details, see [MapDensity.md](MapDensity.md).
 
-FASAN then adds instrumentation for any instrucutions which use memory operands and
-then calls into the `__asan_loadN` and `__asan_storeN` functions provided by the DSO
-to validate memory accesses against the shadow memory.
+## OSX library fuzzing
 
-# Collisions
-FRIDA mode has also introduced some improvements to reduce collisions in the map.
-See [here](MapDensity.md) for details.
+An example of how to fuzz a dynamic library on OSX is included, see
+[test/osx-lib](test/osx-lib). This requires the use of a simple test harness
+executable which will load the library and call a target function within it. The
+dependent library can either be loaded in using `dlopen` and `dlsym` in a
+function marked `__attribute__((constructor()))` or the test harness can simply
+be linked against it. It is important that the target library is loaded before
+execution of `main`, since this is the point where FRIDA mode is initialized.
+Otherwise, it will not be possible to configure coverage for the test library
+using `AFL_FRIDA_INST_RANGES` or similar.
 
-# OSX Library Fuzzing
-An example of how to fuzz a dynamic library on OSX is included [here](test/osx-lib).
-This requires the use of a simple test harness executable which will load the
-library and call a target function within it. The dependent library can either
-be loaded in using `dlopen` and `dlsym` in a function marked
-`__attribute__((constructor()))` or the test harness can simply be linked
-against it. It is important that the target library is loaded before execution
-of `main`, since this is the point where FRIDA mode is initialized. Otherwise, it
-will not be possible to configure coverage for the test library using
-`AFL_FRIDA_INST_RANGES` or similar.
+## Debugging
 
-# Debugging
-Please refer to the [debugging](#debugging) guide for assistant should you
-encounter problems with FRIDA mode.
+Please refer to [DEBUGGING.md](DEBUGGING.md) for assistance should you encounter
+problems with FRIDA mode.
 
-## TODO
+## To do
 
 The next features to be added are Aarch32 support as well as looking at
-potential performance improvements. The intention is to achieve feature parity with
-QEMU mode in due course. Contributions are welcome, but please get in touch to
-ensure that efforts are deconflicted.
+potential performance improvements. The intention is to achieve feature parity
+with QEMU mode in due course. Contributions are welcome, but please get in touch
+to ensure that efforts are deconflicted.
\ No newline at end of file
diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md
index 2ee0c858..fcf8a490 100644
--- a/frida_mode/Scripting.md
+++ b/frida_mode/Scripting.md
@@ -1,25 +1,32 @@
 # Scripting
+
 FRIDA now supports the ability to configure itself using JavaScript. This allows
 the user to make use of the convenience of FRIDA's scripting engine (along with
 it's support for debug symbols and exports) to configure all of the things which
 were traditionally configured using environment variables.
 
-By default FRIDA mode will look for the file `afl.js` in the current working
+By default, FRIDA mode will look for the file `afl.js` in the current working
 directory of the target. Alternatively, a script file can be configured using
 the environment variable `AFL_FRIDA_JS_SCRIPT`.
 
-This script can make use of all of the standard [frida api functions](https://frida.re/docs/javascript-api/), but FRIDA mode adds some additional functions to allow
-you to interact with FRIDA mode itself. These can all be accessed via the global
-`Afl` parameter. e.g. `Afl.print("HELLO WORLD");`,
+This script can make use of all of the standard [frida api
+functions](https://frida.re/docs/javascript-api/), but FRIDA mode adds some
+additional functions to allow you to interact with FRIDA mode itself. These can
+all be accessed via the global `Afl` parameter, e.g., `Afl.print("HELLO
+WORLD");`.
 
 If you encounter a problem with your script, then you should set the environment
 variable `AFL_DEBUG_CHILD=1` to view any diagnostic information.
 
+## Example
 
-# Example
-Most of the time, users will likely be wanting to call the functions which configure an address (e.g. for the entry point, or the persistent address).
+Most of the time, users will likely be wanting to call the functions which
+configure an address (e.g., for the entry point or the persistent address).
 
-The example below uses the API [`DebugSymbol.fromName()`](https://frida.re/docs/javascript-api/#debugsymbol). Another use API is [`Module.getExportByName()`](https://frida.re/docs/javascript-api/#module).
+The example below uses the API
+[`DebugSymbol.fromName()`](https://frida.re/docs/javascript-api/#debugsymbol).
+Another use API is
+[`Module.getExportByName()`](https://frida.re/docs/javascript-api/#module).
 
 ```js
 /* Use Afl.print instead of console.log */
@@ -86,9 +93,9 @@ Afl.done();
 Afl.print("done");
 ```
 
-# Stripped Binaries
+## Stripped binaries
 
-Lastly, if the binary you attempting to fuzz has no symbol information, and no
+Lastly, if the binary you attempting to fuzz has no symbol information and no
 exports, then the following approach can be used.
 
 ```js
@@ -98,11 +105,12 @@ const address = module.base.add(0xdeadface);
 Afl.setPersistentAddress(address);
 ```
 
-# Persisent Hook
+## Persistent hook
+
 A persistent hook can be implemented using a conventional shared object, sample
 source code for a hook suitable for the prototype of `LLVMFuzzerTestOneInput`
-can be found [here](hook/hook.c). This can be configured using code similar to
-the following.
+can be found in [hook/hook.c](hook/hook.c). This can be configured using code
+similar to the following.
 
 ```js
 const path = Afl.module.path;
@@ -112,7 +120,8 @@ const hook = mod.getExportByName('afl_persistent_hook');
 Afl.setPersistentHook(hook);
 ```
 
-Alternatively, the hook can be provided by using FRIDAs built in support for `CModule`, powered by TinyCC.
+Alternatively, the hook can be provided by using FRIDA's built-in support for
+`CModule`, powered by TinyCC.
 
 ```js
 const cm = new CModule(`
@@ -134,8 +143,10 @@ const cm = new CModule(`
 Afl.setPersistentHook(cm.afl_persistent_hook);
 ```
 
-# Advanced Persistence
+## Advanced persistence
+
 Consider the following target code...
+
 ```c
 
 #include <fcntl.h>
@@ -281,14 +292,15 @@ Afl.done();
 Here, we replace the function `slow` with our own code. This code is then
 selected as the entry point as well as the persistent loop address.
 
-## Replacing LLVMFuzzerTestOneInput
-The function `LLVMFuzzerTestOneInput` can be replaced just like any other. Also
+### Replacing LLVMFuzzerTestOneInput
+
+The function `LLVMFuzzerTestOneInput` can be replaced just like any other. Also,
 any replaced function can also call itself. In the example below, we replace
 `LLVMFuzzerTestOneInput` with `My_LLVMFuzzerTestOneInput` which ignores the
 parameters `buf` and `len` and then calls the original `LLVMFuzzerTestOneInput`
-with the paramaters `__afl_fuzz_ptr` and `__afl_fuzz_len`. This allows us to
+with the parameters `__afl_fuzz_ptr` and `__afl_fuzz_len`. This allows us to
 carry out in-memory fuzzing without the need for any hook function. It should be
-noted that the replacement function and the original can *NOT* share the same
+noted that the replacement function and the original *CANNOT* share the same
 name, since otherwise the `C` code in the `CModule` will not compile due to a
 symbol name collision.
 
@@ -320,7 +332,8 @@ Afl.setInMemoryFuzzing();
 Interceptor.replace(LLVMFuzzerTestOneInput, cm.My_LLVMFuzzerTestOneInput);
 ```
 
-## Hooking `main`
+### Hooking `main`
+
 Lastly, it should be noted that using FRIDA mode's scripting support to hook
 the `main` function is a special case. This is because the `main` function is
 already hooked by the FRIDA mode engine itself and hence the function `main` (or
@@ -359,14 +372,16 @@ Afl.setPersistentAddress(cm.main);
 Afl.setInMemoryFuzzing();
 Afl.setJsMainHook(cm.main);
 ```
-## Library Fuzzing
+
+### Library Fuzzing
 
 It doesn't take too much imagination to see that the above example can be
 extended to use FRIDA's `Module.load` API so that the replaced `main` function
 can then call an arbitrary function. In this way, if we have a library which we
-wish to fuzz rather than an execuatble, then a surrogate executable can be used.
+wish to fuzz rather than an executable, then a surrogate executable can be used.
+
+## Patching
 
-# Patching
 Consider the [following](test/js/test2.c) test code...
 
 ```c
@@ -498,7 +513,7 @@ int main(int argc, char **argv) {
 There are a couple of obstacles with our target application. Unlike when fuzzing
 source code, though, we can't simply edit it and recompile it. The following
 script shows how we can use the normal functionality of FRIDA to modify any
-troublesome behaviour.
+troublesome behavior.
 
 ```js
 Afl.print('******************');
@@ -537,8 +552,10 @@ Afl.done();
 Afl.print("done");
 ```
 
-# Advanced Patching
+## Advanced patching
+
 Consider the following code fragment...
+
 ```c
 extern void some_boring_bug2(char c);
 
@@ -565,7 +582,7 @@ void LLVMFuzzerTestOneInput(char *buf, int len) {
 }
 ```
 
-Rather than using FRIDAs `Interceptor.replace` or `Interceptor.attach` APIs, it
+Rather than using FRIDA's `Interceptor.replace` or `Interceptor.attach` APIs, it
 is possible to apply much more fine grained modification to the target
 application by means of using the Stalker APIs.
 
@@ -649,39 +666,43 @@ Afl.setStalkerCallback(cm.js_stalker_callback)
 Afl.setStdErr("/tmp/stderr.txt");
 ```
 
-Note that you will more likely want to find the
-patch address by using:
+Note that you will more likely want to find the patch address by using:
 
 ```js
 const module = Process.getModuleByName('target.exe');
 /* Hardcoded offset within the target image */
 const address = module.base.add(0xdeadface);
 ```
+
 OR
+
 ```
 const address = DebugSymbol.fromName("my_function").address.add(0xdeadface);
 ```
+
 OR
+
 ```
 const address = Module.getExportByName(null, "my_function").add(0xdeadface);
 ```
 
 The function `js_stalker_callback` should return `TRUE` if the original
-instruction should be emitted in the instrumented code, or `FALSE` otherwise.
-In the example above, we can see it is replaced with a `NOP`.
+instruction should be emitted in the instrumented code or `FALSE` otherwise. In
+the example above, we can see it is replaced with a `NOP`.
 
 Lastly, note that the same callback will be called when compiling instrumented
 code both in the child of the forkserver (as it is executed) and also in the
-parent of the forserver (when prefetching is enabled) so that it can be
+parent of the forkserver (when prefetching is enabled) so that it can be
 inherited by the next forked child. It is **VERY** important that the same
-instructions be generated in both the parent and the child, or if prefetching is
+instructions be generated in both the parent and the child or if prefetching is
 disabled that the same instructions are generated every time the block is
 compiled. Failure to do so will likely lead to bugs which are incredibly
 difficult to diagnose. The code above only prints the instructions when running
 in the parent process (the one provided by `Process.id` when the JS script is
 executed).
 
-# OSX
+## OSX
+
 Note that the JavaScript debug symbol api for OSX makes use of the
 `CoreSymbolication` APIs and as such the `CoreFoundation` module must be loaded
 into the target to make use of it. This can be done by setting:
@@ -691,10 +712,11 @@ AFL_PRELOAD=/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
 ```
 
 It should be noted that `CoreSymbolication` API may take a while to initialize
-and build its caches. For this reason, it may be nescessary to also increase the
+and build its caches. For this reason, it may be necessary to also increase the
 value of the `-t` flag passed to `afl-fuzz`.
 
-# API
+## API
+
 ```js
 class Afl {
   /**
@@ -973,4 +995,4 @@ class Afl {
       return Afl.module.getExportByName(name);
   }
 }
-```
+```
\ No newline at end of file
diff --git a/qemu_mode/README.md b/qemu_mode/README.md
index c62309a2..b4b5e7bf 100644
--- a/qemu_mode/README.md
+++ b/qemu_mode/README.md
@@ -1,184 +1,194 @@
 # High-performance binary-only instrumentation for afl-fuzz
 
-  (See ../README.md for the general instruction manual.)
+For the general instruction manual, see [README.md](../README.md).
 
 ## 1) Introduction
 
 The code in this directory allows you to build a standalone feature that
 leverages the QEMU "user emulation" mode and allows callers to obtain
-instrumentation output for black-box, closed-source binaries. This mechanism
-can be then used by afl-fuzz to stress-test targets that couldn't be built
-with afl-gcc.
+instrumentation output for black-box, closed-source binaries. This mechanism can
+be then used by afl-fuzz to stress-test targets that couldn't be built with
+afl-cc.
 
-The usual performance cost is 2-5x, which is considerably better than
-seen so far in experiments with tools such as DynamoRIO and PIN.
+The usual performance cost is 2-5x, which is considerably better than seen so
+far in experiments with tools such as DynamoRIO and PIN.
 
-The idea and much of the initial implementation comes from Andrew Griffiths.
-The actual implementation on current QEMU (shipped as qemuafl) is from
-Andrea Fioraldi. Special thanks to abiondo that re-enabled TCG chaining.
+The idea and much of the initial implementation comes from Andrew Griffiths. The
+actual implementation on current QEMU (shipped as qemuafl) is from Andrea
+Fioraldi. Special thanks to abiondo that re-enabled TCG chaining.
 
-## 2) How to use qemu_mode
+## 2) How to use QEMU mode
 
-The feature is implemented with a patched QEMU. The simplest way
-to build it is to run ./build_qemu_support.sh. The script will download,
-configure, and compile the QEMU binary for you.
+The feature is implemented with a patched QEMU. The simplest way to build it is
+to run ./build_qemu_support.sh. The script will download, configure, and compile
+the QEMU binary for you.
 
-QEMU is a big project, so this will take a while, and you may have to
-resolve a couple of dependencies (most notably, you will definitely need
-libtool and glib2-devel).
+QEMU is a big project, so this will take a while, and you may have to resolve a
+couple of dependencies (most notably, you will definitely need libtool and
+glib2-devel).
 
 Once the binaries are compiled, you can leverage the QEMU tool by calling
-afl-fuzz and all the related utilities with -Q in the command line.
+afl-fuzz and all the related utilities with `-Q` in the command line.
 
-Note that QEMU requires a generous memory limit to run; somewhere around
-200 MB is a good starting point, but considerably more may be needed for
-more complex programs. The default -m limit will be automatically bumped up
-to 200 MB when specifying -Q to afl-fuzz; be careful when overriding this.
+Note that QEMU requires a generous memory limit to run; somewhere around 200 MB
+is a good starting point, but considerably more may be needed for more complex
+programs. The default `-m` limit will be automatically bumped up to 200 MB when
+specifying `-Q` to afl-fuzz; be careful when overriding this.
 
-In principle, if you set CPU_TARGET before calling ./build_qemu_support.sh,
-you should get a build capable of running non-native binaries (say, you
-can try CPU_TARGET=arm). This is also necessary for running 32-bit binaries
-on a 64-bit system (CPU_TARGET=i386). If you're trying to run QEMU on a
-different architecture you can also set HOST to the cross-compiler prefix
-to use (for example HOST=arm-linux-gnueabi to use arm-linux-gnueabi-gcc).
+In principle, if you set `CPU_TARGET` before calling ./build_qemu_support.sh,
+you should get a build capable of running non-native binaries (say, you can try
+`CPU_TARGET=arm`). This is also necessary for running 32-bit binaries on a
+64-bit system (`CPU_TARGET=i386`). If you're trying to run QEMU on a different
+architecture, you can also set `HOST` to the cross-compiler prefix to use (for
+example `HOST=arm-linux-gnueabi` to use arm-linux-gnueabi-gcc).
 
-You can also compile statically-linked binaries by setting STATIC=1. This
-can be useful when compiling QEMU on a different system than the one you're
-planning to run the fuzzer on and is most often used with the HOST variable.
+You can also compile statically-linked binaries by setting `STATIC=1`. This can
+be useful when compiling QEMU on a different system than the one you're planning
+to run the fuzzer on and is most often used with the `HOST` variable.
 
-Note: when targetting the i386 architecture, on some binaries the forkserver
-handshake may fail due to the lack of reserved memory. Fix it with
+Note: when targeting the i386 architecture, on some binaries the forkserver
+handshake may fail due to the lack of reserved memory. Fix it with:
 
+```
 export QEMU_RESERVED_VA=0x1000000
+```
 
-Note: if you want the QEMU helper to be installed on your system for all
-users, you need to build it before issuing 'make install' in the parent
-directory.
+Note: if you want the QEMU helper to be installed on your system for all users,
+you need to build it before issuing `make install` in the parent directory.
 
-If you want to specify a different path for libraries (e.g. to run an arm64
-binary on x86_64) use QEMU_LD_PREFIX.
+If you want to specify a different path for libraries (e.g., to run an arm64
+binary on x86_64) use `QEMU_LD_PREFIX`.
 
 ## 3) Deferred initialization
 
-As for LLVM mode (refer to its README.md for mode details) QEMU mode supports
-the deferred initialization.
+As for LLVM mode (refer to
+[instrumentation/README.llvm.md](../instrumentation/README.llvm.md) for mode
+details), QEMU mode supports the deferred initialization.
 
-This can be enabled setting the environment variable AFL_ENTRYPOINT which allows
-to move the forkserver to a different part, e.g. just before the file is
-opened (e.g. way after command line parsing and config file loading, etc.)
+This can be enabled by setting the environment variable `AFL_ENTRYPOINT` which
+allows to move the forkserver to a different part, e.g., just before the file is
+opened (e.g., way after command line parsing and config file loading, etc.)
 which can be a huge speed improvement.
 
 ## 4) Persistent mode
 
-AFL++'s QEMU mode now supports also persistent mode for x86, x86_64, arm
-and aarch64 targets.
-This increases the speed by several factors, however it is a bit of work to set
-up - but worth the effort.
+AFL++'s QEMU mode now supports also persistent mode for x86, x86_64, arm, and
+aarch64 targets. This increases the speed by several factors, however, it is a
+bit of work to set up - but worth the effort.
 
-Please see the extra documentation for it: [README.persistent.md](README.persistent.md)
+For more information, see [README.persistent.md](README.persistent.md).
 
 ## 5) Snapshot mode
 
 As an extension to persistent mode, qemuafl can snapshot and restore the memory
-state and brk(). Details are in the persistent mode readme.
+state and brk(). For details, see [README.persistent.md](README.persistent.md).
 
-The env var that enables the ready to use snapshot mode is AFL_QEMU_SNAPSHOT and
-takes a hex address as a value that is the snapshot entrypoint.
+The env var that enables the ready to use snapshot mode is `AFL_QEMU_SNAPSHOT`
+and takes a hex address as a value that is the snapshot entry point.
 
-Snapshot mode can work restoring all the writeable pages, that is typically slower than
-fork() mode but, on the other hand, it can scale better with multicore.
-If the AFL++ Snapshot kernel module is loaded, qemuafl will use it and, in this
-case, the speed is better than fork() and also the scaling capabilities.
+Snapshot mode can work restoring all the writeable pages, that is typically
+slower than fork() mode but, on the other hand, it can scale better with
+multicore. If the AFL++ snapshot kernel module is loaded, qemuafl will use it
+and, in this case, the speed is better than fork() and also the scaling
+capabilities.
 
 ## 6) Partial instrumentation
 
 You can tell QEMU to instrument only a part of the address space.
 
-Just set AFL_QEMU_INST_RANGES=A,B,C...
+Just set `AFL_QEMU_INST_RANGES=A,B,C...`.
 
-The format of the items in the list is either a range of addresses like 0x123-0x321
-or a module name like module.so (that is matched in the mapped object filename).
+The format of the items in the list is either a range of addresses like
+0x123-0x321 or a module name like module.so (that is matched in the mapped
+object filename).
 
-Alternatively you can tell QEMU to ignore part of an address space for instrumentation.
+Alternatively, you can tell QEMU to ignore part of an address space for
+instrumentation.
 
-Just set AFL_QEMU_EXCLUDE_RANGES=A,B,C...
+Just set `AFL_QEMU_EXCLUDE_RANGES=A,B,C...`.
 
-The format of the items on the list is the same as for AFL_QEMU_INST_RANGES, and excluding ranges
-takes priority over any included ranges or AFL_INST_LIBS.
+The format of the items on the list is the same as for `AFL_QEMU_INST_RANGES`
+and excluding ranges takes priority over any included ranges or `AFL_INST_LIBS`.
 
 ## 7) CompareCoverage
 
 CompareCoverage is a sub-instrumentation with effects similar to laf-intel.
 
-You have to set `AFL_PRELOAD=/path/to/libcompcov.so` together with
-setting the AFL_COMPCOV_LEVEL you want to enable it.
+You have to set `AFL_PRELOAD=/path/to/libcompcov.so` together with setting the
+`AFL_COMPCOV_LEVEL` you want to enable it.
 
-AFL_COMPCOV_LEVEL=1 is to instrument comparisons with only immediate
-values / read-only memory.
+`AFL_COMPCOV_LEVEL=1` is to instrument comparisons with only immediate
+values/read-only memory.
 
-AFL_COMPCOV_LEVEL=2 instruments all comparison instructions and memory
+`AFL_COMPCOV_LEVEL=2` instruments all comparison instructions and memory
 comparison functions when libcompcov is preloaded.
 
-AFL_COMPCOV_LEVEL=3 has the same effects of AFL_COMPCOV_LEVEL=2 but enables
+`AFL_COMPCOV_LEVEL=3` has the same effects of `AFL_COMPCOV_LEVEL=2` but enables
 also the instrumentation of the floating-point comparisons on x86 and x86_64
 (experimental).
 
-Integer comparison instructions are currently instrumented only
-on the x86, x86_64, arm and aarch64 targets.
+Integer comparison instructions are currently instrumented only on the x86,
+x86_64, arm, and aarch64 targets.
 
 Recommended, but not as good as CMPLOG mode (see below).
 
 ## 8) CMPLOG mode
 
-Another new feature is CMPLOG, which is based on the redqueen project.
-Here all immediates in CMP instructions are learned and put into a dynamic
-dictionary and applied to all locations in the input that reached that
-CMP, trying to solve and pass it.
-This is a very effective feature and it is available for x86, x86_64, arm
-and aarch64.
+Another new feature is CMPLOG, which is based on the redqueen project. Here all
+immediates in CMP instructions are learned and put into a dynamic dictionary and
+applied to all locations in the input that reached that CMP, trying to solve and
+pass it. This is a very effective feature and it is available for x86, x86_64,
+arm, and aarch64.
 
-To enable it you must pass on the command line of afl-fuzz:
-  -c /path/to/your/target
+To enable it, you must pass on the command line of afl-fuzz:
+
+```
+-c /path/to/your/target
+```
 
 ## 9) Wine mode
 
-AFL++ QEMU can use Wine to fuzz Win32 PE binaries. Use the -W flag of afl-fuzz.
+AFL++ QEMU can use Wine to fuzz Win32 PE binaries. Use the `-W` flag of
+afl-fuzz.
 
-Note that some binaries require user interaction with the GUI and must be patched.
+Note that some binaries require user interaction with the GUI and must be
+patched.
 
-For examples look [here](https://github.com/andreafioraldi/WineAFLplusplusDEMO).
+For examples, look
+[here](https://github.com/andreafioraldi/WineAFLplusplusDEMO).
 
 ## 10) Notes on linking
 
-The feature is supported only on Linux. Supporting BSD may amount to porting
-the changes made to linux-user/elfload.c and applying them to
-bsd-user/elfload.c, but I have not looked into this yet.
+The feature is supported only on Linux. Supporting BSD may amount to porting the
+changes made to linux-user/elfload.c and applying them to bsd-user/elfload.c,
+but I have not looked into this yet.
 
 The instrumentation follows only the .text section of the first ELF binary
 encountered in the linking process. It does not trace shared libraries. In
 practice, this means two things:
 
-  - Any libraries you want to analyze *must* be linked statically into the
-    executed ELF file (this will usually be the case for closed-source
-    apps).
+- Any libraries you want to analyze *must* be linked statically into the
+  executed ELF file (this will usually be the case for closed-source apps).
 
-  - Standard C libraries and other stuff that is wasteful to instrument
-    should be linked dynamically - otherwise, AFL will have no way to avoid
-    peeking into them.
+- Standard C libraries and other stuff that is wasteful to instrument should be
+  linked dynamically - otherwise, AFL++ will have no way to avoid peeking into
+  them.
 
-Setting AFL_INST_LIBS=1 can be used to circumvent the .text detection logic
+Setting `AFL_INST_LIBS=1` can be used to circumvent the .text detection logic
 and instrument every basic block encountered.
 
 ## 11) Benchmarking
 
 If you want to compare the performance of the QEMU instrumentation with that of
-afl-gcc compiled code against the same target, you need to build the
+afl-clang-fast compiled code against the same target, you need to build the
 non-instrumented binary with the same optimization flags that are normally
-injected by afl-gcc, and make sure that the bits to be tested are statically
-linked into the binary. A common way to do this would be:
+injected by afl-clang-fast, and make sure that the bits to be tested are
+statically linked into the binary. A common way to do this would be:
 
+```
 CFLAGS="-O3 -funroll-loops" ./configure --disable-shared
 make clean all
+```
 
 Comparative measurements of execution speed or instrumentation coverage will be
 fairly meaningless if the optimization levels or instrumentation scopes don't
@@ -186,37 +196,37 @@ match.
 
 ## 12) Other features
 
-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.
 
 ## 13) Gotchas, feedback, bugs
 
 If you need to fix up checksums or do other cleanups on mutated test cases, see
-`afl_custom_post_process` in custom_mutators/examples/example.c for a viable solution.
+`afl_custom_post_process` in custom_mutators/examples/example.c for a viable
+solution.
 
-Do not mix QEMU mode with ASAN, MSAN, or the likes; QEMU doesn't appreciate
-the "shadow VM" trick employed by the sanitizers and will probably just
-run out of memory.
+Do not mix QEMU mode with ASAN, MSAN, or the likes; QEMU doesn't appreciate the
+"shadow VM" trick employed by the sanitizers and will probably just run out of
+memory.
 
 Compared to fully-fledged virtualization, the user emulation mode is *NOT* a
 security boundary. The binaries can freely interact with the host OS. If you
 somehow need to fuzz an untrusted binary, put everything in a sandbox first.
 
-QEMU does not necessarily support all CPU or hardware features that your
-target program may be utilizing. In particular, it does not appear to have
-full support for AVX2 / FMA3. Using binaries for older CPUs, or recompiling them
-with -march=core2, can help.
+QEMU does not necessarily support all CPU or hardware features that your target
+program may be utilizing. In particular, it does not appear to have full support
+for AVX2/FMA3. Using binaries for older CPUs or recompiling them with
+`-march=core2`, can help.
 
 Beyond that, this is an early-stage mechanism, so fields reports are welcome.
 You can send them to <afl-users@googlegroups.com>.
 
 ## 14) Alternatives: static rewriting
 
-Statically rewriting binaries just once, instead of attempting to translate
-them at run time, can be a faster alternative. That said, static rewriting is
-fraught with peril, because it depends on being able to properly and fully model
-program control flow without actually executing each and every code path.
+Statically rewriting binaries just once, instead of attempting to translate them
+at run time, can be a faster alternative. That said, static rewriting is fraught
+with peril, because it depends on being able to properly and fully model program
+control flow without actually executing each and every code path.
 
-Check out
-[docs/fuzzing_binary-only_targets.md](../docs/fuzzing_binary-only_targets.md)
-for more information and hints.
+For more information and hints, check out
+[docs/fuzzing_binary-only_targets.md](../docs/fuzzing_binary-only_targets.md).
\ No newline at end of file
diff --git a/qemu_mode/README.persistent.md b/qemu_mode/README.persistent.md
index 2ca5c873..7210a8cc 100644
--- a/qemu_mode/README.persistent.md
+++ b/qemu_mode/README.persistent.md
@@ -2,118 +2,118 @@
 
 ## 1) Introduction
 
-Persistent mode lets you fuzz your target persistently between two
-addresses - without forking for every fuzzing attempt.
-This increases the speed by a factor between x2 and x5, hence it is
-very, very valuable.
+Persistent mode lets you fuzz your target persistently between two addresses -
+without forking for every fuzzing attempt. This increases the speed by a factor
+between x2 and x5, hence it is very, very valuable.
 
-The persistent mode is currently only available for x86/x86_64, arm
-and aarch64 targets.
+The persistent mode is currently only available for x86/x86_64, arm, and aarch64
+targets.
 
 ## 2) How use the persistent mode
 
 ### 2.1) The START address
 
-The start of the persistent loop has to be set with env var AFL_QEMU_PERSISTENT_ADDR.
+The start of the persistent loop has to be set with environment variable
+`AFL_QEMU_PERSISTENT_ADDR`.
 
-This address can be the address of whatever instruction.
-Setting this address to the start of a function makes the usage simple.
-If the address is however within a function, either RET, OFFSET or EXITS
-(see below in 2.2, 2.3, 2.6) have to be set.
-This address (as well as the RET address, see below) has to be defined in
+This address can be the address of whatever instruction. Setting this address to
+the start of a function makes the usage simple. If the address is however within
+a function, either RET, OFFSET, or EXITS (see below in 2.2, 2.3, 2.6) have to be
+set. This address (as well as the RET address, see below) has to be defined in
 hexadecimal with the 0x prefix or as a decimal value.
 
 If both RET and EXITS are not set, QEMU will assume that START points to a
-function and will patch the return address (on stack or in the link register)
-to return to START (like WinAFL).
+function and will patch the return address (on stack or in the link register) to
+return to START (like WinAFL).
 
-*Note:* If the target is compiled with position independant code (PIE/PIC)
-qemu loads these to a specific base address.
-For 64 bit you have to add 0x4000000000 (9 zeroes) and for 32 bit 0x40000000
-(7 zeroes) to the address.
-On strange setups the base address set by QEMU for PIE executable may change,
-you can check it printing the process map using 
-`AFL_QEMU_DEBUG_MAPS=1 afl-qemu-trace TARGET-BINARY`
+*Note:* If the target is compiled with position independent code (PIE/PIC) qemu
+loads these to a specific base address. For 64 bit you have to add 0x4000000000
+(9 zeroes) and for 32 bit 0x40000000 (7 zeroes) to the address. On strange
+setups the base address set by QEMU for PIE executable may change. You can check
+it printing the process map using `AFL_QEMU_DEBUG_MAPS=1 afl-qemu-trace
+TARGET-BINARY`.
 
 If this address is not valid, afl-fuzz will error during startup with the
 message that the forkserver was not found.
 
 ### 2.2) The RET address
 
-The RET address is the last instruction of the persistent loop.
-The emulator will emit a jump to START when translating the instruction at RET.
-It is optional, and only needed if the return should not be
-at the end of the function to which the START address points into, but earlier.
+The RET address is the last instruction of the persistent loop. The emulator
+will emit a jump to START when translating the instruction at RET. It is
+optional and only needed if the return should not be at the end of the function
+to which the START address points into, but earlier.
 
-It is defined by setting AFL_QEMU_PERSISTENT_RET, and too 0x4000000000 has to
-be set if the target is position independant.
+It is defined by setting `AFL_QEMU_PERSISTENT_RET`, and too 0x4000000000 has to
+be set if the target is position independent.
 
 ### 2.3) The OFFSET
 
 This option is valid only for x86/x86_64 only, arm/aarch64 do not save the
 return address on stack.
 
-If the START address is *not* the beginning of a function, and *no* RET has
-been set (so the end of the loop will be at the end of the function but START
-will not be at the beginning of it), we need an offset from the ESP pointer
-to locate the return address to patch.
+If the START address is *not* the beginning of a function, and *no* RET has been
+set (so the end of the loop will be at the end of the function but START will
+not be at the beginning of it), we need an offset from the ESP pointer to locate
+the return address to patch.
 
 The value by which the ESP pointer has to be corrected has to be set in the
-variable AFL_QEMU_PERSISTENT_RETADDR_OFFSET.
+variable `AFL_QEMU_PERSISTENT_RETADDR_OFFSET`.
 
 Now to get this value right here is some help:
-1. use gdb on the target 
-2. set a breakpoint to "main" (this is required for PIE/PIC binaries so the
-   addresses are set up)
-3. "run" the target with a valid commandline
-4. set a breakpoint to the function in which START is contained
-5. set a breakpoint to your START address
-6. "continue" to the function start breakpoint
-6. print the ESP value with `print $esp` and take note of it
-7. "continue" the target until the second breakpoint
-8. again print the ESP value
-9. calculate the difference between the two values - and this is the offset
+1. Use gdb on the target.
+2. Set a breakpoint to "main" (this is required for PIE/PIC binaries so the
+   addresses are set up).
+3. "run" the target with a valid commandline.
+4. Set a breakpoint to the function in which START is contained.
+5. Set a breakpoint to your START address.
+6. "continue" to the function start breakpoint.
+7. Print the ESP value with `print $esp` and take note of it.
+8. "continue" the target until the second breakpoint.
+9. Again print the ESP value.
+10. Calculate the difference between the two values - and this is the offset.
 
 ### 2.4) Resetting the register state
 
 It is very, very likely you need to restore the general purpose registers state
 when starting a new loop. Because of this 99% of the time you should set
 
+```
 AFL_QEMU_PERSISTENT_GPR=1
+```
 
-An example is when you want to use main() as persistent START:
+An example is when you want to use `main()` as persistent START:
 
 ```c
 int main(int argc, char **argv) {
 
   if (argc < 2) return 1;
-  
+
   // do stuff
 
 }
 ```
 
-If you don't save and restore the registers in x86_64, the parameter `argc`
-will be lost at the second execution of the loop.
+If you don't save and restore the registers in x86_64, the parameter `argc` will
+be lost at the second execution of the loop.
 
 ### 2.5) Resetting the memory state
 
 This option restores the memory state using the AFL++ Snapshot LKM if loaded.
 Otherwise, all the writeable pages are restored.
 
-To enable this option, set AFL_QEMU_PERSISTENT_MEM=1.
+To enable this option, set `AFL_QEMU_PERSISTENT_MEM=1`.
 
 ### 2.6) Reset on exit()
 
 The user can force QEMU to set the program counter to START instead of executing
 the exit_group syscall and exit the program.
 
-The env variable is AFL_QEMU_PERSISTENT_EXITS.
+The environment variable is `AFL_QEMU_PERSISTENT_EXITS`.
 
 ### 2.7) Snapshot
 
-AFL_QEMU_SNAPSHOT=address is just a "syntactical sugar" env variable that is equivalent to
-the following set of variables:
+`AFL_QEMU_SNAPSHOT=address` is just a "syntactical sugar" environment variable
+that is equivalent to the following set of variables:
 
 ```
 AFL_QEMU_PERSISTENT_ADDR=address
@@ -127,26 +127,27 @@ AFL_QEMU_PERSISTENT_EXITS=1
 ### 3.1) Loop counter value
 
 The more stable your loop in the target, the longer you can run it, the more
-unstable it is the lower the loop count should be. A low value would be 100,
-the maximum value should be 10000. The default is 1000.
-This value can be set with AFL_QEMU_PERSISTENT_CNT
+unstable it is the lower the loop count should be. A low value would be 100, the
+maximum value should be 10000. The default is 1000. This value can be set with
+`AFL_QEMU_PERSISTENT_CNT`.
 
-This is the same concept as in the llvm_mode persistent mode with __AFL_LOOP().
+This is the same concept as in the llvm_mode persistent mode with
+`__AFL_LOOP()`.
 
 ### 3.2) A hook for in-memory fuzzing
 
-You can increase the speed of the persistent mode even more by bypassing all
-the reading of the fuzzing input via a file by reading directly into the
-memory address space of the target process.
+You can increase the speed of the persistent mode even more by bypassing all the
+reading of the fuzzing input via a file by reading directly into the memory
+address space of the target process.
 
 All this needs is that the START address has a register that can reach the
-memory buffer or that the memory buffer is at a known location. You probably need
-the value of the size of the buffer (maybe it is in a register when START is
-hit).
+memory buffer or that the memory buffer is at a known location. You probably
+need the value of the size of the buffer (maybe it is in a register when START
+is hit).
 
-The persistent hook will execute a function on every persistent iteration
-(at the start START) defined in a shared object specified with
-AFL_QEMU_PERSISTENT_HOOK=/path/to/hook.so.
+The persistent hook will execute a function on every persistent iteration (at
+the start START) defined in a shared object specified with
+`AFL_QEMU_PERSISTENT_HOOK=/path/to/hook.so`.
 
 The signature is:
 
@@ -157,8 +158,8 @@ void afl_persistent_hook(struct ARCH_regs *regs,
                          uint32_t input_buf_len);
 ```
 
-Where ARCH is one of x86, x86_64, arm or arm64.
-You have to include `path/to/qemuafl/qemuafl/api.h`.
+Where ARCH is one of x86, x86_64, arm or arm64. You have to include
+`path/to/qemuafl/qemuafl/api.h`.
 
 In this hook, you can inspect and change the saved GPR state at START.
 
@@ -168,8 +169,8 @@ with:
 `int afl_persistent_hook_init(void);`
 
 If this routine returns true, the shared mem fuzzing feature of AFL++ is used
-and so the input_buf variables of the hook becomes meaningful. Otherwise,
-you have to read the input from a file like stdin.
+and so the input_buf variables of the hook becomes meaningful. Otherwise, you
+have to read the input from a file like stdin.
 
-An example that you can use with little modification for your target can
-be found here: [utils/qemu_persistent_hook](../utils/qemu_persistent_hook)
+An example that you can use with little modification for your target can be
+found here: [utils/qemu_persistent_hook](../utils/qemu_persistent_hook)
\ No newline at end of file
diff --git a/qemu_mode/README.wine.md b/qemu_mode/README.wine.md
index 567901cd..ee1ef58a 100644
--- a/qemu_mode/README.wine.md
+++ b/qemu_mode/README.wine.md
@@ -1,21 +1,23 @@
 # How to troubleshoot AFL++'s wine mode
 
 ## 1) Debugging
-To turn on wine debugging use the `WINEDEBUG` environment variable, 
-e.g. `WINEDEBUG=+timestamp,+tid,+loaddll`. 
+
+To turn on wine debugging, use the `WINEDEBUG` environment variable, e.g.,
+`WINEDEBUG=+timestamp,+tid,+loaddll`.
 
 ## 2) LoadLibraryA workaround
-The forked process fails to load libraries loaded via `LoadLibrary` 
-if the load happens after the entry point (error code: 87). To resolve 
-this issue, one needs to load any external libraries before the fork happens.
 
-An early DLL load can be achieved by adding the DLL name into the `Import Directory`
-in the PE file. Such an entry can be added manually in any PE editor. 
+The forked process fails to load libraries loaded via `LoadLibrary` if the load
+happens after the entry point (error code: 87). To resolve this issue, one needs
+to load any external libraries before the fork happens.
+
+An early DLL load can be achieved by adding the DLL name into the `Import
+Directory` in the PE file. Such an entry can be added manually in any PE editor.
 
-Alternativly, one can generate a `.lib` file from the DLL exports and link 
-them together with the harness to create an entry in the `Import Directory`. 
-Use `dumpbin /exports <filename>.dll` to extract the exports and paste the 
-exported function names into a `.def` file. Use `lib /def:<deffile> /OUT:<libfile>`
-to generate a `.lib` and add the library to the linker options. Once the usage of 
-an export is detected (`__declspec(dllimport)`), the
-linker adds the early DLL load.
\ No newline at end of file
+Alternatively, one can generate a `.lib` file from the DLL exports and link them
+together with the harness to create an entry in the `Import Directory`. Use
+`dumpbin /exports <filename>.dll` to extract the exports and paste the exported
+function names into a `.def` file. Use `lib /def:<deffile> /OUT:<libfile>` to
+generate a `.lib` and add the library to the linker options. Once the usage of
+an export is detected (`__declspec(dllimport)`), the linker adds the early DLL
+load.
\ No newline at end of file