let’s reverse

Calling Game Functions from Your Own Executable

2024-12-26T00:33:00+01:00

Programmers write functions all the time, but these days, they rarely rely solely on their own code. In fact, a vast number of functions in most programs are reused from other developers’ work. This is thanks to standard libraries, third-party libraries, and frameworks. These resources often come with clean documentation, helpful README files, and instructions on how to build, install, and use them. They’re incredibly useful and let developers get their projects off the ground quickly.

But have you ever wondered how you could call a function embedded in someone else’s program? For example, what if you wanted to move your character in a game, draw a new GUI object, or print something to the in-game chat—directly from your own executable? Since programs and games are often closed-source, they don’t provide documentation listing their functions. Fortunately, this is where reverse engineering steps in to save the day.

In a previous post we demonstrated how to find a function responsible for parsing commands and, as a side effect, identified a function that prints text to the console. If you haven’t read that post yet, it might be a good idea to check it out before proceeding with this one.

Understanding Function Calls and Calling Conventions

When calling a function in your own program, as a programmer, you need to know a few details:

The name of the function
The parameters the function accepts
The return type (optional but helpful)

However, when dealing with a third-party application, things get more interesting. During compilation, information such as types and function names is often lost (assuming no debug symbols are present and the program is compiled directly to assembly). This makes it impossible to call the function by name. Instead, you will need a slightly different set od details:

The function’s location (its address)
The parameters the function accepts and the calling convention
The return type (and the calling convention to know where the return value is located)

Two question might come to mind: what is calling convention, and why it is enough to use just the function name in your own code, without needing the function’s location?

When you call a function that accepts parameters, there must be an agreed-upon method for the caller to pass those parameters to the callee. This agreement is named the calling convention. For example, parameters can be passed by pushing them onto the stack, either from left to right or right to left. Another question arises: who cleans the stack after the function executes — the caller or the callee? Parameters may also be passed through registers, depending on the strategy. Similarly, the function’s return value must have a designated location, such as a specific register or memory location.

Respecting the calling convention is critical so the callee knows how to interpret the parameters passed by the caller and where to place the return value. When writing your own application, you don’t usually need to worry about this, because the compiler takes care of it. It ensures that the caller adheres to the calling convention expected by the callee.

Similarly, you don’t need to know the function’s address when calling it from your own program because the function name is automatically resolved to its address by the linker.

Obtaining required information

First, we need to gather information about the function we want to call. The most important piece is the function’s location. Whether it is a function to attack a monster, collect an item or print a message to the console, the first step is to pinpoint place in the assembly code.

As mentioned earlier, in this post, we are focusing on the function that prints a message to the console. The steps to locate this function were already covered in previous post so we will skip them here.

As a side note, for this particular game the address of this function will remain the same no matter how many time you restart the game (assuming you are using the same game binary). This is because the game is always loaded at the same address by the operating system — 0x00400000, which is the default base address for x86 Windows executables. If you are curious why this happens, you can learn more here. For modern applications, however, a mechanism known as ASLR (Address Space Layout Randomization) is used, which loads the program image at a different base address on each run or system restart. This mechanism won’t be covered here.

The prologue of the function we are interested in looks like this:

Now we need to determine the number of parameters the function accepts, their types, and calling convention it uses. Thanks to modern decompilers like Ghidra or IDA, this is relatively straightforward for less complex functions. Take a look at the decompilation output:

As you can see, Ghidra deduced that the function accepts two parameters (a this pointer and a pointer of undefined type) and uses the __thiscall calling convention. Additionally, the funtion doesn’t return anything, so the return type is void. While modern tools are fantastic for simplifying our work, this is an educational post, so it’s worthwhile to understand how to reach similar conclusions manually.

To start, it’s helpful to examine how the function is called: There are multiple calls to this function, but they mostly follow the same pattern. A PUSH instruction places a pointer to the text to be printed onto the stack, and an address (0x0789d58) is moved into the ECX register just before the call. After the function executes, the caller doesn’t clean the stack, suggesting the callee handles it.

From this, we can deduce that the function accepts two parameters: the message to print (pushed onto the stack) and a mysterious address (placed in the ECX register). Let’s explore the most common x86 calling conventions.

thiscall:

On the Microsoft Visual C++ compiler, the this pointer is passed in ECX and it is the callee that cleans the stack, mirroring the stdcall convention used in C for this compiler and in Windows API functions. When functions use a variable number of arguments, it is the caller that cleans the stack (cf. cdecl).

and for stdcall:

The stdcall calling convention is a variation on the Pascal calling convention in which the callee is responsible for cleaning up the stack, but the parameters are pushed onto the stack in right-to-left order, as in the _cdecl calling convention. Registers EAX, ECX, and EDX are designated for use within the function. Return values are stored in the EAX register.

It seems that Ghidra was indeed correct in deducing the calling convention! One last thing to verify is whether the callee cleans the stack.

Looking at the last instruction of the callee, we see ret 4. This indicates that after executing this instruction, 4 bytes will be added to the stack pointer, effectively cleaning up the 4 bytes pushed by the caller.

You might be wondering what the this parameter is and why it’s passed to the function as a parameter. If you’ve ever used a C-like language that supports object-oriented programming, you’re probably familiar with the concept. Here’s a quick recap:

#include <iostream>

class Cat
{
private:
	int age;
public:
	Cat(int _age) : age{_age} {}
	
	int getAge()
	{
		return this->age;
	}
};

int main() {
	Cat cat{15};
	
	std::cout << cat.getAge();
	return 0;
}

This is a simple C++ program, that constructs a Cat object, sets its age to 15, and then print the age to the standard output. Nothing too fancy. Take a look at the this->age expression. In C++, you can use this inside a class member function to get a pointer to the current class instance, even though it is not explicitly passed as a parameter. This is thanks to the magic of the compiler. On the assembly level the getAge function might look like this:

int getAge(Cat* this)
{
	return this->age;
}

And the invocation of the function would look like this:

std::cout << Cat::getAge(&cat);

As you can see, even though the this parameter isn’t explicitly passed in your code, the compiler automatically includes it. That’s why on the assembly level, it looks like the parameter is passed explicitly.

Call the function

Armed with the information we gathered earlier, we can finally attempt to call the function. To do this, we will create our own .dll file, inject it into game process, and call the function that prints something to the console. Explaining injection in detail deserves its own post, so for now, we will use existing tools. For now, all you need to know is that once you inject a .dll into a process, it becomes a part of it. This means the .dll has access to the entire process memory, all the program functions, and more - just as if the game were your own program. If you are interested in learning more about injection, you can read about it here.

For this example, we will use the Microsoft Visual Studio IDE and its compiler to create the project. I selected the DLL template as a base. Here is the complete code:

// dllmain.cpp : Defines the entry point for the DLL application.
#include "pch.h"

typedef void(__thiscall* Print_Function)(void* this_ptr, const char* msg);
Print_Function print_to_console = (Print_Function)0x0431d40;
const char* msg = "Visit https://letsreverse.net/";

void main_func()
{
    print_to_console((void*)0x0789D58, msg);
}

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        main_func();
        break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Once the .dll is injected, the DllMain function is triggered with the DLL_PROCESS_ATTACH reason. In this entry point, we invoke main_func, which makes a call to the game’s function. It uses the this pointer we identified earlier (0x0789D58) and passes msg, the message we want to print to the console.

The two lines that might seem mysterious at first:

typedef void(__thiscall* Print_Function)(void* this_ptr, const char* msg);
Print_Function print_to_console = (Print_Function)0x0431d40;

are actually straightforward. The first line creates a typedef for a function pointer named Print_Function. This function accepts two parameters: void* and const char*. The convention is __thiscall, which instructs the compiler to place the first parameter this to ECX register and push the second parameter msg onto the stack. Additionally, the compiler knows that it doesn’t need to clean up the stack afterward, as this will be handled by the callee. You can find more details about all calling conventions supported by Microsoft’s compiler here.

The second line actually tells the compiler that the print_to_console function is located at address 0x0431d40. We know this from the first image attached to this post.

Testing the DLL

Finally, we can test our .dll. For this, we will use an injector tool Cheat Engine. It’s free and open-source, but be cautious during installation — avoid agreeing to any adware. If you’re unfamiliar with the process of injecting a .dll, check out this short video.

And there you have it! Our .dll works perfectly, and we can see the desired string displayed in the game console.

In a future post, we’ll explore the concept of function hooking—modifying existing game functions. This will allow us to alter the function that parses user commands, enabling us to add custom commands and execute specific actions when the user types the appropriate input into the console.

Unveiling Hidden Gems: Exploring Easter Eggs Through Game Reverse Engineering

2024-04-01T17:40:00+02:00

Have you ever heard of Kajko and Kokosz? They are comic characters created by a Polish comic creator named Janusz Christa. Two Slavic warriors travel the world, tackling all sorts of problems with their village along the way. Over the years, various media related to them have been released - comics, computer games, and recently, they even got their own TV series on Netflix! Some people also suggest that they are the Slavic version of Asterix & Obelix, as the characters’ visual appearance and archetypes are similar in both series. Those suggestions were, however, never confirmed.

Speaking of computer games, in this blog post we will investigate one of them: Knights: Learn to Fly published by Play Publishing in 2005. In this game you can play as either Kajko or Kokosz. Your task is to collect coins, defeat enemies, and in some levels, even fly on a broom! When I was a child, with new games I liked to press every possible key on a keyboard one by one and observing their effects on the game. This game was no different. After I pressed ~ on my keyboard, a console popped up. Back then, I didn’t understand the purpose of such consoles, I tried writing random messages, thinking that maybe this was some kind of chat, and someone would reply. Unfortunately, no one did, so I gave up and closed this mysterious window, focusing instead on playing the game. Today, armed with knowledge about game reverse engineering, we will solve this riddle!

Getting started

After we open the console, we are greeted with the message: Argon engine featuring Kajko i Kokosz. Mirage Interactive 2005.. We can type commands and execute them by pressing Enter on the keyboard, just like in normal command prompt. The question is, what commands are accepted and what can we achieve by using them?

To answer this, we will need to take a look inside the game binary. Our task is to find a function that is handling the user commands. To do so, we will use the following property: after you execute a command, the command itself is printed out to the console, so if you type ls and press Enter, ls will be printed to the console. It seems that before the command handler is executed, the print function is called. We could simply put a breakpoint on the print function and then inspect the call stack. Sounds good, but how do we find the print function? This should actually be easy. Do you remember the greeting message that is shown at the top of the console? It looks like a hardcoded string that should be easy to locate, and that string is probably directly passed to the printing function.

Analyzing

To analyze the game executable we will use Ghidra. To perform live debugging - x32dbg, both of them are open source and free to use. After throwing the binary into Ghidra, we can go to Window -> Defined Strings menu, and look for the string located at the top of the console

We see that Ghidra found one reference to that string. Let’s go there

It looks like the FUN_00431d40 is that one that prints text to the console. We will rename it to print_to_console. Now we can look up all the places from which the function is called:

As we can see, there are a lot of references to this function. We could analyze them one by one, however it would take a lot of time. A much smarter approach is to attach a debugger now. Basically, we will:

Run the game
Attach debugger
Put a breakpoint at FUN_00431d40
Write something to the game console
Inspect call stack on breakpoint trigger, so we can see from where the print was called.

After performing all the steps we see this:

So our assumption was correct; indeed after we execute any command (letsreverse in this case), the print function is called, and then the game will jump back to 00434FD0 address. Let’s analyze this function in Ghidra.

Interestingly, it looks like some commands are processed prior to printing: quit, exec and… fuck. quit closes the game, exec executes all the commands that are stored in ar.cfg file in game directory, while fuck responds with Don't make me e-mail your mom!. If any of these commands are executed, the command itself won’t be printed to the console. If the entered command is different from those already mentioned, the command itself is printed. Additionally, if the command contains a parameter, such as letsreverse 1, then another handler at address 00433ed0 is called. This can be seen in the screenshots above.

Getting the commands

The second handler contains a lot of commands. I parsed the decompiler output to list all of them:

DropDebug
credits
screenwidth
screenheight
bitdepth
runworld
mirmil
loadmodels
DrawModels
DrawToonEffect
drawfps
DrawPolygonCount
drawsnow
SnowPhysics
SnowNumFlakes
drawsky
invisible
drawshadowmesh
raportsubsets
raporttextures
sound
DrawStencilShadows
DrawDepthShadows
drawlightrays
drawgrass
detailedgrass
draweffects
lightsemitsmoke
numconsolelines
consolelog
eraselog
extractusedtextures
grasswidth
meshtospritecoef
shadowdistcoef
qualitytextures
dupadupa
raporttechs
numlights
ForceSmallerTextures
farz
fogfar
fognear
fogr
fogg
fogb
ambientr
ambientg
ambientb
skylightr
skylightg
skylightb
SkyLightRotation
SkyLightPitch
SkyShadowsRotation
SkyShadowsPitch
DrawCharacterPaths
DrawPaths
Dither
PlayerBreathe
ProjectedShadowDist
DrawSnowClouds
MeshUpdateCoef
DrawSprites
DrawScreenFilter
FontSizeCoef
MeshMaterialAmbient
MeshMaterialDiffuse
StartMenu
NoClipSpeed
DrawCameraCoordinates
DrawTreeShadows
DrawTransparent
DrawTranslucent
DrawCompass
michael
UpdateMainGame
Gamma
GammaR
GammaG
GammaB
Debug
SystemDebug
AutoScreenshotTime
EnableAntialiasing
TrilinearFiltering
DisableLensFlares
DisableInsects
TreesAlwaysFullDetail
CameraDeg
CameraDist
CameraUp

A lot of these commands are self-descriptive. The most interesting and intriguing ones, in my opinion, include:

credits - Prints out credits that are normally nowhere to be seen in the game(?)
runworld- Allows to load arbitrary game levels
mirmil - Modifies the game save file to appear as if you have completed the entire game, unlocking all levels. By the way, Mirmił is the name of the gord’s leader. The gord in which some of the game levels take place is named Mirmiłowo
invisible - Makes the game character invisible, so enemies don’t target you
michael - Sets some values in the memory. However, it seems these values are never read (as evidenced by both static analysis and setting a hardware breakpoint), so the behavior remains unknown
dupadupa - Enables speedhack and possibility to pass walls and obstacles without colliding with them. Intriguing name, especially considering that dupa means ass in Polish. You can see the command effect on the video below

Future

The reason why those commands were left in the official game release remains unknown. It is unclear whether the authors left them by mistake or intentionally. However, we can make use of them when it comes to modding. In future posts, I will show you how to print your own text to the console, and how to add your own commands.

Unpacking Encrypted Game Files

2023-12-02T20:12:34+01:00

In the last post I described a way that allowed to unpack content of proprietary format. That format was fairly straightforward with no encryption nor decompression and thus it was possible to grab files that are stored inside without even touching a debugger (we used one tho, but it was not necessary). This time, however, things will get a little bit more interesting. Today we will tackle a game from the Crazy Chicken series, to be more precise - Crazy Chicken Kart 2 (or Moorhuhn Kart 2 in original)

Getting started

First we need to inspect files in the game’s installation directory, to see where assets are stored. We can see that there is a folder named data which contains a file named mhk2-00.dat. It is the largest file, which takes about 140MB of space. This will be our target.

When we open the file in hex editor we can see this:

Let’s guess

We can try to guess the structure of the file without using any debugger. Imagine you are a game developer and you are tasked with writing a parser that will unpack and load required files to the game memory. What kind of information is needed?

File count - it is possible to create a file format without it, for example you can put the file header at the end of the content, and then iterate over elements until you meet EOF (end of file), but generally the file count is a part of a file format
Location of entry name/id - There must be a way to identify the entry somehow. It can be for example a numeric ID, or a filename just as casual file on the disk
Way to obtain the entry content location and its length

There are plenty of possibilities how such information can be stored. Let’s see what we can assume just by looking at the previous image. The very first 16 bytes form the string Moorhuhn Kart 2. We can treat it like a file header to be sure we are dealing with the right file. Multiple filenames can be seen. From the beginning of the first filename, till the beginning of the next filename there is exactly 0x80 bytes of space. This is applicable also for the next files, when we scroll the view down. For now we can assume that this space is dedicated to describing a particular file entry. Inside such fragment, there probably are our two missing elements, offset to the entry content and its length. There are two 32 bit integers. We can see that one points somewhere much further into the file, while the other is a much smaller integer, so the first one is the data offset, the second one - data length.

Now, just after the Moorhuhn Kart 2 string we can see an integer 0x456. For now assume this is the file count. We see that the first file entry starts at offset 0x40. The entry is 0x80 bytes len, and there are 0x456 files. So if the 0x456 is really the file count, at offset 0x40 + 0x456 * 0x80 is the end of the last file entry. Let’s check! And indeed. It looks like 0x22B40 is the beginning of data and at the same time the end of file entries. To be even more sure, let’s look at the first file entry and at its data offset, it is also 0x22B40! So it is even better proof that 0x456 is indeed the file count and we are reading data offset just right.

Unpacking

Summarizing all the information obtained above, we can write a simple python script that will iterate over all the file entries, extract and save their content under appropriate names.

import struct
from pathlib import Path


file = open("mhk2-00.dat", mode="rb")

# Seek to the file count
file.seek(0x20)
filecount, = struct.unpack("<H", file.read(2))

for i in range(filecount):
    # Seek to the beginning of the header
    file.seek(0x40 + i * 0x80)
    name = b""
    
    # Read null terminated string
    while (a := (file.read(1))) != b"\x00":
        name += a
        
    print(name)
    # Seek to the offset and length position
    file.seek(0x40 + i * 0x80 + 0x68)
    offset, length = struct.unpack("<II", file.read(8))
    
    filename = name.decode("ascii")
    
    # Create the file directory
    Path(filename).parent.mkdir(parents=True, exist_ok=True)
    
    # Seek to the file content
    file.seek(offset)
    with open(filename, mode="wb") as output:
        content = file.read(length)
        output.write(content)

It looks easy, isn’t it? So far it might be even easier than the format from the previous blog post. However, at the beginning of this post I promised that this will be more interesting and I didn’t lie.

What is inside?

Inside the root directory there are two items, config.txt and a directory mk2. Let’s take a look inside the mk2:

items - Contains different textures and presumably 3D objects of different game items
karts - Animations of all the playable characters in game
lensflares - Textures of flares
level0X - Configuration, textures, music, 3d objects and animations for different levels
menu - Music and textures to be displayed in main menu
misc - Fonts and HUD textures
settings - Encrypted configuration of different karts. Looks interesting in terms of modding
sfx - Different sound effects, collision, engine etc
text.csv - Translation of subtitles in different languages - interesting if you want to translate the game

Examining the results

When we look at the unpacked data it looks almost right. We can see the images and hear sound effects. However, when we open a file with txt extension, we are presented with gibberish:

It looks like the authors of the game decided to somehow obfuscate the content of text files, otherwise the text could be easily replaced directly in the .dat file, even without unpacking. As there are no checksums in the .dat file, this could lead to cheating (presumably the .txt files contains configuration of speed of different vehicles etc). To read the real content of the file we need to take another approach. As you can see, without knowing the algorithm that is used to decipher the content, it is almost impossible to progress further. Even if the algorithm would be known, we still somehow need to obtain the decryption key. Remember, the game must be able to read and understand the file content, so it implies that it knows the deciphering procedure. At the same time we have access to the game executable, this means we can discover this procedure too.

Reversing the text file decryption method

By observing the unpacked files we can see that there is a directory for each game level, inside each of them there are 4 folders, music, objects, settings and textures8bit, going deeper, inside the settings we can find 3 more folders, display, misc, objects, inside them there is a .txt file with the filename that corresponds to the directory name, so inside display you can find display.txt etc. As mentioned previously, all the txt files are encrypted.

Right now we are not interested in the way the game parses the mhk2-00.dat. We already know it. By making a list of all string references we can spot references to objects.txt.

This is probably used to grab configuration file of game level we want to play. Let’s put breakpoints on all references and run the game.

After we hit a breakpoint lets put another one on a ReadFile win api call. There is also a possibility that the whole file was read to the memory at the program start, but this would be a waste of precious RAM (especially in 2003, when the game was created) to load all the level data at once, thus it is more likely that those levels are being read from disk as needed. As we resume the execution we can see that we hit the breakpoint on ReadFile, the buffer is filled with the encrypted data, just as desired.

Interestingly, the first objects.txt to load is from level06 directory. Nevertheless we continue our journey to discover the decryption routine. In order to do so we need to put hardware breakpoint on access at the beginning of the buffer filled with encrypted data.

And boom, we landed a function that performs XORs and shift operations, this looks like some kind of decryption routine. As on the first look it is hard to judge what exactly this function is doing, it is a good idea to use the decompiler to do this for us. After opening the game executable in IDA and navigating to the same address (0x0450384) as we seen in the debugger, we are presented with this view:

Not really clean, but after renaming some variables and changing their types it looks much better:

Let’s add this function to our python script. Take a look at the last if statement in the script:

import struct
from pathlib import Path


file = open("mhk2-00.dat", mode="rb")

# Seek to the file count
file.seek(0x20)
filecount, = struct.unpack("<H", file.read(2))

for i in range(filecount):
    # Seek to the beginning of the header
    file.seek(0x40 + i * 0x80)
    name = b""
    
    # Read null terminated string
    while (a := (file.read(1))) != b"\x00":
        name += a
        
    print(name)
    # Seek to the offset and length position
    file.seek(0x40 + i * 0x80 + 0x68)
    offset, length = struct.unpack("<II", file.read(8))
    
    filename = name.decode("ascii")
    
    # Create the file directory
    Path(filename).parent.mkdir(parents=True, exist_ok=True)
    
    # Seek to the file content
    file.seek(offset)
    with open(filename, mode="wb") as output:
        content = file.read(length)
        
        # If filename ends with .txt perform the decryption
        if filename.endswith(".txt"):
            key = 0x1234
            for b in content:
                result = (2 * (b ^ key)) & 0xFF
                decrypted_char = result ^ (result ^ ((b ^ key) >> 1)) & 0x55
                key = (3 * key + 2) & 0xFFFF
                output.write(bytes([decrypted_char]))
        else:
            output.write(content)

And check how it works now:

As you can see our effort was worth it! Now the text file is decrypted and we are able to read its content.

Conclusion

Depending on the method used by the game manufacturer, sometimes it is not possible to unpack data files just by guessing the file structure. When we are dealing with obfuscation and/or encryption we need to reverse engineer the executable to obtain the decryption method. Thanks for reading.

Unpacking Garfield Game Files

2023-08-11T22:08:44+02:00

You probably heard about Garfield, the cat with orange fur that loves sleep and lasagna. It turns out he is not only protagonist of comics and cartoons, but also computer games. One of such games uniquely named Garfield was released for PC in 2004 by company named The Code Monkeys. In this post, we will take a look into the structure of files used by the game.

Getting started

After installation, inside the main directory we can see data folder, where all the assets lies. The content of audio and fmv is easily accessible, since it is not packed and files inside use widely known formats, such as .wav. More interesting things such as images, 3d models are probably hidden inside mysterious .pak files. Since this is mostly like propriety format, content of those files is inaccessible to most people, however, not for us.

The first thing that should be applied when dealing with unknown file formats is to throw such file inside your favourite hex editor. As we can see, the first 4 bytes, when converted to ASCII are equal to “PACK”. As this value is const among all the .pak files, it is mostly likely the header, so the game parser knows that it is dealing with the right file. In the next bytes we can spot “PNG” string, just before it there is byte equal to 0x89. Together it forms the beginning of the .png image. So we know that there is one packed inside this file, we also know that this is not compressed nor encrypted (otherwise we wouldn’t see the raw png header). But how long it is? Does this image have any index or name? Is it the only image in this .pak file?

The unknown bytes

Between the “PACK” and “PNG” we got 8 unknown bytes. The whole file is 0x1D8018 bytes long. When we interpret first 4 bytes after the “PACK” as little endian value, it looks like some kind of offset that is pointing to almost the end of the file - 0x1D5518. When we go there, we can see that there is a name of a .png file, so our suspicions were right. It is indeed offset to some valuable information. We still got 4 unknown bytes. We could read it in multiple ways, similar as previously, as a 4 byte little endian integer, but on the other hand maybe we should read it byte by byte? Or maybe there are two 2 byte integers? What this value represent? We still don’t know how to read the size of that png image. Questions arise, but is there a way to solve it without guessing?

It turns out that indeed, this can be solved without guessing. Don’t get me wrong. It is perfectly fine to try to solve it by trial and error method (which later in this post will be kinda continued), especially for such file format that looks easy, but to make it more entertaining and more educational, let me introduce more powerful method that will give answers to our questions.

Fun with debugger

Let’s attach debugger to the game. Obviously we don’t have the source code, so we are forced to debug it on the assembly level. For this task I will use x64dbg. The first question that immediately comes to the mind is where to look. The game binary is huge and contains millions of instructions, most of which are irrelevant to us. Good idea for the first try is to look at the string references. There is high probability that at least one of the .pak filename is hardcoded and is used as a parameter to the “open file” function. To look for string references in x64dbg we can use the button shown above. Please note the references are searched per module, so you need to be sure you are in the main one. If you want to change current module, you can go to Symbols tab and then double-click the module you are interested in.

And here it is. As the function is in the export table (a bit unusual for the .exe file), we can see its name so we can be even more certain that we are looking at the correct place

Reversing the `Load_PakFile` function

First, we put a software breakpoint inside this function and resume the program execution. The breakpoint is indeed hit and we can step through the function. Now the question is, what does this function do to the file data, how does it treat our unknown bytes? Before we answer this, first we need to understand how it is even possible that the game transfers bytes from our hard disk to RAM memory.

Reading file to RAM

You see, on modern platforms like Windows it is impossible for a user-mode application (like game) to talk directly to the hardware (like hard disk). To retrieve information from a hardware, apps need to send requests to the kernel. On Windows such requests can be send using WinAPI functions. So if you are creating application that does some actions to files on Windows, it will eventually use some WinAPI calls to deal with files (under the hood), even if you aren’t aware of that. For the purpose of our task, we are interested in functions that gives us access to files. Probably there are multiple ways to do this using WinAPI, but the most popular way for programs is to use CreateFile to open a handle, and then ReadFile to read data to RAM memory.

Breakpoints on API calls

To put breakpoint on API call in x64dbg you can press Ctrl+G and then type the name of the API function. In our case - CreateFileA and ReadFile. Just a one more thing to note. On Windows, a WinAPI function that accepts string as a parameter comes in two versions, ASCII and Unicode. The ASCII ones ends with A, and Unicode ones with W. That is the reason why there are two functions for opening a handle to a file - CreateFileA and CreateFileW. The ASCII function always call Unicode function at the end of the day, so if you are not sure which version is used by the application, it is always safer to put breakpoint on the Unicode call first. However for this game you can safely put the breakpoint on the ASCII one, as this is the function used by the game.

Digging deeper

As you remember, we are now paused at the beginning of Load_PakFile, after stepping over the third call we stop on CreateFileA, looks good so far, this means that the first call is there to open handle to the file. We go back to the function. While going back we also notice that GetFileSize and SetFilePointer are called. This might be useful later. At this point we are just after the third call. As we seen that the SetFilePointer is used, I placed the breakpoint there too and continue stepping. And it pays off, after few calls we stop at the SetFilePointer. From the WinAPI documentation we know that this function accepts four parameters. We can look on the stack, what are their values.

The first one is number that identify the file handle, it may be different on each run. Next two parameters are zero, and the last one is equal to 1 - FILE_CURRENT. So after this call the position of the file cursor will be moved by zero bytes, counting from the current position. Looks kinda useless. We continue stepping.

And we finally land at ReadFile, the first call to read file data to RAM. Now developers might use multiple different techniques, for example they can read the data chunk by chunk, or read everything at once and then parse something further in the program, but in this case, it looks like they decided to read just as little bytes as they need in the moment, look at the parameters at WinAPI documentation and compare with what we get at the stack:

So they want to read 4 bytes from the .pak file into data buffer at 0x18FDBC. After we go back to the Load_PakFile we see that those bytes read from the file are compared with 0x4B434150 or PACK in ASCII. So we were right. The PACK is a header, so the game parser can do sanity check and be sure that it is processing valid .pak file.

Again, we continue with the flow and see another call to ReadFile, another 4 bytes are being read, as you remember this is offset to the first file name in .pak file, then another 4 bytes. Those are the “unknown” to us. Now we see that they should be treated as single integer. It is interesting that the value is shifted left by 6 bytes, so in other words multiplied by 0x40 (64 in decimal).

At the end of the image above there is call to [eax+108]. This is a wrapper for RtlAllocateHeap (I stepped into it, so I know) which allocates a buffer with length equal to the value unknown bytes shifted left by 6. Next call sets the file cursor to the first file name offset and then in the loop the game reads the file by 64 bytes chunks into the previously allocated buffer. The loop is executed as many times as the value of 4 bytes “unknown” integer.

Using obtained information

We could reverse the game further, to check what is done to the data that are now in previously allocated buffer, however, we have some new information that we can apply. Firstly, the previously unknown bytes are mostly like the count of files inside pak file. Then, the offset to first filename is in reality offset to the file information header, and probably each file information header entry is 64 bytes long (as the game was reading it in chunks with that length)

Inspecting the file entry

Now, go back to the binary file at that filename offset. We see that at the beginning there is the filename. Length of the name is nowhere to be found, so we can suspect that this should be read until first null character. The last 8 bytes of the entry looks like two 4 bytes integers, their value is repeated twice for some reasons. Those values look like another offset or file length. The same with preceding 4 bytes, another offset that might be a start of the file, as it looks it is increased in each next entry.

Now we go to the suspected file start offset, and from that place we select next X bytes, where X is equal to the value of last 4 bytes of the file entry (suspected file length). We save those bytes to separate file with png extension and try to run it:

We are greeted with an image. Now we can write simple python script to automate the unpacking process, and also to verify if it works for all the files.

Code to unpack the .pak file

import struct
import os
from pathlib import Path

destination = "output/"

# Set the filename to unpack here
with open("startup.pak", mode="rb") as file:
    header, files_info, file_count = struct.unpack("<III", file.read(4*3))

    for i in range(file_count):
        # Go to header of the file i
        file.seek(files_info + i * 0x40)
        
        # Read the filename until 0x00 byte
        filename = b""
        while (read_byte := file.read(1)) != b'\x00':           
            filename += read_byte
            
        filename = filename.decode("ascii")
        print("Unpacking {}...".format(filename))
        
        # Go to the file placement information
        file.seek(files_info + i * 0x40 + 0x34)
        start_offset, length = struct.unpack("<II", file.read(4*2))
        
        # Go to the beginning of the file data
        file.seek(start_offset)
        
        # Create required directories
        output_path = destination + filename
        os.makedirs(Path(output_path).parent, exist_ok = True)
        
        # Write the data to file
        with open(output_path, mode="wb") as output_file:
            output_file.write(file.read(length))

What is inside?

All files has been unpacked so far, and it looks it worked correctly, as the txt files can be read, the same with png images. For the purpose of game modding, the fonts directory may be interesting, as it contains fonts and dialogs in different languages, so for example if you would like to translate the game to your language, you could modify those dialogs and then repack the files back. What is interesting, when I run the game the language is set to Polish and it looks it cannot be changed, but there is no Polish font in the fonts folder. It turns out the file named english.lng contains the translated Polish dialogs.

To prove this script works for other files, I unpacked some of them, like attic.pak the content is a little bit different and consist of extension such as:

png - It is probably obvious, images of some assets, loading screens etc
rws - This is the most mysterious file extension, probably contains animations, textures
ape - This is plain text file, contains description where checkpoints are on the map, and some information to assist the AI
bin - Probably meshes

Conclusion

As you can see, it was not that hard to make sense how the pak file is structured and then to make script to unpack the content. In future posts I will try to show examples with different difficulty levels (encryption, compression). Thanks for reading.

let’s reverse

Calling Game Functions from Your Own Executable

Understanding Function Calls and Calling Conventions

Obtaining required information

Call the function

Testing the DLL

Unveiling Hidden Gems: Exploring Easter Eggs Through Game Reverse Engineering

Getting started

Analyzing

Getting the commands

Future

Unpacking Encrypted Game Files

Getting started

Let’s guess

Unpacking

What is inside?

Examining the results

Reversing the text file decryption method

Conclusion

Unpacking Garfield Game Files

Getting started

The unknown bytes

Fun with debugger

Reversing the Load_PakFile function

Reading file to RAM

Breakpoints on API calls

Digging deeper

Using obtained information

Inspecting the file entry

Code to unpack the .pak file

What is inside?

Conclusion

Reversing the `Load_PakFile` function