Re: Open Source Games and Cheating - a paradoxum?
On Tue, Jan 21, 2003 at 01:42:52PM -0500, H. S. Teoh wrote:
> This is a legitimate problem, but I disagree that licensing is the answer.
> This is a technical problem which requires a technical solution, not a
> licensing solution. I am sure there are already many open source
> multiplayer games that address this issue in some way. Maybe somebody who
> knows the details can speak up.
I think his proposed solution is technical, not legal.
> > So we need an open source program or library (or even kernel module)
> > that checks for modification of itself and the main program (eg. sending
> > a MD5 hash to the server for comparision with a "white-list") as well as
> > changes from the outside (network traffic, /dev/mem, kernel).
This is impossible. If it's open-source, it's always possible to change
it to send what the server expects. If you're not allowed to change it
in this way, it's not open source.
Netrek makes an effort at something like this (at the user-space binary
level only): a generated encrypter is linked into binaries; if you
don't have one the server thinks is OK, it assumes you're using a
modified binary.
My first impression is that this is a little bit of closed-source inside
an open-source program (though an acceptable amount, for me).
My next impression is that this is akin to hiding a private key inside
the binary (it's generated code, but anyone can generate similar code
with different parameters). I wonder if this has ever come up on d-legal.
It's a tricky spot, I think. (I won't bother theorizing, though.)
(Of course, this isn't at all bulletproof; but see below.)
> There is no need for the client to "verify" itself this way -- I've said,
> and I'll say again, that the solution to hacked clients is, DON'T TRUST
> THE CLIENT. The game protocol should be modified so that only the server
> is ultimately trusted.
The entire point was that you *have* to trust the client to some degree in
many games.
Consider the simple game of seeing who can correctly respond to "Press
the letter %c" the fastest. How do you not trust the client to some
degree: to make sure it's really the user who pressed the key; to
compensate for network latency, and so on?
Network latency is also a general problem. If the user isn't supposed
to know that Joe is behind a wall, an ideal-world network protocol won't
tell the client he's there. However, our less than ideal Internet has
latency, so, for the game to be playable, the server usually has to tell
the client where a person is and which way he's moving if there's a chance
he'll be visible in the near future, even though the user probably shouldn't
know that.
Of course, even if the user's binary is closed-source and hard to modify,
this only helps so much; it's possible the user has hacked up his keyboard
drivers to send fake responses automatically. Even when a game is closed-
source, it's a losing battle--but it's one that closed-source games can
sometimes keep in check long enough for the game to run its course and for
gamers to move on to other games. Open source tends to lose by default.
Don't trust the client more than you have to, but in the real world, you
often do have to trust it to some degree.
--
Glenn Maynard
Reply to: