[quake3] non-cheatable game

[~tw3k!]

man in the middle attack?

On May 14, 2007, at 11: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

Forest
http://tw3k.net