Tags: fbaltor/LibAFL
Tags
Remove {update,clear}_hash from ObserverWithHashField, add hasher (ex… …tending AFLplusplus#1019) (AFLplusplus#1028) * libafl: Remove `{update,clear}_hash` from `ObserverWithHashField` These methods aren't used by `NewHashFeedback`, so there's no compelling reason to keep them in the interface. They preclude implementations of `ObserverWithHashField` that calculcate a hash on-the-fly from a value. For example, my use-case is to store the stdout of a process, and use `NewHashFeedback` to only collect inputs that result in new messages on stdout. Both of these methods are pretty suspicious to begin with - why should other code be able to update the internal state of the observer? What are the semantics of `update_hash`? If there are compelling reasons to keep these methods, let's clarify their intent in the documentation. * libafl: Return hash by value from `ObserverWithHashField` This allows implementors of this trait to not store the hash, but rather to compute it on-the-fly. Since `Option<u64>` is `Copy` (and quite small), and this method is called once per execution of the target program, this is likely to have negligible performance impact. * libafl: Implement `ObserverWithHashField` for `ValueObserver` This demonstrates the utility of the previous two commits. Now, `ValueObserver` can be used with `NewHashFeedback`. * Clippy, move to ahasher * Oops :) --------- Co-authored-by: Langston Barrett <[email protected]>
Metadata lookup once (AFLplusplus#186) * metadata lookup once * fix clippy
Minor changes for 0.3.0 (AFLplusplus#108) * update baby fuzzer in book * readme * readme * book
PreviousNext