Show Posts
1
Quake / Open source, cross-platform anticheat
« on: April 12, 2013, 04:38:08 AM »
hifi and I were brainstorming the AC dilemma this morning and came up with a possible cross-platform, open source solution that could facilitate multiple maintainers. It uses industry-standard techniques like digitally signed binaries and HTTPS. There are two major components: a client-side agent and a server-side web service. There are also minor game protocol extensions required. Here's how it works:
This doesn't yet handle any content hacks, but I think it's a good start towards supporting as many client engines and operating systems as possible. I think the work to implement this on the client is actually rather minimal, too. And because we can verify that the client is authentic here, adding content checks in is actually meaningful. So that's a huge plus.
There is minimal risk in allowing the the Quake-side implementations of this AC be open source. Because only trusted maintainers can submit signatures for their binaries, having the source code readily available poses no immediate threat. The agent and web service can also be open source. The credentials the agent uses to authenticate with the web service in a production environment, however, will have to be very carefully guarded and only included in "official" builds. Obfuscating these credentials in the official builds will be a key concern, as this would be the primary attack vector in this system. A compromised agent program could execute unsigned, insecure client engines, allowing them to pose as authentic.
The point of this thread is to discuss any pitfalls or problems with this approach and to gage the level of interest in this solution. If enough people want it, I would probably build it for Q2 and Quake2World.
- Consensus around trusted clients is built from the community. Quake2 engine maintainers deemed trustworthy begin signing their releases with GNUPG. They submit their signatures to a central repository.
- 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 any binaries which do not have a hit in the authoritative list of signatures, which the agent downloads from the web service over HTTPs at startup.
- The agent launches the client with a cvar (+set ac 1) which 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 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 tied to the client's IP and qport for identification.
- The 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 in the central web service demonstrates that a signed client has initiated the current Quake2 connection.
This doesn't yet handle any content hacks, but I think it's a good start towards supporting as many client engines and operating systems as possible. I think the work to implement this on the client is actually rather minimal, too. And because we can verify that the client is authentic here, adding content checks in is actually meaningful. So that's a huge plus.
There is minimal risk in allowing the the Quake-side implementations of this AC be open source. Because only trusted maintainers can submit signatures for their binaries, having the source code readily available poses no immediate threat. The agent and web service can also be open source. The credentials the agent uses to authenticate with the web service in a production environment, however, will have to be very carefully guarded and only included in "official" builds. Obfuscating these credentials in the official builds will be a key concern, as this would be the primary attack vector in this system. A compromised agent program could execute unsigned, insecure client engines, allowing them to pose as authentic.
The point of this thread is to discuss any pitfalls or problems with this approach and to gage the level of interest in this solution. If enough people want it, I would probably build it for Q2 and Quake2World.
