I've been studying the potential for spoofing attacks against helpers and scripts. The vector for a spoofing attack is any context where player-entered text is displayed to other players. Naïve scripts can be fooled by things like Fedcomm messages or beacon text, but detecting spoofs is relatively simple as long as the player has ANSI on. I have found no instance where a spoof cannot be detected either by its preceding context or the ANSI codes it contains. In fact, I know of only one prompt that cannot be positively identified by its ANSI codes alone.
But everything falls apart with ANSI off. Some spoofs can still be identified by their preceding context, but there is one class of messages where player-entered text appears as the first thing on a line without any predictable preceding context. These are messages like "Mongoose warps into the sector.", and they can spoof any prompt under 41 characters in length. For example, is that "[Pause]" really a pause, or is it the beginning of "[Pause] warps into the sector."? A real prompt lacks a trailing newline character, so without additional knowledge of the protocol there is no way to know if more text is on the way.
But there is still hope in additional knowledge of the protocol. If problematic messages like "[Pause] is hailing you!" are written to the network in a single write, then for all practical purposes it is guaranteed that they will be transmitted in a single packet. The minimum IPv4 MTU is 68 bytes (and in practice is usually much larger) so any message beginning with a spoof name would be guaranteed to have at least a few bytes of trailing context received with it. A "[Pause]" received by itself could then be safely treated as a real pause, as could all other spoofable prompts.
I've asked John Pritchett to determine whether this is the case. If it's not, then I have a few other ideas up my sleeve.
(Reposted from my blog.)
Good afternoon, everyone! Today I'm poring over the script APIs of the two leading helpers to make sure I am not overlooking any useful data that should be captured. My goal for today and tomorrow is to write the database classes to model all the important aspects of a TradeWars universe. Then I will turn my attention back to the lexer patterns that will capture the data.
Also on the agenda this week: setting up hosting for project downloads, and sending out backer surveys.
We're heading into the last weekend of the funding period, and I just need nine more $25 backers (plus an extra $1) to meet the basic funding goal. So before you head off to the beach or the mountains, please consider contributing a few more dollars. And of course, please continue sharing this project with anyone who might be interested!
I did some work on the script system this week, and I'd like to tell you about it.
Weapon M was originally the product of my own frustration with the scripting APIs of the other major helpers. I designed it from the beginning to be a master scripter's ultimate weapon.
Of course, I also wanted it to be user friendly. As you see here, scripts can give themselves names and organize themselves into menus, so that related scripts can be grouped together. They can also schedule timer events. This script just prints "Hello, universe!" every two seconds. More practically, you'd use this feature to schedule things like logging into a game at a particular time.
But what goes on under the hood is even more interesting. One of my major goals was to allow scripts to share data without interfering with each other. If two scripts try to send a command to the same prompt, you never know what might happen. This is a common problem with other helpers.
My solution is to temporarily lock the network whenever a script writes to it in an event handler. Consider this scenario: you have a script that drops fighters every time you enter a sector, and another script that periodically checks to see who is online. Both of these scripts are interested in the COMMAND_PROMPT event. Now, say you've just entered a sector, generating a COMMAND_PROMPT. The fighter drop script receives the event and determines that fighters should be dropped, so it sends the commands to do so. Then the who-is-online script receives the event and determines that it's time for an update. But when it tries to send a command, it gets a NetworkLockedException.
After all interested listeners have received the COMMAND_PROMPT, the network is unlocked and the parser begins reading text from the game again. It parses the results of the drop fighters command, which includes another COMMAND_PROMPT event. This time, the fighter drop script determines that nothing needs to be done. Then the who-is-online script receives the event, and now it is able to send its commands.
Scripts can also explicitly lock the network when they are about to send a burst of text that will generate several events. other scripts will still receive the events, but they won't be able to respond to them. Pretty sweet, eh?