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, 188391 views, last view: 11/01/2024 19: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.

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

#53: Re: ..

by eihrul on 05/31/2005 17:33, refers to #52

That still depends on the client to cooperate with the server. The client could just send over some other binary than itself and the server couldn't tell the difference.

reply to this message

#54: ..

by CC machine on 05/31/2005 18:44

i was having a good game of instagib team on map pyramids, and it disconnected and said:

illegal network message type(clientnum)
disconnected

what does this mean?

reply to this message

#55: ..

by >driAn<. on 05/31/2005 19:39

That means you told the server a wrong client number.

< 0 or > current players

That should not happen if the client and server use the original binary.

reply to this message

#56: ..

by Rick|FreeBSD on 05/31/2005 19:52

Actually it seems a bug in cube...I had it a few times too

reply to this message

#57: :(

by CC machine on 06/01/2005 00:43

spoiled my game, it was a good one, all players were at 10 frags each we were pretty well matched :(

reply to this message

#58: ..

by yanqui on 06/02/2005 11:34

why not shift important elements into a text file and md5sum the thing? md5summing a small file takes very little time, and the sum can be used to ensure that files are the same for all players. Take an md5sum from the server and require all players to have the same sum. Just a suggestion...

reply to this message

#59: Re: ..

by yanqui on 06/02/2005 11:43, refers to #52

what about linux? Also an MD5 hash would be just as effective and much smaller.

reply to this message

#60: ..

by yanqui on 06/02/2005 11:53

....sorry about the double post, it was a reply to #52. Windows bin files are going to be a different size than linux bin files. Theoretically depending on the libraries the linux user has installed linux bins could be different sizes without modification. Important variables should be moved into a text file that can be hashed and read on initialization.
I personally think that if a scripting engine were built that allowed more things to be put into external files seperate from the bin, security could be increased by hashing these files before logging on to a server. To increase security even more the server could send a randomly generated file that would then be hashed with the important files to make a master hash that would be very difficult to replicate.
This wouldn't make cheeting impossible, but it would make it infinitely more difficult. Cheeting would take more time and effort than just learning to play well.

reply to this message

#61: Re: ..

by Pxtl on 06/02/2005 14:17, refers to #58

Been thinking about this already. At some level there must be an opensource binary - it can fake the md5 sum, it can send alternate files (if the server does the sum).

Even if we ported the whole damn engine to Java so that we could ensure that the binaries are all exactly the same, you could still just have a binary that sends a fake. Plus, any program that binds to external libraries (like OpenGL) can still cheat other ways.

reply to this message

#62: Forced Map Downloads

by HopFrog on 06/02/2005 17:47

Would it be possible for servers to force map downloads? If so, that could eliminate any cheats formed by inconsistencies in maps. That wouldn't eliminate all problems, but it could eliminate some.

reply to this message

#63: Re: Forced Map Downloads

by HopFrog on 06/02/2005 17:48, refers to #62

I only mention that because cube maps are pretty small, and typically download very, very quickly.

reply to this message

#64: checksumming

by Aardappel_ on 06/02/2005 20:22

To all of you who want to checksum files.. realize that if you have full control over the source, you also can send the server the correct checksum even though in reality you are using a different file. You can't have the client "check" anything, as the client is not trusted.

reply to this message

#65: Re: checksumming

by Pxtl on 06/02/2005 21:42, refers to #64

Yep. I think most of the experienced coders are pretty-well convinced that there's no true way to prevent cheating on an opensource project. Even with a super-thin client, aimbots would still be dead easy.

reply to this message

#66: Re: checksumming

by yanqui-on-another-machine on 06/03/2005 01:17, refers to #65

but if the server sends a randomly generated file of say 100 bytes that had to be hashed with the map file, one would have to hash the normal map file with the key, then send the new fake numbers. It would make cheeting much more complex.
The hash for the map+keyfile would be different every time. Once again, this wouldn't making cheeting impossible, but it would make it more difficult.

reply to this message

#67: ..

by yanqui-on-another-machine on 06/03/2005 01:35

....and honestly I don't think the focus should be making cheeting impossible, we all know that isn't going to happen. The focus should be making cheeting difficult enough that it requires major revisions to the code that would be beyond the capability of the adverage player.

Right now they just have to change a few lines of code. With checksums they'd have to change multiple lines of code, or maybe even write their own application.
Even closed source games can be reverse engineered by a skilled enough programmer, but there are ways of increasing the difficulty to the point that the adverage script-kidde would be lost... and who cheets?

reply to this message

#68: ..

by yanqui-on-another-machine on 06/03/2005 01:46

or...someone could write a small closed source program to checksum everything. The real code could be open source, but a seperate anti-cheeting project could be created in which the source is only known to a few. The two would interact, but they would be seperate binaries. It could be reverse enginneered, but it would be more difficult.


damn it, I wish I could edit my posts. I keep having ideas right after I finish posting.

reply to this message

#69: ..

by pushplay on 06/03/2005 04:40

Look, hashing anything is silly. You tell me to run program/map a. I open a-cheat. You ask me to send you something about a, and I'll load it into a seperate space and do that.

reply to this message

#70: ..

by yanqui on 06/03/2005 07:17

the program could also hash the soucecode before compiling and somehow include that in the code...

reply to this message

#71: ..

by Tom Finnigan on 06/03/2005 10:41

I think that the key-trading is still the best idea, long-term. When a technological solution isn't viable, I think a social one is.

The one thing I'd change is how the keys are generated and checked. Public key encryption and strong hashing are available in a few easy to use and cross-platform libraries, cryptopp being one that I've had experience with. Send public keys to a server for a given identity, and then use your private key to authenticate (perhaps a dedicated key server would be useful).

Also, it might be better to assume that everyone is trusted until found otherwise, and limit the number of keys a given ip address can generate after being marked untrusted, to 1 a day or something.

reply to this message

#72: Re: Cheating & open source, revisited

by K. Jeras on 06/03/2005 14:09, refers to #63

The suggestions here do not actually address the issue of cheat prevention in the open-source game. They attempt to test that people are all running the same code, and that is inherently flawed in the context of open-source software.

People will be modifying the code in hundreds of different ways that have nothing to do with cheating, some to suit their local machinery, some to overcome physical handicaps by creating interfaces that they can handle, and some just to suit their individual preferences. That's what open source is all about.

Instead of focussing on the strongly anti-FOSS concept of everyone running the same code, cheat prevention needs to address only real game-related cheating, not local code modification. That means keeping certain types of data server-side and periodically checking that client state is consistent with server state. A client modified by a cheater (say for God mode) doesn't get him very far when the server KNOWS that he's dead, and the same applies for all the other player attributes that matter in a game.

Treat *everything* client-side as modifiable and under player control, and everything server-side as under game management control. It's the only approach that has any real chance of success in an open-source world.

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
58275936 visitors requested 76227632 pages
page created in 0.040 seconds using 10 queries
hosted by Boost Digital