In multi-player network games, what techniques exist to try to ensure that users are connecting with the official client application, and not some hacked client app?

I realise there is probably no sure-fire way to do this, but rather I'm interested in techniques that can be employed to mitigate the problem.

I'm especially interested in any techniques that can be used for web based games, but I imagine most can be applied generally.

Thank you!

  • \$\begingroup\$ Some believe generalized cloud gaming is around the corner. It kind of solves this question entirely. \$\endgroup\$ Commented Nov 9, 2012 at 14:28

9 Answers 9


That's interesting problem, but I think you are asking the wrong question here. Let me start from detecting hacked client approach:

If your client is executed on user's side, he can do whatever he wants with your code (until it's too complicated for him, but there will always be someone smarter in the line). Everything you can do like hard-coding encryption of messages between client and server, creating client certificates, or even making client to compute it's checksum, can and given enough time, will be decompiled and cracked. I have seen a software which came with a dongle, this dongle had part of the application's code, but to be able to execute it, dongle first checked crc of the app if it was not tempered.. of course after some time dongle was hacked too.. plus if you make a software update, you need to resend the dongle..

In addition to that, user can use your own client to cheat - by simulating mouse movement and clicks for example.

So the question should be - how to detect a bot player?

Here you have a few options - measuring time between clicks, measuring speed of mouse movements - does mouse move exactly from point A to point B numerous times and hit exactly the same coords? Do user movement is repeatable? If when resource which user was gathering was depleted, do user goes to other action or he waits in place for hours? At the end of the day you end up writing patterns recognition code.

  • 4
    \$\begingroup\$ Your bot checking techniques can be beaten within minutes with adding some few noise around the bot action. \$\endgroup\$
    – AsTeR
    Commented Nov 9, 2012 at 14:20
  • \$\begingroup\$ +1 to this; given that prevention is impossible (and if someone is really determined they could even go so far as to hack their drivers, which should underline that fact) your focus definitely should be on detection instead. I'd also add that any reasonable community that may build up around a game will likely end up policing itself, so you can also put some work into providing tools that assist in that. \$\endgroup\$ Commented Nov 9, 2012 at 14:22
  • 2
    \$\begingroup\$ Programmatic prevention alone is impossible, which is why games like WoW have tons of admins who check out people doing repetitive things and ask them questions to prove they are human. \$\endgroup\$
    – DampeS8N
    Commented Nov 9, 2012 at 14:34
  • 1
    \$\begingroup\$ @AsTeR Those were just some ideas to push in the right direction. There are numerous articles and presentations which tackle this problem more deeply, like this one for example: iis.sinica.edu.tw/~swc/pub/bot_trajectory.html \$\endgroup\$
    – Kamil
    Commented Nov 9, 2012 at 14:45
  • 5
    \$\begingroup\$ "So the question should be - how to detect a bot player?" I disagree, there are multiple ways to cheat without having a bot. For instance letting the client get too much info or trusting the client. \$\endgroup\$
    – Matsemann
    Commented Nov 9, 2012 at 20:29

In multi-player network games, what techniques exist to try to ensure that users are connecting with the official client application, and not some hacked client app?

I don't think this is the right way to approach this or at least not the only thing you should be concerned with.

  1. Make sure you only send client specific information to every client (e.g. a client doesn't need to know what a monster for example can drop, just send the information after killing it, and only to the specified clients)

  2. Do most of the calculations on the server side (positioning etc.). The client is doing it's own calculations BUT can never send his own values only his actions. The server has to check if this action is valid and how it will effect the game.

  3. 1 and 2 are usually combined with predictions. The client and server try to predict certain behaviors. The client for example moves the player but every x seconds or ms. receives a correction by the server

  4. Charge users for their accounts not for the client, this way a user might get hold of a cracked version but can't play without an account.

With 2 you can make sure there are no money hacks, position hacks or wall hacks etc. but bots have always been a problem for many companies. Even big company names like blizzard have trouble with that. What you could do is limit the playable time per account, so that someone can't be online for more than 540 hours per month. I remember a bot which used color values of monsters + mouse input in order to farm XP. Another way would be to provide an additional program which checks for other running applications and memory access but this brings a handful of new problems.


Very well written articles for beginners: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

  • \$\begingroup\$ Yeah, I agree it's not the only thing we should be concerned with. We're doing most of these things already, but some exposed elements on the client side are unavoidable. \$\endgroup\$
    – UpTheCreek
    Commented Nov 9, 2012 at 15:26
  • \$\begingroup\$ @UpTheCreek Could you tell us what you're most concerned with? Bots, altering data, what kind of information are send to the client or from the client which need to be protected. As you already notices making a client crack safe is not an easy task but maybe we can help you a little bit better by going to the roots of your concerns. \$\endgroup\$
    – user22553
    Commented Nov 9, 2012 at 15:48
  • \$\begingroup\$ Well for us it's a case of balancing the server side checks/simulation with server costs. We're unable to include everything we'd like. I've thought about this quite a lot, but I wanted to see if there were any ingenious tricks out there to better protect the client :) The client is javascript based, so you can imagine that it's even easier than normal for users to hack! \$\endgroup\$
    – UpTheCreek
    Commented Nov 9, 2012 at 18:24

There is no real foolproof way to guarantee that the "official client" is running; any such mechanism will rely on the validating code communicating back some kind of "secret" to the server, which can be reverse engineered, given enough time. This is basically what happens when an anti-hacking software tells the server that the client is OK.

Edit: to elaborate a bit on the above, consider the code that's validating the client side. It has two very difficult jobs: checking that the original code is being used (and nothing else is present which can interfere with the original code dynamically / at runtime(!)), and communicating this result back to the server, in such a way that this communication cannot be faked. While the first part is insanely difficult, the second part is downright impossible.

If you can update both the client and the server on a regular basis, then you can switch the secret out on a regular basis, with the hope of making it difficult for the crackers to keep up. In all likelihood however, unless you are changing the way the secret is encoded / implemented, it can be cracked very quickly again. So basically, it's an arms-race between you and whoever wants to crack it - who has more time and money to throw at the problem.

Having accepted that part, is there anything else we can do? In a perfect world, with infinite computing power and bandwidth, you could simply continuously transfer state between the client and the server, and have the server run a perfect simulation of what's happening on the client. This model could then be used to validate the actions that the client is claiming to be making. This will not detect whether a human or a bot is playing, but it will be able to validate whether the client is claiming a shot happening through a wall, or some other inconceivable action.

Having enough data on the server is also a first step in detecting irregular behaviour - aiming that's too quick for humans perhaps, etc. Obviously the perfect simulation situation is generally not feasible, but some kind of scaled-down, estimated model can be used in many situations.

  • \$\begingroup\$ +1. I came here to mention the idea of changing the secret frequently, meaning the hackers would have to repeat their work. Complex secrets would make it even better, eg. one that changes based on what the server sends. \$\endgroup\$
    – Kylotan
    Commented Nov 9, 2012 at 17:56

You don't specify the type of game, so I will lean heavily toward RPG/MMO games. But a lot of this can and does apply to FPS, Strategy, and Action games. The way big multiplayer game companies like Blizzard deal with this issue in their games is:

  1. Do all calculation and game actions server side, the client is just a dumb terminal and graphics engine. So if the players are using a different client, it really doesn't matter in game terms, they can't cheat the physics of the game.
  2. Checks for obvious bot programs/clients by looking for obvious computer actions like perfect repetition of click events and mouse movements.
  3. Checks for non-obvious bot programs/clients and alerts in-game moderators to the issue.

They then appear in game (if that's possible, for same games like Starcraft 2 it is not) or otherwise watch/talk to the player about their actions as a 'human check'. Or at least that's how it should be handled. Blizzard is pretty good about this but historically other MMO companies have not been.

Checking for non-obvious bots isn't easy, but a few basic rules to follow include

  • Looking for players that, with only slight variation, are performing the same actions over and over again. This might be sitting at a resource node in an MMO and farming it when it respawns, or it might be running in circles between health/ammo packs in an FPS and never deviating from a specific path and always using the same gun. (Sub-optimal bots in FPSs are rare, but if your game has a ladder to climb where number of games is more important that the talent of the player like some modern FPSs have, bots become valuable again)
  • Looking for players executing the same exact rush or strategy over and over in an RTS. There are certain build orders in Starcraft that can be nearly unbeatable when performed by a bot.
  • Looking for players who have collected vast sums of resources and are now endlessly grinding out one item. This was a big problem in Ultima Online.

The problem is that the more popular your game is, and the more fruitful bots can be in reducing tedium in your game, the more likely people will be to both use and create these bots. And it is trivial to restrict mouse movement speed, add random humanistic variation to clicks, even have the bot make mistakes at a human rate, opening and closing parts of the menu, hitting the wrong button and then closing the window, switching between keyboard and mouse work like humans do to reduce hand fatigue. (you don't even realize you do it)

So the last step when someone or a bot is doing something repetitive for a very long time really has to be a human mod coming up to the player and talking to them. If they are there and respond with human answers, they are human. Typically the mods will ask the player to stop for a while, or follow them somewhere and perform some other actions, the hoops become more complex with time.


Of course, eventually someone will create a bot that is indistinguishable from a real person, passing the Turing test. And there are a lot of bot writers out there who aim to do just that.

I, myself, had a passing fascination with the idea when I first started programming and created useless bots for Ultima Online which would stand in town and imitate NPCs. The commands were super simple so they were easy to make, just key strokes to step in different directions, and watching the chat log for its own name and piping the messages to ALICE over via a web version of the AI. I don't remember which and it probably doesn't exist anymore.


Point is, you need to decide where to draw the line. If you can't afford an army of moderators to talk to people your system identifies as bots, you are probably better off letting the community mark people as bots, and then when enough do over time, kick the player for about an hour. Not ban, just kick. The real problem for most players is that bots hog resources that other human players could be using. If mobs are scarce, as was the issue with Ragnarok Online, then bots that roam about and clear whole areas of enemies while scooping up items (or not) are common, and they ruin the game for other people. So you can skirt the cost of admin armies that way.

Finally, you can also live with bots as a reality of your game space and encourage their use. This requires designing your game around the eventual and common use of bots, trainers and helper programs. I want to say there was an MMO that did this about 10 years ago, but I can't remember which one it was. It spelled the end of the game, because MMOs are grind heavy and it meant that 95% of the players we away from their keyboards at any given time and destroyed the community. If you go this route, be careful.

  • 3
    \$\begingroup\$ On your final paragraph, SOE's Star Wars Galaxies was an example of an MMO with a pretty robust ingame scripting/macro language, yet it didn't have much of a bot problem. What ended up happening was that some of the more tedious ingame necessities were scripted (most starports had a queue of players in front of a fully automated healer buff-ing bot, for instance), and low-level XP grinding was often done this way too. IMO this all massively added to the game, what killed it were some incredibly bad decisions and game changes, with little to no warning or communication. \$\endgroup\$
    – GAThrawn
    Commented Nov 9, 2012 at 17:47

avoid having game-features from which a user can win by doing repetitive tasks, especially in browser-like games. game-features which cause repetitive tasks not only cause other users angry because they don't have time to do them, but it also makes the game much easily botable (and much less fun!)

If a given game-feature can be botable, why is there that feature on the game anyway?? That feature is clearly calling the user to build a bot.

The game is meant to be played by giving the player a reasonable amount of entertainment, normally by a set of non-trivial choices. The ability do decide facing non-trivial choices separates a human from a bot. Ultimately, instead of searching for bots, search on your game where a bot could be implemented, and implement it you by yourself to be used by everyone. By doing that, you save time to a game-player by avoiding him of performing boring tasks, while you fight the bots from the root: if there are no botable game-features, how can there be bots?

My bottom line is: I would say that there is a threshold on the minimum amount of complexity a game needs to not be botable. Make your game above that threshold by adding non-trivial choices which will ultimately increase the user experience.

Anyway, maybe this paradigm no longer applies on the present days... but I still believe this is what makes a good game.

  • 1
    \$\begingroup\$ +1 The only effective way against cheating is designing the game in a way that cheating isn't effective in the first place. \$\endgroup\$
    – API-Beast
    Commented Nov 9, 2012 at 22:38
  • \$\begingroup\$ My last sentence was right because I was astonished by no one had even considered that as a possibility... \$\endgroup\$ Commented Nov 10, 2012 at 6:44

The existing answers are already good, but I wanted to point out that if your checks are expensive (ex: running the entire game server-side to make sure the client isn't cheating), then you can choose to only do it some of the time.

For example, you could only check actions in a particular region or by particular players (randomly changing after some time), or just have a queue of actions and randomly pick which ones to validate (and ignore the others). Maybe come up with a heuristic of who's likely to be cheating (basically look for people who are most successful) and validate their actions on the server.

Make sure the server doesn't give away when it's validating actions and when it's not. Always send your standard response until you're ready to take action (and don't give it away by taking longer to send a response when you're validating and when you're not).

This way you can get pretty good protection against cheating, using only the server power you can spare (although obviously the closer you are to validating every action, the better protection from cheating).


Well, I don't think there is an "the-Ultiamte-soltution". You may encode the Datapackages, and give the server that recieves the packages some rules. To example you could set that the biggest realistic/allowed move is +1 and not like a cheater/hacker that would set it to 5 or higher just to be faster. Just think about what could a hacker do to be better than other players and set rules for it.


The simplest way is to in essence make the client a dumb terminal. Everything is done on the server, and the client just sends commands to the server. This way the server is fully in control of everything.

This is probably not the most suitable case for you however, because the server has to perform more computations, and the user experience will be lackluster. So the more logic you leave up to the client to perform, the better the user experience, but the less security there is. So you'll have to find a middle ground that is acceptable for you.

Also, only send the client what it "should" know. For example, if an enemy player is behind a wall, don't send that information to a client, or a hacked client will be able to discern this information (read: wallhack).


EDIT: I misunderstood the question. I interpreted it as "prevent pirated/hacked key" instead of "hacked software that can send a message to generate 1 billion gold for the player."

Most games these days have a value tied to an account in a database since anything that a client can send to a server can be modified. This is probably the simplest and most effective method.

With the prevalence of high speed internet and P2P file transferring, companies have switched from cd-keys that are stored locally on the client to keys that are linked to an account on their servers. There are no more "official" or "non-official" client software since anyone can download the client. But you can only play if you have an account with access to play.

This also has a benefit to the company since they don't need to spend as much producing physical copies of the software.

  • \$\begingroup\$ I wasn't the one that voted you down, but to me this doesn't really provide any protection. Sounds like you are talking about only letting authorised users connect - that's easily dealt with. But the problem is there wouldn't be anything to stop someone with a valid account reverse engineering the messaging, and writing my own hacked client. \$\endgroup\$
    – UpTheCreek
    Commented Nov 9, 2012 at 12:57
  • \$\begingroup\$ -1 this does not answer the question, having an on-line account doesn't prevent somebody from connecting with a hacked client that, for example, automates in-game actions. wow is entirely online based and it still gets hacked constantly. to prevent this blizzard employs their "warden" anti-cheat software, which is an example of dealing with the problem in question \$\endgroup\$
    – dreta
    Commented Nov 9, 2012 at 12:57
  • \$\begingroup\$ Arg, you're right. I misunderstood the question. \$\endgroup\$ Commented Nov 9, 2012 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .