is it feasible to transplant the thought of fork() into this project on windows? about winafl HOT 6 OPEN

I would disagree that fork() is unnecessary with persistent mode. Any sufficiently complicated (and poorly-written) app that maintains large amounts of global state will never get past a single iteration in persistent mode (from my own experience with using this) because jumping execution back to the target function will often fail some kind of check on the global state.

If I understand the fork() strategy correctly, it would actually mitigate this issue because you'd fork from a point where the global state is correct, so you would avoid the issue of rerunning the target function from a bad state. I suspect this would actually be very helpful with the target I'm fuzzing and I may be able to dedicate some time to getting it to work.

from winafl.

WinAFL alternative to fork() is persistent mode, that is, running multiple samples without restarting the target process. WinAFL user selects a target function (usually the function that processes the input file) via target_module / target_offset and once that function is reached it is ran in a loop instead of returning normally. In between the iterations WinAFL processes coverage data and replaces the input file with a fresh sample.

from winafl.

@ivanfratric you mean that it is unnecessary to do Fork()? And for the improvement done by Marcel Böhme's CCS16 Coverage-based Greybox Fuzzing as Markov Chain, do you think it benefits WinAFL？

from winafl.

Yes, in persistent mode fork() is unnecessary. It is possible to implement many different fuzzing strategies but that is outside the scope of this project. The goal of WinAFL was explicitly to mirror the functionality of AFL on windows. I have another project that would make it easier to plug custom fuzzing strategies while using winafl client for coverage measurement. I might merge this with WinAFL at some point, but as I wrote, for now this is out of scope.

from winafl.

Well, the current solution has its drawbacks but it is for the most part a working solution and it is working under severe constraints such as no fork on Windows and no access to target source code. Of course, if you have an idea how to do it better you are absolutely free to implement it, I'd welcome an alternative to WinAFL :-)

from winafl.

Just a quick comment - Windows includes an API that may help with restoring global state during persistent mode. The GetWriteWatch/ResetWriteWatch APIs could be used if a hook on VirtualAlloc set the MEM_WRITE_WATCH prior to global state being initialized.

from winafl.