问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
漏洞分析与复现
NEW
活动
摸鱼办
搜索
登录
注册
初探windows异常处理
windows系统里，为了保证系统内核的强壮和稳定，为了保证用户程序的强壮和稳定，提供了异常处理机制，来帮助程序员和系统使用人员处理异常。如果想要更加深入的掌握操作系统，异常处理的知识是必不可少的，不仅如此，软件调试也与异常处理息息相关。
0x00 前言 ======= windows系统里，为了保证系统内核的强壮和稳定，为了保证用户程序的强壮和稳定，提供了异常处理机制，来帮助程序员和系统使用人员处理异常。如果想要更加深入的掌握操作系统，异常处理的知识是必不可少的，不仅如此，软件调试也与异常处理息息相关。 0x01 异常执行流程 =========== 异常产生后，首先是要记录异常信息(异常的类型、异常发生的位置等)，然后要寻找异常的处理函数，我们称为异常的分发,最后找到异常处理函数并调用，我们称为异常处理。 **异常的分类** - CPU产生的异常 - 软件模拟产生的异常 0x02 CPU异常 ========== ```c++ CPU指令检测到异常(例：除0) 查IDT表，执行中断处理函数 CommonDispatchException KiDispatchException ```  找到IDT表的0号中断  首先保存现场  然后向下走，但是并没有直接异常处理的代码，这里有一个跳转跟进去。为什么操作系统没有直接将异常处理写进去，这是因为操作系统希望我们自己首先能够将异常给处理掉  跟进去后发现调用了`CommonDispatchException`函数  `CommonDispatchException`主要是把一些异常的信息存储到了自己的结构体`_EXCEPTION_RECORD`里面，结构如下 ```c++ type struct _EXCEPTION_RECORD { DWORD ExceptionCode; //异常代码 DWORD ExceptionFlags; //异常状态 struct _EXCEPTION_RECORD* ExceptionRecord; //下一个异常 PVOID ExceptionAddress; //异常发生地址 DWORD NumberParameters; //附加参数个数 ULONG_PTR ExceptionInformation [EXCEPTION_MAXIMUM_PARAMETERS]; //附加参数指针 } ```  然后通过`KiDispatchException`去找到异常处理函数  在前面的跳转中，带过去了两个寄存器`eax`、`ebx`，`eax`我们可以发现它的值为`0c000094`，这个值是操作系统定义的   然后再是ebx，ebp指向的是`_Trap_Frame`结构体的栈顶，+68指向的就是eip  这两个值就对应了结构里面的`ExceptionCode`和`ExceptionAddress`  再看`ExceptionFlags`，CPU导致的异常这个值为0，软件调试导致的异常这个值为1  CPU异常执行的流程： > 1、CPU指令检测到异常 > 2、查IDT表，执行中断处理函数 > 3、调用CommonDispatchException(构建EXCEPTION\_RECORD) > 4、KiDispatchException(分发异常：目的是找到异常的处理函数) 0x03 模拟异常记录 =========== 调用过程 ```c++ CxxThrowException RaiseException(DWORD dwExceptionCode, DWORD dwExceptionFlags, DWORD nNumberOfArguments, const ULONG_PTR *lpArguments) NTDLL.DLL!RtlRaiseException() NT!NtRaiseException NT!KiRaiseException ``` 首先手动抛出异常  然后去反汇编发现调用了`CxxThrowException`  CxxThrowException ----------------- ```c++ __CxxThrowException@8: 00401290 push ebp 00401291 mov ebp,esp 00401293 sub esp,20h 00401296 push esi 00401297 push edi 00401298 mov ecx,8 0040129D mov esi,offset string "The value of ESP was not properl"...+0E0h (00423118) 004012A2 lea edi,[ebp-20h] 004012A5 rep movs dword ptr [edi],dword ptr [esi] 004012A7 mov eax,dword ptr [ebp+8] 004012AA mov dword ptr [ebp-8],eax 004012AD mov ecx,dword ptr [ebp+0Ch] 004012B0 mov dword ptr [ebp-4],ecx 004012B3 lea edx,[ebp-0Ch] 004012B6 push edx 004012B7 mov eax,dword ptr [ebp-10h] 004012BA push eax 004012BB mov ecx,dword ptr [ebp-1Ch] 004012BE push ecx 004012BF mov edx,dword ptr [ebp-20h] 004012C2 push edx 004012C3 call dword ptr [__imp__RaiseException@16 (0042b15c)] ``` 该代码所做的事情如下： > ① 先从内存中拷贝一段0x20字节的固定结构体到堆栈中; > ② 将ExceptionList也拷贝到堆栈中（该结构体内部） > ③ 传入有关参数调用RaiseException函数。 注意，ThrowCode虽然从用户代码传入进来，但分析其函数并没有用到，而是直接调用一段固定的异常码。而&ThrowCode以及异常链被作为其参数存储，这样通过分析就可以轻易找到其ThrowCode值，其作为参考之后来处理SEH。 RaiseException -------------- 跟进去调用了`Kernel32.dll`的`RaiseException`   这里跟CPU异常不同的是，CPU异常会将错误代码跟着寄存器一起传入，但是软件异常并没有，这里看一下  这里的edx为`E06D7363`就是软件调试的错误代码，这里注意，随着语言和版本的不同，这里的EDX即错误代码并不固定，取决于编译环境  第二个差异就是CPU异常存储的是发生异常的地址，软件异常则是存储`RaiseException`函数的地址  0x04 内核层异常处理流程 ============== 前面我们分析过，存在两种异常，CPU异常与用户模拟异常，其异常触发时收集的线路是不同的，但是其最终走经过`KiDispatchException`函数。 当走到`KiDispatchException`，CPU异常与用户模拟异常唯一的区别是CPU异常最高位置1（`nt!KiRaiseException`异常派发时的上一行代码），其余记录的都是一样的。 而`KiDispatchException`的处理是按照其先前模式来处理的，也就是内核异常与用户异常两种，而不是按照CPU异常与用户模拟异常来进行处理。 ```c++ 1) _KeContextFromKframes 将Trap_frame备份到context 为返回3环做准备 2) 判断先前模式 0是内核调用 1是用户层调用 3) 是否是第一次机会 4) 是否有内核调试器 5) 如果没有或者内核调试器不处理 6) 调用RtlDispatchException 7) 如果返回FALSE 也就是0 8) 再次判断是否有内核调试器 有就调用 没有直接蓝屏 ``` KiDispatchException ------------------- 首先定位到`KiDispatchException`函数  首先备份`Trap_Frame`结构，如果是用户层的异常则需要返回3环堆栈  首先通过判断先前模式的值来识别是内核异常还是用户层异常，这里有一个是否第一次调用该函数的判断，这是因为这个函数会被调用很多次，如果不是第一次调用则直接跳转  这个函数的最后一个参数就是表示这个函数是第几次被调用  然后继续判断有没有内核调试器的存在(如windbg)  如果有内核调试器的存在就走下面的`KiDebugRoutine`函数  如果内核调试器没有处理返回失败的话就跳转  `RtlDispatchException`调用异常处理函数  跟进到`RtlDispatchException`  又调用了`RtlGetRegistrationHead`  跟进去发现取的是`fs:[0]`  \_EXCEPTION\_REGISTRATION\_RECORD --------------------------------- 我们知道0环的`fs:[0]`指向KPCR，KPCR的第一个结构是`_NT_TIB`，`_NT_TIB`的第一个成员是`ExceptionList`，是一个`_EXCEPTION_REGISTRATION_RECORD`类型的结构体 `_EXCEPTION_REGISTRATION_RECORD`结构如下 ```c++ typedef struct _EXCEPTION_REGISTRATION_RECORD { struct _EXCEPTION_REGISTRATION_RECORD *Next; PEXCEPTION_ROUTINE Handler; } EXCEPTION_REGISTRATION_RECORD; ``` `_EXCEPTION_REGISTRATION_RECORD`里面有两个成员，`*Next`是一个指针指向下一个`_EXCEPTION_REGISTRATION_RECORD`结构，而第二个成员`Handler`指向的就是一个异常处理函数 `RtlDispatchException`的作用如下： > 遍历异常链表，调用异常处理函数，如果异常被正确处理了，该函数返回1 > > 如果当前异常处理函数不能处理该异常，那么调用下一个，以此类推。 > > 如果到最后也没有处理这个异常，返回0。  调用异常处理函数得到返回值后跳转到地址  然后判断返回值是否为1，1的话就是处理成功，跳转  异常被处理成功则把`Context`结构放回`Trap_Frame`里面  如果没有被处理成功则继续往下走进行有无内核调试器的判断，如果有内核调试器则调用`KiDebugRoutine`  如果没有内核调试器或者有内核调试器但是没有处理异常，则跳转到下面的地方  操作系统蓝屏  0x05 用户层异常处理流程 ============== 定位到`KiDispatchException`，进入用户异常的函数  进入函数首先判断是不是第一次调用，然后继续往下走，如果有内核调试器则直接跳转，没有的话继续往下走  然后进行异常的处理，调用`DbgkForwardException`，这个函数的作用是调用3环的调试器 ，再进行判断有无3环的调试器接收异常，如果没有则返回3环处理  然后进行结构体的修改，这里同用户APC执行的修改过程  然后修改`EIP`的值为`KeUserExceptionDispatcher`函数的地址，这时候`EIP`的值已经是函数地址，这时候再回到原函数   注意这里并没有直接进行返回3环的操作，而是`KiDispatchException`这个函数执行结束过后回到原函数，用不同的方法回到3环 ```c++ CPU异常：CPU检测到异常 -> 查IDT执行处理函数 -> CommonDispatchException <-> KiDispatchException 通过IRETD返回3环 模拟异常：CxxThrowException -> RaiseException -> RtlRaiseException -> NT!NtRaiseException -> NT!KiRaiseException <-> KiDispatchException 通过系统调用返回3环 ``` 无论通过那种方式，但线程再次回到3环时，将执行`KiUserExceptionDispatcher`函数 KiUserExceptionDispatcher ------------------------- 返回三环后，可以看到其调用一个`RtlDispatchException`。注意，在处理内核异常时，也有一个同名的`RtlDispatchException`，那是内核模块，这是三环模块。 `RtlDispatchException`可以认为是异常的核心，区别是如果在内核模块，则处理零环，如果在ntdll模块，则处理三环。 
发表于 2022-04-14 09:57:00
阅读 ( 6732 )
分类：
漏洞分析
2 推荐
收藏
1 条评论
向往阳光的月光
2022-07-19 21:45
idb文件能给下不~
请先
登录
后评论
请先
登录
后评论
szbuffer
30 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
