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?
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.
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.
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
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.
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
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.
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).
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.
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.
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?
> 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).
>> 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.
>> 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.
This is something I’ve always thought about doing, but lack the in-depth RF/demodulation knowledge to undertake. Glad to see the SDR community is already on top of it!
I wonder if this telemetry is also unencrypted for launches carrying sensitive government payloads? Very cool stuff though, rtl-sdr.com has been a great source of entertainment for many years!
People have been running full simulations of SpaceX vehicles just of on-screen telemetry and videos [0]. In the past, SpaceX has been very open towards these kind of efforts, they don't seem to mind at all.
Looks like this is just data from the GPS receiver, mostly about where the rocket thinks it is at the moment. This doesn't strike me as particularly sensitive. Data from, say, sensors embedded in the engines would be much more interesting.
And if amateur astronomers can do it, a well-funded national space agency can do it even better. I'm 100% sure that any launch is picked up via radar and sattelites and the like when they happen, and various properties extracted and extrapolated to determine their target orbit.
That said, I wouldn't be surprised if some known launches also contained some unknown payloads. Stealth technology on a satellite would probably thwart detection in space well enough.
> Stealth technology on a satellite would probably thwart detection in space well enough.
Stealth is great for radar, but even the B-2 can be spotted pretty easily via the Mk 1 eyeball. Satellites also have to have radiators, which limits what you can manage.
>> but even the B-2 can be spotted pretty easily via the Mk 1 eyeball.
It has a visual cloaking device too. It isn't terribly complicated. The bottom of the aircraft is a particular color. If you fly at an altitude that the sky above is the same color as the bottom of your plane, people on the ground cannot see you. So a tiny camera pointed up can be used to calibrate the altitude to best hide.
Also see counterillumination, a trick used by many sea creatures to hide from things below them. I doubt the B2 uses this but the military has studied it as an option in the past.
The article would seem to indicate it helps, but certainly doesn't get you all the way there.
> Modern stealth aircraft, such as the F-117 Nighthawk attack jet and B-2 Spirit bomber, are painted in matte black or dark grey and are flown at night to limit their visual signature.
Can't really do that in space; you've got a day/night cycle ever 90 minutes or so.
Space is black. Even in daylight, the background behind an object in space is always black (except when passing in front of the sun). A black plane against a blue sky stands out. A black satellite against the black of space does not. Or a blue plane against a blue background.
The F117 is black and only flew at night, at lower levels. The bottom of the B2 isn't actually black, more a dark grey with a bit of blue in it. And the top of the aircraft is more sea blue than black at most angles. Someone thought long and hard about those colors, about not just painting it all black like the F117.
> A black satellite against the black of space does not.
It sure heats up fast, though. Radiating enough heat not to roast the electronics is already an issue for satellites with shiny coatings to keep heat from the sun out.
The ISS is way bigger than a highly classified satellite, but I'd guess a lot of nation states have way better capability than some guy with a telescope in his back yard in New Zealand.
I really want to upgrade to Mk 2 eyeballs, maybe with some new receptors to see extra colours, infrared and ultraviolet. Maybe the capability to see polarised light too.
> Stealth technology on a satellite would probably thwart detection in space well enough.
I bet you could make a satellite look like a stray screw or fleck of paint with enough effort. Careful geometry and surface design can reduce the radar cross section to a tiny fraction; some ultrablack coating and judicious heat rejection could make it look effectively invisible to optical and IR. Power with an RTG to avoid glints and radar scatter from solar panels.
And I'm sort of geeking out thinking about how you could misdirect observers about the payload's path— release a very shiny dummy payload, and then release the real thing some time before or after. Or pull a Millennium Falcon gambit and release the actual payload from a disposed fairing or stage when no one's looking...
Maybe it's possible to detect radio echoes off the rocket exhaust trail (passively) like it is possible to do with meteors [0][1] and roughly tell where the second stage is (just for the sake of doing it this way).
I can't speak to SpaceX's decision, but in FCC rulings, they have proposed encryption when commanding vehicles, not for telemetry or tracking comms (satellites, specifically, although I'd assume similar guidance for vehicles, with the only command you're going to send to the vehicle would be boom for range safety).
For historical purposes, range safety on SpaceX vehicles has been autonomous and onboard since 2017. Vehicles emit telemetry, but do not receive commands.
Those final gasps of data while a vehicle is breaking up could be critical for understanding what went wrong with it. I can definitely see how missing out on the final milliseconds of telemetry because some encryption buffer wasn't full enough to trigger a frame or something would be unacceptable.
I think this is the true reason that telemetry is as raw as possible.
The happy-path telemetry tells you very little you didn't already know, but when something goes wrong, those last few bits before the transmitter went silent can make or break your analysis. Sitting on bits until you have enough to run a block through the cipher seems like a terrible idea, even if that's only a few microseconds.
Things happen mighty fast when you're trying to get data that might represent the structural collapse or propagation of a blast wave through the body of a hypersonic vehicle.
I think this is a very plausible reason. After a F9 blew up in 2016 or so, the NASA accident review even threw a little bit of shade because the telemetry right before the explosion was lost to bufferbloat
How much would that affect the ability to recover a partially-corrupted stream, though? I feel like that's part of this too— where the last few seconds might have an increasing amount of the content scrambled, and encryption would render that completely unusable, whereas having it in plaintext would still permit some degree of inference about the fragments you do have.
Might be some truth here. Although at this point automatically interpreting plain text data would fail as well. In both cases, you could add separating symbols in the raw data stream.
Also, timing should help here. Sure there can be gaps, but at a given data rate the receiving end should be able to compensate for it, as long as velocity doesn't have large unexpected changes (doppler). Even then it should be decodable afterwards.
There are a lot of ways you can compensate for any of these issues. That said, of course plain text is going to be the easiest option for a human to decode when everything else fails.
I have been curious on what it would take to do a Contact like signal fake. Would it be possible for a satellite to be launched into a direction in space that for all intensive purpose make it look like it is coming from somewhere else further away? Would it be easy to tell that it is originating much closer than what it is simulating? How far would it need to be away from earth before it was believable, and then would the fact the signal's source is constantly moving futher away be discernible from the signal itself? Basically, think along the lines of a fanfic premise told from Michael Kitz' perspective.
>> Would it be possible for a satellite to be launched into a direction in space that for all intensive purpose make it look like it is coming from somewhere else further away?
Anything is possible but it would be very hard. You would have to fake the doppler shifts. With massive scrutiny you might even have to fake some absorption lines. Then, if the signal was longer than a few days/weeks, you would need to place the emitter far enough away that parallax, relative motion against the stellar background, was undetectable. That distance is probably measured in light-years.
This is just a guess, but having read the FCC regs in the past, maybe it's because it's so much easier to be complaint when your link is unencrypted (and your rf standard published).
I imagine it adds latency, which at the very least means more data is lost in case of accident, which can make it harder to know what went wrong.
It also adds an additional failure point, as a single bit error during encryption can scramble an entire data packet or worse, rather than just invalidating a single sensor reading.
It would be cool but I don't see it happening any time soon. Plenty of demos have been created, but the ASICs that the SDR would be competing with are much more efficient at doing their particular job, and they're very cheap.
I vaguely understand that modern high performance rf chipsets are largely software defined anyway, which is why they require binary firmware blobs.
The modulations have gotten so complex that there's really no chance of a CPU or even a general purpose FPGA keeping up in real-time. Someone unencumbered by an NDA would need to be smart enough to design a specialty FPGA with the right sort of accelerators in silicon. They would also need to avoid any active patents.
Like pretty much anything, I imagine someone will figure it out for any given technology a decade or two after it's mostly obsolete.
Are patents a problem for software distributed in source code form? I don not think so. I remember something related to font hinting and apple patents that could be circumvented by simply uncommenting part of the code recompiling.
I specifically mean patents for the "generalized" accelerator hardware implemented in silicon that would presumably be needed to make a specialty FPGA that's fast enough to handle modern RF modulations, even in a vaguely software-defined way. That's presumably companies like Qualcomm's secret sauce, and you can bet they have it locked down with patents and NDAs. If someone came up with a general purpose CPU powerful enough to actually do everything fast enough purely in software, then that might be different (but would likely have plenty of its own patent issues!)
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-...