Book review (#980)

* docs review

* docs review

* docs review wording

* docs review wording

* docs review wording

* wording

* nits

* wording

* wording

* nits

* docs_review wording

* wording

* wording

* wording

* Wording

* wording

* nits

* Wording

* fix main naming for afl++

* update symcc

Co-authored-by: Dominik Maier <dmnk@google.com>

docs/src/advanced_features/concolic.md

@@ -1,7 +1,7 @@
 # Concolic Tracing and Hybrid Fuzzing
 LibAFL has support for concolic tracing based on the [SymCC](https://github.com/eurecom-s3/symcc) instrumenting compiler.
 
-For those uninitiated, the following attempts to describe concolic tracing from the ground up using an example.
+For those uninitiated, the following text attempts to describe concolic tracing from the ground up using an example.
 Then, we'll go through the relationship of SymCC and LibAFL concolic tracing.
 Finally, we'll walk through building a basic hybrid fuzzer using LibAFL.
 
@@ -92,18 +92,18 @@ In hybrid fuzzing, we combine this tracing + solving approach with more traditio
 The concolic tracing support in LibAFL is implemented using SymCC.
 SymCC is a compiler plugin for clang that can be used as a drop-in replacement for a normal C or C++ compiler.
 SymCC will instrument the compiled code with callbacks into a runtime that can be supplied by the user.
-These callbacks allow the runtime to construct a trace that similar to the previous example.
+These callbacks allow the runtime to construct a trace that is similar to the previous example.
 
 ### SymCC and its Runtimes
 
 SymCC ships with 2 runtimes: 
 
- * a 'simple' runtime that attempts to solve any branches it comes across using [Z3](https://github.com/Z3Prover/z3/wiki) and
+ * a 'simple' runtime that attempts to solve any branch conditions it comes across using [Z3](https://github.com/Z3Prover/z3/wiki) and
- * a [QSym](https://github.com/sslab-gatech/qsym)-based runtime, which does a bit more filtering on the expressions and also solves using Z3.
+ * a [QSym](https://github.com/sslab-gatech/qsym)-based runtime, which does a bit more filtering on the expressions and also solves them using Z3.
 
 The integration with LibAFL, however, requires you to **BYORT** (_bring your own runtime_) using the [`symcc_runtime`](https://docs.rs/symcc_runtime/0.1/symcc_runtime) crate.
 This crate allows you to easily build a custom runtime out of the built-in building blocks or create entirely new runtimes with full flexibility.
-Checkout out the `symcc_runtime` docs for more information on how to build your own runtime.
+Check out the `symcc_runtime` docs for more information on how to build your own runtime.
 
 ### SymQEMU
 
@@ -123,7 +123,7 @@ There are three main steps involved with building a hybrid fuzzer using LibAFL:
 3. building the fuzzer.
 
 Note that the order of these steps is important.
-For example, we need to have runtime ready before we can do instrumentation with SymCC.
+For example, we need to have a runtime ready before we can do instrumentation with SymCC.
 
 ### Building a Runtime
 
@@ -137,7 +137,7 @@ There are two main instrumentation methods to make use of concolic tracing in Li
 * Using an **compile-time** instrumented target with **SymCC**. 
 This only works when the source is available for the target and the target is reasonably easy to build using the SymCC compiler wrapper.
 * Using **SymQEMU** to dynamically instrument the target at **runtime**.
-This avoids a separate instrumented target with concolic tracing instrumentation and does not require source code.
+This avoids building a separate instrumented target with concolic tracing instrumentation and so does not require source code.
 It should be noted, however, that the 'quality' of the generated expressions can be significantly worse and SymQEMU generally produces significantly more and significantly more convoluted expressions than SymCC.
 Therefore, it is recommended to use SymCC over SymQEMU when possible.
 
@@ -158,23 +158,23 @@ Make sure you satisfy the [build requirements](https://github.com/eurecom-s3/sym
 
 Build SymQEMU according to its [build instructions](https://github.com/eurecom-s3/symqemu#readme).
 By default, SymQEMU looks for the runtime in a sibling directory.
-Since we don't have a runtime there, we need to let it know the path to your runtime by setting `--symcc-build` argument of the `configure` script to the path of your runtime.
+Since we don't have a runtime there, we need to explicitly set the `--symcc-build` argument of the `configure` script to the path of your runtime.
 
 ### Building the Fuzzer
 
 No matter the instrumentation method, the interface between the fuzzer and the instrumented target should now be consistent.
 The only difference between using SymCC and SymQEMU should be the binary that represents the target:
-In the case of SymCC it will be the binary that was build with instrumentation and with SymQEMU it will be the emulator binary (eg. `x86_64-linux-user/symqemu-x86_64`), followed by your uninstrumented target binary and arguments.
+In the case of SymCC it will be the binary that was build with instrumentation and with SymQEMU it will be the emulator binary (eg. `x86_64-linux-user/symqemu-x86_64`), followed by your uninstrumented target binary and its arguments.
 
 You can use the [`CommandExecutor`](https://docs.rs/libafl/0.6.0/libafl/executors/command/struct.CommandExecutor.html) to execute your target ([example](https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/libfuzzer_stb_image_concolic/fuzzer/src/main.rs#L244)).
-When configuring the command, make sure you pass the `SYMCC_INPUT_FILE` environment variable the input file path, if your target reads input from a file (instead of standard input).
+When configuring the command, make sure you pass the `SYMCC_INPUT_FILE` environment variable (set to the input file path), if your target reads input from a file (instead of standard input).
 
 #### Serialization and Solving
 
 While it is perfectly possible to build a custom runtime that also performs the solving step of hybrid fuzzing in the context of the target process, the intended use of the LibAFL concolic tracing support is to serialize the (filtered and pre-processed) branch conditions using the [`TracingRuntime`](https://docs.rs/symcc_runtime/0.1/symcc_runtime/tracing/struct.TracingRuntime.html).
 This serialized representation can be deserialized in the fuzzer process for solving using a [`ConcolicObserver`](https://docs.rs/libafl/0.6.0/libafl/observers/concolic/struct.ConcolicObserver.html) wrapped in a [`ConcolicTracingStage`](https://docs.rs/libafl/0.6.0/libafl/stages/concolic/struct.ConcolicTracingStage.html), which will attach a [`ConcolicMetadata`](https://docs.rs/libafl/0.6.0/libafl/observers/concolic/struct.ConcolicMetadata.html) to every [`TestCase`](https://docs.rs/libafl/0.6.0/libafl/corpus/testcase/struct.Testcase.html).
 
-The `ConcolicMetadata` can be used to replay the concolic trace and solved using an SMT-Solver.
+The `ConcolicMetadata` can be used to replay the concolic trace and to solve the conditions using an SMT-Solver.
 Most use-cases involving concolic tracing, however, will need to define some policy around which branches they want to solve.
 The [`SimpleConcolicMutationalStage`](https://docs.rs/libafl/0.6.0//libafl/stages/concolic/struct.SimpleConcolicMutationalStage.html) can be used for testing purposes.
 It will attempt to solve all branches, like the original simple backend from SymCC, using Z3.

docs/src/advanced_features/frida.md

@@ -17,7 +17,7 @@ If you are on Windows, you'll need to install llvm tools.
 LibAFL uses Frida's [__Stalker__](https://frida.re/docs/stalker/) to trace the execution of your program and instrument your harness.
 Thus, you have to compile your harness to a dynamic library. Frida instruments your PUT after dynamically loading it.
 
-For example in our `frida_libpng` example, we load the dynamic library and find the symbol to harness as follows:
+In our `frida_libpng` example, we load the dynamic library and find the symbol to harness as follows:
 
 ```rust,ignore
         let lib = libloading::Library::new(module_name).unwrap();
@@ -28,9 +28,9 @@ For example in our `frida_libpng` example, we load the dynamic library and find
 
 ## `FridaInstrumentationHelper` and Runtimes
 
-To use functionalities that Frida offers, we'll first need to obtain `Gum` object by `Gum::obtain()`.
+To use functionalities that Frida offers, we'll first need to obtain a `Gum` object by `Gum::obtain()`.
 
-In LibAFL, we use the `FridaInstrumentationHelper` struct to manage frida-related state. `FridaInstrumentationHelper` is a key component that sets up the [__Transformer__](https://frida.re/docs/stalker/#transformer) that is used to generate the instrumented code. It also initializes the `Runtimes` that offer various instrumentation.
+In LibAFL, we use the `FridaInstrumentationHelper` struct to manage frida-related state. `FridaInstrumentationHelper` is a key component that sets up the [__Transformer__](https://frida.re/docs/stalker/#transformer) that is used to generate the instrumented code. It also initializes the `Runtimes` that offer various instrumentations.
 
 We have `CoverageRuntime` that can track the edge coverage,  `AsanRuntime` for address sanitizer, `DrCovRuntime` that uses [__DrCov__](https://dynamorio.org/page_drcov.html) for coverage collection (to be imported in coverage tools like Lighthouse, bncov, dragondance,...), and `CmpLogRuntime` for cmplog instrumentation.
 All of these runtimes can be slotted into `FridaInstrumentationHelper` at build time.
@@ -53,7 +53,7 @@ Combined with any `Runtime` you'd like to use, you can initialize the `FridaInst
 
 ## Running the Fuzzer
 
-After setting up the `FridaInstrumentationHelper`. You can obtain the pointer to the coverage map by calling `map_mut_ptr()`.
+After setting up the `FridaInstrumentationHelper` you can obtain the pointer to the coverage map by calling `map_mut_ptr()`.
 
 ```rust,ignore
         let edges_observer = HitcountsMapObserver::new(StdMapObserver::from_mut_ptr(
@@ -83,5 +83,5 @@ You can then link this observer to `FridaInProcessExecutor` as follows:
         );
 ```
 
-And, finally you can run the fuzzer.
+And finally you can run the fuzzer.
-See the `frida_` examples in [`./fuzzers`](https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers/) for more information and, for linux or full-system, play around with `libafl_qemu`, another binary-only tracer.
+See the `frida_` examples in [`./fuzzers`](https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers/) for more information and, for linux or full-system, play around with `libafl_qemu`, another binary-only tracer.

docs/src/advanced_features/no_std.md

@@ -1,6 +1,6 @@
 # Using LibAFL in `no_std` environments
 
-It is possible to use LibAFL in `no_std` environments e.g. custom platforms like microcontrollers, kernels, hypervisors, and more.
+It is possible to use LibAFL in `no_std` environments e.g. on custom platforms like microcontrollers, kernels, hypervisors, and more.
 
 You can simply add LibAFL to your `Cargo.toml` file:
 
@@ -16,7 +16,7 @@ cargo build --no-default-features --target aarch64-unknown-none
 
 ## Use custom timing
 
-The minimum amount of input LibAFL needs for `no_std` is a monotonically increasing timestamp.
+The minimum amount of support LibAFL needs for a `no_std` environment is a monotonically increasing timestamp.
 For this, anywhere in your project you need to implement the `external_current_millis` function, which returns the current time in milliseconds.
 
 ```c

docs/src/advanced_features/nyx.md

@@ -2,12 +2,12 @@
 
 NYX supports both source-based and binary-only fuzzing.
 
-Currently, `libafl_nyx` only supports [afl++](https://github.com/AFLplusplus/AFLplusplus)'s instruction. To install it, you can use `sudo apt install aflplusplus`. Or compile from the source:
+Currently, `libafl_nyx` only supports [afl++](https://github.com/AFLplusplus/AFLplusplus)'s instruction type. To install it, you can use `sudo apt install aflplusplus`. Or compile from the source:
 
 ```bash
 git clone https://github.com/AFLplusplus/AFLplusplus
 cd AFLplusplus
-make all # this will not compile afl's additional extension
+make all # this will not compile afl's additional extensions
 ```
 
 Then you should compile the target with the afl++ compiler wrapper:
@@ -20,9 +20,9 @@ export CXX=afl-clang-fast++
 make
 ```
 
-For binary-only fuzzing, Nyx uses intel-PT(Intel® Processor Trace). You can find the supported CPU at <https://www.intel.com/content/www/us/en/support/articles/000056730/processors.html>.
+For binary-only fuzzing, Nyx uses intel-PT(Intel® Processor Trace). You can find the list of supported CPUs at <https://www.intel.com/content/www/us/en/support/articles/000056730/processors.html>.
 
-## Preparing Nyx working directory
+## Preparing the Nyx working directory
 
 This step is used to pack the target into Nyx's kernel. Don't worry, we have a template shell script in our [example](https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/nyx_libxml2_parallel/setup_libxml2.sh):
 
@@ -49,7 +49,7 @@ python3 ./packer/packer/nyx_config_gen.py /tmp/nyx_libxml2/ Kernel || exit
 
 ## Standalone fuzzing
 
-In the [example fuzzer](https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/nyx_libxml2_standalone/src/main.rs). First you need to run `./setup_libxml2.sh`, It will prepare your target and create your nyx work directory in `/tmp/libxml2`. After that, you can start write your code.
+In the [example fuzzer](https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/nyx_libxml2_standalone/src/main.rs) you first need to run `./setup_libxml2.sh`. It will prepare your target and create your nyx work directory in `/tmp/libxml2`. After that, you can start to write your code.
 
 First, to create `Nyxhelper`:
 
@@ -57,7 +57,7 @@ First, to create `Nyxhelper`:
 let share_dir = Path::new("/tmp/nyx_libxml2/");
 let cpu_id = 0; // use first cpu
 let parallel_mode = false; // close parallel_mode
-let mut helper = NyxHelper::new(share_dir, cpu_id, true, parallel_mode, None).unwrap(); // we don't the set the last parameter in standalone mode, we just use None, here
+let mut helper = NyxHelper::new(share_dir, cpu_id, true, parallel_mode, None).unwrap(); // we don't need to set the last parameter in standalone mode, we just use None, here
 ```
 
 Then, fetch `trace_bits`, create an observer and the `NyxExecutor`:
@@ -67,11 +67,11 @@ let observer = unsafe { StdMapObserver::from_mut_ptr("trace", helper.trace_bits,
 let mut executor = NyxExecutor::new(&mut helper, tuple_list!(observer)).unwrap();
 ```
 
-Finally, use them as normal and pass them into `fuzzer.fuzz_loop(&mut stages, &mut executor, &mut state, &mut mgr)` to start fuzzing.
+Finally, use them normally and pass them into `fuzzer.fuzz_loop(&mut stages, &mut executor, &mut state, &mut mgr)` to start fuzzing.
 
 ## Parallel fuzzing
 
-In the [example fuzzer](https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/nyx_libxml2_parallel/src/main.rs). First you need to run `./setup_libxml2.sh` as described before.
+In the [example fuzzer](https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/nyx_libxml2_parallel/src/main.rs) you first need to run `./setup_libxml2.sh` as described before.
 
 Parallel fuzzing relies on [`Launcher`](../message_passing/spawn_instances.md), so spawn logic should be written in the scoop of anonymous function `run_client`:
 
@@ -90,7 +90,7 @@ let mut helper = NyxHelper::new(
     cpu_id,    // current cpu id
     true,      // open snap_mode
     parallel_mode, // open parallel mode
-    Some(parent_cpu_id.id as u32), // the cpu-id of master instance, there is only one master instance, other instances will be treated as slaved
+    Some(parent_cpu_id.id as u32), // the cpu-id of main instance, there is only one main instance, other instances will be treated as secondaries
 )
 .unwrap();
 ```
@@ -102,7 +102,7 @@ let observer = unsafe { StdMapObserver::from_mut_ptr("trace", helper.trace_bits,
 let mut executor = NyxExecutor::new(&mut helper, tuple_list!(observer)).unwrap();
 ```
 
-Finally, open a `Launcher` as normal to start fuzzing:
+Finally, open a `Launcher` as usual to start fuzzing:
 
 ```rust,ignore
 match Launcher::builder()

docs/src/core_concepts/corpus.md

@@ -4,8 +4,8 @@ The Corpus is where testcases are stored. We define a Testcase as an Input and a
 
 A Corpus can store testcases in different ways, for example on disk, or in memory, or implement a cache to speedup on disk storage.
 
-Usually, a testcase is added to the Corpus when it is considered as interesting, but a Corpus is used also to store testcases that fulfill an objective (like crashing the tested program for instance).
+Usually, a testcase is added to the Corpus when it is considered as interesting, but a Corpus is used also to store testcases that fulfill an objective (like crashing the program under test for instance).
 
-Related to the Corpus, there is the way in which the fuzzer should ask for the next testcase to fuzz picking it from the Corpus. The taxonomy for this in LibAFL is CorpusScheduler, the entity representing the policy to pop testcases from the Corpus, FIFO for instance.
+Related to the Corpus is the way in which the next testcase (the fuzzer would ask for) is retrieved from the Corpus. The taxonomy for this handling in LibAFL is CorpusScheduler, the entity representing the policy to pop testcases from the Corpus, in a FIFO fashion for instance.
 
 Speaking about the code, [`Corpus`](https://docs.rs/libafl/0/libafl/corpus/trait.Corpus.html) and [`CorpusScheduler`](https://docs.rs/libafl/0/libafl/corpus/trait.CorpusScheduler.html) are traits.

docs/src/core_concepts/executor.md

@@ -13,7 +13,7 @@ In Rust, we bind this concept to the [`Executor`](https://docs.rs/libafl/0/libaf
 
 By default, we implement some commonly used Executors such as [`InProcessExecutor`](https://docs.rs/libafl/0/libafl/executors/inprocess/struct.InProcessExecutor.html) in which the target is a harness function providing in-process crash detection. Another Executor is the [`ForkserverExecutor`](https://docs.rs/libafl/0/libafl/executors/forkserver/struct.ForkserverExecutor.html) that implements an AFL-like mechanism to spawn child processes to fuzz.
 
-A common pattern when creating an Executor is wrapping an existing one, for instance [`TimeoutExecutor`](https://docs.rs/libafl/0.6.1/libafl/executors/timeout/struct.TimeoutExecutor.html) wraps an executor and install a timeout callback before calling the original run function of the wrapped executor.
+A common pattern when creating an Executor is wrapping an existing one, for instance [`TimeoutExecutor`](https://docs.rs/libafl/0.6.1/libafl/executors/timeout/struct.TimeoutExecutor.html) wraps an executor and installs a timeout callback before calling the original `run` function of the wrapped executor.
 
 ## InProcessExecutor
 Let's begin with the base case; `InProcessExecutor`.
@@ -24,7 +24,7 @@ When you want to execute the harness as fast as possible, you will most probably
  One thing to note here is, when your harness is likely to have heap corruption bugs, you want to use another allocator so that corrupted heap does not affect the fuzzer itself. (For example, we adopt MiMalloc in some of our fuzzers.). Alternatively you can compile your harness with address sanitizer to make sure you can catch these heap bugs.
 
 ## ForkserverExecutor
-Next, we'll take a look at the `ForkserverExecutor`. In this case, it is `afl-cc` (from AFLplusplus/AFLplusplus) that compiles the harness code, and therefore, we can't use `EDGES_MAP` anymore. Hopefully, we have [_a way_](https://github.com/AFLplusplus/AFLplusplus/blob/2e15661f184c77ac1fbb6f868c894e946cbb7f17/instrumentation/afl-compiler-rt.o.c#L270) to tell the forkserver which map to record the coverage.
+Next, we'll take a look at the `ForkserverExecutor`. In this case, it is `afl-cc` (from AFLplusplus/AFLplusplus) that compiles the harness code, and therefore, we can't use `EDGES_MAP` anymore. Fortunately we have [_a way_](https://github.com/AFLplusplus/AFLplusplus/blob/2e15661f184c77ac1fbb6f868c894e946cbb7f17/instrumentation/afl-compiler-rt.o.c#L270) to tell the forkserver which map to record the coverage in.
 
 As you can see from the forkserver example,
 
@@ -48,7 +48,7 @@ See AFL++'s [_documentation_](https://github.com/AFLplusplus/AFLplusplus/blob/st
 Finally, we'll talk about the `InProcessForkExecutor`.
 `InProcessForkExecutor` has only one difference from `InprocessExecutor`; It forks before running the harness and that's it.
 
-But why do we want to do so? well, under some circumstances, you may find your harness pretty unstable or your harness wreaks havoc on the global states. In this case, you want to fork it before executing the harness runs in the child process so that it doesn't break things.
+But why do we want to do so? Well, under some circumstances, you may find your harness pretty unstable or your harness wreaks havoc on the global states. In this case, you want to fork it before executing the harness runs in the child process so that it doesn't break things.
 
 However, we have to take care of the shared memory, it's the child process that runs the harness code and writes the coverage to the map.
 

docs/src/core_concepts/feedback.md

@@ -11,16 +11,16 @@ The concept of "interestingness" is abstract, but typically it is related to a n
 As an example, given an Observer that reports all the sizes of memory allocations, a maximization Feedback can be used to maximize these sizes to sport pathological inputs in terms of memory consumption.
 
 In terms of code, the library offers the [`Feedback`](https://docs.rs/libafl/0/libafl/feedbacks/trait.Feedback.html) and the [`FeedbackState`](https://docs.rs/libafl/0/libafl/feedbacks/trait.FeedbackState.html) traits.
-The first is used to implement functors that, given the state of the observers from the last execution, tells if the execution was interesting. The second is tied with `Feedback` and it is the state of the data that the feedback wants to persist in the fuzzers's state, for instance the cumulative map holding all the edges seen so far in the case of a feedback based on edge coverage.
+The first is used to implement functors that, given the state of the observers from the last execution, tells if the execution was interesting. The second is tied with `Feedback` and is the state of the data that the feedback wants to persist in the fuzzers's state, for instance the cumulative map holding all the edges seen so far in the case of a feedback based on edge coverage.
 
-Multiple Feedbacks can be combined into boolean formula, considering for instance an execution as interesting if it triggers new code paths or execute in less time compared to the average execution time using [`feedback_or`](https://docs.rs/libafl/*/libafl/macro.feedback_or.html).
+Multiple Feedbacks can be combined into a boolean expression, considering for instance an execution as interesting if it triggers new code paths or execute in less time compared to the average execution time using [`feedback_or`](https://docs.rs/libafl/*/libafl/macro.feedback_or.html).
 
-On top, logic operators like `feedback_or` and `feedback_and` have a `_fast` option (`feedback_or_fast` where the second feedback will not be evaluated, if the first part already answers the `interestingness` question, to save precious performance.
+On top, logic operators like `feedback_or` and `feedback_and` have a `_fast` variant (e.g. `feedback_or_fast`) where the second feedback will not be evaluated, if the value of the first feedback operand already answers the `interestingness` question so as to save precious performance.
 
 Using `feedback_and_fast` in combination with [`ConstFeedback`](https://docs.rs/libafl/*/libafl/feedbacks/enum.ConstFeedback.html#method.new), certain feedbacks can be disabled dynamically.
 
 ## Objectives
 
 While feedbacks are commonly used to decide if an [`Input`](https://docs.rs/libafl/*/libafl/inputs/trait.Input.html) should be kept for future mutations, they serve a double-purpose, as so-called `Objective Feedbacks`.
-In this case, the `interestingness` of a feedback indicates, if an `Objective` has been hit.
+In this case, the `interestingness` of a feedback indicates if an `Objective` has been hit.
-Commonly, these would be a`crash or a timeout, but they can also be used to find specific parts of the program, for sanitization, or a differential fuzzing success.
+Commonly, these objectives would be a crash or a timeout, but they can also be used to detect if specific parts of the program have been reached, for sanitization, or a differential fuzzing success.

docs/src/core_concepts/input.md

@@ -6,10 +6,10 @@ In our model of an abstract fuzzer, we define the Input as the internal represen
 
 In the straightforward case, the input of the program is a byte array and in fuzzers such as AFL we store and manipulate exactly these byte arrays.
 
-But it is not always the case. A program can expect inputs that are not byte arrays (e.g. a sequence of syscalls) and the fuzzer does not represent the Input in the same way that the program consumes it.
+But it is not always the case. A program can expect inputs that are not linear byte arrays (e.g. a sequence of syscalls forming a use case or protocol) and the fuzzer does not represent the Input in the same way that the program consumes it.
 
 In case of a grammar fuzzer for instance, the Input is generally an Abstract Syntax Tree because it is a data structure that can be easily manipulated while maintaining the validity, but the program expects a byte array as input, so just before the execution, the tree is serialized to a sequence of bytes.
 
 In the Rust code, an [`Input`](https://docs.rs/libafl/*/libafl/inputs/trait.Input.html) is a trait that can be implemented only by structures that are serializable and have only owned data as fields.
 
-While most fuzzer use a normal `BytesInput`], more advanced inputs like inputs include special inputs for grammar fuzzing ([GramatronInput](https://docs.rs/libafl/*/libafl/inputs/gramatron/struct.GramatronInput.html) or `NautilusInput` on nightly), as well as the token-level [EncodedInput](https://docs.rs/libafl/*/libafl/inputs/encoded/struct.EncodedInput.html).
+While most fuzzers use a normal `BytesInput`, more advanced ones use inputs that include special inputs for grammar fuzzing ([GramatronInput](https://docs.rs/libafl/*/libafl/inputs/gramatron/struct.GramatronInput.html) or `NautilusInput` on Rust nightly), as well as the token-level [EncodedInput](https://docs.rs/libafl/*/libafl/inputs/encoded/struct.EncodedInput.html).

docs/src/core_concepts/mutator.md

@@ -1,9 +1,9 @@
 # Mutator
 
-The Mutator is an entity that takes one or more Inputs and generates a new derived one.
+The Mutator is an entity that takes one or more Inputs and generates a new instance of Input derived by its inputs.
 
 Mutators can be composed, and they are generally linked to a specific Input type.
 
-There can be, for instance, a Mutator that applies more than a single type of mutation on the input. Consider a generic Mutator for a byte stream, bit flip is just one of the possible mutations but not the only one, there is also, for instance, the random replacement of a byte of the copy of a chunk.
+There can be, for instance, a Mutator that applies more than a single type of mutation to the input. Consider a generic Mutator for a byte stream, bit flip is just one of the possible mutations but not the only one, there is also, for instance, the random replacement of a byte of the copy of a chunk.
 
 In LibAFL, [`Mutator`](https://docs.rs/libafl/*/libafl/mutators/trait.Mutator.html) is a trait.

docs/src/core_concepts/observer.md

@@ -4,8 +4,8 @@ An Observer is an entity that provides an information observed during the execut
 
 The information contained in the Observer is not preserved across executions, but it may be serialized and passed on to other nodes if an `Input` is considered `interesting`, and added to the `Corpus`.
 
-As an example, the coverage map, filled during the execution to report the executed edges used by fuzzers such as AFL and `HonggFuzz` can be considered an observation. Another `Observer` can be the time spent executing a run, the program output, or more advanced observation, like maximum stack depth at runtime.
+As an example, the coverage map, filled during the execution to report the executed edges used by fuzzers such as AFL and `HonggFuzz` can be considered an observation. Another `Observer` can collect the time spent executing a run, the program output, or a more advanced observation, like maximum stack depth at runtime.
-This information is not preserved across runs, and it is an observation of a dynamic property of the program.
+This information is an observation of a dynamic property of the program.
 
 In terms of code, in the library this entity is described by the [`Observer`](https://docs.rs/libafl/0/libafl/observers/trait.Observer.html) trait.
 

docs/src/core_concepts/stage.md

@@ -1,8 +1,8 @@
 # Stage
 
-A Stage is an entity that operates on a single Input got from the Corpus.
+A Stage is an entity that operates on a single Input received from the Corpus.
 
-For instance, a Mutational Stage, given an input of the corpus, applies a Mutator and executes the generated input one or more time. How many times this has to be done can be scheduled, AFL for instance uses a performance score of the input to choose how many times the havoc mutator should be invoked. This can depend also on other parameters, for instance, the length of the input if we want to just apply a sequential bitflip, or be a fixed value.
+For instance, a Mutational Stage, given an input of the corpus, applies a Mutator and executes the generated input one or more times. How many times this has to be done can be scheduled, AFL for instance uses a performance score of the input to choose how many times the havoc mutator should be invoked. This can depend also on other parameters, for instance, the length of the input if we want to just apply a sequential bitflip, or a fixed value.
 
 A stage can also be an analysis stage, for instance, the Colorization stage of Redqueen that aims to introduce more entropy in a testcase or the Trimming stage of AFL that aims to reduce the size of a testcase.
 

docs/src/design/architecture.md

@@ -10,6 +10,6 @@ Thinking about similar fuzzers, you can observe that most of the time the data s
 
 Beside the entities previously described, we introduce the [`Testcase`](https://docs.rs/libafl/0.6/libafl/corpus/testcase/struct.Testcase.html) and [`State`](https://docs.rs/libafl/0.6/libafl/state/struct.StdState.html) entities. The Testcase is a container for an Input stored in the Corpus and its metadata (so, in the implementation, the Corpus stores Testcases) and the State contains all the metadata that are evolved while running the fuzzer, Corpus included.
 
-The State, in the implementation, contains only owned objects that are serializable, and it is serializable itself. Some fuzzers may want to serialize its state when pausing or just, when doing in-process fuzzing, serialize on crash and deserialize in the new process to continue to fuzz with all the metadata preserved.
+The State, in the implementation, contains only owned objects that are serializable, and it is serializable itself. Some fuzzers may want to serialize their state when pausing or just, when doing in-process fuzzing, serialize on crash and deserialize in the new process to continue to fuzz with all the metadata preserved.
 
 Additionally, we group the entities that are "actions", like the `CorpusScheduler` and the `Feedbacks`, in a common place, the [`Fuzzer'](https://docs.rs/libafl/*/libafl/fuzzer/struct.StdFuzzer.html).

docs/src/design/metadata.md

@@ -19,7 +19,7 @@ pub struct MyMetadata {
 
 The struct must be static, so it cannot hold references to borrowed objects.
 
-As an alternative to `derive(SerdeAny)` that is a proc-macro in `libafl_derive` the user can use `libafl::impl_serdeany!(MyMetadata);`.
+As an alternative to `derive(SerdeAny)` which is a proc-macro in `libafl_derive` the user can use `libafl::impl_serdeany!(MyMetadata);`.
 
 ## Usage
 

docs/src/design/migration-0.9.md

@@ -75,7 +75,7 @@ where
 ```
 
 The executor is constrained to `EM` and `Z`, with each of their respective states being constrained to `E`'s state. It
-is no longer necessary to explicitly defined a generic for the input type, the state type, or the generic type, as these
+is no longer necessary to explicitly define a generic for the input type, the state type, or the generic type, as these
 are all present as associated types for `E`. Additionally, we don't even need to specify any details about the observers
 (`OT` in the previous version) as the type does not need to be constrained and is not shared by other types.
 
@@ -101,7 +101,7 @@ See `fuzzers/` for examples of these changes.
 If you implemented a Mutator, Executor, State, or another kind of component, you must update your implementation. The
 main changes to the API are in the use of "Uses*" for associated types.
 
-In many scenarios, Input, Observers, and State generics have been moved into traits with associated types (namely,
+In many scenarios, Input, Observer, and State generics have been moved into traits with associated types (namely,
 "UsesInput", "UsesObservers", and "UsesState". These traits are required for many existing traits now and are very
 straightforward to implement. In a majority of cases, you will have generics on your custom implementation or a fixed
 type to implement this with. Thankfully, Rust will let you know when you need to implement this type.
@@ -127,7 +127,7 @@ where
 }
 ```
 
-After 0.9, all `Corpus` implementations are required to implement `UsesInput` and `Corpus` no longer has a generic for
+After 0.9, all `Corpus` implementations are required to implement `UsesInput`. Also `Corpus` no longer has a generic for
 the input type (as it is now provided by the UsesInput impl). The migrated implementation is shown below:
 
 ```rust,ignore
@@ -163,7 +163,7 @@ A more complex example of migration can be found in the "Reasons for this change
 
 ## Observer Changes
 
-Additionally, we changed the observers API, as the API in 0.8 led to undefined behavior.
+Additionally, we changed the Observer API, as the API in 0.8 led to undefined behavior.
 At the same time, we used the change to simplify the common case: creating an `StdMapObserver`
 from libafl_target's `EDGES_MAP`.
 In the future, instead of using:
@@ -181,5 +181,5 @@ let edges_observer = unsafe { std_edges_map_observer("edges") };
 
 Alternatively, `StdMapObserver::new` will still work, but now the whole method is marked as `unsafe`.
 The reason is that the caller has to make sure `EDGES_MAP` (or other maps) are not moved or freed in memory,
-for the lifetime of the lifetime of the `MapObserver`.
+for the lifetime of the `MapObserver`.
 This means that the buffer should either be `static` or `Pin`.

docs/src/message_passing/message_passing.md

@@ -1,6 +1,6 @@
 # Message Passing
 
-LibAFL offers a standard mechanism for message passing over processes and machines with a low overhead.
+LibAFL offers a standard mechanism for message passing between processes and machines with a low overhead.
 We use message passing to inform the other connected clients/fuzzers/nodes about new testcases, metadata, and statistics about the current run.
 Depending on individual needs, LibAFL can also write testcase contents to disk, while still using events to notify other fuzzers, using an `OnDiskCorpus`.
 
@@ -28,12 +28,12 @@ Shared maps, called shared memory for the sake of not colliding with Rust's `map
 Each client, usually a fuzzer trying to share stats and new testcases, maps an outgoing `ShMem` map.
 With very few exceptions, only this client writes to this map, therefore, we do not run in race conditions and can live without locks.
 The broker reads from all client's `ShMem` maps.
-It checks all incoming client maps periodically and then forwards new messages to its outgoing broadcast-`ShMem`, mapped by all connected clients.
+It periodically checks all incoming client maps and then forwards new messages to its outgoing broadcast-`ShMem`, mapped by all connected clients.
 
 To send new messages, a client places a new message at the end of their shared memory and then updates a static field to notify the broker.
 Once the outgoing map is full, the sender allocates a new `ShMem` using the respective `ShMemProvider`.
 It then sends the information needed to map the newly-allocated page in connected processes to the old page, using an end of page (`EOP`) message.
-Once the receiver maps the new page, flags it as safe for unmapping from the sending process (to avoid race conditions if we have more than a single EOP in a short time), and then continues to read from the new `ShMem`.
+Once the receiver maps the new page, it flags it as safe for unmapping by the sending process (to avoid race conditions if we have more than a single EOP in a short time), and then continues to read from the new `ShMem`.
 
 The schema for client's maps to the broker is as follows:
 
@@ -54,10 +54,10 @@ After the broker received a new message from clientN, (`clientN_out->current_id
 
 The clients periodically, for example after finishing `n` mutations, check for new incoming messages by checking if (`current_broadcast_map->current_id != last_message->message_id`).
 While the broker uses the same EOP mechanism to map new `ShMem`s for its outgoing map, it never unmaps old pages.
-This additional memory overhead serves a good purpose: by keeping all broadcast pages around, we make sure that new clients can join in on a fuzzing campaign at a later point in time
+This additional memory resources serve a good purpose: by keeping all broadcast pages around, we make sure that new clients can join in on a fuzzing campaign at a later point in time.
 They just need to re-read all broadcasted messages from start to finish.
 
-So the outgoing messages flow like this over the outgoing broadcast `Shmem`:
+So the outgoing messages flow is like this over the outgoing broadcast `Shmem`:
 
 ```text
 [broker]

docs/src/message_passing/spawn_instances.md

@@ -8,14 +8,14 @@ The straightforward way to do Multi-Threading is to use the `LlmpRestartingEvent
 It abstracts away all the pesky details about restarts on crash handling (for in-memory fuzzers) and multi-threading.
 With it, every instance you launch manually tries to connect to a TCP port on the local machine.
 
-If the port is not yet bound, this instance becomes the broker, itself binding to the port to await new clients.
+If the port is not yet bound, this instance becomes the broker, binding itself to the port to await new clients.
 
 If the port is already bound, the EventManager will try to connect to it.
 The instance becomes a client and can now communicate with all other nodes.
 
 Launching nodes manually has the benefit that you can have multiple nodes with different configurations, such as clients fuzzing with and without ASAN.
 
-While it's called "restarting" manager, it uses `fork` on Unix operating systems as optimization and only actually restarts from scratch on Windows.
+While it's called "restarting" manager, it uses `fork` on Unix-like operating systems as optimization and only actually restarts from scratch on Windows.
 
 
 ## Automated, with Launcher
@@ -23,7 +23,7 @@ While it's called "restarting" manager, it uses `fork` on Unix operating systems
 The Launcher is the lazy way to do multiprocessing.
 You can use the Launcher builder to create a fuzzer that spawns multiple nodes with one click, all using restarting event managers and the same configuration.
 
-To use launcher, first you need to write an anonymous function `let mut run_client = |state: Option<_>, mut mgr, _core_id|{}`, which uses three parameters to create individual fuzzer. Then you can specify the `shmem_provider`,`broker_port`,`monitor`,`cores` and other stuff through `Launcher::builder()`:
+To use launcher, first you need to write an anonymous function `let mut run_client = |state: Option<_>, mut mgr, _core_id|{}`, which uses three parameters to create an individual fuzzer. Then you can specify the `shmem_provider`,`broker_port`,`monitor`,`cores` and other stuff through `Launcher::builder()`:
 
 ```rust,ignore
     Launcher::builder()
@@ -42,12 +42,12 @@ To use launcher, first you need to write an anonymous function `let mut run_clie
 This first starts a broker, then spawns `n` clients, according to the value passed to `cores`.
 The value is a string indicating the cores to bind to, for example, `0,2,5` or `0-3`.
 For each client, `run_client` will be called.
-On Windows, the Launcher will restart each client, while on Unix, it will use `fork`.
+On Windows, the Launcher will restart each client, while on Unix-alikes, it will use `fork`.
 
 Advanced use-cases:
 
 1. To connect multiple nodes together via TCP, you can use the `remote_broker_addr`. this requires the `llmp_bind_public` compile-time feature for `LibAFL`.
-2. To use multiple launchers for individual configurations, you can set `spawn_broker` to `false` on all but one.
+2. To use multiple launchers for individual configurations, you can set `spawn_broker` to `false` on all instances but one.
 3. Launcher will not select the cores automatically, so you need to specify the `cores` that you want.
 
 For more examples, you can check out `qemu_launcher` and `libfuzzer_libpng_launcher` in [`./fuzzers/`](https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers).

docs/src/tutorial/tutorial.md

@@ -2,4 +2,4 @@
 
 In this chapter, we will build a custom fuzzer using the [Lain](https://github.com/microsoft/lain) mutator in Rust.
 
-This tutorial will introduce you in writing extensions to LibAFL like Feedbacks and Testcase's metadata.
+This tutorial will introduce you to writing extensions to LibAFL like Feedbacks and Testcase's metadata.

libafl_concolic/symcc_runtime/symcc

@@ -1 +1 @@
-Subproject commit 5cccc33456c48ad83008eb618e7da5d005c72d89
+Subproject commit a42e95e754f7d8645957ab399d3eb346d2303b5a