Go Back

Rift - The Entities

For the purpose of this blog I will refer to an older version of Rift (an open beta version, dated 20-2-2011), since the latest version is missing some of the IDA info (lazy :) and I expect you to have some IDA and debugging knowledge and I expect you to have the decompiler plugin as well.

Well I said I was going to blog about Rift, so here is the first in a few blogs about Rift. I will not have any code-samples for you to play with and you will have to lookup the latest pointers yourself (if you wish to play with this info). But I'll try to explain how I got the info that I needed.

The first thing I am usually interested in when looking at a new MMO is the way it stores its entities, you know the other players, the npcs, etc. Knowing how the game stores it's entities is vital for creating bots, radars, etc. It is not vital for float hacking, teleport hacking and speed hacking, but I usually stay away from those types of hacks.

We know what we are looking for, but the question quickly arises "how do you look for something like that", well luckily for us hackers most new MMO's have in-game commands and functions to help you out. Rift also has a command which helps you to find this and it's called "/target". With that nice command you can target anything in-game by name. As such this command must (somehow) loop through all the entities (or at least part of them) to find out which entity you want to target.

So the first thing we want to do is find the function responsible for the target-command, we open up IDA's string-list and look for "target" and we look at the references to "aTarget" (the variable name IDA gives it), one line stands out which is "mov eax, offset aTarget". If we visit the reference, we find a function which is pretty empty. If we check the reference of that function, we see its a virtual function of a class. With a bit of trial/error, it was easy to find out that the class in question is indeed the target-command class, and the 3rd virtual function is the actual SlashTarget function (we will call it SlashTarget from now on). The process of finding the correct function differs per game, but in this case it was easy.

If we open up SlashTarget we see a reasonably large function, which does a lot of things. Most of which we do not care about, the one thing we do care about though is the string "No target with the name: [%NAME]", it indicates that the target we are looking for does not exist. If we look a bit up (in the decompiled view) then we see that a function is called prior to the "if" that leads to the "No target" string. In this case it was sub_64A500. If we open up that function we see a "while (1)" loop.

I will spare you the details, while the loop does loop through all the entities. It is not looping through the actual entity list but rather a copy of it. Having no idea how it got this copy, I did something that I usually try to avoid (with a passion), I opened up OllyDBG set a breakpoint at the start of SlashTarget and at the end of SlashTarget, used the command and traced all instructions. This is a horrible way of reverse engineering, but it does work :) (note, I did have to enable "Remember memory" in the debugging -> run trace options of OllyDBG)

Ending up with a 100-150mb tracelog, you can understand why you'd want to avoid this. However it does give meaningful insight. The way I went about it was to do a "/target <someone>" and having the name in lowercase. This way I could see the difference between the entity name and the target-command argument. Now I looked for the first occurrence of <someone> in the correct case. From there I back-traced all the pointers to its origin.

The first occurrence of the pointer was inside the function (sub_6E0100) that copied the entity list. Back tracing where it was called I found out that it was indeed called from sub_64A500, and to be more precise this line "(*(void (__thiscall **)(void *, struct tm **))(*(_DWORD *)v8 + 0x18))(v8, &Tm);" (yeay for IDA screwing up half of rift by adding some TM structure).

It's reasonably easy to find out what function is at 0x18, if you look at the v8 you see its filled by a function a few lines above the call. If you look into that function then near the end you will see that it is actually setup by another function. Then if you dive into that function you'd see what the class v-table is. If you go to the v-table and get the function at 0x18 (the 6th function), the function should look like this. If you then dive into that function you will see sub_6E0100 being called.

If we inspect sub_6E0100 we'll probably agree that it's a bit of a nasty beast. At least it took me a few tries to get the data out correctly (at least I think I have it correct now). I can't remember how I exactly found out, but the EntityManager that I marked when looking for the v-table has the entity array that this function is looping through at offset-4 and the length (parameter a3) at offset-8. I am pretty sure that was from back-tracing the trace-log.

After a lot of trial and error (and trying to figure out how the freaking sub_6E0100 function worked), I came to this C# code:

var entityManager = memory.ReadInteger(_entityManager);
var entityArray = memory.ReadInteger(entityManager + 4);
var entityArrayLength = memory.ReadInteger(entityManager + 8);

var items = new List<int>();
for (var i = 0; i < entityArrayLength; i++)
    var entityArrayItem = entityArray + i * 0x18;
    int nextAddress = memory.ReadInteger(entityArrayItem + 0x10);
    if ((nextAddress & 1) == 1)
        nextAddress ^= 1;
        if (nextAddress == 0)

    while (true)

        entityArrayItem = memory.ReadInteger(entityArrayItem + 0x10);

        if ((entityArrayItem & 1) == 1)
            entityArrayItem ^= 1;
        if (entityArrayItem == 0)

I did a few compares a bit differently then the original Rift code, mostly because I wasn't getting the expected behavior in C# (mainly the ^= part).

Basically from analyzing the function I came to the conclusion that the EntityArray is not 'really' an array but more a hash table. The initial item's are in the array (0x18 bytes in size) and if more item's are in the same bucket, then the next item is stored at 0x10 . The entity id is stored at offset 0 (its a ulong) and the pointer to the entity itself is stored at offset 8.

Why the first bit is sometimes set when there is also a pointer in at 0x10 is a bit unclear to me. Perhaps someone else can shed some light on that ? :)

The above code sample does get all entities. My next blog (that I'll put up in a few days) will explain a bit about how Rift stores data for its entities (if you have a beta-exe still lying around, look for the "EntityComponent"'s).

This game takes OO very serious, things are stored so many level's deep it's very annoying :)

Posted by: Da_Teach on Saturday, March 5, 2011  •  Comments (107)  •  Full story  •  Rift Decompiler IDA Pro

Trine Part #2

I planned to write this blog a few days ago, but my main PC (the one I hack on) decided to die on me and couldnt get it fixed until late last night. But its up and running and I finally got around to finishing my trainer for Trine.

As mentioned in my previous blog, turning on "Unlimited Health" made enemies invincible too. That ruins the playability of the game a bit. So one of the first things you check is to see if the function that decreases health is used on a different spot for players then for enemies. This wasn't the case, my guess is that the players are part of the same entity-array as the enemies.

Since we couldn't use that as a base-reference, I did a quick search  (using Cheat Engine) for a static address for the player-structure. Perhaps its in there somewhere, but I got bored of looking for it ;)

So whats left? Well figure out how the game "knows" its a player instead of an enemy. I wont post the entire decompiled function (it has 1300 lines!) but you can download it by clicking here.

If you download the function, then you'll see that at line 1254 the new health is calculated. Whats interesting is the part where it would decrease the damage by certain collectible items. It starts at line 1186 and ends at 1249. Now I didnt really care to figure out what it did there, but the if at line 1186 was interesting.

This "if ( (a2->byte212 && a2->dword1D4 || a2->dword1CC) && a2->dword960 != 1 )" basically checks if the current entity is the player or an enemy, as enemies don't have items. Some further analysis (using pointers found with Cheat Engine) reveals that pointer + 960h = 2 for a player while its 1 for enemies.

Now we have a way to check if the type of entity (who's health is being decreased). Now we have to modify the instruction at 691BB2h to only decrease health for enemies. However we can't magically add instructions to an executable, so we have to allocate some memory (or use a codecave, but thats something for another day) in Trine, write the instructions in there that we want to "add" and then redirect the program flow to this newly created piece of code.

First we have to write some assembler which we can write to the allocated piece of memory, I chose for this:
cmp dword ptr [ebx+960], 2  // Check if its a player
je 691BB8 // Yes, jump back
mov [ebx+254], esi // No, decrease health
jmp 691BB8 // Jump back

What we basically do is check if its a player, if it is we jump back to the original function, if its not we decrease health and jump back. We have to decrease the health, because thats the function we are replacing. You could possibly change "mov [ebx+254], esi " into "mov [ebx+254], 0" which would instantly kill everything when you hit it.

After we created this code inside our newly allocated memory, its just a matter of replacing the instruction at 691BB2h with a jump to our piece of code and voilla. Players stay alive and enemies die.

I made a small trainer which you can download here. It includes a modified "Unlimited Energy" as nop'ing that function didn't always have the desired effect. My new modification is to always write the maximum energy into the current-energy field.

Posted by: Da_Teach on Saturday, January 16, 2010  •  Comments (13)  •  Full story  •  Code Injection Trine Decompiler Trainer

Defense Grid: The Awakening Part #2

Since Defense Grid: The Awakening used a, for me, unknown PE Packer, the easiest way to disassemble it is to dump the executable once you have started it. There are various tools out there which allow you to do this, I used LordPE it's easy to use and has a ton of options which I didn't use ;)

The output of this dump is not a working executable. It is possible to create a working executable, but it requires more work which is often not worth the effort. The only reason I could think of would be if you wanted to pre-patch the executable, however this often is only required for cracks.

Anyways, back to the game. We now have a dumped executable which IDA Pro can actually disassemble and with the help of the Hex-Ray's wonderfull decompiler add-on, we where able to convert the function which contained the credit-modification code to semi-readable C/C++ code. While I can read assembly code, its a lot harder and more error prone.

The decompiler has some limitations, for example it can't decompile MMX instructions. If it could, the code would probably be a lot easier to understand. But here's the decompiled function (sub_8BB110)(note that I have circled parts of the function which are of interest):


As you can see, just before the instruction that modifies the credits, _EBX is filled with variable v27, that variable in turn is filled by sub_47E6E0. This might not be clear until you disassemble sub_47E6E0. As you can see in the disassembled code of function sub_8BB110, a pointer was given to v26 but in sub_47E6E0 the result is actually put into v26 and v26 + 4. The last addition actually causes function sub_47E6E0 to write into v26 and v27.

Here's what sub_47E6E0 looks like:


I've added some names to the parameters, one of the parameters "basePointer" is especially interesting. In sub_8BB110 you will see that "basePointer" is v25 + 16. Now the fun part is that if you look back in sub_8BB110 you will see that its filled by v6 + 4. Now its not hard to guess that the same trick done by sub_47E6E0 was done by sub_47E1B0 as well. If you look at sub_47E1B0 you will see a very similar function:


Note that the basePointer for this function is dword_B458E8 + 44.

This however only explains 2 of the 3 parameters to get the pointer to the value we're interested in. The 3rd parameter of function sub_47E1B0 and sub_47E6E0 are actually lookup values. I've called them type values in my disassembly though. These type values originate from a2 (v23 is filled with a2) and a3.

We know that the value that we are looking at is at pointer + 0x10 and if you look at sub_47E6E0 you will see that type-value that it looks for is at 0xC (12). So if we go back to Cheat Engine and decrease the pointer of "credits spent" by 4, we will know the lookup value for the "credit spent". In our case its 9. It wouldnt be hard to find the starting-credit lookup value either, but you can do that yourself ;)

This still leaves the lookup value for sub_47E1B0 (a2), for this we look at the usage of sub_8BB110. If we look at the cross reference of that function and goto the first usage of sub_8BB110, we will see that a2 is filled with dword_B458C4+212. Now I havent fully tested it, but I assume that value always has the right lookup/type value. In testing that turned out to be true anyway.

Now that we have the pointer-lookup scheme of the game, we can write a trainer which uses this information to increase / decrease the credits spent. In part #3 I'll show you how I converted the pointer-code into an external program (trainer) which will increase or decrease the credits spent.

Posted by: Da_Teach on Saturday, January 2, 2010  •  Comments (13)  •  Full story  •  Decompiler IDA Pro Defense Grid