Hacker News Reader

Comment by _Microft | Hacker News Reader

Some sleuths repaired/decoded a corrupted video file from (the first?) splashdown of a Falcon 9 in the ocean a few years ago [0], so maybe someone is able to tease out some information from the recorded binary data as well? They only searched for obvious string data so far.

It's a different beast of course, as the structure and meaning of the data is basically unknown in contrast to the known format of a video file.

Maybe some meanings can be inferred, let's say that a value in the possible range of rpms of a turbopump is correlated with acceleration or so?

[0] https://www.nasaspaceflight.com/2014/06/recovering-falcon-9-...

View on HN

Video decoded here.

https://twitter.com/r2x0t/status/1370030702633312259

I'm interested in the ITAR implications here of the video. When asked about seeing the inside of the fuel tank during the crew demo mission Shotwell said no because it was covered by ITAR. This video clearly shows inside a tank.

Shotwell's comments are surprising since SpaceX has publicly shown that same interior tank camera view many times on previous webcasts.

I wonder if something was different about the demo mission?

Not sure about @r2x0t but @uhf_satcom is involved in some pretty amazing space rf projects, poke around their tweet history. Some crazy smart folks out there.

I'm kinda hoping they'll publish some specs about at least part of their transmission data, I mean given that it's not encrypted either means it's not critical, or encryption is too costly. I can imagine that commands the other way do have some kind of encryption.

There are no commands the other way. F9 flies entirely autonomous, including termination. Based on the FCC filings, I'm pretty sure it doesn't even have receivers.

There was a reddit thread from a guest lecture a few years ago that said that around T-1 they turn off all receivers on Falcon 9.

https://www.reddit.com/r/spacex/comments/lw6yk1/notes_from_a...

Those same notes mention that the flight termination system was unencrypted. Now it's autonomous.

More info on AFSS.

https://www.spaceflightinsider.com/space-centers/ccafs/autom...

I know the Air Force claims this makes it safer by avoiding the need for a range officer to make a time sensitive safety call but it’s not like there isn’t a precedent of software goofs in this area of software controlled termination

https://apnews.com/article/1d85f290e31cad8532636fcb576f4788

The launch termination system at least needs a receiver

The way the automated FTS works is essentially that the USAF blasts a "DO NOT BLOW UP" signal with a very high power transmitter to the FTS. If the FTS doesn't receive that signal, it triggers and then you have a RUD.

That sounds terrifying

True, but it’s the safest configuration because you want the default condition to abort. The inverse set up is less safe because there are more failure modes for a receiver to break, meaning if a abort command was sent there’s more chance it won’t respond. It’s like choosing a normally-open or normally-closed valve; you want the default (power off) configuration to be the safer one. Inadvertently aborting is safer than not aborting when you should have

I don’t disagree, but that is in fact how it works!

RUD: Rapid Unscheduled Dissassembly

I prefer the term distributed landing.

I’m hereby notifying you that I have now appropriated that term for my own future use. :)

Isn’t this only the case if the intent is for a range officer to abort? I.e., if this system is fully autonomous and on-board, a receiver wouldn’t be necessary?

What the OP seems to be saying is that the emergency abort system actually operates on a “lysine deficiency” basis: if the signal is no longer received, the self-destruct system goes BOOM.

I suppose this classifies as “fail-safe”, though if there’s folks riding on the tip of this large sharp shard with the explosive force of a small nuclear weapon I’d be rather concerned about radio transient interference and things like that.

In that case, is it not really autonomous? Who’s stopping the signal? I’m assuming the range officer?

When passengers are on-board, there’s generally a launch abort engine that is supposed to help them leave safely in a abort scenario

Yes

It does not. F9 FTS is onboard and entirely automated. There is no ground trigger.

I'd assume so. It's standard practice with space hardware to keep the downlink unencrypted, and secure just the command channel. Saves on complexity and power use (the latter matters a lot for satellites).

> that commands the other way

Does Falcon 9 even have a command channel anymore? The trajectory is preprogrammed, guidance and control is automatic, and the flight termination system is automatic as well.

People who code still make mistakes. There's got to be an override of some sort

The override is missing the droneship or blowing itself up.

Why the hell does there "got" to be an override. Humans are generally not good at doing hypersonic/supersonic aerodynamic modeling in their heads, especially remotely

`The override is missing the droneship or blowing itself up.` Disagree, that's not an override. That's a program written by a human programmer (who makes mistakes) that autonomously decides that something went wrong.

I would argue there has "got" to be an override precisely because humans make mistakes all the time and so there's no reason to think that an autonomous failsafe should work in all possible situations.

I don't know much about rocketry, but if it's true that there's no remote abort capability, that seems like a deeply misguided decision.

>> I don't know much about rocketry

There you go.

You are welcome to try and disagree with decades of rocket launch practices.

The range safety officer can blow up the rocket if the rocket veers off and is in danger of overshooting the safe area.

Otherwise, you know the reason why we launch over water? Since it doesn't goddamn matter after it clears the tower and clears the danger zone. It either blows up over water, and who cares, it lands in the water, who cares, or it blows up in the upper atmosphere, and who cares.

Also, the rocket blowing itself up is a reference to the fact that if it is going off course, there is damn good chance it will destroy itself since aerodynamic forces are calculated to a specific launch window with upper weather. If not following a calculated path, good chance it will rip itself apart.

Also many abort modes are disabled for the first few seconds in flight so a dumb human or computer wont accidentally trigger a abort after flight starts and blow up the launch pad

>> You are welcome to try and disagree with decades of rocket launch practices.

>> The range safety officer can blow up the rocket if the rocket veers off and is in danger of overshooting the safe area.

I'm confused. Am I not the one arguing for a remote abort command (which, so far as I know, has been standard practice for a while) and you, above, argue that rockets don't need one because humans are bad at modeling rocket aerodynamics?

> The override is missing the droneship or blowing itself up.

What if "missing the drone ship" means "hitting Chicago"?

I'm somewhat surprised to hear that there may not be a functional remote abort mechanism.

> What if "missing the drone ship" means "hitting Chicago"?

It doesn't and never will. The rocket is never on a trajectory that will hit Chicago (or any other populated area). The splashdown point of the ballistic trajectory is always over the ocean, until the final burn puts it on the drone ship or landing pad. If that burn doesn't happen for whatever reason, it crashes in the ocean (and that has happened in the past).

I don't know, if it launches sideways and starts heading for a crowd they might want to force it to blow itself up or something like that.

SSH into the rocket and restart services?

> kubectl rollout restart deploy spacex-falcon9

> kill -9 1

you are confusing encryption and signing

>> commands the other way do have some kind of encryption.

I'm betting that they don't. The reason that this stuff isn't encrypted is likely the same reason that fighter jets and airliners don't have keys. Yes, someone could jump in and do something bad, but the greater danger is the encryption/lock system causing an accident by getting in the way of legitimate commands. This is the launch vehicle, not the spy satellite.

It is likely that physical realities offer sufficient protection. The rocket might be designed to ignore commands coming from the wrong direction and/or signal strength. It might be that to send a command you would have to be physically co-located with the legitimate antenna array, or be ridiculously more powerful, something that would be very easy to detect.

> Yes, someone could jump in and do something bad, but the greater danger is the encryption/lock system causing an accident by getting in the way of legitimate commands.

That's just not how encryption works...

Also, a malicious actor being able to point a multi-ton rocket filled with explosive fuel the wrong direction would be far worse than the system continuing the mission autonomously.

Now imagine human spaceflight missions where the command stream can be hijacked by anyone with an SDR. Yeah, not happening.

The command stream better be authenticated, and if you're doing cryptographic message authentication, you might as well encrypt the payload so no one else can read it anyways.

> The rocket might be designed to ignore commands coming from the wrong direction and/or signal strength.

You want to talk about something error prone "getting in the way of legitimate commands"? That would be an unbelievably error prone approach. Oh, the rocket accidentally rolled on its axis a few degrees? Ignore all commands to correct it!

Encryption and authentication are extremely reliable.

> Now imagine human spaceflight missions where the command stream can be hijacked by anyone with an SDR. Yeah, not happening.

I am no expert on spacecraft command channels but I would highly doubt that a lot of non military US spacecraft use encrypted command signals until extremely recently.

He is right. Space engineers are extremely adverse to trying new technology and technique. They are even more adverse to adding code to things that work without adding more code.

In order to talk to one of these things you have to have one of the satellites in the NASA DTN. Technically the DTN protocol supports authentication and encryption but remember that everything about DTN must maintain perfect backwards compatibility with space assets that are made with decades old technology. Security is not it's primary goal like with terrestrial communications. Connectivity is far more important.

Some US hardware also operates on frequencies that do not penetrate the atmosphere, an old failsafe against ground-based interference/spying. So, even if totally unencrypted, the attackers SDR would have to be in orbit. That's a high barrier for the average hacker.

Well yeah, but the actors that can overcome that barrier are likely the ones you're most worried about in the first place.

So maybe it limits number of adverse actors that can attempt anything, but it doesn't allow you any shortcuts in system design/security.

I've always assumed that frequency barrier stuff was more about defense against tactical, air based electronic jamming/countermeasures.

ETA: Thinking about it some more, what you describe seems like a slightly different type of security by obscurity. If you're relying on it for security.

Obscurity is about hiding amongst the noise. I describe physical network separation, essentially air-gapping. Do we encrypt the signal between a car's brake pedal and the brakes? Why not? It is a very important network that could result in loss of life. We don't encrypt because the network is physically separate from attackers. If they are tapping into your car's internal wiring then they could kill you in any number of easier ways. A rocket tuned to only listen to emitters from specific locations need not encrypt because it is also physically separated from potential attackers. So in high-reliability systems if encryption/authentication only offers protection in hypothetical edge cases where the attackers is co-located with controllers, but presents any additional complications, it won't be employed.

>We don't encrypt because the network is physically separate from attackers.

Given the existence in modern vehicles of:

- a shared bus for communication amongst the processing units

- autonomous emergency braking being fairly standard

and

- network connectivity being available in some cases

I think your analogy might be outdated.

>> spaceflight missions where the command stream can be hijacked by anyone with an SDR. Yeah, not happening.

An SDR attached to some serious antenna hardware, enough to get into the sidelobe of an antenna pointed at the legitimate command network. As for rockets rolling, that isn't handled by ground commands. That sort of stuff it totally within the rocket's internal systems. The ground staff have very little control until the second stage has done its thing.

Reply on news.ycombinator.com