Cheating & open source, revisited

by Aardappel_ on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 188229 views, last view: 11/01/2024 09:32

As you all know, cheating is a problem for Cube being Open Source. Noone likes the current solution of the incompatible binaries, and I am getting to the point where I see the usefulness of having other people continue to work on Cube whenever I don't have the time.. currently that is problematic and would be much easier if the source to the official game could be truely open.

Multiplayer continues to be an important aspect of Cube, so we can't ignore cheating and simply hope that people won't change 1 line of code to enable god mode or permanent octa-damage, because they will (tell me something about human nature and the people on the interweb).

The solution can't come in the form of "cheat protection", this simply isn't possible with the current cube, and even if the entire gameplay code was moved serverside, is still fragile. Don't even suggest it... make sure you understand the nature of the client/server gameplay code before commenting.

The solution for Cube I feel has to be a social one. As you may remember, I designed a solution before:
http://wouter.fov120.com/rants/trusted_communities.html
The problem with this particular design is that it is too complex to set up, and too centralized. I would like to come up with a solution that is simpler, less implementation work, and can work with any group of people, centralized or not.

This is the idea I came up with sofar:

Every player that wants to play in a cheat free environment, can use a command in Cube to generate a set of key files. A key file is simply a file of, say, 10000 random bytes. The player then hands out these files to players he trusts... or rather, players he wants to trust him. (why there are multiple files will become clear later).

A server can either be in untrusted mode (default, works as before), or trusted mode. It can be set to trusted mode by the server admin, or voted by the players until the server empties. It will show up in the server browser as trusted.

If a player A & B connect to a trusted server, A looks up B's nickname in his folder of key files. If he finds a corresponding key file, he chooses a few random file offsets and reads the bytes there. It now sends a packet to B asking it for the bytes at those offsets. If B really is B, it can simply read its own keyfile and return the values. A now compares the values, and if they match, it sends a "I trust B" packet to the server. The hud shows which clients you trust, and for each client how many clients trust him in total. You are now sure that B really is who he says he is.

On a trusted server, people that after exchange of trust packets have gained no trust, can be booted from the server automatically. This allows you to play games with trusted people in your community, and have external people unable to be join the game.

asking for random offsets guarantees that untrustworthy clients or even servers never get to sniff keys. "Trust" is evaluated locally and for you only, so can't be spoofed.

The one problem would be handing your key file to someone who later turns out to be untrustworthy. This person could now impersonate you and appear to be you to all your trusted friends. Hence the multiple key files, so you can give a different key file to different people (or groups of people). That way, if the person "goes bad", he can't impersonate you towards your friends, as he doesn't have the keyfile your friends have.

The system is not perfect of course. You can still have 2 cheaters join together and trust eachother. Luckily cheaters hardly ever come in groups, and there are more complicated ways to protect even against this.

The biggest issue is the inconvenience of having to exchange key files, and especially to require new players to find existing players on forums/irc before they can sensibly play. I think it is bearable though, as you only need to do it once, and Cube multiplayer is a fairly closed community. And if servers are by default untrusted, you can give newcomers the benefit of the doubt until they behave suspicious.

What do you all think? Please think it through thoroughly before commenting (I am talking to you, Jean Pierre! :). I am especially interested in "holes" in this system, i.e. ways that cheaters could abuse it if they really wanted to.

   Board Index   

#71: ..

by Tom Finnigan on 06/03/2005 10:41

I think that the key-trading is still the best idea, long-term. When a technological solution isn't viable, I think a social one is.

The one thing I'd change is how the keys are generated and checked. Public key encryption and strong hashing are available in a few easy to use and cross-platform libraries, cryptopp being one that I've had experience with. Send public keys to a server for a given identity, and then use your private key to authenticate (perhaps a dedicated key server would be useful).

Also, it might be better to assume that everyone is trusted until found otherwise, and limit the number of keys a given ip address can generate after being marked untrusted, to 1 a day or something.

reply to this message

#72: Re: Cheating & open source, revisited

by K. Jeras on 06/03/2005 14:09, refers to #63

The suggestions here do not actually address the issue of cheat prevention in the open-source game. They attempt to test that people are all running the same code, and that is inherently flawed in the context of open-source software.

People will be modifying the code in hundreds of different ways that have nothing to do with cheating, some to suit their local machinery, some to overcome physical handicaps by creating interfaces that they can handle, and some just to suit their individual preferences. That's what open source is all about.

Instead of focussing on the strongly anti-FOSS concept of everyone running the same code, cheat prevention needs to address only real game-related cheating, not local code modification. That means keeping certain types of data server-side and periodically checking that client state is consistent with server state. A client modified by a cheater (say for God mode) doesn't get him very far when the server KNOWS that he's dead, and the same applies for all the other player attributes that matter in a game.

Treat *everything* client-side as modifiable and under player control, and everything server-side as under game management control. It's the only approach that has any real chance of success in an open-source world.

reply to this message

#73: Re: Cheating & open source, revisited

by yanqui on 06/03/2005 22:54, refers to #72

The only reason I'm not agreeing with the trusted community thing (which I think would otherwise be a good idea) is that I feel it's elitist and therefore hurts the community. I think that people with trust keys will only play with other people with trust keys and no one with trust will play on the open servers. I wasn't invited to Cube, I found it while looking for games for my step-son. Both of us would be excluded and I don't think that's good for the community.
I think both K Ieras and sparr might be on to something by having the server-side check the client. If there was a monitor running that checked dammage done to the shot player (as calculated by the shooting client and then as calculated by the shot client) every time someone fired a shot, matched the two up against eachother and against the max possible dammage, then kicked people who did more dammage than was physically possible and people who didn't die when both the server and the client figured they should, that might be a good start. Server side verification of client side math would probabbly go a long way to help.

I still think checksumming would help a bit in making sure everyone is on the same page. It would get rid of unintentional cheeting, and we wouldn't have to spend half a game yelling at people to type /getmap. Also it's eaiser to hack a map than to modify source, so the idiots would be out of luck.
Overall I think some form of server-side verification the best so far.

reply to this message

#74: Re: Cheating & open source, revisited

by Pxtl on 06/03/2005 23:31, refers to #73

Having the server track the client is still a loser's game. It means a massive amount of code, often leading to a thin-client. This would lose Cube's simplicity, and would also lose the advantage that Cube has that it is super-low-bandwidth. Sauer would no longer be modem-friendly.

Also, I would keep from users being single-key. Remember that one could run "keyless" server for new users. While these servers might be plagued with cheaters, a few moderators could just keep an eye open to draft the good ones.

reply to this message

#75: Re: Cheating & open source, revisited

by Zer0 on 06/04/2005 00:09, refers to #72

Aimbot is also cheat, but it`s much harder to detect it by server.

reply to this message

#76:


Re: Cheating & open source, revisited

by K. Jeras on 06/04/2005 03:46

Cube gains hugely from its simplicity (sauer even more so, probably), and I agree that adding huge complexity would almost certainly end up being a bad thing. In which case, it may be best to just forget the whole issue of coded cheat prevention and learn to play only with friends and well behaved acquaintances.

It's not hard, you realize soon enough who the cheats are. And that approach is infinitely better than discriminating against those who quite legitimately modify a client that is released as open source but do no cheating whatsoever.

reply to this message

#77: f

by Gilt on 06/04/2005 03:49

..

reply to this message

#78: Re: f

by Gilt on 06/04/2005 03:52, refers to #77

accident... sigh

reply to this message

#79: ..

by yanqui on 06/04/2005 04:23

hum.... each client keeps a game log of sorts, right? That log could be expanded, then if someone is accused of cheeting the logs could be uploaded to the server. If one log disagrees significantly with the rest the person could be banned...

reply to this message

#80: server tracking

by Sparr on 06/04/2005 17:08

the server can track the player's behavior without using additional bandwidth. it doesnt have to tell the client where the client should be every second, it simply waits for the client to send an update then checks that against the internal state. if the client is trying to do something wrong, THEN the server corrects it, but as long as the clients behave then the server never has to send any additional data.

of course, the processing power required for the server will increase quite a bit, but i think that is an acceptable change.

reply to this message

#81: ..

by CC machine on 06/04/2005 19:31

idea:

move all the code server-side, so that the only thing that the client does tell the server which key(s) they are pressing. that way there would be no physical cheating becuase the server handles all the physical stuff

reply to this message

#82: typo

by CC machine on 06/04/2005 19:32

*does is tell the server
*(s) they are/is pressing

sorry for the double post

reply to this message

#83: ..

by >driAn<. on 06/04/2005 19:40

What about a server side rendering? So the client receives bitmaps from the server and the only thing he does himself is sending key/mouse input.
:P

CC_machine: This is (practical) not possible.

reply to this message

#84: ..

by CC machine on 06/04/2005 22:08

server side rendering?? that would only work on super high bandwidths and lots of poeple dont have that :(

reply to this message

#85: Re: ..

by >driAn<. on 06/04/2005 22:13, refers to #84

CC: that was a joke, its impossible, same as your idea.

reply to this message

#86: Re: server tracking

by Pxtl on 06/05/2005 00:31, refers to #80

Not that simple. Very often, in normal Cube, you can kill a player in such a way that, because of the ping differences, the other player never had line-of-sight with you (although you had line-of-sight with him).

Eg. you and player have a wall between you so you can't see each other. He jumps, and by coincidence you jump a quarter second later. Assume quarter second ping. From his perspective, you jumped a half second after him, and he never saw you. From your perspective, you jumped at the same time, and you shot him in the face.

Now, the problem - the server saw things 1/8th of a second, because the server has half-ping lag. So to the server, you never saw each other. So how does the server know you didn't wallhack the collision detection and cheat? I guess the client could send "I shot player X from position Y at position Z" - which is a heftier message than "I shot X"... the server could confirm "Yes, indeed, guy 1 was at X and guy 2 was at Z recently, so that shot is possible" - but that would involve some nasty searching through recent history.

And it still doesn't stop aimbots. All it prevents is impossible cheat shots. I think the main thing that the server can do is track health/status (preventing invulnerability) and track movement to avoid teleportation or flight tricks. Invulnerability is arguably the scariest cheat besides aimbots (which are pretty much impossible to prevent), because it's very difficult to detect - and that can easily be handled by moving damage-counting server-side, which wouldn't make for more messaging either way.

The hard part will be preventing using the power of Cube's client-side damage handling, which basically lets the player say "do X damage to Y" without even shooting.

reply to this message

#87: Re: ..

by CC_machine on 06/05/2005 10:56, refers to #85

oh ok i thought you were being serious

though server side rendering would solve the problem though, if you could squash the images so that they would fit down low bandwidths

reply to this message

#88: ..

by >driAn<. on 06/05/2005 11:45

CC_machine:
xD forget it, thats not even possible in a LAN.

reply to this message

#89: Re: Lightweight server-side cheat detection

by Pxtl on 06/05/2005 19:31, refers to #89

I would avoid having the server invalidate race-condition-based kills. By the logic of Cube's networking, that was a fair and successful shot. I would suggest a validation where you simply check that yes, at a point in recent history the shooter was where the shot came from, the shootee was where the shot hit, and the shot does not pass through any walls. It would have to be a full search through about a ping of history for shooter and shootee. This would accomodate the very loose timing used in Cube. If these 3 conditions are true, it's a fair shot. Whether these events happened at the same time would be ignored. It would be looser than a real check, but would never invalidate successful shots from the client without cheating. However, it would also be more computationally expensive - you'd have to search through the two players' recent-movement buffers to check for their existence at the origin and target positions of the shot. Also, you'd have to add the additional information of "where the target was when I hit him" to the netcode sent by the shooting player. In the end, it would still make it very risky to cheat-kill a man through walls (youd have to see him very recently, or he'd have to see you). Not a perfect protection, but something.

Of course, that fix only stops the shoot-through-walls problems. There are still other concerns - timing cheats (screwing with running speed, rate-of-fire), movement cheats (flight/teleportation), inventory cheats, and health cheats. The last two are easy, but the first two are tricky to fix.

reply to this message

#90: ..

by >driAn<. on 06/05/2005 20:22

I have a question, did you guys ever read the cube netcode? It seems to me you didn't or you didn't read it carefully enough.
Its imho not worth to implement any of those 'cheat-protection' checks, because there are 1000 other ways to confuse the game.

reply to this message

   Board Index