Remove the word "we"

13 files changed, 32 insertions, 32 deletions

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