[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