Windows系统异常处理调试

字数统计: 11k字   |   阅读时长≈ 43分

因为做项目，需要做漏洞检测。但是很多漏洞由于只能找到 POC，能触发程序崩溃。所以就需要做一个 系统异常处理的检测。在之前对异常处理有一定的了解下，很想从内核 对系统异常处理的步骤进行一个全面的调试分析。所以完成这篇文章，算是对这个知识的总结。

0x1 异常简介

异常是CPU或者程序发生的某种错误，异常处理就是异常产生之后Windows对于产生的错误的一段处理程序。异常可分为硬件异常和软件异常。

硬件异常

硬件异常是由CPU发现的异常，比如说除零异常、内存访问异常，经常看到的错误信息类似于 0xXXXXXX 指令引用的0xXXXXX内存，该内存不能为read”等。硬件异常可以分为三种：

  • fault,在处理此类异常时，操作系统会将遭遇异常时的“现场”保存下来，比如EIP、CS等寄存器的值，然后将调用相应的异常处理函数。如果异常处理成功，则恢复到原始现场、继续执行
  • trap，在处理此类异常时，操作系统会将异常的下文保存，在处理异常后，直接执行导致异常的指令的下一条指令。例如调试使用的断点操作就是基于该类异常，当下断点时调试器会将原本指令此处对应的十六进制保存下来，然后替换第一个字节替换为0xCC的，造成异常中断。
  • abort，中止异常，主要是处理严重的硬件错误等，这类异常不会恢复执行，会强制退出

在windows系统中，硬件异常和中断被不加区分的存放在了一个向量表中，即IDT(interruption descriptor table)，可以使用windbg的 !idt指令查看IDT（查看 IDT，需要在内核调试模式下才能进行。这里我是使用windbg 双机调试内核）。下表中前面序号代表是第几个中断或异常，后面函数则是对这种异常或终端的处理函数，也即异常处理例程：

image-20200731171518044

然后，可以使用 r idtr 来查看 idtr 寄存器中保存的 idt 表地址。

软件异常

由操作系统或应用程序抛出的异常，即异常不是由CPU触发的。比如C++关键字throw、Windows API函数的 RaiseException。这类异常都是基于RaiseException这个用户态API和NtRaiseException的内核服务建立起来的。RaiseException的函数原型：

1
void RaiseException(DWORD dwExceptionCode , DWORD dwExceptionFlags,DWORD nNumberofArguments,const DWORD* lpArguments);

dwException是异常状态码，可以在NtStatus.h中找到，应用程序也可以有自己的异常状态码。nNumberofArguments和lpArguments是用来定义异常的数据。

函数会将异常的相关信息传入一个维护异常的结构，即EXCEPTION_RECORD，然后再去调用RtlRaiseException函数，结构如下：

1
2
3
4
5
6
7
8
1.	typedef struct _EXCEPTION_RECORD {  
2.	  DWORD                    ExceptionCode;      //异常状态码  
3.	  DWORD                    ExceptionFlags;     //异常标志位  
4.	  struct _EXCEPTION_RECORD *ExceptionRecord;   //指向下一个异常的指针  
5.	  PVOID                    ExceptionAddress;   //异常的发生地址  
6.	  DWORD                    NumberParameters;   //ExceptionInformation数组中参数的个数  
7.	  ULONG_PTR                ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];    //异常的描述信息  
8.	} EXCEPTION_RECORD;

​ 之后调用的RltRaiseException会将当前的上下文保存到CONTEXT结构中，此后调用的函数会维护一个TrapFrame（即栈帧的基址）和异常的处理次数的标志，调用链如下：

1
2
1.	用户：RaiseException -> RltRaiseException -> NtRaiseException -> KiRaiseException 
2.	内核：RtlRaiseException -> NtRaiseException -> KiRaiseException

0x2 异常分发

异常产生

硬件异常产生是当CPU尝试执行指令时检查到的问题。

当异常产生时，CPU查询中断处理表，找到异常处理的函数（_KiTrapXX之类）-> KiTrapXX函数里面调用CommonDipatchException-> 调用KiDispatchException进行异常分发。

软件异常的产生调用RaiseException->包装异常->NtRaiseException->进入内核-> 调用nt!NtRaiseException-> 调用KiDispatchException进行异常分发;其中包装异常的意思就是，因为这个异常是模拟的，所以这个异常的具体信息需要由程序自己来填充。

异常分发

硬件异常会通过IDT去调用异常处理例程（一般为KiTrap系列函数），而软件异常则是通过API的层层调用传递异常的信息，实际上二者最后都会靠KiDispatchException函数来进行异常的分发。

KiDisPatchException函数的函数原型如下：

1
2
3
4
5
6
7
1.	void KiDispatchException (  
2.	    IN PEXCEPTION_RECORD ExceptionRecord,  //描述异常的结构  
3.	    IN PKEXCEPTION_FRAME ExceptionFrame,     
4.	    IN PKTRAP_FRAME TrapFrame,              //描述发生异常时的上下文  
5.	    IN KPROCESSOR_MODE PreviousMode,       //说明异常来自内核还是用户态  
6.	    IN BOOLEAN FirstChance                  //说明异常是否是第一次处理  
7.	    )

最后，KiDispatchException 异常分发流程如下：

image-20200731175220493

内核异常分发

当 PreviousMode 为 KernelMode 时，就会进入右边的 内核异常分发。

首先系统 会维护一个 KiDebugRoutine 函数，然后判断是否开启了 内核调试器。如果开启了，则将异常交给内核调试器处理。如果未开启内核调试器，则会进入 下一步 RtlDispatchException ，函数原型如下：

1
BOOLEAN RtlDispatchException(PEXCEPTION_RECORD ExceptionRecord,PCONTEXT ContextRecord)

ExceptionRecord 是系统的异常结构，ContextRecord 是系统的异常时的上下文环境。

函数处理逻辑为：

1
2
3
4
5
6
取异常登记链表的头指针
	遍历异常登记记录
	检查异常登记记录的有效性，有效则执行
		异常已处理，返回
	没有处理，返回并继续遍历
	如果是内嵌异常则进行特殊处理

此时，如果异常被处理了，那么系统将会继续向下正常执行。如果异常没有被处理，则会进行第二轮分发，再次判断是否开启了内核调试器，如果没有开启内核调试器。则此时这个异常 为 UnhandleException（即未处理异常），则表明系统出现问题。常表现为系统蓝屏。

用户态异常分发

内核态的异常处理函数在内核中，用户态的异常处理函数在用户态中。当用户态异常经过KiDispatchException时，则需要切换到用户态的代码进行异常的分发和处理。

用户态异常的分发更加复杂，主要原因是处理此异常需要先切换到用户空间，然后交由用户层的异常代码再次进行分发，流程如下：

1
2
3
4
5
6
7
8
9
10
1.	检查当前是不是第一次分发该异常，如果异常第一次没有被处理，那么第二次就不会再调用异常处理程序，而是直接尝试将异常发给调试器；
2.	如果当前是第一次分发该异常，那么便尝试将异常发给内核调试器，调用内核函数 DbgkForwardException；
3.	如果内核调试器不存在或者没有对该异常进行处理，那么则尝试将异常发送给用户态调试器；
4.	如果用户态调试器不存在或者没有处理该异常，那么此时便准备一个返回ntdll!KiUserExceptionDispatcher函数的应用层调用栈，准备  产生的异常的数据，然后结束本次KiDispatchException函数的运行。因为函数结束之后，会调用KiServiceExit返回用户层，此时当前的TrapFrame就是准备好的用户执行ntdll!KiUserExceptionDispatcher的环境，所以当从内核退出时，用户态线程便会从执行ntdll!KiUserExceptionDispatcher开始执行；
5.	ntdll!KiUserExceptionDispatcher调用ntdll!RtlDispatchException进行异常的分发，此处的流程和内核态nt!RtlDispatchException流程基本一致；
6.	通过RtlCallVectoredExceotionHandlers遍历VEH链表尝试查找异常处理函数；
7.	如果VEH没有处理函数处理该异常，则从fs[0]读取ExceptionList并开始执行SHE的函数处理；
8.	如果到最后仍然没有处理该异常，这时便会再次主动调用NtRaiseException将该异常重新抛出来，但是此时就不是第一次机会了，此时NtRaiseException流程重新调用了ntdll!KiDispatchException，并再次进入用户态异常的处理分支，但是此时不再是第一次异常处理，所以此次异常不会再次发送给用户态进行分发，而是再次尝试将异常发给用户调试器（此时不会再次将异常发送给内核调试器），此时有两次机会可以让用户态调试器进行异常的处理，最后如果此异常仍然没有被用户态调试器处理，那么ntdll!KiDispatchException便会调用ZeTerminateProcess直接结束该进程；
9.	如果在上一步有异常处理程序处理了该异常，那么便会调用NtContinue，将之前保存的TrapFrame还原；
10.	当函数从NtContinue返回时，就会根据上面函数的处理结果继续执行。

应用层异常的分发可能存在找不到异常处理方案，但是应用层和内核最大的区别在于，如果内核层发生的异常没有被正确执行，那么此时就会产生蓝屏。但是用户层的异常如果找不到异常处理程序处理该异常，那么最终Windows系统会根据当前系统的设置，调用UnhandledExceptionFilter的函数，这个函数被调用之后，要么弹出一个错误框，要么启动一个调试器。也即无论如何都会存在一个异常处理函数来接管最后的异常。

如果我们使用 Windbg 调试一个程序，当程序崩溃时，Windbg记录到的程序异常处理点 就应该从 ntdll!KiDispatchException函数处开始处理。

关于 VEH 和 SEH 的处理在 ntdll!RtlDispatchException函数中。

0x3 SEH和VEH

SEH

SEH是比较特殊的异常处理链表，全名为Structed Exception Handler，SEH的注册结构体只能作为局部变量存在于当前线程的调用栈，如果一旦结构体的地址不在当前调用栈的范围中，则在进行异常分发时，将不会进入该函数。SHE描述结构的注册随着函数的调用而注册，随着函数的结束而注销。其结构如下：

1
2
3
4
5
1.	typedef struct _EXCEPTION_REGISTRATION_RECORD  
2.	{  
3.	  struct _EXCEPTION_REGISTRATION_RECORD *Next;   //下一个SHE节点  
4.	  PEXCEPTION_ROUTINE Handler;                     //处理该异常的函数，异常回调函数  
5.	}EXCEPTION_REGISTRATION_RECORD

该链表只允许在头节点来进行删除和增添操作，且FS的0一直指向头节点，这就说明，越新的函数越接近头节点，系统会维护链表最后的next指向0xFFFFFFFF。

SEH是基于线程的一种处理机制，且依赖于栈进行存储和查找，所以被称作是基于栈帧的异常处理机制。SEH装载代码如下：

1
2
3
push offset SEHandler
push fs:[0]
mov fs:[0],esp

先向栈中压入Handler和当前的节点，构成一个EXCEPTION_REGISTRATION_RECORD结构，而esp指向栈顶，正好就是新的EXCEPTION_REGISTRATION_RECORD，将他付给fs:[0]就是让SEH的头节点变成刚加入的新节点。SEH卸载过程即为恢复栈平衡的代码：

1
2
mov esp,dword ptr fs:[0]
pop dword ptr fs:[0]

SEH异常的安装实际上从main函数之前就开始了，当我们在启动一个进程时，实际的启动位置也就是kernel!32BaseProcessStartThunk，而在这个函数内就已经开始有try、catch结构了，线程的启动函数kernel!32BaseThreadStart也是如此：

1
2
3
4
5
6
7
8
VOID BaseThreadStart(PTHREAD_START_ROUTINE pfnStartAddr, PVOID pvParam) {  
    __try{  
        ExitThread((pfnStartAddr)(pvParam));  
    }  
    __except (UnhandledExceptionFilter(GetExceptionInformation())){  
        ExitProcess(GetExceptionCode());  
       }  
}

实际上这里的try catch结构构成的异常回调函数就是top level，即顶层异常处理，它们也是SEH链的最后一部分，并且可以看到，它们的except还存在一个叫做UnhandledFilter函数，和字面上的意思相似，这是用来实现异常过滤的函数。

当异常分发到RtlDispatchException函数时，会根据线程注册的SEH来处理该异常，其伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
1.	if VEH异常处理例程 != Exception_continue_search  
2.	    goto end_func  
3.	  
4.	else  
5.	    limit = 栈的limit  
6.	    seh = 借助FS寄存器获取SEH的头节点  
7.	    while(seh!=-1):  
8.	        if SEH节点不在栈中 || SEH节点位置没有按ULONG对齐 || Handler在栈中  
9.	            goto end_func  
10.	        else  
11.	            seh = 当前seh指向的下一个seh  
12.	    seh = 借助FS寄存器获取SEH的头节点  
13.	    while(seh!=-1):  
14.	        if(检查safeseh)  
15.	            goto end_func  
16.	        else  
17.	            return_value = 执行该seh的handler  
18.	            switch(return_value):  
19.	                case 处理成功:  
20.	                    flag=1  
21.	                    goto end_func  
22.	                case 没法处理:  
23.	                    seh = 当前seh指向的下一个seh  
24.	                case 处理时再次遭遇异常  
25.	                    设置标记，做内嵌异常处理  
26.	                    goto    end_func  
27.	end_func:  
28.	    调用VEH的continue handler  
29.	    return

其执行过程为：

1
2
3
4
5
6
7
•	调用VEH ExceptionHandler进行处理，成功则结束，否则进行SEH
•	遍历SEH节点，对每一个Handler进行RtlExceptionHandlerForException，根据返回值执行不同操作
•	ExceptionContinueExecution，表示异常已经被处理过了，接下来就可以回到之前的异常现场（Context）再执行试试了。
•	ExceptionContinueSearch，表示这个节点的handler处理不了这个异常，此时就会借助Next指针去寻找下一个节点接着去处理
•	ExceptionNestedException，意思是处理异常时又引发了一个新的异常，如果是内核态遇到了这个问题就直接蓝屏，如果是用户态的话就成了”嵌套”异常，也就是会在此处再次进行异常处理
•	ExceptionCollidedUnwind，这个和上面的类似，不过上面是异常处理时遇到了麻烦，而这个是在恢复现场的时候遇到了不测，这个”恢复现场”的过程也叫做展开。 
•	调用VEH ContinueHandler进行处理

UnhandleExceptionFilter函数

未处理异常过滤函数，简称UEF函数，是异常处理和windows error report交接的关键，其流程如下：

  • 错误的预处理，主要是对三个方面的检查：

    • 是否存在着嵌套异常。嵌套异常是一种非常难处理的情况，如果处理的不好就很难再恢复原始的状态了，于是这种情况下UEF函数会直接调用NtTerminateProcess结束当前的进程
    • 是否是违例访问。这种情况下UEF函数会尝试去通过更改页属性的方式去修复错误，当然如果访问的是绝对不该访问的页，那UEF就无法解决了。
    • DebugPort有没有。DebugPort在异常分发的过程中起到了标志着调试器是否开启的任务，一旦UEF检测到了DebugPort那它就不会处理该异常，而是返回一个ExceptionContinueSearch，而它作为最后的异常处理也没有处理该异常的话自然也就进入了第二次的异常分发，成功使调试器接手该异常

  • 进行最终的处理

    • 根据程序的设置直接结束进程。windows提供了SetErrorMode的api用来设置某个标志位，一旦设置了，那那就不会出现任何的错误提示，程序直接结束。判断当前进程是否在job中，如果在且设置了未处理异常时直接结束，那就直接杀掉进程。
    • 查看是否设置了JIT调试，如果是就开始进行调试。
    • 弹出异常信息。此时程序会加载faultrep.all，调用ReportFault函数来汇报错误，如果设置了错误报告或者是非常严重的错误会弹出error窗口询问用户是否要发送错误报告，而其余情况下就会弹出我们熟知的application error

SEH处理流程

很久之前就写了这篇文章记录对windows的异常处理机制的笔记。但是随着后续深入学习，发现还有很多关键的流程与数据结构仍然不是很了解。所以在半年后，由来补充一些知识。下面关于SEH的知识点主要参考自此文章。

异常注册的链表会保存在线程的数据结构中，异常所涉及的一些行为都是线程相关的，比如线程 T1触发的异常只能由线程 T1来处理。

注册异常完后，线程就可以抛出或处理异常，系统也可以做相应的管理工作。系统的管理工作包括：找到触发异常的线程的异常处理链表，按照规则对该异常进行分发，根据分发后的处理结果在进行下一步的分发或结束处理。

系统管理所使用的数据结构或宏：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 #define EXCEPTION_CHAIN_END ((struct _EXCEPTION_REGISTRATION_RECORD * POINTER_32)-1)

typedef enum _EXCEPTION_DISPOSITION {

    ExceptionContinueExecution,

    ExceptionContinueSearch,

    ExceptionNestedException,

    ExceptionCollidedUnwind

} EXCEPTION_DISPOSITION;


typedef struct _EXCEPTION_RECORD {

    DWORD ExceptionCode;

    DWORD ExceptionFlags;

    struct _EXCEPTION_RECORD *ExceptionRecord;

    PVOID ExceptionAddress;

    DWORD NumberParameters;

    ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];

} EXCEPTION_RECORD;



typedef EXCEPTION_RECORD *PEXCEPTION_RECORD;



typedef EXCEPTION_DISPOSITION (*PEXCEPTION_ROUTINE) (

    IN struct _EXCEPTION_RECORD *ExceptionRecord,

    IN PVOID EstablisherFrame,

    IN OUT struct _CONTEXT *ContextRecord,

    IN OUT PVOID DispatcherContext

);

typedef struct _EXCEPTION_REGISTRATION_RECORD {

    struct _EXCEPTION_REGISTRATION_RECORD *Next;

    PEXCEPTION_ROUTINE Handler;

} EXCEPTION_REGISTRATION_RECORD;


typedef EXCEPTION_REGISTRATION_RECORD *PEXCEPTION_REGISTRATION_RECORD;

Exception_registration_record：结构就是异常信息

  1. EXCEPTION_REGISTRATION_RECORD::Next指向下一个 Exception_Registration_record，由此构成一个异常注册记录链表，链表的最后一个结点会将 Next置为 Exception_chain_end，表示链表到此结束；
  2. Exception_Registration_record::handler指向异常处理函数

当接收到异常后，系统找到当前线程的异常链表，从链表中的第一个结点开始遍历，找到一个 Exception_registration_record就调用它的 Handler，并把该异常（有第一个类型为 Exception_record的参数表示）传递给该 Handler，Handler处理并返回一个类型为 Exception_disposition的枚举值，用于指示系统下一个的行为：

  • ExceptionContinueExecution 表示：已修正此异常的，从事发点重新执行
  • EceptionContinueSearch表示：没有处理此异常，继续搜索
  • ExceptionNestedException 和 ExceptionCollidedUniwnd 后续解释

内核异常处理流程

首先 CPU执行的指令触发了异常，CPU改执行 IDT中的 KiTrap，KiTrap会调用 KiDispatchException，函数原型如下：

1
2
3
4
5
6
7
VOID KiDispatchException (
    IN PEXCEPTION_RECORD ExceptionRecord,
    IN PKEXCEPTION_FRAME ExceptionFrame,
    IN PKTRAP_FRAME TrapFrame,
    IN KPROCESSOR_MODE PreviousMode,
    IN BOOLEAN FirstChance
);

该函数用于分发异常，在当前栈中分配一个 Context，调用 KeContextFromKframes初始化它，检查 ExceptionRecord->ExceptionCode，如果：

  • 是 STATUS_BREAKPOINT，则将 CONTEXT::Eip 减一；
  • 是 KI_EXCEPTION_ACCESS_VIOLATION，将检查是否是由 AtlThunk触发，如果是触发 NX(不可执行)，则将 ExceptionRecord->ExceptionInformation[0]置为 0（表示触发操作的类型，0表示读，1 表示写）
  • 如果 FirstChance为 True，则将该异常传达给内核调试器，如果内核调试器没有处理，则调用 RtlDispatchException进行处理
  • 如果 FirstChance为 False，则再次将该异常传达给内核调试器，如果内核调试器没有处理，则 BUGCHECK
  • 如果第3步中，内核调试器没有处理，则将异常传达给应用层调试器，如果仍然没有处理，则将 KTRAP_FRAME和 EXCEPTION_RECORD拷贝到 UserMode的栈中，并设置 KTRAP_FRAME::Eip为 ntdll!KiUserExceptionDispatcher，返回（将该异常交由应用层异常处理程序进行处理）
  • 如果第4步中，内核调试器仍然没有处理，则调用 ZwTerminateProcess结束进程，并 BUGCHECK

这里首先来看是内核异常 KernelMode的情况，先不讨论应用层异常。其重点是调用 RtlDispatchException，如下：

1
2
3
4
BOOLEAN RtlDispatchException (
    IN PEXCEPTION_RECORD ExceptionRecord,
    IN PCONTEXT ContextRecord
);

遍历当前线程的异常链表，依次调用 RtlExecuteHandlerForException，RtlpExecuteHandlerForException会调用异常处理函数，再根据返回值做不同的处理：

  • ExceptionContinueExecution 表示：结束遍历，返回
  • EceptionContinueSearch表示：继续遍历下一个结点
  • ExceptionNestedException，从指定的新异常继续遍历

只有正处理 ExceptionContinueExecution才会返回TRue，其他情况返回 FALSE

这里先解释一下异常链表，系统将异常链表头保存在线程结构里，线程的内核数据结构体现是 _ETHREAD：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
kd> dt _ETHREAD
    ntdll!_ETHREAD
    +0x000 Tcb              : _KTHREAD
        ... 省略之后的成员



kd> dt _KTHREAD
ntdll!_KTHREAD
    ... 省略的域成员
    +0x074 Teb              : Ptr32 Void
   ... 省略的域成员



Teb 成员的类型实际是 _TEB，来看看
kd> dt _TEB
ntdll!_TEB
    +0x000 NtTib            : _NT_TIB
    ... 省略的域成员        

kd> dt _NT_TIB
ntdll!_NT_TIB
     +0x000 ExceptionList    : Ptr32 _EXCEPTION_REGISTRATION_RECORD
     +0x004 StackBase        : Ptr32 Void
     +0x008 StackLimit       : Ptr32 Void
     +0x00c SubSystemTib     : Ptr32 Void
     +0x010 FiberData        : Ptr32 Void
     +0x010 Version          : Uint4B
     +0x014 ArbitraryUserPointer : Ptr32 Void
     +0x018 Self             : Ptr32 _NT_TIB

对于系统，只需要借助 FS寄存器来加速寻找，在应用层 FS寄存器指向当前执行线程的 _TEB结构体，再内核层 FS寄存器指向另一个跟 CPU相关的结构体：_KPCR：

1
2
3
4
nt!_KPCR
    +0x000 NtTib            : _NT_TIB
    +0x000 Used_ExceptionList : Ptr32 _EXCEPTION_REGISTRATION_RECORD
    ...

与 _TEB一样，其第一个域成员也是 _NT_TIB，此时是 nt!_NT_TIB，而应用层是 ntdll!_NT_TIB，其结构一样。所以，无论在应用层和内核层，系统都可以使用 FS[0]找到异常链表。

那么CPU触发的异常处理流程，调用流程如下：

1
CPU 检测到异常 -> KiTrap?? -> KiDispatchException -> RtlDispatchException -> RtlpExecuteHandlerForException

上述为硬件异常。

软件异常

软件异常与硬件异常流程相似，如下：

1
RtlRaiseException -> RtlDispatchException -> RtlpExecuteHandlerForException

这里分析新函数 RtlRaiseException，用于触发异常，如下：

1
2
3
VOID RtlRaiseException (
    IN PEXCEPTION_RECORD ExceptionRecord
);

RtlRaiseException首先调用 RtlDispatchException分发异常，如果 RtlDispatchException成功分发（有处理函数处理了该异常），则结束本函数。如果没有成功分发，则调用 ZwRaiseException再次触发异常，此次传入的异常 FisrtChance被设置为 False。

此时系统提供的SEH机制，总结如下：

  1. 系统原始异常处理功能简单，实际过程中很难直接使用，整个异常处理过程就是遍历异常链表，挨个调用已成注册信息的处理函数，如果其中有某个处理函数处理了该异常（返回值为 ExceptionContinueExecution，就从异常触发点（如果是断点异常，则要回退一个字节的指令）重新执行。否则不管是整个链表中没有找到合适的处理函数(返回值为 ExceptionContinueSearch)，或者遍历出现问题(返回值为ExceptionNestedException)，系统都会简单 BUGCHECK。

编译器 异常处理

不同编译器提供的 SEH增强版本有不同之处，但其都基于 Windows系统提供的机制完善。一个典型的增强版就是微软的编译器(简称 MSC)里提供的 __try、__finally、__except。接着就用这个增强版作为目标进行分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
typedef struct _EXCEPTION_REGISTRATION PEXCEPTION_REGISTRATION;

struct _EXCEPTION_REGISTRATION{
    struct _EXCEPTION_REGISTRATION *prev;
    void (*handler)(PEXCEPTION_RECORD, PEXCEPTION_REGISTRATION, PCONTEXT, PEXCEPTION_RECORD);
    struct scopetable_entry *scopetable;
    int trylevel;
    int _ebp;
    PEXCEPTION_POINTERS xpointers;
};


这个 EXCEPTION_REGISTRATION 在增强版中就相当于原始版本中的 EXCEPTION_REGISTRATION_RECORD。可以这么理解它：
struct _EXCEPTION_REGISTRATION{
    struct _EXCEPTION_REGISTRATION_RECORD ExceptionRegistrationRecord;
    struct scopetable_entry *scopetable;
    int trylevel;
    int _ebp;
    PEXCEPTION_POINTERS xpointers;
}; // 注：本结构体只用于理解原始版和增强版的区别，实际代码中并没有这种形式的定义

沿用了老版本的注册信息结构，在域成员名称山做了改动，把 Next改名为 Prev，把 Handler改为 handler。在原始基础上增加了 4 个 域成员 (scopetable、trylevel、_ebp、xpointers)。在实际中，最后一个域成员 xpointers存放在 prev之前，也即实际 __try增强版用的结构体如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
typedef struct _EXCEPTION_REGISTRATION PEXCEPTION_REGISTRATION;

struct _EXCEPTION_REGISTRATION{
    PEXCEPTION_POINTERS xpointers;
    struct _EXCEPTION_REGISTRATION *prev;
    void (*handler)(PEXCEPTION_RECORD, PEXCEPTION_REGISTRATION, PCONTEXT, PEXCEPTION_RECORD);
    struct scopetable_entry *scopetable;
    int trylevel;
    int _ebp;
};

相关的宏和结构
TRYLEVEL_NONE           equ     -1
TRYLEVEL_INVALID        equ     -2

scopetable_entry
    +0x000 previousTryLevel : Uint4B
    +0x004 lpfnFilter       : Ptr32     int
    +0x008 lpfnHandler      : Ptr32     int

Exception_Registration::scopetable是类型为 scopetable_entry的数组；

Exception_Registration::trylevel是数组下标，用来索引 scopetable的数组成员；

_ebp是包含该 _Exception_Registration结构体的函数的栈帧指针，对于没有 FPO优化的函数，一开头通常有个 push ebp的操作，_ebp的值就是被压入的 ebp的值。

原始版本中，每一对 触发异常-处理异常 都会有一个注册信息即 Exception_Registration_Record，也即 每一个 __try/__except(__finally)都对应一个 Exception_registration。

但实际不同，每个使用 __try/__except(__funally)的函数，不管其内部嵌套或反复使用多少 __try/ __except(__finally)都之注册一遍，即只讲一个 Exception_Registration挂入当前线程的异常链表中，（对于递归函数，每一次调用都会创建一个 Exception_Registration，并挂入线程的异常链表中）。

那如何处理函数内部出现的多个 __try/__except(__finally) 呢？这多个 __except 代码块的功能可能大不相同，而注册信息 EXCEPTION_REGISTRATION 中只能提供一个处理函数 handler，怎么办？

MSC 的做法是，MSC 提供一个处理函数，即 EXCEPTION_REGISTRATION::handler 被设置为 MSC 的某个函数，而不是程序猿提供的 __except 代码块。代码提供的多个 __except 块被存储在 EXCEPTION_REGISTRATION::scopetable 数组中。我们看看上面的 scopetable_entry 定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct _EH4_SCOPETABLE {
        DWORD GSCookieOffset;
        DWORD GSCookieXOROffset;
        DWORD EHCookieOffset;
        DWORD EHCookieXOROffset;
        _EH4_SCOPETABLE_RECORD ScopeRecord[1];
};

struct _EH4_SCOPETABLE_RECORD {
        DWORD EnclosingLevel;	//previousTryLevel
        long (*FilterFunc)();
        union {
            void (*HandlerAddress)();
            void (*FinallyFunc)(); 
    };
};

其中 scopetable_entry::lpfnHandler 就是程序猿提供的 __except 异常处理块代码。而 lpfnFilter 就是 __except 的过滤块代码。对于 __finally 代码块，其 lpfnFilter 被置为 NULL，lpfnHandler 就是其包含的代码块。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
VOID SimpleSeh()
{
    __try
    {  
    }  
    __except(ExceptionFilter_0(...))
    {  
                 ExceptCodeBlock_0;
    }  
          
     __try
     {
                  __try
                  {

                  }
                  __except(ExceptionFilter_1(...))
                 {
                           ExceptCodeBlock_1;

                 }
     }  
     __except(ExceptionFilter_2(...))
     {  

                   ExceptCodeBlock_2;

     }  
}

编译时，编译器会为 SimpleSeh分配一个 Exception_Registration和一个拥有3个成员的 scopetable数组，并将 Exception_Registration::scopetable 指向该数组（EXCEPTION_REGISTRATION::scopetable只是一个指针，不是数组）。按照 __try关键字出现的顺序，将对应的 __except/__finally出入数组：

1
2
3
4
5
6
7
8
scopetable[0].lpfnFilter = ExceptionFilter_0;
scopetable[0].lpfnHandler = ExceptCodeBlock_0;

scopetable[1].lpfnFilter = ExceptionFilter_1;
scopetable[1].lpfnHandler = ExceptCodeBlock_1;

scopetable[2].lpfnFilter = ExceptionFilter_2;
scopetable[2].lpfnHandler = ExceptCodeBlock_2;

根据之前讨论的流程：RtlRaiseException -> RtlDispatchException -> RtlpExecuteHandlerForException。

RtlpExecuteHandlerForException 会调用注册信息中的处理函数，即 EXCEPTION_REGISTRATION::handler。该函数是由 MSC 提供的，内部会依次调用 scopetable 中的 lpfnHandler。

例如 在14和15行之前触发异常，那应该先从 scopetable[2] 的 ExceptionFilter_2 开始执行，假设该函数返回 EXCEPTION_CONTINUE_SEARCH。那接下来应该是 scopetable[1]，假设 ExceptionFilter_1 也返回 EXCEPTION_CONTINUE_SEARCH。那么接下来是不是就应该轮到 scopetable[0] 了？不是。咱们再看看上面的伪代码，行14和行15之间的代码并没处于第一个 __try/__except 的范围中，该异常轮不到 scopetable[0] 来处理。那怎么办？SimpleSeh 执行的过程中怎么知道到 scopetable[1] 就应该停止？

MSC是通过 scoptable_entry::prviousTryLevel解决：

1
2
3
4
5
6
7
8
9
10
11
scopetable[0].previousTryLevel = TRYLEVEL_NONE;
scopetable[0].lpfnFilter = ExceptionFilter_0;
scopetable[0].lpfnHandler = ExceptCodeBlock_0;

scopetable[1].previousTryLevel = TRYLEVEL_NONE;
scopetable[1].lpfnFilter = ExceptionFilter_1;
scopetable[1].lpfnHandler = ExceptCodeBlock_1;

scopetable[2].previousTryLevel = 1;
scopetable[2].lpfnFilter = ExceptionFilter_2;
scopetable[2].lpfnHandler = ExceptCodeBlock_2;

scopetable_entry::previousTryLevel 包含的意思是“下一个该轮到数组下标为 previousTryLevel 的单元了”。当 scopetable_entry::previousTryLevel 等于 TRYLEVEL_NONE(-1) 时，就会停止遍历 scopetable。

此时，当14和15行之间触发异常时，首先遍历到 scopetable[2]，处理完后，找到 scopetable[2].previousTryLevel，发现其值为1，那么遍历到 scopetable[1]，处理完后，找到 scopetable[1].previousTryLevel，发现其值为 TRYLEVEL_NONE，于是停止遍历。

如果行4和行5之间触发了同样的异常，执行流程应该如何。首先，执行 scopetable[2]，然后在 scopetable[1]。但显然不对，这次的异常是在第一个 __try/__except 中触发的，轮不到 scopetable[2] 来处理，怎么办？

这个时候就需要使用 EXCEPTION_REGISTRATION::trylevel ，其的作用就是标识从那个数组单元开始遍历。

与 scopetable_entry::previousTryLevel 不同，EXCEPTION_REGISTRATION::trylevel 是动态变化的，也就是说，这个值在 SimpleSeh 执行过程中是会经常改变的。比如，

  1. 执行到行4和行5之间，该值就会被修改为0；

  2. 执行到第12行，该值被修改为1；

  3. 执行到14行，该值为2。

这样，当异常触发时候，MSC 就能正确的遍历 scopetable 了。

图如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
  4G   |--------------------------|        ...

       |  ...                     |         |

   --> |--------------------------|         |

  /    | ret_addr                 |         |

func1  | _EXCEPTION_REGISTRATION  |    _EXCEPTION_REGISTRATION                    /  previousTryLevel = TRYLEVEL_NONE        \

  \    | ...                      |         |                    -> scopetable[0] |  lpfnFilter       = ExceptionFilter_0    |

   --> |--------------------------|         |                   /                 \  lpfnHandler      = ExceptionCodeBlock_0 /

  /    | ret_addr                 |         |                  /                  /  previousTryLevel = TRYLEVEL_NONE        \   <-

func2  | _EXCEPTION_REGISTRATION  |    _EXCEPTION_REGISTRATION      scopetable[1] |  lpfnFilter       = ExceptionFilter_1    |    |

  \    | ...                      |         |                  \                  \  lpfnHandler      = ExceptionCodeBlock_1 /    |

   --> |--------------------------|         |                   \                 /  previousTryLevel = 1                    \   -^

  /    | ret_addr                 |         |                    -> scopetable[2] |  lpfnFilter       = ExceptionFilter_2    |

func3  | _EXCEPTION_REGISTRATION  |    _EXCEPTION_REGISTRATION                    \  lpfnHandler      = ExceptionCodeBlock_2 /

  \    | ...                      |         |

   --> |--------------------------|         |

  /    | ret_addr                 |         |

func4  | _EXCEPTION_REGISTRATION  |    _EXCEPTION_REGISTRATION

  \    | ...                      |           ^

   --> |                          |           |

       |                          |         FS:[0]

  0 -> |--------------------------|

该图函数关系为 func1->func2->func3->func4

真实代码分析，分为三块：SEH创建代码，MSC提供的 handler函数，以及展开函数。

首先宏和结构体如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#define EXCEPTION_NONCONTINUABLE 0x1    // Noncontinuable exception
#define EXCEPTION_UNWINDING 0x2         // Unwind is in progress
#define EXCEPTION_EXIT_UNWIND 0x4       // Exit unwind is in progress
#define EXCEPTION_STACK_INVALID 0x8     // Stack out of limits or unaligned
#define EXCEPTION_NESTED_CALL 0x10      // Nested exception handler call
#define EXCEPTION_TARGET_UNWIND 0x20    // Target unwind in progress
#define EXCEPTION_COLLIDED_UNWIND 0x40  // Collided exception handler call
#define EXCEPTION_UNWIND (EXCEPTION_UNWINDING | EXCEPTION_EXIT_UNWIND | \
                                                         EXCEPTION_TARGET_UNWIND | EXCEPTION_COLLIDED_UNWIND)


nt!_EXCEPTION_RECORD
   +0x000 ExceptionCode    : Int4B
   +0x004 ExceptionFlags   : Uint4B
   +0x008 ExceptionRecord  : Ptr32 _EXCEPTION_RECORD
   +0x00c ExceptionAddress : Ptr32 Void
   +0x010 NumberParameters : Uint4B
   +0x014 ExceptionInformation : [15] Uint4B


typedef enum _EXCEPTION_DISPOSITION {
    ExceptionContinueExecution,
    ExceptionContinueSearch,
    ExceptionNestedException,
    ExceptionCollidedUnwind
} EXCEPTION_DISPOSITION;


// scopetable_entry::lpfnFilter 的返回值，也就是 __except 过滤块的返回值
     #define EXCEPTION_EXECUTE_HANDLER       1
     #define EXCEPTION_CONTINUE_SEARCH       0
     #define EXCEPTION_CONTINUE_EXECUTION    -1

SEH创建代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
VOID SehTest()
{
    ULONG ulVal = 0;

    __try // 第一个 __try 域
    {
        ulVal = 0x11111111; // 最后一位为1表示“在 __try 代码块中”
    }
    __except(Filter_0())
    {
        ulVal = 0x11111110; // 最后一位为0表示“在 __except/__finally 代码块中”
    }

    __try // 第二个 __try 域
    {
        ulVal = 0x22222222;
        __try // 第三个 __try 域
        {
            ulVal = 0x33333333;
            *((ULONG*)NULL) = ulVal; // 触发异常
        }
        __finally
        {
            ulVal = 0x33333330;
        }
    }

    __except(Filter_2())
    {
        ulVal = 0x22222220;
    }

    return;
}

反汇编如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
kd> uf passthrough!SehTest
    ;PassThrough!SehTest 
	f8720040  mov     edi,edi
    f8720042  push    ebp             ; l_ExceptionRegistration->_ebp
    f8720043  mov     ebp,esp
    f8720045  push    0FFFFFFFEh      ; l_ExceptionRegistration->trylevel = TRYLEVEL_INVALID (-2)
    f8720047  push    offset PassThrough!__safe_se_handler_table+0x8 (f8721468)   ; l_ExceptionRegistration->scopetable
    f872004c  push    offset PassThrough!_except_handler4 (f8720390)              ; l_ExceptionRegistration->handler
    f8720051  mov     eax,dword ptr fs:[00000000h]
    f8720057  push    eax             ; _EXCEPTION_REGISTRATION::prev
    f8720058  add     esp,0FFFFFFF4h  ; 这里分配了 0xc 字节的栈空间，其中紧贴着 l_ExceptionRegistration->prev; 的4个字节存放着 l_ExceptionRegistration->xpointers
    f872005b  push    ebx
    f872005c  push    esi
    f872005d  push    edi
    f872005e  mov     eax,dword ptr [PassThrough!__security_cookie (f87220b0)]
    f8720063  xor     dword ptr [ebp-8],eax   ; 对 scopetable 进行异或加密
    f8720066  xor     eax,ebp                 ; 对 __security_cookie 进行加密
    f8720068  push    eax                     ; 把加密了的 __security_cookie 也压入栈中，后面用来对 scopetable 进行解密
    f8720069  lea     eax,[ebp-10h]
    f872006c  mov     dword ptr fs:[00000000h],eax    ; 将 l_ExceptionRegistration 挂入线程异常链表中
    f8720072  mov     dword ptr [ebp-18h],esp
    f8720075  mov     dword ptr [ebp-1Ch],0
    f872007c  mov     dword ptr [ebp-4],0             ; 进入第一个 __try 域，l_ExceptionRegistration->trylevel = 0
    f8720083  mov     dword ptr [ebp-1Ch],11111111h
    f872008a  mov     dword ptr [ebp-4],0FFFFFFFEh    ; 离开第一个 __try 域，l_ExceptionRegistration->trylevel = TRYLEVEL_NONE (-2)
            ; ---------------------------------------------------------------------------------
            ; 这里有个空洞，用 uf 命令是不会显示的。范围是 f8720093 到 f87200a9，汇编码如下
            ; PassThrough!SehTest+0x53 [d:\workspace\code\mycode\r0\passthrough\passthrough.c @ 611]:
            ; f8720093  call    PassThrough!Filter_0 (f8720010)
            ; f8720098  ret
            ; f8720099  mov     esp,dword ptr [ebp-18h]         ; 第一个 __except 处理域
            ; f872009c  mov     dword ptr [ebp-1Ch],11111110h
            ; f87200a3  mov     dword ptr [ebp-4],0FFFFFFFEh    ; 离开第一个 __try 域，l_ExceptionRegistration->trylevel = TRYLEVEL_NONE (-2)
            ; ---------------------------------------------------------------------------------
        ;PassThrough!SehTest+0x6a [d:\workspace\code\mycode\r0\passthrough\passthrough.c @ 616]:
          f87200aa  mov     dword ptr [ebp-4],1             ; 进入第二个 __try 域，l_ExceptionRegistration->trylevel = 1
          f87200b1  mov     dword ptr [ebp-1Ch],22222222h
          f87200b8  mov     dword ptr [ebp-4],2             ; 进入第三个 __try 域，l_ExceptionRegistration->trylevel = 2
          f87200bf  mov     dword ptr [ebp-1Ch],33333333h
          f87200c6  mov     eax,dword ptr [ebp-1Ch]
          f87200c9  mov     dword ptr ds:[00000000h],eax    ; 触发异常
          f87200ce  mov     dword ptr [ebp-4],1             ; 离开第三个 __try 域，l_ExceptionRegistration->trylevel = 1
          f87200d5  call    PassThrough!SehTest+0x9c (f87200dc)
          f87200da  jmp     PassThrough!SehTest+0xa4 (f87200e4)
            ; ---------------------------------------------------------------------------------
            ; ---------------------------------------------------------------------------------
            ; 空洞，范围是 f87200dc 到 f87200e3，汇编码如下
            ; 
            ; PassThrough!SehTest+0x9c [d:\workspace\code\mycode\r0\passthrough\passthrough.c @ 628]:
            ; f87200dc c745e430333333  mov     dword ptr [ebp-1Ch],33333330h    ; __finally 域
            ; ---------------------------------------------------------------------------------
        ;PassThrough!SehTest+0xa4 [d:\workspace\code\mycode\r0\passthrough\passthrough.c @ 630]:

          f87200e4  mov     dword ptr [ebp-4],0FFFFFFFEh    ; 离开第二个 __try 域，l_ExceptionRegistration->trylevel = TRYLEVEL_NONE (-2)

          f87200eb  jmp     PassThrough!SehTest+0xc4 (f8720104)

            ; ---------------------------------------------------------------------------------
            ; 空洞，范围是 f87200ed 到 f8720103，汇编码如下
            ; 
            ; PassThrough!SehTest+0xad [d:\workspace\code\mycode\r0\passthrough\passthrough.c @ 631]:
            ; f87200ed e83effffff      call    PassThrough!Filter_2 (f8720030)
            ; f87200f2 c3              ret
            ;
            ; f87200f3 8b65e8          mov     esp,dword ptr [ebp-18h]          ; 第二个 __except 处理域
            ; f87200f6 c745e420222222  mov     dword ptr [ebp-1Ch],22222220h
            ; f87200fd c745fcfeffffff  mov     dword ptr [ebp-4],0FFFFFFFEh     ; 离开第三个 __try 域，l_ExceptionRegistration->trylevel = TRYLEVEL_NONE (-2)
            ; ---------------------------------------------------------------------------------
        ;PassThrough!SehTest+0xc4 [d:\workspace\code\mycode\r0\passthrough\passthrough.c @ 637]:
          f8720104  mov     ecx,dword ptr [ebp-10h]
          f8720107  mov     dword ptr fs:[0],ecx            ; 恢复旧的 EXCEPTION_REGISTRATION。即从线程异常链表中摘除 l_ExceptionRegistration
          f872010e  pop     ecx
          f872010f  pop     edi
          f8720110  pop     esi
          f8720111  pop     ebx
          f8720112  mov     esp,ebp
          f8720114  pop     ebp
          f8720115  ret

最后 scopetable内容如下：

1
2
3
4
5
6
7
8
9
kd> dd f8721468
    f8721468  fffffffe 00000000 ffffffd4 00000000  < 16个字节的坑
    f8721478  [fffffffe f8720093 f8720099] [fffffffe
    f8721488  f87200ed f87200f3] [00000001 00000000
    f8721498  f87200dc] 00000000 00000000 00000000
    f87214a8  00000000 00000000 00000000 00000000
    f87214b8  00000000 00000000 00000000 00000000
    f87214c8  00000000 00000000 00000000 00000000
    f87214d8  00000000 00000000 00000000 00000000

前 16 字节用于其他作用，之后就是三个 scopetable_entry，使用大括号标记。对照前面的汇编代码可以发现，scopetable_entry::lpfnFilter和 scopetable_entry::lpfnHandler就是汇编中的空洞处的代码。其中，第三个 scopetable_entry::lpnFilter是 NULL，是因为这是一个 __try & __finally块，没有 lpfnFilter。

这里需要特别注意两点：

  • Exception_Registration::scopetable 指针被 __security_entry进行了异或加密
  • Exception_Registration::scopetable并不直接指向 scopetable_entry数组，在第一个 scopetable_entry之前有 16 个字节，其主要作用是帮助验证 scopetable是否被破坏。第三个 DWORD，即上文中的 ffffffd4是一个偏移量，后续会讲

MSC提供的 EXCEPTION_REGISTRATION::handler

EXCEPTION_REGISTRATION::handler指向由 MSC编译器提供的一个函数，这个函数内部负责调用 scopetable[?]->lpfnFilter/lpfnHandler。这个函数通常为 module!__except_handler，其中 module为模块名，?表示某数字。

这里的 __except_handler4的原型如下：

1
2
3
4
5
6
EXCEPTION_DISPOSITION _except_handler4 (
    PEXCEPTION_RECORD pExceptionRecord,
    PEXCEPTION_REGISTRATION pExceptionRegistration,
    PCONTEXT,
    PDISPATCHER_CONTEXT
);

反汇编代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
kd> uf PassThrough!_except_handler4
   PassThrough!_except_handler4
    f8720390  mov     edi,edi
    f8720392  push    ebp
    f8720393  mov     ebp,esp
    f8720395  sub     esp,14h
    f8720398  push    ebx
    f8720399  mov     ebx,dword ptr [ebp+0Ch] ; ebx = pExceptionRegistration
    f872039c  push    esi
    f872039d  mov     esi,dword ptr [ebx+8]   ; esi = pExceptionRegistration->scopetable
    f87203a0  xor     esi,dword ptr [PassThrough!__security_cookie (f87220b0)]    ; 用 __security_cookie 对 scopetable 解密
    f87203a6  push    edi
    f87203a7  mov     eax,dword ptr [esi]
    f87203a9  mov     byte ptr [ebp-1],0   ; ebp-1 存放的是一个 BOOLEAN 值，用来表示是否执行过任何 scopetable_entry::lpfnFilter
    f87203ad  mov     dword ptr [ebp-8],1  ; ebp-8 被用来存放本函数的返回值，这里初始化为 ExceptionContinueSearch (1)
    f87203b4  lea     edi,[ebx+10h]        ; edi = pExceptionRegistration->_ebp
    f87203b7  cmp     eax,0FFFFFFFEh       ; 检查 scopetable 中坑的第一个 DWORD 值，后续来做相关的安全处理
<   f87203ba  je      PassThrough!_except_handler4+0x39 (f87203c9)

  PassThrough!_except_handler4+0x2c 
; 校验 scopetable 完整性（1）
    f87203bc  mov     ecx,dword ptr [esi+4]
    f87203bf  add     ecx,edi
    f87203c1  xor     ecx,dword ptr [eax+edi]
    f87203c4  call    PassThrough!__security_check_cookie (f8720638)

 PassThrough!_except_handler4+0x39 
; 校验 scopetable 完整性（2）
>   f87203c9  mov     ecx,dword ptr [esi+0Ch]
    f87203cc  mov     eax,dword ptr [esi+8]
    f87203cf  add     ecx,edi
    f87203d1  xor     ecx,dword ptr [eax+edi]
    f87203d4  call    PassThrough!__security_check_cookie (f8720638)

; 安全工作处理完毕，开始进入异常处理流程
    f87203d9  mov     eax,dword ptr [ebp+8]     ; eax = pExceptionRecord
    f87203dc  test    byte ptr [eax+4],66h      ; pExceptionRecord->ExceptionFlags & EXCEPTION_UNWIND，判断是异常处理过程还是展开过程
<   f87203e0  jne     PassThrough!_except_handler4+0x138 (f87204c8)

//后续为异常处理过程
...

函数代码不长，分为两大分支：一个分支处理异常，一个分支处理展开。处理异常的代码负责遍历 scopetable，依次调用 scopetable_entry::lpfnFilter，并针对不同的返回值做出不同的处理：

  1. 返回 Exception_Continue_execution，说明异常已经被调用的 lpfnFilter修复，返回 ExceptionContinueExecution
  2. 返回 Exception_Continue_Search，则继续遍历下一个 scopetable_entry
  3. 返回 Exception_Execute_Handler，则说明当前 scopetable_entry::lpfnHandler负责处理该异常，于是调用它。

一旦有某 scopetable_entry::lpfnFilter返回 EXCEPTION_EXECUTE_HANDLER，就会进行全局展开和局部展开。展开结束后会调用该 scopetable_entry::lpfnHandler，该函数即为 _except处理域，该函数形式是一个函数，实际上只是一段不返回的代码。即这段代码中没有 ret指令，执行完整个 _except处理域后，会接着执行其后的指令，并不会返回 _except_handler4。

_except_handler4在执行的过程中可能会调用这几个函数：

​ _EH4_CallFilterFunc 负责调用 scopetable_entry::lpfnFilter；

​ _EH4_TransferToHandler 负责调用 scopetable_entry::lpfnHandler；

​ _EH4_GlobalUnwind 负责全局展开；

​ _EH4_LocalUnwind 负责局部展开。

_EH4_CallFilterFunc和 _EH4_TransferToHandler的反汇编代码，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
kd> uf PassThrough!_EH4_CallFilterFunc
    PassThrough!_EH4_CallFilterFunc 
	f87205d1  push    ebp
    f87205d2  push    esi
    f87205d3  push    edi
    f87205d4  push    ebx
    f87205d5  mov     ebp,edx
    f87205d7  xor     eax,eax
    f87205d9  xor     ebx,ebx
    f87205db  xor     edx,edx
    f87205dd  xor     esi,esi
    f87205df  xor     edi,edi
    f87205e1  call    ecx ; lpfnFilter();
    f87205e3  pop     ebx
    f87205e4  pop     edi
    f87205e5  pop     esi
    f87205e6  pop     ebp
    f87205e7  ret

kd> uf PassThrough!_EH4_TransferToHandler
    PassThrough!_EH4_TransferToHandler 
    f87205e8  mov     ebp,edx
    f87205ea  mov     esi,ecx ; esi = lpfnHandler
    f87205ec  mov     eax,ecx
    f87205ee  xor     eax,eax
    f87205f0  xor     ebx,ebx
    f87205f2  xor     ecx,ecx
    f87205f4  xor     edx,edx
    f87205f6  xor     edi,edi
    f87205f8  jmp     esi     ; jmp lpfnHandler

展开

我们假设一系列使用 SEH 的函数调用流程：func1 -> func2 -> func3。在 func3 执行的过程中触发了异常。

分发异常流程 RtlRaiseException -> RtlDispatchException -> RtlpExecuteHandlerForException，RtlDispatchException 会遍历异常链表，对每个 EXCEPTION_REGISTRATION 都调用 RtlpExecuteHandlerForException，RtlpExecuteHandlerForException 会调用 EXCEPTION_REGISTRATION::handler，也就是 _except_handler4。如上面分析，该函数内部遍历 EXCEPTION_REGISTRATION::scopetable，如果遇到有 scopetable_entry::lpfnFilter 返回 EXCEPTION_EXECUTE_HANDLER，那么 scopetable_entry::lpfnHandler 就会被调用，来处理该异常。

因为 lpfnHandler 不会返回到 _except_handler4，于是执行完 lpfnHandler 后，就会从 lpfnHandler 之后的代码继续执行下去。也就是说，假设 func3 中触发了一个异常，该异常被 func1 中的 __except 处理块处理了，那 __except 处理块执行完毕后，就从其后的指令继续执行下去，即异常处理完毕后，接着执行的就是 func1 的代码。不会再回到 func2 或者 func3，这样就有个问题，func2 和 func3 中占用的资源怎么办？这些资源比如申请的内存是不会自动释放的，岂不是会有资源泄漏问题？

这个问题就需要利用展开来解决，展开就是进行清理，包括动态分配的资源的清理，栈空间是由 func1的 mov esp, ebp这类操作顺手清理。那么展开工作由谁来完成，这里就需要交给触发异常的函数自己来完成。

展开分为两种：全局展开和局部展开

全局展开是指针对异常链表中的某一段，局部展开针对指定EXCEPTION_REGISTRATION。用上面的例子来讲，局部展开就是针对 func3 或 func2 （某一个函数）内部进行清理，全局展开就是 func2 和 func3 的局部清理的总和。再归纳一下，局部展开是指具体某一函数内部的清理，而全局展开是指，从异常触发点（func3）到异常处理点（func1）之间所有函数（包含异常触发点 func3）的局部清理的总和。

全局展开汇编代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
kd> uf PassThrough!_EH4_GlobalUnwind
 PassThrough!_EH4_GlobalUnwind 
	f87205fa   push    ebp
    f87205fb   mov     ebp,esp
    f87205fd   push    ebx
    f87205fe   push    esi
    f87205ff   push    edi
    f8720600   push    0   ; pReturnValue
    f8720602   push    0   ; pExceptionRecord
    f8720604   push    offset PassThrough!_EH4_GlobalUnwind+0x15 (f872060f) ; pReturnEip
    f8720609   push    ecx ; pExceptionRegistration
    f872060a   call    PassThrough!RtlUnwind (f8720678)
    f872060f   pop     edi
    f8720610   pop     esi
    f8720611   pop     ebx
    f8720612   pop     ebp
    f8720613   ret

RtlUnwind 的原型：
VOID RtlUnwind(
    PEXCEPTION_REGISTRATION pExceptionRegistration
    PVOID pReturnEip
    PEXCEPTION_RECORD pExceptionRecord,
    PVOID pReturnValue
);

这里的全部汇编可以参考原文，总结如下：从异常链表头开始遍历，一直遍历到指定 EXCEPTION_REGISTRATION_RECORD，对每个遍历到的 EXCEPTION_REGISTRATION_RECORD，执行 RtlpExecuteHandlerForUnwind 进行局部展开。

局部展开： 在 _except_handler4中，有提到该函数既负责处理异常也负责局部展开，其区分功能的标志就是判断 EXCEPTION_RECORD::ExceptionFlags是否包含 EXCEPTION_UNWIND标志位：

1
2
3
4
5
f87203dc  test    byte ptr [eax+4],66h      ; pExceptionRecord->ExceptionFlags & EXCEPTION_UNWIND，判断是异常处理过程还是展开过程

该标志是在 RtlUnwind 中被设置的，可以参考 RtlUnwind 中地址为 808673b7 和 808673bd 出的指令：
808673b7  or      dword ptr [esi+4],2 ; l_ExceptionRecord.ExceptionFlags |= EXCEPTION_UNWINDING (0x2)
808673bd  or      dword ptr [esi+4],6 ; l_ExceptionRecord.ExceptionFlags |= EXCEPTION_UNWINDING | EXCEPTION_EXIT_UNWIND (0x2 | 0x4)

局部展开具体汇编代码可以参考原文。

这里总结下处理异常和展开过程中涉及到的遍历操作：

  1. 在异常处理过程中，每个异常都至少会遍历异常链表两次（如果发生嵌套一行，比如展开过程中，又触发异常，则会遍历更多次）。一次是 RtlDispatchException中，遍历的目的是找到愿意处理该异常的 _Exception_registration_record；另一次是在展开过程中，RtlUnwind函数内，遍历的目录是为了对每个遍历到的 Exception_Registration_record进行局部展开
  2. 每个 scopetable也会被遍历至少两次，一次是在 __except_handler中，遍历的目的是找到愿意处理该异常的 scopetable_entry。另一次是在展开过程 _local_unwind4函数内，目的是找到所有指定范围内的 scopetable_entry::lpfnFilter为 NULL的 scopetable_entry 调用其 lpfnHandler即 __finally处理块

VEH

VEH是一个全局链表，全名为Vectored Exception Handler，这个全局链表里面存放的异常处理函数可以过滤所有线程产生的异常，其处理函数的原型如下：

1
2
3
4
typedef LONG  
(NTAPI *PVECTORED_EXCEPTION_HANDLER)(  
    struct _EXCEPTION_POINTERS *ExceptionInfo  
);

VEH的注册是通过API函数AddVectoredExceptionHandler进行注册的，他比SEH拥有更优先的级别过滤异常。其原型如下：

1
WINBASEAPI PVOID WINAPI AddVectoredExceptionHandler(ULONG FirtstHandler,PVECTORED_EXCEPTION_HANDLER VectoreHandler)

第一个参数是一个标志位，表示注册的回调函数是在链表的头还是尾，0是插入尾部，非0是插入头部。第二个参数是回调函数的地址，返回一个VectoredHandlerHandle，用于之后卸载回调函数。回调函数原型：

1
LONG CALLBACK Vectorhandler()

在RltDispatchException的过程中VEH将会优先于SHE调用，若回调函数解决的问题和SEH相似，都会返回ExceptionContinueExcution表示处理完毕。然后借助CONTEXT的内容恢复上下文，跳过SEH继续执行程序，如果失败了就遍历VEH链表寻找解决方法，如果所有的回调函数都不能处理的话再将执行权归还，继续向下执行SEH的相关内容。

0x4 Windbg异常调试

已注册异常

我们以 Adobe Reader为例，来调试Windows异常处理。

当我们使用 Adobe Reader 打开一个有字体错误的 PDF时，Adobe Reader会弹出错误窗口，提示发生字体错误。

当我们使用Windbg调试时，程序首先会停在 KernelBase!RaiseException，我们查看调用堆栈，如下所示。

image-20200801172038310

image-20200801182745914

我们查看一下发生异常的地址，如下所示：

image-20200801182717026

根据IDA函数名，我们能大概判断出此处为程序通过 Throw 抛出了一个异常。使得程序进入了 RaiseException异常处理。

然后进入了 ntdll!RaiseException，开始处理异常。

image-20200801172154119

最后程序弹出了，错误窗口，如下所示：

image-20200801185650748

未处理异常

我以 Adobe Reader的漏洞cve-2010-2883调试为例，说明Windows的异常处理流程。

CVE-2010-2883是一个发生在Adobe Reader上的栈溢出漏洞，在当前Windows10环境下，由于内存堆布局的变化，原有POC样本在Windows10下实现堆喷时，并不会将ROP数据准确喷到 0x0c0c0c0c下，所以在执行到ROP时会导致内存访问错误。

我们在程序漏洞点处下断点：0x808b062处，可以看到该指令处的 虚表指针已经被改为一个 ROP地址，0x4a80cb38 是Adobe Reader一个未使用ASLR的icucnv38.dll的ROP地址。

img

在执行该指令后，程序马上将会触发非法访问内存错误。我们在 ntdll!KiUserExceptionDispatcher 和 ntdll!RtlDispatchException 以及 最后的 KernelBase!UnhandledExceptionFilter下断点。

首先程序触发异常之后，我们的 调试器会接管异常。我们直接继续运行，走系统的异常处理 流程。

image-20200801164613928

那么程序流程将会直接跳转到 ntdll!KiUserExceptionDispatcher，由于此时的Windbg在用户态调试，所以内核执行的部分会被直接忽略。也就是我们的异常 被分发到用户态下处理。

image-20200801132927499

然后会在ntdll!KiUserExceptionDispatcher中跳入 ntdll!RtlDispatchException 执行 VEH 和 SEH。此时，我们可以查看一下程序的 SEH链，如下所示：

image-20200801165035332

当系统 遍历 VEH 和 SEH 链表，不能够处理该异常时。那么系统就会去执行 SEH链表的最后一项 UnhandledExceptionFilter来处理异常。

image-20200801132956531

同时，我们可以看到其实在Adobe Reader发生漏洞的CoolType.dll 内是有注册 UnhandledExceptionFilter函数处理过程。下图是我们在 Windbg 中会看到程序最后会执行 GetCurrentProcess 和 TerminateProcess函数。

image-20200801161109757

我们在CoolType.dll 反汇编中 中也可以看到关于 UnhandleExceptionFilter 的注册 以及处理步骤。

image-20200801164419288

Windbg 中最后就在 TerminateProcess() 后结束，Adobe Reader最终退出。

image-20200801164503275

0x5 总结

本次对于Windows异常处理机制，主要是对异常处理时几个标志性函数进行了学习和调试。对于内核的处理，以及异常处理的详细流程并没有进行过多总结。感觉自己对于Windbg 的使用还是不够到位，某些关键步骤没有能够跟踪到，以后还要加强学习吧

参考文献

异常分类： Windows调试——从0开始的异常处理（上）

https://www.anquanke.com/post/id/175293

异常分发：Windows异常处理核心原理

​ https://blog.csdn.net/qq_42208826/article/details/85321301

SEH和VEH：Windows调试艺术——从0开始的异常处理

​ https://www.anquanke.com/post/id/175753#h2-0

异常处理： windows 异常处理

​ https://blog.csdn.net/lanuage/article/details/52225201

​ Windows用户态异常处理

​ https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2014/03/31/windows-user-exception

赏

只要你支持她，我们就是好朋友2333

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主要研究：
二进制安全、漏洞挖掘
CTF菜鸡一只

天枢Dubhe 学习ing