Cheating & open source, revisited

by Aardappel_ on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 188242 views, last view: 11/01/2024 11: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   

#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

#21: Re: trust sytem is best

by D.plomat on 04/29/2005 13:03, refers to #20

PKI is something complex but fortunately there are already many available free and well documented standard tools+libraries.

> any banning policy will do

Not any, but the trusted communities system establishes autobanning (in fact not banning, but restricting access to trusted servers) based on a powerful distributed rating method that is viable to scale very well without constant heavy monitoring by dedicated staff.
So it's precisely this banning system if we can call it a "banning system" that can be used effectively for free games and communities projects.

reply to this message

#22: ..

by sinsky on 04/30/2005 01:34

You may be surprised but I've been thinking about that too. Of course I can't really do anything because I lack low-level coding skills completely, therefore my course of action took an entirely different and very wrong direction. I won't talk hypothetically because I've already done it (hold on to your chairs - big laugh is coming :).

So. What is it that a cheater gets from the cheating experience? Can't really be sure. Could be anything, but practically it's always something malicious. The guy feels good and everyone else feels bad. He can do the important thing, and other players who have invested time, emotions, and money in the ideal case, can not.

I doubt there's a way to identify 100% if a person has malicious intentions, even in real life people that know each other for ears sometimes have a hard time with this. You see, removing a cheater does not really solve this problem because someone can always make you feel bad just as easily using the chat, and cheat protection comes in to make this happen rarely by eliminating technical issues. And when something bad happens rarely, more people will join a community in the meantime, but is more ppl = more fun?

I understand that I haven't said anything important and maybe it's time to apologise for wasting your time so far. So I'll be brief - not long ago I enabled coopedit mode on Orb, my pet Cube project (at home I mean, nothing new on the web yet). Since Orb editing heavily relies on typing console commands, I also made messages received from the chat be treated as console commands. This system is highly inefficient and can survive only between people with 100% level ot trust, and probably not fitted for a community at all. If we have ten people playing for example and one of them types "quit" on the chat, all clients will quit and all coopedit work will be lost (unless saved recently). Of course this arises another question - what could a cheater do in a coopedit game where players can not be hurt physically, and only their work on the map can be altered. And also if a cheater, who I think can merely be referred to as "malicious person" in this environment, has done work on the map along with other players what rights does he hold to that work.

Of course it's just a game. No one really cares about a few cubes.. or do they.

reply to this message

#23: ..

by pushplay on 04/30/2005 03:02

It seems to be that kick-timebanning the ocasional punk is far less work than seeing the people I want to play with (not all of whom speak enlgish or see outside the server) get a copy of my key, and have to repeat that process every time I suspect someone has gotten a hold of my key that shouldn't have.

reply to this message

#24: Re: ..

by Pxtl on 04/30/2005 03:20, refers to #22

I think his point on malicious person is well taken - in any system, you have to wonder where you draw the line? Any kind of griefing behaviour (chatspamming, TKing, etc) or only for outright cheaters? There is the problem of what physical method to use to kick someone off of a server. For example, if you use group voting, I'm sure it would be trivial for the griefer to just connect 15 fake clients and take over the server. Admins are often absent. This is why I think there's merits to having a Slash-style masterserver for tracking users - you could let the long-term, experienced, good users have banning priviledges across all servers. Of course, then you also need meta-moderators to deal with anyone who abuses that power.

reply to this message

#25: ..

by enigma_0Z on 04/30/2005 05:09

Hmm, interesting...

I like the public/private key identification method alot...

But there's a n isue iwth this too...

If someone has become "untrusted", they can simply delete they're key and create a new one... of course then you decide whether or not they're trusted all over again. Unless you associate IP, Mac, and key within a span of, say, thirty minutes (DHCP users would die otherwise)...

What I mean is, if user A with IP 1.2.3.4 and MAC of 40*(whatever) and key of abcdefg becomes untrusted, logs off, and then reconnects with the masterserver with ip of 1.2.3.4 and the same MAC BUT a key of pqrstuv, then you'd have to realize that it's him...

But wouldn't having these huge keys eat up network time and kill server harddrives?

Hmmm

reply to this message

#26: Re: ..

by enigma_0Z on 04/30/2005 05:17, refers to #25

Some more ideas...

You would need a few things added to cube before this would work...

Namely:

1. A better (much better) voting system...

2. A kick/ban system (duh)

3. An easier way to identify players in game. The text is way to quick otherwise.

4. Serverside controls (kick, ban, slap, freeze, kill, + or - trust)

Another suggestion... perhaps trust should be governed by servers more than clients, eg. impose restrictions on clients, or make server votes count for more...

Another idea about managing trust...

Perhaps you could have two "trusted" numbers, server trust and player trust...

the server trust could be like b 1-1000, and client trust 1-100. That way clients can't all gang up on a single user (preventing trust wars), but servers could have more control over who connects and who doesn't. Furthermore, you could start players at 5001/501, and build (or destroy) their trust from there... You could make it too so that new users have a different trust number from any other users (so servers could judge better)... hmmm

reply to this message

#27: What does slap command?

by jean pierre on 04/30/2005 07:45

I never knew slap command what is its effect?

reply to this message

#28: Re: ..

by >driAn<. on 04/30/2005 09:25, refers to #25

"If someone has become "untrusted", they can simply delete they're key and create a new one... of course then you decide whether or not they're trusted all over again."
No, if they do a new key they start again with 0 trust.

reply to this message

#29: ..

by Gilt on 04/30/2005 17:42

I haven't really throughly read the thread, but it seems like everybody is talking about different things...

It seems like aard's idea is more of a way to give people who don't have the means or will to set up their own private server, the ability to use a temporary semi-private server to play on, in a sense. and that trust keys are per relationship, not player.

anyway, off the top of my head, I would be kind of worried about bots and hippies who trust everybody, though don't know how big of a problem that would be.

reply to this message

#30: ..

by Gilt on 04/30/2005 18:02

oh, and I bet cheaters will start preying on newbs to get into trust servers.

"Hey newb, you want to be my friend? If you're my friend you can go play on the safe trust servers!" or some other bullshit.

reply to this message

#31: ..

by makkE on 04/30/2005 20:19

I have waited a while to see everyones opinion before I post mine.

The most problematic issue I see about this "trust" system is that it´s pretty complicated. A system like this might make sense in a big community, but, don´t get me wrong, I believe cube will never get too big.

At the moment cheating is really no problem in cube. I believe it´s up to cube´s nieche-like state. (the closed netcode doesn´t really prevent an ambitious hacker from coding a cheat, does it?)

Someone who likes the simplicity and speed of cube´s gameplay is (at least to me) very often a person that wouldn´t cheat anyways. It´s brute gameplay does in my opinion only really attract people that look for real competition, for people that don´t mind losing ..etc..

The other half (I guess the majority) of people that try cube will quit playing it after 5 minutes anyways ("too fast, looks crap, too few weapons no this and that, can´t impress my friends with that"..)

So well to get to the point: Cube´s gameplay already prevents a lot of "malicious" persons even bother with playing it and cheating.
For those few morons (excuse me) that really try cheating or go on peoples nervers, a simple kick/ban function would be sufficient.

I also believe that just very few coders would bother to write a cheat for cube.
I mean those people want fame. They won´t be able to impress their fellow "evil coder friends" with saying: "Look I wrote a hack/bot/cheat for cube"
And the common idiot doesn´t code.., he´ll go back on some cs pub to use his easily downloadable hack/cheat and annoy people there.

Of course, if cube went fully opensource, the possibility to hack it would be there. But I believe none of the coders intrested in the cube code (the people on this board for example) will ever even consider writing a hack.

To sum my 2 ?cents up: ability to kick/ban people an the basis of a more simple ("Vote yes (F1)/no (f2)") voting system would be sufficient.

If cube should go open source and if after some time problems do arise, the trust system might be reconsidered.

One last word: I personally have met only 1 person I would have wanted to kick (for namefaking and spamming) in over a year of cube pubbing.

reply to this message

#32: Re: ..

by Aardappel_ on 04/30/2005 21:18, refers to #31

I don't mind putting in some simple ip-banning, infact, maybe I should do that already given that people have used in-memory client hacks already.

But I strongly disagree that people won't cheat... you seriously underestimate how retarded the average interweb user is. If the source code is right there, and it takes changing 1 number or uncommenting one line, it will be too tempting. You don't even need to know C++. Infact, on windows people will distribute recompiled binaries, much like now there's in-memory cheat clients available for cube.

And for the ESL, yes you may think you have less of a problem because you know all players, and you do demos/screenshots. But if I was interested in cheating in the ESL, it would be VERY easy without being noticed, I could simply write some kind of minor graphical enhancement (akin a radar or rendering behind walls) that shows me where my opposition is at any time. You can play with that information without it being clearly noticable on a demo, yet giving you huge advantage. You can turn these gimmicks off for the screenshot.

And in non-match games, these kinds of cheats are even easier.

reply to this message

#33: Re: ..

by DrLZRDMN on 05/01/2005 17:28, refers to #32

The way I see it, cube is not completely done. A lot of those cheating are mearely hackers trying to help the developement of the game, testing it. I think that if you want to implement the 'trust' do not apply it to all servers. I also think that people with modified clients should be allowed to play (but may be restricted from some servers). If somone is trying to play "seriusly" they don't want someone flying around shooting rapid fire rockets and not dying. However, others might like to experiment with the game.
For play servers and match servers, have them verify the checksum, however, also allow other people to run servers that allow hacking.

reply to this message

#34: Re: ..

by >driAn<. on 05/01/2005 19:31, refers to #32

Only a kick/ban system won't help, it would be too easy to cheat in cube if its fully open source. And yes, there are only a few fools/cheaters on the pubs atm, but if people see how easy it is to modify the client the pubs will be flooded by such dumb people, I'm sure.
I like the idea of an "open cube", but its really hard to find out if that 'key' system works.
Maybe its necessary to handle it like GPG/PGP with a kind of keyserver (for each community) and a public/private key for every player =)

reply to this message

#35: ..

by Jcdpc Mozilla_is_teh_cookie_monster on 05/03/2005 03:06

I think a kick/ban system is the best way to prevent it. The other systems seem either ineffective (sure the player might not be able to code a bot, but he can still do that map-hack trick that im going to refrain from explaining in detail, but you probably know what im talking about) or might cause more problems than they solve (the trust system could easily be abused, and is overly complicated)

reply to this message

#36: On Further Reflection

by pushplay on 05/03/2005 07:32

I've decided I actually like the idea. Trust keys isn't mutex with voting for the common servers, and the possibility of cube becomming even less newbie friendly isn't as bad as punks wrecking the community entirely.

reply to this message

#37: ..

by kernowyon on 05/03/2005 10:33

The biggest problem with implementing any form of cheat banning system would be that some people get accused of cheating even when they are not. We have all been in servers where someone has the invulnerability bug - or seems to move amazingly quick due to lag issues etc. And of course, there are one or two players out there who are genuinely unbeatable - insight for instance.
With a vote system, these people could be kicked from a server - and maybe even blacklisted - for something which isnt their fault.
I do agree that cheating is an issue - I have seen some quite blatent cheats of late - with all weapons in insta for instance, or even with modded weapons ( anyone else see the guy with the flamethrower? ).
One thing I do find annoying is the number of people who find it funny to bind a key to say abusive phrases - usually involving some very foul language. Likewise those players with foul nicks to start with.
Luckily, as has been mentioned in this thread already - most of the cheats seem to appear for a day or so - then leave the servers.

reply to this message

#38: ..

by deathrabbit@optonline.net on 05/03/2005 23:34

I really agree with kernowyon for the most part. Most cheaters leave fairly quickly possibly since there isn\'t any way they\'re rewarded other than having a little fun unlike in some other games where there are rankings or items to buy. Most of the time there is no problem but occasionally there is one but as kernowyon and many other people said they usually go away after a day and sometimes you can play around them of just go to a different server.

Before implanting any kind of anti-cheating system you should either fix or think about game bugs that may make someone look like a cheater who is not such as the invincibility bug most people who play a lot have seen and/or had it happen to them.

Trust keys might be annoying and hard to deal with if you play on multiple computers and would make it VERY hard for new people to get into the community or even people who just took a break for a while unless there were rules restricting the use of \"trust only\" servers.

A kick/ban system might be nice since you could remove the cheater but it also has problems. Many new players don\'t read the instructions like they should and don\'t know how to vote, therefor making your vote have a harder time passing. Also kicking someone would probably temporaraly fix a glitch giving a player an unfair advantage, but most players would probably jump right to banning someone. Also a group of cheaters could join a room at the same time to prevent the vote from being passed and to ban regular players! Also if ip\'s were banned, some innocent people might not be able to play because of someone else on the same network cheating or has dynamic ip geting banned. Also with the idea of a + - trust system, morons could lower peoples trust just to make them look bad unless maybe admins and mods could give trust for free and other people have to pay 1 trust to raaise or lower someone\'s trust? exept nice people might lower their rank too much. Also with a trust system, someone can play legitamatly and gain people\'s trust and then cheat when they\'re fully trusted.

I believe a simple kick/temp ban(no more than an hour) would help a lot. Cheaters or people who have an advantage to to glitches could just be kicked and if someone continues to have an advantage they could be temp banned. The temp banning would get someone out of the game for a little bit in case of a mistake they\'re not fully banned and most cheaters would probably go away during that time and if they didn\'t it wouldn\'t be a bit deal to ban someone every hour and I dought they would stay for more than a day trying to get back in.

Also a server moderater system would be nice so that the person in charge of a server could give out a password to people they trust and they could kick/ban people within that server. This way people can be in charge of who is on there server and remove cheaters and other morons.

Also i have one last note:
To all people who talk about if cube was fully open source, it is essentially fully open source as long as it can be dissasembled fairly well. I recommend you use a software protector such as SDProtector, or ACProtector on the Windows version which will make it much harder for people to hack or dissasemble it and only the best of the best will be able to, who will probably not be able to be hardly stopped at all anyway. I recomend you stay away from X-Treme Protector and Thermida though because they like to mess around with the Windows registry.

Thanks for reading.

-deathrabbit

reply to this message

   Board Index