# Realistic 'hacks' that programmer may exploit in a brand new FTL comm system that was not securely written?

In my world one company has had a monopoly on FTL comms, making large beacons in each inhabited system. This company has worked to prevent knowledge that smaller FTL comms were possible, in order to ensure their monopoly.

The system ansibles work by having a hard coded location and identifier for each comm, which were used to secure them. They only accept messages from known ansibles and generally are securable because the company is regulating every node.

Smaller shipboard ansibles were built as proof-of-concepts within the company at one point, only to be buried when it was decided the tech was a threat to their monopoly. As a incomplete proofs of concept, these shipboard comms were built without any thought to security. For example these comms, unlike the larger system comms, were built to use an ad-hoc registry system where each ansible could register itself with other local ansibles on the fly, but registered ansibles are not properly authenticated! These shipboard ansibles were also only able to broadcast messages within a system; they lack enough power to reach ansibles in other systems.

A certain group -- think of it as something like a large organized pirate fleet with some political extremist views -- has recently had schematics for the shipboard comms leaked to them. The pirates treat the ansibles as black boxes, not understanding the physics or code behind them, but are still able to build and deploy ansibles to their ships, giving them a major tactical advantage in fights where light speed delay usually makes tactics difficult to organize. Our protagonists have captured a small number of these ansibles and are trying to set up their own mini-fleet to resist the pirates'/fanatic group's aggression using them. This includes reverse-engineering the blackbox code of the ansibles to help create exploits to give their side tactical advantages in fights.

All of these battles are happening rapidly with both sides trying to reverse engineer, hack, and patch their ansibles quickly enough to take advantage of, or protect against, exploits as they're discovered, but there isn't enough time to fully learn the code or rewrite more secure code from scratch.

The underlying physics behind the FTL systems is not fully known by either side, and I intend to keep somewhat undefined intentionally to allow me more wiggle room for 'hacks'. So while I have some room to make the physics fit any exploit I like, in general I'm drawing parallels with early wi-fi routers as to how the ansibles function.

I'm looking for more potential exploits that both the hackers and pirates may utilize to gain a tactical advantage. A tactical advantage may mean hearing their enemies comms, 'blocking' their enemies FTL comms, knocking out both sides' comms when desired, replay attacks, whatever.

I'm looking mostly for exploits that both could be quick to write with partially understood code and, ideally, are also relatively quick to patch, so that both sides have to keep coming up with new tricks every few months rather than relying on the same exploit. To make it believable that so many exploits can be figured out so fast, I'm trying to keep a system analogous to the original ARPANET and wireless communication, with exploits being mostly reusing exploits that worked on the old Internet before more secure protocols were made standard.

The first exploit will be eavesdropping on enemy comms most likely, no encryption is built in after all. However, the enemy will figure this out quickly and will start encrypting their messages prior to sending them through the ansible, so that will be patched quickly. I'm more interested in exploits that will occur after that.

I already have a handful of exploits I like, including constant broadcast of gibberish to block both sides' FTL comms, and later one side stopping blocking at brief set periods to allow broadcast of comms during those brief open spots, etc. I'd like help coming up with more exploits to give me more options for what tricks I can have either side perform.

• Comments are not for extended discussion; this conversation has been moved to chat. Jun 27, 2017 at 17:49
• Use the FTL comm technology to send tactical information to the past, succeeding in every skirmish and mission attempted. That is possible because every FTL communication is a potentially time communication device, if the heroes manage to juggle the frames of reference correctly. Jun 27, 2017 at 20:25
• @11684 it entirely depends how far you're sending the message. The encryption is still going to take less time than actually reading the message. Jun 28, 2017 at 9:17
• For clarity: Ansibles connect to 2,3,4 etc local ansibles and then act like an 1980's style IP network with similar network/security flaws? Sounds fun. Jun 28, 2017 at 9:30

I'm going to take a look from the software perspective rather than abusing physics.

# Denial of Service/The Killer Poke

A malformed packet can be sent which confuses the hardware in such a way that it crashes or, at worst, causes damage. This actually happened with early CPUs, where certain instructions would allow one to release the magic smoke that allows them to operate. (What actually happened was that if you sent a bad instruction to the CPU it would open a line directly from source to ground, resulting in a short circuit that would burn out the CPU.) This was called the "Killer Poke".

# Changing Configuration

If certain malformed instructions allow external packets to access the ansible's configuration, you can change them to be anything you want. This could be a buffer overflow allowing arbitrary code execution, or in really badly secured systems, a request to upload a temporary file to a specific location that just happens to be the configuration file's location. Again, actually happens.

# Eavesdropping

If you use the above attack to change the configuration of the ansible, you could have it redirect all communication to a particular ansible, which will then forward the communications to the intended recipient, while recording the message for later use. This would be a Man in the Middle attack and would likely be difficult for them to notice.

# Abuse the developer tools and updating functionality

Since this was a prototype, the developers would have had several hooks for debugging and software deployment. At the very least, there would be a way to update the firmware/operating system. If it's not secured, you can easily wipe/update the firmware. Possibly remotely, or perhaps a mole would be necessary for physical access (would be a very suspenseful part of the story). If there's debugging commands, they will allow the attacker to view or even change memory and live communications.

• I like the developer tools point, I had not yet thought of that. i also appreciate your focusing on hacks that work even if they start to encryption, it seems allot in the comments got too focused on hacking the encryption and not on the other issues that are exploitable. Jun 27, 2017 at 13:01
• Combining the last 3 -> Giving people chatroulette instead of their intended recipient Jun 27, 2017 at 21:44
• An instantaneous comms MITM attack... That would be pretty hard to notice! Jun 28, 2017 at 10:27
• @Izkata this may be a war with both sides trying to kill each other, but still forcing someone to interact with the sort of people on chatroulette is just wrong!! :P Jun 30, 2017 at 14:29
• @dsollen I was thinking more like TVTropes's Distracted by the Sexy Jun 30, 2017 at 14:42

The obvious one to try, without needing to know anything about the software: back-time signalling.

Just play around and see what happens when you try to communicate between a bunch of different ships moving at different relative velocities. Do both sides of a conversation experience the other as being slowed down when the ships are moving? Then you can set up a cyclical transmission that moves information backwards in time, bouncing data back and forth between two ships. Is the signal pinned to the proper time of whoever initiated the call, or whoever received it? Then the time with which you are communicating with the other ship can slowly drift away from the present, so again, one side or the other can send information backwards in time.

If communication is truly instantaneous going both ways between any pair of ansibles, then there is some way of arranging for backwards-in-time signalling. Software may have been written to adjust for that, in which case I would expect the hackers to be trying to find a way to turn the adjustments off, because getting back-time signalling would be a huge tactical advantage. If the fundamental physics disallows backwards signalling, then it can't be instantaneous for all communication channels, which means that ships moving in particular ways will have disadvantages in tactical communication, and the hackers will be able to perform experiments to determine whether any restrictions on back-time signalling are in fact merely software protections, or fundamental to the physics of the device.

• Comments are not for extended discussion; this conversation has been moved to chat. Jun 27, 2017 at 17:48

Without any thought to security? Oh boy.

The most prominent security features that will be absent are:

• Encryption
• Authentication
• Data sanitisation

That lets you do next to anything.

# Missing Encryption

Depending on how your FTL signals are sent, this might allow you to intercept transmissions. There are three basic categories in which I'd separate FTL signals:

This would require the most energy (conventionally scaling with m * r^2 where r is the radius of the sphere in which you want to broadcast and m the message length), but also the least amount of configuration. You just send everything everywhere. Since it's unencrypted, anyone can listen in.
• Directional antenna.
You calculate the relative position of your receiver and broadcast in that direction. To cope with ships moving at high speed, this system would have to be very sophisticated, but it would require much less energy (only m instead of m * r^2) and it would only be interceptable by someone directly in the path between the transmitter and the receiver.
• Quantum entanglement.
This would allow for no interception whatsoever (at least on the signal level), but would take an insane amount of work to set up. Quite frankly, I have no idea how much energy it would take to run them.

You also name jamming (your "constant broadcast of gibberish") as an element you like. In that form, it would only work with the first two, but you could still fall back to a Denial-of-Service attack for all of them. By itself, a DoS would only impair the victim side, but you could easily explain both sides being disabled by either:

• having the other side "shoot back" as soon as they detect a DoS
• the DoS'ing being so intensive that they require all ansibles at full power, so you'd be too busy DoS'ing to have any capacity left to "talk".

Missing encryption is quite hard to fix once and for all for a team who doesn't really understand what they're messing with, but short-lived mitigations would be simple enough. Basically any change to the encoding (think Cesar Cipher) would render the other side unable to understand the intercepted information. It probably won't take them long to break the encoding, but maybe long enough for the message to become worthless (e.g. because the attack already happened). And it would IMO fit nicely into your game of cat and mouse. :P

# Missing Authentication

If you don't know who you're talking to, can you trust them?

Attacks on a human level:

Incoming transmission:

This is Captain Borg Zerk, we have located a primary rebel hideout on planet 753-KV44. Planning to attack in 3 hours, requesting assistance. Coordinates of proposed rendevouz point attached.

Except that message was sent by protagonist Herp Derp, and the coordinates are inside a neutron star.

For text transmissions this is dead simple, and for video/audio, you can just intercept some transmissions, take out your epic photoshop skills and fabricate such a message. Live conversations might be possible, but only with a real lot of engineering.

Attacks on a technical level:

A fun thing you could do would be a deauthentication attack. Basically you send a signal that marks the end of someone else's transmission. If that someone is currently talking, they'll be interrupted and have to re-dial. If you do that every 5 seconds, they can't establish a transmission.

Another fun thing would be a slow loris attack. Let's say your device can have 100 open transmissions at the same time. You open 100 channels to someone else, and bam, they can't have any more transmissions. And since there is no authentication, they can't just "block" you without blocking everyone else too.

Missing authentication would require some effort to fix, but I'd argue that would be feasible.
If you want implementation details: Assign a different secret to each node, which all other nodes know about. Then when you have an incoming transmission, you send back some random data to the transmitter, which they then append to their secret, hash it (sha512 or so) and send it back. You do the same computations locally, and can verify who you're talking to. Such a hash cannot be fabricated without knowing the secret, and the random data prevents hashes from being captured and re-used.

# Missing Sanity Checks

This is the real deal, but it gets very technical here.
If you don't wanna read the next paragraph or don't understand it, just skip to the "TL;DR", I won't blame you. ;)

Okay, here goes:
In your transmission protocol, you're gonna want to split up your data into frames (so that you don't have to slap metadata onto every byte, and to make it possible to process the data in parts). In software designed without security in mind, a function would most likely have a fixed-size buffer into which it reads the data, and after that buffer would be the address of the code where to resume after the function is done. Now, if the function does not check whether there is more data in a frame that it can store, it will start overwriting the return address. This lets an attacker alter the program flow and, through that, run arbitrary code.
This is just one type of vulnerability to arise and probably the simplest to exploit; there will be ones that are more complex, but altogether there's gonna be loads and boat loads of them.

TL;DR: Missing sanity checks let you run arbitrary code on receiving devices.

Since neither side really understands the ansible, it sounds unlikely that they would be able to interface it with the board computer, so the rest of the ship should be safe.

But for the ansibles themselves, this is fatal since it gives an attacker complete control over the device. You could install spyware, lock up their system (rendering them unable to send an SOS), or try to overclock and fry some hardware parts, possibly even starting a fire or electrocuting the people in immediate vicinity.

Such attacks would require quite some time and knowledge the develop and execute (which would mean they're only feasible later in the story, once a team had to work on the devices quite a number of times, and has gained intimate knowledge at least about parts of it), but that is good since they also give you immense power.
Spyware could go undetected for a very long time, and even if the victim knew there was one, it might take them quite some time to find, and even more to remove it.

The only way to fix such vulnerabilities without re-designing the entire system from scratch is to patch each and every one of them separately, once you learn of them. This will provide you with enough bugs to be exploited for decades, possibly even centuries.

• Did you mean $r^2$ rather than $r^3$, or are you assuming that FTL signals spread out in all directions of time as well as space? If that's the case, I expect interference from transmitters in the past and future to be a major problem! Jun 27, 2017 at 2:24
• @LoganR.Kearsley I actually meant for the third dimension to be the message length, but didn't think it through when writing down the formula. Thanks for pointing it out. :) Jun 27, 2017 at 2:29

First thing that occurs to me is the equivalent of ARP spoofing. You said it'd "use an ad-hock registry system where each ansible could register itself with other local ansibles on the fly" -- so have one ansible register itself under the ID of some opponent's ansible; when it gets a signal, it forwards that to the actual target (after recording and maybe modifying the content). If possible, it'd also register itself with the target under the source's ID, and do this to both directions of the conversation for a full man-in-the-middle attack.

Note that this is useful even if the opponents are using secure encryption over the channel, because you can do traffic analysis (who's talking to whom is often informative). Actually, depending on how you make them work, this might be possible even without a MITM. If that's the case, there are possible countermeasures like sending dummy traffic and sending traffic by indirect routes.

## Using the FTL communication to steal information from other computers

First, some articles:

It should be obvious from the above articles that it's definitely possible to use a system that is not connected at all to read classified information on another system. As a security hobbyist, I would not at all be surprised if you could listen to tiny fluctuations in the FTL comms to figure out what happens in other systems.

## Using comms manipulation to interfere in other systems

There will likely be some kind of automated interaction between the FTL comms and the rest of the ship, even if it was just sending certain signals on a hidden channel. Things like transmitting ship locations to radars, coordinated jump routines, weapon synchronization,... Besides sending fake messages to these systems, you can also send messages that can break systems. You can tell weapons to overheat, crash radar systems, shut down the engines,... This depends on the amount of automation that happens over these systems.

Pulling unencrypted data from the ansible makes sense as the very first attack and the very first patch. However, even encrypted data can be revealing.

## Injection

An attacker may be able to inject data into your stream that might mess with it in several ways:

• Exploit known parsing bugs to make the receiving system crash or exploit some other part of the receiving system (one protection against this kind of attack is to authenticate the sender and use a time sensitive identifier or sequence number so that authentication can't be easily intercepted and spoofed)
• Determine information about the message by it's length or frequency
• The very presence or absence of messages can tell a lot: that there is or isn't something to communicate. To protect against this attack, always be sending information
• The length of a message can expose information. A long message might convey that there is a lot to say. A long portion of information in the bits designated as the "to" field could indicate that the message is for the fleet instead of for an individual receiver. In particularly poorly implemented encryption, you might be able to identify the sender or receiver by the length of their encrypted call sign. To protect against this attack, all packets should be of the same length, but this doesn't protect against:
• The frequency of messages can expose information. Sending many different packets at once can expose similar information as length of packets. In some cases such as voice data, a conversation can sometimes be reconstructed based off of the frequency of messages being sent. Because audio is typically sent in real-time (particularly in the case of a technology centered on the timeliness of information), audio is particularly susceptible to these attacks. To protect against this attack you may need to add a latency to communication and always send messages of a fixed length, even when nothing is being said. Another interesting defense might be to embed a real conversation inside of a fake one: a prerecorded and harmless (or misinformative) conversation's rhythms are used to transmit the actual encrypted voice data. This would be an excellent defense not only because it misinforms but also because it hides the fact that you are aware of the exploit from your enemy. For example, if the protagonists have been reconstructing conversations this way for a long time, then protecting themselves from such an attack by sending signals of fixed length might give their enemies a reference point as to when the protagonists uncovered this exploit and therefor which information has been compromised. However, if a spoofed conversation's rhythm is used, then this hides the fact that the protagonists have this knowledge. This could also be used by the protagonists as a "canary in a coal mine": the protagonists broadcast relevant and timely misinformation and once the protagonists witness the enemy responding to this misinformation, they know at which point in time the enemy has become aware of the exploit, and therefor the protagonists know at which point to become suspicious of the conversations they themselves are reconstructing.
• Blocking signals. If an attacker has access to the network you're using (or it's done "over the air") there's little you can do to defend your network from being jammed altogether. Some interesting aspects of this problem are that the attacker would need to be able to broadcast the jamming signal either from close enough to the target, or from some place in between the target and the receiver/sender. Also if there are multiple ansible frequencies then jamming might require more than one ansible depending on the technology. It would also require more power to jam more frequencies, either limiting the time it took to jam a signal from the start of the target's broadcast, or limiting the amount of space you could cover with your jamming signal, or limiting the number of frequencies you could jam at once.

## Triangulation

The position of a sender may be discovered by detecting the strength of the signal sent and thereby triangulating their position. There are many ways an attacker might carry out this exploit. Here are a few:

• A single ship could triangulate a sender's source by simply moving around space as signals are being sent. This would require the target to remain relatively still and would also require them to be sending multiple signals. The number and frequency of signals needed would really depend upon the accuracy of signal-strength info (for instance, if a certain strength very reliably corresponds to a specific distance, then it's easier to triangulate. If there's variables that might introduce interference, then it becomes more difficult), and it would also depend upon where the attacker's ship was in relation to the target.
• Many ships coordinating together could determine a target's location by intercepting a single transmission. One downside of this method is that all of the attacking ships would be similarly exposed because they would also need to communicate over the ansible in order to convey this information to each other.
• A single ship could deploy probes which did all the work for them. As an added benefit, the probes can then broadcast the information they receive, meaning that an attacker's ship can be receiving this information instantaneously without broadcasting their own location (since they do not need to send any signals in order to instantaneously triangulate a position in this case). Of course this solution might be very expensive and dangerous if ansibles are rare: it would be a significant risk to float your ansible out there on a defenseless probe, especially if your enemies also have the ability to triangulate positions.
• One possible defense to this attack would be for the defender to transmit ansible signals from a secure location which they don't mind their enemies knowing, like a protected fortress. From this location, the ansible can be used in one direction only without giving away the location of the receivers. If the directionality of the ansible signal can be manipulated so that it's broadcasting in a single line or cone instead of to all surrounding space, then defending ships could also relay signals back to this secure location with a certain level of protection against triangulation: you would need to be much closer to triangulate a directional signal, or happen to be positioned between the receiver and sender (in which case you probably only need to receive a single such message in order to determine the location of the target, with very high accuracy).
• A defender could also deploy decoy signal senders if they could afford it.

## Real security arms races

One important thing to remember in all of this is that technology arms races do not occur if enemies are unaware of each other's capabilities. One great example of this is the Ultra machine which cracked Enigma in WWII: the cryptographic arms race did not continue on the German side after Enigma because the Germans were unaware that their signals had been cracked.

When it comes to modern computer security, the arms races which we know about continue because of the very public nature of these defenses and exploits. Defenses (like hashing algorithms) are often published because it is thought that the defenses lost through publishing source code (mainly the advantages of "obscurity", which are questionable), do not outweigh the benefits gained. Other people who are interested in your technology can then read the source code to double-check it for you. When you get a lot of people trying to scrutinize the security of a defense, it's thought to be much stronger than if only a few people were relying on their own limited expertise and the obscurity of their code.

Likewise, attackers tend to sell or share their tools. Often attackers don't even bother hiding their tools at all because they know that the average target either aren't computer literate enough to know to look for and protect form such exploits, or because even when the average target knows about the exploit, they're not likely to do anything about it. A great example of this is that people often reuse their password. Users know that this is bad practice and that it means their password is only as secure as the least secure service they use this password for, but they do it anyway.

In the case of an incredibly rare and valuable technology like the ansible, however, many of these exploits would go totally undetected, particularly "quiet" exploits like triangulation.

Hiding the fact that you have certain information can be it's own security challenge. For example, even though your enemy cannot detect via the ansible that you are triangulating their position, if you always go right toward their position every time they send messages, they'll pick up on it pretty quick. So to mask that you have that information you will need to act like you don't have it more often than not.

My advice is not to make the enemies/heroes too smart to the advances of the other, particularly in the cases of exploits which aren't easily detectable like triangulation or reconstructing speech based off of the rhythms of voice data.

• I very much like your point about hiding what what you know. Everything else is good as well, thank you. Jun 27, 2017 at 23:13

Since you might be looking for less sophisticated techniques that a bunch of pirate hackers could come up with, I suggest adding a Distributed Denial of Service attack to their arsenal.

In ambush situations, in order to keep the enemy ships from immediately phoning home, all of the pirate ships could simultaneously flood the enemy ship's communication systems with messages. In a naive communication protocol, the ship might try to send ACKs (Acknowledgements) to each sender, resulting in congested bandwidth (if your FTL system has such a notion) or overloading of the onboard computer systems and memory buffers.

Doesn't take much code to rig it and the pirate ships could even coordinate the flood manually.

If more than one ansible rig can be placed on a ship, they could even retrofit one of theirs into a specialized Electronic Warfare ship.

This combines several concepts present in the answers already given, but I think it is an idea worth its own answer because it relies heavily on the FTL part.

With sufficient hand-waving, a FTL communication system could be used to make a self-amplifying attack.

In the context of DoS attacks, an amplifier is a third-party machine which can be used as a relay to increase the number of packets that reach the target: if there is a setup in which you can send one packet to a third-party machine and have it send three packets to the target, then you can send three times as many packets to the target as you would be able to do alone. This is called an amplification attack.

With backward-in-time communication, a system could be set up to act as its own amplifier, with a snowballing effect: you send a signal back in time to your machine, and this has the effect of eliciting three packets from the machines. Then each of these sends a signal back in time again, and collectively they produce 9 packets. These 9 signals become 27 in the next loop, then 81, and so on.

I think there are some factors here that people are missing.

If by FTL you mean faster than light, then you are proposing a system that doesn't send or receive transmissions in a way anything like what we have now.

You cannot send a message by making a wave or particle travel faster than light, you break the laws of physics that way.

Now that isn't to say that communication at the effective Equivalent of FTL isn't possible.

So....in really, really handwavy terms.... In theory, using Quantum entanglement or something like "direct counterfactual quantum communication" solution then, in theory you could get instantaneous communications between two linked quantum particles.

With a Quantum entanglement The side effect of this is that there is literally nothing to intercept, in fact unless you intercepted the message at a device before the message is sent or after the message is received you wouldn't be able to intercept at all. You can't introduce noise, or interference... you might be able to break the entanglement bond. Thats assuming the end points are entirely secure...

You might be able to build a man in the middle attack, if you had access to Both ends of the path without the owner knowing, you could setup some kind of relay... but not possible without having access to both ends, without the real owner knowing.

If you used a system that allow for quantum entanglement at a distance, you could possibly disrupt or intercept and do some kinda of man in the middle attack during the formation of a "connection".

I guess another SciFi type solution would be to somehow send a signal outside our particular universe, and have in travel in another universe that has a different set of physical laws and therefore be able to go the effective equivalent of faster than light ( without actually going FTL). In theory there might be something to intercept there perhaps?

OR write your own laws of physics... it is your world. Perhaps a certain type of energy fluctuation allows for the detection of a communications channel as it moves into and out of a inter-spacial pocket.

OK, so we're treating the ansible network like an 1980's or early 90's IP network.

Each ansible passes on packets similar to an IP network with similar weaknesses to the historical internet.

History has some fun examples.

https://en.wikipedia.org/wiki/AS_7007_incident

Sometimes you just want to break the other guys system. So connect to the network and use something like BGP to advertise that you have the best route to absolutely everything and everyone. Suddenly your node is a black hole in the network and communications break down for most other nodes.

Good if you want to screw up their network mid battle.

As a version 2:

You can do something similar to cut off just their command ship mid-battle. Advertise that you have the best route to a particular node. similar to this event: