Take the 2-minute tour ×

Consider a relatively small multiplayer game server, written by an individual or a small company. Some malicious user wants to boost their character stats by a factor of 100.

What paths of attack might they have and what are the most important safeguards to prevent these attacks?

share|improve this question
I've edited the question to focus it more strongly at game development, rather than at compromising a specific kind of server. This should at least steer it toward on-topic. Of course, edit more if you think it's needed. –  Anko Jun 4 '13 at 8:47
Good edit @Anko. Still, now the question is off-topic for other reasons, you can imagine write entire books on that subject, which is hardly the scope for practical question here. Still voting to close for that reason. Lisa, please read the FAQ for details on what questions to ask here. –  Maik Semder Jun 4 '13 at 8:53
The unfortunate part about this question is that it's almost as broad as "How do I make a game". It is incredibly dependent on so many characteristics of your game and the platform it operates on. Difficult to give a real answer I would say. The biggest reason is that for every general purpose preventative measure developers take to prevent such actions, there will almost always be someone that finds an alternative if they care enough. –  Evan Jun 4 '13 at 12:41
I would argue that a sufficiently useful overview of common attack vectors and defenses could be given to make this question - and its answer - useful. The answers so far aren't quite up to par, though, IMO. –  Sean Middleditch Jun 4 '13 at 17:00

3 Answers 3

up vote 1 down vote accepted

Ok, I can tell you that I had access to the opensource wow server code, and the worst thing for me was fixing the loop holes which gave some not "noon programmers" the ability to manipulate packets, the unofficial opensource servers have thousands backloops and they do not check the packets. On contrary I am sure that you wont do any harm to anyone, because an advanced skill in programming to do such stuff. And in the question you haven't mentioned networking which is all about handling packets. That is how wall hacks work, speed hacks if the server allows something and it will not have a bottlecap of some sort, there is no reason why the hacked client shouldn't send 10x more packets that are responsible for player forward movement. So in this case the player would be able to move 10x faster.

Keep in mind, that tinkering with somebody's server will get you into trouble. In the civilised world you are not allowed to do harm or manipulate data without the owners permission. (Applies to DDOS attacks too). All the incomming packet data, that exceeds the norm is logged in 95% of sittuations. And the player who does that gets a permanent ip-ban.

Search google for "packet manipulation methods".

Still, if somebody wants to go work as an "anti hacking programmer" this is the perfect way to learn about it. And never do it on somebody's server because I can tell you that it is extremely hard to avoid getting your actions logged. If you do it on somebody's server you will most likely be banned from the server and you might even get a real life "ban"...

share|improve this answer
Thank you for your answer, Mikolaj. Before accepting your answer, what can you tell me about the following topic (which I guess is related to the main one): I heard about something called "injection" that is like extracting games' "parameters" and modifying them. Is it just a rumor? –  Lisa Ann Jun 4 '13 at 9:03
I do not know about it. –  Mikolaj Marcisz Jun 4 '13 at 9:37
Just to note, the typical wall hack changes how walls are rendered and/or renders additional hints based on data already being on client side. Wall hacks usually don't modify anything on the networking side (they might use incoming packets to get their data though). –  Mario Jun 4 '13 at 10:18
There are two types of wallhacks Mario, a wallhack that makes you see through walls, and a wall hack that makes you walk through them. Haven't noted that, sorry for leaving that part. Though the most common one is the x-ray –  Mikolaj Marcisz Jun 4 '13 at 13:38

Attack vector 1: The netcode

As already pointed out by Mario, one important factor when designing the network protocol of a client/server application is to not blindly trust the client. You can't control the software which runs on the client machine. You can't even tell that it's your software and not something the user programmed themself. The same limitations apply to anti cheat software. They can't do anything you can't do yourself to prevent hacking your client software. So make sure that the server doesn't allow the player to do anything they aren't supposed to do, like setting their stats to any number they want.

Treat the network input of the client like you would treat the user input on a GUI. Would you make the number fields on the character status screen editable, allow the user to put in anything they want and then go with it? Certainly not. So why would you do that on the server?

Attack vector 2: The database

Most games use SQL databases as backends. Whenever you use an SQL database and deal with data provided from an untrusted source, you have to be weary of SQL injections. This is a common mistake many people make when using an SQL databases and which allows users to do anything to the database they want, including deleting and altering records. Fortunately it's easy to avoid by following some well-known coding practices like prepared statements, ORM wrappers or stored procedures.

Attack vector 3: The infrastructure

The gameserver might run on an operating system which might not be configured for high security, not be behind a properly set-up firewall and might not have the latest patches. This can make it vulnerable for os-level exploits allowing remote code execution or unauthorized logins. How to properly secure a server on the OS level is a topic for http://security.stackexchange.com and/or http://serverfault.com.

Attack vector 4: The human factor

But the biggest security hole of all is always the user.

All other security measures are worthless when an attacker acquires the password to a GM or admin account.

An attacker could use social engineering techniques to impersonate staff members and claim that they forgot their password. They could use spear phishing to trick staff into revealing their passwords or they could trick staff members into installing keyloggers.

The only countermeasure against this is to educate all staff members about proper security practices.

Some of your staff members could also be susceptible to bribery or blackmail (or just be idiots), especially when they are unpaid volunteers from your community. This problem can be partially mitigated by 1. having a rigid code of conduct explaining what a staff member can and can't do in a certain situation and 2. properly log all admin actions making it impossible to abuse privileges without you finding out.

share|improve this answer

Another interesting question where I can cite that awesome quote I've found on the internet a few years ago regarding the creation of multiplayer games:

The client is in the hands of the enemy.

Whereas the enemy is the player trying to cheat or "hack".

Overall, there's no 100% perfect way to avoid hacking, cheating or botting.

One of the easiest way to avoid such issues is - as said in the quote - to never trust the client.

Neverwinter Nights 2 offers a perfect example for this. It had horrible net code. I helped running a roleplay server a few years ago and it was really, really hard to do so right after the first expansion has been released. What happened?

Account creation in Neverwinter Nights 2 has been (not sure it's been changed) the perfect example of how not to do it. Just to note, the game offers two different modes of multiplayer gameplay: Either characters saved on the local player's machine or characters saved on the server. The first approach allows easy cheating, so we didn't use it. However, the second approach hasn't been a lot better:

At account creation, the game created the character and uploaded it to the server. That doesn't sound very secure and it isn't. In fact, this caused quite some unintentional issues. If an expansion player created some character with expansion features and logged into a non-expansion server, the server couldn't handle that suddenly "invalid" character data and simply crashed.

What should have been done instead is something a bit different: The client should tell the server what to create. But in the end the server determines how/what he creates and whether it accepts the parameters given. This is how pretty much any modern MMORPG handles its character creation process and other mechanics. If you still happen to pass some invalid value, you'll just receive an error message rather than see your character being created with invalid stats.

As you specifically asked to magically gain 100 points of some attribute or anything like that: If done right, there's nothing you can do without having access to the actual server. If all calculations (like damage) happen on the server, you simply can't influence or modify them.

Something like the injection you mentioned can have some - but at most minimal - effect based on how the game is written:

Let's assume upon login, the server sends the client some data package "permissions". This will tell the client what the player is allowed to see, for example spawn points or transitions usually not visible to the player. Using traffic manipulation, you could use a program to modify that package so the client thinks you're actually allowed to see that stuff (for example), yet this won't change how you appear to other players or the server (because that data should be verified by the server before being accepted and/or passed on).

share|improve this answer
Have you any link where injection is well explained for beginners? –  Lisa Ann Jun 4 '13 at 11:00
Not right now, although it's essentially like catching some snail mail, using some white marker and changing some word or number, then passing it off to the initial recipient. –  Mario Jun 4 '13 at 11:08

Your Answer


