Cheating & open source, revisited |
by Aardappel_
on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 188227 views, last view: 11/01/2024 09:28 |
|
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
|
|
#39: .. |
by deathrabbit
on 05/03/2005 23:49
|
|
Sorry for the double post, but I missed some stuf and could a mod please edit my e-mail address out of the name slot? I axidentally put it there and dont really want it there.
Also, some people don't realize how bad the cheating situation is. For those of you who don't know, we've seen modded weapons, edit mode in any mode, other weapons in instagib, infinite ammo, invincibility, people moveing like 10 times as fast as anyone else, and other problems.
You could try comparing some sort of checksum when you connect. This might work but memory cheats could be loaded after connecting, so the check could be more frequent.
Another idea that I like more than all others that I have seen and and came up with is the ignore idea. A player should be able to ignore and not see anything about including the score, character model, ammo being pickud up, and bullets from players that they choose. This can make a person not mind if a cheater is in the game since they can just ignore them and neither person will be able to see or effect the other one, rendering all the cheaters cheats useless, AND giving them no targets to cheat against.
Thanks for reading.
-deathrabbit
reply to this message
|
|
#40: Re: .. |
by lokirulez
on 05/04/2005 00:35, refers to #32
|
|
"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.""
Cheating/faking/hacking is a common problem in online leagues and will always be. The only thing league admins can do is check for easy to recover things like demos/screenshots.
I read about your trusted communities quite a long time ago and still think it's great.
I doubt that a social anti-cheat system will work in competions, but let's have a try, anyway.
reply to this message
|
|
#41: deathrabbit |
by pushplay
on 05/06/2005 08:30
|
|
The difference between cheating by hacking a binary and hacking the source is miles appart. In hacking a binary I can play with some constants and maybe get extra ammo and take less damage. In hacking the source I could get super elaborate and you would never be able to detect it. I could have timers drawn over all the pickups for when they'll respawn, you would never know.
And given the game is open source there is no question you could ask my hacked client that I couldn't give a correct answer to. As a last resort I could always have my hacked client also run a server for a proper client and relay all questions and answers. Man in the middle attack basically. I even question the viability of trusted computing in hardware
reply to this message
|
|
#42: .. |
by makkE
on 05/23/2005 04:15
|
|
Uhm I never really believed it could be a problem until I saw it today. Go for the trust thing and the kick/ban :(
Sad but it´s got to be (saw a guy ruining a game to day by editing :(
reply to this message
|
|
#43: my $.02 |
by Sparr
on 05/23/2005 04:35
|
|
I have an idea. What if cheat ban voting was automatic? This idea would not help against passive hacks like radar, but invulnerability hacks for sure. Basically you set up the client so that every few seconds it randomly picks an opponent and tracks their position, health, weapon, whatever. If your client thinks they are doing impossible things (like floating if they have the wrong/hacked map) then it lets the server know. If enough clients make the vote, they get kicked.
I think vote kicking would be nice too, even if not against cheating. It would be nice to be able to kick people who dont understand /getmap, or who chat spam. The best part about voting is that its completely human controlled. Unfortunately this would hurt players like Insight who might get accused more often than they should, but in cases like that you could implement whitelisting by server admins.
reply to this message
|
|
#44: the real solution... |
by Sparr
on 05/23/2005 04:36
|
|
I think the real solution to the problem involves a little of everything. Take every idea here, implement it to SOME degree. Getting the right balance will be hard, but every method helps fix the weak points of another.
reply to this message
|
|
#45: Re: the real solution... |
by kernowyon
on 05/23/2005 10:28, refers to #44
|
|
Yep - good idea.
As mentioned, voting to kick people can be incorrectly or maliciously used against those players who are good - such as Insight or several other great players.
However, something needs to be done to rid Cube of the comedians who appear on a server then spout obscenities at everyone, or those people who are blatently cheating.
I do wonder how many of those "floaters" who dont have the correct map are new to the game and simply dont understand the /getmap function? Many times I have seen people asked to use the getmap command, only to see them typing getmap without the actual / command prompt bit. So it simply comes out as getmap repeated many times before someone puts them right. Same with name etc.
I like the radar idea - that would solve the invulnerability issues at least - which is something which seems to cause of lot of aggro in the servers. The number of times people are accused of cheating when they are simply victims of the invulnerability bug is amazing. Of course, some people do take advantage of it - but to be fair, its hard to tell you are invulnerable sometimes for a while.
reply to this message
|
|
#46: .. |
by CC_machine
on 05/24/2005 19:10
|
|
also dont forget that there are other types of cheating other than mods of cube, for example:
using a modded map to give the player an advantage (e.g. flood the map to enable flying to dodge rockets etc.)
believe me ive tried it before, and no-one even suspected me of cheating ( just for testing.. honest)
reply to this message
|
|
#47: .. |
by makkE
on 05/24/2005 21:02
|
|
I know that kinda stuff is pretty obvious.. but you should refrain in the future to even mention it ;) Don't tell them how to here..
reply to this message
|
|
#48: .. |
by CC_machine
on 05/26/2005 19:39
|
|
oops.. just thought id mention it cause you were asuming cube mods were the only way to cheat :P
reply to this message
|
|
#49: Re: .. |
by jean pierre
on 05/27/2005 07:19, refers to #48
|
|
Mine says different protocol when entering in a server with my MOD that is a good thing tough becouse i editted weapons and it isnt cool to have rocket launcher in multiplayer that does a bigger explosion that could kill 20 people on touch(if they're near)
reply to this message
|
|
#50: .. |
by CC_machine
on 05/27/2005 23:19
|
|
jean pierre have you uploaded your mod to quadropolis (http:\\www.cube.snieb.com)
reply to this message
|
|
#51: Re: .. |
by jean pierre
on 05/28/2005 07:06, refers to #50
|
|
Last time i tried it gaved me an error page really due to long time and i seriusly hate uploading too much so dont suppose to help but im sure Fusion is even better cause Lava MOD is just a pack of new lame graphics and different levels please dont ask me to upload it now(Il upload it maybe when Hell freezes over?)
reply to this message
|
|
#52: .. |
by CC machine
on 05/31/2005 17:17
|
|
question: everything physical (that is the player physics, not textures models and all that) is in the cube.exe inside the bin folder right? at least i think it is. if that is true, if someone is accused of cheating, then the server could upload his/her cube.exe and see if it is modded. scince the .exe is only 148 kb, it shouldnt take too much time to upload
What do you think of my idea?
reply to this message
|
|
#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
|
|
|
Board Index
|
|