Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

rtl-sdr.com

Post reply on HN
Print view View original

61–70 of 114 posts

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#61

Post by sgtnoodle »

marcodiego wrote: post #16

How likely is the possibility of sdr freeing us from wifi chips or cell modems that need proprietary firmware?

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.

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#62

Post by ceejayoz »

sandworm101 wrote: post #59
ceejayoz wrote: post #58

Earlier quoted context omitted.

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…

> 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.

There's a good, detailed explanation of how hard stealth in space is at https://worldbuilding.stackexchange.com/questions/23313/stea....

There've been efforts towards stealthier craft. https://en.wikipedia.org/wiki/Misty_(satellite)

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#63

Post by beerandt »

sandworm101 wrote: post #46
zelon88 wrote: post #45

Earlier quoted context omitted.

> 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 addin…

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.

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#64

Post by marcodiego »

sgtnoodle wrote: post #61
marcodiego wrote: post #16

How likely is the possibility of sdr freeing us from wifi chips or cell modems that need proprietary firmware?

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. Th…

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.

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#65

Post by Rebelgecko »

mikepurvis wrote: post #26
verelo wrote: post #9

Earlier quoted context omitted.

Encryption takes time, and energy. I suspect they are trying to avoid adding latency to anything that’s not super sensitive.

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 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

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#66

Post by 0xdeadbeefbabe »

Cthulhu_ wrote: post #20
ceejayoz wrote: post #14

Earlier quoted context omitted.

Amateur astronomers are very good at spotting national security payloads after launch. https://www.theatlantic.com/technology/archive/2016/06/mappi...

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 proba…

> And if amateur astronomers can do it, a well-funded national space agency can do it even better.

This confidence in agencies and funding is puzzling to me.

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#67

Post by sandworm101 »

beerandt wrote: post #63
sandworm101 wrote: post #46

Earlier quoted context omitted.

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 s…

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.2m Satellite Dish

#68

Post by outworlder »

darknavi wrote: post #48
jccooper wrote: post #37

Earlier quoted context omitted.

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.

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#69

Post by codeduck »

daniellarusso wrote: post #51
ClumsyPilot wrote: post #39

Earlier quoted context omitted.

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

SSH into the rocket and restart services?

> kubectl rollout restart deploy spacex-falcon9

Re: Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m Satellite Dish

#70

Post by mikepurvis »

vardump wrote: post #43
mikepurvis wrote: post #26

Earlier quoted context omitted.

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.

You don't need any buffering if you pick your encryption mode correctly. That is, use a stream cipher.

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.
Post reply on HN