Abnormal distribution (user anomaly)

Content review:

If the exception is sent at the kernel layer, it is relatively simple to handle, because the exception handling function is also in ring 0, and there is no need to switch the stack, but if the exception occurs in ring 3, it means that the stack must be switched and return to ring 3 to execute the processing function

The switching stack processing method is almost the same as the execution process of the user APC, the only difference is that the function executed after the user APC returns to the third loop is KiUserApcDispatcher, and the function executed after the return loop 3 in the exception handling is KiUserExceprionDispatcher

Therefore, understanding the execution process of the user's APC is the key to understanding the 3 loop exception handling

User exception handling process:

VOID KiDispatchException (ExceptionRecord, ExceptionFrame, TrapFrame, PreviousMode, FirstChance)
1._KeContextFromKframes Backup Trap_frame to the context in preparation for returning to the 3rd ring

Step 1: Regardless of user exception or kernel exception, first back up Trap_frame (when the current thread enters ring 0, the register area environment, that is, the values ​​of the eip running place) to the context (preparation for returning to ring 3)

The distribution of the two exceptions (user exception and kernel exception) of this function is under its control, so there is whether the exception handling needs to go back to the third ring, the kernel exception does not need to go back (the kernel exception handling function is in the 0 ring), the user exception needs to go back ( The user layer processing function is in the 3rd ring 0).

2. Step 2: Determine the previous mode, 0 is the kernel call, 1 is the user call, the user layer is abnormal, and then jump: 0x4258C3

The third step: the first time it is executed, it must be the first call (this function is executed more than once), so continue on:

Here it is judged whether the kernel debugger is enabled. If there is a kernel debugger, then this value is non-zero. If there is a kernel debugger, then it will call and send the exception information to the exception debugger first (then we assume here There is no kernel exception debugger, or the kernel exception debugger did not handle it)

The fourth step: used to judge the 3 ring debugger (if the 3 ring debugger does not exist or the 3 ring debugger has not processed it, then go down)

Step 5: Prepare for returning to Third Ring Road

The Trap_frame is backed up to the context at the beginning, and then you can change it as you like here.

The most critical modification is to overwrite the value in KeUserExceptionDispatcher to Eip, which does not directly return to the third ring at the current position. But let the current program end execution

to sum up

VOID KiDispatchException（ExceptionRecord，ExceptionFrame，TrapFrame，PreviousMode，FirstChance）

1. _KeContextFromKframes backup Trap_frame to context in preparation for returning to the 3rd ring
2. Determine the previous mode 0 is a kernel call, 1 is a user call
3. . Is it the first chance
4. Is there a kernel debugger
5. Send to 3 ring debugging
6. If the 3 ring debugger does not handle this exception, correct EIP to KiUserExceptionDispatcher
7. KiDispatchException function execution ends: CPU exception and simulated exception return place is different
   CPU exception: CPU detected exception—>check IDT to execute the processing function—>CommonDispatchException—>KiDispatchException return 3 loop
   simulation exceptions through IRETD : CxxThrowException—>RaiseException —>RtlRaiseException---->Nt!NtRaiseException—>Nt!KiRaiseException---->KiDispatchException returns to ring 3 through the system call
8. Either way, but the thread goes back to loop 3 again, and the KiUserExceptionDispatcher function will be executed