Loading story…
Independent researchers published detailed reverse-engineering of SpaceX Starlink user terminals, showing that the devices’ firmware, boot chain, and runtime services can be closely inspected through hardware teardown, eMMC extraction, and emulation. Analyses of v2, v3, and Standard Actuated Rev3/GenV2 terminals found large portions of firmware left unencrypted, documented custom integrity controls including ECC and sxverity, and mapped a Linux-based architecture in which user-space C++ networking components handle much of the terminal logic. Researchers also identified an STSAFE-A110 security chip used for device identity and key operations, observed telemetry-related Ethernet recording components, and reported that one terminal initialized 41 SSH public keys while leaving port 22 open on the local network.
Separate work demonstrated that Starlink secure boot could be bypassed in a lab by voltage fault injection against the BL1 stage on the custom ARM SoC, yielding root-level access despite secure-boot protections. Researchers built QEMU-based environments to debug services such as httpd, WebSocket, and gRPC, examined the internal user_terminal_frontend interface, and found an unauthenticated SoftwareUpdateRequest on the internal network that could start the update flow, although fuzzing did not uncover a practical remote exploit path. Black-box testing also triggered out-of-memory crashes in the Go-based frontend through malformed localhost-bound IPC traffic, while SpaceX reportedly reproduced the fault-injection proof of concept and mitigated part of it by disabling UART output via eFuse.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
8 events from the most recent confirmed update back to the earliest known activity.
In its March 2025 publication, DARKNAVY reported building a basic QEMU-based emulation environment for the Rev3 firmware. Within emulation, the team successfully ran and debugged components including httpd, WebSocket, and gRPC services.
On 26 March 2025, DARKNAVY published a preliminary analysis of the Starlink Standard Actuated Rev3/GenV2 user terminal antenna. The researchers disassembled the hardware, extracted firmware from the eMMC chip, and reported that much of the firmware was unencrypted, exposing the boot chain, kernel, filesystem components, and runtime layout.
The Quarkslab research found that the user_terminal_frontend process exposed an unauthenticated SoftwareUpdateRequest on the internal network. The request could trigger the software update flow, with sxverity becoming the first component to parse the supplied update bundle.
On 29 August 2023, Carlo Ramponi published a detailed reverse-engineering analysis of Starlink User Terminal v2 and v3 firmware. The study documented the boot chain, custom integrity mechanisms, runtime internals, Slate Sharing IPC, and QEMU-based emulation of the device environment.
At Black Hat USA 2022, Lennert Wouters presented a lab attack showing that voltage fault injection against the BL1 boot stage could bypass secure boot on the SpaceX Starlink user terminal and yield root-level researcher access. The presentation also described eMMC extraction, boot-chain analysis, and a custom modchip approach.
After SpaceX's UART mitigation, the researcher refined the attack approach and regained access to the Starlink terminal. The updated method triggered on eMMC D0 rather than UART activity.
Following the fault-injection research, SpaceX deployed a mitigation that blew a previously unused eFuse to disable UART output on the terminal. This removed the UART-based trigger path and forced the researcher to adapt the attack to monitor eMMC activity instead.
After the Black Hat research, SpaceX PSIRT reproduced the demonstrated proof-of-concept attack against the Starlink terminal. This confirmed the feasibility of the hardware fault-injection technique under lab conditions.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
3 references tracked. Mallory keeps watching after this page renders.
darknavy.org
Open sourceblog.quarkslab.com
Open sourcei.blackhat.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers disclosed two separate boot-chain security issues that undermine trusted startup protections on major platforms. CERT/CC warned that outdated Microsoft-signed UEFI **shim** bootloaders—especially `shim` version `0.9` and earlier, including forked or unpatched builds used by vendors such as Red Hat Enterprise Linux, CentOS, Oracle, OpenSUSE, and WhiteCanyon—can be abused to bypass **Secure Boot** and run arbitrary code before the operating system loads. Because the attack executes in the early boot phase, it can evade EDR visibility and establish persistent compromise; Microsoft is responding by expanding the UEFI Forbidden Signature Database (**DBX**) to revoke vulnerable bootloaders, while administrators have been urged to update signature databases first and test carefully to avoid leaving systems unbootable. Paradigm Shift also disclosed an **unpatchable BootROM flaw** in Apple `A12` and `A13` chips and released a proof-of-concept exploit, `usbliter8`, showing that affected devices from the iPhone XS through the iPhone 11 line can be compromised during startup. The bug stems from USB controller behavior in SecureROM that allows unauthorized memory writes via crafted packets, enabling temporary reduction of security settings, booting of unsigned software, and the familiar `PWND` USB serial marker after exploitation. Apple was notified before publication, but because the weakness is embedded in silicon, software updates cannot fully eliminate the risk for affected devices over their operational lifetime.
Jun 29, 2026
Researchers from Eclypsium discovered that nearly 200,000 Linux-based Framework laptops and desktops were shipped with signed UEFI shell components containing a powerful 'memory modify' (mm) command, which can be exploited to bypass Secure Boot protections. The mm command, intended for low-level diagnostics and firmware debugging, provides direct read and write access to system memory, including critical security variables such as gSecurity2. By abusing this command, an attacker can overwrite the gSecurity2 variable with NULL, effectively disabling signature verification for all subsequent UEFI module loads and breaking the Secure Boot trust chain. This vulnerability allows attackers to load bootkits such as BlackLotus, HybridPetya, and Bootkitty, which can evade operating system-level security controls and persist even after OS reinstallation. The attack can be automated using startup scripts, ensuring persistence across reboots. The issue is not the result of a supply chain compromise or malicious intent, but rather an oversight in the inclusion of diagnostic tools signed with trusted certificates. Eclypsium's research highlights that these signed UEFI shells, while legitimate, function as backdoors that undermine the security model of Secure Boot. The presence of such tools in production devices exposes users to significant risk, as attackers can leverage them for pre-OS infections, espionage, sabotage, or ransomware attacks. The gaming industry has already seen commercial cheat providers exploiting similar UEFI-level bypasses, and the same techniques could be adopted by nation-state actors or advanced persistent threats. Framework has acknowledged the issue and is working on remediation, with fixes planned for affected models such as the Framework 13 (11th and 12th Gen Intel). The discovery underscores the broader risk of trusted, signed components containing powerful functionality that can be misused, and the need for rigorous review of firmware-level tools included in shipping devices. The vulnerability demonstrates that even systems marketed as secure and repairable can harbor critical flaws if diagnostic utilities are not properly restricted. The incident serves as a warning to hardware manufacturers and the security community about the dangers of trusted but overly permissive firmware components. Eclypsium's findings have prompted a reassessment of trust models in firmware security, emphasizing the importance of minimizing attack surfaces in pre-boot environments. The case also illustrates how attackers are increasingly targeting lower layers of the computing stack to achieve persistence and evade detection. Framework's response and the ongoing remediation efforts will be closely watched by the industry as a test case for responsible disclosure and mitigation of firmware-level threats.
Jul 23, 2026
Security researchers have demonstrated new hardware-based techniques to extract sensitive data from devices previously considered secure, including smartwatches and confidential computing servers. In one case, analysts revived the 'Blinkenlights' technique, adapting it to modern TFT screens to extract firmware from a budget smartwatch by exploiting a dial parser vulnerability. This allowed arbitrary memory content to be displayed on the device's screen, which was then captured using a high-speed Raspberry Pi Pico setup. The smartwatch, which contained fake health sensors and used a JieLi AC6958C6 system-on-chip, was found to have weak authentication and a flawed firmware parser, enabling the out-of-bounds read attack. Separately, researchers from KU Leuven University presented a low-cost hardware attack called 'Battering RAM' at Black Hat Europe 2025, which targets secure CPU enclaves such as Intel SGX and AMD SEV. By using a $50 DDR4 interposer, the researchers manipulated memory address mapping at runtime, bypassing firmware mitigations and gaining unauthorized access to encrypted memory. This allowed them to extract platform provisioning keys, forge attestation reports, and implant persistent backdoors on protected virtual machines, raising concerns about the security of cloud infrastructures relying on these technologies.
Jun 29, 2026