[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Bit on cheating: was: Re: Introductions
> > > - 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 don't think so, because having the sourcecode is only marginally easier than
having the binaries. Reverse-Engineering is too easy.
What it really needs here is a Trustworthy Computing Plattform, something like
Palladium, that has the feature of remote attestation. With remote
attestation a player can remotely attestate against the server and against
all other players that he is playing fair.
And this would only really make sense when the Games are OpenSourced, because
only then every player can inspect, whether the game itself is fair, and what
the attestetated fairness really means.
> 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.
Well, I am not really sure how you can counterfeit vote-cheating.
Secure voting is still an extremely hard problem in the crypto-branche.
> 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.
Come on. Never heard of Steganography?
There are enough easy and standard expansion methods. Base64, Hexadecimal, ...
Hexadecimal storage divides the Entropy by 2, but you can have any individual
expansion method you want.
And you can easily design a key-storage system, if you need that.
> 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?
Why? The Key is data, not sourcecode. I don't think that it violates the GPL.
But you should notice, that simple Knowledge-based-Proofs are fundamentally
flawed for remote attestation!
With a Knowledge-based proof (like storing a secret key in a binary, and
having a zero-knowledge protocol to attestate the knowledge of the key
against the other players and the server), you only attestate knowledge, but
It is the difference between knowing how to play fair and actually doing it!
With Knowledge-based Proofs you only attesttate that you know how to play
fair, but nobody knows whether you are really playing fair, and you can
easily attestate you knowledge while cheating at the same time.
So what you need is a trusted third-party (you have to trust it, and all other
players have to trust it) that controlls whether you are really playing fair,
and that attestates those controlling-results to the other players (and the
This trusted third-party can be other players on LAN-parties for example, who
are watching the game, or it can be a Palladium like platform for