The average Starlink user probably doesn’t spend a lot of time thinking about their hardware after getting the dish aligned and wiring run. To security researchers, however, it’s another fascinating device to tinker with as they reverse-engineer the firmware and try to both find out what makes it tick, as well as how to break it. This is essentially the subject of [Carlo Ramponi]’s article over at Quarkslab as he digs into the firmware architecture and potential weaknesses in its internal communication.

The user terminal hardware itself is a quite standard AArch64 ARM-based SoC, along with the proprietary communication interface, all of which is controlled by the Linux-based firmware. Dumping the firmware itself was made easy thanks to existing work by researchers at the KU Leuven, involving dumping the contents of the onboard eMMC storage. After this the firmware architecture could be analyzed, which turned out to consist out of mostly C++-based binaries, but with a single big binary for the user front-end written in Go.

Communication between these processes is handled through a custom inter-process protocol called ‘Slate Sharing’, all of which is coordinated via the core User Terminal Control process. It are these Slate IPC messages which form the most likely attack surface for a fuzzing attack, with the SoftwareUpdateRequest command being an interesting target as it would seem to not require authentication since it doesn’t address a specific user. This work is part of [Carlo]’s master’s thesis, and should form the basis of further research on the Starlink User Terminal firmware.