-
Notifications
You must be signed in to change notification settings - Fork 58
BFF does not capture the crash #30
Comments
Does running |
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 |
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. |
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 |
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. |
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 :( |
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 ?. |
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? |
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 |
Dear!
A problem is happening to me recently.
At first I thought it was my PC or the application I analyzed but something strange happens.
I could validate it with the option to verify the BFF.
I know that a file causes a crash in an application, before when I executed bff I captured it but at time it jumps the windbg or any postmorten debug but it does not capture the bff I do not know why.
I really do not know if it's my pc, I have windows 10 x64 and the process is x64 but I also try it with x32 always worked fine but at the time it's like the error is captured by the debuger and not by the bff.
I hope that someone knows the solution!
The text was updated successfully, but these errors were encountered: