SEH异常之编译器原理探究

字数统计: 1.9k字   |   阅读时长≈ 7分

我们在之前已经了解了VEH和SEH异常，在这里我们来深入探究一下编译器为我们提供的’_try_except’和’_try_finally’的原理实现。

0x00 前言

我们在之前已经了解了VEH和SEH异常，在这里我们来深入探究一下编译器为我们提供的_try_except和_try_finally的原理实现。

0x01 _try_except原理

image-20220329091038461.png

调用_except_handle3这个异常处理函数，这里并不是每个编译器的异常处理函数都是相同的，然后存入结构体，将esp的值赋给fs:[0]，再就是提升堆栈的操作

image-20220328203820634.png

每个使用 _try _except的函数，不管其内部嵌套或反复使用多少_try _except，都只注册一遍，即只将一个 _EXCEPTION_REGISTRATION_RECORD挂入当前线程的异常链表中(对于递归函数，每一次调用都会创建一个 _EXCEPTION_REGISTRATION_RECORD，并挂入线程的异常链表中)。

typedef struct _EXCEPTION_REGISTRATION_RECORD {
struct _EXCEPTION_REGISTRATION_RECORD *Next;
PEXCEPTION_ROUTINE Handler;
  } EXCEPTION_REGISTRATION_RECORD;

可以看到只有一个异常处理函数

image-20220328204334138.png

那么这里编译器是如何做到只用一个异常处理函数的呢？编译器把原来_EXCEPTION_REGISTRATION_RECORD结构进行了拓展，添加了三个成员

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

新堆栈结构如下
image-20220328205626354.png

scopetable

struct scopetable_entry
{
   DWORDpreviousTryLevel//上一个try{}结构编号 
   PDWRDlpfnFilter  //过滤函数的起始地址
   PDWRDlpfnHandler //异常处理程序的地址 
}

查看地址可以发现有三个结构体

image-20220328210620793.png

存储着的正式异常函数的开始地址和结束地址

image-20220328210921516.png

第一个值previousTryLevel是上一个try结构的编号，这里如果在最外层就是-1，如果在第二层就是0，如果在第三层就是1，以此类推

image-20220328211441617.png

image-20220328211431096.png

trylevel

该成员表示代码运行到了哪个try结构里面，进入一个try则加1，try结构执行完成之后则减1

image-20220328212928168.png

image-20220328213102558.png

_except_handler3

1.CPU检测到异常 -> 查中断表执行处理函数 -> CommonDispatchException -> KiDispatchException -> KiUserExceptionDispatcher -> RtlDispatchException ->VEH -> SEH

2.执行_except_handler3函数

<1> 根据trylevel选择scopetable数组

<2> 调用scopetable数组中对应的lpfnFilter函数

1.EXCEPTION_EXECUTE_HANDLER(1) 执行except代码

2.EXCEPTION_CONTINUE_SEARCH(0) 寻找下一个

3.EXCEPTION_CONTINUE_EXECUTION(-1) 重新执行

<3> 如果lpfnFilter函数返回0 向上遍历 直到previousTryLevel=-1

假设有两个异常点

image-20220328214631447.png

首先找到trylevel为0

image-20220328214712048.png

然后找到异常过滤表达式为1

image-20220328214828859.png

然后遍历数组的lpfnFilter

image-20220328214920905.png

image-20220328215004575.png

如果返回值为1则调用异常处理函数，如果为0则该异常函数不处理，如果为-1则继续从原异常点向下执行

image-20220328215147660.png

image-20220328215136933.png

假设在B这个地方出异常，得到trylevel为2

image-20220328215213691.png

那么这里就回去遍历lpfnFilter为2的地方

image-20220328215328118.png

假设这里返回值为0，则继续查找，注意这个地方是向上查找，首先判断当前previousTryLevel的值是否为-1，如果为-1就停止查找(-1代表已经是最外层)try结构，然后再向上找，假设这里返回值仍然为0，判断previousTryLevel的值为-1，就停止查找，没有找到响应的异常处理函数

image-20220328215543352.png

0x02 _try_finally原理

无论try结构体中是什么代码，都会执行finally里面的代码

// SEH6.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
VOID ExceptionTest()
{
__try
{
return;
printf("Other code");
}
__finally
{
printf("Must run this code");
}
}
int main(int argc, char* argv[])
{
ExceptionTest();
getchar();
return 0;
}

image-20220329091038461.png

局部展开

当try里面没有异常，而是return、continue、break等语句时，就不会走_except_handle3这个函数，而是调用_local_unwind2进行展开

image-20220329091558879.png

然后调用[ebx + esi*4 + 8]

image-20220329091914211.png

跟进去就到了finally语句块的地方

image-20220329092006412.png

我们探究一下实现的原理，这里本来应该是lpfnFilter参数，指向异常处理过滤的代码的地址，但是这里是0。只要这个地方的地址为0就是finally语句块

image-20220329092429559.png

全局展开

// SEH6.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
VOID ExceptionTest()
{
__try
{
__try
{
__try
{
*(int*)0 = 1;
}
__finally
{
printf("Must run this code : A");
}
}
__finally
{
printf("Must run this code : B");
}
}
__except(1)
{
printf("Here is Exception_functions");
}
}
int main(int argc, char* argv[])
{
ExceptionTest();
getchar();
return 0;
}

全局展开就是一层一层的向上找异常处理函数，finally模块还是照常执行

image-20220329094846868.png

image-20220329102145583.png

0x03 未处理异常

入口程序的最后一道防线

image-20220329104223648.png

这里调用mainCRTStartup()，然后调用入口程序

image-20220329104250459.png

相当于这里才是一个进程开始执行的地方

image-20220329104533520.png

这里有一个call调用，跟进去看看

image-20220329104602203.png

发现有修改fs:[0]的操作，这里就相当于编译器为我们注册了一个异常处理函数

image-20220329104705199.png

这里到kernel32.dll里面的BaseProcessStart里面看一下，这里有一个注册SEH异常处理函数的操作

image-20220329105057347.png

线程启动的最后一道防线

// SEH7.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
DWORD WINAPI ThreadProc(LPVOID lpParam)
{
int i = 1;
return 0;
}
int main(int argc, char* argv[])
{
CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
getchar();
return 0;

可以发现线程也是从kernel32.dll开始的

image-20220329105932341.png

然后跟进调用

image-20220329110018752.png

可以发现还是注册了一个异常处理函数

image-20220329110034166.png

还是去IDA里面看BaseThreadStart函数，发现也注册了一个SEH异常的函数

image-20220329110402112.png

UnhandledExceptionFilter

相当于编译器为我们生成了一段伪代码

__try
{
}
__except(UnhandledExceptionFilter(GetExceptionInformation())
{
//终止线程
//终止进程
}

只有程序被调试时，才会存在未处理异常

UnhandledExceptionFilter的执行流程：

1) 通过NtQueryInformationProcess查询当前进程是否正在被调试，如果是，返回EXCEPTION_CONTINUE_SEARCH，此时会进入第二轮分发 
2) 如果没有被调试： 
查询是否通过SetUnhandledExceptionFilter注册处理函数 如果有就调用 
如果没有通过SetUnhandledExceptionFilter注册处理函数 弹出窗口 让用户选择终止程序还是启动即时调试器 
如果用户没有启用即时调试器，那么该函数返回EXCEPTION_EXECUTE_HANDLER

SetUnhandledExceptionFilter

如果没有通过SetUnhandledExceptionFilter注册异常处理函数，则程序崩溃

image-20220401142104425.png

image-20220401142146258.png

测试代码如下，我自己构造一个异常处理函数callback并用SetUnhandledExceptionFilter注册，构造一个除0异常，当没有被调试的时候就会调用callback处理异常，然后继续正常运行，如果被调试则不会修复异常，因为这是最后一道防线，就会直接退出，起到反调试的效果

// SEH7.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
long _stdcall callback(_EXCEPTION_POINTERS* excp)
{
excp->ContextRecord->Ecx = 1;
return EXCEPTION_CONTINUE_EXECUTION;
}
int main(int argc, char* argv[])
{
SetUnhandledExceptionFilter(callback);
_asm
{
xor edx,edx
xor ecx,ecx
mov eax,0x10
idiv ecx
}
printf("Run again!");
getchar();
return 0;
}

直接启动可以正常运行

image-20220329113645787.png

使用od打开则直接退出

image-20220329113851211.png

image-20220329113905022.png

KiUserExceptionDispatcher

只有当前程序处于调试的时候才可能产生未处理异常

1) 调用RtlDispatchException  查找并执行异常处理函数
2) 如果RtlDispatchException返回真,调用ZwContinue再次进入0环，但线程再次返回3环时，会从修正后的位置开始执行。
3) 如果RtlDispatchException返回假,调用ZwRaiseException进行第二轮异常分发
(参见KiUserExceptionDispatcher代码)

image-20220329114630657.png


赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

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

俗话说“好记性不如烂笔头”，各个安全社区各自为战，当我们想要搜索某一方面的文章的时候总是得在各个平台之间来回横跳，于是乎，一个平台文章聚合搜索的想法诞生了。
然后正好我想有一个自己的博客，于是乎两者融合在了一起。
下面简单介绍各个导航的区别：
个人文章：本人的笔记、复现、总结等或者本人参与的共同创作。
收集文章：手工从公众号收集保存的文章，更新频率看本人喜好所以比较慢。
聚合文章：从各大平台收集整理，由工具实现，每天更新。
很惭愧，只做了一点微小的工作。