CARRDS for Game Protection

Everybody wants a magic bullet; a miracle cure. Anything that will make unwanted problems go away. Of course, there is no such thing. However, understanding and using the CARRDS framework can help you avoid many of the problems that plague multi-player online games.

CARRDS is a conceptual framework for building networked games (see Figure 1):

Control – the keyboard, mouse, joystick, controller, Wiimote, voice, biofeedback, whatever raw means a Player uses to interact with a game.

Action – the normalized control that the game rules understand: WASD – Up, Left, Down, Right

Rules – the actual rules of the game.

Random – random events sit in the nebulous intersection of Actions (players rolling dice to determine their move choices), Rules (determining the result of an attack), and State (a Player’s cards). Also, random events raise some interesting problems in a networked environment.

Display – the presentation provided to a Player of the game’s State. Note, their can certainly be multiple views of the game’s State.

State – the current state of the game, or, in a multi-player game, the partial State known to a single player.

The simplest way to implement a networked game is to use a distributed object application and synchronize the game State (see Figure 2). This is very tempting. It is easy, fast, and the developer doesn’t have to think about the multi-player design. Basically, each player “does his thing” and the distributed object tool takes care of “smoothing” state out (essentially averaging the state between players or taking the latest version of state as authoritative).

The problem with this approach is that games are distributed transaction systems, not distributed object systems. Games do not necessarily have symmetric information, and the key to a multi-player game is that it is a game with rules. As you can see from the figure above, if a game uses state-based synchronization, cheating is very easy because the networking occurs “below” the game rules. Therefore, incoming state from a remote player is implicitly trusted by the very nature of the network communication. Even if the communication path itself is encrypted, a malicious player can use a tool like Cheat Engine to manipulate his local game State and trust in the distributed object system to push the corrupted data to the other players.

The other standard approach to multi-player gaming is to implement a client-server design (see Figure 3).

This approach is secure. Control or Actions can be sent to a central Server for processing. The archetype of this approach is a MUD where players enter raw telnet text and send it to the server which in turn returns new state information. The problem often comes from cheating by developers. The “cheat” I am talking about is that too often developers wind up implementing state and rules on the client-side AND using a State synchronization approach to update the server…. which leads back to right back to the scenario described above.

It is technically possible to implement a multi-player game via control (see Figure 4).

The main limitation of this approach is that there are often substantial differences between different computers in the raw control data that they use. Also, different game players may want to use different controls (different mice, trackballs, D-pad controllers) with different amounts and types of information and it would be unnecessarily burdensome to force the game to understand all of the different valid control systems.

Action-based gameplay networking (Figure 5) has a lot of advantages. Game actions are inherently bandwidth efficient.

The security advantage of this approach (and it applies to Control-based networking) is that it occurs “above” the game rules. Therefore, the game implementation can more naturally protect itself from remote malicious data. This is the updated version of the old game developer’s adage “don’t trust the client”.

The standard structure for game processing is therefore:

1. Incoming Action (local or remote).
2. Is the Action (and any associated parameters) Legal under the Rules*? (given the current state of the game, the player initiating the Action, etc.)
3. Implement the Action.
4. Update State (use the Action and its parameters in conjunction with the game Rules to determine the new game State).

* There are effectively two types of game rules, rules that update the game and rules about the legality of actions.

Random is, of course, also a part of this process (though it is a topic for another day).

CARRDS gives multi-player game developers a simple conceptual tool to understand the networking strategies that they have available and an understanding of the security consequences of each approach.

About the Author
Steven Davis, CEO of IT GlobalSecure, leads the SecurePlay (http://www.secureplay.com) game security product development, IT and game security engineering services and training. He writes a blog on game security on other industry issues at: http://www.playnoevil.com. Mr. Davis' twenty years of expertise includes security leadership positions at NSA, CSC, Bell Atlantic, and SAIC. He worked on Nuclear Command and Control, Key Management Systems, and other security systems for the government and commercial customers. He holds a BA Mathematics from the University of California-Berkeley and obtained his Masters Degree from George Washington University in Security Policy Studies. He holds several patents for innovative security solutions.