Cube Engine Games

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, 188284 views, last view: 11/01/2024 13:30

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

#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.