Reversing Microsoft Visual C++ Part I: Exception Handling

原文链接http://www.openrce.org/articles/full_view/21

Abstract

Microsoft Visual C++ is the most widely used compiler for Win32 so it is important for the Win32 reverser to be familiar with its inner working. Being able to recognize the compiler-generated glue code helps
to quickly concentrate on the actual code written by the programmer. It also helps in recovering the high-level structure of the program. 

In part I of this 2-part article (see also: Part II: Classes, Methods and
RTTI), I will concentrate on the stack layout, exception handling and related structures in MSVC-compiled programs. Some familiarity with assembler, registers, calling conventions etc. is assumed. 

Terms:
Stack frame: A fragment of the stack segment used by a function. Usually contains function arguments, return-to-caller address, saved registers, local variables and other data specific to this function.
On x86 (and most other architectures) caller and callee stack frames are contiguous.
Frame pointer: A register or other variable that points to a fixed location inside the stack frame. Usually all data inside the stack frame is addressed relative to the frame pointer. On x86 it's
usually ebp and it usually points just below the return address.
Object: An instance of a (C++) class.
Unwindable Object: A local object with auto storage-class specifier that is allocated on the stack and needs to be destructed when it goes out of scope.
Stack UInwinding: Automatic destruction of such objects that happens when the control leaves the scope due to an exception.
There are two types of exceptions that can be used in a C or C++ program.
SEH exceptions (from "Structured Exception Handling"). Also known as Win32 or system exceptions. These are exhaustively covered in the famous Matt Pietrek article[1]. They are the only exceptions available
to C programs. The compiler-level support includes keywords __try, __except, __finally and a few others.
C++ exceptions (sometimes referred to as "EH"). Implemented on top of SEH, C++ exceptions allow throwing and catching of arbitrary types. A very important feature of C++ is automatic stack unwinding during
exception processing, and MSVC uses a pretty complex underlying framework to ensure that it works properly in all cases.
In the following diagrams memory addresses increase from top to bottom, so the stack grows "up". It's the way the stack is represented in IDA and opposite to
the most other publications. 

Basic Frame Layout

The most basic stack frame looks like following: 

...
Local variables
Other saved registers
Saved ebp
Return address
Function arguments
...

Note: If frame pointer omission is enabled, saved ebp might be absent. 

SEH

In cases where the compiler-level SEH (__try/__except/__finally) is used, the stack layout gets a little more complicated. 


 
SEH3 Stack Layout

When there are no __except blocks in a function (only __finally), Saved ESP is not used. Scopetable is an array of records which describe each __try block and relationships between them: 

struct _SCOPETABLE_ENTRY {
DWORD EnclosingLevel;
void* FilterFunc;
void* HandlerFunc;
}

For more details on SEH implementation see[1]. To recover try blocks watch how the try level variable is updated. It's assigned a unique number per try block,
and nesting is described by relationship between scopetable entries. E.g. if scopetable entry i has EnclosingLevel=j, then try block j encloses try block i. The function body is considered to have try level -1. See Appendix 1 for an example. 

Buffer Overrun Protection

The Whidbey (MSVC 2005) compiler adds some buffer overrun protection for the SEH frames. The full stack frame layout in it looks like following: 


 
SEH4 Stack Layout

The GS cookie is present only if the function was compiled with /GS switch. The EH cookie is always present. The SEH4 scopetable is basically the same as SEH3 one, only with added header: 

struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};

struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};

GSCookieOffset = -2 means that GS cookie is not used. EH cookie is always present. Offsets are ebp relative. Check is done the following way: (ebp+CookieXOROffset) ^ [ebp+CookieOffset]
== _security_cookie Pointer to the scopetable in the stack is XORed with the _security_cookie too. Also, in SEH4 the outermost scope level is -2, not -1 as in SEH3. 

C++ Exception Model Implementation

When C++ exceptions handling (try/catch) or unwindable objects are present in the function, things get pretty complex. 


 
C++ EH Stack Layout

EH handler is different for each function (unlike the SEH case) and usually looks like this: 

(VC7+)
mov eax, OFFSET __ehfuncinfo
jmp ___CxxFrameHandler

__ehfuncinfo is a structure of type FuncInfo which fully describes all try/catch blocks and unwindable objects in the function. 

struct FuncInfo {
// compiler version.
// 0x19930520: up to VC6, 0x19930521: VC7.x(2002-2003), 0x19930522: VC8 (2005)
DWORD magicNumber;

// number of entries in unwind table
int maxState;

// table of unwind destructors
UnwindMapEntry* pUnwindMap;

// number of try blocks in the function
DWORD nTryBlocks;

// mapping of catch blocks to try blocks
TryBlockMapEntry* pTryBlockMap;

// not used on x86
DWORD nIPMapEntries;

// not used on x86
void* pIPtoStateMap;

// VC7+ only, expected exceptions list (function "throw" specifier)
ESTypeList* pESTypeList;

// VC8+ only, bit 0 set if function was compiled with /EHs
int EHFlags;
};

Unwind map is similar to the SEH scopetable, only without filter functions: 

struct UnwindMapEntry {
int toState;        // target state
void (*action)();   // action to perform (unwind funclet address)
};

Try block descriptor. Describes a try{} block with associated catches. 

struct TryBlockMapEntry {
int tryLow;
int tryHigh;    // this try {} covers states ranging from tryLow to tryHigh
int catchHigh;  // highest state inside catch handlers of this try
int nCatches;   // number of catch handlers
HandlerType* pHandlerArray; //catch handlers table
};

Catch block descriptor. Describes a single catch() of a try block. 

struct HandlerType {
// 0x01: const, 0x02: volatile, 0x08: reference
DWORD adjectives;

// RTTI descriptor of the exception type. 0=any (ellipsis)
TypeDescriptor* pType;

// ebp-based offset of the exception object in the function stack.
// 0 = no object (catch by type)
int dispCatchObj;

// address of the catch handler code.
// returns address where to continues execution (i.e. code after the try block)
void* addressOfHandler;
};

List of expected exceptions (implemented but not enabled in MSVC by default, use /d1ESrt to enable). 

struct ESTypeList {
// number of entries in the list
int nCount;

// list of exceptions; it seems only pType field in HandlerType is used
HandlerType* pTypeArray;
};

RTTI type descriptor. Describes a single C++ type. Used here to match the thrown exception type with catch type. 

struct TypeDescriptor {
// vtable of type_info class
const void * pVFTable;

// used to keep the demangled name returned by type_info::name()
void* spare;

// mangled type name, e.g. ".H" = "int", ".?AUA@@" = "struct A", ".?AVA@@" = "class A"
char name[0];
};

Unlike SEH, each try block doesn't have a single associated state value. The compiler changes the state value not only on entering/leaving a try block, but also for each constructed/destroyed object. That
way it's possible to know which objects need unwinding when an exception happens. You can still recover try blocks boundaries by inspecting the associated state range and the addresses returned by catch handlers (see Appendix 2). 

Throwing C++ Exceptions

throw statements are converted into calls of _CxxThrowException(), which actually raises a Win32 (SEH) exception with the code 0xE06D7363 ('msc'|0xE0000000). The custom parameters of the Win32 exception include
pointers to the exception object and its ThrowInfo structure, using which the exception handler can match the thrown exception type against the types expected by catch handlers. 

struct ThrowInfo {
// 0x01: const, 0x02: volatile
DWORD attributes;

// exception destructor
void (*pmfnUnwind)();

// forward compatibility handler
int (*pForwardCompat)();

// list of types that can catch this exception.
// i.e. the actual type and all its ancestors.
CatchableTypeArray* pCatchableTypeArray;
};

struct CatchableTypeArray {
// number of entries in the following array
int nCatchableTypes;
CatchableType* arrayOfCatchableTypes[0];
};

Describes a type that can catch this exception. 

struct CatchableType {
// 0x01: simple type (can be copied by memmove), 0x02: can be caught by reference only, 0x04: has virtual bases
DWORD properties;

// see above
TypeDescriptor* pType;

// how to cast the thrown object to this type
PMD thisDisplacement;

// object size
int sizeOrOffset;

// copy constructor address
void (*copyFunction)();
};

// Pointer-to-member descriptor.
struct PMD {
// member offset
int mdisp;

// offset of the vbtable (-1 if not a virtual base)
int pdisp;

// offset to the displacement value inside the vbtable
int vdisp;
};

We'll delve more into this in the next article. 

Prologs and Epilogs

Instead of emitting the code for setting up the stack frame in the function body, the compiler might choose to call specific prolog and epilog functions instead. There are several variants, each used for
specific function type: 

Name	Type	EH Cookie	GS Cookie	Catch Handlers
_SEH_prolog/_SEH_epilog	SEH3	-	-
_SEH_prolog4/_SEH_epilog4 S	EH4	+	-
_SEH_prolog4_GS/_SEH_epilog4_GS	SEH4	+	+
_EH_prolog	C++ EH	-	-	+/-
_EH_prolog3/_EH_epilog3	C++ EH	+	-	-
_EH_prolog3_catch/_EH_epilog3	C++ EH	+	-	+
_EH_prolog3_GS/_EH_epilog3_GS	C++ EH	+	+	-
_EH_prolog3_catch_GS/_EH_epilog3_catch_GS	C++ EH	+	+	+

SEH2

Apparently was used by MSVC 1.XX (exported by crtdll.dll). Encountered in some old NT programs. 

...
Saved edi
Saved esi
Saved ebx
Next SEH frame
Current SEH handler (__except_handler2)
Pointer to the scopetable
Try level
Saved ebp (of this function)
Exception pointers
Local variables
Saved ESP
Local variables
Callee EBP
Return address
Function arguments
...

Appendix I: Sample SEH Program

Let's consider the following sample disassembly. 

func1           proc near

_excCode        = dword ptr -28h
buf             = byte ptr -24h
_saved_esp      = dword ptr -18h
_exception_info = dword ptr -14h
_next           = dword ptr -10h
_handler        = dword ptr -0Ch
_scopetable     = dword ptr -8
_trylevel       = dword ptr -4
str             = dword ptr  8

push    ebp
mov     ebp, esp
push    -1
push    offset _func1_scopetable
push    offset _except_handler3
mov     eax, large fs:0
push    eax
mov     large fs:0, esp
add     esp, -18h
push    ebx
push    esi
push    edi

; --- end of prolog ---

mov     [ebp+_trylevel], 0 ;trylevel -1 -> 0: beginning of try block 0
mov     [ebp+_trylevel], 1 ;trylevel 0 -> 1: beginning of try block 1
mov     large dword ptr ds:123, 456
mov     [ebp+_trylevel], 0 ;trylevel 1 -> 0: end of try block 1
jmp     short _endoftry1

_func1_filter1:                         ; __except() filter of try block 1
mov     ecx, [ebp+_exception_info]
mov     edx, [ecx+EXCEPTION_POINTERS.ExceptionRecord]
mov     eax, [edx+EXCEPTION_RECORD.ExceptionCode]
mov     [ebp+_excCode], eax
mov     ecx, [ebp+_excCode]
xor     eax, eax
cmp     ecx, EXCEPTION_ACCESS_VIOLATION
setz    al
retn

_func1_handler1:                        ; beginning of handler for try block 1
mov     esp, [ebp+_saved_esp]
push    offset aAccessViolatio ; "Access violation"
call    _printf
add     esp, 4
mov     [ebp+_trylevel], 0 ;trylevel 1 -> 0: end of try block 1

_endoftry1:
mov     edx, [ebp+str]
push    edx
lea     eax, [ebp+buf]
push    eax
call    _strcpy
add     esp, 8
mov     [ebp+_trylevel], -1 ; trylevel 0 -> -1: end of try block 0
call    _func1_handler0     ; execute __finally of try block 0
jmp     short _endoftry0

_func1_handler0:                        ; __finally handler of try block 0
push    offset aInFinally ; "in finally"
call    _puts
add     esp, 4
retn

_endoftry0:
; --- epilog ---
mov     ecx, [ebp+_next]
mov     large fs:0, ecx
pop     edi
pop     esi
pop     ebx
mov     esp, ebp
pop     ebp
retn
func1           endp

_func1_scopetable
;try block 0
dd -1                      ;EnclosingLevel
dd 0                       ;FilterFunc
dd offset _func1_handler0  ;HandlerFunc

;try block 1
dd 0                       ;EnclosingLevel
dd offset _func1_filter1   ;FilterFunc
dd offset _func1_handler1  ;HandlerFunc

The try block 0 has no filter, therefore its handler is a __finally{} block. EnclosingLevel of try block 1 is 0, so it's placed inside try block 0. Considering
this, we can try to reconstruct the function structure: 

void func1 (char* str)
{
char buf[12];
__try // try block 0
{
__try // try block 1
{
*(int*)123=456;
}
__except(GetExceptCode() == EXCEPTION_ACCESS_VIOLATION)
{
printf("Access violation");
}
strcpy(buf,str);
}
__finally
{
puts("in finally");
}
}

Appendix II: Sample Program with C++ Exceptions

func1           proc near

_a1             = dword ptr -24h
_exc            = dword ptr -20h
e               = dword ptr -1Ch
a2              = dword ptr -18h
a1              = dword ptr -14h
_saved_esp      = dword ptr -10h
_next           = dword ptr -0Ch
_handler        = dword ptr -8
_state          = dword ptr -4

push    ebp
mov     ebp, esp
push    0FFFFFFFFh
push    offset func1_ehhandler
mov     eax, large fs:0
push    eax
mov     large fs:0, esp
push    ecx
sub     esp, 14h
push    ebx
push    esi
push    edi
mov     [ebp+_saved_esp], esp

; --- end of prolog ---

lea     ecx, [ebp+a1]
call    A::A(void)
mov     [ebp+_state], 0          ; state -1 -> 0: a1 constructed
mov     [ebp+a1], 1              ; a1.m1 = 1
mov     byte ptr [ebp+_state], 1 ; state 0 -> 1: try {
lea     ecx, [ebp+a2]
call    A::A(void)
mov     [ebp+_a1], eax
mov     byte ptr [ebp+_state], 2 ; state 2: a2 constructed
mov     [ebp+a2], 2              ; a2.m1 = 2
mov     eax, [ebp+a1]
cmp     eax, [ebp+a2]            ; a1.m1 == a2.m1?
jnz     short loc_40109F
mov     [ebp+_exc], offset aAbc  ; _exc = "abc"
push    offset __TI1?PAD         ; char *
lea     ecx, [ebp+_exc]
push    ecx
call    _CxxThrowException       ; throw "abc";

loc_40109F:
mov     byte ptr [ebp+_state], 1 ; state 2 -> 1: destruct a2
lea     ecx, [ebp+a2]
call    A::~A(void)
jmp     short func1_try0end

; catch (char * e)
func1_try0handler_pchar:
mov     edx, [ebp+e]
push    edx
push    offset aCaughtS ; "Caught %s\n"
call    ds:printf       ;
add     esp, 8
mov     eax, offset func1_try0end
retn

; catch (...)
func1_try0handler_ellipsis:
push    offset aCaught___ ; "Caught ...\n"
call    ds:printf
add     esp, 4
mov     eax, offset func1_try0end
retn

func1_try0end:
mov     [ebp+_state], 0          ; state 1 -> 0: }//try
push    offset aAfterTry ; "after try\n"
call    ds:printf
add     esp, 4
mov     [ebp+_state], -1         ; state 0 -> -1: destruct a1
lea     ecx, [ebp+a1]
call    A::~A(void)
; --- epilog ---
mov     ecx, [ebp+_next]
mov     large fs:0, ecx
pop     edi
pop     esi
pop     ebx
mov     esp, ebp
pop     ebp
retn
func1           endp

func1_ehhandler proc near
mov     eax, offset func1_funcinfo
jmp     __CxxFrameHandler
func1_ehhandler endp

func1_funcinfo
dd 19930520h            ; magicNumber
dd 4                    ; maxState
dd offset func1_unwindmap ; pUnwindMap
dd 1                    ; nTryBlocks
dd offset func1_trymap  ; pTryBlockMap
dd 0                    ; nIPMapEntries
dd 0                    ; pIPtoStateMap
dd 0                    ; pESTypeList

func1_unwindmap
dd -1
dd offset func1_unwind_1tobase ; action
dd 0                    ; toState
dd 0                    ; action
dd 1                    ; toState
dd offset func1_unwind_2to1 ; action
dd 0                    ; toState
dd 0                    ; action

func1_trymap
dd 1                    ; tryLow
dd 2                    ; tryHigh
dd 3                    ; catchHigh
dd 2                    ; nCatches
dd offset func1_tryhandlers_0 ; pHandlerArray
dd 0

func1_tryhandlers_0
dd 0                    ; adjectives
dd offset char * `RTTI Type Descriptor' ; pType
dd -1Ch                 ; dispCatchObj
dd offset func1_try0handler_pchar ; addressOfHandler
dd 0                    ; adjectives
dd 0                    ; pType
dd 0                    ; dispCatchObj
dd offset func1_try0handler_ellipsis ; addressOfHandler

func1_unwind_1tobase proc near
a1 = byte ptr -14h
lea     ecx, [ebp+a1]
call    A::~A(void)
retn
func1_unwind_1tobase endp

func1_unwind_2to1 proc near
a2 = byte ptr -18h
lea     ecx, [ebp+a2]
call    A::~A(void)
retn
func1_unwind_2to1 endp

Let's see what we can find out here. The maxState field in FuncInfo structure is 4 which means we have four entries in the unwind map, from 0 to 3. Examining
the map, we see that the following actions are executed during unwinding:

state 3 -> state 0 (no action)
state 2 -> state 1 (destruct a2)
state 1 -> state 0 (no action)
state 0 -> state -1 (destruct a1)
Checking the try map, we can infer that states 1 and 2 correspond to the try block body and state 3 to the catch blocks bodies. Thus, change from state 0 to
state 1 denotes the beginning of try block, and change from 1 to 0 its end. From the function code we can also see that -1 -> 0 is construction of a1, and 1 -> 2 is construction of a2. So the state diagram looks like this: 



Where did the arrow 1->3 come from? We cannot see it in the function code or FuncInfo structure since it's done by the exception handler. If an exception happens inside try block, the exception handler first
unwinds the stack to the tryLow value (1 in our case) and then sets state value to tryHigh+1 (2+1=3) before calling the catch handler. 

The try block has two catch handlers. The first one has a catch type (char*) and gets the exception object on the stack (-1Ch = e). The second one has no type (i.e. ellipsis catch). Both handlers return the
address where to resume execution, i.e. the position just after the try block. Now we can recover the function code: 

void func1 ()
{
A a1;
a1.m1 = 1;
try {
A a2;
a2.m1 = 2;
if (a1.m1 == a1.m2) throw "abc";
}
catch(char* e)
{
printf("Caught %s\n",e);
}
catch(...)
{
printf("Caught ...\n");
}
printf("after try\n");
}

Appendix III: IDC Helper Scripts

I wrote an IDC script to help with the reversing of MSVC programs. It scans the whole program for typical SEH/EH code sequences and comments all related structures and fields. Commented are stack variables,
exception handlers, exception types and other. It also tries to fix function boundaries that are sometimes incorrectly determined by IDA. You can download it from MS
SEH/EH Helper. 

Links and References

[1] Matt Pietrek. A Crash Course on the Depths of Win32 Structured Exception Handling.
http://www.microsoft.com/msj/0197/exception/exception.aspx
Still THE definitive guide on the implementation of SEH in Win32.

[2] Brandon Bray. Security Improvements to the Whidbey Compiler.
http://blogs.msdn.com/branbray/archive/2003/11/11/51012.aspx
Short description on changes in the stack layout for cookie checks.

[3] Chris Brumme. The Exception Model.
http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx
Mostly about .NET exceptions, but still contains a good deal of information about SEH and C++ exceptions.

[4] Vishal Kochhar. How a C++ compiler implements exception handling.
http://www.codeproject.com/cpp/exceptionhandler.asp
An overview of C++ exceptions implementation.

[5] Calling Standard for Alpha Systems. Chapter 5. Event Processing.
http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-PY8AC-TET1_html/callCH5.html
Win32 takes a lot from the way Alpha handles exceptions and this manual has a very detailed description on how it happens. 

Structure definitions and flag values were also recovered from the following sources:
VC8 CRT debug information (many structure definitions)
VC8 assembly output (/FAs)
VC8 WinCE CRT source