Open source, cross-platform anticheat

[Jay Dolan]

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:

• 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.

[Jay Dolan]

Okay, so this is hilarious. The approach I described above is actually precisely what John Carmack prescribed to the community in 1999 when id first GPL'ed the Quake1 engine:

There are a number of people upset about the Quake 1 source code release, because it is allowing cheating in existing games.

There will be a sorting out period as people figure out what directions the Quake1 world is going to go in with the new capabilities, but it will still be possible to have cheat free games after a few things get worked out.

Here's what needs to be done:

You have to assume the server is trusted. Because of the way quake mods work, It has always been possible to have server side cheats along the lines of "if name == mine, scale damage by 75%". You have to trust the server operator.

So, the problem then becomes a matter of making sure the clients are all playing with an acceptable version before allowing them to connect to the server. You obviously can't just ask the client, because if it is hacked it can just tell you what you want to hear. Because of the nature of the GPL, you can't just have a hidden part of the code to do verification.

What needs to be done is to create two closed source programs that act as executable loaders / verifiers and communication proxies for the client and server. These would need to be produced for each platform the game runs on. Some modifications will need to be done to the open source code to allow it to (optionally) communicate with these proxies.

These programs would perform a robust binary digest of the programs they are loading and communicate with their peer in a complex encrypted protocol before allowing the game connection to start. It may be possible to bypass the proxy for normal packets to avoid adding any scheduling or latency issues, but it will need to be involved to some degree to prevent a cheater from hijacking the connection once it is created.

The server operator would determine which versions of the game are to be allowed to connect to their server if they wish to enforce proxy protection. The part of the community that wants to be competetive will have to agree to some reasonable schedule of adoption of new versions.

Nothing in online games is cheat-proof (there is allways the device driver level of things to hack on), but that would actually be more secure than the game as it originally shipped, because hex edited patches wouldn't work any more. Someone could still in theory hack the closed source programs, but that is the same situation everyone was in with the original game.

People can start working on this immediately. There is some prior art in various unix games that would probably be helpfull. It would also be a good idea to find some crypto hackers to review proposed proxy communication strategies.

http://floodyberry.com/carmack/johnc_plan_1999.html#d19991225

This was pointed out to me by someone with a very good memory in #icculus.org.

[M1SERY]

German!

[Golgo13]

If enough people want it, I would probably build it for Q2 and Quake2World.

if you build it, they will come..      

[|iR|Focalor]

if you build it, they will come..

They will come... to trash talk it and call it spyware/malware without knowing what it does or how it works? You're funny. The guy who has historically decried anticheat is now gonna jump on board with it. Why? What changed?

[quadz]

because hex edited patches wouldn't work any more.

Problem is, there have been Q2 cheats on Windows for over a decade that would escape the detection of a secure launcher mechanism.

http://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-Proces

R1ch's anticheat was out of necessity designed to thwart runtime code injection.

These days, there's even some proof-of-concept aimbot code floating around that doesn't bother with code injection, and merely uses WriteProccessMemory to directly update memory locations in the client (mouse position and such.) I don't know a way around these except to have the client aggressively relocate key variables.

I definitely like the idea of a cross-platform anticheat for Q2. And the secure loader idea might be better than nothing on other operating systems -- but unfortunately it's insufficient for existing cheats on Windows.

[The Happy Friar]

What's the advantage over anticheat, except multiplatform?

I've thought about it too, the game Defcon did it in a neat way I thought.  It had no specific cheat protection, but it assumed the server was always 100% correct in it's code (like carmack said), if the client didn't match the server when a command was sent, it overwrote the client's command when it was send from the server to the clients.  IE the client has a hack for 100 super-fast ICBM's.  Doesn't match the server code so it just ignores the client's code & send the "correct" data.  I'm not sure why Q2 couldn't do this, the server already has the client code & knows the locations of players, so it can be told players can't move at such a speed, they can't aim so fast, etc.   In Q2 this would be the equivalent of anti-lag code that snaps you back in place where it thinks you should be, but instead it changes your weapon models, adjusts your speed, etc.

Since we're assuming the server ops are legit & not immoral, could a md5 checksum of "safe" client's be made & the server just have some code to check if the client has a valid checksum of a client?

The issue I see with having a list of trusted clients is getting the client on to the list.  Tweaks to the code & a recompile would need to be resubmitted, so keeping up to date could be annoying at times (but it's not like Q2 clients are updated every week).  What's a trusted client?  How could a new client get on to the list?  Etc.  Those are minor details at this point though.

In regards to cheats, I always thought a neat would would be a program that doesn't inject code or write to memory, but a program that plays the game for you.  It sends keyboard/mouse commands to the client so there's no actual interacting with the client, the client things it's a standard kb/mouse imput.

[quadz]

the game Defcon did it in a neat way I thought.  It had no specific cheat protection, but it assumed the server was always 100% correct in it's code (like carmack said), if the client didn't match the server when a command was sent, it overwrote the client's command when it was send from the server to the clients.  IE the client has a hack for 100 super-fast ICBM's.  Doesn't match the server code so it just ignores the client's code & send the "correct" data.  I'm not sure why Q2 couldn't do this, the server already has the client code & knows the locations of players, so it can be told players can't move at such a speed, they can't aim so fast, etc.

Q2 servers indeed have accounted for most of this from the beginning, and modern Q2 servers place constraints on movement speed as well.

Historically in Q2, the only trusted data from the client equates to the current "buttons pressed" bits, plus the view angles, per any given moment in time.

This narrow-bandwidth protocol puts severe theoretical constraints on what sorts of cheats are possible. (Leaving aimbots, wallhax, speedhax, but ruling out any kind of "scripting" attacks that plague some other games. For example, there's no way in Q2 for a client to fool the server by claiming to be temporarily in 'god mode' or to have a health or ammo boost, etc. The protocol is decisively too narrow for that.)

could a md5 checksum of "safe" client's be made & the server just have some code to check if the client has a valid checksum of a client?

Picture the client as a network socket, because that's all the server can see. Client & server each send numbers to one another that are assigned some semantic meaning by the receiving end. The client can lie about any question asked by the server, by sending back the appropriate numbers.

In regards to cheats, I always thought a neat would would be a program that doesn't inject code or write to memory, but a program that plays the game for you.  It sends keyboard/mouse commands to the client so there's no actual interacting with the client, the client things it's a standard kb/mouse imput.

Right; indeed, my prior post mentioned a variation on this theme -- but generally speaking in an era when a full modern Linux kernel can boot up in JavaScript in a web browser, anticheat all comes back to what {some} client sends vs. what {some} server believes.

[LedZep]

because hex edited patches wouldn't work any more.

Problem is, there have been Q2 cheats on Windows for over a decade that would escape the detection of a secure launcher mechanism.

http://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-Proces

R1ch's anticheat was out of necessity designed to thwart runtime code injection.

These days, there's even some proof-of-concept aimbot code floating around that doesn't bother with code injection, and merely uses WriteProccessMemory to directly update memory locations in the client (mouse position and such.) I don't know a way around these except to have the client aggressively relocate key variables.

I definitely like the idea of a cross-platform anticheat for Q2. And the secure loader idea might be better than nothing on other operating systems -- but unfortunately it's insufficient for existing cheats on Windows.

Meh, the hacks that write directly to process memory aren't that scary IMO, since they would have to have lengthy offset tables for every client, and every version of the client. As soon as an update rolls out, the author of such a cheat would have to create yet another file that contains new locations for the variables. This would be tedious, and (in most cases) would make the hack of a private nature.

Same goes for the infamous Cheat Engine. You can write scripts that read/write from processes and such at a very low level, and eventually make an aimbot. However it's not practical and extremely difficult... unless someone knows a client author's exact build environment, cflags, etc and traces the memory locations at compile o.0

I thought about it on Carmack's scale, and he's right. The client can always spoof messages to the server. At least at driver level. Our only hope is security through obscurity. How about closed-source multi-platform AC with promises to hand it off to a trusted person?

edit

I like the idea of "aggressively changing variables" though. Funny you should mention it. A lot of flash games fully rely on the client, and at the very end publish scores to a web server. This is why a lot of their authors implement that exact memory edit counter-measure. It's not that easy to find what you're looking for when there's dozens of copies of it, with a bouncing pointer. Or even with pointers to pointers, etc.

[Jay Dolan]

DLL injection on Windows (and, to a lesser extent, Mac and Linux) seems to be a weakness you can't easily code around. I have nothing to counter that point, quadz. Likewise, if someone has a hacked OpenGL driver, there's not much you can do that works everywhere.. is there?

But aren't cheats that try to write directly to a process' address space mitigated by ASLR in recent OSes?

Edit: lawl, HTML != UBB syntax

[The Happy Friar]

Picture the client as a network socket, because that's all the server can see. Client & server each send numbers to one another that are assigned some semantic meaning by the receiving end. The client can lie about any question asked by the server, by sending back the appropriate numbers.

Wouldn't it be possible then for someone to bypass an anticheat program and always send an "all good" signal?

Maybe we shouldn't be looking at making an AC that stops people from cheating, maybe we should be looking at a client+server combo that makes the cheating hard enough to do people won't bother for a decade+ old game.  A custom Q2 server that locks so many things in place, the client must math everything, user names/passwords for players, things like that.

I know, then it's like Steam, and I hate Steam, but those methods stop cheating more then an external program that can be ignored.

[quadz]

I thought about it on Carmack's scale, and he's right. The client can always spoof messages to the server. At least at driver level. Our only hope is security through obscurity.

Agreed -- that's indeed what I was getting at in the subsequent post mentioning the JavaScript PC emulator that boots Linux inside a web browser tab. At any given level, software can't tell whether the level above is emulated.

At some point anticheat.dll makes system calls, and simply has to trust it's running in a genuine environment...

[ex]

Meh, the hacks that write directly to process memory aren't that scary IMO, since they would have to have lengthy offset tables for every client, and every version of the client. As soon as an update rolls out, the author of such a cheat would have to create yet another file that contains new locations for the variables. This would be tedious, and (in most cases) would make the hack of a private nature.

Same goes for the infamous Cheat Engine. You can write scripts that read/write from processes and such at a very low level, and eventually make an aimbot. However it's not practical and extremely difficult... unless someone knows a client author's exact build environment, cflags, etc and traces the memory locations at compile o.0

I don't know a single thing about coding, but I can weigh in a tiny bit on this.  I knew a guy about a decade ago who would do exactly what you're talking about, a new hacked version of a client every time there would be an update made to it.  It was so sad that sometimes it would be done the very day the update was released (usually within hours).  Some people are just monsters with coding and can hack things with ease, so it's not unbelievable to think that someone would be able to do this kind of stuff.  It's been done before, in this very game, probably more than just a few times.

BTW I do fully support the ideas of making a cross-platform AC.  Not sure about the open source thing, though, since that would enable a coding genius to hack it continually.  It should probably be kept somewhat private within the hands of a few trusted individuals (quadz, jay dolan, R1ch [if he's ever around anymore] etc.).

[X'tyfe]

1, How does it compare to R1's anticheat?
2, Is it even needed?


As far as question 2, my reasoning is that: How many cheats actually work outside of a Windows environment? Pretty much 0 right? The only issue that users on other platforms face with this is that they are locked out from forced AC servers. Now that is valid reason for a new system since that was an obvious design oversight with what R1 did.

HOWEVER, I would argue that anticheat of any kind is a wasted effort, especially for a 12 year old game that people barely play. Hackers WILL find a way to do it no matter what, its the same for piracy. As an example, Ezquake, which is a modern form of Quakeworld initially had a similar system in place but they ditched it because it was a waste of time. Why put all this effort in if it will be for nothing? And especially if the intention is to make it an open thing, I don't fully understand how you plan to keep this open and not have it foiled easily but I'd argue this even more strongly on that point alone.

[Jay Dolan]

1, How does it compare to R1's anticheat?
2, Is it even needed?


As far as question 2, my reasoning is that: How many cheats actually work outside of a Windows environment? Pretty much 0 right? The only issue that users on other platforms face with this is that they are locked out from forced AC servers. Now that is valid reason for a new system since that was an obvious design oversight with what R1 did.

HOWEVER, I would argue that anticheat of any kind is a wasted effort, especially for a 12 year old game that people barely play. Hackers WILL find a way to do it no matter what, its the same for piracy. As an example, Ezquake, which is a modern form of Quakeworld initially had a similar system in place but they ditched it because it was a waste of time. Why put all this effort in if it will be for nothing? And especially if the intention is to make it an open thing, I don't fully understand how you plan to keep this open and not have it foiled easily but I'd argue this even more strongly on that point alone.

You're missing a number of key points:

1. It won't be necessarily just for Quake2. In fact, I would probably roll this out for Q2W first and then backport it to Q2. Other Q2-derived games (Alien Arena, UFO:AI, ..) could also use it -- not just the technology itself, but the same exact launcher and web service. The protocol extensions could easily be ported to Q1 and Q3 as well.
2. Writing hacks for open source games is trivial. You assume that there are no cheats for Mac and Linux out there; I disagree. I bet there are plenty, but there is zero way to detect or prevent them today. Anyone with familiarity with these engines could write an aim bot in hours. Wallhacks in less.
3. Open-sourcing the implementation does not automatically compromise its effectiveness -- that's a very ignorant claim. Is the Linux kernel insecure? The security of the proposed solution is derived from the mechanisms it employs, not from keeping its inner workings a secret.