FreeGameDev

http://quake2world.net/blogs/jdolan/gpl-quake-anticheat

Gives an interesting overview on a potential open-source implementation of such an anti-cheat feature.

Personally I am in the camp of "it is only a game and you can quit if someone cheats"... but sometimes there are only a few servers active, and one guy (edit: or gal ) can ruin it for the rest of players... so some sort of anti-cheat tool might be a good thing after all. And for sure it is something many players demand and it is also used as an argument against open-source multiplayer games (as silly as that might be).

I can be only agree. If you can't stand to play with other human players, don't go multi. Cheating is silly in this case.

Julius {l Wrote}:http://quake2world.net/blogs/jdolan/gpl-quake-anticheat

Gives an interesting overview on a potential open-source implementation of such an anti-cheat feature.

Personally I am in the camp of "it is only a game and you can quit if someone cheats"... but sometimes there are only a few servers active, and one guy (edit: or gal ) can ruin it for the rest of players... so some sort of anti-cheat tool might be a good thing after all. And for sure it is something many players demand and it is also used as an argument against open-source multiplayer games (as silly as that might be).

I showed this to Quin (Red Eclipse developer) as it isn't all that hard to implement and issues with Linux distros packaging it themselves can be sorted out by giving a private key.

There is one huge problem though.
Forget compiling the game yourself.

I like having the latest and greatest, until compatibility breaks anyway (at which point I stop updating until it returns). Sure, there will be 'no anti-cheat' servers but not only will they be few and far between, no-one will play on them (e.g. all of Valve's games) and if they do, they will probably be the bots of a programmer testing their skill out.

So just consider that aspect before you immediately go waving this banner. Still, it does seem the best and easiest way to create a solid anti-cheat system - disallow custom binaries.

Evropi {l Wrote}:There is one huge problem though.
Forget compiling the game yourself.

Well, of course, this wouldn't necessarily be true.

Just if you want to play on the official game servers, you need a key. Since it is open source, sombody could run a server without a key required.

Well there could be nightly signed builds like Xonotic's autobuild feature for those wanting to stay bleeding edge, but yeah this is rather something to do once your game has a bit more maturity and people stick to the official builds mostly.

Even if the server only accepts signed binaries, it still can't prevent cheating, because someone can hack the client source code to let it use the data of signed binaries to fool the server

charlie {l Wrote}:

Evropi {l Wrote}:There is one huge problem though.
Forget compiling the game yourself.

Well, of course, this wouldn't necessarily be true.

Just if you want to play on the official game servers, you need a key. Since it is open source, sombody could run a server without a key required.

The point was that no-one but bots would go on these servers like <insert any game with anti-cheat technology and dedicated servers here>.

acme_pjz {l Wrote}:Even if the server only accepts signed binaries, it still can't prevent cheating, because someone can hack the client source code to let it use the data of signed binaries to fool the server

Hence why the key is kept private. -.-

Correct me if I'm wrong, but only the agent checks the signature of the binary. Therefore, you'd only need to modify the agent to always launch the main client, even if the signature does not match.

CruzR {l Wrote}:Correct me if I'm wrong, but only the agent checks the signature of the binary. Therefore, you'd only need to modify the agent to always launch the main client, even if the signature does not match.

Well, you would not be able to simply recompile the agent to always launch the client, since the agent binary contains a secret key embedded in it (if I understood correctly), and without that key it cannot communicate with the auth server.

However directly modifying the agent binary would be possible, and it only takes one person to do that and spread that hacked agent binary around to break this system. The goal would be to make the agent binary as hard to modify as possible, but having the source available is contrary to that goal.

This system definitely makes it harder to cheat, and for small communities perhaps that would be enough to prevent cheating, and minimise it for larger communities. Looks like J.Dolan is going to implement this system, and it'll be very interesting to see if it helps to reduce or prevent cheating.

andrewj {l Wrote}:
Well, you would not be able to simply recompile the agent to always launch the client, since the agent binary contains a secret key embedded in it (if I understood correctly), and without that key it cannot communicate with the auth server.

However directly modifying the agent binary w d be possible, and it only takes one person to do that and spread that hacked agent binary around to break this system. The goal would be to make the agent binary as hard to modify as possible, but having the source available is contrary to that goal.

This system definitely makes it harder to cheat, and for small communities perhaps that would be enough to prevent cheating, and minimise it for larger communities. Looks like J.Dolan is going to implement this system, and it'll be very interesting to see if it helps to reduce or prevent cheating.

Yeah, that's what I meant. You simply disassemble the agent binary, find the branch instruction where it decides whether to trust the client or not, and then use a hexeditor to replace the branch instruction with a nop or an unconditional jump, depending on whether the first or the second branch is the correct one.

Whatever happened to "the server is always right"?

Before login the server could check hashes of the binary and all used mods, to prevent incompatible versions (our cheater has these "fixed" of course). The server keeps track of every client's state.

Now, every action a client takes is sent to the server for verification. Every valid action gets added to the random seed, which in turn is used to generate a random number every 3 seconds. That random is also requested from each client. Is the random from a client different, then it's out of sync and disconnected with a nice error message. Bye bye cheater.

This mechanism's actual purpose is to find bugs, but it conveniently helps with removing cheaters.

Other games also use the method to check, if the client has modified files different than the default ones. Now you could make it strict and kick everyone who has modified files or just give a warning like some others games I played do.

Duion {l Wrote}:Other games also use the method to check, if the client has modified files different than the default ones. Now you could make it strict and kick everyone who has modified files or just give a warning like some others games I played do.

Interesting... how would this be checked? Sounds like an expensive process to handle on the server. On the client, I guess it could be easily removed. Do you have more details? This is intriguing.

You probably know this but I'm just gonna say it for the record...

As I understand it, the proper solutions to prevent any and all cheats (without signing binaries...) would be to make the server the only one doing authorative model updates. The clients just display information from the server and sends commands to the server. So basically the client is degraded to a "viewer".

doktorfinkelstein {l Wrote}:You probably know this but I'm just gonna say it for the record...

As I understand it, the proper solutions to prevent any and all cheats (without signing binaries...) would be to make the server the only one doing authorative model updates. The clients just display information from the server and sends commands to the server. So basically the client is degraded to a "viewer".

Yes that is the least hackable way, but unless you have a very good connection to the server (high bandwidth and low latency) it provides a poor experience to the player, since the client can only show what the server sends -- you cannot render any frames in-between since you don't have the game state. So when you move the mouse, it takes time for your view to change (round trip to server and back), and that's bad for immersion.

andrewj {l Wrote}:

doktorfinkelstein {l Wrote}:You probably know this but I'm just gonna say it for the record...

As I understand it, the proper solutions to prevent any and all cheats (without signing binaries...) would be to make the server the only one doing authorative model updates. The clients just display information from the server and sends commands to the server. So basically the client is degraded to a "viewer".

Yes that is the least hackable way, but unless you have a very good connection to the server (high bandwidth and low latency) it provides a poor experience to the player, since the client can only show what the server sends -- you cannot render any frames in-between since you don't have the game state. So when you move the mouse, it takes time for your view to change (round trip to server and back), and that's bad for immersion.

Yes! Good example. But for some games - say, a submarine simulation with just a radar screen - it would work. But definitely not for an FPS. As I understand it, modern FPS like BF3 do a mix of "server is authorative" and client can do some hit detection.

And if I remember correctly, bf1942 had server-side hit detection and that's why you had to adapt your weapon lead depending on the ping you had. fun times!

And another thought: if the game is purely LAN, it's also a feasible option.