Introduction to ARM TrustZone and Qualcomm QSEE

The ARM TrustZone technology partitions a system-on-chip (SoC) into two execution environments: the Normal World and the Secure World. This hardware-enforced isolation is fundamental to securing sensitive operations, such as cryptographic key management, biometric authentication, and digital rights management (DRM). Qualcomm’s implementation of the Secure World is known as the Qualcomm Secure Execution Environment (QSEE), which includes the Secure Monitor, the QSEE Operating System (QSEE OS, formerly QTEE), and Trusted Applications (TAs) running within it.

Reverse engineering the QSEE Secure World is a critical yet challenging task for security researchers. It allows for vulnerability discovery, understanding proprietary implementations, and ensuring the integrity of secure functionalities. This case study delves into practical techniques for extracting code from the Qualcomm Secure Execution Environment, focusing on both software and hardware-assisted methodologies.

Understanding the QSEE Architecture and TrustZone States

In an ARMv8-A architecture, TrustZone is managed by the Secure Monitor at Exception Level 3 (EL3). It’s responsible for switching between the Normal World (EL1n/EL0n) and the Secure World (EL1s/EL0s). The QSEE OS typically runs at EL1s, managing resources and executing TAs which operate at EL0s. Communication between the Normal World (e.g., Android) and the Secure World occurs via a Secure Monitor Call (SMC) interface. This interface is strictly controlled to prevent unauthorized access to secure resources.

The Challenge of Code Extraction

Extracting code from QSEE is inherently difficult due to several layered security mechanisms:

• Hardware Isolation: Memory regions designated for the Secure World are inaccessible from the Normal World.
• Secure Boot: The boot chain ensures that only cryptographically signed and authenticated code executes, preventing unauthorized modification of secure components.
• Memory Protection Units (MPUs) and Memory Management Units (MMUs): These units are configured by the Secure World to enforce strict access controls.
• Debug Protections: JTAG/SWD debugging interfaces are often disabled or restricted after boot, or require specific authentication keys (e.g., via eFuses).

Software-Assisted Code Extraction Techniques

Software-based methods primarily rely on identifying and exploiting vulnerabilities within the Normal World kernel or existing Trusted Applications.

1. Leveraging Normal World Kernel Vulnerabilities

If a vulnerability exists in the Android kernel (e.g., a memory disclosure or arbitrary read/write primitive), it might be possible to access certain memory regions mapped by the QSEE driver. While direct access to Secure World memory is generally blocked, a kernel vulnerability could potentially:

• Bypass `ioctl` restrictions on TEE-related drivers to trigger a Secure World memory dump functionality that’s intended for debugging but not properly secured.
• Identify shared memory regions that, if misconfigured, could expose fragments of TA data or code.

Example of a hypothetical driver interaction (conceptual):

#include <fcntl.h> #include <sys/ioctl.h> #define TEE_IOCTL_MAGIC 'T' #define TEE_IOCTL_GET_SECURE_MEM_INFO _IOR(TEE_IOCTL_MAGIC, 0x1, struct sec_mem_info) struct sec_mem_info {    unsigned long base;    unsigned long size; }; int main() {    int fd = open("/dev/qsee_mem", O_RDWR);    if (fd < 0) {        perror("Failed to open /dev/qsee_mem");        return 1;    }    struct sec_mem_info info;    // Hypothetically, an exploit might bypass checks for this ioctl    if (ioctl(fd, TEE_IOCTL_GET_SECURE_MEM_INFO, &info) == 0) {        printf("Secure memory base: 0x%lx, size: 0x%lxn", info.base, info.size);        // Further exploitation to dump this region    } else {        perror("IOCTL failed");    }    close(fd);    return 0; } 

2. Exploiting Trusted Application (TA) Vulnerabilities

Trusted Applications are the primary targets for code extraction, as they contain the sensitive logic. Vulnerabilities within a TA, such as buffer overflows, integer overflows, or format string bugs, could be exploited to achieve arbitrary read/write within the TA’s memory space or even the QSEE OS context. If an arbitrary read primitive is achieved, the TA’s entire code segment can be dumped.

Steps involved:

1. Identify the TA’s UUID and interface via Normal World logs or binary analysis of `tee-supplicant` or related libraries.
2. Fuzz the TA’s `invoke_command` interface (the primary way to interact with TAs via SMCs).
3. Upon identifying a vulnerability, craft an exploit payload to dump memory. This might involve chaining primitives (e.g., information leak for base address, then arbitrary read for full dump).

Hardware-Assisted Code Extraction Techniques

Hardware-assisted methods offer a more direct approach but often require physical access and bypass of robust debug security features.

1. JTAG/SWD Debugging

JTAG (Joint Test Action Group) and SWD (Serial Wire Debug) are industry-standard interfaces for on-chip debugging. If these interfaces are active and debug authentication is bypassed (or non-existent), they provide powerful control over the SoC.

Steps:

1. Locate Debug Pins: Physically identify the JTAG/SWD test points on the device’s PCB. This often involves visual inspection, continuity checks, or X-ray analysis.
2. Connect Debugger: Use a hardware debugger (e.g., J-Link, OpenOCD with FT2232-based adapter, Lauterbach TRACE32) to connect to the identified pins.
3. Bypass Debug Protections: This is typically the hardest part. Qualcomm devices often have eFuses blown to permanently disable JTAG/SWD after manufacturing, or implement proprietary debug authentication protocols. Techniques might include voltage glitching, clock glitching, or cold boot attacks to temporarily disable protections, though these are advanced and beyond simple access. Assuming debug is enabled:
4. Halt the CPU: Once connected, halt the ARM core. It’s crucial to halt it while in the Secure World context (e.g., during a TA execution or while the QSEE OS is active) to ensure Secure World memory mappings are active.
5. Dump Memory: Use the debugger’s memory dump commands to read out physical memory regions. TAs are typically loaded into specific, often contiguous, memory blocks. Knowledge of the QSEE OS memory map (potentially gleaned from firmware analysis) is crucial here.

Example using OpenOCD (conceptual, specific addresses depend on the device):

# OpenOCD configuration for an ARMv8-A core target armv8.cpu configure -work-area-phys 0x10000000 -work-area-size 0x4000 target armv8.cpu configure -event-setup-succeeded { echo "CPU setup succeeded!" } init reset halt # Assuming target is halted in Secure World (EL1s or EL0s) # Dump a hypothetical TA memory region starting at 0x86000000 with size 0x20000 (128KB) dump_image ta_dump.bin 0x86000000 0x20000 exit 

2. Firmware Image Analysis

Before dynamic analysis, statically analyzing firmware images (e.g., from OTA updates, or extracted from flash storage like eMMC/UFS via chip-off) can provide invaluable insights. Tools like IDA Pro or Ghidra can disassemble the bootloaders (SBL, XBL) and the QSEE OS image itself. This can reveal:

• Memory layouts and address ranges for the Secure World components.
• SMC handler functions and their dispatch tables.
• Trusted Application loading mechanisms and their potential locations in memory.
• Weaknesses in the secure boot chain or firmware update process.

While this doesn’t directly extract running code, it provides the map needed for other extraction techniques.

Analyzing Extracted Code

Once a memory dump is obtained (either through software or hardware methods), the next step is analysis. Load the raw binary dump into a disassembler like IDA Pro or Ghidra. Key steps include:

• Identify Entry Points: Based on static analysis of the QSEE OS or TA headers, locate the entry point and reset vectors.
• Reconstruct Functions: Use the disassembler’s auto-analysis features. Manually define functions and data structures.
• Identify Libraries/APIs: Recognize calls to QSEE OS APIs or standard C library functions.
• Data Flow Analysis: Trace critical data paths, especially related to cryptographic operations, key handling, or secure sensor processing.

Conclusion

Extracting code from Qualcomm’s QSEE TEE is a complex endeavor that requires a deep understanding of ARM TrustZone, device-specific implementations, and often a combination of software and hardware skills. Whether through sophisticated software exploits leveraging kernel or TA vulnerabilities, or through direct hardware debugging, the goal remains to gain visibility into the Secure World’s logic. Each technique presents unique challenges and requires persistence, but the insights gained are crucial for advancing mobile device security research and identifying critical vulnerabilities in secure environments.