Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

After playing these games, asking other players/admins, and reading online I am led to believe that Quake Live and Battlefield 3 are frequented by bots and there are plenty of hacks of various kinds. I'm confused how this is possible, or even easy seeing how many players have access to these kinds of "tools" (sic).

Isn't it possible for the game authors to digitally sign the game executables so that when they run, the server can ensure only the allowed client is sending commands, thus preventing any kind of abuse? I.e. every player command would be signed by a private key, or symmetrically encrypted (not sure which would make more sense).

I understand that players can look at the running executable's behavior (memory etc.), but if games are apparently so easy to hack, shouldn't most apps be hacked as well (e.g. Skype, all DRM running on Windows etc.)?

share|improve this question
    
Encrypting takes way to much time and machinepower. This will increase delay and decrease number of players on a server (or number of servers per computer) –  Matsemann May 5 '12 at 11:58
    
@Matsemann I think the 'cost' part is pretty obvious choice in games where players buy their own servers anyway, since most players hate hacks and bots (BF3 AFAIK is run on players' own servers). I am confused about 'delay' part. Exactly how much slower would that be? A decent latency for an FPS player is below 40ms, right? How many ms would be added through good encryption or digital signing? You're saying noone is doing it in realtime games (also RTS like StarCraft 2)? –  Jakub P. May 5 '12 at 12:08
1  
Nah, it's not like you can't encrypt game traffic fast enough, it just doesn't do anything to stop the problem. –  eBusiness May 5 '12 at 12:17
    
Even if the only things the client had access to was the final rendered frame, the audio, and the control inputs, it would still be possible to cheat (e.g. by using facial recognition software to automatically locate and attack enemies). –  Adam Oct 31 '12 at 1:02
    
Is there an article somewhere that explains in detail the implementation of such a bot? I'd like to see what binaries are created / modified, how exactly, what they respond to, what's the role of videocard etc. –  Jakub P. Oct 31 '12 at 15:01

3 Answers 3

If it's client-side it's vulnerable.

A hacked client could always be programmed to just send the server the responses it expects, and it doesn't even need to be limited to the client executable. Hacked video card drivers that let players see through walls are also possible, proxys that intercept and modify net traffic, input drivers that work off info in screen grabs, hacked high-visibility player skins, and they're only the crudest examples.

No matter how much technical know-how is needed to construct one of these, as soon as it's done once it can get out in the wild and then every cheater has it.

share|improve this answer
1  
I will find a source for this later, but a great example is how player made AI was made for StarCraft II. The developers did hex-dumps/intercepts to analyze the vector information being sent to the video card for stuff to draw. They identified this info as buildings/units and programmed a bot to play the game with this information. Wall-hacks work the same, by intercepting calls to the DirectX library, analyzing them for player information, and then editing the call to include an outline to show players through walls. This method of hacking is very difficult to stop. –  kurtzbot Oct 30 '12 at 19:55
1  
@kurtzbot usually you capture data between server and client (as some proxy or just a sniffing software) or as a fake client or modification of the client. What you describe is probably a way to workaround some encrypting taking place in S2. –  Markus von Broady Oct 31 '12 at 7:57
    
OK, so correct me if I didn't understand correctly -- all that wallhacks need is a modified video driver that can draw a couple of things on top of what it normally does. The code to interpret drawing commands for players (to recognize them and make them visible through walls) is within the video driver binary. Is that it? If so, that's very clever and indeed I have no idea how to prevent it :)) Though this is very different from, say, aimbots, which definitely requires some non-human input to the client. –  Jakub P. Oct 31 '12 at 14:52
2  
Well the D3D dll contains all the good stuff, drawing objects, and making sure to hide objects that are behind other objects. What you would do is to create a "proxy" D3D dll, that intercepts the calls, does what it want's with them, then you would call the normal D3D dll and pass the result on to the originalcaller. You can then think of the exploits after that as a sort of "Man in the middle" attack. –  Delusional Logic Oct 31 '12 at 15:30
1  
@JakubP., there are some ways to prevent it but they would dramatically reduce performance. I know that one technique is to analyze the frame sent to the card every 60th frame. All the hacker has to do is just not do anything on that 60th frame. But even checking every 60th frame for modifications is expensive and honestly not worth the effort for video game companies (although this has been implemented by a game company and defeated by some hacker group, which is why I mention it). –  kurtzbot Oct 31 '12 at 19:04

Isn't it possible for the game authors to digitally sign the game executables so that when they run, the server can ensure only the allowed client is sending commands, thus preventing any kind of abuse? I.e. every player command would be signed by a private key, or symmetrically encrypted (not sure which would make more sense).

You just copy all that to your cheat client. If the client is required to send it's own hash then a cheat client will just have alternate code that sends whatever is required. There is nothing you can put in the original client that can't be copied to the cheat client.

And since you ask, yes, pretty much all DRM can be hacked, and it happens all the time.

The one thing that can't be hacked, if it's properly made, is license codes for online services. It's pretty trivial to make sure that people at least can't play on the official servers unless they have bought an official license.

share|improve this answer
    
I don't understand your very general statement that "you just copy all that". What do you copy exactly? Are you saying it's not feasible to design client applications running on Windows that are safe from complete reverse engineering and breaking any encryption mechanism used by them? –  Jakub P. May 5 '12 at 19:15
6  
"Are you saying it's not feasible to design client applications running on Windows that are safe from complete reverse engineering and breaking any encryption mechanism used by them?" Yes. –  eBusiness May 5 '12 at 21:25
    
When the client needs to send its hash to the server, you can just keep a copy of the original client around, let the cheat client calculate the hash of it, and send this to the server instead of its own hash. –  Philipp Oct 31 '12 at 8:31

Your suggested encryption scheme does not change the premise that games generally run client-side and for a good reason, yet anything client-side is 'in the hands of the enemy'. If the game client needs to know where opponents are, even if they are obscured to the player, then a wallhacker will also have access to this information, as from a technical point of view, both are the same recipient, namely 'the client'. A game developer cannot guarantee to keep this distinction between legitimate software and hacking tools intact and safely communicate with the game client, but not the attacker, because this distinction does not yet exist before the data passes the trust boundary between server and the player's machine and the bad guy gets in control. If this distinction cannot be relied upon, we must assume the game client and the hacker are the same party.

Encryption can be used to communicate safely over an untrusted channel. Superficially, it seems to do exactly what is required here, getting a message from A to B without an attacker being able to read or alter its contents. But there's a catch. The system is useless if the attacker can decrypt the message. The system is equally useless if the intended recipient cannot. In this scenario, the attacker and the recipient are the same person.

Your question concludes in saying: "if games are apparently so easy to hack, shouldn't most apps be hacked as well (e.g. Skype, all DRM running on Windows etc.)?". They should indeed and in fact they are.

share|improve this answer
    
Wallhacks aside (answer by mh01 suggests decryption or altering game client is unnecessary to develop them), I still don't understand how exactly it works for, say, aimbots, or in general, creating something that becomes a modified (hacked) game client. So to get a straight answer: some people have broken encryption/security of every major online computer game out there WHICH ALLOWED creating fake game clients? By fake game client I understand binary code running on "player's" machine that responds to server data and can do things human player's couldn't. –  Jakub P. Oct 31 '12 at 14:57
    
Is there an article somewhere that explains in detail the implementation of such a bot? I'd like to see what binaries are created / modified, how exactly, what they respond to, what's the role of videocard etc. –  Jakub P. Oct 31 '12 at 15:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.