[quake3] non-cheatable game

Mike Hobbs mike at hobbshouse.org
Tue May 15 14:45:58 EDT 2007


Until the CPU can perform arithmetic with encrypted data in its 
registers, and the encryption key is 100% unreadable from memory, disk, 
network, and EEPROM, I remain skeptical that anything is hacker-proof.

- Mike


David Jackson 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
>




More information about the quake3 mailing list