home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


Cheating & open source, revisited

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

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.

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages

#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

#180: Re: I like it overall

by RealNitro on 11/29/2005 10:13, refers to #179

I was thinking exactly the same as metlslime. And what happens when a cheater (or an other @sshole) becomes master?

reply to this message

#181: Re: I like it overall

by Aardappel_ on 11/29/2005 10:36, refers to #179

it doesn't protect against every possible attack.. nothing does.

reply to this message

#182: Re: I like it overall

by macdonag_work on 11/29/2005 11:10, refers to #181

Nice and not too much hassle. Here's a suggestion (stop me if you've heard this one before)...

Similar to the password idea, but have the server be able to connect to a mail server. If a user wants to join, needs to enter a valid address. A short unique password is sent to the users email. That is used to enter the game. If the user gets kicked, that email adress is banned (for 24 hours?).

Any server using this would need to set up mail server details of course.

Had thought of making ban lists public, and having other servers copy this list, but if some malicious server started adding innocent's details to ban lists it would fall apart...

reply to this message

#183: Re: I like it overall

by Aardappel_ on 11/29/2005 20:21, refers to #182

that is too much hassle to make work, and new hotmail addresses are created in seconds.

reply to this message

#184: so...

by Aardappel_ on 11/30/2005 10:39

mastermode has been implemented. A few things still remain (better messages, and the spectator mode), but other than that, the system as described above is working (and even simplified!).

The code is in CVS, and the description of how to use it is in the section "Cheating & Multiplayer" in game.html.

I also fixed the "being semi-connected" multiplayer bugs. So now we just need a masterserver and sauer multiplayer can start! :)

We'll test more in the next few days.

reply to this message

#185: ..

by enigma_0Z on 12/02/2005 14:24

@aard > it doesn't protect against every kind of attack, nothing does.

The only problem (regarding the denial-of-service possibility) that I see is that it may end up (over time) that you have all the servers stuck in mode 3 (alot like the ones stuck in coopedit, or the double ogro problem). Perhaps we can have mastermode time out if the person is alone for so long? (on the order of hours)?

reply to this message

#186: ..

by enigma_0Z on 12/02/2005 14:26

Another idea...

If the person is uneducated (or just doesn't want the responsibility), could we make a command for that person to hand off master status to another player?

reply to this message

#187: Re: ..

by Aardappel_ on 12/03/2005 01:56, refers to #185

mastermode gets reset to 0 whenever the current master leaves the server.

To pass on master to someone else, just reconnect.

reply to this message

#188: Re: ..

by metlslime on 12/03/2005 04:18, refers to #187

"In master mode, the first person that joined will be the 'master' (and when he leaves, if someone remains, the second etc.)."

So you can only pass master on to the second guy on the list, not necessarily the person of your choosing. Though, I guess you could kick everyone else first.

reply to this message

#189: Re: ..

by Aardappel_ on 12/04/2005 05:31, refers to #188

maybe I'll add such a command if it really looks like a frequent occurrance. For the moment, it should be enough to get going.

We should have a masterserver soon, hopefully.

reply to this message

#190: Re: ..

by sinsky on 12/06/2005 13:23, refers to #189

I don't know how realistic what I suggest is since I haven't gotten my hands on Sauer yet and am currently an outsider here.. anyway here it is - also adding some control to the person whose computer the server is running on. Also displaying contact info like mail address, ICQ # or other means to get in touch with that person (by setting a MOTD for example).

reply to this message

#191: ...

by mardicas on 12/06/2005 23:38

I think the master idea is good. But, i agree with sinsky, the server owner should have full control and be able to set the master. And

reply to this message

#192: ..

by mardicas on 12/06/2005 23:39

... most people dont recognize cheaters and what if the qurrent master is a bad player and kicks the player who are better than he is saying that he was a cheater :P

reply to this message

#193: I think...

by Aardappel_ on 12/07/2005 10:13

you're all misunderstanding master mode. It is not some kind of status. It is just the easiest way to play with just your friends on the fly, on any servers.

So if there are people on a server that for any reason you don't like, don't play with them. Go to another server.

The person who runs the server should not have any special priviledges... master mode is about organizing a game, not the server.

reply to this message

#194: Hey guys

by Maikik on 12/10/2005 20:32

I have an idea... kinda.
Why not do a 'check' before connecting to a server - the client gets a generated code - example the client has a hacked version he gets a code 950522
The server has the real version - he gets a code 950596
If the codes match ,you can connect.
This still has a hole in it ,you see...

reply to this message

#195: Re: Hey guys

by CrazyTB on 12/31/2005 22:41, refers to #194

Very easy to workaround, very easy to cheaters send correct code and still be cheaters.

reply to this message

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages


Unvalidated accounts can only reply to the 'Permanent Threads' section!


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
58263515 visitors requested 76215184 pages
page created in 0.036 seconds using 10 queries
hosted by Boost Digital