So I finally took the time to look more thoroughly into the Unreal 3 Engine. Found this forum that has some info on the engine, so I decided to take a closer look. The forum doesn't really explain the memory model of the engine, so I had to figure out a lot of stuff. I have to say, I still don't fully grasp the class/archetype/etc structure yet, but I'm getting there.

With the info given on the forum I was able to write a basic framework which will enable manipulation of almost any UE3 based game (though the pattern match is currently lacking and will fail on several games).

I won't release the source code of that framework just yet, but I'll release a Proof of Concept trainer for Dungeon Defenders. This trainer should work on any version of Dungeon Defenders as it detects all required variables using pattern matching.

This trainer has no options and has to be running in the background while you play. It'll do the following things:

Make (almost?) all towers cost 0 mana and 0 defense units

Will make the bonus XP that you buy in your tavern fill an entire level

Increase the loot you get from chests (both amount and quality)

Decrease cost of upgrading armor/weapons/etc by a *lot*

Gives all Mage towers/players/crystals 100.000.000HP

Increases damage done by Mage towers by a ghazillion :)

Sets 'TheStartWave' to 1 (so if you start at wave 25 , the game will think you started at wave 1, which increases loot quality)

Increases damage done by players by 100 times

Using this on Ranked servers will probably get you banned, so use with care.

I bought a few more steam games on friday (F.E.A.R. 3, DeusEx, Brinck, Fall out series, Duke Nukem) and ran into the annoying crash-at-breakpoint again. This time, however, I decided to put some time into it to try and find why this is happening.

After a lot of googling I ran into this blog post:
http://nsylvain.blogspot.com/2007/08/threadhidefromdebugger-but-why.html

While it does not specifically mention Steam, it does explain why WinDBG (and other debuggers like OllyDBG and C.E.) crash the game when a break point is triggered. Windows simply does not tell WinDBG about the break point and as such it crashes the game (as the game can't handle it either).

So I spend several hours figuring out ways to circumvent the "ThreadHideFromDebugger" flag.

At first I tried to undo the "ThreadHideFromDebugger" flag, but apparently once you've set this flag, it stays on (there's no way to turn it off on a thread). I then tried to access the ETHREAD structure which gets modified by "NtSetInformationThread" but apparently you can't get access to the ETHREAD structure from User Space (at least not in any way that I could find).

So the only way to get rid of the "ThreadHideFromDebugger" flag is by not letting the application set the flag. There's two ways to do this, stop it in user mode or in kernel mode. Kernel mode is nice, but it really isn't funny to BSOD your system a lot while developing the driver. Also the whole 'need it to be signed' part for x64 sucks. But this is still a valid option which I might look into.

But I decided to write a user mode DLL which you can inject into Steam. Once it's injected, you simply have to start the game you want to debug from within steam and the DLL does all the work for you. It hooks 3 functions, CreateProcessA/W and NtSetInformationThread, the NtSetInformationThread hook is responsible for actually disabling the "ThreadHideFromDebugger" flag. The CreateProcess hooks are used to hook any game launched by Steam.

There's 1 big *read this*, do *not* start VAC-games (and probably also PunkBuster games) with this DLL loaded into Steam! It will most likely get you banned. Also a small disclaimer, only use this to cheat in single player games. Cheating in online-games is wrong mkay! ;)

It seem's that I did something to annoy Trion, as they have banned all my accounts for 'automation'. I'm not entirely sure how they detected my program, considering I kept it all private. I suspect (but can't prove it) that it was caused by the Line of Sight check that I used. But someone else suggested it had to do with "actions" per minute/second/whatever.

It sucks a bit since I was still enjoying the game, but such is the life of a hacker. It does coincide nicely with my vacation though, going away for 3 weeks on the 26th. Looking for the sun in southern Italy.

When I get back I'll devote more time to this blog again, I've been slacking due to my fun in Rift. Like writing an article about finding a static pointer to variables that are stored several levels deep.

It seems a new DLC made Defense Grid popular again, so here's an updated trainer.

If any other trainer is not working, let me know and I'll update them. If you have any requests for game-trainers, also let me know. I can't promise anything, but sometimes I'm bored and I'll do trainer-requests.

A few people asked me for example code, so I wrote a small proof of concept Entity Reader.

This will basically list all entities in the memory of Rift and list various properties of the entity components. It will also list extended Player/Target information and list group / raid info. This is far from all the available data, but it's all that I have thus far.

If you decide to use this, at least give me some credit and don't try to pass this off as your own work! Other then that, use this as you wish (keep in mind that on the actual source, my usual license still applies).

Also, I will *not* be updating the offsets / pointers /etc. Also if your not a developer/hacker then this proof of concept won't help you. It's not compiled and does not do anything past listing all the entities!

Note, the proof of concept no longer works due to version differences, but it does give the general idea on how it should work (if you update the pointers using my other blogs, it'll probably work again)

My previous blog basically showed you how I got all the entities from Rift, but it did not show you how to get the needed data from the entities. Thing's like 'what type of entity is it', 'where is it located', etc. In this blog I'll try to explain how I found out how Rift stores this data.

As with my previous blog, I wrote using an open-beta executable. For this part it is a must. The release-executable no longer contains the information that I will be talking about, which will make it a whole lot harder to find out which entity component your dealing with.

When analyzing Rift (when looking at how it handles entity data) you will often see code that looks like this:

The dword_12055DC usually varies, but the code is almost always the same. Although you might sometimes see it mixed up in other if-statements (usually it's only the first line of the above block).

Basically every entity in Rift is build up out of several components, the code that is shown gets the entity component address (if the component exists). From what I gather, each component has an id/index. When a component gets added to an entity, it's component index is used to look up the index of the address. Why the component index isn't directly used directly to get the address is a bit of a mystery to me.

The above code however does not get you very far, considering there are likely around 64 possible entity components. To find out what entity component the game is accessing you need an open-beta executable. They removed the string-names (for each component) from the release.

If we look at the cross reference of dword_12055DC, you will notice that there is one line of code that stands out "mov eax, offset dword_12055DC". This line is shared between all entity components. If we go to the function, you will notice that the only thing it does is return the offset. If we cross reference that function, we will notice its used in a v-table.

We're interested in the first function in the v-table, usually (always?) the constructor, to give us a clue on which component it is. The release executable has no info for you there (as said they removed all string references). However the above component had this constructor in the beta:

Now isn't that lovely, we just got the name of the component. While it doesn't magically give you all the information that you need, it does help you understand what it is used for.

For me, 5 components where of interest:

The ClientEntityComponentActor component, it stores health of the entity

The ClientEntityComponentPlayer component, it stores the player's name

The ClientEntityComponentNPC component, it stores the NPC's name (but only if it is different from it's original name)

The ClientEntityComponentMod component, it stores the entities faction

The ClientEntityComponentTransform component, it stores the location of the entity

I will not go into detail on all of these components (heck I don't know half of the info that is stored in them), but I will go into two. The Transform component and the Player component.

The Transform component is the easiest of them all. We have to look up the /loc command. Using the same technique used in the previous blog. When looking at the code of SlashLoc, we notice that it uses an entity component (ClientEntityComponentTransform) and right after that it loads a couple of variables from the address.

You can probably guess what it loads. As I said, this was the easiest (and I wasn't kidding! :).

The Player component probably stores a lot more then "just the name" but I only needed the name. Unlike the Transform component, the player's name is stored 2 levels deep.

To find the player name we go back to the SlashTarget function from the previous blog, and we go into sub_64A500 again. We look through the function and dive into sub_5E5110 and then dive straight into the only function in there as well. If you look into that function, you will see three components being used. There's a big if-statement, checking if there is a player address or not. We are interested in the first function that gets called when there is a player address (sub_616270).

If you look into that function, the first code line reads as follows (in the o-beta exe) "sub_57B7E0((void *)(*(_DWORD *)(this + 0x2C) + 0xA0), (int)&v3);", and guess what. In the open beta, the pointer at "((playerNameAddress + 0x2C) + 0xA0)" pointed to a unicode string with the player name in it. In the release its 0x2C + 0x180 .

The use of entity components makes it a lot harder to find values that your interested in. I, for example, would love to find out the class of a player. But haven't gotten around to looking at where the game stores it. Health took a while to figure out, I found that using a debugger and simply back-tracing each of the pointer addresses.

For the standings/faction I used "SlashFollow", since you can't follow enemies the game must check the standings in "SlashFollow" (and it does).

I have no code example for this part, but if anyone is interested, I could make an example for it. Leave a comment if you are (or if you have questions).

One small warning, there's some extensive error checking inside Rift, crashing the client (or pausing the debugger too long when performing certain actions) can get you banned! Be careful!

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:

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 :)

Since I only seem to have fun botting in eve, and not so much playing eve. I figured I'd take a look at what's out there. A friend of mine had a Beta-invite for Rift, so I started looking at that.

It seems like a fun game, although it resembles Warhammer a lot. But it looks like me and my friend will be playing that for a bit. And I could never play a game without hacking it, so I started doing some exploratory hacking and thus far found coordinates of all entities and player names (they store npc-names differently, haven't gotten around to that yet).

Are there any people interested in any type of Rift hacks? Note, I won't do a full bot, it's no fun. But perhaps a Radar? Or perhaps some float-hacking?