about summary refs log tree commit diff
diff options
context:
space:
mode:
authorllzmb <46303940+llzmb@users.noreply.github.com>2021-12-05 19:31:43 +0100
committerllzmb <46303940+llzmb@users.noreply.github.com>2021-12-05 19:40:56 +0100
commit139db40cfc243d2de4eb1584e41867e5a44a06f9 (patch)
tree958ea8d9a07496357185682ab1d112ecf61b1b35
parent89df436290c67b1c03122bfe5c68cf4f92e581c0 (diff)
downloadafl++-139db40cfc243d2de4eb1584e41867e5a44a06f9.tar.gz
Fix usage and punctuation in connection with "then" and "than"
-rw-r--r--docs/fuzzing_binary-only_targets.md2
-rw-r--r--docs/fuzzing_in_depth.md32
-rw-r--r--instrumentation/README.llvm.md2
-rw-r--r--utils/afl_network_proxy/README.md2
-rw-r--r--utils/afl_untracer/README.md2
-rw-r--r--utils/aflpp_driver/README.md26
6 files changed, 33 insertions, 33 deletions
diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md
index fd18b5c1..5434a22c 100644
--- a/docs/fuzzing_binary-only_targets.md
+++ b/docs/fuzzing_binary-only_targets.md
@@ -172,7 +172,7 @@ Fore more information, see
 
 ## Binary rewriters
 
-An alternative solution are binary rewriters. They are faster then the solutions
+An alternative solution are binary rewriters. They are faster than the solutions
 native to AFL++ but don't always work.
 
 ### ZAFL
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 29e8f817..aaceb600 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -211,7 +211,7 @@ is more effective).
 ### d) Modifying the target
 
 If the target has features that make fuzzing more difficult, e.g., checksums,
-HMAC, etc. then modify the source code so that checks for these values are
+HMAC, etc., then modify the source code so that checks for these values are
 removed. This can even be done safely for source code used in operational
 products by eliminating these checks within these AFL++ specific blocks:
 
@@ -244,16 +244,16 @@ Then build the target. (Usually with `make`)
 
 **NOTES**
 
-1. sometimes configure and build systems are fickle and do not like stderr
+1. Sometimes configure and build systems are fickle and do not like stderr
    output (and think this means a test failure) - which is something AFL++ likes
    to do to show statistics. It is recommended to disable AFL++ instrumentation
    reporting via `export AFL_QUIET=1`.
 
-2. sometimes configure and build systems error on warnings - these should be
+2. Sometimes configure and build systems error on warnings - these should be
    disabled (e.g., `--disable-werror` for some configure scripts).
 
-3. in case the configure/build system complains about AFL++'s compiler and
-   aborts then set `export AFL_NOOPT=1` which will then just behave like the
+3. In case the configure/build system complains about AFL++'s compiler and
+   aborts, then set `export AFL_NOOPT=1` which will then just behave like the
    real compiler. This option has to be unset again before building the target!
 
 #### configure
@@ -304,8 +304,8 @@ that you want to fuzz, plus a few specific AFL++ functions around it. See
 [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md)
 for details.
 
-Basically if you do not fuzz a target in persistent mode then you are just doing
-it for a hobby and not professionally :-).
+Basically if you do not fuzz a target in persistent mode, then you are just
+doing it for a hobby and not professionally :-).
 
 ### g) libfuzzer fuzzer harnesses with LLVMFuzzerTestOneInput()
 
@@ -418,9 +418,9 @@ Note that both scripts improve your fuzzing performance but also decrease your
 system protection against attacks! So set strong firewall rules and only expose
 SSH as a network service if you use these (which is highly recommended).
 
-If you have an input corpus from step 2 then specify this directory with the
-`-i` option. Otherwise create a new directory and create a file with any content
-as test data in there.
+If you have an input corpus from step 2, then specify this directory with the
+`-i` option. Otherwise, create a new directory and create a file with any
+content as test data in there.
 
 If you do not want anything special, the defaults are already usually best,
 hence all you need is to specify the seed input directory with the result of
@@ -498,8 +498,8 @@ and not waste CPU time.
 
 ### c) Using multiple cores
 
-If you want to seriously fuzz then use as many cores/threads as possible to fuzz
-your target.
+If you want to seriously fuzz, then use as many cores/threads as possible to
+fuzz your target.
 
 On the same machine - due to the design of how AFL++ works - there is a maximum
 number of CPU cores/threads that are useful, use more and the overall
@@ -658,7 +658,7 @@ An "easy" helper script for this is
 [https://github.com/vanhauser-thc/afl-cov](https://github.com/vanhauser-thc/afl-cov),
 just follow the README of that separate project.
 
-If you see that an important area or a feature has not been covered so far then
+If you see that an important area or a feature has not been covered so far, then
 try to find an input that is able to reach that and start a new secondary in
 that fuzzing campaign with that seed as input, let it run for a few minutes,
 then terminate it. The main node will pick it up and make it available to the
@@ -668,13 +668,13 @@ AFL_TRY_AFFINITY=1` if you have no free core.
 Note that in nearly all cases you can never reach full coverage. A lot of
 functionality is usually dependent on exclusive options that would need
 individual fuzzing campaigns each with one of these options set. E.g., if you
-fuzz a library to convert image formats and your target is the png to tiff API
+fuzz a library to convert image formats and your target is the png to tiff API,
 then you will not touch any of the other library APIs and features.
 
 ### h) How long to fuzz a target?
 
-This is a difficult question. Basically if no new path is found for a long time
-(e.g., for a day or a week) then you can expect that your fuzzing won't be
+This is a difficult question. Basically, if no new path is found for a long time
+(e.g., for a day or a week), then you can expect that your fuzzing won't be
 fruitful anymore. However, often this just means that you should switch out
 secondaries for others, e.g., custom mutator modules, sync to very different
 fuzzers, etc.
diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md
index ca9ce933..d220e52c 100644
--- a/instrumentation/README.llvm.md
+++ b/instrumentation/README.llvm.md
@@ -269,7 +269,7 @@ can set:
 AFL_LLVM_SKIP_NEVERZERO=1
 ```
 
-If the target does not have extensive loops or functions that are called a lot
+If the target does not have extensive loops or functions that are called a lot,
 then this can give a small performance boost.
 
 Please note that the default counter implementations are not thread safe!
diff --git a/utils/afl_network_proxy/README.md b/utils/afl_network_proxy/README.md
index c478319a..c34463e2 100644
--- a/utils/afl_network_proxy/README.md
+++ b/utils/afl_network_proxy/README.md
@@ -1,6 +1,6 @@
 # afl-network-proxy
 
-If you want to run afl-fuzz over the network than this is what you need :)
+If you want to run afl-fuzz over the network, then this is what you need. :)
 Note that the impact on fuzzing speed will be huge, expect a loss of 90%.
 
 ## When to use this
diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md
index cd87998b..da0e0c77 100644
--- a/utils/afl_untracer/README.md
+++ b/utils/afl_untracer/README.md
@@ -15,7 +15,7 @@ Supported is so far Intel (i386/x86_64) and AARCH64.
 
 ### Modify afl-untracer.c
 
-Read and modify afl-untracer.c then `make`.
+Read and modify afl-untracer.c, then `make`.
 To adapt afl-untracer.c to your needs, read the header of the file and then
 search and edit the `STEP 1`, `STEP 2` and `STEP 3` locations.
 
diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md
index 8b9fe15f..c547aaea 100644
--- a/utils/aflpp_driver/README.md
+++ b/utils/aflpp_driver/README.md
@@ -5,20 +5,20 @@
 aflpp_driver is used to compile directly libfuzzer `LLVMFuzzerTestOneInput()`
 targets.
 
-Just do `afl-clang-fast++ -o fuzz fuzzer_harness.cc libAFLDriver.a [plus required linking]`.
+Just do `afl-clang-fast++ -o fuzz fuzzer_harness.cc libAFLDriver.a [plus
+required linking]`.
 
-You can also sneakily do this little trick:
-If this is the clang compile command to build for libfuzzer:
-  `clang++ -o fuzz -fsanitize=fuzzer fuzzer_harness.cc -lfoo`
-then just switch `clang++` with `afl-clang-fast++` and our compiler will
+You can also sneakily do this little trick: If this is the clang compile command
+to build for libfuzzer: `clang++ -o fuzz -fsanitize=fuzzer fuzzer_harness.cc
+-lfoo`, then just switch `clang++` with `afl-clang-fast++` and our compiler will
 magically insert libAFLDriver.a :)
 
-To use shared-memory test cases, you need nothing to do.
-To use stdin test cases, give `-` as the only command line parameter.
-To use file input test cases, give `@@` as the only command line parameter.
+To use shared-memory test cases, you need nothing to do. To use stdin test
+cases, give `-` as the only command line parameter. To use file input test
+cases, give `@@` as the only command line parameter.
 
-IMPORTANT: if you use `afl-cmin` or `afl-cmin.bash` then either pass `-`
-or `@@` as command line parameters.
+IMPORTANT: if you use `afl-cmin` or `afl-cmin.bash`, then either pass `-` or
+`@@` as command line parameters.
 
 ## aflpp_qemu_driver
 
@@ -38,6 +38,6 @@ AFL_QEMU_PERSISTENT_HOOK=/path/to/aflpp_qemu_driver_hook.so afl-fuzz -Q ... -- .
 ```
 
 if you use afl-cmin or `afl-showmap -C` with the aflpp_qemu_driver you need to
-set the set same AFL_QEMU_... (or AFL_FRIDA_...) environment variables.
-If you want to use afl-showmap (without -C) or afl-cmin.bash then you may not
-set these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`.
\ No newline at end of file
+set the set same AFL_QEMU_... (or AFL_FRIDA_...) environment variables. If you
+want to use afl-showmap (without -C) or afl-cmin.bash, then you may not set
+these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`.
\ No newline at end of file