[quake3] non-cheatable game

[Mike Hobbs]

I know, I know, but I've just been catching up on old email and ran 
across this thread (again). Hopefully this will put the nail in the 
coffin once and for all:

Every Intel processor contains a special single-step trap flag (TF) in 
its hardware. When set, it allows a low-level debugger to trace each and 
every machine code instruction that occurs in the processor hardware. 
This effectively allows the debugger to inspect and/or modify all memory 
and every CPU register value after each and every CPU instruction. So 
even if you obfuscate or encrypt the binary code, a debugger will ALWAYS 
be able to monitor what a program is doing in the CPU hardware and alter 
its behavior. To prevent hacking 100%, your only option is to run the 
program on a non-Intel CPU; preferably one that can perform proper 
arithmetic and logic with encrypted data in its memory and registers.

You can try little tricks like setting a program to run as a hypervisor, 
which might fool the debugger into running in an emulated environment. 
But at the end of the day, the end-user has physical access to the CMOS 
and boot sector of the machine and can therefore always out-hypervisor 
your hypervisor. (Not to mention the option of installing an in-circuit 
debugger.)

- Mike


David Jackson wrote:
>
> I am unsure as to why this has devolved into derisive comments and 
> veiled insults.
>
> Rather than reiterate, I will simply take a few steps back and when 
> everyone comes to their senses, and the outrage subsides, I will 
> return to this discussion.
>
>
> On May 15, 2007, at 2:02 PM, LinuxManMikeC wrote:
>
>> Whatever you make, someone can break.  Its just a question of how
>> difficult you make it for them to break.  Hence, "you will never be
>> able to make the game non-cheatable".  You can only make it extremely
>> difficult to cheat, or make it infeasible to even attempt cheating for
>> a considerable length of time.  But if you really have such profound
>> knowledge of how to do this, why not go create it, become a
>> billionaire, and make us all eat our hats?
>>
>> Mike
>>
>> On 5/15/07, David Jackson <azog at bellsouth.net> wrote:
>>>
>>> I always worry about absolute statements like "this can never be done".
>>>
>>> You have to look beyond conventional methods of memory mapping, and
>>> program code/program data organization.
>>>
>>> I'm not going to dig into it, it's far too lengthy for this forum,
>>> but it is entirely possible to obfuscate it at many levels.  The
>>> question becomes more what tradeoffs you are willing to accept.
>>>
>>> David Jackson
>>>
>>> On May 14, 2007, at 10:51 PM, Theorem 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
>>>
>>>
>