[quake3] non-cheatable game

Diego de Estrada diego1609 at gmail.com
Tue May 15 01:00:01 EDT 2007


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