0x000050，干货看这篇!基于异常的狩猎行为——自我保护触发自杀

0、介绍

这次分析的问题很有意义。软件的自我保护机制被触发抛出异常，在异常链处理中进行了简单的检测，命中再次产生了异常，也就是嵌套在异常中的异常，但最具挑战性的是如何找到事件第一现场，房子泄漏是烟夜雨，Windbg提供的商用命令集体罢工。

涉及到以下知识点：

1、命令失效时，如何手动在dmp中找到关键调用，关键数据；

2、如何手动重构栈帧，复原调用栈；

3、用户态异常分发的优先级及路径；

4、32位下，OS从内核分发至用户态时做的关键动作，64位下又有何区别；

5、嵌套的异常如何找到案发第一现场；

1、背景

周末闲居在家，老友发来求助信息，说是玩游戏玩的好好的，突然崩溃了，作为软件开发的他自然想探寻下crash的原因罗，通过Everything搜索了下电脑上的*.dmp，找到了本次游戏崩溃产生的dmp文件。题外话，游戏一般都会在crash时保存下dmp，并发送至后台处理，这里能找到也就不奇怪了。然后便祭出神器——Windbg开始分析，但由于各种原因诸如MiniDump，没有PDB，栈回溯失败，Windbg的很多自动化命令失效等等原因，没有分析各所以然出来，遂抛给了我，请我助其一臂之力，看看到底是啥子原因。分析之余，觉得挺有意思，撰文以分享之。

2、分析过程

2.1 step1：看一下异常记录，如下，为了规避哪款游戏，这里隐藏着与游戏相关的信息，包括游戏的各个模块名，代之以GameModule,GameExe这样的名字；

常规的异常，往空指针里写数据了；

2.2 step2：再看下异常上下文，如下：

与上边异常记录给的信息也是吻合的，但这条反汇编代码非常的奇怪，居然是硬编码好了的往0x00000000地址中写数据，这到底是在干嘛？看下附近的反汇编代码吧，看看在干什么，如下：

从上边反汇编出来的代码来看，有意思的还不仅仅是这一行代码，紧接着的下一行代码也是非常奇怪，死循环，在原地打转。越来越有趣了，简单分析下这段代码的功能：

首先，这个函数没有自己独立的栈帧，[esp+4]取出的便是第一个参数，而这个函数也只有一个参数，ret 4可以说明；当然这里边没有用到ecx，edx之类的寄存器，所以就排除了寄存器传参的可能性；

接着，80000003h这个数字有着特殊的含义的，正如C0000005h代表的是 EXCEPTION_ACCESS_VIOLATION，80000003h代表的是 EXCEPTION_BREAKPOINT;

这就更增加了问题的有趣性，显然这里是在判断当前异常是不是EXCEPTION_BREAKPOINT，不是的话直接返回0，什么也不干；否则的话则调用其他函数处理，然后再次触发写0x00000000地址，再次嵌套触发异常，触发自杀；我的第一反应是：游戏在做反调试的事情吗？但立马又否定了这个想法，原因很简单——如果当前进程处于调试状态，EXCEPTION_BREAKPOINT异常压根不会派遣给进程，调试器就给处理掉了。当然，我们也可以看下，进程是否被调试，如下：

这些证据都或多或少的证实着，当前的游戏进程没有被调试。[后边会专门写文章讲解异常是如何被CPU发现并转交给OS，OS又是如何确认是内核异常还是用户态异常，如果是用户态异常，OS又是如何分发给用户态进程的。]。先不着急回答这些问题，看下栈回溯，看看程序的执行路径；

2.3 step3：栈回溯，如下：

由于没有符号，当然也肯定不会有罗，所以回溯出来的栈可读性差，但不要紧，做逆向分析，不也这样的嘛。但这个栈不正常，这里还没有进入SEH的分发，而是在VEH就被拦截掉了；VHE的全称是Vectored Exception Handling，向量化异常处理，这个与SEH不太一样，且只能用在Ring3，是进程级别的，不像SEH是线程级别的，异常在分发时，先遍历VEH链，处理了则不会继续往后传递，没处理则继续后遍历，分发异常；我为什么说当前处于VEH呢？很简单，因为没有看见SEH的特征处理函数，哪怕是相关联的一点点函数调用的影子都没有，为了打消你的疑虑，我们来逆向分析下ntdll!RtlDispatchException的关键部分，这个函数很大，我们就看看774af15a返回地址附近的代码。

2.4 step4：逆向分析关键API的关键部分，如下：

会判断RtlpCallVectoredHandlers()的返回值，如果是0的话，则调用RtlpExecuteHandlerForException()，那么0是啥意思呢？且看下边的定义，返回0意味着继续分发异常，也就是RtlpExecuteHandlerForException()中做的勒，即遍历SEH链进行异常的分发，暂且按下不表。

回过头来看看上边游戏做的事情，如果不是EXCEPTION_BREAKPOINT则让异常继续分发，不做任何特殊处理，如果是EXCEPTION_BREAKPOINT的话，则没有接下来的事情了。简单分析下RtlpCallVectoredHandlers()即可知道OS是如何管理VEH的了，如下：

即通过ntdll!LdrpVectorHandlerList这个链表来管理每个Handler， AddVectoredExceptionHandler、 RemoveVectoredExceptionHandler分别往这个链表里增删项。

2.5 step5：寻找案发第一现场——分析起因

到目前为止，我们看见的所有的异常上下文，包括栈回溯，都是第二案发现场了，是”mov dword ptr ds:[00000000h],eax”这条指令触发的，它并不是最直接导致这次crash的罪魁祸首，顶多算个背锅的，自杀的罪名被他坐实了。按理说，如果嵌套了一次异常，那.cxr后执行k进行回溯的话，栈上应该有两个ntdll!KiUserExceptionDispatcher才对，我们看下现实的情况是怎样的：

what？？？这是啥，居然一个ntdll!KiUserExceptionDispatcher都没有，刚刚上边.ecxr之后的k看栈回溯不是还有一个ntdll!KiUserExceptionDispatcher的吗？怎么现在一个都没有了？这当然是Windbg在栈回溯时除了问题了，而且也经常会出问题，这也怪不得他，原因有很多，我们没有符号，dmp也是Minidump类型的，有的也是FPO的，它回溯起来肯定会有问题的。现在就有两个问题需要解决了，第一：上边出现的这个ntdll!KiUserExceptionDispatcher是第一案发现场还是。。。

第二：如果是第一案发现场，那第二案发现场的ntdll!KiUserExceptionDispatcher如何找出来；

我们再用下Windbg提供的其他两个很厉害的命令来找ntdll!KiUserExceptionDispatcher，看看能不能揪出来，如下:

很遗憾，这些命令集体哑火，啥帮助也没有，我们要开始靠自己的双手来掘金了，使用dps来做，输出的太多了，简单整理下如下所示：