0

In a 3rd party application I'm modifying by means of DLL injection, there's a chunk of code that throws an EXCEPTION_SINGLE_STEP exception if it detects changes to the code. To bypass this countermeasure, I wish to catch that exception and discard it completely. However, Windows keeps rethrowing it and therefore my exception handler is stuck in an endless loop.

My code currently:

LONG WINAPI VEH_Handler(struct _EXCEPTION_POINTERS *ExceptionInfo)
{
    printf("Got an exception %X at address %X\n", ExceptionInfo->ExceptionRecord->ExceptionCode, ExceptionInfo->ExceptionRecord->ExceptionAddress);

    if (ExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_SINGLE_STEP)
    {
        return EXCEPTION_CONTINUE_EXECUTION;
    }

    return EXCEPTION_CONTINUE_SEARCH;
}

//...

//in DllMain
AddVectoredExceptionHandler(1, VEH_Handler);

Is there a way for me to force Windows to forget about the exception and continue execution?

3

I assume this is a follow-up on this question.

If the program you're injecting the DLL into is setting the processor's trap flag, then returning from the exception will restore the trap flag as well, which would explain why the trap exception is thrown again and windows will keep calling your exception handler.

You might check the stack, find where the pushed flags from the exception are saved, and clear the trap flag before returning (*flagptr &= ~0x100).

However, the fact that your application sets the trap flag in the first place might mean one of those two things:

  • The application has detected that you're trying to crack it, and sets the trap flag to make it crash, or enter the debugger in an inconvenient way. It might do anything else to your program as well.
  • The application installs a trap exception handler, sets the trap flag, and has the trap handler modify the code that's being executed (25 years ago, i've seen this in a dos application, where the trap handler decrypted instructions just before they got executed, and re-encrypted them immediately afterwards, so you never saw the real assembly in a whole, so that's hardly a new technique).

Both possibilities probably mean that just ignoring the traps won't help you much; you should find the code that sets the trap flag, check why it's doing this, and continue your analysis from there.

  • It is, indeed. Okay, thanks for your suggestions, I'll play around with it. – szczurcio Feb 23 '15 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.