Struct Reconstruction

When you reverse engineer a binary file, you often don't have the original source code, meaning you don't know what structures the programmer defined and what fields each one has.

Here you have to reconstruct the data structure based on how the program accesses memory. We call this Struct Reconstruction.

Assume the original program has a structure like this:

C

struct User {
int id;
int age;
char active;
};

This structure has three fields, one for the user ID, one for age, and one for the active status.

But when you examine the compiled file, you may not see the User name or the id and age fields at all. You only have assembly instructions that work with memory addresses.

Now let's see how we can identify the structure from these instructions.

Finding the field addresses.

Suppose you come across the following instructions in assembly.

Asm

mov eax, dword ptr [rcx]

mov edx, dword ptr [rcx+4]

movzx eax, byte ptr [rcx+8]

Let's examine them one by one.

Asm

mov eax, dword ptr [rcx]

Reads four bytes from the address in RCX.

Asm

mov edx, dword ptr [rcx+4]

Reads four bytes from the next four bytes.

Asm

movzx eax, byte ptr [rcx+8]

Reads one byte from the eight bytes after the initial address.

Now, the information that We have this form

Text

Base address + 0 four bytes
Base address + 4 four bytes
Base address + 8 one byte

This pattern can show that the program is accessing three different fields of a structure

Determining the size and type of fields

Based on the size of the accesses, we can guess what type each field has

A four-byte access may be related to int or float

A one-byte access may be related to char or a boolean value

But be aware that size alone does not determine the exact type of data, for example, a four-byte value can also be part of a larger number

To better identify, you need to see where the value is used

If the value is used with numerical calculation instructions, it may be a regular number. If it works with instructions related to floating-point operations, it is more likely to be a float

Reconstructing the structure

Given the accesses we saw, we can create a possible structure

C

struct Unknown {
int field_0;
int field_4;
char field_8;
};

We named the fields based on their memory offsets for now because we don't know their actual use yet

After examining more parts of the program, we might find out that field_0 is the user ID, field_4 is the user's age, and field_8 is the activation status

The labeling is done based on the meaning of the data, not just the appearance of the assembly

Checking for writing to fields

Don't just check the read instructions, writing to memory also gives us important information

For example:

Asm

mov dword ptr [rcx], 123
mov dword ptr [rcx+4], 25
mov byte ptr [rcx+8], 1

These instructions write to offsets zero, four, and eight, respectively

If you see the same offsets used for reading and writing in different parts of the program, the likelihood that you are dealing with fields of a structure increases

Of course, you still need to check whether RCX is really the base address of a shared structure or just a point to a part of memory at that moment

Finding the actual size of the structure

There is an important point here

The largest offset you find is not necessarily the full size of the structure

For example, if the last field starts at offset eight and is one byte in size, the minimum space required for these fields is 9 bytes, but the final size of the structure may be larger due to memory alignment rules.

For example, the compiler may round the structure to 12 bytes to meet the required alignment.

The structure may also have other fields that we have not yet accessed in the paths examined.

So you should estimate the size of the structure by examining the memory allocation, how pointers are used, and all visible offsets.

How is this done in Ghidra?

Once you have found a possible structure, you can create a new structure from the Data Type Manager and define its fields.