Online Game Server Security
by Ban Seng Keng
Introduction
“An online game's success or failure is largely determined by how the players are treated. In other words, the customer experience -- in this case, the player experience -- is the key driver of online success,” quote from “The Future of Online Gaming" (http://www.costik.com):
It seems that the introduction of every new game is followed by the introduction of web sites dedicated to cheating the game. In one- or two-person games, cheating is a minor issue, since it only affects one or two people at a time. However, a single cheater in an online game can affect thousands of people and have lasting implications. That’s why for an online game the security to prevent cheater is also a big concern.
Cheating technique and possible preventions
The first type of cheating is reflex augmentation, which is when a computer program replaces human reaction to produce superior results. This type of cheating is really only applicable to games where reflexes and reaction times matter, and thus is most applicable to action games, such as First Person Shooting ( FPS ).
The way it works is the proxy server of the cheater monitors and attempts to decode all of the packets it is routing. Then a program keeps track of the movements and locations of all the players the server is reporting to the game, building a simple model. When the proxy sees a Fire Weapon command packet issued by the cheater, it checks the locations and directions of all the players it is currently tracking and picks a target from them. It then inserts a Move/Rotate command packet into the stream going to the server in front of (or into) the Fire Weapon command packet that points the player straight at the selected target. And that’s a perfect shoot, godlike killer.
One of the earlier countermeasures to be developed was a server add-on that statistically identified players whose aim was too good to be true, then kicked out and banned the perpetrators. This naturally proved controversial, since some people really are "railgun gods," and the issue of possibly falsely identifying a person as a cheater was raised (and has yet to go away). And of course, the aiming proxies evolved with time. Later versions were improved to consider only the player's current field-of-view (FOV) and compensate for lag, and added just enough randomness in their aim to stay below a server's "too good to be legit" identification threshold.
Another way to make life more difficult for the proxy creator is to make the command syntax dynamic. Using something as simple as a seed number that's given to the game when it connects and a custom random number function, the actual opcodes used in the communication packets can be changed from game to game, or even more often. The seed itself doesn't have to be transmitted; it could be derived from some aspect of the current game itself. The idea here is that since a proxy sees all the communications, but only the communications, the random seed is derived from something not explicitly communicated. Foolproof? No. But it's far more difficult to hack, forcing the hackers to start from scratch.
If guaranteed delivery is used, another communications protection technique is to serialize each packet. Taking it a bit further, make a portion of the next serial number dependent on a checksum of the last packet. While there are speed issues with the delivery, it's an excellent way to make it difficult to insert or modify packets.
The next major cheating technique is called authoritative client. This is when one player's modified copy of an online game tells all the other players that a definitive game event has occurred. Examples of the communications would be "player 1 hit player 2 with the death-look spell for 200 points of damage," "player 2 has 10,000 hit points," and so on. The other players' games accept these as fact without challenging them and update their copy of the game simulation accordingly.
In this case, a hacked client can be created in many ways: The
executables can be patched to behave differently, the game data files can be
modified to change the game properties on the hacked client, or the network
communication packets can be compromised. In any case, the result is the same -
the game sends modified commands to the other players who blindly accept them.
Games are especially vulnerable to this type of exploit when they are based on
a single-player game engine that has been extended to support online
multiplayer in the most direct (read: quickest to develop) manner.
The first step to eliminate most problems with authoritative clients is
to install a mechanism in the game that verifies that each player is using the
same program and data files. This means going out and computing a CRC or
similar identifier for all the data in question, not just relying on a value
stored in the file or the file size. A nice side benefit is that this method
also detects out-of-date files during the development process.
Another method is to check the command request, a command request
describing the command is sent out to other players and is also placed into the
player's own internal command queue, which contains command requests from other
players as well as his own requests. Then the game engine pulls command
requests from the queue and performs another validation check, rejecting the
request if it fails. The fundamental difference is that every player has a
chance to reject every action in the game based solely on the information on
that player's machine. No other machine provides the information to make the
determination on what is right and wrong. A hacked game cannot reach out and
alter what's on an honest player's machine with this approach.
Alternatively, to make life even more difficult for the hacker by
allowing command requests to bypass the verification check only on the machine
that issued it, deliberately allowing the game to go out of synch if the
initial verification check or data has been hacked.
The third technique is called information exposure. The principle is simple: On a compromised
client, the player is given access or visibility to hidden information. The
fundamental difference between this and authoritative clients is that
information exposure does not alter communications with the other players. Any
commands sent by the cheater are normal game commands - the difference is that
the cheater acts upon superior information.
The first-person-shooter
cheats of modified maps, as they let cheating players see things that they normally
wouldn't be able to (in the case of modified maps), or see them more easily (in
the case of a modified player model that glows in the dark). Any game whose
game play relies on some information being hidden from a player has a lot to
lose to these types of cheats.
The real-time strategy (RTS)
genre suffers severely from this. The most obvious being hacks that remove the
"fog of war" and "unexplored map" areas from the display.
With a fully visible map, the cheating player can watch what other players are
planning and head them off at the pass, so to speak. The hacker may go after the
variables that control the display characteristics of the map. With the help of
a good debugger and single-player cheat codes to reveal the whole map, finding
the locations in memory that control the map display is fairly simple.
But information exposure
cheats can be totally passive. Consider a scenario where a program gains access
to the memory space of an RTS game that is running. It then reads key values
for each player in the game out of memory and sends them to an adjacent
networked computer. This is one of the weaker parts of this type of game.
Hackers like to pause the game and scan through the memory and figure out the
control variable and modify it.
There are some methods that can greatly reduce the likelihood of this sort of passive attack. But it cannot guarantee 100 percent security, but they make the hacker's job much harder.
The first strategy is to encrypt very significant values in memory at all times. Simple encryption is relatively easy when all access to the variables goes through assessor functions. A communicative function such as XOR is your friend here, as it alters values upon storing, restores them upon reading, and is extremely fast. The whole point is to make it very hard for the hacker to find the variables he is searching for in the first place. Values the hacker would know to look for are not left around so that a simple scan can find them.
The second strategy for slowing down passive attacks is to never access very significant values from outside the class hierarchy. Assuming the values are located while using the debugger, try not to access them in a way that starts with a reliably fixed memory address. Combining this with small, randomly sized spacing buffer allocations during the main game setup ensures that the memory addresses for vital information will never be the same from one game to the next.
The sad truth is that the Internet is full of people that love to ruin the online experiences of others. It is always hard to secure the game from the hackers as the developers gave them a copy of their game when they purchased it. The hackers have access to the same tools that the developers had while making the game. They have the compilers, dissemblers, debuggers, and utilities that the developers have, and a few that developers don't. And they are smart people - they are probably more familiar with the Assembly output of an optimized C++ file than those developer.
New technique and new algorithm is one of the better solutions to provide much more security to the game. While considers about the game server security, the game performance is also a key element to be success. No matter what kind of security mechanism or game feature is used, most important is no to lose the fun of the game.
Final thought
Security is a serious concern in all online games, but especially in persistent worlds. A single security hole can make the customers disappear overnight. As more games move to the Internet, we'll hear about security more often, since players will break through the weak protection in most games. With proper planning and eternal vigilance, however, someone can avoid becoming a casualty of the online revolution.
Reference:
http://www.gamasutra.com/features/20000724/pritchard_pfv.htm
http://www.gamasutra.com/features/19970707/security.htm
http://www.gamasutra.com/features/19970601/looking_ahead.htm
http://ausweb.scu.edu.au/aw2k/papers/wong/paper.html