C++ Reversing Series - 0x00

Table of Contents

The more functional and developable a product is, the more complex it is. This complexity made it difficult to create “quality” applications in the software development world where functional programming was previously used effectively. Instead of functional programming, the object-oriented programming paradigm, which was introduced with a higher level approach, was introduced and enabled developers to reveal large projects more clearly by writing code that can be associated with real life.

The advantages of object-oriented programming for the programmer are indisputable, but do the same conditions apply to the reverse engineer analyzing an application?

The answer to the question is clearly no because while software coded with a classical (i.e. functional) approach is compiled by the compiler as is, software coded using OOP structure is compiled by the compiler using different approaches and rules. A reverse engineer who is not familiar with these approaches and rules has difficulty in analyzing such applications. Especially if advanced OOP features such as polymorphism and dynamic binding are utilized, this situation becomes unmanageable. In this article, I will talk about the topics and details of how to reversing C++ applications written using OOP. Since defining C++ structures in sophisticated and advanced applications and shortening the reverse engineering processes will not fit in one article, I will make this a series :)

Class & Struct Similarity

We mentioned that OOP provides great benefits and can simplify complex structures. There is an unknown here, isn’t there? If you have analyzed applications developed with traditional programming (ex: a malware written in C) and you are familiar with the x86 architecture and instruction set, it is not so unknown for you. Because the “high-level” concepts we are going to talk about are actually based on the basics you already know.

// class_struct.h

class cls_material{
    char code;
    int count;
    bool avail;

struct str_material {
    char code;
    int count;
    bool avail;

The class and struct we defined above are basically the same. The compiler interprets and compiles both in the same way. Let’s make implementations to test this.

// class_struct.cpp

    struct str_material gold;
    cls_material copper;

    gold.avail = true;
    gold.code = 17;
    gold.count = 15;

    copper.avail = false;
    copper.code = 18;
    copper.count = 23;

In the small code example we kept data about the materials. An important point here is that the resources are initialized on the stack (we will also talk about dynamic initialization). There doesn’t seem to be any difference at the source code level. Let’s dissassemble and take a look.

.text:00401000                 push    ebp
.text:00401001                 mov     ebp, esp
.text:00401003                 sub     esp, 18h ; allocated for local variables
.text:00401006                 mov     [ebp+var_4], 1 ; gold.avail
.text:0040100A                 mov     [ebp+var_C], 11h ; gold.code
.text:0040100E                 mov     [ebp+var_8], 0Fh ; gold.count
.text:00401015                 mov     [ebp+var_10], 0 ; copper.avail
.text:00401019                 mov     [ebp+var_18], 12h ; copper.code
.text:0040101D                 mov     [ebp+var_14], 17h ; copper.count
.text:00401024                 xor     eax, eax
.text:00401026                 mov     esp, ebp
.text:00401028                 pop     ebp
.text:00401029                 retn
.text:00401029 _main           endp         endp

We have proved that there is no difference at the assembly level, and that struct and class are the same up to the memory footprint. In the simplest terms, we can say that classes are essentially the same as structs and that these two structures are really just a collection of memory addresses of types.

Class Constructor

Constructor is one of the most important concepts we need to recognize in order to reverse the OOP structure in C++. Let’s look at the declaration and definition of the constructor.

// constructor.hpp

class Material {

    char code;
    int count;
    bool avail;

    Material(char _code, int _count, bool _avail) : code{ _code }, count{ _count }, avail{ _avail }{}

    char getCode();
    int getCount();
    bool isAvail();


// constructor.cpp

char Material::getCode() {
    return code;

int Material::getCount() {
    return count;

bool Material::isAvail() {
    return avail;

// main.cpp (Implementation)

int main() {
    Material* gold = new Material(17, 15, true);
    std::cout << gold->getCode() << "\n" << gold->getCount() << "\n" << gold->isAvail();

    return 0;

The constructor of our Material class takes the attributes at initialization time and makes the variables ready for use. There are also related member functions that return each attribute. In its implementation, it is worth noting that we use dynamic initialization compared to the previous simple class example.

.text:004012E3                 push    0Ch             ; Class boyutu
.text:004012E5                 call    ??2@YAPAXI@Z    ; operator new(uint)
.text:004012EA                 mov     [ebp+Block], eax
.text:004012ED                 sub     esp, 8
.text:004012F0                 mov     [ebp+var_4], 0
.text:004012F7                 mov     ecx, eax ; eax = Class pointerı
.text:004012F9                 call    sub_401260 ; Material::Material()

Before calling the constructor, the heap allocated memory area that will hold our class pointer is assigned to the ecx register and the constructor of the Material class (sub_401260), which is basically a member function, is called.

.text:00401260                 push    ebp
.text:00401261                 mov     ebp, esp
.text:00401270                 push    esi
.text:00401271                 mov     esi, ecx ; ecx = this pointer
.text:00401273                 push    0Ah
.text:00401275                 mov     byte ptr [esi], 11h ; code 
.text:00401278                 mov     dword ptr [esi+4], 0Fh ; count
.text:0040127F                 mov     byte ptr [esi+8], 1 ; avail
.text:0040129B                 mov     eax, esi ; this pointer moved to eax register for return
.text:004012A5                 mov     esp, ebp
.text:004012A7                 pop     ebp
.text:004012A8                 retn    0Ch

We can see that the sub_401260 function is a constructor. The this pointer, which is the secret pointer of our object, is used in the constructor through the ecx register. The parameters we pass in the initialize phase are moved to the memory space allocated for our object according to their size.

After the object is constructed, the arrangement of the attributes in memory is as above (I don’t mention the memory padding and the size of the variables).

Member Function Calls

Let’s continue our example with our Material class again. Since the attributes are specified as private, we have written get functions (you can see their definitions in the example above).

.text:00401299                 call    sub_401260 ; constructor
.text:0040129E                 mov     edx, eax ; edx = object pointer
.text:004012A0                 mov     ecx, edx ; ecx = object pointer
.text:004012A2                 call    sub_401250 ; Material::isAvail()
.text:004012A7                 movzx   ecx, al
.text:004012AA                 push    ecx
.text:004012AB                 mov     ecx, edx ; ecx = object pointer
.text:004012AD                 call    sub_401240 ; Material::getCount()
.text:004012B2                 push    eax 
.text:004012B3                 call    sub_401230 ; Material::getCode()

We can call our member functions via our object pointer (this). Note that C++ compilers (at least MSVC) assign the this pointer to the ecx register when calling a member function of an object. So the constant use of ecx may indicate the use of OOP primitives.


Inheritance is undoubtedly the concept that gives the OOP structure its inter-class relationship and extension structure. It is one of the two most difficult (in my opinion) fundamentals to reverse OOP based C++ applications.

It would be more useful to examine the topic of Inheritance under two headings as single and multiple. Let’s both explain and reverse with examples :)

Single Inheritance

In this situation derived class has only one base class.

// inheritance.hpp

class Plant {
    int age;
    Plant() : age{ 0 } {};

class Tree : public Plant {
    int leaf_count;
    Tree() : leaf_count{ 0 } {}

class Fruit : public Plant {
    int water_percent;
    Fruit() : water_percent{ 0 } {};

There are two important concepts when it comes to inheritance: base class and derived class. Derived classes take the attributes of base classes. Since we know that each plant has an age, we define this common attribute in our base class. And we inherit our base class to each plant type we create.

// main.cpp

int main() {
    Tree oak;
    Fruit apple;

    return 0;

As you can see in the implementation, we have inherited the attributes of the base class to the derived classes. Let’s come to the reverse part, which is our topic, and this time let’s consider that we are creating our objects on the stack.

.text:004010D0                 push    ebp
.text:004010D1                 mov     ebp, esp
.text:004010D3                 and     esp, 0FFFFFFF8h
.text:004010D6                 sub     esp, 8 
.text:004010D9                 lea     ecx, [esp+8+var_8] 
.text:004010DC                 call    sub_401090 ; Tree::Tree()
.text:004010E1                 lea     ecx, [esp+8+var_8]
.text:004010E4                 call    sub_4010B0 ; Fruit::Fruit()
.text:004010E9                 xor     eax, eax
.text:004010EB                 mov     esp, ebp
.text:004010ED                 pop     ebp
.text:004010EE                 retn

On the surface it looks like the constructors of the derived classes are called first, but the underlying concept is completely different.

.text:00401090 sub_401090      proc near               
.text:00401090                 push    esi             
.text:00401091                 mov     esi, ecx
.text:00401093                 call    sub_401070 ; Plant::Plant()
.text:00401098                 push    offset aTreeTree ; "Tree::Tree()\n"
.text:0040109D                 mov     dword ptr [esi+4], 0
.text:004010A4                 call    _printf
.text:004010A9                 add     esp, 4
.text:004010AC                 mov     eax, esi
.text:004010AE                 pop     esi
.text:004010AF                 retn
.text:004010AF sub_401090      endp

.text:004010B0 sub_4010B0      proc near               
.text:004010B0                 push    esi             
.text:004010B1                 mov     esi, ecx
.text:004010B3                 call    sub_401070 ; Plant::Plant()
.text:004010B8                 push    offset aFruitFruit ; "Fruit::Fruit()\n"
.text:004010BD                 mov     dword ptr [esi+4], 0
.text:004010C4                 call    _printf
.text:004010C9                 add     esp, 4
.text:004010CC                 mov     eax, esi
.text:004010CE                 pop     esi
.text:004010CF                 retn
.text:004010CF sub_4010B0      endp

.text:00401070 sub_401070      proc near               
.text:00401070                 push    esi             
.text:00401071                 mov     esi, ecx
.text:00401073                 push    offset Format   ; "Plant::Plant()\n"
.text:00401078                 mov     dword ptr [esi], 0 ; age = 0
.text:0040107E                 call    _printf
.text:00401083                 add     esp, 4
.text:00401086                 mov     eax, esi
.text:00401088                 pop     esi
.text:00401089                 retn
.text:00401089 sub_401070      endp

Now everything is clearer. Even though it looks like the constructors of the derived classes are called first, the compiler actually calls the base class constructor first. After the base class is constructed, the other elements in the derived class are constructed. Maybe it seems confusing, let’s describe it in our code:

Tree() : leaf_count{ 0 } {}
Tree() {
    Plant::Plant(); // you might think there is a secret call 
    leaf_count = 0;

Multiple Inheritance

Derived class has more than one base class. Let’s update our existing Tree class and add Forest as a base class.

class Forest {
    int numof_trees;
    Forest() : numof_trees{ 0 } { printf("Forest::Forest()\n"); }

class Tree : public Plant, public Forest {
    int leaf_count;
    Tree() : leaf_count{ 0 } { printf("Tree::Tree()\n"); }

Currently we have a derived class with 2 base classes. Let’s disassemble it and see which one will be constructed first.

.text:00401090 sub_401090      proc near ; Tree::Tree() constructor             
.text:00401090                 push    esi             
.text:00401091                 mov     esi, ecx ; esi = this pointer
.text:00401093                 call    sub_401050 ; Plant::Plant()
.text:00401098                 lea     ecx, [esi+4]
.text:0040109B                 call    sub_401070 ; Forest::Forest()
.text:004010A0                 push    offset aTreeTree ; "Tree::Tree()\n"
.text:004010A5                 mov     dword ptr [esi+8], 0 ; leaf_count = 0
.text:004010AC                 call    _printf
.text:004010B1                 add     esp, 4
.text:004010B4                 mov     eax, esi
.text:004010B6                 pop     esi
.text:004010B7                 retn
.text:004010B7 sub_401090      endp

We can see that base classes are constructed from left to right, unlike parameter passing. Let’s change the initialize values of the class variables to leaf_count = 1, age = 2, numof_trees = 3, add the attribute int root_size = 50 to the Plant class and see how the object belonging to the Tree class is arranged in memory with multiple member variables.

.text:00401070 sub_401070      proc near ; Plant::Plant()               
.text:00401070                 push    esi             
.text:00401071                 mov     esi, ecx ; esi = Tree this pointer 
.text:00401073                 push    offset Format   ; "Plant::Plant()\n"
.text:00401078                 mov     dword ptr [esi], 2 ; age = 2
.text:0040107E                 mov     dword ptr [esi+4], 32h ; root_size = 50
.text:00401085                 call    _printf
.text:0040108A                 add     esp, 4 
.text:0040108D                 mov     eax, esi ; return this 
.text:0040108F                 pop     esi
.text:00401090                 retn
.text:00401090 sub_401070      endp

.text:004010A0 sub_4010A0      proc near ; Forest::Forest()              
.text:004010A0                 push    esi            
.text:004010A1                 mov     esi, ecx ; Tree this pointer
.text:004010A3                 push    offset aForestForest ; "Forest::Forest()\n"
.text:004010A8                 mov     dword ptr [esi], 3 ; numof_trees = 3
.text:004010AE                 call    _printf
.text:004010B3                 add     esp, 4 
.text:004010B6                 mov     eax, esi ; return this
.text:004010B8                 pop     esi
.text:004010B9                 retn
.text:004010B9 sub_4010A0      endp

In Multiple inherit, we can see the content of the object created for the derived Tree class more clearly. As in Single, we have understood that it contains all the attributes of the base class in order from right to left.


Polymorphism, which stands for Polymorphism, basically allows us to behave “of another type and in more than one form “. Polymorphism is most common for us reverse engineers with the concept of dynamic dispatch. Virtual methods are used to call the same function (type of function, number of parameters and types) of the most derived class that is derived and overridden from the base class and is one of the ways to provide dynamic dispatch.

Let’s continue with our Tree and Plant class examples, but this time simplify them a bit.

// poly.hpp

class Plant {
    int age;
    Plant() : age{ 20 } {}
    virtual void create() { std::cout << "New plant type created!\n"; }
    void del() {std::cout << "Plant type deleted!\n";

class Tree : public Plant{
    int leaf_count;
    Tree() : leaf_count{ 10 } {}
    virtual void create() { std::cout << "New tree created!\n"; }
    void del() { std::cout << "Tree deleted!\n"; }

The create() and del() methods, which are exactly the same, can be found in both base and derived classes. In order to fully understand the function of virtual methods, let’s be aware that our del() method is not a virtual method.

// main.cpp

int main() {
    Tree* oak = new Tree;
    Plant* plt { oak };


    return 0;

New tree created!
Plant type deleted!

When the virtual method is called from the base class, the method of the most derived class is called, while in the non-virtual method, it calls the method of the class (Plant) from which it is currently called without any lookup action on the objects.

So what exactly is this lookup and how does the compiler call the most derived method?

Virtual Function Table (VfTable)

Virtual function invocation, also referred to as dynamic binding, takes place at runtime and is as far as possible independent of compiler optimizations. The VfTable contains the address of each virtual method in sequential order and is dispatchable by the table.

.text:00401030 sub_401030      proc near ; Tree::Tree()
.text:00401030                 call    sub_401000 ; Plant::Plant()
.text:00401035                 mov     dword ptr [ecx], offset ??_7Tree@@6B@ ;&Tree::vftable
.text:0040103B                 mov     eax, ecx
.text:0040103D                 mov     dword ptr [ecx+8], 0Ah ; leaf_count = 10
.text:00401044                 retn
.text:00401044 sub_401030      endp

.text:00401000 sub_401000      proc near ; Plant::Plant()
.text:00401000                 mov     dword ptr [ecx], offset ??_7Plant@@6B@ ; &Plant::vftable
.text:00401006                 mov     eax, ecx
.text:00401008                 mov     dword ptr [ecx+4], 14h
.text:0040100F                 retn
.text:0040100F sub_401000      endp

Since it is a base class, the Plant::vftable reference will be assigned to the object pointer, but later the Tree::vftable reference will be replaced and the Tree::create() method will be called. Since we first create an object from the Tree class and reference it to the Plant class, the compiler changes the vftables. The reason why we specify as independent of compiler optimization as possible is also explained in practice.

.rdata:00403204 ??_7Plant@@6B@  dd offset sub_401010    ; Plant::create()
.rdata:00403208                 dd offset ??_R4Tree@@6B@ ; const Tree::`RTTI Complete Object Locator'
.rdata:0040320C ; const Tree::`vftable'
.rdata:0040320C ??_7Tree@@6B@   dd offset sub_401050    ; Tree::create()

We can also understand the content of VfTable from the above disassemble output. For a better understanding, let’s specify it via the UML template and show it in the memory array.

plt: 0C 32 99 00 | 14 00 00 00 | 0A 00 00 00
      &vftable        age         leaf_count

&vftable(0099320C): 50 10 99 00

We have clearly explained the vftable sharing and memory allocations between base and derived classes.

.text:00401073                 call    sub_401030 ; Tree::Tree()
.text:00401078                 mov     ecx, eax ; eax = oak object pointer
.text:0040107A                 mov     edx, [eax] ; [eax] = vftable reference
.text:0040107C                 call    dword ptr [edx] ; [edx] = Tree::create() reference
.text:0040107E                 call    sub_401020 ; Plant::delete()

In the disassemble fragment above, we can see how vftable is used. In our implementation, we override and call the Tree::create() method. We can call the method at runtime via vftable, which is referenced in the first 4 bytes of the object pointer. Then, since the virtual keyword is not used, the Plant::delete() method is called and the program terminates.


Microsoft Word - Reversing_CPP.doc (blackhat.com)

Reversing C++ programs with IDA pro and Hex-rays – Aris’ Blog (0xbadc0de.be)

Learn C++ – Skill up with our free tutorials (learncpp.com)

comments powered by Disqus