Attacking Online Games

Attracted by the catchy title "Exploiting Online Games: Cheating Massively Distributed Systems" I bought the book by Hoglund and McGraw. It wasn't exactly what I expected because it handles mostly client side attacks on the game client. It was also quite verbose and could be compressed to a much smaller volume but reads easily. I didn't mind the book discussing only World of Warcraft because I was looking for fundamental principles behind the attacks.

I am going to discuss the following points:

The book makes one thing very clear: the typical Massively Multi-Player Online Game needs to keep a lot of vital game state in the client software installed at the gamers PC. Game play proceeds too fast as if the server could be told about all moves and supply correct game state.In some cases the server seems to be unable to even validate the local moves. In other words what you usually learn in distributed systems security: "never trust the client" is both true and unavoidable for MMOGs.

What are the consequences? It means that most attacks on those distributed systems are directed at the game client and only indirectly affect server state as well. Even exploiting race conditions between game servers in data centers are mostly a local action at the client.

But from a theoretical point of view it means that there is no clear cut way to achieve a secure game that is save from being exploited. Simply because the client can be under rather complete control of an attacker there is no security protocol nor cryptographic technology that could prevent client side manipulations. All that is left is trying to detect manipulation either by scanning the client side (to a surprising degree I had to learn), by surprising the client (bot detection through reverse turing test) or by clever game design and delayed server side validation. I had hopes to learn more about safe game design and validation on the server side but the book had not information on that.

The dependence on client side manipulations leads to a situation where security of the game is an arms race between new attack vectors and new detection or prevention measures taken by the game companies or their suppliers. The goal of the game companies therefore is not to prevent cheating completely but to prevent a magnitude of cheating that does financial damage to the company, e.g. by driving away legitimate players.

But what is cheating? Theoretically - and the book covers law and money things in several chapters - it is everything that is forbidden by EULAs, TOUs (terms of use) or general laws (of whatever country, but that is a different problem). But is exploiting a game feature that leads to a duplication of virtual goods really cheating if it is done through the regular, original game client and its UI?

Bots. They are fascinating. Most games forbid them as they seem to be incompatible with human game play by giving unfair advantages. Does anybody know a game that could tolerate or even promote the use of bots while still look attractive to human players? Depends on game design I guess. Currently MMOGs seem to try to detect bots but the book asks correctly: Why does the game design allow a mob to show up repeatedly and predictably at the same location only to become a victim of a farming macro bot? Istn't that a defect in the game AI?

Detection of bots is quite difficult and some authors believe that only hardware based captcha tokens will be able to stop bots. See the paper Keeping Bots out of Online Games by Philippe Golle and Nicolas Ducheneaut. Golle's homepage btw. has interesting papers on machine learning, attacks on cognitive authentication systems, automated captcha's etc.

The book presents bots as rather simple state machines. Bots need to detect game state in some way to be able to react properly. The mechanisms used to do that are the same as e.g. for macros (which do not work unattended).

Online Poker. If I wouldn't have met a young guy once who told me about his online poker playing habit I would not believe that such a thing really exists. I mean how could anybody with a bit of a brain left put his money on a game where ALL the vital parameters are completely out of his control and very much remote on top of that? The poker site wants to make money and their computer deals the cards and can do manipulations much faster than you can detect them. Other players can collude against one player and can rig the game anyway they want. The authors tell a story about a poker site using a pseudo random number generator which resulted in guessable card decks once at least five cards were open at the table. Attack software could predict the order of cards in the deck in this case. But I don't think it really needs bugs like those to make it clear that online-playing for money is simply stupid. (OK, a friend told me that using the bonus money that poker sites offer to newcomers is a sure way to win some money: just use the bonus money till it lasts, take whatever you won and run. Of course this behavior is frowned at by other players and the poker sites but at least it is rational behavior (;-). Maybe it just needs some trust into computers which is derived of a complete lack of understanding how they work. A trust that an ex-kernel hacker just can't come up with...

The authors concentrate mostly on local attack vectors on the game client. The following diagram lists the different locations where the game client can be attacked. There is actually a fifth attack vector not mentioned in the book: regular game client extension APIs as they are used by countless utilities in WoW (see www.mobmap.de for an elaborate example of a site that does world data collection). I consider those as legitimate utilities. Blizzard btw. protects the APIs through different techniques like checking whether a certain API call could even result from the current game situation (to prevent the automatic capture of world data) or by tainting approaches to detect when a certain critical internal API function is called from a user function (see the paper "using tainting in browser security" by Rene Schneider).

The different attack locations result in very different attacks with different degrees of effectivity, danger to be detected, skills needed to create attack software and finally the dependency on changes in the game client. The "over game" attacks are macros which drive the game through the regular user interfaces like keyboard and mouse events. Macros can use screen sampling (e.g. detection of pixels of a certain color in a certain area) to deduce game modes like attacking. The authors claim that macros are rather hard to detect for the game companies. Another important feature is resistance against changes in the game client and here macros should be rather easily adjusted.

"in game" attacks cover a wide variety of attack vectors which have a manipulation of memory cells of the game in common. To achieve a successful manipulation - e.g. to make walls transparent so that you can see enemies early on, a famous counterstrike-hack - you need to know where world data are stored. They have to be stored in the case of enemy location data because the game client needs to use them. Besides data certain functions of the game client are of course also very interesting, e.g. the main dispatch loop for events or helpers to load libraries etc.

There are countless ways to achieve manipulation. Forced injection of DLLs is one way, running the game client under a debugger another. They all have something in common: when the game client changes they need to be changed as well. And there is the danger of being detected by the game client which can use certain checksums, shadow storage locations or operating system functions to verify DLLs or to detect running under a debugger. The authors describe ways to recover from a change in the game client. They describe a client decompiler which uses heuristics to detect core functions by scanning the .exe file of the game client. Generally finding data and functions is a tedious approach and my feeling is that the game client has many ways to detect manipulation.

To prevent detection the authors mention running a debugger (or a bot running as a debugger) remotely on a different machine. Only a small agent would work like a proxy between remote debugger and game client. This is actually the same thing as remote debugging.

The authors do not mention the Vista word. My feeling is that the Vista protection mechanisms like address space randomization, stack and heip protection, data region execution protection - while far from being perfect (see the black hat 2008 talk about vista security in Security Architecture in Browsers and Operating Systems, more...) - will throw a wrench into many mechanisms used by game hackers. But of course it takes only a few dedicated hackers to create easy to use frameworks for new exploits.

"Under" the game attacks are intercepting game calls to 3D graphic libraries or even the lower level driver libraries e.g. for NVIDIA hardware. Some are supposedly even going directly to the graphic hardware to look for interesting data. Because the interface to 3D libraries is rather a high-level one it allows reconstruction of the game world objects. This can finally even lead to the development of a new game client software. These attacks also might have to be adjusted when the original game client changes but because they work on a more abstract level (game object descriptions) they are probably easier to adjust.

The "out of game" scenario deals with intercepting the communication between game server and client. It requires the ability to decrypt the communication (basically recovering the symmetric key used in the client for data encryption. I do not know whether games use PKI but it could be too costly given the high number of concurrent players (can be in the 100.000s). And in both cases the keys need to be extracted from a running client.

The interception attacks also require knowledge about the communication protocol used. Reverse engineering such protocols is tedious but far from impossible. Changes again require adaptations in the proxy. The proxy can do more than just reading data. Delaying packets can be another useful feature (see next attack).

Finally the game server themselves can be attacked, either directly (think DDOS attack to prenvent a server from receiving or responding in time) or indirectly by leveraging race conditions e.g. during server transfers.

For much of the source code examples the authors use techniques from previous books on exploiting software. They give hints about loading libraries by injection, how to use debuggers and disassemblers and also include a chapter on reverse engineering tactics. My feeling is that those chapters can give you merely some ideas on what is possible but to actually create such attacks much more knowledge about the operating system, CPU and machine code, assembler etc. are needed.

As long as there is client code running under the control of an attacker all kinds of manipulations are possible. The authors discuss preventive measures like the "warden" software from WoW which scans other processes on your PC (which is rather questionable from a legal point of view). And it is not really compatible with the advice from the authors to never run the game client under admin privileges. I suppose you have to install those game clients under admin privileges to allow e.g. the warden to do its dirty deeds. But after that you really don't need to worry about running the game client under admin: it can use whatever service etc. was installed initially with full privileges...

Given the availability of broadband connections nowadays the game vendors could download parts of the game client dynamically and with ever changing characteristics. This would make it rather hard for attackers to decipher the code in realtime to find the proper addresses of data and functions. Even the protocol could be changed on the fly.

All of this will only make it harder for attackers because the threat-model behind needs to assume not only a tapped wire but also a compromised client under the control of an attacker. For many regular e-business applications such a scenario is not even part of their threat model (they just assume the internet threat model). I wonder what those services could learn from game companies? After all: security is security that works as Peter Gutmann, Simson Garfinkel and others insist on...

If your are intersted in security in virtual worlds you might want to read the Security in Virtual Worlds. It shows a much broader approach which includes social engineering, colluding, duplicating 3-D models, copyright violations etc.