Re: Bit on cheating: was: Re: Introductions

[Gregor Mückl <GregorMueckl@gmx.de>]

Am Mittwoch, 10. Dezember 2003 17:24 schrieben Sie:
> On Tue, 9 Dec 2003, Gregor Mückl wrote:
> > > 2)The main engine is a balanced tree with “game time” as the key.  Each
> > > player will run his own tree and only check in with a central server
> > > periodically to stay in sync.  When a unit is moved it must publish 
> > > events locally, if it moves onto enemy ground, it must publish on both
> > > the local and remote event tree.
> >
> > This is a *very* problematic approach. This way you open barn doors for
> > cheaters. Because each player has the only authoritative copy of his map
> > locally it is on him/her to edit it as he/she likes and noone would even
> > have a chance of noticing that.
>
> You could fix it though, by storing all events on the client, and having
> the server replay all events when syncing. Only if the states match, the
> player is allowed online. And obviously, other clients would check from
> time to time, that the hashed state of the clients matched the server
> hashes. (This way the server could check the rules, reducing the load on
> the clients). This is doable, I am sure.
>

That sounds like a nice approach for simulations.

> > The only measures against cheating that I am aware of are rather
> > drastic:
> >
> > - use a server that decides on *everything*. If a citicen in a player's
> > city wants to poop, the server must confirm it.
>
> But, in non FPS games, where player interaction is rarer, you can actually
> "just" check that the rules were followed once in a while.
>

Yes, you can definitvely play some tricks here. But since my focus is on an 
action game, I am not really aware of too many techniques.

> > - encrypt/obfuscate network traffic.
>
> Wont work with open source though :-)
>

Ah, this hits the weak spot of open source games: Once you get hold of the 
source code, you can do anything with it, especially adding cheat code within 
the actual game logic. So the bottom line is that you can trust neither 
server nor client by default, which is a very unpleasant situation.

I think that the easiest countermeasure is to provide players with the means 
to rate - and maybe even ban - players that are obviously cheating. However, 
this must be done in a democratic process, or the cheaters themselves might 
use it in revenge on honest players. Such a model does not need a very 
sophisticated design, but will need some kind of moderation to actually work.

> > - never release the sources for your network code. This is not as
> > far-fetched as it might seem: it's very likely that the people at Valve
> > are rewriting their Half-Life 2 network code totally from scratch after
> > the sources leaked in October. The release date hasn't been moved for
> > nothing.
>
> Other methods, includes what the nethack people does; blessed binaries,
> with embedded (randomly accessed) digital keys.
>

This is an interesting approach. However, I do not understand how they are 
able to hide the key in their binaries. Given the statistic characteristics 
of a cryptographic key (quite a lot of keys look like they are an almost 
perfect stream of random numbers, mostly because how they are generated), you 
should be able to make it out within the file within minutes. Using strace or 
gdb on a nethack session might give you quite some extra hints on the 
location of the key.

To the key to this approach is to effectively hide the key from prying eyes, 
within a region, on which the user has the ultimate control. How can you 
possibly do that?

Additionally, this is not possible with true free software licenses like the 
GPL, as the binaries and sources that you distribute must actually correspond 
exactly. So you would be force to publish the unobfuscated key along with the 
code. The only alternative I see now is to use the BSD license. IIRC, nethack 
is under a BSD-style license, right?

> And, you could authenticate the players: Won't stop cheating, but allows
> you to distinguesh between players you trust, and do not trust.
>

See above. Some time ago I've started to design some sort of generic 
metaserver along with a player database, which would essentially become some 
sort of single-sign-on environment for players.

What I wanted to do was to make a database-backed server that is able to 
distribute lists of currently running games along with their states. The 
protocol would allow for a filter on the game name to allow the server to be 
shared between totally different games (for example, both atlantik and quake 
games) and would allow each game server to store and update additional 
essentially free-form game specific data with the reference to itself (such 
as current map, number of players, etc...).

The second part would have been a centralized player "management" facility 
together with means to rate individual players. The players do not need to 
enter a lot of information in the registration process: a nick, a password 
and a working email address should be enough.

My idea was to provide game programmers with a framework that covers all of 
the above. A game that fully supported the framework would even have the 
possibility to show each player's current fairness rating (and possibly even 
high scores or leage ranking or ... whatever, actually :-) when the player 
enters the game.

When I look at all the database work in the backend I think that this might 
even be a fun project to tackle. Would anyone be interested? 

Regards,
Gregor