Loading story…
Researchers reversing a customized U-Boot bootloader from an ARM Cortex-A7 IoT device found that the vendor’s firmware protection relied on the clear-text bootloader to decrypt an encrypted Linux kernel during startup. By analyzing firmware partitions from the vendor site with Binwalk, strings, SoC documentation, and Ghidra, they reconstructed the bootloader’s memory layout, identified its interrupt vector table, and relocated the raw binary to 0x00800000 for accurate analysis. They determined that the bootloader used AES for kernel decryption and SHA-1 in key derivation, while the root filesystem was likely decrypted later by the kernel itself.
The researchers then bypassed the custom encryption scheme by emulating the bootloader’s decryption routine instead of fully reimplementing it. Using the Unicorn CPU emulator rather than QEMU, they directly invoked the block_aes_decrypt function with controlled registers and memory, showing that the AES key was hard-coded in the U-Boot binary and that no external hardware interaction was required to recover plaintext. Their proof of concept decrypted the first 512 bytes of the kernel image, after which they converted the recovered raw kernel into an analyzable ELF using vmlinux-to-elf for further reverse engineering.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
Shielder published the second part of its walkthrough, showing how the researchers used Unicorn CPU emulation to execute the bootloader's AES decryption routine and recover decrypted kernel data for further analysis.
Shielder published the first part of its technical analysis of a customized U-Boot bootloader from an ARM Cortex-A7 IoT device, describing how the researchers reconstructed the bootloader layout and identified its firmware decryption logic.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
shielder.com
Open sourceshielder.com
Open sourceunicorn-engine.org
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.
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
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
Researchers previously disclosed **LogoFAIL**, a broad set of UEFI image-parsing flaws that can let attackers execute code during the DXE boot phase by abusing OEM logo customization paths. The vulnerabilities affect parsers for formats including BMP, GIF, PNG, JPEG, PCX, and TGA, and can be triggered from attacker-controlled sources such as the EFI System Partition, firmware update volumes, or NVRAM. Binarly reported 29 root causes, including 15 likely exploitable issues, and demonstrated arbitrary code execution on a Lenovo ThinkCentre M70s Gen 2 via an AMI PNG parser flaw. The weaknesses can bypass protections such as **Secure Boot**, Intel Boot Guard, AMD hardware-validated boot, and ARM TrustZone-based verification, with impact spanning firmware from major BIOS and device vendors. Subsequent reporting said the **BootKitty** malware family exploited LogoFAIL to infect **Linux** systems, marking a notable evolution from a theoretical firmware weakness into active bootkit tradecraft. Coverage described the attack path as exceptionally difficult to detect or remove because it operates in UEFI before the operating system loads, allowing persistence below traditional endpoint defenses. The case also undercut assumptions that Linux systems are insulated from modern UEFI bootkits, showing that firmware-level compromise can survive OS reinstallations and evade both software- and hardware-based security controls.
Jun 29, 2026