Change "AFL" to "AFL++"

docs/INSTALL.md

@@ -20,7 +20,7 @@ The easiest choice is to build and install everything:
 sudo apt-get update
 sudo apt-get install -y build-essential python3-dev automake git flex bison libglib2.0-dev libpixman-1-dev python3-setuptools
 # try to install llvm 11 and install the distro default if that fails
-sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang 
+sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang
 sudo apt-get install -y gcc-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-plugin-dev libstdc++-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-dev
 sudo apt-get install -y ninja-build # for qemu_mode
 git clone https://github.com/AFLplusplus/AFLplusplus
@@ -114,8 +114,8 @@ This means two things:
   - Fuzzing will be probably slower than on Linux. In fact, some folks report
     considerable performance gains by running the jobs inside a Linux VM on
     MacOS X.
-  - Some non-portable, platform-specific code may be incompatible with the
-    AFL forkserver. If you run into any problems, set `AFL_NO_FORKSRV=1` in the
+  - Some non-portable, platform-specific code may be incompatible with the AFL++
+    forkserver. If you run into any problems, set `AFL_NO_FORKSRV=1` in the
     environment before starting afl-fuzz.
 
 User emulation mode of QEMU does not appear to be supported on MacOS X, so black-box instrumentation mode (`-Q`) will not work.

docs/afl-fuzz_approach.md

@@ -348,7 +348,7 @@ 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,
 it will earn a score of 100%. When the value is lower but still shown in purple,
 the fuzzing process is unlikely to be negatively affected. If it goes into red,
-you may be in trouble, since AFL will have difficulty discerning between
+you may be in trouble, since AFL++ will have difficulty discerning between
 meaningful and "phantom" effects of tweaking the input file.
 
 Now, most targets will just get a 100% score, but when you see lower figures,
@@ -506,7 +506,7 @@ directory. This includes:
 - `edges_found`       - how many edges have been found
 - `var_byte_count`    - how many edges are non-deterministic
 - `afl_banner`        - banner text (e.g. the target name)
-- `afl_version`       - the version of AFL used
+- `afl_version`       - the version of AFL++ used
 - `target_mode`       - default, persistent, qemu, unicorn, non-instrumented
 - `command_line`      - full command line used for the fuzzing session
 

docs/custom_mutators.md

@@ -21,7 +21,8 @@ fuzzing by using libraries that perform mutations according to a given grammar.
 
 The custom mutator is passed to `afl-fuzz` via the `AFL_CUSTOM_MUTATOR_LIBRARY`
 or `AFL_PYTHON_MODULE` environment variable, and must export a fuzz function.
-Now AFL also supports multiple custom mutators which can be specified in the same `AFL_CUSTOM_MUTATOR_LIBRARY` environment variable like this.
+Now AFL++ also supports multiple custom mutators which can be specified in the
+same `AFL_CUSTOM_MUTATOR_LIBRARY` environment variable like this.
 ```bash
 export AFL_CUSTOM_MUTATOR_LIBRARY="full/path/to/mutator_first.so;full/path/to/mutator_second.so"
 ```

docs/env_variables.md

@@ -307,7 +307,7 @@ checks or alter some of the more exotic semantics of the tool:
     (`-i in`). This is an important feature to set when resuming a fuzzing
     session.
 
-  - Setting `AFL_CRASH_EXITCODE` sets the exit code AFL treats as crash. For
+  - Setting `AFL_CRASH_EXITCODE` sets the exit code AFL++ treats as crash. For
     example, if `AFL_CRASH_EXITCODE='-1'` is set, each input resulting in a `-1`
     return code (i.e. `exit(-1)` got called), will be treated as if a crash had
     occurred. This may be beneficial if you look for higher-level faulty
@@ -493,7 +493,7 @@ checks or alter some of the more exotic semantics of the tool:
     This is especially useful when running multiple instances (`-M/-S` for
     example). Applied tags are `banner` and `afl_version`. `banner` corresponds
     to the name of the fuzzer provided through `-M/-S`. `afl_version`
-    corresponds to the currently running AFL version (e.g. `++3.0c`). Default
+    corresponds to the currently running AFL++ version (e.g. `++3.0c`). Default
     (empty/non present) will add no tags to the metrics. For more information,
     see [rpc_statsd.md](rpc_statsd.md).
 

docs/fuzzing_in_depth.md

@@ -106,9 +106,9 @@ You can select the mode for the afl-cc compiler by:
 MODE can be one of: LTO (afl-clang-lto*), LLVM (afl-clang-fast*), GCC_PLUGIN
 (afl-g*-fast) or GCC (afl-gcc/afl-g++) or CLANG(afl-clang/afl-clang++).
 
-Because no AFL specific command-line options are accepted (beside the --afl-MODE
-command), the compile-time tools make fairly broad use of environment variables,
-which can be listed with `afl-cc -hh` or by reading
+Because no AFL++ specific command-line options are accepted (beside the
+--afl-MODE command), the compile-time tools make fairly broad use of environment
+variables, which can be listed with `afl-cc -hh` or by reading
 [env_variables.md](env_variables.md).
 
 ### b) Selecting instrumentation options
@@ -213,7 +213,7 @@ is more effective).
 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
 removed. This can even be done safely for source code used in operational
-products by eliminating these checks within these AFL specific blocks:
+products by eliminating these checks within these AFL++ specific blocks:
 
 ```
 #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION