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?

hard to say due to lack of information.
try researching about the LoadConfig directory.

Can you tell more about the other address?

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?

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)

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!

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.

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.

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

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.

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

OK, I will have a try,thanks

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.

@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 )

OK, I accept your advice.Anybody interests in such a question, I will send a PM to him(or her),including you.

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,