Page History

...

On non-Windows platforms supported by BFF, the crash identifier is generated using an MD5 hash, so the faulting address isn't obvious based solely on the directory name.

Enabling the Debug Heap

The release version of BFF 2.8 disables the debug heap by default. The original motivation for this was to more closely represent the non-debugged execution of the target application. This appeared to make sense in the Windows XP days, as on that platform one could make a pretty reliable proof-of-concept exploit for a crash that involved the Windows heap. On modern Windows platforms, heap-related crashes can have a high amount of variability in the crash properties, even among seemingly-identical invocations of the target application. We can avoid these variations in heap-related crashes by enabling the following feature in bff.yaml:

debugger:
    debugheap: True

Combining These Options

When the above two three options are both used all used, BFF is put into a mode where it becomes more obvious which crashes have an EFA that is directly influenced by the bytes in the fuzzed file. By looking for EFA patterns that have 0x78 in them, you can find crashes where you may be able to influence the code being executed. For example:

...

Here are multiple crashes where the faulting address appear to be influenced by the 'x' bytes in our fuzzed file. Again, to put BFF into this mode, use the following two three options:

 runoptions:
    minimize: string
    keep_unique_faddr: True
 
debugger:
	debugheap: True

Assuming you have Cygwin installed on your Windows fuzzing VM, crashes that appear to have a controllable EFA can be found with these commands:

...

Jackpot! We've started with an UNKNOWN crash, and we now have a demonstrably EXPLOITABLE crash. All of this was made possible with the following two three BFF options use used together:

runoptions:
    minimize: string
    keep_unique_faddr: True
 
debugger:
	debugheap: True