[HN Gopher] Receiving SpaceX Falcon 9 Telemetry with a HackRF an...
___________________________________________________________________
Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2m
Satellite Dish
Author : _Microft
Score : 211 points
Date : 2021-03-11 12:48 UTC (10 hours ago)
(HTM) web link (www.rtl-sdr.com)
(TXT) w3m dump (www.rtl-sdr.com)
| danbr wrote:
| 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!
| shmerl wrote:
| Does HackRF require soldering an RF shield to it? Apparently it
| comes without it by default.
| mastax wrote:
| No, but you can add it if you want a lower noise floor.
| shmerl wrote:
| I mean how critical is it? Just an improvement in quality or
| it's bad without it?
| myself248 wrote:
| Yes, both. It depends on what you're doing. Tractors don't
| need to be aerodynamic.
| MayeulC wrote:
| Lower noise floor = easier to grab low-power or distant
| signals. It really depends on your use-case.
| marcodiego wrote:
| How likely is the possibility of sdr freeing us from wifi chips
| or cell modems that need proprietary firmware?
| sgtnoodle wrote:
| 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.
| marcodiego wrote:
| 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.
| sgtnoodle wrote:
| 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!)
| newman8r wrote:
| 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.
| namibj wrote:
| The latter already exists, at least for LTE.
|
| Well, SDR-based clients that you could package in a smartphone
| form factor. They're fairly power-hungry, though.
| _Microft wrote:
| 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-...
| Cthulhu_ wrote:
| 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.
| jccooper wrote:
| 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.
| gbrown wrote:
| The launch termination system at least needs a receiver
| bumby wrote:
| 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?
| bumby wrote:
| 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
| darknavi wrote:
| 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...
| outworlder wrote:
| Those same notes mention that the flight termination
| system was unencrypted. Now it's autonomous.
| TeMPOraL wrote:
| 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).
| eeZah7Ux wrote:
| you are confusing encryption and signing
| sandworm101 wrote:
| >> 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.
| coder543 wrote:
| > 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.
| sandworm101 wrote:
| >> 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.
| zelon88 wrote:
| > 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.
| sandworm101 wrote:
| 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.
| beerandt wrote:
| 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.
| sandworm101 wrote:
| 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.
| Denvercoder9 wrote:
| > 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.
| ClumsyPilot wrote:
| People who code still make mistakes. There's got to be an
| override of some sort
| daniellarusso wrote:
| SSH into the rocket and restart services?
| codeduck wrote:
| > kubectl rollout restart deploy spacex-falcon9
| NikolaeVarius wrote:
| 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
| matmatmatmat wrote:
| `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.
| NikolaeVarius wrote:
| >> 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
| drmpeg wrote:
| Video decoded here.
|
| https://twitter.com/r2x0t/status/1370030702633312259
| jcims wrote:
| 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.
| soapboxrocket wrote:
| 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.
| koolk3ychain wrote:
| 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!
| ex3ndr wrote:
| I feel that this data is trade secret - why it is not encrypted?
| ylere wrote:
| 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.
|
| [0] Example for SN9:
| https://www.youtube.com/watch?v=UeBtBidjlvk |
| https://flightclub.io/result?code=SN91
| gmueckl wrote:
| 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.
| rrmm wrote:
| If they were carrying a national security payload, then
| having a gps feed of the second stage trajectory and target
| orbit would be less than ideal.
| stevehawk wrote:
| you can't classify something in the public eye
| ceejayoz wrote:
| Amateur astronomers are very good at spotting national
| security payloads after launch.
|
| https://www.theatlantic.com/technology/archive/2016/06/mapp
| i...
| rrmm wrote:
| Yup. Easy to do for most adversary nation-states as well,
| but the NRO still doesn't allow the SpaceX livestream to
| follow stage 2.
| _Microft wrote:
| 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).
|
| [0] https://www.electronics-notes.com/articles/antennas-
| propagat...
|
| [1]
| https://en.wikipedia.org/wiki/Meteor_burst_communications
| ceejayoz wrote:
| Yeah, over-classification is definitely a thing. I
| suspect they don't want close-up video imagery of the
| payloads out there, either.
| Cthulhu_ wrote:
| 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.
| tbabb wrote:
| > 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...
| ceejayoz wrote:
| > Or pull a Millennium Falcon gambit and release the
| actual payload from a disposed fairing or stage when no
| one's looking...
|
| There was some speculation over that approach with the
| failed launch of the Zuma satellite.
| https://en.wikipedia.org/wiki/Zuma_(satellite)
| [deleted]
| ceejayoz wrote:
| > 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.
| kchr wrote:
| > Mk 1 eyeball
|
| I giggled.
| mrlonglong wrote:
| 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.
| rrmm wrote:
| Apparently many people have some capability to see
| polarised light under certain circumstances:
| https://en.wikipedia.org/wiki/Haidinger%27s_brush
| mindcrime wrote:
| Great, NCSU should be able to whip you up something like
| that soon:
|
| https://news.ycombinator.com/item?id=26400218
| sandworm101 wrote:
| >> 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.
|
| https://www.thedrive.com/the-war-zone/29543/the-visible-
| hist...
| ceejayoz wrote:
| 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.
| sandworm101 wrote:
| 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.
|
| https://www.thedrive.com/content/2019/08/b-2-top-2.jpg
| vesrah wrote:
| Wouldn't you then find the satellites by looking for star
| occultation?
| ceejayoz wrote:
| > 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/qu
| estions/23313/stea....
|
| There've been efforts towards stealth _ier_ craft.
| https://en.wikipedia.org/wiki/Misty_(satellite)
| 0xdeadbeefbabe wrote:
| > 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.
| chrisseaton wrote:
| > This doesn't strike me as particularly sensitive.
|
| I'm no rocket scientist but I would have thought you'd want
| to encrypt and sign everything... by default. Otherwise how
| do you stop spoofing as well?
| verelo wrote:
| Encryption takes time, and energy. I suspect they are
| trying to avoid adding latency to anything that's not super
| sensitive.
| mikepurvis wrote:
| 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.
| Rebelgecko wrote:
| 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
| myself248 wrote:
| 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.
| vardump wrote:
| You don't need any buffering if you pick your encryption
| mode correctly. That is, use a stream cipher.
| mikepurvis wrote:
| 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.
| vardump wrote:
| It would not affect at all. Flipped bits / transmit
| errors have no avalanche effect, unless the bit was
| flipped in the encryption module.
| mikepurvis wrote:
| What if you have gaps in your stream with uncertain
| length, though?
|
| Based on quick read about stream ciphers, it seems like
| the alignment of the key and data is pretty critical.
| toomuchtodo wrote:
| 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).
| BenjiWiebe wrote:
| Spoofing is extremely difficult when you are pointing a
| highly directional dish antenna up into the air at a
| rocket.
| dylan604 wrote:
| Not if you're SR Hadden.
|
| 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.
| sandworm101 wrote:
| >> 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.
| cedivad wrote:
| 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).
| magicalhippo wrote:
| 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.
| de6u99er wrote:
| You can do this with FPGAs in real-time.
|
| https://www.google.com/search?q=fpga+encryption+serial+data+.
| ..
| robin_reala wrote:
| Serbia and Siberia are substantially different places. Let's hope
| it's just a typo and not a bug :)
| londons_explore wrote:
| I really want to visit /S.*ia/ sometime!
| fastball wrote:
| Might want to use /S[beir]+a/, otherwise you're gonna end up
| visiting a famous singer!
| darknavi wrote:
| South Africia is really pretty this time of year!
| Lev1a wrote:
| I personally don't have the kind of time to visit all of
| /S.*ia/, I'll have to make to do with just /S\w+ia/.
|
| Shame, really...
| function_seven wrote:
| Not sure what you have against Sia, Cypress. I, for one,
| will try to make it to /S\w*ia/.
___________________________________________________________________
(page generated 2021-03-11 23:00 UTC)