Re: Open Source Games and Cheating - a paradoxum?
On Tue, Jan 21, 2003 at 05:20:20PM +0100, Joachim Breitner wrote:
> Hello,
>
> You might wonder how this relates to debian. In my opinion, this problem
> might become crucial to Debian. It's games that awake computer interest
> and skills in young kids, and Debian needs them as volunteers. But if
> Debian can't offer popular games (i.e. online multiplayer games) because
> they have to be closed source,
Um, I'm not following the logic here. Why would they "need" to be closed
source? I'm assuming that you're equating "closed source" to "cannot
cheat". That's not really true, y'know. It just takes proper game design
so that the game *server* is trusted, but the game *client* is not. The
reason a lot of online games suffer from cheating or "hacks" is because
of bad design: i.e., trusting the game client.
Technically, anything on the user's computer can be modified freely,
closed source or not. Executable binaries can be hacked to cheat during
the game, just as much as recompiling a hacked client from source does.
(Yes it's harder to hack a binary. But it's still possible, and people
still do it.) Therefore, if you want a cheat-free game, what you *really*
want is not open/closed source, but a game design that only trusts the
server. There *are* some of those games around already, and they are open
source. Their being open source has nothing to do with whether players can
cheat.
[snip]
> My train of thought starts here: Open Source will not require local
> changes to the game to run and modified versions will have to to be able
> to connect to certain servers. But the mainstream which will get stable
> packaged versions must be stopped from running modified versions on
> public servers (the servers you usually play and where tournaments -
> partly with real money prizes - are held). So we need a way for the
> server to tell if the client is modified.
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.
[snip]
> 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).
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.
But of course, for multi-server games, this becomes a legitimate problem:
how to prevent a hacked server from joining a server network. One way,
based on your suggestion, is: every time a new server connects to the
existing network of "trusted" servers, to generate a one-time key, and the
new server must checksum itself using this key (something like MD5
checksumming but with the key incorporated as an integral part of the
calculation), and then send the result back to the trusted servers. The
trusted server then can verify if the new server is "legitimate". This
method also makes it difficult for a hacked server to fake the reply just
by caching what the "legal" checksum should be.
But ultimately, there is no way for an end-user to know if a given server
network is "trusted" or not, except by the network's reputation. There may
not even be a need for complex checksumming mechanisms; server networks
will live or die based on reputation. This also makes it possible to have
variant game servers, which may be patched or improved versions of the
"official" server. This is actually desirable in the open source world (If
the user doesn't like the changes, just log on to another network).
[snip]
> So basically we need a way for a server to know if the client is one of
> the versions that are "allowed" and if they are messed with in some way
> or the other.
There is no need for this. Just design a network protocol that does not
trust the client.
T
--
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all
I can take." -- Calvin & Hobbes
Reply to: