Merge pull request #1191 from llzmb/docs_quality_assurance

Docs content - quality assurance

4 files changed, 35 insertions, 34 deletions

diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md
index 9cdc5eb6..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.
@@ -160,9 +160,9 @@ Lastly, if your defect only occurs when using `afl-fuzz` (e.g., when using
 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 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).
+Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is 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.
 
diff --git a/frida_mode/MapDensity.md b/frida_mode/MapDensity.md
index b6a96ca0..50f2720f 100644
--- a/frida_mode/MapDensity.md
+++ b/frida_mode/MapDensity.md
@@ -77,13 +77,13 @@ evenly distributed.
 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 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
-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.
+the address may 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 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
 
diff --git a/frida_mode/README.md b/frida_mode/README.md
index c19280e1..08f6b891 100644
--- a/frida_mode/README.md
+++ b/frida_mode/README.md
@@ -120,9 +120,9 @@ x86 and x64 architectures. Implementation details can be found
 
 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
+library is also linked to the `compiler-rt` component of AFL++ 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)
 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
@@ -141,6 +141,7 @@ instances run CMPLOG mode and instrumentation of the binary is less frequent
 (only on CMP, SUB and CALL instructions) performance is not quite so critical.
 
 ## 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
@@ -229,9 +230,9 @@ instances run CMPLOG mode and instrumentation of the binary is less frequent
 * `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.
+  `AFL_FRIDA_STATS_INTERVAL` has expired). Note that just because a new path is
+  found does not mean a new block needs to be compiled. It could be that the
+  existing blocks instrumented have been executed in a different order.
 
   ```
   stats
@@ -359,16 +360,16 @@ 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
+function marked `__attribute__((constructor()))` or the test harness can 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
 
-Please refer to [DEBUGGING.md](DEBUGGING.md) for assistance should you encounter
-problems with FRIDA mode.
+Should you encounter problems with FRIDA mode, refer to
+[DEBUGGING.md](DEBUGGING.md) for assistance.
 
 ## To do
 
diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md
index fcf8a490..ad86fdd3 100644
--- a/frida_mode/Scripting.md
+++ b/frida_mode/Scripting.md
@@ -109,8 +109,8 @@ Afl.setPersistentAddress(address);
 
 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 in [hook/hook.c](hook/hook.c). This can be configured using code
-similar to the following.
+can be found in [hook/](hook/). This can be configured using code similar to the
+following.
 
 ```js
 const path = Afl.module.path;
@@ -334,8 +334,8 @@ Interceptor.replace(LLVMFuzzerTestOneInput, cm.My_LLVMFuzzerTestOneInput);
 
 ### Hooking `main`
 
-Lastly, it should be noted that using FRIDA mode's scripting support to hook
-the `main` function is a special case. This is because the `main` function is
+Lastly, it should be noted that using FRIDA mode's scripting support to hook the
+`main` function is a special case. This is because the `main` function is
 already hooked by the FRIDA mode engine itself and hence the function `main` (or
 at least the first basic block already been compiled by Stalker ready for
 execution). Hence any attempt to use `Interceptor.replace` like in the example
@@ -405,22 +405,22 @@ Consider the [following](test/js/test2.c) test code...
 #include <unistd.h>
 
 const uint32_t crc32_tab[] = {
-	0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
+    0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
 
   ...
 
-	0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
+    0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
 };
 
 uint32_t
 crc32(const void *buf, size_t size)
 {
-	const uint8_t *p = buf;
-	uint32_t crc;
- 	crc = ~0U;
-	while (size--)
-		crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8);
-	return crc ^ ~0U;
+    const uint8_t *p = buf;
+    uint32_t crc;
+    crc = ~0U;
+    while (size--)
+        crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8);
+    return crc ^ ~0U;
 }
 
 /*
@@ -511,7 +511,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
+source code, though, we can't just edit it and recompile it. The following
 script shows how we can use the normal functionality of FRIDA to modify any
 troublesome behavior.