Minor doc fixes (#339)
This commit is contained in:
parent
f5bed190e7
commit
7eb293e087
@ -172,7 +172,7 @@ let mut generator = RandPrintablesGenerator::new(32);
|
|||||||
|
|
||||||
// Generate 8 initial inputs
|
// Generate 8 initial inputs
|
||||||
state
|
state
|
||||||
.generate_initial_inputs(&mut executor, &mut generator, &mut mgr, &scheduler, 8)
|
.generate_initial_inputs(&mut fuzzer, &mut executor, &mut generator, &mut mgr, 8)
|
||||||
.expect("Failed to generate the initial corpus".into());
|
.expect("Failed to generate the initial corpus".into());
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -187,6 +187,7 @@ use libafl::{
|
|||||||
corpus::{InMemoryCorpus, OnDiskCorpus, QueueCorpusScheduler},
|
corpus::{InMemoryCorpus, OnDiskCorpus, QueueCorpusScheduler},
|
||||||
events::SimpleEventManager,
|
events::SimpleEventManager,
|
||||||
executors::{inprocess::InProcessExecutor, ExitKind},
|
executors::{inprocess::InProcessExecutor, ExitKind},
|
||||||
|
fuzzer::StdFuzzer,
|
||||||
generators::RandPrintablesGenerator,
|
generators::RandPrintablesGenerator,
|
||||||
inputs::{BytesInput, HasTargetBytes},
|
inputs::{BytesInput, HasTargetBytes},
|
||||||
state::StdState,
|
state::StdState,
|
||||||
@ -257,27 +258,33 @@ The observers are usually kept in the corresponding executor as they keep track
|
|||||||
|
|
||||||
```rust,ignore
|
```rust,ignore
|
||||||
// Create the executor for an in-process function with just one observer
|
// Create the executor for an in-process function with just one observer
|
||||||
let mut executor =
|
let mut executor = InProcessExecutor::new(
|
||||||
InProcessExecutor::new(&mut harness, tuple_list!(observer), &mut state, &mut mgr)
|
&mut harness,
|
||||||
.expect("Failed to create the Executor".into());
|
tuple_list!(observer),
|
||||||
|
&mut fuzzer,
|
||||||
|
&mut state,
|
||||||
|
&mut mgr,
|
||||||
|
)
|
||||||
|
.expect("Failed to create the Executor".into());
|
||||||
```
|
```
|
||||||
|
|
||||||
Now that the fuzzer can observe which condition is satisfied, we need a way to rate an input as interesting (i.e. worth of addition to the corpus) based on this observation. Here comes the notion of Feedback. The Feedback is part of the State and provides a way to rate input and its corresponding execution as interesting looking for the information in the observers. Feedbacks can maintain a cumulative state of the information seen so far in a so-called FeedbackState instance, in our case it maintains the set of conditions satisfied in the previous runs.
|
Now that the fuzzer can observe which condition is satisfied, we need a way to rate an input as interesting (i.e. worth of addition to the corpus) based on this observation. Here comes the notion of Feedback. The Feedback is part of the State and provides a way to rate input and its corresponding execution as interesting looking for the information in the observers. Feedbacks can maintain a cumulative state of the information seen so far in a so-called FeedbackState instance, in our case it maintains the set of conditions satisfied in the previous runs.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
Feedbacks are used also to decide if an input is a "solution". The feedback that does that is called the Objective Feedback and when it rates an input as interested it is not saved to the corpus but to the solutions, written in the `crashes` folder in our case. We use the CrashFeedback to tell the fuzzer that if an input causes the program to crash it is a solution for us.
|
Feedbacks are used also to decide if an input is a "solution". The feedback that does that is called the Objective Feedback and when it rates an input as interesting it is not saved to the corpus but to the solutions, written in the `crashes` folder in our case. We use the 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:
|
We need to update our State creation including the feedback state and the Fuzzer including the feedback and the objective:
|
||||||
|
|
||||||
```rust,ignore
|
```rust,ignore
|
||||||
extern crate libafl;
|
extern crate libafl;
|
||||||
use libafl::{
|
use libafl::{
|
||||||
bolts::{rands::StdRand,
|
bolts::{current_nanos, rands::StdRand, tuples::tuple_list},
|
||||||
corpus::{InMemoryCorpus, OnDiskCorpus, RandCorpusScheduler},
|
corpus::{InMemoryCorpus, OnDiskCorpus},
|
||||||
events::{setup_restarting_mgr_std, EventConfig, EventRestarter},
|
|
||||||
feedbacks::{MapFeedbackState, MaxMapFeedback, CrashFeedback},
|
feedbacks::{MapFeedbackState, MaxMapFeedback, CrashFeedback},
|
||||||
fuzzer::{StdFuzzer},
|
fuzzer::StdFuzzer,
|
||||||
|
state::StdState,
|
||||||
|
observers::StdMapObserver,
|
||||||
};
|
};
|
||||||
|
|
||||||
// The state of the edges feedback.
|
// The state of the edges feedback.
|
||||||
@ -318,6 +325,14 @@ Another central component of LibAFL are the Stages, that are actions done on ind
|
|||||||
As the last step, we create a MutationalStage that uses a mutator inspired by the havoc mutator of AFL.
|
As the last step, we create a MutationalStage that uses a mutator inspired by the havoc mutator of AFL.
|
||||||
|
|
||||||
```rust,ignore
|
```rust,ignore
|
||||||
|
use libafl::{
|
||||||
|
mutators::scheduled::{havoc_mutations, StdScheduledMutator},
|
||||||
|
stages::mutational::StdMutationalStage,
|
||||||
|
fuzzer::Fuzzer,
|
||||||
|
};
|
||||||
|
|
||||||
|
// ...
|
||||||
|
|
||||||
// Setup a mutational stage with a basic bytes mutator
|
// Setup a mutational stage with a basic bytes mutator
|
||||||
let mutator = StdScheduledMutator::new(havoc_mutations());
|
let mutator = StdScheduledMutator::new(havoc_mutations());
|
||||||
let mut stages = tuple_list!(StdMutationalStage::new(mutator));
|
let mut stages = tuple_list!(StdMutationalStage::new(mutator));
|
||||||
|
Loading…
x
Reference in New Issue
Block a user