Cheating & open source, revisited

by Aardappel_ on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 188258 views, last view: 11/01/2024 11:38

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   

#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

#159: Facilitatating cheating

by shadow516 on 06/26/2005 00:57

In my opinion, one of the best ways of combating cheating is to facilitate it. Make "sandbox" servers where cheating is acceptable, "regular" servers where there are bare-bones cheating measures, and "official" or "tournament" servers where there is serious cheating prevention. That way, people who just get bored with the game can go to the sandbox servers and just goof of, or maybe experiment with a new idea, and not interfere with serious games.

reply to this message

#160: Re: Facilitatating cheating

by CrazyTB on 06/26/2005 05:28, refers to #159

Interesting idea... Not sure if will work.

Of course, we will need some type of cheat-checking at servers/clients, or some type of "kicking", when some cheater tries to mess with "pure servers".

Care must be taken to not leave any little hole to allow cheaters cheat with kicking system. :)

reply to this message

#161: Quick synthesis and centering back to main topic

by D.plomat on 06/27/2005 00:40

The legitimity of using home-compiled bins on official servers is another topic (IMHO this should be allowed if this doesn't conflict with some contraints (ie the actual anti-cheat protection) but i don't consider this a very important thing as Cube is still 100% open-source). Some agree, some disagree but that's not the point.

Cube uses modified bins as anti-cheat protection. This protection isn't effective for a game that reaches some audience. This also applies to many commercial games, be them closed source or not (well, actually they're all, and that doesn't seem to make them cheat-proof). But that still isn't the point.

Some technical solutions have been studied, mainly:
-checksumming binaries, any tech that have some basic IS security notions will tell this is trivial to fool on a non-trusted client. (the PC of some random unknown user who downloads Cube obviously is a non-trusted environment)
-heuristics analysis of the game actions , as many have said => leads to endless and already lost arms race between developpers and cheaters, with added side-effects:
-making FOSS developpers waste precious time (a developper (with already a huge TODO-list) will use 3-4 hours for coding some protection algorythm and some folk who has nothing more useful to do will always find some other way to cheat in a couple of minutes)
-bloating the code

Aard already thought about all those alternatives, already knows why they won't work and proposes a new system that seems very promising, and is also very friendly for open-source gaming, both by not necessiting closed souce bins and the efficiency/developper workload ratio so i think we should really concentrate on two things:
1. Implementation and design choices for this system
2. As any security system, begin to harden it already by trying to find potential holes in and closing them even before it gets exposed to the wild


@shadow: the "sandbox servers" are the public untrusted servers in the system Aard describes. Regular are trusted with a minimum trust value required, official and tournament have higher required trust-value.

reply to this message

#162: aw geez

by pushplay on 06/27/2005 09:04

"Why not allow people to set up servers that can only use official bins"

Why does this keep comming back?

reply to this message

#163: official bins..

by Aardappel_ on 06/28/2005 04:44

don't really stop anyone from cheating, as we have seen with cube. It is good as a stopgap measure, but certainly can't be a longtime solution for sauerbraten.

reply to this message

#164: player identification

by hungerburg on 07/06/2005 12:44

slashdot today is carrying a story about "OpenID", the "blogosphere"s distributed commentors identification system. Basically: if a nick contains an @ sign, its an openID, and can be checked - by the cube server and/or client - against the IDserver (part after the @). players have to logon to the IDserver before playing (maybe inside client). its in itself not secure enough for banking, but might work well with commenting and gaming too.

CONS:
- lag when player joins (query the IDserver first)
- servers and clients have to keep lists of black sheep (players, IDservers) (or better whitelists?)
- dependancy on xml/rpc library, if the livejournal system was used
- newcomers still arent trusted, ie. they are "unidentified"

PROS:
- makes it easy on newcomers that already comment on blogs ;)
- makes ID expensive (have to sign up for a new account on a *trusted* IDserver, once caught cheating and blacklisted or taken from the whitelist)
- nick is used for identification, so nicks (the full ones) become "properties" like email addresses - but the first part (prominently displayed) is free as anybody can run her own IDserver

reply to this message

#165: Re: player identification

by Aardappel_ on 07/06/2005 20:54, refers to #164

the pro's/con's tradeoff for this isn't really working for cube. The amount of infrastructure needed to interface with this, + the amount of cube specific stuff on top of it would be huge. And then it doesn't really solve our problems all that well as identities for cheating are still a bit too easy.

If you'd go this "establish identity on the web" route, it'd be much easier to just tack on a more serious user registration to this forum, including people's homepages and other info, and more of a tie in with the masterserver where we can see games played, on what servers etc. Then add a system where I can extend my trust to users I know, and a way for servers to only allow users with a certain trust level.

I don't like this because it requires too much administration, which is exactly what my original ideas were attempting to solve.

reply to this message

#166: Big player models? Change mapmodels?

by CrazyTB on 07/11/2005 04:36

If someone can change the default "ogro" playermodel to some other bigger model, then this player will be able to shot the others easier.

The same thing may happen if someone deletes all mapmodels, or change to something smaller.

In addition (this was already discussed before) the player may have a different map, and will be able to "hide in walls" (from the point of view of non-cheating players).

reply to this message

#167: ...

by ooo on 07/11/2005 06:07

actaully the big player models does not work, it would resize the player so it really doesnt matter if he changes it to the pig or the knight.

as for having a different map, that may be a problem, because it takes no skill what so ever to edit the map so you have an advantage around the corners and such

reply to this message

#168: Re: ...

by D.plomat on 07/11/2005 17:44, refers to #168

Maybe that would use much CPU on the server. I think it wouldn't be too much for Cube, for sauer i don't know.

And maybe that could make the game even more bandwidth-friendly than it already is :)

reply to this message

#169: Re: ...

by CrazyTB on 07/12/2005 03:57, refers to #168

Send/receive only visible players won't work, because someone's bullet/rocket even if the player is not visible to me.

The problem with modified maps is that cheater will "enter" in walls. The non-cheaters won't see him, but the cheater will be able to shoot. The non-players will think the wall is alive and can shoot...

I think all clients must do collision detection for all players. This may avoid some of the cheats.

reply to this message

   Board Index