Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It
arrowPress Releases
September 22, 2019
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It


July 24, 2000 Article Start Previous Page 3 of 4 Next
 

The next major class of cheats is what I've dubbed "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 and models arguably fall under this classification, 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.

There are a couple of ways the hacker accomplishes this. 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. Then either the game .EXE file is modified to initialize those map control values differently, or a program is made that attaches to the game's memory space and modifies the variable values while the game is running. To combat this, the values of those variables should be regularly reported to other players in the form of a checksum or CRC code. Unfortunately, that only raises the stakes; the hackers then just attack the code that reads those control values (easy enough to find quickly), inverting or NOP'ing out the instructions that act upon them.

Additional techniques are needed to detect the hacked game view. There are a couple of ways to take advantage of the fact that the full game simulation is run on all clients. One way is to borrow a technique from the "authoritative client" section and check each command request for the side effects of a hacked map on one of the players. We specifically ask the game simulation, which is separate from the screen display, the question, "Can that player see the object he just clicked on?" In doing this we are assuming ahead of time that such hacks will be attempted, making sure we consider the side effects by which they might be detected. Once again, easing up on checks of the player's own machine is very useful. The next time the game performs a synchronization check, all the other players will agree that the cheating client is "out of synch" with the rest of the game and can deal with him accordingly.

Another technique that avoids looking at the display control variables is to compile abstract statistics on what gets drawn to the screen. The statistics are derived from the game simulation data and just filed away. This doesn't immediately prevent the hacker from cheating; instead, you send the statistics around as part of the status synchronization and see what the other players think of them.

In the RTS map-hack case, it is necessary for some change to be made to the game; either the code or some data is in a modified state while the game is running. And if something has been modified, you can attempt to detect that.

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. An industrious hacker once raised that scenario with me regarding one of the Age of Empires games, saying he had figured out how to read out of memory the resource amounts for every player. At first we thought that this wasn't very serious. He then explained that if he polled the values a couple hundred times a second, he could identify nearly every discrete transaction. A simple Visual Basic program could then display a log window for each player, with messages for events such as the training of various units (to the extent they could be distinguished from others on the basis of cost), and messages for events such as building construction, tribute, and advancement to the next age. Basically, this cheating method was the next best thing to looking over the shoulders of his opponents.

Rule #7: There is no such thing as a harmless cheat or exploit. Cheaters are incredibly inventive at figuring out how to get the most out of any loophole or exploit.

Intrigued, I asked him how he could be sure he had found the correct memory locations each time, as they changed each game since they were stored in dynamically allocated classes. His answer was most interesting. He first scanned the memory space of a paused game looking for known values for things such as population, wood, gold, and other very significant game values that he knew about and believed were unique. He had a simple custom program that looked for the values in basic formats such as long ints and floats. After his program identified all the possible addresses with those values, he ran the game a bit more until the values had changed. He then reran the program, checking the prior list of locations for the new values, reducing the list of possible addresses until he was sure he had found the correct locations. He then put a read-access breakpoint on the value and looked at how it was accessed from various points in the code. At one of the breakpoints, the C++ code for accessing the wood amount looked something like this:

GAME_MASTER -> GAME_WORLD->PLAYER[n].
ResourceAmount[Wood_Index];

This is a pointer to a pointer to an object containing an array of integers, one of which contains the value of the player's current stockpile of wood, and all the objects are dynamically allocated. The hacker's point was that if you trace back through all the dynamic pointers, you eventually find a static variable or base pointer. The different spots where his breakpoints were triggered were from member functions at different levels in the class hierarchy, and even from outside the class hierarchy containing the data. And it was finding an instance of that latter access condition that was the jackpot. There it was in his debugger's disassembly window: a base address and the Assembly code to traverse through the classes and handle player and resource index numbers.

Considering all this, I found a couple of strategies that can greatly reduce the likelihood of this sort of passive attack. Again, these tips 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. Upon consideration, most game variables are not significant enough to warrant such protection - the hit points of a particular object don't tell anyone much, while a drop of 1,000 food and 800 gold from a player's resources does indicate that the player is advancing to the Imperial Age, which is an event of large strategic importance in our game. 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. In C++, our encrypted assessor functions for game resources look something like what's shown in Listing 1.

Listing 1. Hiding the variables that tip off hackers to possible cheats.

void GameResource::SetResource(int Resource_Num, int Resource_Amount)
{
GameResourceAmount[ResourceNum] = Resource_Amount ^ EncryptValue[ResourceNum];
}
int GameResouce::GetResource(int Resource_Num)
{
return( GameResourceAmount[ResourceNum] ^ EncryptValue[ResourceNum] );
}
//and more specific functions...
void GameResource::SetWood(int Wood_Amount)
{
GameResourceAmount[RESOURCE_WOOD] = Wood_Amount ^ EncryptValue[RESOURCE_WOOD];
}
int GameResource::GetWood(void)
{
return( GameResourceAmount[RESOURCE_WOOD] ^ EncryptValue[RESOURCE_WOOD] );
}

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. A piece of C++ code you won't see in our next RTS game would be the following:

GLOBAL_GAME_POINTER -> PLAYER_DATA[n] ->
RESOURCE_TABLE[gold] = SOME_UNIQUE_START_VALUE;

Information access isn't limited to games as complex as RTS games, it can extend to something as simple as a card game. Consider an online card game such as poker. All it would take to ruin the game is for a player to see the values of the face-down cards in another player's hand. If the information is on the machine, hackers can go digging for it. This goes back to rule number four.


Article Start Previous Page 3 of 4 Next

Related Jobs

HB Studios
HB Studios — Lunenburg/Halifax, Nova Scotia, Canada
[09.20.19]

Experienced Software Engineer
University of Exeter
University of Exeter — Exeter, England, United Kingdom
[09.20.19]

Serious Games Developer
innogames
innogames — Hamburg, Germany
[09.20.19]

PHP Developer - Tribal Wars
innogames
innogames — Hamburg, Germany
[09.20.19]

Java Software Developer - New Mobile Game





Loading Comments

loader image