BFF does not capture the crash about certfuzz

[wdormann]

Does running ./tools/repro.py <crasherfile> reproduce the crash?

[jplopezy]

Thanks for reply

Yes and i see the command line of cdb, looks fine, but when run bff crash outside

eax=16f0bc20 ebx=77bd5920 ecx=00000001 edx=00000021 esi=00000002 edi=1ba24d80
eip=77b99a8a esp=16f0bbfc ebp=16f0bc8c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll_77ac0000!RtlIsNonEmptyDirectoryReparsePointAllowed+0xaa:
77b99a8a eb33 jmp ntdll_77ac0000!RtlIsNonEmptyDirectoryReparsePointAllowed+0xdf (77b99abf)

[wdormann]

I can't make sense out of this bug report. If you can clearly convey how this is a BFF bug, feel free to open this ticket.

[jplopezy]

Sorry if I was not clear.

Basically what I want to say is that I have an application and a file that is vulnerable to it.

I confirm this with windbg and other debuggers.

What happens is that trying to fuzz with BFF I see that it does not find faults.

What I do to confirm if oka is working is to change the config (bff.yaml) to verify.

And what happens is that instead of the cdb.exe of the bff capturing the crash, the windbg runs outside.

It is as if the bff executes an "os.system" with the application alone and not with the cdb.

When I run the repro.py I see that the cdb is executed.

That is the difference, I repeat never before had this happened to me with the bff, I do not understand why it has this behavior

[jplopezy]

[wdormann]

The first invocation of a fuzzing campaign doesn't use a debugger. It does this for target app caching purposes, as well as allowing the user to see that it's launching the target app as expected.
In a "verify" run, where the seed files are all crashers, then yeah, it may be a little confusing.
If you let BFF continue, does it categorize the crashes? The screenshot you provided is what you'll see before the campaign starts.

[jplopezy]

Is that that's the weird thing?

I execute it with several files but the others capture them either.

It catches my attention because it started happening to me recently, maybe the application incorporates some mechanism.

I have dep and asrl deactivated :(

[jplopezy]

You know something that you notice is very strange adding the debug "-d"

DEBUG certfuzz.file_handlers.tmp_reaper - Failed to delete

As the process is taking the tmp and can not eliminate it, maybe that influences.

Is there a way to change the tmp by default ?.

[jplopezy]

already modified the tmp and it remains the same .. how strange, consult the repro.py how should I end up facing a crash?

Currently only gives me access violation, is that okay? or does it also generate the folder with the testcase and execute the exploitable?

[jplopezy]

In the end you can solve the problem.

For some reason by default under vcredist_x86 2013 and it is not compatible.

I worked with the 2010 version

regards