googleprojectzero
LOAD_DLL_DEBUG_EVENT filename error
Hey all,
I find a error in winaflpt.c:1175，I run the winaflpt-debug as follow
winaflpt-debug.exe -debug -coverage_module pdfcore.dll -fuzz_iterations 10 -target_module E:\w.exe -target_offset 0x1270 -nargs 2 -- E:\w.exe E:\a.pdf
I log the file when LOAD_DLL_DEBUG_EVENT
I aslo use Process Monitor to log the load dll behavior of target exe,
From Process Monitor we can see pdfcore.dll load at 0xfd10000
But In the Output, It does not contain pdfcore.dll, it's name changed to IDHLPAPI.dll
Because pdfcore.dll is my coverage_module,so it's critical.
And Finally it out As follow
[-] PROGRAM ABORT : Process exited before reaching the target method
Location : run_target_pt(), D:\workflow\2019-3-22-afl-intelpt\winafl\winaflpt.c:1438
I can not figure where is wrong!
Interesting. Could you check the return value of GetFinalPathNameByHandleA, possibly it is failing and that's why you get the name of the previous DLL. Could you also check if the file handle (1st argument) is valid?
As for your other question about the target method, target_module takes just the base name, not the path, so -target_module E:\w.exe should be -target_module w.exe. Most likely this is the reason.
GetFinalPathNameByHandleA return 0
i think we should add the judge of the return value of GetFinalPathNameByHandleA
As for your other question about the target method, target_module takes just the base name, not the path, so -target_module E:\w.exe should be -target_module w.exe. Most likely this is the reason.
this one i change , Now it report another error
the value of DebugEv->u.LoadDll.hFile aslo is 0, I am tring to figure out why
I see. The problem is that base_name is used later. However, we can do this:
- If the file handle is NULL, set base_name to null and add a breakpoint to the module entrypoint as usual
- Later, module_name in winafl_breakpoint structure will end up empty as seen in https://github.com/googleprojectzero/winafl/blob/master/winaflpt.c#L530
- Then, in on_module_loaded (https://github.com/googleprojectzero/winafl/blob/master/winaflpt.c#L769), you can check if module_name is empty, and if so, call GetModuleBaseNameA to correct the module name.
As for the other error, I see eventCode: 5 in your screenshot which means the process exited so we can't query the trace for it. Assuming the target function is returning normally and not calling exit() or something similiar, I'm not sure why we're not catching that return, though it would be useful to know what events occured before.
To expand a bit on how catching the return from target function is supposed to work: When the target function is reached for the first time, its return address is overwritten with 0x0AF1 here https://github.com/googleprojectzero/winafl/blob/master/winaflpt.c#L912. When a return is attempted, this results in an exception which is caught in https://github.com/googleprojectzero/winafl/blob/master/winaflpt.c#L1128.
Sorry to bother you again! I fix some error above and try to fuzz now! But strange error happen! I use command as follow
afl-fuzz.exe -i E:\in -o E:\out -P -t 20000 -- -coverage_module pdfcore.dll -fuzz_iterations 10 -target_module w.exe -target_offset 0x1270 -nargs 2 -- E: \w.exe @@
And it reports as follow
[-] PROGRAM ABORT : Module pdfcore.dll loaded in the address range that module pdfcore.dll previously occupied. This is currently unsupported.
Location : add_module_to_section_cache(), D:\workflow\2019-3-22-afl-intelpt\winafl\winaflpt.c:727
Process Monitor log as follow
In Dry Run, the second time target process load pdfcore.dll,But the address is different bettween the first time's address. So it cause error in https://github.com/googleprojectzero/winafl/blob/master/winaflpt.c#L726
And the main program use loadlibrary to load pdfcore.dll dynamically. The ida screenshot as follow
Because it use many function in pdfcore.dll，and the context is complicated, so i did not write a wrapper to load pdfcore.dll and fuzz it.
Thanks for your patience on my question!
So nice you are!
Hmm, yeah, currently WinAFL in PT mode does support module loading and unloading during iterations, but only if the module is always loaded on the same address (which is usually the case on Windows as ASLR only kicks in once per boot, unfortunately this is not the case here, not sure why). I could (and should) fix this (e.g. by also tracking the unload events and removing the module from section cache, but that would also mean having to clear the PT decoder cache and the performance would suffer greatly as a result.
If it's only this one DLL that is causing problems, perhaps the easiest solution here would be to modify the DLL headers and force it to always load on the same address.
Ok I figure out how to modify the DLL headers to force it to always load on the same address. Could you give me any reference? Although i am trying to search this on Google now. Thanks!
Perhaps this tool will work? https://blog.didierstevens.com/2010/10/17/setdllcharacteristics/
And if that doesn't work there is also EDITBIN https://docs.microsoft.com/en-us/cpp/build/reference/editbin-options?view=vs-2017
Hi, I was wondering if you managed to get the DLL to load on the fixed address and if that resolved your issues - it would also be useful to know for others who encounter the same problem.
Sorry I went to holiday for few day! I try this tool https://blog.didierstevens.com/2010/10/17/setdllcharacteristics/ it works, although the speed is very slow.(1.65/sec!) I change the PT buffer size to 2410241024 to make it don't report overflow warning, I think large size may stuck the fuzzing~~ Anyway,thanks you very much!
I see. That PT buffer size may indicate that a lot is happening inside your target function (for the sense of measure, PT buffer of 24MB could correspond to ~200 million basic blocks or possibly even more), which is not ideal for fuzzing. My suggestion would be to try to build a custom harness that fuzzes just the logic you want. See this blog post for some tips on doing that: https://research.checkpoint.com/50-adobe-cves-in-50-days/
Also, please note that the PT buffer size should be a power of 2, in your case it will probably be rounded down to 16MB.