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:
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:
+set ac 1) that informs the client to attempt to use the AC protocol extensions.
stdout. During the connection handshake, after a
challengehas 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.
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.