Re: Game Loop and Simulation

[Erik <br0ke@math.smsu.edu>]

On 10-Feb-2000 Steve Baker wrote:
> Mads Bondo Dydensborg wrote:
>> 
>> On Wed, 9 Feb 2000, Alan Chen wrote:
>> 
>> > I should note that there are related problems with a
>> > standard client-server setup. A dishonest client can
>> > cause just almost as many problems as a dishonest or
>> > malfunctioning peer.  Does anyone have info on
>> > solutions for that?
>> 
>> There has recently been a lot of discussion about this on the QuakeForge
>> mailing list, given that cheating in the current implementation of Quake 1
>> is very possible.
>> 
>> You will have to divide the cheats into 2 classes:
>> 
>> a) cheats like : client side "bots" that plays instead of the server
>>    (also timers etc).
>> b) cheating directly with the game state; running faster then allowed,
>>    etc.
>> 
>> Due to a tradeoff between clientside prediction and security, cheats like
>> b) are very possible in Quake (at the moment). Moving all game logic to
>> the server seems to be the only way to stop this.
>> 
>> a) is unstopable (in theory). Only if you can find a way to ensure the
>> client player uses the correct client, OS, drivers, hardware, etc. can you
>> guarentee cheating wont happen. In practice various levels of obfusication
>> may help for various periods of time. (Like binary only releases,
>> encrypting the datastream, hiding the decryption key in the binary, etc).

ok, so I packet dump the authentification sequence into a file, modify the
binary, packet dump the auth sequence again, look for the difference, and
'edit' my version so it sends the same info as before... And I think things
like binary only releases and trying to hide the details will *NOT* help at
all, and will probably result in poorer security, both from laziness (look at
m$ security, oohhh, how powerful their password crypts are) as well as making
it a juicier target for people who brag about cracking programs... Good solid
open source security would, of course, be optimal, but that'll have the servers
working extra hard... but hiding code/methods and trying to generate signatures
won't really enhance security

> 
> The problem under Linux is that all the infrastructure is OpenSourced and
> the provisions of GPL guarantee that you shall be able to re-link the
> binary against new library code.
> 

this applies to windows, too... More and more things in windows are getting
open source alternatives

> Hence, even though you have no sources - and no desire to reverse engineer
> the binary, cheating is still possible.
> 

I remember on the commadores, a lot of games got "cracked"; the security
options removed and usually there were cheats inserted, sometimes called
'trainer' mode. When they did that, they didn't reverse engineer the entire
binary, they just fiddled, poked, and prodded until something interesting
happened and reverse engineered the tiny little part they were interested in. I
doubt it'd be very difficult to mess with a modern game this way provided a
decent debugger and knowlege of asm...

> One hack that would be very easy (for example) would be to change Mesa
> to render every polygon at only 80% of it's normal opacity.  This would
> allow you to see through walls at people hiding behind them. (Well, maybe)
> This would only take a couple of lines of code.
> 

this is the kind of thing I'm seeing as an issue for windows...

> I'm sure that an inventive mind with nothing better to do than cheat
> on computer games could come up with a variety of similarly creative
> hacks.
> 

there're ppl with skill out there who can't think of better things to do... :)

I think in the end you have to trust no one will cheat enough to cause a
problem. No matter what security measure is in place, it can be subverted. The
goal isn't to make something un-cheatable, it's to make it so it's not worth
the effort. I think that's something a lot of people overlook when thinking of
ways to curb cheating... that's my dumbass observation, anyways :) now 'scuze
me while I edit mesa to help me win q3... :} (if only I had the hw to run it)

> -- 
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
> sjbaker@hti.com      (work)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
> For additional commands, e-mail: linuxgames-help@sunsite.auc.dk

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.