fixed some minor typos in the book

docs/src/design/core_concepts.md

@@ -80,7 +80,7 @@ Generators are traditionally less used in Feedback-driven Fuzzing, but there are
 
 A Stage is an entity that operates on a single Input got from the Corpus.
 
-For instamce, 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 use a performance score of the input to choose how many times the havoc mutator should be invoked. This can depends 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 time. How many times this has to be done can be scheduled, AFL for instance use a performance score of the input to choose how many times the havoc mutator should be invoked. This can depends 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.
 
 A stage can be also 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/getting_started/build.md

@@ -20,6 +20,6 @@ The directory contains a set of crates that are not part of the workspace.
 
 Each of these example fuzzers uses particular features of LibAFL, sometimes combined with different instrumentation backends (e.g. [SanitizerCoverage](https://clang.llvm.org/docs/SanitizerCoverage.html), [Frida](https://frida.re/), ...).
 
-You can use these crates as examples and as skeletons for custom fuzzers with similar featuresets.
+You can use these crates as examples and as skeletons for custom fuzzers with similar feature sets.
 
 To build an example fuzzer you have to invoke cargo from its respective folder (`fuzzers/[FUZZER_NAME]).

docs/src/getting_started/crates.md

@@ -11,7 +11,7 @@ This is the main crate that contains all the components needed to build a fuzzer
 
 This crate has the following feature flags:
 
-- std, that enables the parts of the code that use the Rust standard library. Without this flags, libafl is no_std.
+- std, that enables the parts of the code that use the Rust standard library. Without this flag, libafl is no_std.
 - derive, that enables the usage of the `derive(...)` macros defined in libafl_derive from libafl.
 
 By default, std and derive are both set.

docs/src/introduction.md

@@ -25,5 +25,5 @@ To give an example, as opposed to old-skool fuzzers, a `BytesInput` is just one
 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 on the near road-map.
 - `fast`: We do everything we can at compiletime so that the runtime overhead is as minimal as it can get.
-- `bring your own target`: We support binary-only modes, like Frida-Mode with ASAN and CmpLog, as well as multiple compilation passes for sourced-based instrumentation, and of course supoprt custom instrumentation.
+- `bring your own target`: We support binary-only modes, like Frida-Mode with ASAN and CmpLog, as well as multiple compilation passes for sourced-based instrumentation, and of course support custom instrumentation.
 - `usable`: This one is on you to decide. Dig right in!