Reverse Engineering SpaceX

SpaceX Is Now Public. Here's What Reverse Engineering Starlink Actually Revealed.

SpaceX raised about $75 billion in a record IPO, and closed its first trading day at $160.95 on 12 June. The stock story is well covered. This piece is about the dish on a roof, which security researchers and radio engineers have been dissecting for years, and what they learned.

A note on scope: I'm covering findings, not procedures. Several of these results involve hardware attacks, and I'm leaving out anything that works as a recipe.

The Boot Chain Was Hardened, and Still Fell to a Glitch

The first public break came from Lennert Wouters at KU Leuven. His Black Hat 2022 talk describes a custom quad-core Cortex-A53 SoC with verified boot based on ARM trusted firmware, where the early-stage bootloaders include custom fault injection countermeasures. Hardware inspection found a serial port and a locked-down boot path. The boot images were signed, U-Boot ignored serial input, and the development login was disabled.

Voltage fault injection got past it. Per the researchers, the attack bypasses signature verification during the SoC's ROM bootloader (BL1), allowing arbitrary code from BL2 onward. The Starlink-FI repo published the board design, and Wouters withheld patched firmware and the exact glitch details. The root of trust is in ROM, so he argued it can't be fixed on shipped units. SpaceX's position, per the coverage, is that the attack needs physical access and compromises only that one device.

SpaceX's own response is worth noting. It publishes its U-Boot fork on GitHub to satisfy the license, and the Quarkslab follow-up credits SpaceX's security team with providing a rooted dish for research.

What's on the Flash

With a dump in hand, Quarkslab's analysis shows how the device is organized. Memory is partitioned in the U-Boot config, and almost every partition appears twice (A/B), so a failed update never overwrites the known-good copy. Three integrity layers stand out:

• Custom ECC, not security. The scheme uses Reed-Solomon coding plus an MD5 over the whole file. It provides integrity but not authenticity. The signed FIT image is protected separately, because the final bootloader checks its signature.
• sxverity. A custom wrapper around Linux dm-verity, where SpaceX implemented only root hash verification. Its image header is repeated four times and signed with ED25519.
• LUKS. The only writable partitions are encrypted with LUKS.

Runtime startup is custom too. SpaceX replaced the usual init system with its own sxruntime_start, driven by a config format that sets per-process conditions, users, AppArmor profiles and CPU priorities.

The Daemons and the IPC Nobody Documented

Per Quarkslab, most runtime binaries are C++ and some are statically linked, which made them hard to analyze. The user-facing process, user_terminal_frontend, is written in Go. That choice helped researchers, because Go binaries carry symbols. With the GolangAnalyzer Ghidra plugin they recovered structures and function names.

Process names suggest a network stack, though the author hedges every mapping with "perhaps":

• phyfw for the physical layer
• rx_lmac and tx_lmac for lower MAC
• umac for upper MAC, possibly including satellite selection
• connection_manager and ut_packet_pipeline for stateful connections and an encrypted tunnel backed by the secure element

The most interesting find is the internal bus. Processes talk to a central control process over a protocol called Slate Sharing. It runs over UDP on the loopback interface, with raw packed big-endian C structs and a header holding a magic type, a CRC, a sequence number and a fragment index. The decoder shortcut was a gift: message layouts are listed in plain config files under the runtime directory, so the structures didn't need to be reverse-engineered binary by binary. Quarkslab built a sniffer and injector on top of that.

Fuzzing the bus found a bug worth reading about. A malformed obstruction-map message with huge num_rows and num_cols values made the Go frontend try to allocate the product with no size check. In Go, the runtime panics rather than corrupting memory. Quarkslab notes the bug was only reachable through UDP to a loopback-only service, and the dish's iptables rules filter incoming UDP, so they classed it as a bug rather than a vulnerability.

The gRPC Surface

The dish exposes a gRPC server on its LAN. The Rust crate starlink-rs documents an unauthenticated HTTP/2 gRPC server at 192.168.100.1:9200 that supports server reflection. Quarkslab's write-up shows the request schema is a large oneof covering status, reboot, factory reset, stow, obstruction map and more. It also describes a second, authenticated path: a secure channel using mutual TLS with certificates in the secure element, while the mobile app and web UI use the insecure channel.

SoftwareUpdateRequest is the interesting handler, since it takes a large input without authentication. But it only buffers the bundle. The first code to parse it is sxverity, which checks the signature before anything is flashed. Quarkslab fuzzed that header parser in Unicorn with AFL++. The run lasted about 24 hours and over a million executions with no crash, which the author attributes to a small, simple input format.

Two caveats on all of this. It's 2023 work on v2 and v3 hardware. And the schema moves: a UVic paper notes gRPC once exposed the serving satellite, cell ID and gateway ID, and SpaceX removed that through firmware updates, which pushed researchers toward inference. The community tooling is starlink-grpc-tools. Firmware watchers still diff releases: one researcher's May analysis found a DishBatteryStats message hinting at a Starlink Mini with a built-in battery.

The Radio Is Where the Real Depth Is

The most rigorous work isn't on the dish at all. A UT Austin team led by Todd Humphreys did blind identification of the downlink. Their paper says blind identification of an operational OFDM signal, including exact synchronization sequences, hadn't been achieved before. They avoided modifying a terminal, because operating one as development hardware means defeating security controls designed to prevent that, and the clock quality is unknown. They built their own capture rig around a 90 cm dish and a GPS-disciplined oscillator.

The recovered parameters, per their Table II:

• 240 MHz channels, 1024 subcarriers, a 32-sample cyclic prefix, and a 1/750 s frame of 302 symbols at 4.4 µs each.
• Eight channels, 250 MHz apart with 10 MHz guard bands. The lowest two are vacant, likely to avoid the radio astronomy band.
• Each frame opens with a primary sync sequence: a 127-bit m-sequence encoded as symmetric DPSK and repeated eight times, with the first repetition inverted.

The design choices read like engineering decisions. The 32:33 useful-to-total symbol ratio is far more efficient than LTE's, because the space-to-Earth channel has low delay spread. And four sync symbols every 1.33 ms is unusually heavy compared with terrestrial OFDM, which helps channel estimation and, as a side effect, positioning.

One subtle finding: the sync sequences are identical across all satellites, unlike GNSS codes. So a receiver has to resolve which satellite it heard from ephemerides, Doppler and frame timing. The paper claims pseudoranges below -6 dB SNR, well under what communication needs.

The 2026 follow-up, Pilots and Other Predictable Elements, goes further. It decodes the edge pilots, bands of 4QAM symbols at both channel edges that repeat identically across frames, beams, channels and satellites. The related project estimates a processing gain of roughly 48 dB, enough for compact receivers to get timing from low-SNR side beams. The authors also report that the old Doppler pilot tones have weakened significantly since 2023. A supplementary dataset of 1009 decoded frames from a v2.0-mini satellite is public.

A related timing study found that frame arrival times show nanosecond-level jitter at best, but v1.0 and v1.5 satellites apply once-per-second timing jumps of up to hundreds of nanoseconds, and frame timing is only loosely disciplined to GPS time. The authors attribute that to software design rather than hardware.

What Reverse Engineering Still Can't See

It sees one slice. The satellites, the ground gateways and the inter-satellite links are not buyable hardware, so the evidence comes from the dish and its downlink. Even the dish findings are version-specific. Quarkslab itself says it didn't fully inspect the satellite network stack or protocols.

The practical rule: treat any Starlink claim as dated to a firmware and hardware version, and prefer results with a reproducible artifact, whether a dataset, a script or a capture.

Follow for more coverage on MCP, agentic AI, and AI infrastructure.