首页
活动
安全导航

撕开编译器给throw套上的那层皮——代码还原

阅读量380565

|

发布时间 : 2020-06-22 10:30:03

 

1、前言

做软件开发的同事或多或少都用过throw，而我是个例外，我第一次“真正接触”throw，是在一次dmp的分析中，追踪异常数据时，深入的挖了下，觉得里边有些东西对大家在开发中遇到异常时，可能会有些帮助。本文经过简单的逆向分析，弄清楚有关于throw的全貌，使得你将来无论是使用throw还是分析dmp时，都如鱼得水，游刃有余。撰以小文，与君分享。

 

2、实验分析过程

写了个简单的demo如下，完全是为了演示throw，演示环境为VS2010，X86，Release；

class MyBaseException
{
public:
       MyBaseException()
       {
              std::cout<<"BaseException"<<std::endl;
       }
};

class MyException:public MyBaseException
{
private:
       int m_a;
       int m_b;
       int m_c;
       char m_name[100];
public:
       MyException(const char * str,int a,int b,int c)
       {
              strcpy_s(m_name,100,str);
              m_a = a;
              m_b = b;
              m_c = c;
       }

       int get_a(){return m_a;}
       virtual int get_b(){return m_b;}
       virtual int get_c(){return m_c;}
       virtual char * get_name(){return m_name;}
};

int main()
{
       throw MyException("exception_demo",1,2,3);
       return 0;
}

运行之后，不出意外是这样子的，如下图所示

直接点击”调试“按钮即可，说明下，我习惯用Windbg调试和分析问题，所以我将Windbg设置为JIT了。这边看个人喜好；由于我的设置，我这里默认拉起来的就是Windbg了；来看下拉起来的样子，如上右图所示；下边就可以开始分析了；

看过我之前的文章的同学都可能会想到我常用的两个命令”.exr -1”和”.ecxr”，可这里他不灵了，不信你看：

0:000> .exr -1
Last event was not an exception
0:000> .ecxr
Unable to get exception context, HRESULT 0x8000FFFF

留个小小的思考题，为什么在这里，这两个命令突然失效了？答案文末给出。既然这招行不通，那就先看看调用栈，如下：

0:000> kb
# ChildEBP RetAddr  Args to Child
00 00fff3d0 76f314ad ffffffff 00000003 00000000 ntdll!NtTerminateProcess+0xc
01 00fff4a8 75725902 00000003 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0xbd
02 00fff4bc 715e7997 00000003 00fff50c 715e7ab0 KERNEL32!ExitProcessImplementation+0x12
03 00fff4c8 715e7aaf 00000003 30b17962 00000000 MSVCR100!__crtExitProcess+0x17
04 00fff50c 7161bf47 00000003 00000001 00000000 MSVCR100!doexit+0xfb
05 00fff520 7164d707 00000003 7164383d 30b17936 MSVCR100!_exit+0x11
06 00fff528 7164383d 30b17936 00000000 00000000 MSVCR100!abort+0x32
07 00fff558 00911897 00fff5fc 7664ba90 00fff62c MSVCR100!terminate+0x33 
08 00fff560 7664ba90 00fff62c 255e6b41 00000000 test!__CxxUnhandledExceptionFilter+0x3c
09 00fff5fc 76f829b8 00fff62c 76f563d2 00fffe60 KERNELBASE!UnhandledExceptionFilter+0x1a0
0a 00fffe60 76f47bf4 ffffffff 76f68ff3 00000000 ntdll!__RtlUserThreadStart+0x3adc3
0b 00fffe70 00000000 00911684 01191000 00000000 ntdll!_RtlUserThreadStart+0x1b

且先不管这个栈帧是否合理，我看见了一个关键的API——KERNELBASE!UnhandledExceptionFilter，之所以说他关键，是因为他是异常分发中SEH链上的最后”守墓人”；其原型如下：

LONG UnhandledExceptionFilter( _EXCEPTION_POINTERS *ExceptionInfo ); 
typedef struct _EXCEPTION_POINTERS
{ 
    PEXCEPTION_RECORD ExceptionRecord; 
    PCONTEXT ContextRecord; 
} EXCEPTION_POINTERS, *PEXCEPTION_POINTERS;

https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-unhandledexceptionfilter

好，那我们就来看下这里边的数据，如下：

0:000:x86> dt _EXCEPTION_POINTERS 00fff62c
msvcr100!_EXCEPTION_POINTERS
   +0x000 ExceptionRecord  : 0x00fff768 _EXCEPTION_RECORD
   +0x004 ContextRecord    : 0x00fff7b8 _CONTEXT
0:000:x86> dt _EXCEPTION_RECORD  0x00fff768
msvcr100!_EXCEPTION_RECORD
   +0x000 ExceptionCode    : 0xe06d7363
   +0x004 ExceptionFlags   : 1
   +0x008 ExceptionRecord  : (null)
   +0x00c ExceptionAddress : 0x765b4402 Void
   +0x010 NumberParameters : 3
   +0x014 ExceptionInformation : [15] 0x19930520
0:000:x86> dt _CONTEXT 0x00fff7b8
msvcr100!_CONTEXT
   +0x000 ContextFlags     : 0x1007f
   +0x004 Dr0              : 0
   +0x008 Dr1              : 0
   +0x00c Dr2              : 0
   +0x010 Dr3              : 0
   +0x014 Dr6              : 0
   +0x018 Dr7              : 0
   +0x01c FloatSave        : _FLOATING_SAVE_AREA
   +0x08c SegGs            : 0x2b
   +0x090 SegFs            : 0x53
   +0x094 SegEs            : 0x2b
   +0x098 SegDs            : 0x2b
   +0x09c Edi              : 0x9133d4
   +0x0a0 Esi              : 1
   +0x0a4 Ebx              : 0
   +0x0a8 Edx              : 0
   +0x0ac Ecx              : 3
   +0x0b0 Eax              : 0xfffc98
   +0x0b4 Ebp              : 0xfffcf0
   +0x0b8 Eip              : 0x765b4402
   +0x0bc SegCs            : 0x23
   +0x0c0 EFlags           : 0x212
   +0x0c4 Esp              : 0xfffc98
   +0x0c8 SegSs            : 0x2b
   +0x0cc ExtendedRegisters : [512]

数据看上去一切都正常，此时大家伙都知道了，该用.ecxr命令了。其实这里有个很方便的命令，它可以直接处理_EXCEPTION_POINTERS *，一步到位，用法如下：

0:000:x86> .exptr 00fff62c
----- Exception record at 00fff768:
ExceptionAddress: 765b4402 (KERNELBASE!RaiseException+0x00000062)
   ExceptionCode: e06d7363 (C++ EH exception)
  ExceptionFlags: 00000001
NumberParameters: 3
   Parameter[0]: 19930520
   Parameter[1]: 00fffd38
   Parameter[2]: 00912400
  pExceptionObject: 00fffd38
  _s_ThrowInfo    : 00912400
  Type            : class MyException
  Type            : class MyBaseException
----- Context record at 00fff7b8:
eax=00fffc98 ebx=00000000 ecx=00000003 edx=00000000 esi=00000001 edi=009133d4
eip=765b4402 esp=00fffc98 ebp=00fffcf0 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
KERNELBASE!RaiseException+0x62:
765b4402 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:00fffcec=255e6225

注意看，它在ExceptionCode后边直接提示了这是个“C++ EH exception”，它是怎么知道的？在回答这个问题前，先来看一下e06d7363这个数字的特性：

0:000:x86> .formats e06d7363
Evaluate expression:
  Hex:     e06d7363
  Decimal: -529697949
  Octal:   34033271543
  Binary:  11100000 01101101 01110011 01100011
  Chars:   .msc
  Time:    ***** Invalid
  Float:   low -6.84405e+019 high 0
  Double:  1.86029e-314

哦，原来他的字符解释是”.msc”，Windbg就是借此判断它是C++异常的，如果此还不足以说明问题，后边我们还会看到最本质的；此时你应该有很多疑问，比如_s_ThrowInfo是什么？为什么会出现”class MyException”和”class MyBaseException”字符串？别急，下边我们一步一步的揭开这些谜团。源码中throw在被编译器处理过会是下边这个样子：

;throw MyException("exception_demo",1,2,3);
... 省略  
00911078 6800249100      push    offset test+0x2400 (00912400)
0091107d 8d4588          lea     eax,[ebp-78h]                 //这个是MyException栈对象的地址
00911080 50              push    eax
00911081 c7458c01000000  mov     dword ptr [ebp-74h],1
00911088 c7459002000000  mov     dword ptr [ebp-70h],2
0091108f c7459403000000  mov     dword ptr [ebp-6Ch],3
00911096 e8050c0000      call    test+0x1ca0 (00911ca0)        //根据

栈回溯可知,这个是CxxThrowException()

出现了一个非常关键的调用，CxxThrowException()，且这个函数有两个参数；依照目前的证据的话，我们有理由推测throw被编译器处理过后便是调用的CxxThrowException()。那这个函数的原型甚至源码是啥样的呢？如下：

0:000:x86> uf _CxxThrowException
715e86e8 8bff            mov     edi,edi
715e86ea 55              push    ebp
715e86eb 8bec            mov     ebp,esp
715e86ed 83ec20          sub     esp,20h
715e86f0 8b4508          mov     eax,dword ptr [ebp+8]                   ;arg1
715e86f3 56              push    esi
715e86f4 57              push    edi
715e86f5 6a08            push    8
715e86f7 59              pop     ecx
715e86f8 be34875e71      mov     esi,offset msvcr100!ExceptionTemplate (715e8734) ;下边有dmp出这块内存的数据
715e86fd 8d7de0          lea     edi,[ebp-20h]
715e8700 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]    ;从ExceptionTemplate中拷贝8*4=0x20字节的数据
715e8702 8945f8          mov     dword ptr [ebp-8],eax                  ;用arg1替代从ExceptionTemplate中拷贝过来的对应偏移的数据
715e8705 8b450c          mov     eax,dword ptr [ebp+0Ch]                ;arg2
715e8708 5f              pop     edi
715e8709 8945fc          mov     dword ptr [ebp-4],eax                  ;用arg2替代从ExceptionTemplate中拷贝过来的对应偏移的数据
715e870c 5e              pop     esi
715e870d 85c0            test    eax,eax
715e870f 7409            je      msvcr100!_CxxThrowException+0x35 (715e871a)
715e8711 f60008          test    byte ptr [eax],8
715e8714 0f856a440100    jne     msvcr100!_CxxThrowException+0x2e (715fcb84)
715e871a 8d45f4          lea     eax,[ebp-0Ch]
715e871d 50              push    eax                                    ;lpArguments
715e871e ff75f0          push    dword ptr [ebp-10h]                    ;nNumberOfArguments
715e8721 ff75e4          push    dword ptr [ebp-1Ch]                    ;dwExceptionFlags
715e8724 ff75e0          push    dword ptr [ebp-20h]                    ;dwExceptionCode
715e8727 ff1508105c71    call    dword ptr [msvcr100!_imp__RaiseException (715c1008)]
715e872d c9              leave
715e872e c20800          ret     8

715fcb84 c745f400409901  mov     dword ptr [ebp-0Ch],1994000h
715fcb8b e98abbfeff      jmp     msvcr100!_CxxThrowException+0x35 (715e871a)

0:000:x86> dd 715e8734 l8
715e8734  e06d7363 00000001 00000000 00000000
715e8744  00000003 19930520 00000000 00000000

根据”call dword ptr [msvcr100!_imp__RaiseException (715c1008)]”这行调用，我们可以推测出来ExceptionTemplate这个未知结构体的大致字段如下：

struct ExceptionTemplate
{
    DWORD dwExceptionCode            ;e06d7363 ---- .msc
    DWORD dwExceptionFlags           ;00000001
    DWORD xxxx_0                     ;00000000
    DWORD xxxx_0                     ;00000000
    DWORD nNumberOfArguments         ;00000003
    DWORD lpArguments[3]             ;19930520 00000000 00000000
}

综合上边的分析我们可得如下的C代码：

arg1为throw后边的异常对象的地址----这个可直接从上边的函数调用中推测出来；
arg2为_s_ThrowInfo对象的地址----这个是从.exptr给出的结论中推测出来的；

_CxxThrowException(ExceptionObject *arg1,s_ThrowInfo *arg2)
{   
    struct ExceptionTemplate temp = msvcr100!ExceptionTemplate;
    temp.lpArguments[1] = arg1;
    temp.lpArguments[2] = arg2;
    if(*(DWORD*)arg2 & 8)
    {
         temp.lpArguments[0]=0x1994000
    }
    return RaiseException(temp.dwExceptionCode, temp.dwExceptionFlags,temp.nNumberOfArguments,temp. lpArguments);
}

我们来简单看下这个异常对象是不是我们throw出的那个，

0:000:x86> dd 00fffd38
00fffd38  00912150 00000001 00000002 00000003
00fffd48  65637865 6f697470 65645f6e 00006f6d
00fffd58  00000000

0:000:x86> da 00fffd48
00fffd48  "exception_demo"

0:000:x86> dps 00912150
00912150  00911000 test+0x1000
00912154  00911010 test+0x1010
00912158  00911020 test+0x1020
0091215c  00000000

数据分别是我们传入的1,2,3和 “exception_demo”，另外虚表也是对得上的。我这里没有生成pdb，生成了的话，这里是直接可以看到符号解析之后的名字的，当然没有也是分析各种dmp时常遇到的情况。再来分分析下这个s_ThrowInfo为何方神圣。

0:000:x86> dt _s_ThrowInfo 00912400
msvcr100!_s_ThrowInfo
   +0x000 attributes       : 0
   +0x004 pmfnUnwind       : (null)
   +0x008 pForwardCompat   : (null)
   +0x00c pCatchableTypeArray : 0x009123f4 _s_CatchableTypeArray
0:000:x86> dt _s_CatchableTypeArray 0x009123f4
msvcr100!_s_CatchableTypeArray
   +0x000 nCatchableTypes  : 0n2
   +0x004 arrayOfCatchableTypes : [0] 0x009123bc _s_CatchableType
0:000:x86> dd 0x009123f4 l3
009123f4  00000002 009123bc 009123d8
0:000:x86> dt 0x009123bc _s_CatchableType
msvcr100!_s_CatchableType
   +0x000 properties       : 0
   +0x004 pType            : 0x00913038 TypeDescriptor
   +0x008 thisDisplacement : PMD
   +0x014 sizeOrOffset     : 0n116
   +0x018 copyFunction     : 0x009110a0     void  +0
0:000:x86> dt 0x00913038 _TypeDescriptor
msvcr100!_TypeDescriptor
   +0x000 pVFTable         : 0x00912120 Void
   +0x004 spare            : (null)
   +0x008 name             : [0]  ".?AVMyException@@"
0:000:x86> dt 009123d8 _s_CatchableType
msvcr100!_s_CatchableType
   +0x000 properties       : 0
   +0x004 pType            : 0x00913054 TypeDescriptor
   +0x008 thisDisplacement : PMD
   +0x014 sizeOrOffset     : 0n1
   +0x018 copyFunction     : (null)
0:000:x86> dt 0x00913054 _TypeDescriptor
msvcr100!_TypeDescriptor
   +0x000 pVFTable         : 0x00912120 Void
   +0x004 spare            : (null)
   +0x008 name             : [0]  ".?AVMyBaseException@@"
第一处的copyFunction后边有个地址，我看反汇编看一下里边的内容：
0:000:x86> u 009110a0 l20
test+0x10a0:
009110a0 55              push    ebp
009110a1 8bec            mov     ebp,esp
009110a3 8bc1            mov     eax,ecx
009110a5 8b4d08          mov     ecx,dword ptr [ebp+8]                        
009110a8 c70050219100    mov     dword ptr [eax],offset test+0x2150 (00912150)
009110ae 8b5104          mov     edx,dword ptr [ecx+4]
009110b1 56              push    esi
009110b2 895004          mov     dword ptr [eax+4],edx
009110b5 8b5108          mov     edx,dword ptr [ecx+8]
009110b8 57              push    edi
009110b9 895008          mov     dword ptr [eax+8],edx
009110bc 8b510c          mov     edx,dword ptr [ecx+0Ch]
009110bf 8d7110          lea     esi,[ecx+10h]
009110c2 8d7810          lea     edi,[eax+10h]
009110c5 b919000000      mov     ecx,19h
009110ca 89500c          mov     dword ptr [eax+0Ch],edx
009110cd f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
009110cf 5f              pop     edi
009110d0 5e              pop     esi
009110d1 5d              pop     ebp
009110d2 c20400          ret     4

这个函数是啥？这个函数是MyException类的构造函数；

经过上边分析，我们知道了s_ThrowInfo记录的是类的静态信息，如这个类的名字，继承的父类是谁，其构造函数做了什么事情等等信息；这个有啥用呢？这个在做dmp分析时，光有一个ExceptionObject是没太大意义的，因为做分析或者做逆向最大的工作就是分析出字段名字、作用；所以如果能够记录下该ExceptionObject所对应的类型，那对应分析crash就非常有帮助了；

 

3、被Windbg隐藏的意外惊喜

难道每次分析dmp时，都要做手动解析吗？都要先找到UnhandledExceptionFilter,然后找到其传入的两个参数，然后才能使用.ecxr来分析吗？当然不是，有些情况你压根就找不到UnhandledExceptionFilter函数，为啥？造成这个问题的情况很多，比如栈回溯失败，故意破坏了栈帧，dmp栈时失败了等等各种问题。那这样的话，又如何分析呢？方法还是有的，因为我们已经逆向分析出了ExceptionTemplate，有了这个，我们就能去找数据；往RaiseException上一级调用回溯下就可以，举例如下：

00 00fffcf0 715e872d e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x62
很多情况下，拿到dmp进行栈回溯，只有一行，这便是栈回溯失败的例子，不要担心，看见e06d7363你就知道这是个C++异常了。简单查看下内存数据就得到ExceptionTemplate了；

0:000:x86> dd 00fffcf0
00fffcf0  00fffd28 715e872d e06d7363 00000001
00fffd00  00000003 00fffd1c e06d7363 00000001
00fffd10  00000000 00000000 00000003 19930520
00fffd20  00fffd38 00912400 00fffdb0 0091109b
00fffd30  00fffd38 00912400 00912150 00000001
00fffd40  00000002 00000003 65637865 6f697470
00fffd50  65645f6e 00006f6d 00000000 00fffd88
00fffd60  715dd1af 019d392c 019d3981 00fffd80

往高地址找一下e06d7363，找到的便是ExceptionTemplate对象了，然后改怎么分析就怎么分析了；其实这个便是_CxxThrowException()调用RaiseException()在栈上生成的那个临时的ExceptionTemplate对象；每次都一大把dt，还要写上一对压根就不太好记忆的结构体的名字，太麻烦了，Windbg善解人意的一面又显示出来了，提供了一个现成的命令，当然在Windbg的帮助文档里是没有提及这个命令的具体用法的，不过还好，我教你呀；

0:000:x86> !cppexr 00fffd08
  pExceptionObject: 00fffd38
  _s_ThrowInfo    : 00912400
  Type            : class MyException
  Type            : class MyBaseException

干净利落，给出的信息简明扼要；

 

4、思考题的答案：

这两个命令当然不起作用啦，因为这不是dmp，而是处于调试状态，不像在dmp文件中那样按照指定格式记录了相应的数据，在此时Windbg找不到相应的数据，所以就失效了；

本文由void *原创发布

转载，请参考转载声明，注明出处： https://www.anquanke.com/post/id/208939

安全客 - 有思想的安全新媒体

分享到：微信
+12赞
收藏
void *
分享到：微信

发表评论

void *

Windbg忠实粉丝，内核研究者，x86架构爱好者。

  • 文章
  • 18
  • 粉丝
  • 64

TA的文章

相关文章

热门推荐

文章目录
安全客
商务合作
内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66