Fuzzing GUI based applications on windows

[Dollar Strike]

Hello,

Is it possible to fuzz binaries having an GUI using win-afl?

For example:

zenmap which is a GUI version of Nmap

7zip with GUI (though 7zip have cli mode, curious to know if we can fuzz GUI) 

[☣Adam]

Yes, but since the program doesn't automatically exit, every iteration is going to be either a timeout or a crash unless you reverse the binary and specify a function to run.

In the later case, the program will run without instrumentation until it hits that function. It will then run the function with instrumentation (but any library calls will not be instrumented by default IIRC, so like calls to parsers with love in other DLLs). When it gets to the end of the function it will terminate the process unless you are using the in memory fuzzing feature.

If using the in memory fuzzing feature, it will test the stack and run the function again. If this is effectively the function which reads and parses the input file, it'll read new input data and it'll work great. I've never seen it work at all in practice because these operations are seldom called from the same function that also returns, file handles are not closed if the file is still in use, other global state isn't cleaned up, and do on. However, seeing the count to 1 avoids all these problems by just feeding the program one input pet execution. Of course this means executing all the startup overhead for every input which can be a multiple second operation depending on the target program.

Your other option would be to write your own program which calls the same library functions in the same order and does clean up all the global state. If you have source code, this might not be too bad. If not, it is a significant investment of time.

For programs which have a CLI version, it probably makes more sense to just fix those instead of the GUI based counterparts. The GUI operations and less likely to have memory corruption bugs than, for example, the parsers which handle various compressed formats.

Fuzzing GUI apps which don't terminate without user intersection is a hard problem. I haven't seen many fuzzers try to address this. Most projects just find a ways to work around it which are also much more CPU efficient than executing all that GUI code repeatedly. Killerbeez deals with the issue by allowing a target specific "driver" to be written which can exit the program when an alert box pops up (e.g. "zip file is corrupt" error), or when sounds stops playing for a media playing app, or whatever you want to consider the stopping condition. The problem is that it requires writing custom code. A generic driver could be based on CPU usage, but I'd expect that to be less accurate. Of course you can still take the more traditional approaches with Killerbeez too, and that's probably going to be the better approch most of the time, but we just like giving users options. :-)

Full disclosure: I lead the team which created Killerbeez and it was originally based on WinAFL.

Hope that helps,

Adam

--
You received this message because you are subscribed to the Google Groups "afl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.