LibAFL icon indicating copy to clipboard operation
LibAFL copied to clipboard

Count Executions With Same Observer Value

Open riesentoaster opened this issue 1 year ago • 0 comments

Is your feature request related to a problem? Please describe. I have a target that is unstable, i.e. for the same input I don't always get the same observation.

Describe the solution you'd like I would like to have a way to count how often a certain Observer observes the same value to get a frequency distribution and figure out how bad things are. This could be implemented in three levels:

  1. A pure count of how often each observed value is measured — this would only really be useful with a single corpus entry and a NopMutator, but maybe a good start.
  2. A count of how often each value is measured, along with an example input that triggers this execution
  3. A count of how often each value is measured, along with a list of all inputs that triggered this execution — this would be really inefficient, but maybe useful for debugging.

Describe alternatives you've considered Right now, in a very hacky way, I just hash the observer value in the executor and append that hash to a file. It also gets put in some metadata in the corpus, so I can correlate them after the fact. This is wildly inefficient. And I'm using the single corpus entry/NopMutator strategy.

I've also attempted to implement this as a feedback that updates a count field in some metadata entry on each is_interesting call, but I could not get those updated metadata values to be written to disk. It's also a bit hacky, because in is_interesting, I only have the input, and not the testcase, so I have to manually extract that from state -> corpus -> testcase. If this were to work, it would basically provide solution 2. But I'm not sure it's possible, I don't know the internals well enough.

Lastly, one could write a feedback that keeps an internal representation of input-outcome values (e.g. HashMap with the Observer value as the key and a tuple of (count, example_input) as the value, to get solution level 2. These values could then be written to disk at a certain interval, similar to OnDiskTomlMonitor.

Additional context I'm just curious if anyone has an opinion on how this could be done in a pretty way.

riesentoaster avatar Nov 23 '24 13:11 riesentoaster