Ignore exception

[Fruitpunch]

Hey,

I have found that you can detect veh debugger by raising exception with flag 0x4001000A. I could not find a way to ignore exceptions. Is it not possible?

[Eric]

do you have an example sourcecode because I can not reproduce it with
`RaiseException(DBG_PRINTEXCEPTION_WIDE_C/*0x4001000A*/, 0, 4, args);`

not even the windows debugger interface triggers this one

but you can ignore exceptions. in memview go to debug and set break on unexpected exceptions to never, or to "only in specific regions"
If you choose the later, then you will also have "manage exception code filter" where you can enter the exceptions to ignore

[Fruitpunch]

In that case, I've probably interpreted the flow of code incorrectly. Hard to say for sure, I have no idea how to debug exceptions.

That is exactly the function I see being called. x64dbg has no issue with it but with Cheat engine the program crashes. I was so sure that it was Cheat engine swallowing the exception but it could also be checks happening in the handler. I have to keep digging then.

[Fruitpunch]

I have narrowed down the problem. lnside function RtlRaiseException there is a call to RtlRestoreContext+650. For whatever reason the RRC+650 sometimes (I don't know how long Eric ran his trial) skips the correct exception handler on VEH which results in wrong code execution. Assigning SW or HW breakpoints inside RRC+650 lead to an immediate crash and the break and trace function does not work there either.

Since this does not happen in x64Dbg, I no longer have the means nor the patience to figure out the cause. I don't use visual studio so I can't verify if these problems occur in a simple program as well. You could argue that there is some debugger detection magic going on (and it's certainly possible) but I don't see it.

If anyone has come across this type of problem before and knows why it happens it would be great if you could indulge. Otherwise if you're in the same situation, the way I am dealing with this is by figuring out where the execution jumps after the exception and just overwrite the raiseException function with a jump.

[Fruitpunch]

I dug even deeper, couldn't help myself.

I'm even more inclined to believe that there is a problem somewhere in the veh debugger.
The correct handler fails to run because of this code:

Code: Select all

vehdebug-x86_64.UnloadVEH+2F8 - 48 81 B8 10200000 02000100 - cmp qword ptr [rax+00002010],00010002 { 65538 }
vehdebug-x86_64.UnloadVEH+303 - 75 07                      - jne vehdebug-x86_64.UnloadVEH+30C
vehdebug-x86_64.UnloadVEH+305 - BF FFFFFFFF                - mov edi,FFFFFFFF { -1 }
vehdebug-x86_64.UnloadVEH+30A - EB 02                      - jmp vehdebug-x86_64.UnloadVEH+30E

At some point the veh handler writes -1 to edi. I think I found this in the source code DebugHandler.pas.

In InternalHandler:

Code: Select all

//depending on user options either return EXCEPTION_CONTINUE_SEARCH or EXCEPTION_CONTINUE_EXECUTION
if VEHSharedMem^.ContinueMethod=DBG_CONTINUE then
  result:=EXCEPTION_CONTINUE_EXECUTION
else
  result:=EXCEPTION_CONTINUE_SEARCH;

So it continues execution instead of search. I tried to find out where [rax+00002010] (VEHSharedMem^.ContinueMethod) changes by using What writes to this address but I get nothing.

Anyone got any tips on how to find where "VEHSharedMem^.ContinueMethod" changes?

[Eric]

does the error occur in a newly created thread or in an old thread?

there was a bug where new threads would get the wrong context set on exception

[Fruitpunch]

In this game there is a thread that's running RaiseException very often. So it's and old thread.

[Eric]

it's fixed

[Fruitpunch]

Tested 7.5 Pre release. It appears to be working now.
Million thanks to you Eric!