Bypassing Samsung’s Boot Chain: From Heap Overflows to Full Device Compromise

TLDR: Researchers at Quarkslab demonstrated a critical exploit chain against Samsung Galaxy A-series devices, leveraging a heap overflow in the Little Kernel (LK) bootloader and an authentication bypass in the Odin protocol. This chain allows attackers to flash arbitrary partitions, gain persistent root access, and extract sensitive data from the device's secure world, including Keystore keys. The vulnerabilities, tracked as CVE-2024-20832, CVE-2024-20865, and CVE-2024-20820, have been patched, but they highlight the severe risks of insufficient bounds checking in low-level boot components.

Mobile security research often focuses on the application layer, but the real power lies in the boot chain. When the foundation is compromised, the entire security model—including TEE-backed encryption and hardware-backed keystores—collapses. The recent research presented at Black Hat 2024 on the Samsung Galaxy A225F is a masterclass in chaining seemingly minor implementation flaws into a full-system takeover.

The Vulnerability Chain

The attack begins with the Little Kernel (LK), an open-source bootloader common in the Android ecosystem. Samsung modified this bootloader to include proprietary features, such as the Odin recovery protocol and a custom JPEG parser for displaying boot-time logos and error messages.

The researchers identified a heap overflow in this JPEG parser. The code allocates a fixed-size buffer on the heap and then reads a JPEG file from a TAR archive located in the up_param partition. Crucially, the function responsible for reading the file takes a size argument that is supposed to act as a bounds check. However, if the provided size is zero, the check is bypassed entirely, allowing the system to read an arbitrary amount of data into the fixed-size buffer.

Because the heap implementation in this version of LK is a simple miniheap relying on a doubly-linked list, an attacker can overwrite the metadata of adjacent chunks. By carefully crafting the JPEG file, an attacker can turn this heap overflow into an arbitrary write primitive. Since the heap is executable and there is no ASLR or stack canary protection in this boot stage, the path to code execution is straightforward: overwrite a function pointer or return address to redirect control flow to shellcode embedded within the malicious JPEG.

Bypassing Odin Authentication

Gaining code execution in the bootloader is only half the battle. To achieve persistence, the attacker needs to flash malicious code to the device. This is where the Odin protocol comes in. Odin is Samsung’s recovery protocol, which allows for flashing partitions via USB.

The researchers discovered that while Odin authenticates images, the up_param partition—where the malicious JPEGs reside—is not checked at boot. Furthermore, by manipulating the Partition Information Table (PIT) and the GUID Partition Table (GPT), they could trick the bootloader into loading a modified partition structure. By renaming a partition to up_param and flashing it via Heimdall, they could bypass authentication checks and gain the ability to flash any partition on the device.

Extracting Secrets from the Secure World

With persistent root access, the researchers turned their attention to the Secure World, specifically the ARM Trusted Firmware (ATF) and the TEE. They identified an out-of-bounds read vulnerability in an ATF handler, reachable from the normal world via Secure Monitor Calls (SMCs).

The vulnerability exists in a function that uses a global array initialized to a hardcoded memory address. The function takes an index argument from the normal world and uses it to access the array without any bounds checking. This allows an attacker to leak 4 bytes of data from the ATF virtual address space per call. By chaining these calls, an attacker can dump the entire ATF memory, including sensitive keys stored in the TEE.

This is particularly devastating for the Android Keystore system. While keys are stored as encrypted blobs, the raw key material must be decrypted within the secure environment to be used. By stopping execution after the BeginOperation call, the attacker ensures the key is decrypted and resides in memory, then uses the OOB read vulnerability to dump it.

Real-World Applicability

For a pentester, this research is a reminder that hardware-backed security is only as strong as the code that manages it. If you are performing a security assessment on a mobile device, do not assume the boot chain is impenetrable. Tools like mtkclient have made it significantly easier to interact with low-level boot modes on MediaTek-based devices, which are common in the mid-range market.

During an engagement, look for custom bootloader modifications. Manufacturers often add proprietary features to standard open-source components like LK or U-Boot. These additions are rarely subjected to the same level of scrutiny as the core bootloader code and are frequent sources of vulnerabilities. If you can trigger a custom recovery mode or interact with proprietary flashing protocols, you have a high probability of finding an entry point.

Defensive Considerations

Defending against these types of attacks is difficult because they occur before the OS even loads. The primary defense is a rigorous secure boot implementation that verifies every stage of the boot process, including all configuration partitions. Manufacturers must ensure that all parsers—especially those handling complex formats like JPEGs—are hardened against memory corruption and that all inputs are strictly validated.

For security teams, the takeaway is clear: device integrity is not a binary state. Even if a device passes basic attestation checks, it may still be vulnerable to low-level exploits that can be used to bypass those very checks. When assessing mobile fleets, prioritize devices that receive timely firmware updates and have a proven track record of patching boot-level vulnerabilities. If you are building high-security applications, assume that the underlying hardware could be compromised and design your cryptographic protocols accordingly, perhaps by requiring multi-factor authentication that does not rely solely on device-stored keys.