FPS (or MMORPG) Game Hacks

[CycloWizard]

I haven't had time to play any computer games since... 2004/early 2005, but I used to play quite a bit of Quake 3 online, which was preceded by some LAN Counter-Strike when I first started college (fall 1999 when CS was in early beta). Not long after getting in to these games, I would run in to cheaters online. The most common ones were wall hacks, aimbots, anti-recoil scripts (CS only), and auto-fire bots.

My question is: if the game is not open-source, how does a programmer interface with the game? It seems like a wall hack would require someone to change the way the game is rendered, which would require access to the compiled functions within the game (I think?). An aimbot would probably also require some sort of interaction with the game code (or, at least, very fast image analysis, which I doubt could be done in real-time). I suppose an auto-fire bot could utilize higher-level functions or image analysis to take signals from the game and return a "shoot" command.

I was wondering if anyone could explain how this sort of thing works. Are functions compiled in DLLs accessible or "visible" to users who do not have access to the code? If not, how did all of these idiots figure out how to cheat?

If this is inappropriate because it could be used to actually write such a program, I'll withdraw the question. I just downloaded the Q3A source so I could read an example of what a real programmer's code might look like for such a program and it got me thinking about this. Anyway, just curious on what information was available based on having a DLL or how hackers got this information.

 

[DaveSimmons]

Decompilers can bring compiled code back to a form of source, just missing nice variable names and comments.

Assembly can be altered without even doing that. For example if there is a jump to an early exit if the copy protection check fails, the jump instruction could be changed to some no-operation codes that then continue on as if the check had succeeded.

Some game mods where they don't have the source code (Jagged Alliance 2 Urban Chaos) alter the exe file like this for good instead of evil.

 

[CycloWizard]

Thanks for the reply. Again, pardon my ignorance, but is compiled code pure assembly? I'm not sure what else it would be, but I ask because I would be interested to learn how decompilers work if they can recreate code from assembly. I suppose I can see how it might work, but I would think that the resulting code would be pretty ugly.

 

[DaveSimmons]

See here:
http://stackoverflow.com/quest...s-there-a-c-decompiler

> I would think that the resulting code would be pretty ugly.
Right, but it's worth it to some people to spend dozens of hours working through it to help people steal games and/or cheat in them. People who can't create something positive can sometimes still feel worthwhile by tearing things down.


For modders, if the game source code isn't available they may still be able to make small changes by patching in bits of new code and changing built in data like weapon names and specs or character names.

 

[Markbnj]

Much of the time the "hack" isn't accomplished by changing code, but by altering or removing assets, models, maps, etc., all of which are more accessible, and often in formats that allow them to be manipulated with more or less available tools.

 

[Cogman]

There are quite a few methods used for hacking games. I'll try to take the ones you asked in route

1. wall hacks. This one is actually surprisingly simple to accomplish. (At least with open gl) there is a very specific gl command that tells opengl how translucent everything is. By sending a message to set that, the walls quickly become see through. The most common method for getting that in is through the common modding methods like meta-mod (for cs).

2. aimbots. There are two methods that I know of for aim bots. The first, is to change the model to add an uncommon color to the model. When that color is encountered on screen, the gun is pulled to it and a shot is fired. This can be done without such a method, but it is MUCH harder and generally not as accurate. (As games now-a-days will check model tampering, and give models unique colors). The second method involves someone finding the memory address in-game for where the players position is stored, and then using a little math to suck the mouse pointer to that position. In some games, the players name would appear at the top of the screen, so the hack would attach to the player whose name was on top of the screen and then detach when that name disappeared.

3. anti-recoil. this is really just simple pattern memorization. CS would always recoil in the same pattern, so anti-recoiling would be as simple as moving the mouse in the opposite direction of the recoil. That is why you should always add some randomness to your recoils

4. auto-fire. these rely on similar methods mentioned in #2. Essentially, it is finding the memory address that stores the players name in game when they are highlighted. If that address contains a player name, send the fire key. if not, do nothing. Sending keys is a fairly simple win32 API call.

MOST hacks rely on divining information from in game memory, and very few actually modify the game. The ones that do modify the game are generally injected in through some method that I'm not so familiar with (you can look up dll injection). Most modern games have gotten pretty smart and hard to hack. While it is still possible, it just isn't done too often.

 

[GodlessAstronomer]

That's really interesting Cogman. Do you know how they go about finding things like player information in memory? There must be hundreds of strings in memory in a game, and thousands of position variables, it seems like it would be finding a needle in a haystack, especially without access to the source. I've never done this kind of thing before, maybe it's simpler than I make it sound.

 

[slugg]

Well I learned how to program by making hacks, so if any of you guys have any questions, feel free to post!

Let's bust some myths, shall we?

1. Wall Hacks:
Meta-Mod has nothing to do with OpenGL. Sure, you could achieve a "wall-hack" using Meta-Mod, but it isn't a true OpenGL wallhack. In order to make an OpenGL hack, one must make an OpenGL wrapper. There are two main ways of doing this - making the game engine (for whatever game) use your own OpenGL library (your wrapper), or in some cases (as with newer games with anti-cheat technologies), you'd have to do all sorts of memory hacking to hook the existing library and make it execute your own code (generally known as DLL injection). With this done, all sorts of hacks can be done, including a wall hack. Every game renders the world differently, so you'd have to log OpenGL calls (using something like GL-Trace or your own wrapper) and figure out how it works. All Quake-based games render the same way, but obviously the newer versions have extra features. Generally, the static environment has a unique rendering method which you can detect, intercept, and make translucent.

2. Aimbots:
Image analysis (using colors) could work, but it's terrible. No real, functioning, accurate aimbot works this way. If we were to find player coordinates in memory somehow, it would be completely useless. Coordinates mean nothing without a frame of reference, which the game engine supplies. Therefore, the ONLY way to make a functioning aimbot is to gain access to the game engine. But without the source code to the game, how is this done (original question in the OP)? Well, while the source code is not available for most games, most games DO provide an SDK. The flow of any modern game is like so: engine <-> logic (SDK) <-> presentation layer (OpenGL/D3D). As can be seen, the game itself is made with the SDK, not the engine. Therefore, if we can just access the existing SDK interface that's already in memory in a running game, we have access to most (if not all) the game's logic. For example, Quake-based games represent the engine interface as a struct or object. If we can find the memory address of this struct/object, we can make a pointer to it in our OWN code, dereference it, and call whatever functions we see fit! This includes finding player coordinates, player view angles, setting view angles, invoking movement, or anything else you'd really need. You could even tell the game engine to render stuff. With memory hacking, you could even hook/wrap the SDK library so that your code can intercept the game's existing logic code, although this is generally very difficult to do with modern games.

3. Anti-Recoil:
This is not simple pattern memorization. The presentation layer (OpenGL/D3D) does not reflect where the bullets are actually going. Controlling recoil is one of the more advanced hacks, actually. First of all, you need to HOOK (not just access, see above) the logic layer of the game (SDK). Not only that, but you need to find the pseudorandom number in memory in the game engine, below the logic layer. This is very hard to do, but is generally a constant offset in the process frame, so once you find it, you've got it until the developers patch the game again. Once all of this has been achieved, it's a matter of reversing the recoil algorithm by logging input and output values *OR*, if you're lucky, the game SDK will include the source for the algorithm. After all of this work, once your code detects that the game is trying to do some recoil, you use the engine's current psuedorandom number and the logic's current parameters (view angles, etc) with the recoil formula to determine the recoil vector, then you subtract that vector from the player's current view vector. That effectively stops recoil.

4. Auto-Fire:
Pretty much same thing as an aimbot. Find player coordinates. For each player, create a vector from the user's origin to the player's origin. Find the angles between each player vector and the user's view-angles vector. Aim (using aimbot techniques) at the player with the least difference and shoot, using the engine interface.


There are many more hacks. If you're interested in how any of them work, post a question

 

[Cogman]

slugg
1. I agree, the exact method used by most hackers wasn't known to me.
2. Some of the older HL aimbots did infact work that way. If you have bright teal show up on screen, you can quickly find it and move to it. The crux to this method is the fact that you have to modify a texture or model to use the aim bot.
3. Sure, in modern games you would have to do something like that. However, older games like CS could use the native hl script to counter the recoil. countering recoil != controlling bullet flight path. So while your bullets do fly out in random directions, your screen doesn't slide to one side or another as you shoot.
4. Auto-fire is not auto-aim. The method I posted is valid for an auto fire, and much harder to detect then what you have posted.

All in all, your post is enlightening. I've only ever dealt with fairly lower order hacks. So its interesting to see how the more advanced ones get things done.

 

[slugg]

Ahh okay well, here you go:

Image Analysis based aimbots:
Slow and inaccurate. Sure they could work, but there are soooo many problems with them. Definitely a last resort.

Anti-Recoil & Anti-Spread:
I interpreted your original post as "anti-spread". If all you're considering as recoil is the visual component of the vertical movement, then yea I guess a script that moves your view down as your fire could look like it's helping, but not completely solve the problem. Like I said before, what you see is NOT accurate to where the bullets are going, especially in Quake based games (like CS). My previous post actually addresses anti-spread and recoil at the same time, which would give the effect of a "pixel perfect" shot, similar to the railgun in Quake.

Auto-Fire:
I now understand what you're saying. A super simple implementation could be done via your method, I suppose. Many problems with this, though. Some games show text when the crosshair is CLOSE to the enemy, which would make it fail. Also, some games fade the text out slowly, which would make it fail too. Most importantly, 99% of engine implementations use a buffer to store HUD-esque strings (like chat stuff, console stuff, and enemy-name-inside-crosshair). So even if an enemy is NOT in your crosshairs, the string would not be null and it would make the method fail. Usually there is some type of boolean flag to tell the engine to render the string. Good luck finding one of thousands of booleans in memory . Your method does work for some versions of Quake, but I'm not sure of what else. I haven't kept up...

A more advance method is to trace collision vectors between enemy hitboxes and the user's view angles in real-time. This way, the algorithm could detect WHERE the user is aiming (head? chest? legs?) and make a decision on whether or not to fire. It could even detect how close to the center of a hitbox the user is aiming at. Using margin/threshold settings, you could tweak your algorithm to shoot in very human-like patterns. For example - you could make it shoot only if it's 75% or closer to the center of the hitbox, and limit the headshots to 50% of the auto-firing time, and so on. You can get pretty creative with this. Another reason why this method is better is because your method doesn't work for projectile weapons, such as a rocket launcher. Using position data over an interval of frames, ballistic calculations can be done to determine trajectory vectors of objects/players in the world, which could then be used to auto-fire a projectile weapon that would intersect with the enemy player's projected path. The math sounds really fancy, but it's just a bunch of high school algebra, actually.

^^ If you combine my previous "number 4" in my original post with the above method, you can make an "Aim Assist" hack. Similar to how Halo's crosshair work, you could make a hack that slows down the mouse sensitivity the closer you get to a hitbox and accelerate it toward the center of the hitbox while it's moving. The effect makes it "feel" like enemies are "magnetically attracted" to your crosshair. Very cool effect that you can't see - only feel



This stuff is actually quite a lot of fun to implement! Keep the posts coming - this is bringing back memories

 

[CycloWizard]

Thanks everyone, very interesting. I used to be a ladder admin for CS/Q3 for a while back in the day and cheaters were always the bain of my existence. One of my roommates (computer engineer) wrote an autofire hack for Q3 in about 15 minutes just to show me how easy it was to cheat on a non-"Pure" server, but I never looked at the code or anything (since I had never coded anything at that point).

 

[chronodekar]

Originally posted by: GodlessAstronomer
That's really interesting Cogman. Do you know how they go about finding things like player information in memory? There must be hundreds of strings in memory in a game, and thousands of position variables, it seems like it would be finding a needle in a haystack, especially without access to the source. I've never done this kind of thing before, maybe it's simpler than I make it sound.

I'm more familiar to the needle-in-haystack route. Some years back, I used emulators to play old SNES games. The games were simple and a 'hack' was to trace through the memory to find out what variables where changing when you lost a life. It took some trial and error, but once found, it was a matter of modifying that variable to give you unlimited lives.

Now, slugg's post, has my attention. I had no idea things became this complex these days ...