📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

 Forums >>  Debuggers  >>  Fuzzing with pyDBG

Topic created on: August 22, 2007 09:51 CDT by andy .

Hi all.. I am writing a small fuzzer in python to test a server application.  I want to catch exceptions generated in the server app, so I load it with pydbg and set some callbacks through set_callback()

Many requests make the server raise 0xE06D7363 exceptions. According to my understanding, these are the exceptions generated though the "throw" clause in C++ applications. Anyway, the server seems to catch these exceptions, as it keeps running ok.

The problem is that there are some requests that also cause this exception code, but the process ends. I think this is related to unhandled C++ exceptions. Is that rigth?

As I am trying to find vulns in the server app, I have to catch this situation. But if I do a pydbg.set_callback(0xE06D7363,...) it catches ALL exceptions, even the handled ones!

So what I did is to install a handler for the EXIT_PROCESS_DEBUG_EVENT, analyzing when the process is closed and report only the packets that cause that event...

Is this the best solution or somebody have a better and more elegant one?

  jms     August 22, 2007 11:20.45 CDT
Use the terminate_process() call from pydbg to kill the process.

So inside your crash handler, assuming dbg == pydbg():

dbg.terminate_process()

And then you can kill that child thread as well if you like so you don't have this massive thread counting happening either.

  andy   August 22, 2007 11:23.30 CDT
Thanks jms, I have just edited the post a few minutes before your reply because I found the termine_process method! Thank you anyway!

Any ideas regarding the updated topic?

  jms     August 22, 2007 11:23.50 CDT
Sorry and you could also use the:


dbg.debug_set_process_kill_on_exit(True)


The MSDN describes it a bit better, however I generally use an explicit terminate_process() call in a scenario like yours.

  jms     August 22, 2007 11:25.59 CDT
Inside of process_stalker you will see the following code:


# if the user wants to ignore first chance exceptions then do so.
        if self.ignore_first_chance and dbg.dbg.u.Exception.dwFirstChance:
            return DBG_EXCEPTION_NOT_HANDLED


That particular exception code is indeed the standard exception code from MS VC++. So try doing as the code snippet above does to let the first chance exceptions pass.



if dbg.dbg.u.Exception.dwFirstChance:
     return DBG_EXCEPTION_NOT_HANDLED


Note: Registration is required to post to the forums.

There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit