4 files changed, 16 insertions, 16 deletions
diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md
index 9cdc5eb6..b703ae43 100644
--- a/frida_mode/DEBUGGING.md
+++ b/frida_mode/DEBUGGING.md
@@ -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..c2b98473 100644
--- a/frida_mode/README.md
+++ b/frida_mode/README.md
@@ -229,9 +229,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,8 +359,8 @@ 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.
diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md
index fcf8a490..fd4282db 100644
--- a/frida_mode/Scripting.md
+++ b/frida_mode/Scripting.md
@@ -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.