Let's first establish what the crash means in this case and what type of crash it is. If there is nothing in the 'crashes' directory then how do you know the target is crashing and not just closing/hanging. In the output you provided I just see WinAFL was unable to kill the target process (not sure why that would happen, what would prevent it from being killed). In case it helps this is how WinAFL catches crashes:
https://github.com/ivanfratric/winafl/blob/master/winafl.c#L175
Note that any exception not on the list is considered non-security-relevant and will be passed to target process instead of being handled by WinAFL.
Also note that you always have the last sample saved as .cur_input in the output directory (unless you use the -f flag in which case the file is different).

from winafl.

The crash is a BEX, last time this happend it was quite repeatable before i lost my queue. WER reports multiple, with code 0xc000005. So i have no clue why EXCEPTION_ACCESS_VIOLATION was not triggered.

from winafl.

However it is weird that the current .cur_input does not cause a crash. Maybe it was caused by a previous state. But still, everytime i get DEP catching a buffer overflow, winafl gave me that message, even before i set a post-mortem debugger to make dumps.

from winafl.

Here it's happening again:

(1cff98.1d6a44): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=776c3c00 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=718ed835 esp=00f2fbd4 ebp=00000000 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
718ed835 54 push esp
0:002> !load winext\msec.dll
0:002> !exploitable

!exploitable 1.6.0.0
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x00000000718ed835 (Hash=0x1e2606b6.0x1e2606b6)

User mode DEP access violations are exploitable.

0:002> kv

ChildEBP RetAddr Args to Child

WARNING: Frame IP not in any known module. Following frames may be wrong.
00 00000000 00000000 00000000 00000000 00000000 0x718ed835

WinAFL:

--------SNIP-------
Extracting from ....\fuzz\unrar\o2.cur_input

• the file header is corrupt
  No files to extract
• the file header is corrupt

Extracting from ....\fuzz\unrar\o2.cur_input

• the file header is corrupt
  No files to extract
  0 processes nudged
  ERROR: The process "1889336" not found.

[-] PROGRAM ABORT : Cannot kill child process

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

from winafl.

Hmm, WinAFL should catch c0000005 (EXCEPTION_ACCESS_VIOLATION). And you're saying WinAFL gets stuck and is unable to kill the target process every time that happens. Do you perhaps have another piece of software (a debugger or something similar) that catches the exception before WinAFL gets the chance and then attaches to the process (which would explain why WinAFL would be unable to kill it). What do you see on the screen when that happens?

Could you try running WinAFL against test.exe (included with WinAFL)? It's a simple test binary which crashes when input is equal to "test". WinAFL should discover that input after fuzzing for a while and catch the crash.

from winafl.

Yes, the test.exe worked beautifully, it put away the testcase and kept on fuzzing.

About the exception being caught by another application, upon closer inspection that might be it.
I thought it wasn't because i only set WinDbg as post-mortem after this started happening, but when i went and deleted the regkey to unset it, it still contained a stray entry for VS16 as JIT debugger. Test.exe was not caught by either WinDbg or VS so that might be why it worked. So i'm resuming the queue i have now, I will report here if there's any new info.

Thanks!!

from winafl.