search

OpenRCE / sulley

A pure-python fully automated and unattended fuzzing framework.
GNU General Public License v2.0
1.42k stars 338 forks source link

[Google] process_monitor failing to handle access violation following a C++ exception #2

Open Fitblip opened 12 years ago

Fitblip commented 12 years ago

From Matt Watchinski:

For the life of me I can't get process_monitor to generate a crashbin or log test cases that caused a crash, even though the applications blows up.

Seems the applications throws exception code e06d7363, process_monitor sees "first chance", then it skips it. The app then NULL ptr dereferences and dies. Under WinDbg this causes a second chance exception and everything works as expected. PyDBg just says "thread exiting" and then Sulley restarts the app and moves on to the next fuzz case.

When I added something other than None to the _log lamda on pydbg I can see pydbg sees the C++ exceptions, says it's unhandled, says it's first chance and then pydbg bails the thread.

scottjpack commented 12 years ago

I'm having a very similar problem, when running a Visual C++ app, it runs into a violation error, reports the first one, and then when further problems cause the program to crash the debugger shows "thread exiting" and then restarts the app and moves along. Matt, were you ever able to resolve this, or hook Sulley up with a different debugger?

Fitblip commented 12 years ago

Can you send me a copy of the app? Or an app that will do this? I may be able to look into it, but I don't have any apps that I can't debug...

Email is in my profile.

Fitblip commented 12 years ago

Alright, I'm fairly certain this has to pertain to C++ using vtable lookups (which aren't statically resolvable). Since we're going to be moving from PyDBG -> VDB, this should be taken care of automatically. That's one of my next goals for Sulley (along with centralized logging), that way we can start doing things like crashing ARM-based programs (think iPhone) as well! :)