Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mutator selection prioritization #483

Open
plotchy opened this issue May 20, 2024 · 2 comments
Open

Mutator selection prioritization #483

plotchy opened this issue May 20, 2024 · 2 comments

Comments

@plotchy
Copy link
Contributor

plotchy commented May 20, 2024

Ityfuzz selects mutators on random chance. There are two hyperparameters that can affect overall mutation:

  • MAX_STACK_POW (used in libafl to determine how many times in a row to mutate - min of 2, max of 128)
  • HAVOC_TIMES (used in mutators to determine how many iterations of libafl mutations to do - min of 1, max of 10)

The combination of these can produce a min of 2 or max of 1280 mutations to occur on a chosen input.

We are putting a lot of effort into mutating the input, can we do it in a smarter way? A paper like MOpt: Optimized Mutation Scheduling for Fuzzers shows that effort into tracking mutator effectiveness during a run can produce better results than always selecting randomly.
image
Like here the bitflip 1/1 is a really powerful mutator and should be selected more, but by default is equally selected.

They use a Particle Swarm Optimization to prioritize mutators. But i dont know what that means.. Apparently the strategy can be applied to all fuzzers.

@plotchy
Copy link
Contributor Author

plotchy commented May 20, 2024

DARWIN paper has a different take on this using an evolution system.

tho oddly default AFL seems to perform very closely to DARWIN and better than MOpt. Maybe this is better to leave alone

image

@shouc
Copy link
Contributor

shouc commented May 25, 2024

A few other papers (https://www.ndss-symposium.org/wp-content/uploads/2022-162-paper.pdf, https://dl.acm.org/doi/pdf/10.1145/3510003.3510174) also have some results on this. It seems that this really depends on the target we are fuzzing. I'll try to implement something similar and see how it works on smart contracts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants