News for hackers. Stuff that matters.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by _Microft on Thursday March 11, 2021 @08:55AM (#26424018)
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-...

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by drmpeg on Thursday March 11, 2021 @02:48PM (#26428210)
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by soapboxrocket on Thursday March 11, 2021 @05:56PM (#26430073)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by schiffern on Thursday March 11, 2021 @08:37PM (#26431325)
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?

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by jcims on Thursday March 11, 2021 @04:52PM (#26429476)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by Cthulhu_ on Thursday March 11, 2021 @09:54AM (#26424584)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by jccooper on Thursday March 11, 2021 @11:00AM (#26425424)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by darknavi on Thursday March 11, 2021 @11:48AM (#26426068)
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...

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by outworlder on Thursday March 11, 2021 @02:12PM (#26427791)
Those same notes mention that the flight termination system was unencrypted. Now it's autonomous.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by toomuchtodo on Tuesday March 16, 2021 @03:49PM (#26481936)
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by bumby on Thursday March 11, 2021 @04:08PM (#26429017)
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

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by gbrown on Thursday March 11, 2021 @04:50PM (#26429460)
The launch termination system at least needs a receiver
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by SEJeff on Thursday March 11, 2021 @06:29PM (#26430372)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by gbrown on Thursday March 11, 2021 @11:41PM (#26432283)
That sounds terrifying
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by bumby on Friday March 12, 2021 @01:12PM (#26438842)
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
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by SEJeff on Thursday March 11, 2021 @11:45PM (#26432302)
I don’t disagree, but that is in fact how it works!
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by qubex on Friday March 12, 2021 @01:12PM (#26438852)
RUD: Rapid Unscheduled Dissassembly
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by dogma1138 on Tuesday March 16, 2021 @04:03PM (#26482096)
I prefer the term distributed landing.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by qubex on Monday March 22, 2021 @05:08AM (#26538372)
I’m hereby notifying you that I have now appropriated that term for my own future use. :)
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by bumby on Thursday March 11, 2021 @05:24PM (#26429759)
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?
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by qubex on Friday March 12, 2021 @01:16PM (#26438909)
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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by bumby on Friday March 12, 2021 @09:49PM (#26443448)
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

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by gbrown on Thursday March 11, 2021 @11:41PM (#26432284)
Yes
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by jccooper on Friday March 12, 2021 @08:42PM (#26443124)
It does not. F9 FTS is onboard and entirely automated. There is no ground trigger.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by TeMPOraL on Thursday March 11, 2021 @10:21AM (#26424934)
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).
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by Denvercoder9 on Thursday March 11, 2021 @10:54AM (#26425341)
> 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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by ClumsyPilot on Thursday March 11, 2021 @11:14AM (#26425591)
People who code still make mistakes. There's got to be an override of some sort
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by NikolaeVarius on Thursday March 11, 2021 @11:47AM (#26426040)
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

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by matmatmatmat on Thursday March 11, 2021 @03:39PM (#26428749)
`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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by NikolaeVarius on Thursday March 11, 2021 @04:09PM (#26429034)
>> 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

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by matmatmatmat on Thursday March 11, 2021 @06:38PM (#26430443)
>> 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?

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by bigiain on Thursday March 11, 2021 @09:59PM (#26431795)
> 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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by Denvercoder9 on Friday March 12, 2021 @08:58PM (#26443203)
> 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).

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by ric2b on Thursday March 11, 2021 @06:29PM (#26430383)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by daniellarusso on Thursday March 11, 2021 @11:54AM (#26426151)
SSH into the rocket and restart services?
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by codeduck on Thursday March 11, 2021 @02:26PM (#26427939)
> kubectl rollout restart deploy spacex-falcon9
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by numpad0 on Friday March 12, 2021 @05:29AM (#26434156)
> kill -9 1
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by eeZah7Ux on Thursday March 11, 2021 @11:08AM (#26425525)
you are confusing encryption and signing
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by sandworm101 on Thursday March 11, 2021 @10:28AM (#26425017)
>> 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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by coder543 on Thursday March 11, 2021 @10:37AM (#26425113)
> 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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by zelon88 on Thursday March 11, 2021 @11:44AM (#26426001)
> 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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by sandworm101 on Thursday March 11, 2021 @11:46AM (#26426036)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by beerandt on Thursday March 11, 2021 @01:12PM (#26427097)
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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by sandworm101 on Thursday March 11, 2021 @02:08PM (#26427741)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by perl4ever on Friday March 12, 2021 @07:42AM (#26435167)
>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.

Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2... by sandworm101 on Thursday March 11, 2021 @11:40AM (#26425951)
>> 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.