Cheating & open source, revisited

by Aardappel_ on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 172867 views, last view: 05/16/2024 06:54

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   

#139: Re: General long-term strategy

by jean pierre on 06/19/2005 17:50, refers to #138

I had lots of nicks in this forum and all becouse of the internet forgets my cookies.
Now i no longer play in Cube and im proud of it

reply to this message

#140: Re: ..

by Gilt on 06/19/2005 18:34, refers to #139

I think at this point it's pretty clear that what you want is not an engine that can plug-in games, but a library that can be pluged into games.

reply to this message

#141: Re: ..

by enigma_0Z on 06/19/2005 21:00, refers to #139

That's a good idea, actually...

Then whoever makes the game module could keep the netcode closed so no one cheats... (Unless they want to take the time to dissasemble it and yada yada yada, but that hasn't happened with cube yet.).

The thing about closed netcodes is:

1) most people who don't want to cheat won't dissasemble the binaries.

2) Most people who want to cheat are n00bs who don't have the skill or desire to work at hacking the packets or the binary to cheat.

3) Most people who have those skills have better things to do with their time.

pfft. I'd rather a closed netcode like cube's current implementation than open everything. Of course it's up to aard, however.

reply to this message

#142: ..

by quirk on 06/21/2005 18:53

The ignore idea has many merits which other have pointed out but I do see some major flaws inherent in the idea.

It disrupts the game somewhat if some people can't see other people who others can.

What if person A is fed up getting trashed by person B and ignores him/her. Person A then starts attacking person C who appears to be jumping randomly and shooting at no-one. Person A then takes out person C because he isn't getting shot at or distracted by person B, making person C a resonably easy shot.

While a good idea and could be implemented well in other types of game, I don't think it will work here :(.

reply to this message

#143: Re: ..

by kernowyon on 06/21/2005 20:37, refers to #143

But surely, like so many ideas, this would have an effect on the better players in the game?
Person A is thrashed by player B - purely because A is new to the game and B is a long time player, who has practiced a lot.
So A ignores B - maybe because A thinks B is cheating because they always seem to kill them.
So B finds himself with a slowly decreasing number of people prepared to play him/her.
Unless B only plays on the ESL or whatever, this would happen very quickly.
Most means of banning or ignoring specific players - unless there is proof of genuine cheating ( rather than sheer skill or lag issues) - will end up with alienated players.

reply to this message

#144: ..

by quirk on 06/21/2005 21:10

The point is that it could be abused so easily. If I ignore the stronger players I can prey on the weak ones without getting shot at.

reply to this message

#145: ..

by deathrabbit on 06/21/2005 21:34

Although many good ideas are coming out of this, I think we are missing trying to prevent one of the worst (in my opinion) types of cheats, editing in non coopedit games. I think that, even though we don\'t like it, we can put up with someone who doesn\'t die, but it truly pisses me off when someone walls me in. This could be fixed fairly easily though. Whenever an editing command is used, the server could check what the game mode is, and if it is not coopedit, the person could be kicked. This would get rid of edit cheaters and force someone to reconnect if a bug lets them use editmode when thay shouldn\'t be able to. Unfortunatly this would put a little more strain on the servers, I dought the change would hardly be noticable.

reply to this message

#146: Re: ..

by pushplay on 06/22/2005 07:08, refers to #146

It's fairly straightforward to throw away edit messages from the server when in the wrong mode.

reply to this message

#147: Plugin Prevention

by tentus on 06/22/2005 21:19

ok, we've all heard Morgaine push for plugins, right? so, if each gametype was in it's own little plugin, it would be simple for each server to make a small custom gametype. toss in three or four other little plugins, which would apply for slightly tweaked physics, perhaps a spam/swearing filter, etc, all tweaked by the tiniest margin, and small enough to download in a minute or two on dialup, and all of a sudden a cheater has five times the work. someone who made edits to unrelated plugins would be in the clear, and the servers could even choose to follow Aard's Cube model, by making their plugins closed source.

by breaking everything into plugins you make the cheater's job harder, the server's flexibility greater, and the number of addition ways to safegaurd against cheating greater. anyone want to extrapolate on this idea?

reply to this message

#148: ..

by post on 06/23/2005 02:59

These are the cheats I've seen so far:

||Editing in a Non-edit Mode||
-This cheat allows the player to easily fly through walls and objects and edit the map by changing heights and even adding objects to a map.
(quit possibly the most interesting because all players are instantly affected during gameplay :: the only solution so far is to reload the original map which might reset your current score)

||Infinite Health||
-This cheat allows the player to never be killed.
(this is extremely annoying to other players, but can be easily recognizable that there is a cheater playing)

||Infinite Ammo||
-This cheat allows for infinite use of any weapon in any game type, even if the weapon is not allowed.
(the advantage comes when the cheater is the only one with a machine gun while everyone else carries a rifle)

||Change Score|| [frags]
-This basically changes score to any number including negatives so player can be in first place all the time or even last.
(Fortunately the cheater cannot edit other players scores)

The problem with all of these cheats is that none of them are caused by bugs in the game, which most of you have been wrongly assuming. All these cheats can easily be made through binary without ever editing a packet.

Goodluck if someone tries creating a way to stop cheaters.

reply to this message

#149: Ignore's ^

by jean pierre on 06/23/2005 13:51, refers to #148

Whatever......

Yeah right i did heard strange sounds in instagib like rocket launcher shotted only once in the game but that must be becouse the games loads a different sounds thats it.

reply to this message

#150: Re: Ignore's ^

by D.plomat on 06/24/2005 19:19, refers to #149

Maybe, but when you figure this player has a way higher score it gets much more suspicious...

The sounds are client-side, if the game on your PC plays the correct sound for you and other players weapons, then there's nothing that could explain one player makes a different sound unless he really *is* firing a different weapon.

reply to this message

#151: Re: ..

by CrazyTB on 06/25/2005 06:48, refers to #148

I think I know how to reproduce "edit cheat". (or, at least, one of its variations)

Go to some coopedit mode in some server. Then, go to another server running a map you don't have, and a non-coopedit game (maybe you can trigger this "cheat/bug" using the same server). Since you don't have the map, your current map won't be reloaded, and you will still be in edit mode.

How to fix this easily client-side:
- Forbid any edit command when (multiplayer && !coopedit).
- If current game is not coopedit and we receive edit commands from server, ignore them.

reply to this message

#152: Re: ..

by yes on 06/25/2005 07:22, refers to #151

yea, i think the server should have more control

people are able to edit their own map, and then the server reads it and sends it to all the other players, i think the coopedit feature is cool but i dont think many people use it seriously as in making a real playable map. this should be a private feature.

the problem is people are able to send maps and get maps freely, there should be some type of restriction

reply to this message

#153: ..

by yanqui on 06/25/2005 12:21

lets remember that a lot of the cheats we're talking about are modded bins, so trust can be more or less assumed on official bins.
Why not allow people to set up servers that can only use official bins if they want a trusted client-pool? On trusted games ignore/kick/whatever would become unnecessary, on untrusted servers the ignore/kick/whatever solution could be implimented.

Under this plan a good person can prove (s)he isn't cheeting by playing on a trusted client. Also people can know more or less for sure that the other people aren't cheeting too. All the security of closed source...
But on the other side it's still possible to modify the code and use modded clients on servers that don't require official bins.
People who want freedom have it, and they deal with the trade off of less security; people who want security have it, and deal with the trade off of less freedom. Everyone can get what they want without significantly impacting the playability of the game.

reply to this message

#154: ..

by yanqui on 06/25/2005 13:10

I understand where you're coming from and I see your point, but I disagree. It doesn't place people who compile their own bins into the same category as cheeters, it places all people who mod their bins in the same catigory.

Everything has trade offs. The trade off for open source games is that people have the ability to cheet. If you want freedom you have to accept the consiquences. Thats the way the real world works. Just because one group wants something doesn't mean that other people should have to deal with the consiquences of the first group's decisions.
This isn't penalizing anyone, it's allowing people to choose what's important to them without forcing them to deal with the choices of others.
Open sources is anarchism, and anarchism is about accepting personal responsiblity.

/ignore can penalize good players and puts them in the same catigory as cheeters. I think this is more unfair than using an official bin system because players who don't choose to compile their own source have to deal with the consiquences of the choices made by people who choose to compile thier own source.

Gentoo users can run bin files. The source includes linux bin files. Ergo, Gentoo users shouldn't have to recompile. I run the linux bin from the zip file and I don't have any problems.
Furthermore, if I could find all the libraries needed to compile cube from source I would. I would be among the group you say I'm penalizing.
I accept responsiblity for my use of open source software every time I can't use a shockwave file, or I have a problem loading up some windows file through wine. That's just the way things are, you just have to learn to deal with it.

reply to this message

#155: ..

by yanqui on 06/25/2005 13:18

<forgot>
...and trusted clients puts noobs in the same catigory as cheeters..
</forgot>

sorry, it's late.

reply to this message

#156: ..

by yanqui on 06/25/2005 14:29

"Anarchist software law (Copyleft)

The GNU General Public License (GPL) for publishing software, and similar licenses like the GNU Free Documentation License, are often considered examples of anarchist law. Although the GPL is a legal document which coexists with hierarchical legal systems, some claim that it is one of the most concrete elements of anarchist law. However, this is a moot point in the absence of any demonstration that the terms of the license could be enforced without such a legal system in place. On the other hand, the GPL's main goal is to prevent the conversion of free software into proprietary software through use of copyright and nondisclosure agreements. With no legal system in place, there could be no copyright, and nondisclosure agreements could not be enforced, so much of the GPL's purpose would be fulfilled automatically. It would, however, be impossible to enforce the GPL's terms against distributing binary programs while withholding the source code."

from <a href=http://en.wikipedia.org/wiki/Anarchist_law>Wiki on anarchist law</a>
Anarchism is about free association. Open source relies on free association. Anarchism doesn't believe in copyright law. GPL/copyleft is the nullification of copyright law through the use of a legal doccument. GPL/Open Source is the best example of real world anarchism ever. Welcome to reality... but lets get back to the point.

It's more difficult to modify a bin file than it is to modify source. People with the skills to hack a well secured bin file generally won't use them to hack a game. A user bin and an official bin may function exactly the same, but one was compiled in a controlled and trusted environment and one wasn't. Simple as that. One can be trusted and one can't.

Now, as far as cheeting with a bin file, well... nothing will ever make cheeting impossible. Nothing. Never. Not under any circumstances. Someone with enough skill, cunning, and dedication can ALWAYS overcome security. However, it is possible to improve security to the point that cheeting is greatly limited. Intercepting network traffic, hex editing a file, etc... all these require quite a bit more skill than just commenting out or modding one line of source.

In internet security you don't usually try to stop every hacker. That's not possible (money, time, etc). There will always be a way to exploit something, it's just a matter of time. What you do try to do is get rid of the really dangerous ones: the script-kiddies. The people who know what they're doing generally don't do any dammage, the people who don't know what they're doing are just there to make trouble. Same idea applies here. People with the capability to hack a bin usually don't use it that way, and if they do they usually tell you about it and how to fix it.

I'm not proposing that user compiled bins be completely banned from all servers, I'm suggesting that there be two different security structures. First the trusted (perhaps I should have said offial) that uses checksums and such, then the untrusted (and perhaps I should have said unofficial) that uses the the ignore/trust-key method. I'm proposing two security approaches for two different communities of users. I think that's valid.

reply to this message

#157: Re: ..

by CrazyTB on 06/25/2005 18:21, refers to #153

[quote]lets remember that a lot of the cheats we're talking about are modded bins, so trust can be more or less assumed on official bins.
Why not allow people to set up servers that can only use official bins if they want a trusted client-pool? On trusted games ignore/kick/whatever would become unnecessary, on untrusted servers the ignore/kick/whatever solution could be implimented.[/quote]

I once saw one person that was cheating, but haven't modified the binary itself. He said it modified some timers (I have no idea how), and made it directly into memory. So, even official bins can be used for cheating.

In addition, it is impossible to know if one client is using a precompiled or a user-compiled binary, unless we change the network protocol in precompiled. Even this way, someone could try to discover the "closed protocol" (sniffing?) and implement it in his source version. On the other side, someone could hack his precompiled binary.

I think the only way to avoid cheats is to make checks like "Nobody can move more than <x> units per second", "Nobody can fire more than <x> rockets per <y> time units", and so on.

reply to this message

#158: ..

by yes on 06/25/2005 19:49

o and theres a jump glitch

your able to jump about twice as high and the landing is like yur gliding down

reply to this message

   Board Index