On 3/31/07, Zach <netrek at gmail.com> wrote:
> Hi Chris,
> That's great. I'm curious as to precisely how you determined a given
> player was using a borg in your judgement? Does anyone know of any
> borg bot code I could see?
> Zach

Combat features can be taken from the robot code in the server.  Info-borg
features are fairly trivial to add; showing cloakers on the tactical, or
army counts for all planets, for example, just involves commenting out an

Clues to the presence of a borg are it consistently responding to stimuli in
a distinctive fashion, e.g. autophasering at a set distance, or behaviour
that would be hard to achieve with real input, such as spamming torps in
multiple directions almost simultaneously.  Detecting infoborgs is harder,
unless they're helpful enough to send team messages or RCDs every time they
spot an enemy ship picking a planet.

An ethical borg developer (even playing on a non-RSA server) will change the
pigcall (5 spaces) response to identify their client.  A really ethical
developer will turn off the borg features when t-mode starts.

An unethical borg developer (on an RSA server) will use the pigcall of the
blessed client that he's using to spoof the RSA check.

As this is the dev list, I might as well detail how RSA spoofing works.
Anyone capable of implementing this is probably capable of figuring it out
as well, so I don't accept the proposition that obscurity brings security.

Trivially, the borg client performs a man-in-the-middle attack.  It opens a
listening socket (you can just swipe the server code) and both connects to
the real server, and accepts a connection from a blessed client (note: any
blessed client, running on any platform, not necessarily the same as the one
that the borg runs on) that you'll use to spoof the RSA check.  When the
borg client receives the RSA challenge from the server, it passes it on to
the blessed client, which dutifully produces the response, which the borg
client passes back to the server.  It can then just terminate the connection
to the blessed client.

The subtelty is that the RSA response encodes the result of a getpeername(),
to try and spot this MitM attack.  To defeat that, you have to ensure that
getpeername() reports (to the blessed client) that it's talking to the
server, not the borg client.  You can (off the top of my head):

Linux: recompile your kernel.
Solaris: provide a replacement .so that just implements getpeername() at
runtime when linked dynamically to the client.
Windows: provide a shim ws2_32.dll that overrides getpeername() and
otherwise calls (jmps, actually) to the real dll functions.

If blessed client developers want to make things a bit harder, then instead
of using getpeername() during the RSA check, instead encode the address that
the client was told to connect to (which should be the same as the result of
a getpeername()!).  This isn't foolproof, but would raise the bar very

The fundamental lesson of this though is that you *cannot* trust the
client.  Blessing will keep casual hackers at bay, but a determined cracker
will blow past the RSA check in a few hours.  The only real defence is a
design that assumes that the client is a robot, not a human.

The good news is that Netrek is actually pretty robust as-is!  Vector torps
just miss clue targets more efficiently, autophasering is subject to missing
under any amount of lag (even if you 'lead' the target) and can just waste
fuel if you get the algorithm wrong.  Flicking shields on and off under
threat conditions is only a minor efficiency gain (and subject to fatal
results if you snafu it), and clued players can det or dodge multiple
incoming torps more flexibly and effectively (i.e. with a better tactical
and strategic outcome) than an algorithm.

The biggest potential benefits are (tactically) showing cloakers on the
tactical (with irregular and inaccurate positions, heading and speed info),
and (strategically) identifying and marking enemy ships that have picked
up.  A dumb auto-ogger (turn + speed + tractor + phaser + torp + det) can
also save you some button mashing, but only under circumstances where a
manual ogg would have worked anyway.

IME, a borg will just raise the apparent clue level of a player, but only to
middling-competent.  An actual clue player will do everything that a borg
does anyway, and better, because they can adapt their response to the

That said, there are a few "info-borg" features that I feel might as well be
allowed, in particular showing army counts on-screen by default.  The
argument that this gives an unfair advantage over people playing with
traditional clients is spurious; there's no reason why all clients can't be
trivially modified to do this, and limiting all clients to the minimum
subset provided by the oldest client is a fine way to ensure stagnation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20070331/fcfd7dd9/attachment.htm