Documentation fixes (#967)

* a few stylistic/grammar changes

* expression

* some wording and a different git clone command

The original `git clone` command did not work for me (permission denied).

* small wording changes

* review

* typo

* neutral

Co-authored-by: hexcoder <hexcoder-@users.noreply.github.com>

docs/src/baby_fuzzer/baby_fuzzer.md

@@ -105,8 +105,8 @@ fn main(){
 
 ## Generating and running some tests
 
-One of the main components that a LibAFL-based fuzzer uses is the State, a container of the data that is evolved during the fuzzing process.
-Includes all State, such as the Corpus of inputs, the current RNG state, and potential Metadata for the testcases and run.
+One of the main components that a LibAFL-based fuzzer uses is the State, a container of the data that will evolve during the fuzzing process.
+It includes all state, such as the Corpus of inputs, the current RNG state, and potential Metadata for the testcases and run.
 In our `main` we create a basic State instance like the following:
 
 ```rust,ignore
@@ -129,8 +129,8 @@ let mut state = StdState::new(
 
   To avoid type annotation error, you can use `InMemoryCorpus::<BytesInput>::new()` to replace `InMemoryCorpus::new()`. If not, type annotation will be automatically inferred when adding `executor`.
 
-- third parameter is another corpus that stores the "solution" testcases for the fuzzer. For our purpose, the solution is the input that triggers the panic. In this case, we want to store it to disk under the `crashes` directory, so we can inspect it.
-- last two parameters are feedback and objective, we will discuss them later.
+- The third parameter is another Corpus that stores the "solution" testcases for the fuzzer. For our purpose, the solution is the input that triggers the panic. In this case, we want to store it to disk under the `crashes` directory, so we can inspect it.
+- The last two parameters are feedback and objective, we will discuss them later.
 
 Another required component is the **EventManager**. It handles some events such as the addition of a testcase to the corpus during the fuzzing process. For our purpose, we use the simplest one that just displays the information about these events to the user using a `Monitor` instance.
 
@@ -225,7 +225,7 @@ Now we want to turn our simple fuzzer into a feedback-based one and increase the
 **Observer** can record the information about properties of a fuzzing run and then feeds the fuzzer. We use the `StdMapObserver`, the default observer that uses a map to keep track of covered elements. In our fuzzer, each condition is mapped to an entry of such map.
 
 We represent such map as a `static mut` variable.
-As we don't rely on any instrumentation engine, we have to manually track the satisfied conditions by `singals_set` in our harness:
+As we don't rely on any instrumentation engine, we have to manually track the satisfied conditions by `signals_set` in our harness:
 
 ```rust
 extern crate libafl;
@@ -287,7 +287,7 @@ Now that the fuzzer can observe which condition is satisfied, we need a way to r
 
 We use `MaxMapFeedback`, a feedback that implements a novelty search over the map of the MapObserver. Basically, if there is a value in the observer's map that is greater than the maximum value registered so far for the same entry, it rates the input as interesting and updates its state.
 
-**Objective Feedback** is another kind of Feedback which decide if an input is a "solution". It will save input to solutions(`./crashes` in our case) other than corpus when the input is rated interesting. We use `CrashFeedback` to tell the fuzzer that if an input causes the program to crash it is a solution for us.
+**Objective Feedback** is another kind of Feedback which decides if an input is a "solution". It will save input to solutions(`./crashes` in our case) rather than corpus when the input is rated interesting. We use `CrashFeedback` to tell the fuzzer that if an input causes the program to crash it is a solution for us.
 
 We need to update our State creation including the feedback state and the Fuzzer including the feedback and the objective:
 
@@ -356,7 +356,7 @@ fuzzer
 
 `fuzz_loop` will request a testcase for each iteration to the fuzzer using the scheduler and then it will invoke the stage.
 
-After adding this code, we have a proper fuzzer, that can run a find the input that panics the function in less than a second.
+After adding this code, we have a proper fuzzer, that can run and find the input that panics the function in less than a second.
 
 ```text
 $ cargo run

docs/src/baby_fuzzer/more_examples.md

@@ -9,4 +9,4 @@ Examples can be found under `./fuzzer`.
 | baby_fuzzer_nautilus | [nautilus](https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_04A-3_Aschermann_paper.pdf) is a **coverage guided, grammar based** fuzzer|
 |baby_fuzzer_tokens| basic **token level** fuzzer with token level mutations|
 |baby_fuzzer_with_forkexecutor| example for **InProcessForkExecutor**|
-|baby_no_std|a minimalistic example how to create a libafl based fuzzer that works on **`no_std`** environments like TEEs, Kernels or on barew metal|
+|baby_no_std|a minimalistic example how to create a libafl based fuzzer that works on **`no_std`** environments like TEEs, Kernels or on bare metal|

docs/src/getting_started/crates.md

@@ -10,7 +10,7 @@ libafl = { version = "*" }
 
 ## Crate List
 
-For LibAFL, each crate has its self-contained purpose, and the user may not need to use all of them in its project.
+For LibAFL, each crate has its self-contained purpose, and the user may not need to use all of them in their project.
 Following the naming convention of the folders in the project's root, they are:
 
 ### [`libafl`](https://github.com/AFLplusplus/LibAFL/tree/main/libafl)
@@ -52,13 +52,13 @@ To enable and disable features at compile-time, the features are enabled and dis
 Currently, the supported flags are:
 
 - `pcguard_edges` defines the SanitizerCoverage trace-pc-guard hooks to track the executed edges in a map.
-- `pcguard_hitcounts defines the SanitizerCoverage trace-pc-guard hooks to track the executed edges with the hitcounts (like AFL) in a map.
+- `pcguard_hitcounts` defines the SanitizerCoverage trace-pc-guard hooks to track the executed edges with the hitcounts (like AFL) in a map.
 - `libfuzzer` exposes a compatibility layer with libFuzzer style harnesses.
 - `value_profile` defines the SanitizerCoverage trace-cmp hooks to track the matching bits of each comparison in a map.
 
 ### libafl_cc
 
-This is a library that provides utils wrap compilers and create source-level fuzzers.
+This is a library that provides utils to wrap compilers and create source-level fuzzers.
 
 At the moment, only the Clang compiler is supported.
 To understand it deeper, look through the tutorials and examples.

docs/src/getting_started/setup.md

@@ -11,15 +11,15 @@ The first step is to download LibAFL and all dependencies that are not automatic
 > previous command. Additionally, PowerShell-specific examples will use `>`
 > rather than `$`.
 
-While you technically do not need to install LibAFL, but can use the version from crates.io directly, we do recommend to download or clone the GitHub version.
+While technically you do not need to install LibAFL, but can use the version from crates.io directly, we do recommend to download or clone the GitHub version.
 This gets you the example fuzzers, additional utilities, and latest patches.
 The easiest way to do this is to use `git`.
 
 ```sh
-$ git clone git@github.com:AFLplusplus/LibAFL.git
+$ git clone https://github.com/AFLplusplus/LibAFL.git
 ```
 
-You can alternatively, on a UNIX-like machine, download a compressed archive and extract it with:
+Alternatively, on a UNIX-like machine, you can download a compressed archive and extract it with:
 
 ```sh
 wget https://github.com/AFLplusplus/LibAFL/archive/main.tar.gz
@@ -31,7 +31,7 @@ $ ls LibAFL-main # this is the extracted folder
 ## Clang installation
 
 One of the external dependencies of LibAFL is the Clang C/C++ compiler.
-While most of the code is in pure Rust, we still need a C compiler because stable Rust still does not support features that some parts of LibAFL may need, such as weak linking, and LLVM builtins linking.
+While most of the code is written in pure Rust, we still need a C compiler because stable Rust still does not support features that some parts of LibAFL may need, such as weak linking, and LLVM builtins linking.
 For these parts, we use C to expose the missing functionalities to our Rust codebase.
 
 In addition, if you want to perform source-level fuzz testing of C/C++ applications,

docs/src/introduction.md

@@ -4,7 +4,7 @@ Fuzzers are important tools for security researchers and developers alike.
 A wide range of state-of-the-art tools like [AFL++](https://github.com/AFLplusplus/AFLplusplus), [libFuzzer](https://llvm.org/docs/LibFuzzer.html) or [honggfuzz](https://github.com/google/honggfuzz) are available to users. They do their job in a very effective way, finding thousands of bugs.
 
 From the perspective of a power user, however, these tools are limited.
-Their design does not treat extensibility as a first-class citizen.
+Their designs do not treat extensibility as a first-class citizen.
 Usually, a fuzzer developer can choose to either fork one of these existing tools, or to create a new fuzzer from scratch.
 In any case, researchers end up with tons of fuzzers, all of which are incompatible with each other.
 Their outstanding features cannot just be combined for new projects.
@@ -24,7 +24,7 @@ Some highlight features currently include:
 This means it does not require a specific OS-dependent runtime to function.
 Define an allocator and a way to map pages, and you are good to inject LibAFL in obscure targets like embedded devices, hypervisors, or maybe even WebAssembly?
 - `adaptable`: Given years of experience fine-tuning *AFLplusplus* and our academic fuzzing background, we could incorporate recent fuzzing trends into LibAFL's design and make it future-proof.
-To give an example, as opposed to old-skool fuzzers, a `BytesInput` is just one of the potential forms of inputs:
+To give an example, as opposed to old-school fuzzers, a `BytesInput` is just one of the potential forms of inputs:
 feel free to use and mutate an Abstract Syntax Tree instead, for structured fuzzing.
 - `scalable`: As part of LibAFL, we developed `Low Level Message Passing`, `LLMP` for short, which allows LibAFL to scale almost linearly over cores. That is, if you chose to use this feature - it is your fuzzer, after all.
 Scaling to multiple machines over TCP is also possible, using LLMP's `broker2broker` feature.

docs/src/libafl.md

@@ -5,7 +5,7 @@
 *by Andrea Fioraldi and Dominik Maier*
 
 Welcome to LibAFL, the Advanced Fuzzing Library.
-This book shall be a gentle introduction into the library.
+This book shall be a gentle introduction to the library.
 
 This version of the LibAFL book is coupled with the release 1.0 beta of the library.