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, 171050 views, last view: 03/28/2024 14:27

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    Go to next 20 messagesGo to last 20 messages

#1: addendum

by Aardappel_ on 04/27/2005 08:07

This system can even be made easier by allowing you to send trust keys to other players on the server using a command... but only if you trust the server and everyone on it (because it is susceptible to sniffing). Maybe it can be made more secure by opening a direct client to client (p2p, hah) connection for this, or using some kind of public/private key encryption system, but it has got to be simple.

reply to this message

#2: Hmmm, sounds plausible. Own idea:

by Axel on 04/27/2005 11:28

Hello Aard,

first off I'm really, really glad to see still you actively developing Cube. Even radicaly improving it :)

At a second glance, I just play for fun with friends or on public servers. So if someone cheats me, I don't mind that much. He cheats himself as much as he cheats me :)

Ok, finally, as you requested a few thoughts about the cheat protection. You're just going a private/public key direction. That sounds reasonable and will work. But I personally have never received any e.g. pgp mail. My only explantion is, that ppl seem to shy away from the hassle.

My suggestion would be to create a similar solution, but to keep it as simle as possible.

#1: Create a random hex + crc number from: Player name/data, Cube.exe crc, MAC

#2: Store that on client and cube master server

#3: Check identity and Cube file authenticity by checking random parts of hex numbers on client and server (asks master server)

#4: 'secure' cube servers will only allow identified players in 'secured' games

This way you'd the same security, but you would enforce file validity and player identification master server sided.

No need for user to run around town with your keys.

Hope you like the small modifications,
Axel

*who now remembers when he first contacted aard because of DSMP enhancements*

reply to this message

#3: Hey Aard not for offense but ur not great.

by jean pierre on 04/27/2005 14:39

Aard i dont know how to Compile the game really and i wish to know and if i do the network would crash cause it has different code but yet i dont know how to compile :(

reply to this message

#4: ..

by Rick| on 04/27/2005 15:19

First off: I'm glad you consider making cube trully open source :)

Secondly: JP...please stay on topic, you're annoying enough :P

Now for the cheat stuff, as you said it might be a bit problematic for newbs...besides that I think there are enough people playing cube online which are not actively on the forums/IRC. This wouldn't be really a problem if there would be enough servers without this 'cheat protection'. So perhaps a server option to enable/disable trusted keys would be nice, so that server admins can make a few 'public' servers constantly available for the newer people.

Some other simple suggestions:
- kick vote option: so cheaters can be kicked for lets say 30 minutes from the server.
- IP black list: So servers can deny players with certain IP's/IP ranges. Perhaps a thread on the forums can be started to maintain a simple list of all 'wrong' people.

reply to this message

#5: Re: addendum

by >driAn<. on 04/27/2005 17:14, refers to #1

A 'real open' Cube would be great!

"[..] or using some kind of public/private key encryption system, but it has got to be simple."

Yes I think pub/priv key, kind of a pgp system, would be a lot better for the security.


reply to this message

#6: Im not telling you how to compile it.

by jean pierre on 04/27/2005 19:51

ON-TOPIC:
But what does the black list do....
It makes people more annoying and enter with another IP and they curse you back(and possibly more hateness!)

reply to this message

#7: ..

by Rick| on 04/27/2005 19:55

Than block a range and he won't come back ;-)
Besides not everyone is able to just change his IP.

reply to this message

#8: Re: addendum

by tentus on 04/28/2005 03:02, refers to #1

if you made an "untrust" command it may require a slight bit of menu editing- it'd be all to easy to untrust the wrong player with our current system, so a slight modification to add say a confirmation meu with extra data on it would be appropriate. on eht esame coin, you wouldn't want to make trusting too easy, otherwise people will just find a fellow cheater and go for it.

a possible solution to easy cheating would be to make a temporary version of the getmap function: to play on a server with this enabled, cube would _have_ load the level for only as long as they are playing, no prompt or anything. completely automatic, and if it doesn't follow thru then ban them. the problem would be people seeking out the code for this and deleting it, so there'd have to be a way for the server to check that it had actually happend (perhaps check in base that both the original and the temp maps were there?)

well, very promising ideas, i'm very interested in where this will go. good luck explaining all that to newbs though :)

reply to this message

#9: Response

by pushplay on 04/28/2005 03:22

Basically (my understanding of) Aard's scheme is summed up in three ideas:
- common servers which are just what we have now
- elite servers where I only play with people I trust
- a system for proving people are who they say they are

Personally I haven't found impersonation to be a big issue, and on the rare occasions someone wasn't who they claimed to be it was pretty obvious. Additionally, I rarely find myself playing with people I recognize any more but rather a quick game during lunch with randoms. So I would spend 90% of my time in the common servers.

I'd like to propose an alternate scheme. Mostly using a vote kick w/ timeban system using a plurality. One line of text at the top for the person, the current tally, and a kick reason. Also a second line for a response from the person being voted (which is likely to contain profnaity :). The other half would be authenticating with the server to become a trusted client immune from being kicked off, and perhaps even a higher level of trust for gaining referee status.

This would create defacto common servers where admins don't collect keys from those in the community.

Are there any other opensource games out there that have attempted to deal with this? What about that opensource fps that was kind of like tribes?

reply to this message

#10: Re: Response

by Pxtl on 04/28/2005 06:06, refers to #9

The tribes-like game was closed-source. Other FOSS games do have cheating problems (like QuakeWorld), but usually have a thin-client approach to logic so the worst cheating you get is aimbots, and aimbots happen on closed-source games too.

Cube has a thick client, so the client can cheat much more powerfully. In an opensource Cube, a cheater would be a god - he could kill players with a thought.

The approach that most places seem to use is to force the players to build up an identity. Aard's approach is interesting in that it is masterless, but more conventional approaches would be to follow what Slashdot and have a central login system. This could be expanded out to the rest of the Slash concepts of karma, moderators, meta-moderators, etc.

Players who care about play stats would be encouraged to take care of their accounts, because getting banned or redlighted would mean one might have to make a new account. Of course, this means that recording player stats on the master server would be needed (frags, games played, wins, etc). Most players would circumvent this by having a "good" account and several "bastard" accounts. The bastard accounts would get banned, but new ones would be created. This means that serious servers would have to either require old accounts only or minimum karma points or whatever, which means that new players are relegated to the ghetto of free (cheater) servers.

reply to this message

#11: Re: Response

by pushplay on 04/28/2005 07:57, refers to #10

Thinking about it I think there are only two possibilities:
players are assumed untrustworthy, create a long term profile and earn trust
players are assumed trustworthy, create a short term profile and lose trust

And we all agree that no code verification system can work since the hacked source could always run a hacked server with a clean client, observe the proper response and pass it along like a 'man in the middle attack.'

reply to this message

#12: ...

by Aardappel_ on 04/28/2005 08:19

axel: that system doesn't help anything. now the only thing you know is that someone with MAC address X is cheating. You could blacklist him I suppose, but since the client has full control, he can make up any fake address he wants.

jean pierre: yeah I am not great.

rick: the default for servers would be untrusted, so it doesn't affect pure newbs just wanting to try it out. It is more for regular players who just want to exclude unknown entities from their games.

kick/vote & blacklisting is not really a solution. With people being able to change nicks, ips, and reconnect real easily, this means its more work for those combatting cheating than the cheaters.

tentus: untrust is not as solid as trust, as you can't automatically prove it. Obligatory map download is not going to do anything, because if you control the client, you can stop the map from being stored/loaded after download.

pushplay: impersonation is not the problem. What the system does is allow you to automatically block people whose identity you can't verify, different thing.

Again, any kind of manual kicking requires a lot of work on the part of the normal players... not a good plan.

Other open source problems have less of an issue because they have serverside gameplay, and because multiplayer leagues tend to work with set binaries whose crc's are checked by closed source proxies or dlls (as for example in quakeworld).

pxtl: if we were to go with a web based system, then my previous design would work better than what you suggest. Cheaters don't care about their stats, and will easily make a new account.

I think a fundamental thing to see here is that it is easier to trust the good players, than to detect the cheaters.

In general, when thinking of solutions, think from the perspective of the cheater: what could he do to circumvent your idea if he wanted to? Lots of ideas people come up with really are really easy to circumvent, if you have full source code.

reply to this message

#13: solutions...

by ciscon_ on 04/28/2005 11:37

i think that the combination of an rcon, vote kicking/banning, and either aard's system or an account based system would do the trick.
personally i've found that having an active remote console on the server is usually good enough (which seems to be inevitable when you have a popular server that is capable of being remotely controlled as i've seen with qw and q2). if this isn't enough then you allow the players to votekick/ban (for a serverspecified amount of time). it really just comes down to letting somebody have some sort of control over the server.

reply to this message

#14: Re: ...

by Pxtl on 04/28/2005 11:45, refers to #12

Well, actually, the failure of my suggestion is the same as yours - new players are left in the ghetto of "unrecognised" - the ultimate problem is that new players must be sponsored into the game, either by gradual process of karma or by sudden induction through a user key recommendation. The end result is the same. The only reason that I suggest the central server approach is that we've all seen it in action - we've seen Slashdot (and the trolls, and the karma whores, etc) and have a vague idea how well/poorly it would work.

reply to this message

#15: Re: ...

by D.plomat on 04/28/2005 12:35, refers to #12

I think the problem of the "bastard accounts" Pxtl described can be avoided/at least very limited by having an initial "cost" per account. Of course not a monetary cost, but something like a registration procedure that takes about 15min and requires a valid e-mail.

A 15 minutes cost seems reasonable for a player that wants only one account. Of course creating fake yahoo/hotmail accounts is possible, but creating fake mail accounts, then creating fake Cube accounts will probably become unworthy if it takes more time creating the accounts than a cheater can use them to cheat.

There will probably be some lamers so inclined to take 5min hotmail+15min account creation for only 5 minutes of godmode playing but there won't be many, and they won't do this for a long time.

And if someone wants to cheat on a high trust server, he has to create an account, play honestly for a long time to earn enough karma, all that for an account he will probably cheat only once before it gets publicly known as untrustworthy.

Maybe this would require some kind of those "antibot" images to avoid robot creation of accounts.

By having a central trust database/server, this database is out of reach of cheaters, and the client-side code's duty is authenticating the good players against this server, the server have all public keys of all players, each player is the only one having his priv key on his machine(s).
The client sends his trust informations to the trust server, and the play servers only read trust information from the trust server.

Then to find some way of making this appear simple to the user while not adding too much into the client code. I think the setting trust commands will be really well used only if they're into the Cube client, but maybe some things can stay "manual operation", i suppose something like a one-time "drop a certificate file received as mail attachment into a subdirectory of Cube" is an acceptable complexity for even a total newbie (or maybe not?)

I've to make some tests coding with OpenSSL library :)

That's a very interesting project, i think i'll try to make some kind of prototype of this system.


Agree about the IP bans, this is more likely to block trustworthy players sharing the same ISP with a cheater than really keeping cheaters out.

reply to this message

#16: Re: ...

by D.plomat on 04/28/2005 12:43, refers to #14

I think the key feature in setting karma/trust is having people rate wisely so the whole trust score of a player gets an uniform value on all part of the community so the trust-level of a server can remain constant with a constant number.

So if we have multiple levels of trust we have to avoid ppl always setting 100% trust / 100% untrust, maybe by some menu labels like

I fully trust ...
I think ... is trustworthy
I don't know ...
I think ... might be cheating
I'm sure ... cheats

reply to this message

#17: Re: ...

by D.plomat on 04/28/2005 12:50, refers to #16

Reading again the Trusted communities page, this is already addressed by the "false accusation"/"bad trust" system

reply to this message

#18: Aard is right...........

by jean pierre on 04/28/2005 14:49

If we just make kick/ban then the guy could compile cube and remove kick/ban or something misc and look what happens the kick/ban code does not respond and he can come back and cant be kicked/banned.

reply to this message

#19: Re: ...

by Aardappel_ on 04/28/2005 18:35, refers to #15

sure, such a system would work better overal, but it is a more complex system. If we're gonna build a more complex system, I would prefer to just build the system referenced in my initial post. My point of this thread was to see if there are simpler solutions, maybe there aren't.

reply to this message

#20: trust sytem is best

by marco on 04/29/2005 00:45


Hi, I just stumbled on your page. My $0.02 : you want _strong_ identification so you need a PKI infrastructure - there is no shortcut. I don't think it is that hard to implement; once you can identify people uniquely I guess any banning policy will do.




reply to this message

   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
53411507 visitors requested 71171286 pages
page created in 0.031 seconds using 10 queries
hosted by Boost Digital