Sup all,

Ive been poking around with SEH as of late and i came across an interesting question pertaining to SEH and debuggers.
Is there a way to successfully grab an exception before a debugger gets the notification of the exception? Meaning if your program is under a debugger can you in fact be able to get your handler to be called when an exception occurs before the debugger gets it? Im not too knowledgable on the inner workings on how a debugger handles exceptions( I do know that they have a very advanced exception handler to capture all ex ceptions) But what inner layer causes a debugger to be able to handle an exception before your application, i wanted to try and find a way to bypass this but had no direction.
Even if you place your exception handler as the first handler, still the debugger gets it, surely theres a way around this?

Well i guess a little googleing wouldnt have hurt, although i just wasnt sure what to search for, i got my answer right here on RCE!.
http://www.woodmann.com/forum/showthread.php?t=11934&highlight=exception+handling

http://www.debuginfo.com/articles/debugfilters.html

good to go.

That is why we have the BIG RED LETTERS at the top of the Forums.

Of course not everything can be found easily by searching, but it should always be a first step in trying to find what one needs.

Glad you solved your problem.

Regards,

Umm.. I thought even with a top level exception handler, the debugger still gets notified before the exception handler ("first chance" exception). Only if the debugger chooses to not handle the exception does it go to the exception handler, and if the exception handler chooses not to handle the exception, it goes back to the debugger again ("second chance" exception).

Yes, disavowed this is how it works afaik..the techniques mentioned in the links from what i can see go into the SetUnhandledExceptionFilter function because its what notifies that there is an exception that will need handling, and this is when some internal working set the debugport to true and pass it to the debugger. Im still working on it though.

Just a correction from what i said from wtbw, SetUnhandleExceptionFilter happens *after* all the good stuff happens, it notifies after there has been no previous handler to handle the exception, at which point debugport has already been set, and cannot be modified in runtime( thx j00ru)...

So this has to go deeper unfortunately into kernel space to try and stop the debugger from capturing your programs exceptions

There are only 7 events in which the user debugger delivered a message(DBGKM_APIMSG):
- Exceptions
- Creating threads
- Creating processes
- Terminating threads
- Terminating processes
- Map vief of sections
- Unmap view of sections
There are two ways around this.
1. There service NtRemoveProcessDebug, which remove the debug port and, most importantly, this service can be called debugging process.
- DebugObject = NtQueryInformationProcess(ProcessDebugObjectHandle)
- NtRemoveProcessDebug(DebugObject)
2. ThreadHiddenFromDebugger, (ERHREAD.CrossThreadFlags -> PS_CROSS_THREAD_FLAGS_HIDEFROMDBG).
- NtSetInformationThread(NtCurrentThread, ThreadHideFromDebugger)
3. For outside of tracer can be through services(reset trap flag TF):
- NtContinue
- NtSetContextThread
For kernel debug exception delivered in KiDispatchException(), by calling the callback could KiDebugRoutine, it is impossible to circumvent of usermode.

We wrote a small code: http://paste.org.ru/?k4olqo ("http://paste.org.ru/?k4olqo")

Whats the dump for?

To solve your problem:

Few corrected for W7: http://paste.org.ru/?k9lpcz
Is no other way to exist for usermode(remote code execution is not counted).