Valentin Huber

(Continuing the discussion from #2138) `StdOutObserver`s etc. are fairly closely coupled to the specific `Executor` they work with, since they need close interaction. @tokatoka's suggestion in #2138: > When instantiate...

Theoretically yes but practically no. I would like to have the system mutate both parts of the input in all the ways the havoc mutators would. So yes, I can...

> then you put plug this mutator with the existing havoc_mutation That's exactly the issue. How would I do this? The existing havoc_mutations don't seem to have an interface for...

Alright, let me start from the beginning. I have an struct that looks as follows (with only two parts for simplicity's sake, but this should work with n parts in...

I want to find a solution that is transparent to the wrapping mutation scheduler, so that it has full control over all mutators on all parts of the input (i.e....

Alright, I've implemented what I think you suggested: ```rust use std::borrow::Cow; use libafl::{ inputs::{BytesInput, HasBytesVec, Input, UsesInput}, mutators::{MutationResult, Mutator}, Error, }; use libafl_bolts::Named; pub struct MappingMutator { extractor: for &'a...

Alright, I've had another play around. And I'm pretty sure what I'm trying to do is still not possible without reimplementing all mutators in `havoc_mutations`. I cannot reasonably implement `HasMutatorBytes`...

I'm sorry for the confusion. I'll try to summarise my requirements for this custom `Input` type again. Conceptually, I'm doing differential fuzzing on two implementations of the same command line...

> &mut Vec.into() already implements HasMutatorBytes Hey, that's what I needed! What I've currently got: ```rust use std::borrow::Cow; use libafl::{ inputs::{MutVecInput, UsesInput}, mutators::{MutationResult, Mutator}, Error, }; use libafl_bolts::Named; pub struct...

(Even better, it's very easy to write something similar for optional args, as in where the extractor returns an `Option`)