Reversing the Supreme Commander 2 Engine

Last year a few friends I play games with introduced me to the supreme commander series. At first I was a little skeptical of it but after a few hours of playing it started to remind me of the good old days jamming on Command & Conquer. If you haven’t heard of it, Supreme Commander 2 (or SupCom2) is a RTS game where you build an army and try to take out other players. Compared to other games of the genre it’s very fast paced and has a few unique features.After tinkering with the game for a bit, I became interested in how the was implemented under the hood.

In this post I’ll simply be detailing the process I took for pulling this game apart and getting useful information. Once of the most common questions I get asked is “Where do you start when you don’t know anything about the game?”. Well the simplest answer is to go and find some info. Even if theres nothing, you nearly always have something displayed that you can use to start from.

What We know

After a bit of googling we can find a bit of information to give us something to start with

  • It uses the Moho engine which seems to be developed inhouse for these games
  • Makes heavy use of lua scripting
  • Uses D3D9 for rendering

I had a poke around to see what mod developers tend to do for this game, thinking someone would have done a bit of reversing on this game already considering its age but I didn’t really find anything. Most large modding projects tend to just hook the lua system or just use the existing lua mod system which the game provides.

Fuck lua

Determining Class Hierarchy

My first objective was to try map out how the games classes hierarchy was structured for storing all the main gameplay elements such as units and my resources such as mass and energy. I started out with doing a full process dump while in a local skirmish match and letting IDA analyse it. Meanwhile I decided to take the easy road and try find my current mass. Once I found it, I let a debugger break on access and started exploring the code which was accessing it.

The first thing we get is a class which I’ve just called ArmyResources as the resource values and rates are the only things of use I ever found inside them. There’s no RTTI info for this class so god knows what its actually called lol

From here I applied 2 simple techniques for moving up the class hierarchy:

  • Following the callstack up
  • Referencing constructor calls

I started off with the callstack tracing, seeing as I had already a debugger attached in the middle of code accessing data I was interested in using. Most of the time, the thing that I wanted was being accessed as a member of some class. Nearly all of the time this class was passed in as a parameter to the current function or was the this pointer sitting in ecx. Making use of nice debugger features like “Break On Return” made the process of seeing how these parameters were set made this process pretty fast, but the same could be achieved by just following the return addresses on the stack.

While I was doing this, I was following the code along in IDA naming stuff I had found, and also adding the pointers and lists being accessed to classes in Reclass.

After a while I had a class called Sim which seemed to be a world style class containing everything going on in the game currently. I decided to switch up my technique here and take a look in IDA to see if any global pointers are kept to this class. Luckily for me, nearly all the core game classes have virtual function tables and RTTI info to go along with them. Making use of plugins like Class Informer helps a lot with games like this.

Crossreferencing the vtables of the classes I was interested in quickly led me to what classes their pointers where stored inside and exactly where they were. Eventually I ended up in a function which seems to handle the different stages of setting up the engine when starting a new game( search for the string “DoLoading” to find this function yourself). Near the bottom of the function just above “DoLoading 6” we see the following:

.text:00A8182D                 call    Moho__SimDriver__SimDriver
.text:00A81832                 mov     ecx, g_pSimDriver
.text:00A81838                 add     esp, 10h
.text:00A8183B                 mov     g_pSimDriver, eax

Sweet, the SimDriver constructor is called and the pointer is placed in a global which we can access. This class contains a pointer to the Sim instance as well as a few other interesting classes which we can use. You can find the current address for the SimDriver HERE.

At this point, I had a classlayout something like this Class Diagram

Common Engine Structures

After a bit of exploring the classes we have access to I quickly noticed a few common structures that were being used a lot. One was a String class and the other was an Array.


Firstly, strings in this game are stored in an interesting way. I noticed my name being stored in a class and noticed it was being stored inline in a 16 byte block followed by the length and allocated space. But what happens if you have a string longer than 16 characters? Well thats the nice thing about this being my name, so I just changed it. StringViewA StringViewB

We end up with something like this in the end

class MString
		char* m_pText;
		char  m_chBuffer[16];

	int m_szTextLength;
	int m_szBufferSize;


	inline std::string get()
		return m_szTextLength < 16 ? m_chBuffer : m_pText;

	inline int length() { return m_szTextLength; }
	inline int bufferSize() { return m_szBufferSize; }


This ones pretty easy but still, you’ll see it used a lot around the engine. The example usage I’ll show is the army list inside of Sim. This I found way back when following the callstack back up chasing my resources. Inside of an game tick / update function beloning to Sim, I noticed it was updating each of the armies as following in IDA:

army_index = 0;  // This updates each army in the game
if ( (this->armylist_end - this->armylist_begin) >> 2 )
        (*(**(this->armylist_begin + 4 * army_index++) + 0x48))();// index 18 = army::updatetick
    while ( army_index < (this->armylist_end - this->armylist_begin) >> 2 );

Well, thats easy enough.

template<class T> class MArray
	T* m_pArrayStart;
	T* m_pArrayEnd;

	T* begin()
		return m_pArrayStart;

	T* end()
		return m_pArrayEnd;

	size_t size()
		return (reinterpret_cast<uintptr_t>(m_pArrayEnd) - reinterpret_cast<uintptr_t>(m_pArrayStart)) / sizeof(T);

	T& operator[](int index)
		return m_pArrayStart[index];

Fleshing out classes

Well we have a way to access a bunch of classes now, but thats no use if we don’t know how to do anything with them. The first place I looked for hints at where important stuff might be stored in the classes was their virtual functions. As most of the classes had RTTI info it was pretty easy going. I was still interested in finding my units so I decided a good place to start would be the SimArmy class.

Eventually I found a list of Platoons in the army starting at 0x2C0. Inside there was a list of some other class I called UnitGroups. The unit groups contained a list of Units! Woo

Units can be pulled appart in the same way, also just looking at their memory in reclass reveals a few useful strings and vectors etc. Another useful way I found things was looking at the lua function implementations. For example, if we wanted to know where a units health is stored, we can go search for the lua function to get a units health. We end up finding a function such as the following:

HealthFunc HealthFuncPsudo

It’s pretty easy to see that the health of an entity is at offset +0x8C. But looking at a unit in reclass you will quickly see that they are structured with the unit vtable pointer, a 4 byte member, and then the entity. So we need to add 4 bytes for the vmt pointer and 4 bytes for the unknown member, ariving at the health being at Unit+0x94, which can be seen in my class Here.

This same process is used for most of the classes I found in the game.

World to Screen projection

One thing every game hacker wants to be able to do in any game is to draw a HUD to display information about objects in the world. Most of the time, it is useful to have the camera view and projection transforms used by the engine so that we can use simple 3d math to project world coordinates onto our screenspace.

Where do we start when looking for this stuff in a new engine? Well this game uses D3D9 to render so lets start there. To get access to a state in the game where we know that these transforms will be set for certain, I hooked DrawIndexedPrimitive and used a stride logger to find the stride used for rendering game objects such as units and objects around the game object.

The first thing I tried was to see if the transforms were set for the d3d9 device transformation states, using the GetTransform function. After checking the contents of the matrix given it was clean these weren’t set. This wasn’t very suprising, this technique is pretty deprecated at this point, even though this is an old game most people still prefer not to use these functions.

I then tried the more likely place, the shaders. Still in the DrawIndexedPrimitive hook from earlier, I retrieved the vertex shader from the device and used the D3DX Library function D3DXDisassembleShader to disassemble the shader. You can see the output here. The comment provided at the top gives the most interesting information here, a list of constant parameters passed to the shader program, one of them being a 4x4 matrix called ViewProj. Using GetVertexShaderConstantF on the c7 register while in the DIP hook allows you to retrieve the matrix. Transposing it and giving it a try with D3DXVec3Project confirmed it is working.

Some people would just stop here and use this method to retrieve the matrix, but I’d rather not be ghetto and actually find where the games storing this matrix itself. So onward we go!

Unfortunately my work got ghetto anyway, I hooked SetVertexShaderConstantF and set a breakpoint on calls only setting the c7 register containing the matrix we want. After looking around a bit I noticed a lot of renferences to a class Camera class, so I decided to focus my efforts on finding some to get an instance of this instead. Following the call to the constructor, it didnt take long to find what I was looking for, a list of cameras. I was pretty certain I had the right place at this point so just eyeballed the data and recognised what I was after, comparing it to the matrix I had gotten from the shader constants. You can see here where the matrices lie in the cameras if you are interested in using them.

After this work, making a simple unit ESP is very easy with information we have about the units already:


LUA Execution

Look, I’ve barely touched lua before and I only thought of looking into the lua engine because so much of the game uses it. I really didn’t know anything to do with the technology or libraries available so just decided to search for what other people do. After a bit of exploring on the internet it looked like what I needed was two functions, luaL_loadbuffer and lua_pcall.

The I decided the best place to start would be the Lua github. I did a search for the luaL_loadbuffer function and found this call, which had a debug string just sitting next to it. I for the string (“=(debug command)”), and sure enough I got a hit.


One thing caught my eye though, a string referencing something called “KoreVM”. A bit of googling revealed that its a lua implementation owned by Havok make for games. So I knew this wasn’t just vanilla lua. Looking inside the function which at first I believed to be luaL_loadbuffer, it turned out it was actually a wrapper that executed a script completely:

signed int __cdecl luaL_execbuffer_ukn(int state, const char *script, int number)
  int v3; // eax@2
  int v4; // eax@2
  const char *v5; // ST08_4@2
  signed int result; // eax@2
  int v7; // eax@5
  int v8; // eax@5
  const char *v9; // ST08_4@5
  int length; // [sp+0h] [bp-14h]@1
  int error; // [sp+10h] [bp-4h]@1
  signed int error_1; // [sp+10h] [bp-4h]@3

  length = strlen(script);
  error = luaL_loadbuffer(state, script, length, number);
  if ( error )
    v3 = sub_41B060(state, 1);
    v4 = sub_F0917A("%s\n", v3, length);
    fprintf((v4 + 64), v5);
    result = error;
    error_1 = lua_pcall(state, 0, -1, 0);
    if ( error_1 )
      if ( !sub_41AE60(state, -1) )
        v7 = sub_41B060(state, 1);
        v8 = sub_F0917A("%s\n", v7, length);
        fprintf((v8 + 64), v9);
    result = error_1;
  return result;

Atleast at this point, I had found the two functions I needed. Still, out of interest I decided to poke around, after all I still needed the state to execute stuff. Looking at the very first xref to loadbuffer, I found a nice function which was a complete wrapper for lua execution, only requiring the state pointer and the script text:

char __cdecl LuaExecute(int state, const char *script)
  int lua_state; // ecx@1
  int v3; // esi@1
  char result; // al@3
  unsigned int lua_state_; // [sp+10h] [bp-18h]@1

  lua_state = *(state + 0x1C);
  v3 = (*(lua_state + 32) - *(lua_state + 36)) >> 3;
  lua_state_ = *(state + 0x1C);
  if ( luaL_loadbuffer(lua_state, script, strlen(script), script) || lua_pcall(*(state + 0x1C), 0, -1, 0) )
    sub_41B060(*(state + 0x1C), -1);
    lua_pop_maybe(lua_state_, v3);
    result = 0;
    lua_pop_maybe(lua_state_, v3);
    result = 1;
  return result;

Crossreferencing this function gave me a call to help try find the state. The call was being passed a member of a class as the state. I just slapped on a debugger and checked out what this class was and luckily enough for me, it was the Sim. I now had everything I needed to execute lua scripts in the context of the Sim.



I hope this has maybe helped someone looking for a little guidance about what to do when reversing a game with absolutely no starting info. In short… get some info. Even the smallest details and finds help out in the long run. Horde every little class you find.

If you want to see the full repo of stuff I’ve found in this game, you can find it here

Written on February 10, 2017