Tricks and Techniques for Cheating
There are many ways to cheat in an online game. Some of them don't require much in the way of computer programming skills at all. Colluding as a group in an online poker game against an unsuspecting fellow player is an example from the "just takes a telephone" camp. On the other hand, some cheats require deep programming skills.
In this chapter, we'll introduce you to some basic cheating concepts:
- Building a bot
- Using the user interface (UI)
- Operating a proxy
- Manipulating memory
- Drawing on a debugger
- Finding the future
The end results of many of these approaches are now available for purchase online at a number of spurious Web sites. One example is the Pimp My Game Web site at <http://www.pimpmygame.org/>. The Web site, similar to many others like it, boasts the following:
- We give our users the chance to get Exploits, Bots, Hacks, Macros, Patches, Cheats and Guides for all usual MMORPGs and FPS Games that we support. Get them from our own downloads section and forums where you can discuss and debate. You will become more successful in your Game!
Of course, we're more interested in understanding what goes on behind the curtain of these "Exploits, Bots, Hacks, Macros, Patches, Cheats, and Guides" than we are in buying them.
Building a Bot: Automated Gaming
If you Google "online game bots," you'll amass impressive millions of hits. Most of the hits are for sites that offer to sell you a bot. But what is a bot really?
Bots are stand-alone programs that play a game (or part of a game) for you. The term originates from first-person shooter (FPS) games developed for the PC. The term derives from a robot that simulates another player in the game. You might play a game of chess against a bot, or you might battle a bot in an FPS game like DOOM.
Today, the term bot is applied widely to a range of programs, from those as simple as a keyboard mapping that allows you to script together several common actions to those as complex as a player based on artificial intelligence (AI) that plays the game by following simple reasoning rules. In the FPS world, people use bots to perform superhuman actions (e.g., perfect aim). In the MMORPG realm, players use bots to automate the boring parts of play. We provide an example of a macro later in the chapter that controls a character in WoW, thus making that character a bot (temporarily at least).
In all cases, bots perform certain tasks better than humans. Maybe their understanding of chess logic is superior, or maybe they outplay human characters by knowing more about game state than a human can track, or maybe they just do repetitive tasks without getting bored. But whatever they're programmed to do, bots give cheaters an unscrupulous advantage.
Bots have even been used to rob other characters in a game. According to an article in the New Scientist:2
- A man has been arrested in Japan on suspicion of carrying out a virtual mugging spree by using software "bots" to beat up and rob characters in the online computer game Lineage II. The stolen virtual possessions were then exchanged for real cash. The Chinese exchange student was arrested by police in Kagawa prefecture, southern Japan.
In a slightly less obvious fashion, online poker bots have been used to win poker games for their masters. Though professional-level play is not yet possible (because solving the problem involves creating legitimate AI that can pass the Turing test3), poker bots are good enough to win on basic tables with some regularity.4
In final analysis, bots have a mixed reputation. Some serious gamers deride them as a cancer ruining games and the gaming industry for everyone. Others see bots as extremely useful tools for delegating the boring aspects of play to a computer program. Still others see bots as a great way to make a living.
Game companies often deploy technical and legal countermeasures to detect and stop bot activity. Sometimes they keep play statistics about characters and notice when certain values go out of range (e.g., flagging things when a character quadruples its wealth in one hour). Another common countermeasure is to ask a character questions to see how humanlike its responses are.5 The Korea Times reports that in the MMORPG Lineage, at least 150 game minders monitor the game for use of bots and then ban players using them. The report states that 500,000 accounts had been suspended between 2004 and April 2006 because of bot activity.6
Using the User Interface: Keys, Clicks, and Colors
Figure 2-1 A WoW screenshot, demonstrating the state of the art in online game user interfaces.
As you can see, UIs include parts of the screen that a user can interact with by using standard input devices. There are buttons, text windows, and pictures. You play the game by interacting with the UI—it's your window on what's going on.
Cheaters use the UI to cheat. Let's say a game has three buttons, A, B, and C, that you're only allowed to click manually yourself. By some game companies' definition, if you were to install a software automation tool (such as a quality assurance testing tool) that automatically clicks the mouse on x- and y-coordinates to drive these buttons, you would be cheating.
In many cases, EULA allowances and their associated enforcement mechanisms restrict how you use the software. That is, you're allowed to click on buttons yourself, but a program that you write is not. You can learn much more about EULAs in Chapter 4.
Controlling someone's use of the game like this seems rather extreme until you consider the economic impact of automated game play. In most cases, automated game play is realized by using special tools and scripts typically referred to as macros. For example, in WoW, monsters appear at specific locations on a periodic basis. You can easily write a macro that causes the in-game character to stand in that location and automatically kill the monster every time it appears (thus gaining experience points and virtual gold). Of course, you can do this manually yourself, waiting around all day for the monster to appear, but given that the monster appears only once every 10 minutes, that plan will commit you to a very long and boring night. Why not write a macro to wait around for you? Ultimately the question is, how can automating such a boring and repetitive activity be considered cheating?
WoW, and many MMORPGs like it, are so afflicted with repetitious game play that the players have invented a term to describe it: grinding. That is, doing awful, repetitive things all day with your character just to gain experience is likened to a mule going around and around on a treadmill, grinding grain into flour day in and day out. For some reason, players enjoy this self-inflicted misery and will pay $14 a month for the privilege of doing it. Why?
As it turns out, there is deep-seated human psychology at play here, and it has to do with living a double life, as well as the fact that grinding away like this brings economic reward. Whenever you kill that monster, it drops in-game play money and gives you other rewards, such as more experience, skills, and ultimately levels.
If you write a macro to do this grinding for you by manipulating the UI, you can go away to work, or sleep, and come back later and have the sum of all the gold pieces and experience for all the repetitive monster kills waiting for you. Thus, the macro earns you in-game money and simultaneously increases your character's power—but without the associated boredom of actually paying attention. What a great idea! It's so great, in fact, that thousands of players do it all the time. There is even a special term used to describe players who play this way—they are called farmers.
The simple bot that we include later in the chapter uses UI manipulation to control a grinding character.
Operating a Proxy: Intercepting Packets
Interacting with a game through the client software by going through the UI is a straightforward cheating technique that is not hard to code. There are many more sophisticated methods, of course. One method involves operating a proxy between the game client and the game server. This proxy can intercept packets and alter them in transit. In other words, a proxy-based cheating scheme carries out what is in security circles known as an attacker-in-the-middle attack7 (Figure 2-2).
Figure 2-2 A picture of an attacker-in-the-middle attack. In this picture, the hacker interposes between the client and the server and can both monitor and manipulate traffic as it goes either direction.
There are many ways to carry out an attack like this. Monitoring the network wire is one way. Getting between a program and the system dynamic link libraries (DLLs) it is using is another. Basically, any place where messages are passed around by the target program is susceptible to this kind of interpositioning.
Proxy attacks have a long history. Some of the first network-based proxy attacks were devised and used against FPS games. In these games, a fair amount of data about game state is passed around between the client software and the server. Sometimes these data are not displayed for the player to see, but they are available to the software the player is using. A proxy cheat sniffs the network packets, analyzes them, and adjusts various parameters that should not be known by the player. A classic example comes from the FPS game Counter-Strike, where proxy cheats have been used to improve aim drastically (an essential characteristic in the shoot-'em-up world).
Proxy-based cheats in FPS games are usually held very close to the vest. That's because those who use them are interested in evading detection even in complicated social situations. Being outed at a LAN party for a visually detectable cheat could lead to bodily harm of the meat-space variety! Proxy-based aimbots are thus carefully designed to be effectively used in social situations and may involve statistical fuzzing of calculations to simulate not-quite-perfect aim.8
Sophisticated proxy-based attacks attempt to change data as they move between the server and the client. An obvious countermeasure is to encrypt the data so that unintelligible gibberish is all that can be seen going by. However, encryption costs cycles, and the balance is payable in a less-realistic gaming experience that is a major resource hog. Security always trades off against something; it never comes for free.
To use a proxy attack, cheaters configure the proxy with the address of the server they are using. In most cases, the FPS client runs on another machine entirely and connects through the proxy to the server. This situation is very similar in nature to a standard network sniffing situation, the only difference being that packets can be manipulated as they go by.
The real trick is being able to construct a useful model of the game from the traffic going by. The model will do things like track player locations.
When a packet with a marked command such as "fire the truly impressive blunderbuss of flatulence" goes by, the proxy software determines who is where and who must die and makes it so. It may need to do some weapon movement to cause this to happen so that the blunderbuss is properly aimed. (Remember, the weapon and/or player movement needs to seem natural and reasonable—a complete back flip with a triple gainer followed by a shot between the eyes may be a tip-off that something is fishy.)9
Proxy attacks are just as useful for non-FPS games as well. In fact, the most sophisticated attacks against MMORPGs use a very similar idea, interposing on machine state through manipulation of interrupts. You can read more about those attacks in Chapter 6.
Manipulating Memory: Reading and Writing Data
Manipulating game state through interposition as described in the previous subsection is a hands-off cheating technique. The game software is not directly manipulated, only its input and output are. More hands-on techniques get into the game program itself, reading and writing memory, changing values, and generally messing around with game state directly in the software.
One obvious target for manipulation is the drivers that control graphics rendering on the PC. Once again, FPS games led the way in cheating. The Counter-Strike game is a classic FPS. Like many games, it makes extensive use of drivers to control graphics, sound, and networking. Cheaters target the OpenGL and Direct3D drivers to do their dirty work. The Counter-Strike hack called XQZ was one of the first to alter drivers. The creators of Counter-Strike built an anticheat engine called Cheating-Death that was able to detect when OpenGL drivers had been replaced. The arms race was on.
Historically, the reason that drivers are easy to manipulate is that Microsoft Windows doesn't include an easy way to determine whether a driver is legitimate or nefarious. All of this is changing with the release of Vista and its driver signing capability (though don't believe for a minute that this is a security silver bullet). Prior to Vista, finding these cheats on any given computer was difficult even when full access was provided to the machine (and, in fact, even when rootkit technology was involved).
Another common form of client-side manipulation involves the use of classic hooking techniques to interpose on DLLs and other system libraries. Many of these techniques are in common use in software exploits (see our book Exploiting Software for more). All modern operating systems use runtime-loadable libraries (Win32 uses DLLs; Linux and Mac OS X use standard UNIX-shared object libraries such as glibc.so), and as such, all are susceptible to hooking attacks.
In some games, client-side communication is accomplished through DLL calls, all of which are easily intercepted. Modern software almost always makes extensive use of outside libraries, which in this particular case leads directly to the risk of rampant cheating.
Once again, an arms race of sorts has emerged, with classic hacks (such as the loaddll library for Counter-Strike10) leading to hook-proof anticheats leading to sneakier hooks leading to hook detection mechanisms.
Drawing on the Debugger: Breakpoints
Debuggers are another common attack tool used by those who exploit software. There's nothing quite as powerful as a kernel-level debugger with the ability to stop processes in mid stride. Many cheaters use debugger techniques to set breakpoints or other triggers. These triggers can look for certain messages (e.g., a secret key press) or the use of particular functions (e.g., an easily thwarted DLL) and then carry out various nefarious activities.
Modern attacks of the sort that we describe in Chapter 6 often involve the use of sophisticated interrupt-driven state manipulation. More on that later.
Finding the Future: Predictability and Randomness, or How to Cheat in Online Poker
Many games involve an element of chance, poker being among the most obvious. The problem is that producing unpredictable randomness is nontrivial given the way computers work. Much work in software security has gone into improving randomness (which as you might imagine is also necessary for good cryptography).
Here's a good example of how poor pseudorandom number generators (PRNGs) can be broken in practice.11 In 1999, the Software Security Group at Cigital discovered a serious flaw in the implementation of Texas hold 'em poker distributed by ASF Software, Inc. The exploit allowed a cheating player to calculate the exact deck being used for each hand in real time. That means a player who used the exploit knew the cards in every opponent's hand as well as the cards that made up the flop (cards placed face up on the table after rounds of betting). A cheater could "know when to hold 'em and know when to fold 'em" every time. A malicious attacker could use the exploit to bilk innocent players of actual money without ever being caught.
The flaw exists in the shuffling algorithm used to generate each deck. Ironically, the shuffling code was publicly displayed in an online FAQ with the idea of showing how fair the game is to interested players (the page has since been taken down), so it did not need to be reverse engineered or guessed.
In the code, a call to randomize() is included to reseed the random number generator with the current time before each deck is generated. The implementation, built with Delphi 4 (a Pascal IDE), seeds the random number generator with the number of milliseconds since midnight according to the system clock. That means the output of the random number generator is easily predicted. As it turns out, a predictable random number generator is a very serious security problem.
The shuffling algorithm used in the ASF software always starts with an ordered deck of cards and then generates a sequence of random numbers used to reorder the deck. In a real deck of cards, there are 52! (approximately 2226) possible unique shuffles. The seed for a 32-bit random number generator must be a 32-bit number, meaning that there are just over 4 billion possible seeds. Since the deck is reinitialized and the generator reseeded before each shuffle, only 4 billion possible shuffles can result from this algorithm, even if the seed had more entropy than the clock. Yet 4 billion possible shuffles is alarmingly less than 52!.
The flawed algorithm chooses the seed for the random number generator using the Pascal function randomize(). This particular randomize() function chooses a seed based on the number of milliseconds since midnight. There are a mere 86,400,000 milliseconds in a day. Since this number was being used as the seed for the random number generator, the number of possible decks now reduces to 86,400,000—alarmingly less than 4 billion.
In short, there were three major problems, any one of which would have been enough to break the system.
- The PRNG algorithm used a small seed (32 bits).
- The PRNG algorithm used was noncryptographic.
- The code was seeded with a poor source of randomness (and, in fact, reseeded often).
The system clock seed gave the Cigital group members an idea that reduced the number of possible shuffles even further. By synchronizing the program with the system clock on the server generating the pseudorandom number, they were able to reduce the possible combinations down to a number on the order of 200,000 possibilities. After that move, the system is broken, since searching through this tiny set of shuffles is trivial and can be done on a PC in real time.
The tool Cigital developed to exploit this vulnerability requires five cards from the deck to be known. Based on the five known cards, the program searches through the few hundred thousand possible shuffles and deduces which one is a perfect match. In the case of Texas hold 'em poker, this means the program takes as input the two cards that the cheating player is dealt, plus the first three community cards that are dealt face up (the flop). These five cards are known after the first of four rounds of betting and are enough to determine (in real time, during play) the exact shuffle.
Figure 2-3 shows the GUI for the exploit. The Site Parameters box in the upper left is used to synchronize the clocks. The Game Parameters box in the upper right is used to enter the five cards and initiate the search. The figure is a screenshot taken after all cards have been determined by the program. The cheating attacker knows who holds what cards, what the rest of the flop looks like, and who is going to win in advance.
Figure 2-3 Cigital's Internet poker exploit can predict the outcome of a poker hand by taking advantage of a broken shuffling algorithm.
Once the program knows the five cards, it generates shuffles until it discovers the shuffle that contains the five known cards in the proper order. Since the randomize() function is based on the server's system time, it is not very difficult to guess a starting seed with a reasonable degree of accuracy. (The closer you get, the fewer possible shuffles you have to look through.) After finding a correct seed once, it is possible to synchronize the exploit program with the server to within a few seconds. This post facto synchronization allows the program to determine the seed being used by the random number generator and to identify the shuffle being used during all future games in under one second.
The ASF poker software was particularly easy to attack. However, most uses of linear congruential PRNGs (such as rand())are susceptible to this kind of attack. These attacks always boil down to how many outputs an attacker must observe before enough information is revealed for a complete compromise. Even if you only select random numbers in a fairly small range, thus throwing away a large portion of the output of each call to rand(), it usually doesn't take very many outputs to give away the entire internal state.
Many games other than poker make use of randomness. Any game that is completely predictable can be won by a simple program that knows how to predict what will happen next! As more and more money is poured into gaming, these kinds of randomness problems turn into cash cows for attackers.