VS Debug vs. Release Build compatibility with WinAFL

1,087 views
Skip to first unread message

rahul.gu...@gmail.com

unread,
Jun 11, 2018, 8:01:58 PM6/11/18
to afl-users
I am following a tutorial on fuzzing MSXML with WinAFL here: https://symeonp.github.io/2017/09/17/fuzzing-winafl.html.

When I build the symeon.cpp harness in Visual Studio 2017 in debug mode, the WinAFL run using symeon.exe succeeds:

$ ./winafl-master/winafl-master/bin32/afl-fuzz.exe -i io/in/ -o io/out/ -D DR/DR/bin32/ -t 10000 -- -coverage_module msxml6.dll -target_module symeon.exe -target_method fuzzme -nargs 1 -- p/symeon.exe @@


However, when I build release-symeon.cpp in release mode, the WinAFL run immediately fails. I do not understand why this is happening since the timeout is 100 seconds.

$ ./winafl-master/winafl-master/bin32/afl-fuzz.exe -i io/in/ -o io/out/ -D DR/DR/bin32/ -t 100000 -- -coverage_module msxml6.dll -target_module release-symeon.exe -target_method fuzzme -nargs 1 -- p/release-symeon.exe @@

0 processes nudged
WinAFL 1.13 by <ifra...@google.com>
Based on AFL 2.43b by <lca...@google.com>
[+] You have 8 CPU cores and 0 runnable tasks (utilization: 0%).
[+] Try parallel jobs - see docs\parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'io/i/'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...
[-] The program took more than 10000 ms to process one of the initial test cases.
    Usually, the right thing to do is to relax the -t option - or to delete it
    altogether and allow the fuzzer to auto-calibrate. That said, if you know
    what you are doing and want to simply skip the unruly test cases, append
    '+' at the end of the value passed to -t ('-t 10000+').
[-] PROGRAM ABORT : Test case 'id_000000' results in a timeout
         Location : perform_dry_run(), ..\afl-fuzz.c:2815

☣Adam

unread,
Jun 11, 2018, 8:11:37 PM6/11/18
to afl-...@googlegroups.com
My guess is that the compiler is stripping the symbol for "fuzzme" that you are passing in on the command line.

To troubleshoot further, check for the symbol with dumpbin as shown in the blog post. If that's not it, try running the target with drrun.exe similar to what is shown in the blog post. See the DynamioRIO docs for more info about drrun.

Older versions of Visual Studio will probably fix the issue, whatever it is.

Best of luck,
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.

rahul.gu...@gmail.com

unread,
Jun 12, 2018, 1:17:24 PM6/12/18
to afl-users
Thanks for the quick reply Adam. This is what I am seeing:

dumpbin RELEASE
   ordinal hint RVA name 
1  0  000027E0 fuzzme = _fuzzme 
2  1  00002810 main = _main 

dumpbin DEBUG
ordinal hint RVA name
1  0  00011186 fuzzme = @ILT+385(_fuzzme)
2  1  000114DD main = @ILT+1240(_main)

The drrun.exe output for DEBUG shows normal behavior, but for RELEASE, I am seeing:
WARNING: Target function was never called. Incorrect target_offset?

Is there a way to resolve this using VS 2017?

☣Adam

unread,
Jun 12, 2018, 6:18:24 PM6/12/18
to afl-...@googlegroups.com
Try using -target_offset

The readme for winafl has the details on these options. Your symbols look fine to me, so I'm not sure why it's failing, but using an offset will probably fix it.

Also, there's a known bug in DynamoRIO's loader which fails to load newer VS runtime binaries (issue 2658 on their GitHub repo), but we have only seen that on Win7. Win8, 8.1, and 10 seem to work OK. Not sure if you are hitting that or not.

Hope this gets you sorted out.

--Adam

rahul.gu...@gmail.com

unread,
Jun 13, 2018, 5:20:24 PM6/13/18
to afl-users
Do you recommend that I use something like IDA to find the target offset? Is there a way to automate this?

☣Adam

unread,
Jun 13, 2018, 8:05:16 PM6/13/18
to afl-...@googlegroups.com
If the offsets from dumpbin were incorrect, then yes, I'd suggest checking them with a disassembler (IDA, Binary Ninja, etc.). Dumpbin should work though, and be able to be scripted.

If not, both Binary Ninja and IDA have Python interfaces you should be able to use to script this.
Reply all
Reply to author
Forward
0 new messages