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 if() 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 slightly. 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 situation. 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