Reversing MS VC++ Part II: Classes, Methods and RTTI

统计

随笔 - 50
文章 - 42
评论 - 147
引用 - 0

留言簿(6)

随笔分类

文章分类

Link

搜索

积分与排名

积分 - 162640
排名 - 161

阅读排行榜

评论排行榜

摘要

MS VC++ 是Win32平台上最广泛使用的编译器，因此熟悉它的内部工作机制对于Win32逆向爱好者非常重要。能够理解编译器生成的附加（glue）代码有助于快速理解程序员写的实际代码。同样也有助于恢复程序的高级结构。

在Part II中，我将讲到MSVC是如何实现C++的，包括类的布局，虚函数，RTTI。假设你已经熟悉C++基本知识和汇编语言。

基本的类布局

为了解释下面的内容，让我们看看这个简单例子：

class A

{

int a1;

public:

virtual int A_virt1();

virtual int A_virt2();

static void A_static1();

void A_simple1();

};

class B

{

int b1;

int b2;

public:

virtual int B_virt1();

virtual int B_virt2();

};

class C: public A, public B

{

int c1;

public:

virtual int A_virt2();

virtual int B_virt2();

};

多数情形下，MSVC的类按如下格局分布：

Ÿ 指向虚函数表的指针（_vtable_或_vftable_），不过它只在类包括虚函数，以及不能从基类复用合适的函数表时才会被添加。

Ÿ 基类。

Ÿ 函数成员。

虚函数表由虚函数的地址组成，表中函数地址的顺序和它们第一次出现的顺序（即在类定义的顺序）一致。若有重载的函数，则替换掉基类函数的地址。

因此，上面三个类的布局看起来象这样：

class A size(8):

+---

0 | {vfptr}

4 | a1

+---

A's vftable:

0 | &A::A_virt1

4 | &A::A_virt2

class B size(12):

+---

0 | {vfptr}

4 | b1

8 | b2

+---

B's vftable:

0 | &B::B_virt1

4 | &B::B_virt2

class C size(24):

+---

| +--- (base class A)

0 | | {vfptr}

4 | | a1

| +---

| +--- (base class B)

8 | | {vfptr}

12 | | b1

16 | | b2

| +---

20 | c1

+---

C's vftable for A:

0 | &A::A_virt1

4 | &C::A_virt2

C's vftable for B:

0 | &B::B_virt1

4 | &C::B_virt2

上面的图表是由VC8编译器使用一个未公开的参数生成。为了看到这样的类布局，使用编译参数 –d1 reportSingleClassLayout，可以输出单个类的布局。-d1 reportAllClassLayout可以输出全部类的布局（包括内部的CRT类）。这些内容都被输出到stdout（标准输出）。

正如你看到的，C有两个虚函数表vftables，因为它从两个都有虚函数的类继承。C::A_virt2的地址替换了A::A_virt2在类C虚函数表的地址，类似的，C::B_virt2替换了B::B_virt2。

调用惯例和类方法

MSVC中所有的类方法都默认使用_thiscall_调用惯例。类实例的地址（_this_指针）作为隐含参数传到ecx寄存器。在函数体中，编译器通常立刻用其它寄存器（如esi或ed），或栈中变量来指代。以后对类成员的引用都通过这个寄存器或栈变量。然而，在实现COM类时，则使用_stdcall_调用习惯。下文是对各种类型的类方法的一个概述。

1) 静态方法

调用静态方法不需要类的实例，所以它们和普通函数一样的工作原理。没有_this_指针传入。因此也就不可能可靠的分辨静态方法和简单的普通函数。例如：

A::A_static1();

call A::A_static1

2) 简单方法

简单方法需要一个类实例，_this_指针隐式的作为第一个参数传入，通常使用_thiscall_调用惯例，例如通过_ecx_寄存器。当基类对象没有分配在派生类对象的开始处，在调用函数前，_this_指针需要被调整到指向基类子对象的实际开始位置。例如：

;pC->A_simple1(1);

;esi = pC

push 1

mov ecx, esi

call A::A_simple1

;pC->B_simple1(2,3);

;esi = pC

lea edi, [esi+8] ;adjust this

push 3

push 2

mov ecx, edi

call B::B_simple1

正如你看到的，在调用B的方法前，_this_指针被调整到指向B的子对象。

3) 虚方法（虚函数）

为了调用虚函数，编译器首先需要从_vftable_取得函数地址，然后就像调用简单方法一样（例如，传入_this_指针作为隐含参数）。例如：

;pC->A_virt2()

;esi = pC

mov eax, [esi] ;fetch virtual table pointer

mov ecx, esi

call [eax+4] ;call second virtual method

;pC->B_virt1()

;edi = pC

lea edi, [esi+8] ;adjust this pointer

mov eax, [edi] ;fetch virtual table pointer

mov ecx, edi

call [eax] ;call first virtual method

4) 构造函数和析构函数

构造函数和析构函数类似于简单方法，它们取得隐式的_this_指针（例如，在_thiscall_调用惯例下通过ecx寄存器）。虽然形式上构造函数没有返回值，但它在eax中返回_this_指针。

RTTI实现

RTTI（Run-Time Type Identification）运行时类型识别是由编译器生成的特殊信息，用于支持像dynamic_cast<>和typeid（）这样的C++运算符，以及C++异常。基于这个本质，RTTI只为多态类生成，例如带虚函数的类。

MSVC编译器在vftable前设置了一个指针，指向叫做“Complete Object Locator”（完整对象定位器）的结构。这样称呼是因为它允许编译器从特定的vftable指针（因为一个类可能有若干vftable）找到完整对象的位置。COL就像如下定义:

struct RTTICompleteObjectLocator

{

DWORD signature; //always zero ?

DWORD offset; //offset of this vtable in the complete class

DWORD cdOffset; //constructor displacement offset

struct TypeDescriptor* pTypeDescriptor; //TypeDescriptor of the complete class

struct RTTIClassHierarchyDescriptor* pClassDescriptor; //describes inheritance hierarchy

};

类层次描述符描述了类的继承层次。对于一个类，所有COL共享一个。

struct RTTIClassHierarchyDescriptor

{

DWORD signature; //always zero?

DWORD attributes; //bit 0 set = multiple inheritance, bit 1 set = virtual inheritance

DWORD numBaseClasses; //number of classes in pBaseClassArray

struct RTTIBaseClassArray* pBaseClassArray;

};

基类数组描述了所有基类，并包含在执行_dynamic_cast_过程中编译器是否允许强制转换派生类到这些基类的信息。基类描述符中每一项都包含如下结构：

struct RTTIBaseClassDescriptor

{

struct TypeDescriptor* pTypeDescriptor; //type descriptor of the class

DWORD numContainedBases; //number of nested classes following in the Base Class Array

struct PMD where; //pointer-to-member displacement info

DWORD attributes; //flags, usually 0

};

struct PMD

{

int mdisp; //member displacement

int pdisp; //vbtable displacement

int vdisp; //displacement inside vbtable

};

PMD描述了一个基类如何放置在完整类中。在简单的继承体系中，它位于从整个对象起始位置的一个固定偏移处，这个偏移量就是_mdisp_。如果是一个虚基类，那需要从vbtable中取得一个额外的偏移量加上。从派生类到基类调整_this_指针的伪码如下：

//char* pThis; struct PMD pmd;

pThis+=pmd.mdisp;

if (pmd.pdisp!=-1)

{

char *vbtable = pThis+pmd.pdisp;

pThis += *(int*)(vbtable+pmd.vdisp);

}

例如，我们的三个类的RTTI层次关系是：

RTTI hierarchy for our example classes

提取信息

1) RTTI

如果存在，RTTI对于逆向工作来说是无价的信息。从RTTI，有可能恢复类的名字，继承层次，有时候也能恢复部分的类布局。我的RTTI扫描器脚本可以显示大多数此类信息。（参考附录I）

2) 静态和全局初始化例程（initializer）

全局和静态对象需要在main主程序开始前初始化。MSVC通过生成初始化例程函数（funclet）来实现，并把这些函数地址放入一个表中，当_cinit初始化CRT时，会调用它们。这个表通常位于.data段的开始。一个典型的初始化例程如下：

_init_gA1:

mov ecx, offset _gA1

call A::A()

push offset _term_gA1

call _atexit

pop ecx

retn

_term_gA1:

mov ecx, offset _gA1

call A::~A()

retn

从这个表我们可以找到：

· 全局/静态对象的地址

· 它们的构造函数

· 它们的析构函数

还可以参考MSVC _#pragma_directive_init_seg_[5]。

3) Unwind Funclets

若在函数中创建了自动类型的对象，VC++编译器会自动生成异常处理代码以确保在异常发生时会删除这些对象。请参看Part I以了解对C++异常实现的细节。一个典型的unwind funclet在栈上销毁一个对象的过程是：

unwind_1tobase: ; state 1 -> -1

lea ecx, [ebp+a1]

jmp A::~A()

通过在函数体中寻找相反的状态变化，或者是在第一次访问相同的栈中变量时，我们也可以找到构造函数。

lea ecx, [ebp+a1]

call A::A()

mov [ebp+__$EHRec$.state], 1

对于由new创建的对象，unwind funclet确保了万一构造失败也能删除分配的内存：

unwind_0tobase: ; state 0 -> -1

mov eax, [ebp+pA1]

push eax

call operator delete(void *)

pop ecx

retn

在函数体中：

;A* pA1 = new A();

push

call operator new(uint)

add esp, 4

mov [ebp+pA1], eax

test eax, eax

mov [ebp+__$EHRec$.state], 0; state 0: memory allocated but object is not yet constructed

jz short @@new_failed

mov ecx, eax

call A::A()

mov esi, eax

jmp short @@constructed_ok

@@new_failed:

xor esi, esi

@@constructed_ok:

mov [esp+14h+__$EHRec$.state], -1

;state -1: either object was constructed successfully or memory allocation failed

;in both cases further memory management is done by the programmer

另一种类型的unwind funclets用于构造函数和析构函数中。它确保了万一发生异常时删除类成员。这时候，funclets要使用保存在一个栈变量的_this_指针，

unwind_2to1:

mov ecx, [ebp+_this] ; state 2 -> 1

add ecx, 4Ch

jmp B1::~B1

这是funclet析构类型B1位于偏移4Ch处一个类成员的代码。从这里我们可以找到：

· 栈变量代表了C++对象或者指向用new分配的对象的指针

· 它们的构造函数

· 它们的析构函数

· 由new创建的对象的大小

4) 构造/析构函数的递归调用

规则很简单：构造函数调用其他的构造函数（其他基类和成员变量的构造函数），析构函数调用其它的析构函数。一个典型的构造函数按下列顺序执行：

· 调用基类构造函数

· 调用复杂的类成员的构造函数

· 若类有虚函数，初始化vfptr

· 执行当前的构造函数代码（即由程序员写得构造代码）

典型的析构函数几乎按照反序执行：

· 若有虚函数，初始化vfptr

· 执行当前的析构函数代码

· 调用复杂类成员的析构函数

· 调用基类的析构函数

MSVC生成的析构函数另一个独特的特征是它们的_state_变量通常初始化为最大值，每次析构一个子对象就减一，这样使得识别它们更容易。要注意简单的构造/析构函数经常被MSVC内联（inline）。那就是为什么你经常看到vftable指针在同一个函数中被不同指针重复的调用。

5) 数组的构造和析构

MSVC使用一个辅助函数来构造和析构数组。思考下面的代码：

A* pA = new A[n];

delete [] pA

翻译成下面的伪码：

array = new char(sizeof(A)*n+sizeof(int))

if (array)

{

*(int*)array=n; //store array size in the beginning

'eh vector constructor iterator'(array+sizeof(int),sizeof(A),count,&A::A,&A::~A);

}

pA = array;

'eh vector destructor iterator'(pA,sizeof(A),count,&A::~A);

如果A有一个vftable，当删除数组时，相应的会以调用一个删除析构函数的向量来替代：

;pA->'vector deleting destructor'(3);

mov ecx, pA

push 3 ; flags: 0x2=deleting an array, 0x1=free the memory

call A::'vector deleting destructor'

若A的析构函数是虚函数，则按照调虚函数的方式调用：

mov ecx, pA

push 3

mov eax, [ecx] ;fetch vtable pointer

call [eax] ;call deleting destructor

因此，从向量构造/析构函数叠代子调用我们可以知道：

· 对象数组的地址

· 它们的构造函数

· 它们的析构函数

· 类的大小

6) 删除析构函数

当类有虚析构函数时，编译器生成一个辅助函数来删除它。其目的是当析构一个类时确保_delete_操作符被调用。删除析构函数的伪码如下：

virtual void * A::'scalar deleting destructor'(uint flags)

{

this->~A();

if (flags&1) A::operator delete(this);

};

这个函数的地址被放入vftable替换析构函数地址。通过这种方式，如果另外一个类覆盖了这个虚析构函数，那么它的_delete_将被调用。然而实际代码中_delete_几乎不会被覆盖，所以你通常只看到调用默认的delete()。有时候，编译器也生成一个删除析构函数向量，就像下面一样：

virtual void * A::'vector deleting destructor'(uint flags)

{

if (flags&2) //destructing a vector

{

array = ((int*)this)-1; //array size is stored just before the this pointer

count = array[0];

'eh vector destructor iterator'(this,sizeof(A),count,A::~A);

if (flags&1) A::operator delete(array);

}

else {

this->~A();

if (flags&1) A::operator delete(this);

}

};

我跳过了有虚基类的类的大部分实现细节，因为它们使得事情更复杂了，而且在现实生活中很少用到。请参考Jan Gray写的文章[1]。它已经很详尽了，只是用匈牙利命名法有点头痛。文章[2]描述了一个MSVC实现虚继承的实现。更多细节还可以看MS专利[3]。

附录 I ms_rtti4.idc

这是我写的解析RTTI和vtfable的脚本。你可以从Microsoft VC++ Reversing Helpers打包下载我的两篇文章和脚本。这个脚本的特点包括：

解析RTTI结构，用对应的类名重命名vftables
对于某些简单情形，识别和重命名构造函数和析构函数
输出所有的虚函数表，引用的函数，及类的层次到一个文件里

使用说明：

在第一次分析结束后，加载ms_rtti4.idc。它会问你是否想要扫描exe文件来获得vtable。注意这可能是一个漫长的过程。即使你跳过了扫描，你还是可以手工分析vtables。若你选择了扫描，脚本将会试着识别所有的vtables，RTTI，重命名它们，识别和重命名构造函数、析构函数。有时候它会失败，特别是存在虚继承时。扫描结束后，它会打开记录了结果的文本文件。

在加载脚本后，你可以用下面的快捷键手动分析一些MSVC结构：

Alt-F8 －分析vtable。光标应该位于vtable的开始处。若有RTTI，脚本会使用类名。若没有RTTI，你可以输入一个类名，然后脚本将重命名vtable。若有可识别的虚析构函数，脚本也会重命名它。
Alt-F7 －分析FuncInfo。FuncInfo是存在于有对象分配在栈中或使用了异常处理的函数中的结构体。它的地址被传给函数异常处理程序的_CxxFrameHandler。

mov eax, offset FuncInfo1

jmp _CxxFrameHandler

大多数情况下，它可以被IDA自动识别和分析。但我的脚本提供了更丰富的信息。你也可以用我第一篇文章中的_ehseh.idc分析所有的FuncInfo。

把光标放在FuncInfo的开始处，用快捷键。

Alt-F9 －分析ThrowInfo。ThrowInfo是_CxxThrowException用来实现_throw_操作符的一个辅助结构。它的地址是_CxxThrowException的第二个参数。

lea ecx, [ebp+e]

call E::E()

push offset ThrowInfo_E

lea eax, [ebp+e]

push eax

call _CxxThrowException

把光标放在ThrowInfo的开始处，使用该快捷键。脚本会分析该结构体，重复添加thrown类的名字到注释中。它还可以识别和重命名异常的析构函数和拷贝构造函数。

附录II：恢复一个类的实践

我们的题目是：MSN Messenger 7.5（msnmsgr.exe版本号是7.5.324，大小7094272字节）。它使用了大量的C++，含有很多RTTI信息。让我们考虑两个vftable，地址分别在.0040EFD8和.0040EFE0。它们完整的RTTI结构层次如下图：

RTTI hierarchy for MSN Messenger 7.5

所以，这两个vftables都属于一个类－CContentMenuItem。通过查看它的基类描述符，我们看到：

CContentMenuItem包括三个基类－CDownloader, CNativeEventSink和CNativeEventSource。
CDownloader包含一个基类－CNativeEventSink
因此CContentMenuItem直接从CDownloader, CNativeEventSink和CNativeEventSource继承，而CDownloader从CNativeEventSink继承。
CDownloader位于完整对象的起始处，CNativeEventSource是在0x24偏移处。

所以我们可以得出结论，第一个vftable列出了CNativeEventSource的方法，第二个列出了CDownloader或CNatvieEventSink的方法（若干二者均没有虚方法，CContentMenuItem将复用CNativeEventSource的vftable）。现在我们看看有什么指向了这两个表。它们都被两个函数引用，在.052B5E0和.052B547。（这更说明了它们都属于同一个类）。进一步，如果我们看看在函数.052B547的开始处，_state_变量初始化为6，意味着那个函数是析构函数。因为一个类只有一个析构函数，我们可以断定.052B5E0就是它的构造函数。让我们看得更近些：

CContentMenuItem::CContentMenuItem proc near

this = esi

push this

push edi

mov this, ecx

call sub_4CA77A

lea edi, [this+24h]

mov ecx, edi

call sub_4CBFDB

or dword ptr [this+48h], 0FFFFFFFFh

lea ecx, [this+4Ch]

mov dword ptr [this], offset const CContentMenuItem::'vftable'{for 'CContentMenuItem'}

mov dword ptr [edi], offset const CContentMenuItem::'vftable'{for 'CNativeEventSource'}

call sub_4D8000

lea ecx, [this+50h]

call sub_4D8000

lea ecx, [this+54h]

call sub_4D8000

lea ecx, [this+58h]

call sub_4D8000

lea ecx, [this+5Ch]

call sub_4D8000

xor eax, eax

mov [this+64h], eax

mov [this+68h], eax

mov [this+6Ch], eax

pop edi

mov dword ptr [this+60h], offset const CEventSinkList::'vftable'

mov eax, this

pop this

retn

sub_52B5E0 endp

编译器在prolog后的第一件事情就是从exc拷贝_this_指针到esi，因此随后的地址引用都是基于esi。在初始化vfptr前，它调了两个其它函数，一定是基类的构造函数－我们的例子中就是CDownloader和CNativeEventSource。进到这两个函数中，我们可以确认第一个用CDownloader::’vftable’初始化它的vfptr，第二个用CNativeEventSource::’vftable’。我们还可以进一步看看CDownloader的构造函数－它调用了基类CNativeEventSink的构造函数。

同样，从edi中取得传给第二个函数的_this_指针，它指向this+24h。根据我们的类结构图，这个地址是CNativeEventSource子对象的位置。这从另一个方向确认了调用的第二个函数是CNativeEventSource的构造函数。

调用完基类构造函数后，基类对象的vfptr都被CContentMenuItem的实现重写了，意味着CContentMenuItem覆盖了基类的某些虚方法（或添加了它自己的）。(如果有需要，我们可以比较这些表，查看哪些指针被改变或者添加－被添加的就是CContentMenuItem新实现的。

下面我们看看几个在地址.04D8000的函数调用，这时ecx从this+4Ch被设置到this+5Ch －很显然，初始化了一些成员变量。我们如何得知那是一个编译器生成的构造函数调用还是以程序员写的初始化函数呢？这里有几个提示：

函数使用_thiscall_调用习惯，而且是第一次访问这些域。
这些域的初始化是按照地址增长的方向进行的。

为了保证我们可以查看析构函数中的unwind funclet －那里我们可以看得为这些成员变量，编译器生成的析构函数调用。

这个新类不包括虚函数，也就没有RTTI，所以我们不知道它的真实名字。就叫它RefCountedPtr吧。我们已经确定，4D8000是它的构造函数。析构函数我们可以从CContentMenuItem析构函数的unwind funclet找到，它在63CCB4。

回到CContentMenuItem的构造函数，我们看得3个域初始化为0，还有一个vftable指针。这看起来像是一个成员变量内联展开的构造函数（不是基类的，因为若是基类，就应该在继承树中存在）。从用到的vftable的RTTI，我们看得它是CEventSinkList模板的一个实例。

现在，我们来写一个可能的类声明：

class CContentMenuItem: public CDownloader, public CNativeEventSource

{

/* 00 CDownloader */

/* 24 CNativeEventSource */

/* 48 */ DWORD m_unknown48;

/* 4C */ RefCountedPtr m_ptr4C;

/* 50 */ RefCountedPtr m_ptr50;

/* 54 */ RefCountedPtr m_ptr54;

/* 58 */ RefCountedPtr m_ptr58;

/* 5C */ RefCountedPtr m_ptr5C;

/* 60 */ CEventSinkList m_EventSinkList;

/* size = 70? */

};

我们不确定在偏移48处的变量是否不是CNativeEventSource的一部分，因为在CNativeEventSource的构造函数中没有访问过，它很可能是CContentMenuItem的一部分。包含被重命名的方法的构造函数和类结构如下：

public: __thiscall CContentMenuItem::CContentMenuItem(void) proc near

push this

push edi

mov this, ecx

call CDownloader::CDownloader(void)

lea edi, [this+CContentMenuItem._CNativeEventSource]

mov ecx, edi

call CNativeEventSource::CNativeEventSource(void)

or [this+CContentMenuItem.m_unknown48], -1

lea ecx, [this+CContentMenuItem.m_ptr4C]

mov [this+CContentMenuItem._CDownloader._vfptr], offset const CContentMenuItem::'vftable'{for 'CContentMenuItem'}

mov [edi+CNativeEventSource._vfptr], offset const CContentMenuItem::'vftable'{for 'CNativeEventSource'}