Fuzzer causes crash. Now what?

Question

Can anyone point me in the direction of some good tutorials regarding how to identify the type of vulnerability as reported by !exploitable and where to go from there?

Essentially I've got myself a small fuzzing lab setup and I'm trying to broaden my understanding of exploit research and development. So I've got an app that crashes, !exploitable reports as EXPLOITABLE and a Write Access Violation. My issue at this point is I'm not sure what kind of problem is happening, and how to proceed.

Lots of exploit tutorials out there, except they all demonstrate buffer overflows....I'm not sure this is a buffer overflow. Opening the fuzzed file that causes the crash in Immunity Debugger causes the same crash at the same memory address as the !exploitable report. I compared the clean file to the fuzzed file in a bindiffer application and can see the exact hexdecimal change that is causing the crash, but I could use some advice on how to proceed from here in order to start putting together exploit code. I've attached the !exploitable read out in the event someone can provide me some more insight on it and how to gather meaningful information from it.

(834.b7c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=7fffffff ebx=00726afc ecx=0000c9f0 edx=02adc080 esi=02957b18 edi=00000000
eip=005ec57f esp=0187f810 ebp=0187f978 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216
*** WARNING: Unable to verify timestamp for image00400000
*** ERROR: Module load completed but symbols could not be loaded for image00400000
image00400000+0x1ec57f:
005ec57f c704ca00000000  mov     dword ptr [edx+ecx*8],0 ds:0023:02b41000=????????
0:000> r;!exploitable -v;q
eax=7fffffff ebx=00726afc ecx=0000c9f0 edx=02adc080 esi=02957b18 edi=00000000
eip=005ec57f esp=0187f810 ebp=0187f978 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216
image00400000+0x1ec57f:
005ec57f c704ca00000000  mov     dword ptr [edx+ecx*8],0 ds:0023:02b41000=????????
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
Exception Faulting Address: 0x2b41000
First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005)
Exception Sub-Type: Write Access Violation

Exception Hash (Major/Minor): 0x00020e6f.0x435e5a76

Stack Trace:
image00400000+0x1ec57f
image00400000+0x1ebe05
image00400000+0x1eb966
image00400000+0x1eb7f3
image00400000+0x64405
image00400000+0x63eae
image00400000+0x63d2f
image00400000+0x41ca5
image00400000+0x39022
image00400000+0x5d9fa
image00400000+0x5e63f
image00400000+0x38862
image00400000+0x3032
image00400000+0x11d91
Instruction Address: 0x00000000005ec57f

Description: User Mode Write AV
Short Description: WriteAV
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at    
image00400000+0x00000000001ec57f (Hash=0x00020e6f.0x435e5a76)

User mode write access violations that are not near NULL are exploitable. 
quit:

Answer 1

Corelan has a couple of good articles on taking a fuzzing crash through to exploitation :

https://www.corelan.be/index.php/2013/02/26/root-cause-analysis-memory-corruption-vulnerabilities/ and https://www.corelan.be/index.php/2013/07/02/root-cause-analysis-integer-overflows/

Their methodology appears to be a case of looking at the original seed file that was used to generate the fuzzed message and slowly change it into the fuzzed message to identify which change(s) causes the crash.

Having done, that it is then a case of determining what the application does that causes it to crash by running it with an attached debugger and watching where your change influences the programs behaviour. With that you are then looking to see what registers you can take hold of (Ultimately trying to overwrite EIP). Or if it's a heap based crash, can you take overwrite some function pointers so that you could point them to your payload.