[quake3] non-cheatable game

Mike Hobbs mike at hobbshouse.org
Tue May 15 10:46:16 EDT 2007


I guess it does all come down to the meaning of "cheat" as Theorem 
mentions below. For example, even in a game such as chess or go, where 
the entire state of the system is known to all players, I would consider 
it cheating if one player was using software that "thinks ahead" for him.

On a related but more practical level, there exist several types of 
poker bots that will play poker for you on many of the on-line gambling 
sites. That is certainly considered cheating by the other participants, 
even though there is no patching or hacking going on.

- Mike

Diego de Estrada wrote:
> You are missing the point, this has nothing to do with DRM.
> This is not security through obscurity. Here the "root" guy is the
> server, not the clients.
> A bulletproof system is possible, but not easy:
>
> * Direct access to network data comming from the server must not give
> any advantage to the client.
> Example: instead of the server telling the client "an enemy is behind
> the wall" so that he can hear the foot steps, it's better to say
> directly "foot steps comming from that direction".
> This makes wall hack a dull boy.
>
> * A "lie" comming from a client should be detected if and only if it
> gives him any advantage.
> Example: it's easy to detect a too fast walking or movement of the
> camera, so speed hack and auto aim, to some point, are detectable.
>
> Anyway, it's clear that somebody can create something that plays
> excellent without trespassing the limits. I call it a bot, and
> fighting with them is meaningless. Even so, the quality of their play
> is somewhat an evidence of us being closer to Turing's dream.
>
> On 5/15/07, Theorem <theorem21 at gmail.com> wrote:
>> I disagree.  This is exactly the DRM problem, at some point in time 
>> you're going
>> to have to present it to the user, that's the whole point.
>>
>> The definition of cheating I use is "to deceive or influence by fraud".
>>
>>         This can be done many, many ways, software is one attack 
>> vector, hardware is
>> yet another.  This is why "if you can touch it, you can hack it" is a 
>> security
>> mantra.  M. Hobbs eludes to this with "..indiscriminate physical 
>> access".
>>
>>         Even assuming your software IS foolproof you rely on the 
>> hardware to make it
>> happen, which is tainted the instant anyone has physical access. 
>> You're missing
>> a large point here because you trust the hardware.  Regardless if it 
>> "would be
>> difficult to do" to hack your game in hardware I have no doubt it 
>> could be done.
>>   If not to inject code/control characters, then to make a physical 
>> robot move
>> the mouse,press keys, etc all for the user's enjoyment.
>>
>>         As a further aside, if you have root access you'll always be 
>> able to get at the
>> memory addresses of whatever is running.  Using an OS that doesn't 
>> allow you to
>> do that is a slippery slope and you no longer own this device.
>>
>> As an academic exercise I'm sure you can improve the security of the 
>> system to
>> an acceptable level, but you will never be able to make the game 
>> non-cheatable.
>>
>> Have fun :),
>> Theorem
>>
>> David Jackson wrote:
>> >
>> > This is untrue, on many levels.  It is a software engineering problem;
>> > admittedly, a very hefty one, but it can be done.
>> >
>> > At it's very core, you have to be able to protect your program code 
>> and
>> > program data.  A good start would be to -not- use dynamically-linked
>> > libraries.
>> >
>> > David Jackson
>> >
>> > On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>> >
>> >> I don't mean to throw cold water on your research and I don't know
>> >> what your proposed approach is, but I'm 99.999% certain that it is
>> >> impossible to absolutely prevent cheating on any system that the
>> >> cheater has indiscriminate physical access to. (As an aside, this is
>> >> one reason why DRM will never be effective on consumer devices.)
>> >> Access to the source code makes it very easy to cheat, but even
>> >> without access to the code, a hacker with a decompiler can do a lot.
>> >> Even if you encrypt the binary and all messages into and out of it,
>> >> the secret will have to be decoded and into the client's memory at
>> >> some point. A hacker can then inject whatever he wants at that point.
>> >>
>> >> From a different perspective, it is possible for a server to ban a
>> >> client that it "suspects" is cheating, but there is no way to
>> >> absolutely prevent it in the first place.
>> >>
>> >> - Mike
>>




More information about the quake3 mailing list