[quake3] non-cheatable game

[Chris Bunting]

Hello,
I take it that none of you guys are actual game hackers or cheat makers?

I ask this because you guys have went round and round about how cheating can 
never be stopped but yet no one has posted exactly how any of these hacks 
are done.  I myself will not get into this. But all I can say, is that 
PunkBuster does the best with weeding out cheating. PB also catches almost 
all in-memory hacks for aimbots, wall hacks, ammo-mods and so forth. Almost 
every hack that once worked for Quake 3 no longer works anymore. Quake 3 may 
be a little different in the way that it was written but try to find a hack 
or write one to get past PunkBuster in Call of Duty 2.. It's almost 
impossible..

Most games based on of Quake 3 source code such as IoQuake, Tremour, Open 
Arena and many others offer custom game clients.. But how many of these 
developers actually modified any dedicated servers that work specificly with 
the client? ioquake doesn't offer a dedicated server that I've seen. So, 
until you write both, a client and a server with anti-hacking taken into 
consideration, there is no way to ever stop cheating.

Thats just my thoughts,
Chris


----- Original Message ----- 
From: "LinuxManMikeC" <linuxmanmikec at gmail.com>
To: <quake3 at icculus.org>
Sent: Tuesday, May 15, 2007 3:02 PM
Subject: Re: [quake3] non-cheatable game


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