Open CounterCycle opened 1 year ago
Hi CounterCycle,
thank you for reporting the issues. The AFL++ support could use some more love. I think you grasp the issues pretty well!
Are you able to tackle some of these and maybe create a pull request?
Tobi
I made a pull request to the fuzzware-pipeline repo to address the main issue. https://github.com/fuzzware-fuzzer/fuzzware-pipeline/pull/4
It's not a perfect solution, as it still falls back on using the entire corpus, rather than fixing the minimization. I think a proper fix would require patching AFL++.
I don't think I'll have a chance to fix the other issues in the near future, so I'll leave them to someone else if they can take a go at fixing them. They don't prevent fuzzing of any binaries, but would be nice to have.
Thanks, CounterCycle
Hello,
I've been doing some testing with AFL++ after the fixes done in issue #7, thanks for resolving that. I've encountered a couple of additional issues.
Most significantly, some pipeline sessions exit during the middle of fuzzing. The failure seems to occur when a round of modelling is completed. An error line appear stating "Exit code 2 != 0 received from afl-showmap, terminating...". Then an exception in python for no such file or directory at/main/base_inputs. I've pasted the error output below.
I encountered this issue fuzzing the Zephyr SocketCAN binary from the fuzzware-experiments repo. I believe the issue is triggered when an input discovered using the old models triggers a firmware crash when run with the new models.
Additionally, I've noticed some minor issues with other components when AFL++ is used. Using fuzzware fuzz in AFL++ mode failed to start, even when pipeline works. And the output from fuzzware genstats coverage contains incorrect timestamps for block discoveries, I'm guessing because AFL++ already uses relative times in the plot_data file, while AFL used Unix time.
Thank-you, CounterCycle