googleprojectzero / winafl Goto Github PK

Hello, ivanfratric
When building WinAFL with visual studio 2010, I got lots of C2664 ERRORs about the conversion from “u8 *” to “const char *”. So I replace the
typedef uint8_t u8;
with
typedef char u8;.
However, as a result, I get a lot of problems when testing the generated EXE. And when I build it using dev c++ with gcc, I find the generated EXE get much larger than the original EXE. Meanwhile, the speed of fuzzing also slow down. Do you have any suggestions to solve the problems?

Hi, I ran the command like the following to check if DynamoRIO works with winafl:

D:\fuzz\DynamoRIO-Windows-6.2.0-2\bin32\drrun.exe -c D:\fuzz\winafl\bin32\winafl.dll -debug -target_module VUPlyaer.exe -target_offset 0x4532a0 -fuzz_iterations 10  --  VUPlayer.exe in

However, this command will terminate within 1 second and output nothing, no error, no logs. If I remove the -c winafl.dll option, the dynamo will somehow open the targeted exe file for me. It seems winafl has some problem working with dynamo.

Besides, if I use the following command, winafl seems to enter a endless loop and not taking CPU usage at all. The target program's process is also not showing up in the task manager.

D:/fuzz/winafl/bin32/afl-fuzz.exe -i in -o out -D D:/fuzz/DynamoRIO-Windows-6.2.0-2/bin32 -t 20000 --  -fuzz_iterations 5 -target_module VUPlayer.exe -target_offset 0x4532a0 -nargs 2 -- VUPlayer.exe

BTW, I'm using DynamoRIO 6.2.0-2.

Is it possible to fuzz a network application? I do have a python script that is able to send data to the network service and I do know the address of the function that is called for parsing the received data in the target application.
How would I go about doing this?

Thank you.

After days of fuzzing i finally found a BEX in unrar. But AFL didn't seem to catch it and just hung.
Long story short, forgot to make a dump and resumed AFL.
AFL deleted /queue/* and started looking for the /_resume. Which wasn't there because the last session closed forcefully. By then everything, including the last few permutations that lead to the access violation seem to be lost forever. Starting again, hoping to rediscover them....

Output:

[] Setting up output directories...
[+] Output directory exists, will attempt session resume.
[] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning '../../unrar/o_resume'...

[-] The input directory does not seem to be valid - try again. The fuzzer needs
one or more test case to start with - ideally, a small file under 1 kB
or so. The cases must be stored as regular files directly in the input
directory.

[-] SYSTEM ERROR : Unable to open '../../unrar/o_resume'
Stop location : read_testcases(), ..\afl-fuzz.c:1367
OS message : No such file or directory

PS: still in love with your code but as you can imagine this is frustrating as hell

Getting the following error:

C:\Users\akirilov\Desktop\test3>afl-fuzz.exe -i "inputs_small" -o "outputs" -D "C:\DynamoRIO-Windows-6.2.0-2\bin64" -t 60000 -f (redacted) -- -coverage_module (redacted) -coverage_module (redacted) -coverage_module (redacted) -fuzz_iterations 1 -target_module (redacted) -target_offset 0x11AC -nargs 2 -- "C:\xxxx\xxxx\(redacted)" (redacted)
WinAFL 1.02 by <[email protected]>
Based on AFL 1.96b by <[email protected]>
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'inputs_small'...
[+] 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 60000 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 60000+').

[-] PROGRAM ABORT : Test case 'id_000000' results in a hang
         Location : perform_dry_run(), ..\afl-fuzz.c:2511

My modules are just the module name (foo.dll) so not using the full path this time. I see the target program launch and exit cleanly, and it takes significantly less than a minute, yet I still get the same error message no matter how high I set the timeout. I tried without any coverage modules too in case that was the issue, and still no luck.

Hi Ivan,

Wanted to ask you how do you figure out the number of arguments passed to the target method when you have nothing but the binary, without symbols. I know that, for example, x64 programs follow this calling convention, so we can potentially induce parameter count from that, but can we always count on register and stack being set up immediately before the call, or is there some other trick?

Also, what are the consequences of using the wrong number arguments passed to the target method?

Hello ivanfratric

I installed WinAFL and it mostly seems to be running well. However after the WinAFL runs for some time, I get the following System Error message.

I am running the WinAFL tool as an Administrator, so I do not know why the OS denies permission.

Any thoughts?

hi @ifratric @ivanfratric

i have 2 questions regarding winafl

1. suppose i have binary test in which i have 2 modules test1.dll and test2.dll which coincidentally have same offset for different functions like 0202221111 and 303331111 which will be 1111 in both cases which gives us instrumentation data and is fuzzable how to identify which is the correct one
   how can we follow the approach i think its a silly question but still had a doubt so asked .

2. how to analyze hangs and crashes with winafl

Is it possible to fuzz the dll which the the program will load?
the program cpp code like:
typedef void (WINAPI *PGNSI)(LPSYSTEM_INFO);
int main()
{ HMODULE m = LoadLibraryA("C:\path\a.dll");
PGNSI a= (PGNSI)GetProcAddress(m, "GetInfo");
//printf("0x%p\n", m);
//printf("0x%p\n", a);
return 0;
}
I want to fuzz all the functions exposed by dll file (like a.dll), but in this way it does not work when i got the address to calculate the target_offset by GetProcAddress.
Error log: WARNING: Target function was never called. Incorrect target_offset?
Could you give some advice how to fuzz the dll with winafl ( if it is possible)?

When fuzzing a few extraction binaries i bumped into an inconvenience;

Having the program extract the input to stdout is neccesary to avoid tons of 'unique' extracted files with mangled filenames. And also because i find it soothing to watch a bunch of illegal unicode flash by XD.
But when i do this the output gets mixed with afl's.
i've tried redirecting the output to NUL and starting it in another window, unfortunately this doesn't play nice with how the command is passed to winafl.

Would it be possible to have the target binary start from a new window? Or could i do this myself and am i overlooking a command?

I try to us a dictionary but I get an error message:

C:\winafl\build32\Debug>afl-fuzz.exe -x dict -i in -o out -D C:\DynamoRIO-Windows-6.2.0-2\bin32 -t 2000 -- -coverage_module test.exe -fuzz_iteration
s 1000 -target_module test.exe -target_offset 0x31A80 -nargs 2 -- test.exe @@

WinAFL 1.02 by [email protected]
Based on AFL 1.96b by [email protected]
[] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[] Deleting old session data...
[+] Output dir cleanup successful.
[] Scanning 'in'...
[+] No auto-generated dictionary tokens to reuse.
[] Creating hard links for all input files...
[*] Loading extra dictionary from 'dict' (level 0)...

[-] SYSTEM ERROR : Unable to access 'dict\test.txt'
Stop location : load_extras(), C:\winafl\afl-fuzz.c:1636
OS message : No such file or directory

I created a file in the dict directory but it seems that WinAFL is looking for test.txt which is the input file ... What I'm doing wrong ?

I am trying to fuzz foxit reader with winafl , i have run the foxit reader in drrun using

drrun.exe -c winafl.dll -debug -target_module "foxitreader.exe" -target_offset 0x5d22a6 -fuzz_iterations 10 -nargs 2 -- "C:/Program Files (x86)/Foxit Software/Foxit Reader/foxitreader.exe" test.pdf

I have checked the log file and everything works fine.

But when I am tryin to fuzz using the below command I am getting the error

Assert Failure: ..\winafl.c:422: (unreconized command recieved over pipe) and the afl exits.

C:\Tools\winafl\bin32>afl-fuzz.exe -i "C:\Tools\in" -o "C:\Tools\out" -D "C:\Tools\rio\bin32" -t 20000 -- -fuzz_iterations 5000 -coverage_module "foxitreader.exe" -target_module "foxitreader.exe" -target_offset 0x5d22a6 -nargs 2 -- "C:/Program Files (x86)/Foxit Software/Foxit Reader/foxitreader.exe" @@
WinAFL 1.08 by [email protected]
Based on AFL 1.96b by [email protected]
[] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[] Deleting old session data...
[+] Output dir cleanup successful.
[] Scanning 'C:\Tools\in'...
[+] No auto-generated dictionary tokens to reuse.
[] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...

[-] PROGRAM ABORT : No instrumentation detected
Location : perform_dry_run(), ..\afl-fuzz.c:2641

Hi Ivan

While resuming a 7zip fuzzing session i noticed a lot of the files in the queue did not trigger new paths in the dry run. Upon inspecting the output it shows that with a lot of test cases the instrumentation varies per iteration, see below.

Is this maybe noise from translation of DR to AFL? Or could it point to something significant in the program being fuzzed ? For now it seems to be giving a lot of false positives in discovered paths.

    len = 54, map size = 2986, exec speed = 49926 us
[!] WARNING: No new instrumentation output, test case may be useless.
[!] WARNING: Instrumentation output varies across runs.
[*] Attempting dry run with 'id_000161'...


---


 len = 77, map size = 3684, exec speed = 78417 us
[!] WARNING: No new instrumentation output, test case may be useless.
[!] WARNING: Instrumentation output varies across runs.
[*] Attempting dry run with 'id_000163'...

---

  len = 2, map size = 2964, exec speed = 26817 us
[!] WARNING: No new instrumentation output, test case may be useless.
[*] Attempting dry run with 'id_000164'...

---

    len = 7, map size = 2986, exec speed = 33316 us
[!] WARNING: No new instrumentation output, test case may be useless.
[*] Attempting dry run with 'id_000167'...


---

    len = 60, map size = 2970, exec speed = 30770 us
[!] WARNING: No new instrumentation output, test case may be useless.
[*] Attempting dry run with 'id_000168'...

---

    len = 17, map size = 2970, exec speed = 29740 us
[!] WARNING: No new instrumentation output, test case may be useless.
[*] Attempting dry run with 'id_000169'...

----

    len = 77, map size = 3355, exec speed = 52465 us
[!] WARNING: No new instrumentation output, test case may be useless.
[!] WARNING: Instrumentation output varies across runs.
[*] Attempting dry run with 'id_000170'...


---

    len = 15, map size = 3354, exec speed = 38017 us
[!] WARNING: No new instrumentation output, test case may be useless.
[*] Attempting dry run with 'id_000171'...

---

[!] WARNING: No new instrumentation output, test case may be useless.
[!] WARNING: Instrumentation output varies across runs.

I am trying to fuzz with aflwin .. I have created a very simple print hello world application

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{   
        printf("argv[1]: %s\n", argv[1]);
    printf("Hello world\n");
    return 0;
}

Then I tried to fuzz using the following command

afl-fuzz.exe -i test_dll\in -o test_dll\out -D \path\to\DynamoRIO-Windows-6.1.1-3\bin64 -t 2000 -- -targert_module simple.exe targer_offset 0x1720 -fuzz_iterations 100 -- simple.exe @@
0 processes nudged
afl-fuzz 1.96b by <[email protected]>
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'test_dll\in'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...
Attempting to load .DLL: test_dll2...
DLL handle is: 6a1c0000
file: test_dll\out\.cur_input
arg1: test

[-] The program took more than 2000 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 2000+').

[-] PROGRAM ABORT : Test case 'id_000000' results in a hang
         Location : perform_dry_run(), ..\afl-fuzz.c:2451

I tried to locate what is wrong .. the only thing I can see when I try to run

C:\>path\to\DynamoRIO-Windows-6.1.1-3\bin32\drrun.exe -c winafl.dll -debug -target_module abc\simple.exe -target_offset 0x016F4 -fuzz_iterations 10 -nargs 2 -- abc\simple.exe

It doesn't run the application 10 times ... it only run the application once !!
Any ideas? ?

Looking to try converting the remaining afl tools over to windows. I've looked at afl-cmin and with it being bash I'm thinking it may be plausible to port it into Python or another Windows suitable language. What do you think?

c:\work\winafl\DynamoRIO-Windows-6.1.1-3\bin64\drrun.exe -c winafl.dll -debug -target_module notepad.exe -target_offset 0x3a14 -fuzz_iterations 5 -nargs 4 -- C:\Windows\system32\notepad.exe test.txt

runs only one time instead of 5 times

Module loaded, dynamorio.dll
Module loaded, KERNEL32.dll
Module loaded, USER32.dll
Module loaded, ntdll.dll
Module loaded, winafl.dll
Module loaded, drx.dll
Module loaded, drreg.dll
Module loaded, drmgr.dll
Module loaded, drwrap.dll
Module loaded, notepad.exe
Module loaded, WINSPOOL.DRV
Module loaded, COMCTL32.dll
Module loaded, VERSION.dll
Module loaded, KERNELBASE.dll
Module loaded, ADVAPI32.dll
Module loaded, GDI32.dll
Module loaded, SHLWAPI.dll
Module loaded, USP10.dll
Module loaded, MSCTF.dll
Module loaded, SHELL32.dll
Module loaded, RPCRT4.dll
Module loaded, IMM32.dll
Module loaded, SECHOST.dll
Module loaded, msvcrt.dll
Module loaded, COMDLG32.dll
Module loaded, ole32.dll
Module loaded, LPK.dll
Module loaded, OLEAUT32.dll
Module loaded, VERIFIER.dll
Module loaded, CRYPTBASE.dll
Module loaded, UxTheme.dll
Module loaded, dwmapi.dll
In OpenFileW, reading C:\Windows\Fonts\staticcache.dat
In OpenFileW, reading C:\Users\310222344\Downloads\winafl-master\build64\Debug\templates\fuzz2222222-moe69skripnpti.html

after 1st iteration it does not close automatically

please suggest

i think it's difficult to choose a offset .it seems afl does not need offset, why winalf not use static instrumentation with compiler?

Hi, im trying to run WinAFL and I get this error:

C:\Users\fuzz\Desktop\winafl-master\winafl-master\bin32>afl-fuzz.exe -i in -o ou
t -D C:\Users\fuzz\Desktop\DynamoRIO-Windows-7.0.0-RC1\bin32\drrun.exe -t 20000
-- -fuzz_iterations 5000 -coverage_module "foxitreader.exe" -target_module "foxi
treader.exe" -target_offset 0x5d22a6 -nargs 2 -- "C:/Program Files (x86)/Foxit S
oftware/Foxit Reader/foxitreader.exe" @@
WinAFL 1.08 by [email protected]
Based on AFL 1.96b by [email protected]
[] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[] Deleting old session data...
[+] Output dir cleanup successful.
[] Scanning 'in'...
[+] No auto-generated dictionary tokens to reuse.
[] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...

[-] PROGRAM ABORT : CreateProcess failed, GLE=2.

     Location : create_target_process(), ..\afl-fuzz.c:2074

I get that it can't create the process i want to run, but not sure how to fix this.
Thanks.

P.S first time running WinAFL.
Update: still digging around and I think, speking under correction, it has to do with file system redirection? I'm using Windows 7 x64. If anybody could assist, I will be greatful. Thanks

I am getting the following error when I run the test cases. Kindly help to resolve it. DynamoRIO is version 6.2.0

afl-fuzz.exe -i ....\testcases\images\bmp -o ..\output -D C:\Users\Sanjeev\Documents\DynamoRIO\bin32 -t 20000+ -- -fuzz_iterations 100 -- test
_gdiplus.exe @@
WinAFL 1.09 by [email protected]
Based on AFL 2.43b by [email protected]
[] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[] Deleting old session data...
[+] Output dir cleanup successful.
[] Scanning '....\testcases\images\bmp'...
[+] No auto-generated dictionary tokens to reuse.
[] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...
[!] WARNING: Test case results in a timeout (skipping)

[-] PROGRAM ABORT : All test cases time out, giving up!
Location : perform_dry_run(), ..\afl-fuzz.c:2695

process 3272 is not running under DR 0 processes nudged

I am testing a DLL library by creating a wrapper around that DLL and basically calling functions on it. Everything looks working ok but execution speed is 0.38 exec/sec!! that's pretty bad. Is that normal or I am missing something. I am loading the DLL dynamically using LoadLibrary(), I know that slows the execution a bit but not the level of 0.38 exec/sec

Any ideas?

Hi,
first of all, thanks for this wonderful work!
I have an issue. Recently I managed to tear down my vmware workstation fuzzing a simple executable. every run under WinAFL increased GDI objects by 2 on my host. When I've tried to execute in a batch only fuzzed executable, I haven't noticed any increase.

Before I run the afl-fuzz I am able to run my target executable with drrun.exe. But no matter what I do with the timeout passed to afl-fuzz.exe, the test case always results in a hang. Any suggestions to check out?

i'm new here...
i met some difficulties when i want to test the programs like notepad ,chrome etc.
i still don't know how to do after google..
Error message:
ASSERT FAILURE:..\winafl.c:545: false (error connecting to pipe)
Any suggestions to solve this problem? thanks！

So i've re-encounterd a crashing testcase and the same thing is happening; winafl does not detect the event. The 'crashes' directory is empty and the output it was mutating doesn't look like the last few paths. Also .cur_input does not cause a crash

output:

WinAFL

0 processes nudged
ERROR: The process "5997840" not found.

[-] PROGRAM ABORT : Cannot kill child process

     Location : destroy_target_process(), ..\afl-fuzz.c:2127

Windbg:

User mode DEP access violations are exploitable.

I did remember to take a minidump, but now i'll have to sift through the memory or fuzz the originating testcase again to find the crashing input.

Is there anything i might be doing wrong or is there something i can do to work around this?

Admittedly, I'm a noob at building software on Windoze with cMake so this may be PEBCAK. When I followed the README instructions for compiling WinAFL, I got the following linker errors. I was trying to build for 32 bit arch using the VS x86 Native Tools Command Prompt. VS 14.0 on Windows 10. Am I missing something?

Thanks!

Project "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\ALL_BUILD.vcxproj" (1) is building "C:\User
s\cynicxer\Desktop\winafl-master\winafl-master\build32\test_gdiplus.vcxproj" (5) on node 1 (default targets).
PrepareForBuild:
  Creating directory "test_gdiplus.dir\Release\".
  Creating directory "test_gdiplus.dir\Release\test_gdiplus.tlog\".
InitializeBuildStatus:
  Creating "test_gdiplus.dir\Release\test_gdiplus.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
CustomBuild:
  Building Custom Rule C:/Users/cynicxer/Desktop/winafl-master/winafl-master/CMakeLists.txt
  CMake does not need to re-run because C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\CMakeFiles\g
  enerate.stamp is up-to-date.
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /I"C:\Users\cynicxer\Desktop\DynamoRIO-Wind
  ows-6.2.0-2\cmake\..\include" /I"C:\Users\cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\cmake\..\ext\include" /nolo
  go /W1 /WX- /O2 /Oy- /D "CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Z
  c:inline /Fo"test_gdiplus.dir\Release\\" /Fd"test_gdiplus.dir\Release\vc140.pdb" /Gd /TP /analyze- /errorReport:
  queue "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\gdiplus.cpp"
  gdiplus.cpp
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\cynicxer\D
  esktop\winafl-master\winafl-master\build32\Release\test_gdiplus.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32
  .lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib gdiplus.lib /M
  ANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:"C:/Users/cynicxer/Desktop/winafl
  -master/winafl-master/build32/Release/test_gdiplus.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPL
  IB:"C:/Users/cynicxer/Desktop/winafl-master/winafl-master/build32/Release/test_gdiplus.lib" /MACHINE:X86 /SAFESE
  H  /machine:X86 test_gdiplus.dir\Release\gdiplus.obj
  test_gdiplus.vcxproj -> C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\Release\test_gdiplus.exe
FinalizeBuildStatus:
  Deleting file "test_gdiplus.dir\Release\test_gdiplus.tlog\unsuccessfulbuild".
  Touching "test_gdiplus.dir\Release\test_gdiplus.tlog\test_gdiplus.lastbuildstate".
Done Building Project "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\test_gdiplus.vcxproj" (defaul
t targets).

Project "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\ALL_BUILD.vcxproj" (1) is building "C:\User
s\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj" (6) on node 1 (default targets).
PrepareForBuild:
  Creating directory "winafl.dir\Release\".
  Creating directory "winafl.dir\Release\winafl.tlog\".
InitializeBuildStatus:
  Creating "winafl.dir\Release\winafl.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
CustomBuild:
  Building Custom Rule C:/Users/cynicxer/Desktop/winafl-master/winafl-master/CMakeLists.txt
  CMake does not need to re-run because C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\CMakeFiles\g
  enerate.stamp is up-to-date.
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /I"C:\Users\cynicxer\Desktop\DynamoRIO-Wind
  ows-6.2.0-2\cmake\..\include" /I"C:\Users\cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\cmake\..\ext\include" /Zi /
  nologo /W3 /WX- /O2 /Ob1 /Oy- /D WIN32 /D _WINDOWS /D NDEBUG /D X86_32 /D WINDOWS /D "CMAKE_INTDIR=\"Release\""
  /D winafl_EXPORTS /D _WINDLL /D _MBCS /Gm- /MT /GS- /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"winafl.d
  ir\Release\\" /Fd"winafl.dir\Release\vc140.pdb" /Gd /TC /analyze- /errorReport:queue "C:\Users\cynicxer\Desktop\
  winafl-master\winafl-master\winafl.c" "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\modules.c"
  winafl.c
  modules.c
  Generating Code...
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\cynicxer\D
  esktop\winafl-master\winafl-master\build32\Release\winafl.dll" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib g
  di32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib libcmt.lib "C:\Users
  \cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\ext\lib32\release\drx.lib" "C:\Users\cynicxer\Desktop\DynamoRIO-Wind
  ows-6.2.0-2\ext\lib32\release\drcontainers.lib" "C:\Users\cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\ext\lib32\r
  elease\drreg.lib" "C:\Users\cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\ext\lib32\release\drwrap.lib" "C:\Users\c
  ynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\lib32\ntdll_imports.lib" "C:\Users\cynicxer\Desktop\DynamoRIO-Windows-
  6.2.0-2\ext\lib32\release\drmgr.lib" "C:\Users\cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\ext\lib32\release\drco
  ntainers.lib" "C:\Users\cynicxer\Desktop\DynamoRIO-Windows-6.2.0-2\lib32\release\dynamorio.lib" /MANIFEST /MANIF
  ESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:"C:/Users/cynicxer/Desktop/winafl-master/winafl
  -master/build32/Release/winafl.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Users/cynicxe
  r/Desktop/winafl-master/winafl-master/build32/Release/winafl.lib" /MACHINE:X86 /SAFESEH  /machine:X86 /nodefault
  lib /DLL winafl.dir\Release\winafl.obj
  winafl.dir\Release\modules.obj
     Creating library C:/Users/cynicxer/Desktop/winafl-master/winafl-master/build32/Release/winafl.lib and object
  C:/Users/cynicxer/Desktop/winafl-master/winafl-master/build32/Release/winafl.exp
libcmt.lib(dll_dllmain.obj) : error LNK2019: unresolved external symbol __initterm referenced in function "int __c
decl dllmain_crt_process_attach(struct HINSTANCE__ * const,void * const)" (?dllmain_crt_process_attach@@YAHQAUHINS
TANCE__@@QAX@Z) [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(dll_dllmain.obj) : error LNK2019: unresolved external symbol __initterm_e referenced in function "int _
_cdecl dllmain_crt_process_attach(struct HINSTANCE__ * const,void * const)" (?dllmain_crt_process_attach@@YAHQAUHI
NSTANCE__@@QAX@Z) [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(dll_dllmain.obj) : error LNK2001: unresolved external symbol __except_handler4 [C:\Users\cynicxer\Deskt
op\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2001: unresolved external symbol __except_handler4 [C:\Users\cynicxer\Desktop\w
inafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(_sehprolg4_.obj) : error LNK2001: unresolved external symbol __except_handler4 [C:\Users\cynicxer\Deskt
op\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __seh_filter_dll referenced in function ___scr
t_dllmain_exception_filter [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __configure_narrow_argv referenced in function
 "public: static int __cdecl __scrt_narrow_argv_policy::configure_argv(void)" (?configure_argv@__scrt_narrow_argv_
policy@@SAHXZ) [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __initialize_narrow_environment referenced in
function ___scrt_dllmain_after_initialize_c [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.
vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __initialize_onexit_table referenced in functi
on ___scrt_initialize_onexit_tables [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __register_onexit_function referenced in funct
ion __onexit [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __execute_onexit_table referenced in function
___scrt_dllmain_uninitialize_c [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_atexit referenced in function __onexit [
C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_at_quick_exit referenced in function _at
_quick_exit [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __cexit referenced in function ___scrt_dllmain
_uninitialize_c [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(tncleanup.obj) : error LNK2019: unresolved external symbol ___std_type_info_destroy_list referenced in
function "void __cdecl __scrt_uninitialize_type_info(void)" (?__scrt_uninitialize_type_info@@YAXXZ) [C:\Users\cyni
cxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
libcmt.lib(utility_desktop.obj) : error LNK2019: unresolved external symbol _terminate referenced in function ___s
crt_unhandled_exception_filter@4 [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\Release\winafl.dll : fatal error LNK1120: 14 unresol
ved externals [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
Done Building Project "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj" (default targ
ets) -- FAILED.

Done Building Project "C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\ALL_BUILD.vcxproj" (default t
argets) -- FAILED.


Build FAILED.

"C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj" (default target) (6) ->
(Link target) ->
  libcmt.lib(dll_dllmain.obj) : error LNK2019: unresolved external symbol __initterm referenced in function "int _
_cdecl dllmain_crt_process_attach(struct HINSTANCE__ * const,void * const)" (?dllmain_crt_process_attach@@YAHQAUHI
NSTANCE__@@QAX@Z) [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(dll_dllmain.obj) : error LNK2019: unresolved external symbol __initterm_e referenced in function "int
 __cdecl dllmain_crt_process_attach(struct HINSTANCE__ * const,void * const)" (?dllmain_crt_process_attach@@YAHQAU
HINSTANCE__@@QAX@Z) [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(dll_dllmain.obj) : error LNK2001: unresolved external symbol __except_handler4 [C:\Users\cynicxer\Des
ktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2001: unresolved external symbol __except_handler4 [C:\Users\cynicxer\Desktop
\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(_sehprolg4_.obj) : error LNK2001: unresolved external symbol __except_handler4 [C:\Users\cynicxer\Des
ktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __seh_filter_dll referenced in function ___s
crt_dllmain_exception_filter [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __configure_narrow_argv referenced in functi
on "public: static int __cdecl __scrt_narrow_argv_policy::configure_argv(void)" (?configure_argv@__scrt_narrow_arg
v_policy@@SAHXZ) [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __initialize_narrow_environment referenced i
n function ___scrt_dllmain_after_initialize_c [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winaf
l.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __initialize_onexit_table referenced in func
tion ___scrt_initialize_onexit_tables [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxpro
j]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __register_onexit_function referenced in fun
ction __onexit [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __execute_onexit_table referenced in functio
n ___scrt_dllmain_uninitialize_c [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_atexit referenced in function __onexit
 [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_at_quick_exit referenced in function _
at_quick_exit [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility.obj) : error LNK2019: unresolved external symbol __cexit referenced in function ___scrt_dllma
in_uninitialize_c [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(tncleanup.obj) : error LNK2019: unresolved external symbol ___std_type_info_destroy_list referenced i
n function "void __cdecl __scrt_uninitialize_type_info(void)" (?__scrt_uninitialize_type_info@@YAXXZ) [C:\Users\cy
nicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  libcmt.lib(utility_desktop.obj) : error LNK2019: unresolved external symbol _terminate referenced in function __
_scrt_unhandled_exception_filter@4 [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]
  C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\Release\winafl.dll : fatal error LNK1120: 14 unres
olved externals [C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32\winafl.vcxproj]

    0 Warning(s)
    17 Error(s)

Time Elapsed 00:00:08.00

C:\Users\cynicxer\Desktop\winafl-master\winafl-master\build32>

https://github.com/ivanfratric/winafl/blob/master/winafl.c#L175

It seems that exception 0xC0000094 (division-by-zero) is ignored by winafl which will cause hangs and a window will be prompted by WerFault.exe.

Will we consider handle this exception?

Thanks.

Hello :)
It's a question when winafl is used to fuzz about the following parameter:
-target_offset - offset of the method to fuzz from the start of the module.

It confused me in the following situations:

1. It could refer to the offset to the module in the executive file.
2. It could refer to the offset to the module in the running process memory.
   In those situations target_offset could be different. By reading the source code, I think it might be the 2nd one. But I'm not sure, is that correct?And it might be related to the implementation of DynamoRIO?

Thanks very much!

Hi, I am fuzzing this soft called VUPlayer. This software requires the file extension to be m3u to work. So I am trying to change the input file name to xxx.m3u otherwise the input file name will be .cur_input and no crash will be made even using a poc input. I am using the following command to achieve this purpose but it seems I failed since it keeps telling me 1 process nudged and Succeeded terminating process with PID xxxx. Am I using the -f option in a bad way?

C:\Program Files (x86)\VUPlayer> afl-fuzz.exe -i in -o out -f test.m3u -D C:\Users\Administrator\Desktop\DynamoRIO-Windows-6.2.0-2\bin32 -t 20000 -- -fuzz_iterations 5000 -coverage_module VUPlayer.exe -target_module VUPlayer.exe -target_offset 0x532a0 -nargs 2 -- UPlayer.exe @@

I have a question about the target_offset for functions other than main.
I wrote a little program which should test myDll.dll

`void fuzz(int argc, char *argv[])
{
FuncWithParams paramFunc;
paramFunc = (FuncWithParams)GetProcAddress(hDLL, "process");
int result = paramFunc(argc, argv);
}

int main(int argc, char *argv[])
{
hDLL = LoadLibrary("myDll.dll");
fuzz(argc, argv);
FreeLibrary(hDLL);
return 0;
}`

In WinDbg I'm getting the target_offset as follow:

ModLoad: 00da0000 00da9000 test.exe

with x test!main = 00da1060 -> offset is 0x1060
with x test!fuzz = 00da1020 -> offset is 0x1020

When I try to run winafl with target_offset 0x1060 (main) everything works fine but it's very slow (because LoadLibrary is called every time) !
When I try to run winafl with target_offset 0x1020 (fuzz) I'm getting an error that the initial testcase caused a hang -> drun -debug log says: Target function was never called. Incorrect target_offset?

What I'm doing wrong ?

Hello ivanfratric

So I'm just starting out working with winafl, and I wanted to test it out on a simple binary (which has obvious segmentation faults) just so I can understand the process.

While testing winafl on the following simple target:

 #include "stdafx.h"
 int copy_content_from_xml (const char* filename, char* content);

 int main(int argc, char ** argv)
 {
    char *p_args_file; /* String representing XML configuration files */
    char buffer1[2] = {0};
    char buffer2[2] = {0};
    int output = 0;
    if(argc > 1)
    {
        p_args_file = argv[1];
    }
    else
    {
        return 0;
    }

    copy_content_from_xml(p_args_file, buffer1);

    if(buffer1[0] > 98)
    {
        buffer1[2] = 'a';  // Writing out of bound - buffer overflow
        output = buffer2[0];
    }

     if(buffer1[0] < 120)
    {
        output = buffer1[3];  // Reading out of access bound
        buffer1[0] = 'x';  // Writing out of bound - buffer overflow

    }


    return output;
}

int
copy_content_from_xml (const char* filename, char* content) {
    /* Allocate memory for context */
     FILE *fp; /* the XML file */
     int i;
     /* Open file */
     fp =  fopen(filename, "r");
     if (fp == NULL) 
    {
        //fprintf(stderr, "Error: Failed to open '%s'!\n", filename);
        return 0;
    }
   fgets(content, 2, fp);
   fclose(fp);
}

The following window always pops-up, everytime a process is being run, which significantly reduces the execution speed.

Is winafl supposed to generate a pop-up window everytime it discovers a hang? That seems inefficient.

I am learning DynamoRIO along with winafl usage so my debugging skills in the DR environment are still lame, I apologize for not having a solid proof of what I am asking.

In the function instrument_edge_coverage

You have the following code but there is no instrlist_meta_preinsert call afterwards like in the other instructions, is this how it's supposed to be? Are we not updating the previous_offset at the end?

//store the new value
offset = (offset >> 1)&(MAP_SIZE - 1);
opnd1 = OPND_CREATE_ABSMEM(&(winafl_data.previous_offset), OPSZ_4);
opnd2 = OPND_CREATE_INT32(offset);
INSTR_CREATE_mov_st(drcontext, opnd1, opnd2);

afl-fuzz appears to be stripping quotes out of the module arguments. This makes it impossible to test modules located in file paths that contain spaces. For instance:

C:\Users\akirilov\Desktop\test3>afl-fuzz.exe -i "inputs_small" -o "outputs" -D "C:\DynamoRIO-Windows-6.1.1-3\bin64" -t 20000 -- -coverage_module (redacted) -coverage_module (redacted) -coverage_module (redacted) -fuzz_iterations 20000 -target_module (redacted) -target_offset 0x11AC -nargs 2 -- "C:\Program Files\(redacted)" @@
WinAFL 1.01 by <[email protected]>
Based on AFL 1.96b by <[email protected]>
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'inputs_small'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...
ERROR: Failed to create process for "C:\Program": The system cannot find the file specified.

Hello ivanfratric

How would one go about changing the memory limit of the WinAFL tool.

Would changing the memory limit in config.h work?

/* Default memory limit for child process (MB): */
55  
56  #ifndef __x86_64__ 
57  #  define MEM_LIMIT         25
58  #else
59  #  define MEM_LIMIT         50
60  #endif /* ^!__x86_64__ */

My particular folder structure had 3 layers of folders since I unzipped the DynamoRIO stuff into a folder outside of the project and it failed to find the DynamoRIO files. When I used the full path, it was able to compile.

hey all,
I'm trying to use the winafl-cmin.py file for corpus distillation but I'm having troubles running it.
Here's the command I tried and the result:

python winafl-cmin.py -i "C:\Users\john\Desktop\results\seed_files" -o "C:\Users\john\Desktop\results\syncdir" -coverage_module shimgvw.dll -target_module PhotoViewerLoader.exe -nargs 2 -D "C:\users\john\Desktop\DynamoRIO-Windows-6.2.0-2\bin32\" -target_offset 0x1040 -t 10000 -- PhotoViewerLoader.exe @@

corpus minimization tool for WinAFL by <[email protected]> Based on WinAFL by <[email protected]> Based on AFL by <[email protected]> usage: winafl-cmin.py [-h] -i dir -o dir [-n] [--working-dir dir] [-v] [-covtype {edge,bb}] [-call_convention {stdcall,fastcall,thiscall,ms64}] -coverage_module module -target_module module -nargs nargs -D dir (-target_method method | -target_offset rva offset) [-t msec] [-f file] [-C] [-e] [-w n] ...
winafl-cmin.py: error: one of the arguments -target_method -target_offset is required

Running WinAFL with the -target_offset is working fine so I can't really tell what I'm missing here. Any help would be appreciated!
Thanks,
doria90

Hi, ivan,
When I fuzzed the iamgemagick convert with using the command
afl-fuzz -i input_dir -o output_dir -D path/to/Dynamorio/bin32 -t 20000 -- coverage_module convert.exe -fuzz_iterations 5000 -target_module convert.exe -target_offset 0xa291e -nargs 3 -- convert.exe @@ out.ipg
I got an error that
PROGRAM ABORT: test case result in a hang when perform_dry_run().

0xa291e is the export entry of main() function, I got it from IDA pro.

I wonder whether the command is correct or not? When I typed the command convert a.png a.jpg in the console, I got the correct result. So I need your help.

Hi, just took this project out for a spin, but following your instructions I get the following output from the test.exe you provide as example.

[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning '..\..\testcases\others\text'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Attempting dry run with 'id_000000'...

[-] PROGRAM ABORT : No instrumentation detected
         Location : perform_dry_run(), C:\Users\rodrigoa\Desktop\kcode\winafl\afl-fuzz.c:2526

I also get a DR_ASSERT_MSG with the error

unrecognized command received over pipe

The command value is 0x0.

The program runs just fine if I execute

%drpath%\drrun.exe -c %waflpath%\winafl.dll -debug -target_module test.exe -target_offset 0x1010 -fuzz_iterations 10 -nargs 2 -- test.exe ..\..\testcases\others\text\hello_world.txt

The command line I am using is

afl-fuzz -i ..\..\testcases\others\text -o out -D %drpath% -t 2000 -- -fuzz_iterations 10 -target_module test.exe -target_offset 0x1010 -nargs 2 -- test.exe @@

I am using 64 bit binaries for everything and DynamoRIO version 6.1.1-3

Hi @ivanfratric!

I'm using WinAFL to fuzz some small apps and I was wondering if I should enable PageHeap during the fuzzing campaign. I would say yes, but maybe it could lead to some bugs with DynamoRIO or it slows down the executions per second. Do you have any advice?

Thanks!

i have a method , which is basically a constructor. whenever i provide target_method with method name it pops error saying cant find specific module in fuzz_method.
i also have the debug symbols located in same directory of binary.
please help me out in writing proper syntax for executing code

Hello ,I can use winafl to fuzz execution in cmd, and I try to fuzz execution with GUI,but it can't work.
Is it possible to fuzz execution with GUI ? just like some media player(VUPlayer,RealPlayer,and etc.), Document reader( adobe reader, office and etc.), Photo viewer(ACDsee and etc.),and Could you give me some advice how to use winal to fuzz them?
Thank u very much

The current version of afl-fuzz.exe did not support the -S parameter in master-slave mode. The patch can be found at ivanfratric@d22dff7. Could you please recompile the source code and update the binary file?

Hi Ivan,
I am testing your fuzzing tool, i am not sure if I am doing it correctly, but I have tried on Windows XP and Windows 7 both 32 bits, when I start testing it using the drrun.exe or alf_fuzz.exe they seems to hang and it is not getting released, I left it running for hours, please see the screenshot below, I enabled -debug, but I don't see anything wrong.
Another question, Windows XP is supported ?
Please Advise.

I'm getting the above warning in my output and failing to fuzz, but my offset is correct.

OS: Windows Server 2012 R2 (x64)
WinAFL: Current master
DynamoRIO: 6.1.1-3

Command line: "E:\temp\WinAFL\DynamoRIO-Windows-6.1.1-3\bin64\drrun.exe" -c "E:\temp\WinAFL\winafl-master\bin64\winafl.dll" -debug -target_module "E:\temp\WinAFL\winafl-master\bin64\test_gdiplus.exe" -target_offset 0x1270 -fuzz_iterations 10 -nargs 2 -- "E:\temp\WinAFL\winafl-master\bin64\test_gdiplus.exe" "E:\temp\WinAFL\winafl-master\testcases\images\bmp\not_kitty.bmp"

WinDBG:

0:000> x test_gdiplus!main
00007ff6`92411270 test_gdiplus!main (<no parameter info>)
0:000> u test_gdiplus!main
test_gdiplus!main:
00007ff6`92411270 4053            push    rbx
00007ff6`92411272 4883ec40        sub     rsp,40h
00007ff6`92411276 488bda          mov     rbx,rdx
00007ff6`92411279 83f902          cmp     ecx,2
00007ff6`9241127c 7d18            jge     test_gdiplus!main+0x26 (00007ff6`92411296)
00007ff6`9241127e 488b12          mov     rdx,qword ptr [rdx]
00007ff6`92411281 488d0d28350000  lea     rcx,[test_gdiplus!`string' (00007ff6`924147b0)]
00007ff6`92411288 ff1502710000    call    qword ptr [test_gdiplus!_imp_printf (00007ff6`92418390)]
0:000> !peb
PEB at 00007ff6915d4000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            Yes
    ImageBaseAddress:         00007ff692410000
    Ldr                       00007ffd804f1320
    Ldr.Initialized:          Yes
    Ldr.InInitializationOrderModuleList: 0000000000792d90 . 00000000007934a0
    Ldr.InLoadOrderModuleList:           0000000000792f40 . 00000000007971d0
    Ldr.InMemoryOrderModuleList:         0000000000792f50 . 00000000007971e0
                    Base TimeStamp                     Module
            7ff692410000 57769e0b Jul 01 09:44:59 2016 E:\temp\WinAFL\winafl-master\bin64\test_gdiplus.exe
...

0x00007ff692411270 - 0x00007ff692410000 = 0x1270

Not sure what else could be causing the issue?

Hey all,
I could appreciate your help.
I wrote a wrapper which uses PhotoViewer.dll to load and draw images using Windows Photo Viewer and Windows Imaging Component.
Everything works great (really slow, as each image gets opened and closed using a another program which catches the Photo Viewer window and closes it, but I cant see any other solution) and I'm getting unique crashes and hangs.
Here's the commandline:
"C:\Users\john\Desktop\winafl-master\build32\Debug\afl-fuzz.exe" -m 2000 -i "C:\Users\john\Desktop\results\images" -o "C:\Users\john\Desktop\results\syncdir" -M fuzzer01 -D "C:\Users\john\Desktop\DynamoRIO-Windows-6.2.0-2\bin32" -t 20000 -- -coverage_module WindowsCodecs.dll -fuzz_iterations 100 -target_module PhotoViewerLoader.exe -target_offset 0x1040 -nargs 2 -- PhotoViewerLoader.exe @@

When examining these crashes, I get the same exception which probably leads to nowhere. I'm having trouble understanding what I'm missing.

When I open the files in the crash folder, Windows Photo Viewer does not crash but writes that the file is corrupt.
Any ideas? I welcome them all! critics as well :)

Thanks,
doria90

So I've made some drastic changes to the program I was struggling with before and I've gotten runs down to a fraction of a second. However, now I'm having issues with my dry runs since I have a huge folder of templates.

Is there any way to shorten the dry run? And is there any way to reuse dry run results over the same templates in future runs? (For instance, to speed up a distributed fuzzing system)?

Hi Ivan,

Do you know what could be the issue that I am running the Fuzzer for 9 hours and no new paths are getting discovered, I also have WinAFL running on another application and the behaviour is the same.
Please Advise.

            WinAFL 1.03 based on AFL 1.96b 

+- process timing -------------------------------------+- overall results ----+
| run time : 0 days, 9 hrs, 30 min, 22 sec | cycles done : 35.0k |
| last new path : none yet (odd, check syntax!) | total paths : 1 |
| last uniq crash : none seen yet | uniq crashes : 0 |
| last uniq hang : none seen yet | uniq hangs : 0 |
+- cycle progress --------------------+- map coverage -+----------------------+
| now processing : 0 (0.00%) | map density : 37 (0.06%) |
| paths timed out : 0 (0.00%) | count coverage : 1.00 bits/tuple |
+- stage progress --------------------+ findings in depth --------------------+
| now trying : havoc | favored paths : 1 (100.00%) |
| stage execs : 495/500 (99.00%) | new edges on : 1 (100.00%) |
| total execs : 17.5M | total crashes : 0 (0 unique) |
| exec speed : 990.0/sec | total hangs : 0 (0 unique) |
+- fuzzing strategy yields -----------+---------------+- path geometry -------+
| bit flips : 0/32, 0/31, 0/29 | levels : 1 |
| byte flips : 0/4, 0/3, 0/1 | pending : 0 |
| arithmetics : 0/224, 0/0, 0/0 | pend fav : 0 |
| known ints : 0/24, 0/101, 0/40 | own finds : 0 |
| dictionary : 0/0, 0/0, 0/0 | imported : n/a |
| havoc : 0/17.5M, 0/0 | variable : 0 |
| trim : 97.80%/13, 0.00% +-----------------------+
[] Entering queue cycle 35014.-----------------------+
[] Fuzzing test case #0 (1 total)...

Creating an issue to keep track of log files. Conversation started here:
https://groups.google.com/forum/#!topic/dynamorio-users/RXXRxYa08QQ

for the original AFL on linux, the fork server make it more efficient. but for windows, it seems that there is difficult to write a function working as fork(). is there any alternative solution to do some work similar to fork() on windows?

I am getting the following crash on running the winafl.

<Application C:\Users\in3o\Documents\FuzzSample\Release\FuzzSample.exe (15208). WinAFL internal crash at PC 0x70f5cffb. Please report this at . Program aborted. 0xc0000005 0x00000000 0x70f5cffb 0x70f5cffb 0x00000003 0x00000000 Base: 0x70e90000 Registers: eax=0x00000000 ebx=0x012ff288 ecx=0xd27a70b4 edx=0x00000000 esi=0x2222e330 edi=0x2222e324 esp=0x012ff2a8 ebp=0x012ff358 eflags=0x0001020 version 6.2.17367, custom build -no_dynamic_options -client_lib 'C:\Users\in3o\Desktop\acrobat\winafl\bin32\winafl.dll;0;"-debug" "-target_module" "C:\Users\in3o\Documents\FuzzSample\Release\FuzzSample.exe" "-target_method" "Fuzz" "-coverage_module" "vulnerable.dll" "-fuzz_iterations" "10000"' -code_api -probe_api -stack_size 56K -max_elide_jmp 0 -max_ 0x012ff358 0x70f376f4 0x012ff384 0x70f37591 0x012ff890 0x70f372db 0x012ff8d0 0x70ec095d 0x012ff8f8 0x70f30f2c 0x012ff918 0x70f5c8c8>

I am running the fuzzer with following command line.

C:\Users\in3o\Desktop\acrobat\dynamorio\build\bin32\drrun.exe -c winafl.dll -debug -target_module C:\Users\in3o\Documents\FuzzSample\Release\FuzzSample.exe -target_method Fuzz -coverage_module vulnerable.dll -fuzz_iterations 10000 -- "C:\Users\in3o\Documents\FuzzSample\Release\FuzzSample.exe" in\sample.txt