seh机制的逆向

一、SEH 机制逆向探秘 （一）实验测试环境 由于 SEH 机制与调试器有关，所以我们必须使用 relese 版本 测试平台：虚拟机 VM9，,Win Xp Sp3 系统、VC6.0 （二）源代码的分析+高级代码级 SEH 机制分析 （1 ）源代码分析 代码中使用_try_except()结构来构造并处理一个异常。 其中： _try 结构中的代码是正常功能的代码，也就是原本需要侦听、测试的代码。 我们在其中构造了一个除零异常。 _except 结构中调用了（安装了）一个异常处理函数。来对_try 结构中的 异常进行处理。 （但未处理掉） （2 ）从宏观来理解异常处理机制 运行程序，此时会弹出 Messagebox，验证了 MyExceptionhandler()捕 捉到了异常，并首先去处理了异常，所以弹出了 Messagebox。 我们点确定，则会出现异常提示框。这是由于此 MyExceptionhandler() 函数未能处理这个异常，所以最后调用系统默认的异常结构来处理异常。 我们在 MyExceptionhandler()中加上 exit（0）函数，运行，弹出 messagebox 后点击确定，程序正常退出。没有弹出异常提示框。这是由于 MyExceptionhandler()首先处理异常时，直接退出了程序，系统默认异常并 未得到调用。 （三）逆向（汇编代码级）分析 SEH 机制 下面我们通过分析汇编代码，来看 SEH 机制的内部细节。 1、SEH 结构的安装 （1 ）首先载入程序，发现栈底附近已经有个一个 SEH 结构，这就是系统 默认的 SEH 结构，其中 0x7xxxxx 就是实现异常对话框弹出并退出程序功能的！ （2 ）我们看到程序载入处就是一个 SEH 安装，这就是当线程初始化时， 系统会自动向栈中安装一个 SEH,作为线程的默认异常处理。之后就是正常的程 序初始化了。 （3 ）找到 test 函数，发现，进入 test 函数后，程序首先安装了一个 SEH 结构，这个结构就是我们使用_try_except 结构安装的线程异常处理结构。 在汇编中，SEH 结构的安装使用以下结构： 在 test 函数中的 SEH 安装后，我们打开查看-SEH 链可以看到当前的 SEH 链表。对于这个链表，我们分析。第一个是写的，第二个是线程默认的，最后 一个是系统默认的。当出现异常时，系统就会按照这个顺序调用异常处理函数， 对异常进行处理。 2、触发异常后（IDIV ECX 指令） ，系统的动作。 此时系统会捕捉到异常，从而将程序的控制权交给系统。也就是说转入系 统领空。 （需要说明一点：在破解 crackme 时，一般进入系统后，我们都是很快 回到程序领空，但在系统机制的逆向中，我们必须在系统领空中去分析！ ！） 程序转到这，系统领空。 （1 ）在这里，系统第一步做的是：保存当前环境。即，将程序出现异常时 的环境保存起来（保存到系统栈中） push ecx 和 push ebx，前者将 EXCEPTION_RECORD 结构入栈 EXCEPTION_RECORD 结构： 其中第一个参数是异常代码 0xC0000094 表示是除零错误。后面的参数依 次对应。 后者是 CONTEXT 结构： 比如偏移 0X9C 处保存 EDI 寄存器的值，我们可以查看一下： 这些结构会在调用异常处理函数时当做参数传递给异常处理函数。后面会 看到！ （2 ）在系统领空中继续跟踪，知道出现异常，如此往复。！ 0x7C92E465-0x7C94A9EA-0x7C923275 经过几层调用，找到了异常处理函数的调用处。 （这几个函数的其他部分都是做什么的？） 我们分析 ECX 的值，发现就是我们安装的 SEH 结构的异常处理函数地址！ 异常处理函数的 4 个参数： 参数 1：pExcept：指向 EXCEPTION_RECORD 结构体 参数 2：pFrame：指向栈帧中的 SEH 结构体。即，即将调用的 SEH 结构的栈 地址 参数 3：pContext ：指向 Context 结构体。该结构体中包含所有寄存器的状 态。 参数 4：pDispatch:未知用途。 （3 ）此时进入第一个异常处理函数地方。 进入第一个异常处理函数地方，回到了程序领空。 往下执行，到 004011FF CALL DWORD PTR DS:EDI+ECX*4+4 ; 这时，进入就是我们具体的异常处理代码（进入 MyExceptionhandler()中进 行异常处理） ，弹出 messagebox。所以，我们可知，系统调用的第一个异常 处理结构是线程的，也就是使用_try_except 结构安装的。 （4 ）处理完后，如果这个处理函数没能将异常处理完，则继续进入系统领空进 行下一个 SEH 结构的调用。控制权又回到系统手中。 系统继续进行相同的处理，只不过此次调用的异常处理 SEH 成为下一个 SEH，具体可比对系统调用异常处理函数的参数 2，发现其 SEH 地址明显成为 下一个 SEH 结构的地址。 （5 ）对线程默认的异常处理结构进行分析。 此时，进入的异常处理函数应该就是线程默认的异常处理过程。 继续跟进：004011FF CALL DWORD PTR DS:EDI+ECX*4+4 之后弹出如下 对话框： 原来，这个这个对话框是由默认的线程 SEH 结构弹出的。 这是为什么呢？经过跟踪发现原来是调用了 UnhandleExceptionFilter() 函数。也就是在系统处理异常前，提前线程先调用 UnhandleExceptionFilter()函 数，先给程序一次机会，问你是否使用调试器。 正如其所描述的一样，点击确定则程序终止，点击取消则进入调试。 如果点击确定，程序会毫不留情地终止，点击取消则进入调试。 （6 ）已经没有机会了，最后的处理！ 如果我们点击取消加载调试器后，调试器依然没有解决异常，则最后的系统默 认异常处理函数（0xFFFFFFFF 这个 SEH 结构体）就会被调用。其过程与前面完 全相同。参数 2 是 0xFFFFFFFF，而异常处理函数地址是： kernel32.7C839AC0 调用这个函数，其弹出： 这次系统不会给你任何改正的机会。直接通知你：系统出现异常，程序必 须终止！ 比较这两个默认的异常处理，可以发现第一次（线程）的 SEH 处理是为 了给系统最后的处理给一次调试的机会。不过逆向结果显示，二者最终都调用 的都是 UnhandleExceptionFilter()函数！ 总结 1、到这，此测试程序的异常处理机制完全分析完毕，我们可以很清楚地看 到当一个异常抛出时，系统是如何一步一步对异常进行处理的！ 2、由于没有使用 SetUnhandledExceptionFilter()函数对异常进行处理， 所以我们看到，这个异常处理过程中没有进程相关的异常处理！ 同时，也回答了上面的问题， “线程-进程-系统“这个过程不是必须的！ ！ 3、最后要说明的是：不要认为所有的异常处理都是这样的流程，其他的细 节，需要自己去逆向、去调试、去分析，比如：在系统找到恰当的处理异常的 函数后，会将前面调