[This chapter excerpt is printed with permission of Addison-Wesley Professional from the book Exploiting Online Games by Gary McGraw and Greg Hoglund. Please note that Gamasutra itself presents this excerpt as a service to professional game developers wanting to learn about exploitation techniques, and does not advocate using the below techniques to exploit games.]

Data, Data, Everywhere

Two kinds of things can be altered in a software program—the code itself and the data that the code interacts with. (Just to complicate matters, the code itself is, of course, a form of stored data.) Ultimately, everything is just data—a sea of perfectly choreographed 1s and 0s. This insight has huge ramifications for the online game hacker.

Any data that are sent to a game client can be accessed or modified. Once data exist in the game client, they are yours for the taking (and yours for manipulating)—even data you’re not supposed to see. For example, if the game client knows the location of a hidden secret potion, those data must exist in the game client somewhere even if the data are not apparent to you in the user interface. Making this even more fun, many times these game data can be manipulated and changed. For example, if the hidden magic potion is too far away, perhaps you can alter its location coordinates so that it conveniently ends up on the ground right in front of you!

Game clients display information to the game player through the user interface. However, the interface displays only part of the information that the client software possesses—the part that the player is supposed to see. There is often plenty more information under the hood. Assume that there is a magic potion, and that the potion has properties including strength, power, and duration. Under the hood, a software program is managing the magic potion. In our example, if the strength of the magic potion is greater than 100, you get an extra bonus. When you click the Drink button, the potion’s strength will be checked by the software and a bonus may be applied (but only if the condition is met).

[ More book information... ]

As we noted earlier, at the deepest layer of the game client, everything is just data. Even the software itself is stored as data. The software that makes the potion decision is stored in one location, and the data that represent the potion’s strength are stored in a different location. This is typically how it is—executable software bytes are stored in a special area away from the rest of the data. To complete our example and see how all of this matters, if you wanted to fool this game into giving you a bonus, you could go into memory and alter the data that control the potion’s strength. If you set the potion strength data to a number greater than 100, then when the software executes (after you click the Drink button), it will give your character a bonus. You might do this with a fault injection engine or a debugger, or maybe just by poking a value into memory by hand.

The user interface displays only part of what the client software knows. Sometimes you’re supposed to see only pieces of what the software knows as part of the game. In this case, more information about the magic potion is available in the program than is ever displayed to the user. We can look at the software and the data to learn more.

This begs the question of how hard it really is to find out where the potion’s strength is stored. This may sound a bit like a needle-in-a-haystack problem. There are in many cases millions of bytes of data in a single running program. Simply taking a stroll around in the data without a guide turns out to be not very useful. You need some kind of guide to show you what kind of data you’re looking at, and even more specifically, how the data are used. Fortunately, a number of tools and techniques are at your disposal.

First, and most important, data get used. Data are either code or data operated on by code (and in some more complicated cases, both!). If the bits are code, they will be loaded into the CPU at some point and executed. Most disassemblers can find this code and mark it as code, and they’ll subsequently show you the instructions that the code translates to in assembly language. Figure 6–7 shows what assembly language looks like once binary has been through a disassembler.

Figure 6–7 - A disassembler takes binary code and creates assembly code that looks like this. The numbers in the left column are the memory locations where the machine code is located. The corresponding assembly language is in the right column.

But what about normal data? If you have disassembled the code, the code can provide hints as to the location of data. Figure 6–8 shows the code accessing a data location at 0001F574. Because of the way the code is structured, we now know that memory location 0001F574 stores some kind of data. As it turns out, most code contains volumes of information like this to help us find data of interest.

Figure 6–8 - Data are accessed by previously disassembled code, as shown here.