WinAFL & windows executables with GUI

1,747 views
Skip to first unread message

Mike C

unread,
Dec 4, 2016, 10:36:20 PM12/4/16
to afl-users
Hi all, looking for anyone who's fuzzed with WinAFL.  Looks pretty awesome!! Anyway I am trying to fuzz an application that takes in an argument on the command line but launches a GUI that the user has to exit out manually.  Do you guys think the best route for this with WinAFL would be to find the point at which the function I want to fuzz returns, and replace it with a stub to just terminate the process? Any other thoughts that sound like they would be more efficient / better? Thanks!

ifra...@google.com

unread,
Dec 5, 2016, 4:33:14 AM12/5/16
to afl-users
Hi, In order to answer that question, you first need to know how your target app runs under WinAFL. When you select a target function and fuzz the app this happens:

1. Your target runs normally until your target function is reached.
2. WinAFL starts recording coverage
3. Your target function runs until return
4. WinAFL reports coverage, rewrites the input file and patches EIP so that the execution jumps back to step 2
5. After your target function runs for the specified number of iterations, the target process is killed and restarted. Notice that anything that runs after the target function returns is never reached.

The target function should do these things during its life

1. Open the input file (This needs to happen withing the target function so that you can read a new input file for each iteration as the input file is rewritten between target function runs).
2. Parse it (so that you can measure coverage of file parsing)
3. Close the input file (This is important because if the input file is not closed WinAFL won't be able to rewrite it)
4. Return normally (So that WinAFL can "catch" this return and redirect execution. "returning" via ExitProcess() and such won't work)

Whether the target shows GUI during some of these steps is irrelevant. What matters is whether your target requires user interaction between some steps above. If
a) you have a target function that behaves like the above and
b) your target does not require any user interaction until the end of the target function is reached
you're in luck and you can use WinAFL out of the box. If this is not the case, then unfortunately you need to either patch your target of WinAFL to suite the specific need of your target.

Terminating a process after each fuzzing iteration is possible, but WinAFL gets much of its speed due to the fact that it does *not* terminate the process for each fuzzing iteration and you'd be sacrificing that.

Mike C

unread,
Dec 7, 2016, 11:56:05 AM12/7/16
to afl-users
Ivan, thanks so much for your explanation it really helps my understanding of how it works, and now feel embarrassed about suggesting exiting the process ;).

Regarding the "nargs" argument, can you shed a little more light on this? Does calling convention matter? I am testing a C++ app that fulfills the requirements you mentioned quite nicely (it takes a filename as the sole argument but is a class method so is a "thiscall" convention). It seems to hit my target function one time then crash in the second iteration, leading me to believe that maybe I have nargs set wrong.

Thanks again!

Ivan Fratric

unread,
Dec 8, 2016, 5:31:59 AM12/8/16
to afl-...@googlegroups.com
The calling convention is the DynamoRIO default for the architecture, see DRWRAP_CALLCONV_DEFAULT for various architectures in https://github.com/DynamoRIO/dynamorio/blob/a71bf92fb995dada7bfb93046655b6f7c94a22e0/ext/drwrap/drwrap.h#L355

Incorrectly restoring function arguments is one reason why this would fail, but there is also another one: a target function that depend on (and alters) some global state or otherwise has side-effects that prevent it from running correctly multiple times (an ideal target function behaves exactly the same when called multiple times with the same arguments). Figuring out if which is the case might take some debugging.


--
You received this message because you are subscribed to a topic in the Google Groups "afl-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/afl-users/gHQRWpPTzR0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to afl-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages