Re: Open Source Games and Cheating - a paradoxum?
On Tue, Jan 21, 2003 at 08:51:03PM +0100, Joachim Breitner wrote:
> Hi,
>
> Am Die, 2003-01-21 um 19.42 schrieb H. S. Teoh:
> > 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.
>
> No I don't (and now I notice I wasn't clear enough), but some companies
> might think so. If they could be persuated that open source is even
> better against cheating (better software, bugs found faster and faster
> evolving quality) they might think about open source and maybe own money
> by providing a network of servers - just a scenario that crossed my
> minds)
Perhaps it's just a matter of convincing them that creating a network game
protocol that trusts the client is not a good idea? and that it's possible
to create protocols that only trust the server?
> > 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.
>
> That, of course, is the most elegant, efficient and simple solution. But
> it is not possible in every case - how would you defend against some
> kind of bots?
Technically speaking, there is no way to tell if a remote client is a bot
or just a really, really talented and dedicated gamer. (OK, there are
heuristics to check for blatant signs like microsecond think-time, which
may exhibit itself as "jittery" movement. But every heuristic you come up
with can be defeated by a smart-enough AI.)
This may or may not be a bad thing -- what if the game will be greatly
enhanced by bots? For example, in online RPGs, if I were playing the role
of a shopkeeper, I could write a bot that simulates the minimal
shop-keeping functions I do, so that people can still benefit from my shop
when I'm not logged on. Or I can run a clown bot that goes around as
entertainment. Why should the server take sole responsibility for NPC's?
Of course, this is dependent on the nature and purpose of the game. In
some games bots may not be desirable, but I'm not sure if there's a
feasible way to distinguish a client driven by a bot from a client driven
by a human. Both look the same to the server.
[snip]
> > This is a legitimate problem, but I disagree that licensing is the answer.
>
> This would just be an example of a semi-open way which would (might)
> reqiure different licensing. This (bad) solution is still a close source
> obfuscated anti-cheat part, but at least the game could be open source.
But that doesn't solve the problem at all. Licensing only sweeps it under
the rug AFAICT. Besides, we all know how effective strict licensing is in
the hands of users. Just having a license doesn't mean it will be
enforced. People can still run hacked clients.
> > 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.
>
> Now if that would work (probably would not), why not use the same
> process for the client authenticating itself as "legitimate" to the
> network?
[snip]
Unfortunately you're right that it would not work. A hacked client or
server can easily keep a copy of the "real" client/server, and just do the
checksum against that to obtain a checksum that looks legitimate. After
all, theoretically a hacked client can do anything the hacker wants it to;
there's no way to ensure that the checksum is actually done on the running
process. No matter while complex your checksum mechanism may be, the
cheater can just run a real client, connect it to the hacked client, have
the hacked client forward the key from the server to the real client,
return the checksum to the server, and then take over.
Basically, you cannot trust anything on the other side of the network.
With servers, the problem can be alleviated somewhat because there aren't
as many server admins as users, so you can say you trust only specific
people to run a non-hacked server and only allow them to connect to you.
But even then, there's nothing physically stopping the "trusted" person
from running a hacked server.
I don't know if any solution even exists for this problem.
T
--
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Reply to: