[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

20109: Re: [MUD-Dev] Gearing up against GEAR

[Full Header] [Plain Text]
From: "Dave Rickey" <daver@mythicentertainment.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Sun, 22 Jul 2001 14:00:52 -0400
Organization: Kanga.Nu
-----Original Message-----
From: Dan MacDonald <danmac@windows.microsoft.com>
>> -----Original Message-----
>> From: Ted Milker [mailto:tmilker@radiks.net]

>> Hi everyone, I've been following the problems the Asheron's Call
>> developers have been having with a program called "GEAR".  There
>> are a lot of rumors floating around about how exactly this
>> program works.  The one explanation that sounds the most
>> plausible to me is that it plays with the speed of Window's timer
>> functions.  Does anyone have any concrete evidence that this is
>> the way it works?  Can someone explain exactly how Turbine
>> allowed this to happen in the first place?  I'm aware of the
>> first rule of network programming, never trust the client, and
>> surely they must have been aware of it too, so what went wrong?
>> I think it'd be very useful to the development community at large
>> to be aware of this issue and the pitfalls to avoid doing when
>> developing future games.

> Here's a link to Dr.Twisters Gear page. Apparently it works for
> other Games as well, essentially what it does is multiply the
> packets sent By the client up to 256 times, confusing the server.

To be more specific, it messes with the 18 tick per second system
clock used by all PC's to figure out when "now" is (this is entirely
separate from the bus and processor "clocks", which are used to
synchronize data transfers internally, this is the only true "clock"
in the computer).  This is one of the most standardized pieces of
legacy technology in the system, dating back nearly unchanged to the
original IBM 8080 based systems.

Basicly, the PC thinks time is passing 2, 4, 8...256 times as fast
as it actually is.  Everything synched to this real-time clock is
therefore done that much more often and that much faster.  One of
the consequences (and the only one easily detected by the server) is
a drastically increased packet rate from the client.  However,
anyone relying on this behaviour for detection should consider that
making the system drop most of the excess traffic is entirely
possible.

I might add, on many motherboards this can be changed in hardware,
although it would take much more technical knowledge to do than it
takes to run the GEAR software (it would involve bypassing a few
pins on the BIOS).

--Dave Rickey

_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev