[quake3] non-cheatable game

[David Jackson]

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