[Question] VEH / SEH Handlers

[DrakeFish]

Hi there. Since I want to start working on "semi-injected" work, I recently started working on different ways to inject my code in external processes using .NET, may it be with a DLL or without one. I started working on something pretty interesting, hooking thread using VEH/SEH (Vectored/Structured Exception Handlers). The idea of adding my own handler on top of the VEH structure seemed pretty interesting seeing how quick it is to just link/unlink your handler to the list and because this handler would be one of the firsts (if not the first) handlers called, resulting in a lot faster hooks.

However when doing my tests I realized that the application (WoW, in my test) is constantly overwriting the first VEH entry in the linked list with its own exception handler. I then tried to add it to the end of the list, but it seems like this made the exceptions never get to my handler.

By using SetUnhandledExceptionFilter WinAPI to add my handler the exception handler does get called, but from what I read the SEH entries are getting called later than VEH entries, which could be bad for performances.

I would like to get some comments on what you think may be the cause of the overwrite (does SEH bases on VEH structure to work?), and if it would be possible for me to add my exception handler to the top of the the list. Additionally, I would like to know if anyone knows how the SetUnhandledExceptionFilter WinAPI works internally, is it a different structure than the VEH or are those working together?

Tl;dr: Gief info on how to have my handler on top of the 'list' and explain how SEH works internally.

I will continue searching about this on the web, but I have to say the information about those are often limited on how to call it / use it in a simple ASM-coded program.

Thanks in advanced for any help / heads up!

[sitnspinlock]

just a quick overview i know you know this.

debugger (if attached) ->

veh ->

seh chain ->

filter

in order to put your own SEH handler at the top of the chain for the thread you simply need to add it to the first 4 bytes of the thread environment block (in x86) fs:[0x0], and then of course do not forget to link to the rest of the chain because wow uses some seh techniques to try and prevent the ol' trap n trace.

but I have not mentioned safe seh. this prevents you from throwing in your own custom seh handler because it's a pretty old attack method. Unless it resides in the exception table in the PE, you could manually add it but then you are looking at perhaps bypassing a checksum on the executable if any is even used, I don't know.

as for it overwriting the top level VEH I cant say I have seen this happen, try watching RtlAddVectoredExceptionHandler or the encoded pointers in the ntdll data segment.

also afaik cypher would be a good person to ask because I believe he tried or maybe already did implement safeseh in his manual map system, and my knowledge of user exception dispatching is a little foggy ;p

[DrakeFish]

everdox answered all the questions I needed to know about on here and over IM. Thanks

[Cypher]

It's almost impossible to guarantee that you can keep your position at the top of the VEH chain through 'conventional' methods.

Look at the return value of AddVectoredExceptionHandler. The documentation says it's a void*, but it's actually a pointer to an undocumented structure. Reverse-engineer NTDLL and you should be able to work out the best way to keep yourself at the top of the chain. It can get complicated depending how 'stealthy' you want to go with it too, but it's a fun project for sure. For example, how would you defend against someone simply grabbing the LdrpVectoredHandlerList (that name is from memory, check the NTDLL symbols for verification) directly from memory and injecting them-self into the top of the list without having to call RtlAddVectoredExceptionHandler? I haven't looked at that in a while, but from my vague memory all the potential holes can be plugged relatively securely.