Cheating & open source, revisited

by Aardappel_ on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 172268 views, last view: 04/29/2024 18:19

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   

#159: Facilitatating cheating

by shadow516 on 06/26/2005 00:57

In my opinion, one of the best ways of combating cheating is to facilitate it. Make "sandbox" servers where cheating is acceptable, "regular" servers where there are bare-bones cheating measures, and "official" or "tournament" servers where there is serious cheating prevention. That way, people who just get bored with the game can go to the sandbox servers and just goof of, or maybe experiment with a new idea, and not interfere with serious games.

reply to this message

#160: Re: Facilitatating cheating

by CrazyTB on 06/26/2005 05:28, refers to #159

Interesting idea... Not sure if will work.

Of course, we will need some type of cheat-checking at servers/clients, or some type of "kicking", when some cheater tries to mess with "pure servers".

Care must be taken to not leave any little hole to allow cheaters cheat with kicking system. :)

reply to this message

#161: Quick synthesis and centering back to main topic

by D.plomat on 06/27/2005 00:40

The legitimity of using home-compiled bins on official servers is another topic (IMHO this should be allowed if this doesn't conflict with some contraints (ie the actual anti-cheat protection) but i don't consider this a very important thing as Cube is still 100% open-source). Some agree, some disagree but that's not the point.

Cube uses modified bins as anti-cheat protection. This protection isn't effective for a game that reaches some audience. This also applies to many commercial games, be them closed source or not (well, actually they're all, and that doesn't seem to make them cheat-proof). But that still isn't the point.

Some technical solutions have been studied, mainly:
-checksumming binaries, any tech that have some basic IS security notions will tell this is trivial to fool on a non-trusted client. (the PC of some random unknown user who downloads Cube obviously is a non-trusted environment)
-heuristics analysis of the game actions , as many have said => leads to endless and already lost arms race between developpers and cheaters, with added side-effects:
-making FOSS developpers waste precious time (a developper (with already a huge TODO-list) will use 3-4 hours for coding some protection algorythm and some folk who has nothing more useful to do will always find some other way to cheat in a couple of minutes)
-bloating the code

Aard already thought about all those alternatives, already knows why they won't work and proposes a new system that seems very promising, and is also very friendly for open-source gaming, both by not necessiting closed souce bins and the efficiency/developper workload ratio so i think we should really concentrate on two things:
1. Implementation and design choices for this system
2. As any security system, begin to harden it already by trying to find potential holes in and closing them even before it gets exposed to the wild


@shadow: the "sandbox servers" are the public untrusted servers in the system Aard describes. Regular are trusted with a minimum trust value required, official and tournament have higher required trust-value.

reply to this message

#162: aw geez

by pushplay on 06/27/2005 09:04

"Why not allow people to set up servers that can only use official bins"

Why does this keep comming back?

reply to this message

#163: official bins..

by Aardappel_ on 06/28/2005 04:44

don't really stop anyone from cheating, as we have seen with cube. It is good as a stopgap measure, but certainly can't be a longtime solution for sauerbraten.

reply to this message

#164: player identification

by hungerburg on 07/06/2005 12:44

slashdot today is carrying a story about "OpenID", the "blogosphere"s distributed commentors identification system. Basically: if a nick contains an @ sign, its an openID, and can be checked - by the cube server and/or client - against the IDserver (part after the @). players have to logon to the IDserver before playing (maybe inside client). its in itself not secure enough for banking, but might work well with commenting and gaming too.

CONS:
- lag when player joins (query the IDserver first)
- servers and clients have to keep lists of black sheep (players, IDservers) (or better whitelists?)
- dependancy on xml/rpc library, if the livejournal system was used
- newcomers still arent trusted, ie. they are "unidentified"

PROS:
- makes it easy on newcomers that already comment on blogs ;)
- makes ID expensive (have to sign up for a new account on a *trusted* IDserver, once caught cheating and blacklisted or taken from the whitelist)
- nick is used for identification, so nicks (the full ones) become "properties" like email addresses - but the first part (prominently displayed) is free as anybody can run her own IDserver

reply to this message

#165: Re: player identification

by Aardappel_ on 07/06/2005 20:54, refers to #164

the pro's/con's tradeoff for this isn't really working for cube. The amount of infrastructure needed to interface with this, + the amount of cube specific stuff on top of it would be huge. And then it doesn't really solve our problems all that well as identities for cheating are still a bit too easy.

If you'd go this "establish identity on the web" route, it'd be much easier to just tack on a more serious user registration to this forum, including people's homepages and other info, and more of a tie in with the masterserver where we can see games played, on what servers etc. Then add a system where I can extend my trust to users I know, and a way for servers to only allow users with a certain trust level.

I don't like this because it requires too much administration, which is exactly what my original ideas were attempting to solve.

reply to this message

#166: Big player models? Change mapmodels?

by CrazyTB on 07/11/2005 04:36

If someone can change the default "ogro" playermodel to some other bigger model, then this player will be able to shot the others easier.

The same thing may happen if someone deletes all mapmodels, or change to something smaller.

In addition (this was already discussed before) the player may have a different map, and will be able to "hide in walls" (from the point of view of non-cheating players).

reply to this message

#167: ...

by ooo on 07/11/2005 06:07

actaully the big player models does not work, it would resize the player so it really doesnt matter if he changes it to the pig or the knight.

as for having a different map, that may be a problem, because it takes no skill what so ever to edit the map so you have an advantage around the corners and such

reply to this message

#168: Re: ...

by D.plomat on 07/11/2005 17:44, refers to #168

Maybe that would use much CPU on the server. I think it wouldn't be too much for Cube, for sauer i don't know.

And maybe that could make the game even more bandwidth-friendly than it already is :)

reply to this message

#169: Re: ...

by CrazyTB on 07/12/2005 03:57, refers to #168

Send/receive only visible players won't work, because someone's bullet/rocket even if the player is not visible to me.

The problem with modified maps is that cheater will "enter" in walls. The non-cheaters won't see him, but the cheater will be able to shoot. The non-players will think the wall is alive and can shoot...

I think all clients must do collision detection for all players. This may avoid some of the cheats.

reply to this message

#170: Re: ...

by hungerburg on 07/12/2005 13:04, refers to #170

that also would require the server to have a copy of the map ;)

reply to this message

#171: Re: ...

by Wolf on 07/12/2005 18:35, refers to #171

How would a client know if it can see other clients w/o getting their positional data?

reply to this message

#172: heh

by asdt54n on 07/13/2005 10:05

someone will find a way to exploit all the flaws in this idea

plus i predict an invisibility hack is on its way

reply to this message

#173: Re: ...

by D.plomat on 07/13/2005 15:00, refers to #172

I don't think that can work, if you refresh the visibility on each movement, then you need to send positionnal data... on each movement.

BTW each time you refresh the visibility you [need to] give your position to other players so if the refresh would be either:
-too few often => players appearing in the middle of a room
-too frequent => with a simple interpolation an approximation of the other player movement can be computed, and will be smoother and more predictive => easier to shoot at.

IMO there's no way to implement a useful version of this client-side only.

Plus this is only a protection for *one specific cheat* only.

If we want protection against all potential cheats, the only option is to protect against those who would use cheats => social solution is the only option

reply to this message

#175: lets do this simpler, then...

by Aardappel_ on 11/29/2005 04:23

ok,

So highest on my priority list for sauer right now is to get multiplayer (and singleplayer) for the FPS game to at least the state of cube or better, so we can move on to working on the RPG. For that to happen, one big thing still stands in the way: making multiplayer bearable in the context of cheating.

so my "trusted communities" idea is cool, but it requires way too much organization and infrastructure. Same with any similar ideas based on public/private keys etc.

I am also not going to rewrite all gameplay to be purely server side (which would not stop cheating btw, it just would reduce it a bit).

I also don't want to get into the whole "official binaries with different protocols" mess that we had with cube, which doesn't stop cheating either.

Which doesn't leave many options. One option I have contemplated, since the Cube/Sauer community is rather small, to simply have no cheat protection.

Yup, you heard that right, just allow people to compile their own binaries, change whatever they want, and joining a multiplayer game.

I will just accept the fact that there will be cheaters. But what I want to do is make it easier for the non-cheater to play with friends, undisturbed by cheaters.

An option sofar would be to use maxclients or passwords to block the server. But that is kinda inflexible, requires organization again, and doesn't allow you to play with strangers that happen to be non-cheaters.

So my idea is to allow you to run servers besides in "open" (anyone can join) and "password" mode, a third mode which for now I will call "master" mode (which will be the default).

In master mode, the first person that joined will be the "master" (and when he leaves, if someone remains, the second etc.). If a person wants to join the server, a message will popup on the master's screen, and he has to press a key to let this person in. The master can also kick anyone on the server.

What this will do, is make it real easy to have a game amongst friends, you will simply only let your friends in, and you can have a closed game easily, without passwords or maxclients (so you can use any server).

If you want to have a general game, you can let everyone in... and if they turn out bad, you can kick them, and not let them in again (remember, refusing people requires no further action).

Having a single person as master is also better because voting for kicking people often takes long, or votes just don't get through. Voting for letting someone in would certainly take too long.

If a cheater is the master, well, then you can just leave and let him play alone.

If someone is the master that doesn't see the cheating (or doesn't understand the system) but you do, well, this can happen, you can either try to educate them, or invite the remaining players to a different server.

The system doesn't stop cheaters impersonating people you trust, but this doesn't seem to be a frequent problem.

The system is not ideal (like no choice is), but I think it will allow people to play cheat free games together relatively easily, without too much complicated infrastructure involved.

What do you all think?

reply to this message

#176: Re: lets do this simpler, then...

by mykilx on 11/29/2005 04:38, refers to #175

Sounds like a great idea. Looking forward to it.

reply to this message

#177: Re: lets do this simpler, then...

by Aardappel_ on 11/29/2005 05:18, refers to #175

I'll also add a "mastermode" command for the master to use. He can use it to force map changes, or disable the master mode until the server clears again, etc.

reply to this message

#178: ok, so....

by Aardappel_ on 11/29/2005 06:20

suggested modes the master can set (going from public to private):

0 (default): anyone can enter, but I can still kick. Good for fun games when no cheaters appear to be around.

1: like 0, but my map votes are vetos now. Good for playing with people that don't know how to vote.

2: like 1, except only people I allow can play, others become spectators (yes, a spectator mode will be added!). Spectators can not join the game. This mode is good for tournament matches

3: like 2, except people that I don't allow will not be allowed in the server at all. This mode is good for private games on any server.

Kicks ban an ip address for several hours, to not allow easy name change and reconnect.

Spectator mode in 0/1 will allow people to switch between spectating and not.

reply to this message

#179: I like it overall

by metlslime on 11/29/2005 08:06

The only big hole I see in this is denial of service attacks -- scan the master server, find out all empty servers, join each one, set mode 3, and idle.

This is not a likely event, but all it takes is one person to do it and then "master" mode is useless (at least until the next patch.)

reply to this message

   Board Index