Remove the word "we"
MODIFY
TODO.md
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

MODIFY
docs/afl-fuzz_approach.md
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,

MODIFY
docs/custom_mutators.md
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.

MODIFY
docs/fuzzing_binary-only_targets.md
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.

MODIFY
docs/fuzzing_in_depth.md
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.

MODIFY
frida_mode/DEBUGGING.md
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.

MODIFY
instrumentation/README.instrument_list.md
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

MODIFY
unicorn_mode/samples/c/COMPILE.md
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.

MODIFY
unicorn_mode/samples/persistent/COMPILE.md
unicorn_mode/samples/persistent/COMPILE.md
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

MODIFY
unicorn_mode/samples/speedtest/README.md
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:

MODIFY
utils/aflpp_driver/README.md
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]`.

MODIFY
utils/autodict_ql/readme.md
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

MODIFY
utils/qbdi_mode/README.md
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() {

Remove the word "we"