Nope, they do not comply with the GPL licenses for their User Terminal firmware. I've sent them GPL requests for the GPLv2 Buildroot based firmware build system they use but they have so far refused to provide the source code. They have posted some kernel/uboot sources.
I am both a major Buildroot contributor and have Starlink internet service.
Their router firmware is OpenWRT based and while they have posted some source code for that it is not the source code corresponding to the binary firmware builds they actually distribute.
I have NAND dumps of both the User Terminal and router.
Funny enough a few years back their internal firmware CI even accidentally sent me some emails about broken builds since they applied some of my buildroot patches from upstream.
There's an immediate application to this research, and that's answering the following question:
How does the implementation of their geo-fencing enforcement actually work? As you may know, you can't use starlink in India (or Iran etc.), even with a roaming plan.
Sure, it is possible that the satellites just "go off" whenever passing over these territories. However, from experience, there's a good chance that this isn't how it works. Perhaps there is some cooperation from the client side (at the software level). Perhaps the terminal being hard-to-root had made it "trusted enough" for this purpose in their security design.
If anyone is up to answering that question, I'm sure they'll get a bunch of karma on their HN post.
I know my previous sat phone from Thuraya had a GPS receiver and refused to connect before getting a GPS lock for precisely this reason.
Now, Thuraya is a bit weird in that they have some price plans that differ by the country you're calling from. Most sat phone networks don't do that but Thuraya is the cheapest in airtime by far especially when using some of these plans.
But I wouldn't be surprised if most networks work this way. After all a gps receiver costs peanuts these days and takes up trivial amounts of space.
If this is the case it's kinda cool because it can then also be used to circumvent these restrictions by spoofing the GPS signal either over the air or in the transceiver itself. Highly illegal obviously but technically cool.
Also, simply turning off the sat over these areas is not so easy because the footprint will cover a radius of hundreds of kilometers. So border areas will be a big problem.
You won't be able to spoof the gps location too much though because if you give it a location way outside your footprint I'm sure the sat is smart enough to block you.
> If this is the case it's kinda cool because it can then also be used to circumvent these restrictions by spoofing the GPS signal either over the air or in the transceiver itself. Highly illegal obviously but technically cool.
Since the Starlink satellites aim themselves to an extent, I’d think spoofing your location _too_ far away from where you actually are could end up with you unable to actually get a lock on any satellites.
Of course they focus in smaller areas as it significantly increases capacity too (providing multiple cells per sat with each their own capacity). But a more focused beam is still not able to follow borders tightly.
It's easier to focus from LEO (low earth orbit) like Starlink but there you're dealing with a constantly moving footprint. And see how small a Starlink sat is. Good luck fitting the big cantenna (and really you want several). Phased array yes but not a huge one. The more elements the tighter the focus.
With GEO (geostationary orbit) you don't have the moving problems and they do use static "cantennas" or rather dishes but you're so far away that you can't focus tightly anyway. The footprint of a single GEO cell dish is still the size of a small country.
I would bet if there’s any beam shaping they try to shape to avoid affected areas. Better to allocate that power somewhere it’s useful/paid for.
They probably also just authenticate based on end user (e.g. what is the account being used and where is if registered), and make it against usage terms to operate in certain geolocations. The uplink terminals may also include GPS metadata but that doesn’t seem necessary since most won’t move and extra GPS equipment would be added expense.
Huh? Why would the satellites go off? The Starlink satellites know they own location, so they most likely have a list of cells they are allowed to serve. It's a lot harder to hack a satellite in orbit than a terminal you have physical access to.
Well… no actually. Many satellites are “bent pipes”, and do no signal authentication. They just transpond and send the data back down. If you can get the uplink to hear you, you can use it. The problem is uplink may not always be listening in your direction.
It’s actually really easy to jam or pirate many satellites for this reason. I’m unsure if spacex has more auth than the industry standard.
Starlink is unique in being a LEO massive constellation using phased arrays and thus afaik cannot work like that. The terminal and satellites must work in conjunction to steer the beam electronically at a pretty fast rate, they're only ~550km away at a relative velocity of 7-someodd km/s. Cells are quite small, beam spots even smaller, and terminals must both track a given sat and jump between multiple ones.
Yes, all indications are that SpaceX auth is also very modern and very good, but the very nature of the system means they have to have quite precise location information on both sides. The satellites will simply not transmit where it's not permitted by regulators, and can do that with high resolution because they simply physically cannot usefully see very big circles. That's exactly why thousands and thousands of satellites are needed.
In another comment you mentioned "if there's any beam shaping" which seems to indicate you really haven't ever taken any real look at Starlink? It's nothing like an old HEO sat system.
SpaceX has been developing sat to sat links, but in the current system a majority of traffic just goes up and down like a bent pipe. However because of the speed the sats move the system needs to know the location of all endpoints in real time. A given sat is only visible to a base station for something like 90 seconds. So it's very different from traditional GEO services, or even MEO services like Iridium et all for that matter.
It's the ground side, the user endpoints and downlink stations (the latter Starlink can do without in some places due to the laser links) though that need approval to transmit from country regulators.
The sats themselves are regulated by the launching country, the US only.
I'd expect that since Starlink has to be a bit more involved in the communication (particularly for determining need for packet routing over the laser interconnects between satellites), they might not be bent pipes.
Plus, with things like updating the constellation, which likely is a significant security concern, they would probably be relying on some sort of geofencing.
It's definitely worth reading some of those earlier studies as well as this one, like that link 2 "Dumping and extracting the SpaceX Starlink User Terminal firmware" [0] also got some good discussion and insights [1]. There were a few tidbits in that I don't see here, like how root-enabled development hardware also was geofenced both to obvious SpaceX locations but also a few pretty random seeming ones that presumably were used for quiet off site testing in more challenging environmental conditions. It's cool to read the build up of knowledge, although one take home that shouldn't be unusual yet is was that SpaceX really seems to have done a pretty careful job in terms of security from the get-go, learning the lessons of those who came before for once.
That'd be fun to see but the transmit power probably isn’t strong enough to see things at any kind of range. It already maps out all the obstructions the dish sees and produces a map of them in the app though.
It seems like the weak point was the frontend process that was written in Go which was decompiler friendly, allowing the author to unravel a lot of details about the other software processes and communication protocols.
I love me some Go, but yeah, it wouldn't be my first choice if one of the requirements was "make it hard to reverse engineer". Which would suggest that that wasn't one of the requirements?
I was part of a project that did some analysis of OpenWRT firmware at scale. It was a lot of fun. The firmware is ( obviously ) publicly available. If you're interested in finding some cool results, you should try out FACT:
Yea, favorite place I found OpenWRT was in DJI phantom 2 Wi-Fi Extender module. Managed to SSH into it. Hardware was not particularly interesting just cool to see OpenWRT in a widely purchased product.
> The first step was to dump the firmware of the device since it's not publicly available, and we did that thanks to a blog post by the COSIC research group at KU Leuven.
And they contribute by not sharing the firmware :(
I know it might have legal issues, but this is not helpful for other researchers if we keep things hidden
>Most of the binaries have been implemented in C++ and some of them are also statically linked. Due to this, it was challenging to reverse-engineer these binaries and due to time constraints, we were unable to fully comprehend all of them. Some work was done to identify statically linked library functions, using the binary diffing technique. It is also probable that these programs were implemented using the State Machine Design Pattern, which makes heavy use of features of Object Oriented Programming such as multiple inheritance, virtual methods and generic types. This made the reverse-engineering process even more difficult due to the complex structures that are produced by the compiler when using these features.
