Open source, cross-platform anticheat

[quadz]

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.

I hate to be Captain WetBlanket McRainParade, but Linux isn't secure when the person doing the mischief has a local console with a root shell. Which is where the analogy needs to start to be at parity with someone hacking local anticheat software.

Security Through Obscurity sucks, of course -- but it's all we've got when the hacker is in complete control of the client?

[Jay Dolan]

Aren't we talking about the way to obscure the production credentials baked into the official builds of the agent software? That, I agree very much, will have to be a secret to make them difficult to extract from the binaries. But the rest.. I mean:

• Parse the signatures list, look for a hit.
• If you get a hit, fork / exec the game and watch its stdout.
• Watch for the AC token, HTTP PUT any tokens to the REST service.

There's no voodoo worth "protecting" here, is there? Using a valid SSL certificate on the web server, and forcing HTTPs on the agent, will make steering the REST calls elsewhere difficult. But, outside of that, we're talking about PUT'ing a small block of JSON and checking for some sort of "ack".

[Jay Dolan]

Another thought.. I could also statically link the agent to limit the number of DLL injection points (GNUPG, openSSL).

[LedZep]

You could make the anticheat send checksums of itself + its state + <salt> at server's request. The request from the server would contain the <salt>. For complexity's sake, the anticheat would have many states that change based on other server messages. This would effectively prevent dummy anticheat implementations and severly code-caved ones (since they would skip a bunch of state changes). Slight modifications to the anticheat.... I don't know.

edit

And by checksum of itself, I mean from memory, not the file. The server would also have to keep track of the specific client's 'would-be' state.
This is still obscurity I think, just proxied over to the AC as opposed to hard-baking the client :/

[VaeVictis]

You could make the anticheat send checksums of itself + its state + <salt> at server's request. The request from the server would contain the <salt>. For complexity's sake, the anticheat would have many states that change based on other server messages. This would effectively prevent dummy anticheat implementations and severly code-caved ones (since they would skip a bunch of state changes). Slight modifications to the anticheat.... I don't know.

edit

And by checksum of itself, I mean from memory, not the file. The server would also have to keep track of the specific client's 'would-be' state.
This is still obscurity I think, just proxied over to the AC as opposed to hard-baking the client :/

you could still make a dummy anticheat generate the appropriate data to hash when given the salt... so... yeah that won't help

some sort of asymmetric encryption involved with the salted hashing would have to take place... but even then, once it is decrypted on the client side, the malicious version could take over, and obviously it would have access to the same keys...

gah the more i think about it, the more it is just completely useless because everything is transparent to the client, and as quadz said it would have to run in a trusted environment

even if you had some super invasive service that went through a network shell and checked a memory dump of the game files... who is to say that shell isn't virtual?

if it is a trusted environment it fixes so many brain teasers... would be cool to figure out if there was a way to verify it was a trusted environment... but that is not 100% possible

ah security is so fucking useless... lets just all use telnet rsh and ftp, becaues fuck it... and store our passwords in LM hashing, and say to hell with SSL and use shttp rocking 3des... this shit just makes me sad

[hifi]

Hello,

I felt I had to comment on this too as jdolan mentioned my name in the first post.

It's a good thing everyone are pondering about the possible security problems with the system as it is essential to know the potential weaknesses of it before writing a single line of code. Even when (if we ever start working on it) it is finished, we must know all ways to bypass it as it will define the level of security we have.

That said, in my opinion the only function of the "anticheat" would be to validate that the actual client executable that is executed is one of the officially released ones. Meaning there is no antihack measures in it at all because it would require substantial amount of work and obfuscation to keep it somewhat secure from hackers.

So, what I would like to see is just that, a guarantee the client source is not modified (source based hacks) and that the client is not a known cheat client, simple binary hashing with SHA-XYZ is enough. Bonus points for content hashing too.

The purpose of all this is to make it impossible for a less skilled programmer to bypass it. Requiring in-memory patching/injection to cheat is something that I consider outside the context of a simple verification tool. I think Valve's VAC works a bit like this by verifying the data is valid when connecting to a server even though it most definitely has more sophisticated anticheat measures too.

Big issue that has been already said is trusting the environment. I think the only way to work around that is to force the game itself to do all IO through the tool itself. That way file loading can be trusted as it goes through the anticheat and it can hash the files on-the-fly from fread() calls by the game. Doing this is quite simple on Windows and Linux, possibly on other platforms too.

One problem that I haven't yet figured out completely in my own head is how to verify and launch the client executable in a trusted way. We must consider IO to be hooked and untrusted. Doing that (hooking/proxying) is very simple on both mentioned platform with either DLL overrides on windows or LD_PRELOAD or LD_LIBRARY_PATH on Linux.

One way to solve this the client executable needs to be loaded through that untrusted IO, verified in-memory, then launched - from memory. This would mean we need to implement our own PE loading mechanism (there are examples on the net) for Windows and the same for ELF just to support two platforms. Is it worth it? Are there any better approaches to launch the client?

Overall, in my opinion, the environment must be considered untrusted to get even the slightest level of security and everything we need must be statically linked to have some sort of integrity.

Finally, at this point, I don't yet see it being secure enough as long as I can (theoretically) bypass it without even opening the debugger. I hope we can figure all these things out and get it implemented. Before that, it must go through many skilled programmers and hackers to determine bypassing is NOT trivial.

[The Happy Friar]

I mentioned it before but noone commented, what about a members only server.  When you connect, if you're not in the accepted list of people to play you don't connect.  Have it be a server command (that can be in the cfg) to check a master server for approved players.  If you're caught cheating, you're booted.  new players must manually be approved.

[The Happy Friar]

If it's just a small group of players who only want to play against each other, or for match games, then you can just use a normal password protected server for this kind of thing.

Or even your own server, either way security isn't an issue, I agree.

If you're talking about doing something like this on a larger scale, then I'd be against the idea as it would only fragment the community more than it already is and would make it even harder for new players to find populated servers to join.

How would it fragment people any more then anything described above with special servers, clients, 3rd party files, etc?  People already sign in for Steam, Origin & other clients.  Any more player is either going to have stock Q2 (from Steam, CD, etc) or an already custom client from one of the starter packs floating around.  Those people would already need to go out of their way to get in to a "safe" server. 

[LedZep]

Tell me if this sounds like a good idea (this would probably help Q2W more than anything else):

Instead of playing around with some AC lib (which is a singleton by design pattern, meaning that due to its modular nature, exploiting would be easier), we should simply work on making the actual net protocol better. One of the first and most obvious things is the vis-ing. We should work on/improve sending clients information that is much more partial than what Q2 servers relay. This would already completely fuck over anyone trying to use wallhacks, since the server simply won't send the locations of players, projectiles and such behind walls (the visibility checking is done on the server).

After that, we can further increase the servers' anti-cheat logic, such as determining a client's net rate and adding a maximum delta angle per second (approximated through the net_rates). In the end, we could 'snap' a player's facing angle back to where it was on the server side if they try to do a full fledged 180 deg turn over 1 packet. This would start to close in on the aimbotters.

Believe it or not, there are certain behaviors that a cheat client often demonstrates. By identifying them properly and adding useful server-sided checks and requests, we could make the cheaters' lives a living hell.

[quadz]

We should work on/improve sending clients information that is much more partial than what Q2 servers relay. This would already completely fuck over anyone trying to use wallhacks, since the server simply won't send the locations of players, projectiles and such behind walls (the visibility checking is done on the server).

Sounds worthwhile. There's definitely room to improve on Q2's sv_nc_visibilitycheck.

After that, we can further increase the servers' anti-cheat logic, such as determining a client's net rate and adding a maximum delta angle per second (approximated through the net_rates). In the end, we could 'snap' a player's facing angle back to where it was on the server side if they try to do a full fledged 180 deg turn over 1 packet. This would start to close in on the aimbotters.

There are a couple kinds of aimbot: the kind where the movement is entirely human and the bot merely takes the shot at the correct time; and the old-school snap-angle kind. But even with the latter, cheaters use a narrow FOV for the bot, so there won't be massive delta angles.

I've occasionally wondered if a server-side neural net might be able to be trained to recognize narrow-FOV snap-angle bot aiming characteristics sent by the client; but I dunno how one would go about recognizing the bots that use purely human movement and just fire at the ideal moment.

[LedZep]

For the vis-checking, I say we use raycasting from client to client. Relying on BSP visleafs is useless, since some maps are compiled in full vis anyway :/ edit: I meant novis lol

You are right about the aimbots, some people actually limit the aimbot on purpose to reproduce the human-like smoothness/visibility. I think that we should do a nice little research project. Launch a server for testing hacks, but while people hack away on them, we can collect various kinds of data and compare them to non-cheaters. This could lead us to some discoveries

How does nc visibility check work anyways? Does the server just spoof other client's positions to some remote coordinates if the observing client can't see them? Or is the Q2 protocol happy with not getting all the clients' information in a frame?

[Jay Dolan]

It's not raycasting, it's just Cm_BoxTrace, but yes, adding a server-side visibility check would be a good way to minimize wall-hack opportunities and also save some bandwidth. I'll put an issue in Github to add this to Q2W. Thanks LedZep!

https://github.com/jdolan/quake2world/issues/51

[Jay Dolan]

How does nc visibility check work anyways? Does the server just spoof other client's positions to some remote coordinates if the observing client can't see them? Or is the Q2 protocol happy with not getting all the clients' information in a frame?

Q2's protocol actually has a pretty elegant "delta compression" technique, so you can elect to dis-include an entity at any given frame without causing problems. The next time an entity *is* included in a frame, a delta from its last transmitted state is calculated and appended to the packet. If the last transmitted frame is deemed to be too old, a full snapshot of the entity's state (a "baseline") is sent instead.

So there's really no reason to not add this, but I will say that some caution must be used to avoid entities appearing out of nowhere. Remember that the client's view origin is a few frames ahead of where the server thinks the client is, due to client-side prediction. So the server will have to "pad" the bounding boxes of entities (perhaps using some scale of the receiving client's latency and velocity, as well as the queried entity's latency (if player) and velocity).

Definitely an interesting idea. I'll have to experiment with it to see how often you can safely omit entities without risking visual artifacts.

[LedZep]

Interesting, I always thought delta frames were only introduced in Quake 3. I might have misinterpreted somebody's article or post (I can't remember what it was). It said that Quake 3's net code was much better than Q2's since Q2 sends the whole snapshot every frame. Or maybe the writer was misinformed

[Jay Dolan]

If you can point out the article, I'll decipher it for you. But Q2 absolutely uses delta compression:

https://github.com/jdolan/quake2/blob/master/src/server/sv_ents.c#L32