Hackaday Links Column Banner

Hackaday Links: May 19, 2024

If there was one question we heard most often this week, it was “Did you see it?” With “it” referring to the stunning display of aurora borealis — and australis, we assume — on and off for several days. The major outburst here in North America was actually late last week, with aurora extending as far south as Puerto Rico on the night of the tenth. We here in North Idaho were well-situated for prime viewing, but alas, light pollution made things a bit tame without a short drive from the city lights. Totally worth it:

Hat tip to Tom Maloney for the pics. That last one is very reminiscent of what we saw back in 1989 with the geomagnetic storm that knocked Québec’s grid offline, except then the colors were shifted much more toward the red end of the spectrum back then.

Continue reading “Hackaday Links: May 19, 2024”

Starlink terminal being injected with 12V from an external PSU

Bypass PoE And Power Your Starlink Terminal Directly

Sometimes, you will want to power a device in a way it wasn’t designed for, and you might find that the device in question is way too tailored to the original power source. Today, [Oleg Kutkov] is here to give us a master class on excising unnecessary power conversion out of your devices, with the Starlink terminal as an example. This device can only be officially powered from 48V PoE, but can technically work from about 12V – and, turns out, many people want to mount a Starlink terminal to their cars.

[Oleg] shows us the power circuit of the Starlink terminal, explaining which component is responsible for what, and gives us a block diagram. Then, he shows you the 12V rail that all internal components actually draw power from, and where to feed power into it. Plus, he warns you about possible caveats, like having to disable the builtin 12V regulator to prevent it from backfeeding-induced damage. If you’re looking to modify a similar device, this tutorial gives you heaps of insight on what you might need on your foray.

Thinking to modify your own Starlink terminal, perhaps, and wondering about the power consumption? [Oleg] has current consumption graphs for you, collected with a data logger for Uni-T UT800 of his own design, providing detailed figures on just how much energy you ought to supply to power the terminal from 12V, and where to (not) get it. After all, even a seemingly suitable power supply might not do.

A bias tee module added inside the Starlink terminal, connected to the pads where a GPS antenna used to be wired

GPS Antenna Mods Make Starlink Terminal Immune To Jammers

The Starlink receivers need positioning and precise timing information to function, and currently the best way to get that information is to use a global navigation satellite system (GNSS) such as GPS. Unfortunately, the antenna used for this secondary satellite connection leaves something to be desired. Of course, when it comes to solving Starlink problems, there’s no one best than [Oleg Kutkov], whose duty is to fix and improve upon Starlink terminals used in Ukraine — and when the specific problem is GPS bands getting jammed by the invading military, you better believe that a fix is due.

[Oleg] sets the scene, walking us through the evolution of GPS circuitry on the Starlink terminals. Then he shows us the simplest mods you can do, like soldering an improved passive antenna in place of the chip antenna currently being used. Then, he takes it up a notch, and shows us how you could attach an active antenna by using a bias tee module, a mod that would surely work wonders on more than just this device! Then, he brings out the test result tables — and the differences are impressive, in that the Starlink terminals with active antenna mods were able to get GPS signal in areas with active jamming going on, while the unmodified ones could not.

The post is exceptionally accessible, and a must read for anyone wondering about GPS antenna reception problems in customer-accessible devices. This is not the only Starlink hardware mod we’ve seen [Oleg] make, we’ve just covered his Starlink Ethernet port restoration journey that meticulously fixes Ethernet connectivity oversights in the newer models, and the blog also has an article about powering Starlink terminals without the need for PoE, so, do check it out if you’re looking for more!

Pictures of the internals of the Starlink adapter

Restoring Starlink’s Missing Ethernet Ports

Internet connectivity in remote areas can be a challenge, but recently SpaceX’s Starlink has emerged as a viable solution for many spots on the globe — including the Ukrainian frontlines. Unfortunately, in 2021 Starlink released a new version of their hardware, cost-optimized to the point of losing some nice features such as the built-in Ethernet RJ45 (8P8C) port, and their proposed workaround has some fundamental problems to it. [Oleg Kutkov], known for fixing Starlink terminals in wartime conditions, has released three posts on investigating those problems and, in the end, bringing the RJ45 ports back.

Starlink now uses an SPX connector with a proprietary pinout that carries two Ethernet connections at once: one to the Dishy uplink, and another one for LAN, with only the Dishy uplink being used by default. If you want LAN Ethernet connectivity, they’d like you to buy an adapter that plugs in the middle of the Dishy-router connection. Not only is the adapter requirement a bother, especially in a country where shipping is impeded, the SPX connector is also seriously fragile and prone to a few disastrous failure modes, from moisture sensitivity to straight up bad factory soldering.

Continue reading “Restoring Starlink’s Missing Ethernet Ports”

Starlink’s Inter-Satellite Laser Links Are Setting New Record With 42 Million GB Per Day

Slide from the SpaceX Starlink presentation on mesh routing via the laser links. (Credit: PCMag/Michael Kan)
Slide from the SpaceX Starlink presentation on mesh routing via the laser links. (Credit: PCMag/Michael Kan)

Although laser communication in space is far from novel, its wide-scale deployment as seen with SpaceX’s Starlink satellite internet constellation has brought the technology to the forefront like never before. This was quite apparent during the SPIE Photonics West event on January 30th when [Michael Kan] and other journalists attended a presentation by SpaceX’s [Travis Brashears] on the inter-satellite laser communication performance that was first enabled with the Starlink v1.5 satellites.

Among currently active inter-satellite communication systems, Starlink is by far the most numerous and with the highest bandwidth, reaching over 42 PB per day across its over 9000 space lasers (yes, that is over 9000) for a 5.6 Tbps throughput. Since these satellites form a mesh network with their 100 Gbps laser transceivers, a big part of using it efficiently is to route any data with the least amount of latency while taking into account link distance (maximum of 5,400 km), link duration (up to multiple weeks) and presence of other Starlink satellites before they become within reach. With this complex mesh in LEO, this also means that a very high uptime can be accomplished, with a claimed 99.99% due to rapid route changing.

For the future, SpaceX has plans to not only keep upgrading its own Starlink satellites with better laser transceivers, but to also make them available to third-party satellites, as well as beam the lasers directly down to Earth for ground-based transceivers. The latter is still cutting edge, despite it being tested to beam cat videos to Earth from Deep Space.

Hackaday Links Column Banner

Hackaday Links: January 28, 2024

From the “No good deed goes unpunished” files, this week came news of a German programmer who probably wishes he had selected better clients. According to Heise Online (English translation), a freelance programmer — referred to only as “defendant” in the article — was retained by a company to look into a database problem in their system. His investigation revealed that the customer’s database was being filled with log messages from a third-party service called Modern Solution GmbH & Co. KG. over a MySQL connection to a remote server. Assuming this connection was dedicated for his client’s use, the programmer looked at the executable used to make the connection with a text editor, which revealed a password in plain text. Upon connecting to the remote database, he found that it not only contained data for all of Modern Solution’s customers, but also data for all the end users of their customers.

Realizing he’d unintentionally wandered into verboten territory, the programmer immediately backed out and contacted Modern Solutions. They quickly fixed the issue, and then just as quickly reported him to the police. Their “investigation” revealed that the programmer had “decompiled” the executable to obtain the password, in violation of German law. The judge agreed, stating that merely looking at and using the password constituted a criminal offense, regardless of intent and despite the fact that Modern Solution had provided the password to the programmer’s client when they sold them the software. The upshot of all of this nonsense? A €3,000 fine for the programmer, if the verdict stands on appeal. It could have been worse, though; German law allows for up to three years in prison for such offenses.

Continue reading “Hackaday Links: January 28, 2024”

Diving Into Starlink’s User Terminal Firmware

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.