Attacking Samsung Galaxy A* Boot Chain, and Beyond

Attacking Samsung Galaxy A* Boot Chain, and Beyond

Speakers: Rafael, Maxime

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=qU9SzAo1G-s

Overview

This talk, presented by Rafael and Maxime at Black Hat USA, delves into a sophisticated chain of vulnerabilities discovered in Samsung Galaxy A-series devices based on MediaTek System-on-Chips (SoCs). The researchers detail how they achieved complete control over these devices through the USB port, ultimately enabling the exfiltration of sensitive secrets stored within the secure world, including key store keys. The research highlights critical weaknesses in the boot chain of these devices, specifically within Samsung's customized Little Kernel (LK) bootloader and its interaction with the Odin recovery protocol.

The significance of this work extends beyond the immediate devices affected. While the initial entry point for their previous research relied on a known boot ROM vulnerability, this new attack chain bypasses the need for such an exploit, making it applicable even to devices where the boot ROM vulnerability has been patched. The findings underscore the perils of insufficient security mitigations in critical boot components and the often-overlooked attack surface presented by seemingly innocuous features like image parsers. The persistence of the exploit, surviving reboots and factory resets, poses a severe threat to user data integrity and device security.

The presentation provides a comprehensive breakdown of the exploit development process, from identifying a heap overflow in the JPEG parser to leveraging an authentication bypass in the Odin protocol. It meticulously details the exploitation of a mini-heap allocator and the lack of standard memory safety mitigations, culminating in arbitrary code execution within the bootloader. The work serves as a stark reminder for device manufacturers to implement layered security, rigorous code reviews, and comprehensive fuzzing across all stages of the boot process, particularly for components operating with high privileges.

Background

▶ Watch: Introduction to attacking Samsung Galaxy A boot chain (0:00)

The journey into attacking Samsung's boot chain began with the researchers' previous work at Qlab, where they investigated how Android protects user data through its encryption schemes. For this research, they acquired a Samsung Galaxy A22, a relatively inexpensive device featuring a MediaTek System-on-Chip and running Samsung's Tigris OS. This particular device was initially targeted due to a known boot ROM vulnerability that could be exploited using an open-source tool called TK client. This initial vulnerability provided a convenient debugging environment for their subsequent research, allowing them to bypass the first stage of the secure boot and patch the system to extract credentials for brute-forcing user data. However, the core of this Black Hat presentation demonstrates an attack chain that does not rely on this initial boot ROM vulnerability, making it more broadly applicable.

To understand the attack, it's crucial to grasp the Secure Boot process on MediaTek SoCs. When the CPU powers on, it first executes a read-only piece of code known as the Boot ROM. This code runs with the highest privileges, specifically the E3 privilege level, within the secure world. The Boot ROM's primary responsibility is to load and verify the next stage bootloader, the Preloader. The Preloader, in turn, initializes the system and loads the ASTERED (also known as the Secure Monitor), which will eventually become the most privileged software running on the device once it's fully booted. The Preloader also initializes the system environment and loads the third-stage bootloader, Little Kernel (LK).

Little Kernel is an open-source bootloader widely adopted in the Android ecosystem. Its main function is to boot Android, which includes verifying Android images using Android Verified Boot (AVB), a standard security feature. However, the LK instance on Samsung Galaxy A-series devices is a closed-source, modified version by Samsung. These modifications introduce several Samsung-specific features, including Odin, a recovery protocol for flashing partitions via USB; "security bits" which void the device's warranty if the bootloader is unlocked (a security measure for Samsung, not the user); and crucially, a JPEG parser. This JPEG parser is responsible for displaying logos on the device screen during boot. The researchers identified this JPEG parser as a particularly interesting target because the logo files it processes are stored in an archive (referred to as the "upper parttion") that, while signed, is never checked at boot. This oversight meant that anyone capable of modifying the device's internal memory could alter these logo files without triggering a security alert, presenting a prime opportunity for vulnerability discovery. The presenters referenced prior research on "logo file" vulnerabilities, underscoring that image parsing in bootloaders has historically been a fruitful area for security exploits.

Key Findings

▶ Watch: Samsung's customized Little Kernel (LK) and Odin protocol (3:00)

The research unveiled a sophisticated, multi-stage attack chain that allowed for complete compromise of Samsung Galaxy A-series devices running MediaTek SoCs. The core findings can be summarized as follows:

1. Heap Overflow in Little Kernel's JPEG Parser: The primary vulnerability identified was a heap overflow within the custom JPEG parser implemented in Samsung's Little Kernel bootloader. This overflow was due to an insecure design choice where the function responsible for reading JPEG files could be called with a maximum size argument of zero. When this argument is zero, the system's size check is bypassed, allowing the parser to read an arbitrarily sized JPEG file into a fixed-size heap buffer, leading to an overflow.

1. Arbitrary Code Execution in Little Kernel: Leveraging the heap overflow, the researchers developed an exploit that achieves arbitrary code execution within Little Kernel. This was facilitated by the lack of standard memory safety mitigations in LK, such as Address Space Layout Randomization (ASLR), stack canaries, or a non-executable heap. The mini-heap allocation algorithm used in LK was exploited to gain an arbitrary write primitive, which was then used to overwrite a return address on the stack with the address of attacker-controlled shellcode placed in the overflowed JPEG buffer.

1. Persistence Across Reboots and Factory Resets: A critical aspect of the LK code execution exploit is its persistence. The partition containing the malicious JPEG files is not wiped during reboots or even factory resets. This means that once the exploit is successfully deployed, it remains active on the device, providing a persistent backdoor for the attacker.

1. Odin Authentication Bypass: To deploy the malicious JPEG without prior privileges, the researchers discovered a method to bypass the authentication mechanism of Samsung's Odin recovery protocol. Odin typically requires images to be signed for flashing. By comparing the Partition Information Table (PIT) and a global array that dictates authentication requirements, they identified specific partitions—namely PGT and SGT (Primary and Secondary GUID Partition Table headers)—that could be flashed without signature verification via USB.

1. Reshaping the Partition Table: The ability to flash PGT and SGT without authentication provided a powerful primitive: the ability to reshape the device's partition table. By modifying the GUID Partition Table (GPT), they could alter the definition of other partitions, including the "upper parttion" where the vulnerable JPEG files reside. This allowed them to effectively redirect the system to a controlled location containing their malicious JPEG, thereby enabling the heap overflow exploit without needing prior access to internal memory or a separate boot ROM vulnerability.

1. Secure World Memory Leakage: The culmination of this attack chain—from USB access to Odin authentication bypass, to LK code execution—enabled the researchers to leak memory from the secure world. Specifically, they demonstrated the ability to extract key store keys, which are fundamental to the device's cryptographic security. While they acknowledged it was "still unclear" if attestation keys could also be leaked at the time of the talk, the compromise of key store keys alone represents a severe security breach.

1. Widespread Impact: The vulnerabilities were found to affect all Samsung devices based on MediaTek SoCs that the researchers investigated, primarily low- and mid-range Galaxy A-series models. Importantly, the attack chain is effective even on devices where the initial boot ROM vulnerability (used for debugging) had been patched, significantly broadening its scope. Samsung has since fixed all reported vulnerabilities.

Technical Deep Dive

▶ Watch: Discovery of an unchecked JPEG parser in Little Kernel (3:40)

The technical core of this attack chain rests on two main pillars: a heap overflow vulnerability in the Little Kernel (LK) bootloader and an authentication bypass in the Odin recovery protocol.

Heap Overflow in Little Kernel's JPEG Parser:

The vulnerability resides within Samsung's customized Little Kernel, specifically in the code responsible for parsing and rendering JPEG logos on the screen during boot (03:00). The process involves three main steps:

1. Buffer Allocation: The code first allocates a buffer of a constant, fixed size on the heap.
2. File Reading: A function, which the researchers called read_jpeg_file, is then invoked. This function takes a filename, looks for it in the "upper parttion" (an archive containing the logos), and reads the JPEG content into the previously allocated buffer.
3. Image Rendering: Finally, a function named P_Image is called to parse and render the image on the screen.

The critical flaw lies in the read_jpeg_file call (04:00). This function takes a third argument intended to be a maximum size. Before reading the file, the system typically compares the file's size (obtained from its header) against this provided maximum size. If the file is larger, an error is triggered, and the read operation stops. However, in this specific invocation, the maximum size argument was set to zero. When the maximum size is zero, this size check is effectively ignored, allowing the read_jpeg_file function to read an arbitrarily large JPEG file into the fixed-size buffer, resulting in a heap overflow.

Exploiting the Mini-Heap Allocator:

To exploit this heap overflow, the researchers needed to understand the heap allocation algorithm used in Little Kernel, which is a mini-heap implementation (05:00). This mini-heap relies on a singly linked list of free chunks, all residing within the same memory pool. Each chunk's metadata consists of a pointer to the previous chunk (prev_ptr), a pointer to the next chunk (next_ptr), the chunk's size, and then the actual content area.

A heap overflow allows an attacker to overwrite the metadata of the subsequent free chunk in memory. The key to turning this into an arbitrary write primitive lies in how the allocation algorithm handles chunk removal from the free list (06:00). When a chunk is allocated, it's removed from the free list. To do this, the system dereferences the next_ptr and prev_ptr of the chunk being allocated to update the pointers of its neighbors: next_chunk->prev_ptr is set to point to prev_chunk, and prev_chunk->next_ptr is set to point to next_chunk. If an attacker can control the next_ptr and prev_ptr of a chunk that is about to be allocated (by overflowing into its metadata), they can achieve an arbitrary write. Specifically, if next_ptr points to an attacker-controlled address A and prev_ptr points to an attacker-controlled value V, then during de-allocation, *A will be overwritten with V. The only constraint is that both A and V must be readable addresses.

Achieving Code Execution:

The lack of common security mitigations in Little Kernel significantly simplified the exploit (06:00). There was no ASLR (predictable memory layout), no stack canaries (no protection against stack-based overflows), and critically, the heap was executable. This last point meant that shellcode could be placed directly on the heap and then executed.

The exploit strategy involved:

1. Shellcode Placement: The attacker crafts a malicious JPEG file that, when read, overflows the buffer. This overflowed data contains the attacker's shellcode.
2. Fake Chunk Creation: Beyond the shellcode, the overflow also overwrites the metadata of the next free chunk with a fake chunk header.
3. Arbitrary Write Trigger: In this fake chunk, the next_ptr is set to point to a return address on the stack (a predictable location due to no ASLR), and the prev_ptr is set to point to the attacker's shellcode within the JPEG buffer (07:00).
4. Execution Redirect: When the next allocation occurs, the system attempts to remove the (now fake) chunk from the free list. This operation causes the return address on the stack to be overwritten with the address of the shellcode, effectively redirecting execution flow to the attacker's code. This leads to code execution in Little Kernel (LK).

Odin Authentication Bypass:

The challenge remained: how to flash this malicious JPEG to the device's internal memory without already having privileges? This is where the Odin recovery protocol comes into play (08:00). Implemented in Little Kernel by Samsung, Odin allows flashing partitions through USB. While the official client is closed-source, an open-source client called Heimdall exists and was used in the researchers' proof of concept.

Odin usually requires images to be authenticated with a signature as a footer (09:00). This authentication relies on two internal structures:

1. Partition Information Table (PIT): Stored at a fixed address in the eMMC (embedded MultiMediaCard), the PIT provides details about partitions (e.g., block counts, names). A partition not present in the PIT cannot be flashed via Odin. The PIT itself can be updated, but this requires a signed image (10:00).
2. Global Authentication Array: A global array within the system indicates which partitions must be authenticated (10:00). If a partition is not listed in this array, it will not be authenticated.

By comparing the PIT entries with the global authentication array, the researchers identified a list of partitions that could be flashed without any authentication (10:00). Crucially, while the upper parttion (containing JPEGs) is authenticated, two other partitions, PGT (Primary GUID Partition Table) and SGT (Secondary GUID Partition Table), were found to be flashable without authentication. These partitions point to the header of the GUID Partition Table (GPT).

The GPT, similar to the PIT, describes the device's partitions. This discovery yielded a powerful primitive: without authentication, via the USB cable, an attacker could reshape the partition table of the device by flashing modified PGT/SGT entries (11:00). The PIT is used for Samsung-specific features like Odin and JPEG loading, while the GPT is used for general system operations, such as loading Android images. By manipulating the GPT, the researchers could effectively change the definition and location of the upper parttion in the PIT, pointing it to a controlled area. This allowed them to then flash their malicious JPEG, triggering the heap overflow and achieving code execution.

The combined chain of four vulnerabilities (Odin authentication bypass via GPT manipulation, leading to flashing of malicious JPEG, triggering heap overflow, leading to code execution in LK) ultimately allowed them to leak memory from the secure world, including key store keys (12:00).

Demo / Proof of Concept

▶ Watch: Transforming heap overflow into an arbitrary write primitive (5:30)

While the talk did not feature a live, explicit video demonstration of the exploit chain in action, the presenters clearly outlined the methodology and stated the successful outcome of their proof-of-concept. The core demonstration revolved around the ability to:

1. Flash modified GPT headers (PGT/SGT) via USB without authentication: This was achieved using an open-source client like Heimdall, which interacts with the Odin protocol. By manipulating these headers, they effectively reshaped the device's partition table.
2. Deploy a malicious JPEG file: After reshaping the partition table to point the "upper parttion" to a controlled location, they could then flash a crafted JPEG file. This JPEG file contained the heap overflow payload and shellcode.
3. Achieve Little Kernel (LK) code execution: The specially crafted JPEG, when parsed by the vulnerable LK JPEG parser, triggered the heap overflow, leading to arbitrary code execution within the bootloader.
4. Leak secure world memory: With code execution in LK, they demonstrated the capability to read sensitive data from the device's secure world, specifically confirming the leakage of key store keys. This step likely involved using their shellcode to read from specific memory regions and exfiltrate the data, possibly back over USB.

The entire chain, from physical USB connection to the device to the exfiltration of secure world secrets, was presented as a functional proof of concept, highlighting the severe implications for affected devices.

Defensive Implications

▶ Watch: Exploiting LK due to lack of mitigations for code execution (7:00)

The detailed attack chain presented by Rafael and Maxime offers crucial insights for device manufacturers, security researchers, and end-users regarding the security posture of mobile devices, particularly those in the low-to-mid-range segment.

Firstly, the most immediate defensive implication for users of affected Samsung Galaxy A-series devices based on MediaTek SoCs is to update their device firmware immediately. Samsung was informed of these vulnerabilities and has since released fixes (12:00, 14:00). Regular software updates are paramount to patching known security flaws.

For device manufacturers, the research underscores several critical areas for improvement:

1. Implement Robust Memory Safety Mitigations: The glaring absence of basic memory safety mitigations in Little Kernel (LK) and ARM Trusted Firmware (ATF) was a key enabler for the heap overflow exploit (06:00, 12:00). Manufacturers must integrate:

• Address Space Layout Randomization (ASLR): To randomize memory addresses, making it difficult for attackers to predict the location of stack return addresses or shellcode.
• Data Execution Prevention (DEP) / No-Execute (NX) bits: To mark memory regions (like the heap) as non-executable, preventing the execution of attacker-injected code.
• Stack Canaries: To detect and prevent stack-based buffer overflows.
• Hardened Heap Allocators: Modern heap allocators often include metadata integrity checks and other protections against heap exploitation techniques.

1. Strict Input Validation for Parsers: The root cause of the heap overflow was a lack of proper input validation in the JPEG parser when the max_size parameter was set to zero (04:00). All code that processes external or untrusted input, especially in early boot stages, must implement rigorous size checks, bounds checks, and format validation to prevent overflows and other memory corruption vulnerabilities. This applies not just to image parsers but any component handling external data.

1. Comprehensive Signature Verification: The Odin authentication bypass highlighted a critical flaw where seemingly non-critical partitions (PGT/SGT) could be flashed without signature verification (10:00). All critical components and data archives, regardless of their perceived importance (e.g., logo files), must be cryptographically signed and their signatures rigorously checked at every boot stage before use. The fact that the logo archive was signed but never checked at boot was a significant oversight (04:00).

1. Layered Security and Principle of Least Privilege: The ability to reshape the partition table via unauthenticated GPT flashing is a powerful primitive that should not be accessible without strong authentication. Critical boot components and protocols like Odin should enforce the principle of least privilege, ensuring that only absolutely necessary operations can be performed at each stage, and always with the highest level of security scrutiny.

1. Thorough Code Review and Fuzzing: The researchers explicitly stated that the vulnerabilities were "quite simple" and "could have been easily spotted through code reviews and maybe fuzzing" (12:00). This underscores the importance of continuous and exhaustive security auditing, static analysis, and dynamic fuzzing of all bootloader components, especially those that are custom-developed or modified by device manufacturers.

1. Secure World Isolation: Even with compromises in the normal world, the secure world is designed to protect critical assets. The leakage of key store keys indicates that the isolation between the normal and secure worlds was not sufficiently robust in this scenario. Manufacturers must ensure that sensitive data within the secure world remains protected, even if the normal world or bootloader is compromised, through stronger memory isolation, access control, and secure memory regions. The question of whether attestation keys could also be leaked further emphasizes the need for robust secure world design.

Key Takeaways

• A complex chain of four vulnerabilities enabled full control over Samsung Galaxy A-series devices with MediaTek SoCs, allowing for the leakage of secure world secrets, including key store keys.
• A critical heap overflow vulnerability in Samsung's customized Little Kernel (LK) bootloader, specifically within its JPEG parser, was the entry point for arbitrary code execution due to a bypassed size check (max_size=0).
• The absence of standard memory safety mitigations in LK, such as ASLR, stack canaries, and non-executable heap, significantly simplified the exploitation of the heap overflow into arbitrary code execution.
• An authentication bypass in Samsung's Odin recovery protocol allowed attackers to unauthentically flash GUID Partition Table (GPT) headers (PGT/SGT) via USB, enabling the reshaping of the device's partition table and subsequent deployment of malicious JPEG files.
• The entire exploit chain is persistent, surviving device reboots and factory resets, and impacts devices even if their initial boot ROM vulnerabilities have been patched, broadening the attack surface.
• This research highlights the critical importance of rigorous code reviews, comprehensive fuzzing, and the implementation of robust memory safety mitigations and strong authentication checks across all stages of the secure boot process in mobile devices.

About the Speaker(s)

The research presented in this talk was initiated at Qlab. The presentation was delivered by Rafael and Maxime, with Maxime introducing himself and Rafael as his co-speaker at the beginning of the talk. They also acknowledged their colleagues and Gabriel for their contributions to the project. Specific titles or company affiliations beyond Qlab were not explicitly stated within the provided transcript.