Quetoo BETA Pwning nubz one rail slug at a time.

Lately I've been reevaluating my stance on anticheat measures in GPL games -- specifically in Quake II and Quake2World. For years, I've advocated just playing with people you trust, on servers you trust, and leaving it at that. After all, it's just a game, right? Anyone cheating to win at Quake is probably losing at life..

But my recent adoption of Quake II maintenance for Mac and Linux has spurred me to reconnect with the active Quake II community, and within that community a strong desire for anticheat measures still exists. And finally, what always pushes me over the edge to explore a new project, the technical challenges to implementing an anticheat for the first time seem interesting to me.

The primary goals of a good anticheat solution, to me, should be:

• Cross platform and open source: Forcing users to run one particular engine on one particular OS is unacceptable.
• Easy to implement for engine maintainers: Simple game source modification requirements will drive anticheat adoption.
• Use industry-standard technologies where possible: Don't reinvent the wheel poorly; SSL and digital signatures ftw.

The approach I'm proposing consists of two primary components: a client-side agent program and a server-side web service. Here's how it would work:

• Consensus around trusted clients is built from the community. Quake II engine maintainers deemed trustworthy begin signing their releases with GNUPG. They submit their signatures to the anticheat maintainers for inclusion.

• A web service is created which can, among other things, return the authoritative list of trusted signatures for a particular game.
• An agent program is created to run on all client machines where AC will be used. The agent is responsible for launching the game.
• The agent will refuse to launch executables which do not have a hit in the authoritative list of signatures, downloaded from the web service over HTTPS at startup.
• The agent launches the game with a cvar (+set ac 1) that informs the client to attempt to use the AC protocol extensions.
• Because the agent launches the signed client, it can parse its stdout. During the connection handshake, after a challenge has been initiated, the client generates a one-time use token (a GUID) and prints it out before sending it to the server to complete the challenge.

• The agent program parses out the token and submits it to the web service as well. The token is bound to the client's IP and qport for identification. Additional information, such as the signature used to obtain the token, can also be transmitted.
• The game server can now query the web service for the token before allowing or disallowing the connection. The token is removed from the web service once it is returned to the game server. Tokens also expire automatically from the web service after 1 minute.
• The presence of a valid token from the web service demonstrates that a signed client has initiated the current connection: the server can trust that client.

With a trusted connection established, further protection measures can be taken: the server can ask the client to return hashes of media assets to verify that they are also authentic. In this way, servers could optionally protect against modified content and enforce a pure server environment.

The beauty of this model is that it's relatively simple to implement in any Quake-derived game, and the mechanism itself can be generalized to support many games. In fact, a single web service and agent program could authenticate clients for Quake, Quake II, Quake 3 Arena, and all of their open source derivatives.

The other key advantage of this model is that it can be entirely open source. Because only trusted engine maintainers would be allowed to submit signatures for their binaries, the AC-enabled game engine source code poses no immediate threat.

The agent and web service can also be open source, with the caveat that the credentials the agent uses to authenticate with the web service in a production environment will only be included in "official" builds. Obfuscating these credentials is a key concern, as this will be the primary attack vector in this system.

I'd like to start working on this once I've wrapped up a couple smaller changes in the Quake2World experimental branch. Feedback and help are most welcome! There's also a discussion thread on the TastySpleen Quake forum where this idea first surfaced.