View Full Version : Help about such a strange SEH trick
kcynice
June 2nd, 2008, 22:45
there is the exception raised, but i don't know why the control will not go to the first handler in the SEH chain.
push -1
push 05A2C8D8 ;//I think this should be the exception handler
mov eax,dword ptr fs:[0]
push eax
mov dword ptr fs:[0],esp
sub esp 84h
push ebx
push esi
push edi
mov ebx,27h
mov eax,dword ptr[ebx] ;//here will get an exception
when the exception is raised, the control should goto 05A2C8D8, the first
exception handler, right? But it's strange that it goes to another address
instead! why?
[yAtEs]
June 3rd, 2008, 03:02
hard to say due to lack of information.
try researching about the LoadConfig directory.
ZaiRoN
June 3rd, 2008, 03:46
Can you tell more about the other address?
kcynice
June 3rd, 2008, 04:31
in fact, there almost no any details about the address.because I have not seen such an address was push to the stack or store in global area.
but, i want to know, why the control will go to another address but not the first entry in the SEH chain?
fr33ke
June 3rd, 2008, 05:37
I think it could be, in order of likelyness:
A debugger swallows the exception or does something weird
A Vectored Exception Handler swallows the exception or does something weird
Someone hooked something in the Windows internals and does something weird (maybe in the kernel in the IDT or at ntdll's KiUserExceptionDispatcher)
kcynice
June 3rd, 2008, 08:17
I am not sure which make it go like this. But,I have used two debugger to debug the same code,one is OllyDbg,the other is Syser(ring0 level debugger).When the exception is raised,syser doesn't allow me trace into the exception handling flow,but jump to the strange address(which was i mentioned) directly,no matter i set a breakpoint at the first handler in SEH chain. But for OllyDbg,the control will go to the first handler and do some code(the program may be coded by c++,it runs to msvcr71.__CxxFrameHandler). The result is most important,the program can run well under Syser,but will encounter a fatal error and terminate when this exception is raised!
naides
June 3rd, 2008, 08:23
Are you debugging a protection?
If that is the case, it smells to me that you are near the core of the protection and they are playing a dirty trick on you and your debugger to send you off course. . .
Try using windbg to follow this into Ring 0. I am not sure Syser has matured completely yet.
kcynice
June 3rd, 2008, 09:18
Yes, the protection of the program seems a little intelligent,right? I have not tried windbg before. I only know its a source code level debugger, so i thought its only used to debug some program with debug info.If it can trace the details of the exception, i will have a try.
blabberer
June 3rd, 2008, 11:49
check out if vectored handling exception is being used
iirce if there is veh and veh handled the exception
seh wont be called
veh iirc has a callout table and if al after veh is 1 i think rtlDispatchException() returns back to KiUserApcDispatcher () and back to ZwContinue
naides
June 3rd, 2008, 11:59
Quote:
[Originally Posted by kcynice;74938]I only know its a source code level debugger, so i thought its only used to debug some program with debug info. |
Not really, while not user friendly or reversing oriented like Olly and SoftIce, WinDBG will trace any program. Ricardo Narvaja did some work on reversing with windbg. Hopefully some of it may have been translated to English. I even remember some one was working on a GUI interface/menu driven front for it.
blabberer
June 3rd, 2008, 13:27
well i was googling to find corraboration to my statements above
that seh isnt called if veh is handling the exception
and i found matt_pietrek saying so
Quote:
The PEXCEPTION_POINTERS parameter is a pointer that gives the function everything it could want to know about the exception, including the exception type, address, and register values. The function is expected to return either EXCEPTION_CONTINUE_SEARCH or EXCEPTION_CONTINUE_EXECUTION.
When EXCEPTION_CONTINUE_EXECUTION is returned, the system attempts to restart execution of the process. Vectored exception handlers that appear later in the list won't be called, nor will any of the structured exception handlers. When the function returns EXCEPTION_CONTINUE_SEARCH, the system moves on to the next vectored exception handler. After all vectored exception handlers have been called, the system starts with the structured exception handling list.
In addition to the AddVectoredExceptionHandler API, there's also a RemoveVectoredExceptionHandler API, which removes a previously installed handler from the list. It's not terribly interesting, but I am mentioning it here for completeness.
The ability to preempt the normal SEH processing is something that various system-level programmers have wanted for a long time. However, with this flexibility comes the responsibility to use vectored exception handling properly. A vectored exception handler has the ability to return EXCEPTION_CONTINUE_EXECUTION, which causes subsequent handlers in the list not to be called. Somebody else's code may be expecting to see certain exceptions, and if you don't properly pass them along, you'll introduce bugs. Microsoft has introduced a great new capability here, so let's not mess it up for everybody else by carelessly assuming that your vectored exception handler is the only one registered.
http://msdn.microsoft.com/en-us/magazine/cc301714.aspx
|
also you can take a look at admirals nanomites tool it uses veh and then hooks veh installer apis
to pose as always first in chain so that it can cheat sehs

kcynice
June 3rd, 2008, 20:22
Quote:
[Originally Posted by naides;74943]Not really, while not user friendly or reversing oriented like Olly and SoftIce, WinDBG will trace any program. Ricardo Narvaja did some work on reversing with windbg. Hopefully some of it may have been translated to English. I even remember some one was working on a GUI interface/menu driven front for it. |
OK, I will have a try,thanks
kcynice
June 3rd, 2008, 21:22
Quote:
[Originally Posted by blabberer;74944]well i was googling to find corraboration to my statements above
that seh isnt called if veh is handling the exception
and i found matt_pietrek saying so
also you can take a look at admirals nanomites tool it uses veh and then hooks veh installer apis
to pose as always first in chain so that it can cheat sehs  |
I know what you meant. but the problem is that,one debugger can go to the first SEH handler but another can't. In fact, there are two dlls,first dll calls the second's functions, and the exception would be raised in the second dll function.like this:
first_dll_func(params...)
{
...//do somethings, there also some functions in second dll is called.
call the second dll's function which will raised an exception.
...//other code, i have not traced there because the exception
}
so, if it uses VEH, veh is process related, but i can't find the call for AddVectoredExceptionHandler in any file used by the program. In addition,if there is VEH used,the control flow will go to the VEH handler first but not go to the SEH chain if the exception was dealt with. But the fact is, the control will go to the SEH chain first in OllyDbg, so i can say there is no VEH or VEH doesn't deal with such exception.Further more, under Syser,the control will go to another strange address but NOT go to the SEH chain in anyway.
omega_red
June 4th, 2008, 03:26
@kcynice: maybe you could share the target via PM

BTW, windbg is the most powerful free windows debugger out there IMO, its capabilities are just mind blowing. Too bad it takes much time to learn and its gui is not that good (SI lovers should like it though

)
kcynice
June 4th, 2008, 04:03
OK, I accept your advice.Anybody interests in such a question, I will send a PM to him(or her),including you.
dELTA
June 4th, 2008, 11:33
Wohoo, he "accepted" the advice, now we can all get our expert exchange scores!
WHAT? There are no scores? Oh my god, what the hell have I been doing here answering questions all these years!?!?!

You do it just because of the undying glory you have achieved as a result.
Regards,
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.