Cheating & open source, revisited

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

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   

#134: ..

by makkE on 06/19/2005 13:21

Yes! Thank you very much, Jean Pierre !!:D
We don´t like it either...

reply to this message

#135: Re: ..

by jean pierre on 06/19/2005 13:36, refers to #134

Bah end this we're getting off-topic!

reply to this message

#136: Re: Alternatives

by hungerburg on 06/19/2005 13:42, refers to #130

again, public key cryptography would make grounds for buddy lists without central registration - remember (ok, chances are) no two public keys are the same, only one person has the corresponding (possibly even pass phrase protected) private key.

thats like real life: my friends dont register with the government, they register with me ;)

still no idea though, how a client may "ping" all the peers in a game (necessary to check if yesterdays Alice is the same as todays). let alone how to trust unknowns (maybe just reborn cheaters/nuisances).

distraction: to raise the price for a new identity, accept only keys that ares signed by a central authority (aka government) (could be machine with 1h delayed email). (this might also eliminate the need to ping peers, if server can be trusted.)

-- I dont know myself for such bureaucatic suggestions...

reply to this message

#137: Re: Alternatives

by Gilt on 06/19/2005 15:53, refers to #130

hmm... ok, then let's talk about this "round" based system.

I don't think it needs to be a part of the game... instead we can build off ignoring to do basically the same thing, since it is much more flexible. Clients can ignore new players for a set amount of time after they connect to the server, like the round system. Or maybe they can accept new connections right away, but enter into a "lock down" mode after a player has been ignored and leaves the server, where they won't accept new clients for a period of time afterwards. Or some other scheme that can be developed individually.

reply to this message

#138: Re: General long-term strategy

by kernowyon on 06/19/2005 17:19, refers to #131

As you may or may not have noticed - I never curse or swear at others - either in the game or on the forum :) I dislike the way some people use foul and abusive language in game - I personally would love to see some form of kick method for those who insist on swearing constantly in the game.
I was simply curious. Just didn't think I had ever seen you in game, unless you had another nick.
No probs :)

reply to this message

#139: Re: General long-term strategy

by jean pierre on 06/19/2005 17:50, refers to #138

I had lots of nicks in this forum and all becouse of the internet forgets my cookies.
Now i no longer play in Cube and im proud of it

reply to this message

#140: Re: ..

by Gilt on 06/19/2005 18:34, refers to #139

I think at this point it's pretty clear that what you want is not an engine that can plug-in games, but a library that can be pluged into games.

reply to this message

#141: Re: ..

by enigma_0Z on 06/19/2005 21:00, refers to #139

That's a good idea, actually...

Then whoever makes the game module could keep the netcode closed so no one cheats... (Unless they want to take the time to dissasemble it and yada yada yada, but that hasn't happened with cube yet.).

The thing about closed netcodes is:

1) most people who don't want to cheat won't dissasemble the binaries.

2) Most people who want to cheat are n00bs who don't have the skill or desire to work at hacking the packets or the binary to cheat.

3) Most people who have those skills have better things to do with their time.

pfft. I'd rather a closed netcode like cube's current implementation than open everything. Of course it's up to aard, however.

reply to this message

#142: ..

by quirk on 06/21/2005 18:53

The ignore idea has many merits which other have pointed out but I do see some major flaws inherent in the idea.

It disrupts the game somewhat if some people can't see other people who others can.

What if person A is fed up getting trashed by person B and ignores him/her. Person A then starts attacking person C who appears to be jumping randomly and shooting at no-one. Person A then takes out person C because he isn't getting shot at or distracted by person B, making person C a resonably easy shot.

While a good idea and could be implemented well in other types of game, I don't think it will work here :(.

reply to this message

#143: Re: ..

by kernowyon on 06/21/2005 20:37, refers to #143

But surely, like so many ideas, this would have an effect on the better players in the game?
Person A is thrashed by player B - purely because A is new to the game and B is a long time player, who has practiced a lot.
So A ignores B - maybe because A thinks B is cheating because they always seem to kill them.
So B finds himself with a slowly decreasing number of people prepared to play him/her.
Unless B only plays on the ESL or whatever, this would happen very quickly.
Most means of banning or ignoring specific players - unless there is proof of genuine cheating ( rather than sheer skill or lag issues) - will end up with alienated players.

reply to this message

#144: ..

by quirk on 06/21/2005 21:10

The point is that it could be abused so easily. If I ignore the stronger players I can prey on the weak ones without getting shot at.

reply to this message

#145: ..

by deathrabbit on 06/21/2005 21:34

Although many good ideas are coming out of this, I think we are missing trying to prevent one of the worst (in my opinion) types of cheats, editing in non coopedit games. I think that, even though we don\'t like it, we can put up with someone who doesn\'t die, but it truly pisses me off when someone walls me in. This could be fixed fairly easily though. Whenever an editing command is used, the server could check what the game mode is, and if it is not coopedit, the person could be kicked. This would get rid of edit cheaters and force someone to reconnect if a bug lets them use editmode when thay shouldn\'t be able to. Unfortunatly this would put a little more strain on the servers, I dought the change would hardly be noticable.

reply to this message

#146: Re: ..

by pushplay on 06/22/2005 07:08, refers to #146

It's fairly straightforward to throw away edit messages from the server when in the wrong mode.

reply to this message

#147: Plugin Prevention

by tentus on 06/22/2005 21:19

ok, we've all heard Morgaine push for plugins, right? so, if each gametype was in it's own little plugin, it would be simple for each server to make a small custom gametype. toss in three or four other little plugins, which would apply for slightly tweaked physics, perhaps a spam/swearing filter, etc, all tweaked by the tiniest margin, and small enough to download in a minute or two on dialup, and all of a sudden a cheater has five times the work. someone who made edits to unrelated plugins would be in the clear, and the servers could even choose to follow Aard's Cube model, by making their plugins closed source.

by breaking everything into plugins you make the cheater's job harder, the server's flexibility greater, and the number of addition ways to safegaurd against cheating greater. anyone want to extrapolate on this idea?

reply to this message

#148: ..

by post on 06/23/2005 02:59

These are the cheats I've seen so far:

||Editing in a Non-edit Mode||
-This cheat allows the player to easily fly through walls and objects and edit the map by changing heights and even adding objects to a map.
(quit possibly the most interesting because all players are instantly affected during gameplay :: the only solution so far is to reload the original map which might reset your current score)

||Infinite Health||
-This cheat allows the player to never be killed.
(this is extremely annoying to other players, but can be easily recognizable that there is a cheater playing)

||Infinite Ammo||
-This cheat allows for infinite use of any weapon in any game type, even if the weapon is not allowed.
(the advantage comes when the cheater is the only one with a machine gun while everyone else carries a rifle)

||Change Score|| [frags]
-This basically changes score to any number including negatives so player can be in first place all the time or even last.
(Fortunately the cheater cannot edit other players scores)

The problem with all of these cheats is that none of them are caused by bugs in the game, which most of you have been wrongly assuming. All these cheats can easily be made through binary without ever editing a packet.

Goodluck if someone tries creating a way to stop cheaters.

reply to this message

#149: Ignore's ^

by jean pierre on 06/23/2005 13:51, refers to #148

Whatever......

Yeah right i did heard strange sounds in instagib like rocket launcher shotted only once in the game but that must be becouse the games loads a different sounds thats it.

reply to this message

#150: Re: Ignore's ^

by D.plomat on 06/24/2005 19:19, refers to #149

Maybe, but when you figure this player has a way higher score it gets much more suspicious...

The sounds are client-side, if the game on your PC plays the correct sound for you and other players weapons, then there's nothing that could explain one player makes a different sound unless he really *is* firing a different weapon.

reply to this message

#151: Re: ..

by CrazyTB on 06/25/2005 06:48, refers to #148

I think I know how to reproduce "edit cheat". (or, at least, one of its variations)

Go to some coopedit mode in some server. Then, go to another server running a map you don't have, and a non-coopedit game (maybe you can trigger this "cheat/bug" using the same server). Since you don't have the map, your current map won't be reloaded, and you will still be in edit mode.

How to fix this easily client-side:
- Forbid any edit command when (multiplayer && !coopedit).
- If current game is not coopedit and we receive edit commands from server, ignore them.

reply to this message

#152: Re: ..

by yes on 06/25/2005 07:22, refers to #151

yea, i think the server should have more control

people are able to edit their own map, and then the server reads it and sends it to all the other players, i think the coopedit feature is cool but i dont think many people use it seriously as in making a real playable map. this should be a private feature.

the problem is people are able to send maps and get maps freely, there should be some type of restriction

reply to this message

#153: ..

by yanqui on 06/25/2005 12:21

lets remember that a lot of the cheats we're talking about are modded bins, so trust can be more or less assumed on official bins.
Why not allow people to set up servers that can only use official bins if they want a trusted client-pool? On trusted games ignore/kick/whatever would become unnecessary, on untrusted servers the ignore/kick/whatever solution could be implimented.

Under this plan a good person can prove (s)he isn't cheeting by playing on a trusted client. Also people can know more or less for sure that the other people aren't cheeting too. All the security of closed source...
But on the other side it's still possible to modify the code and use modded clients on servers that don't require official bins.
People who want freedom have it, and they deal with the trade off of less security; people who want security have it, and deal with the trade off of less freedom. Everyone can get what they want without significantly impacting the playability of the game.

reply to this message

   Board Index