Introduction to TrustZone and TEE

ARM’s TrustZone technology is a foundational security feature embedded in modern System-on-Chips (SoCs), creating two isolated execution environments: the Normal World and the Secure World. The Normal World, where operating systems like Android or Linux run, is less privileged. The Secure World hosts the Trusted Execution Environment (TEE), which executes sensitive operations like cryptographic key management, secure boot, and digital rights management (DRM) within Trusted Applications (TAs).

While software vulnerabilities in the Normal World are common targets, exploiting the TEE often requires a deeper understanding and, crucially, hardware-level access. This guide will walk you through the fascinating realm of hardware exploitation to compromise a TrustZone TEE, focusing on using JTAG/SWD for direct memory access and runtime manipulation.

Why Hardware Exploitation?

Hardware exploitation provides unique advantages. It allows an attacker to bypass software-enforced security mechanisms, directly observe and manipulate the processor’s state, memory, and peripherals, often even when the system is in a secure boot state or during the execution of sensitive Secure World code. This level of access is often the only way to uncover or exploit vulnerabilities in a hardened TEE.

Prerequisites and Target Selection

Knowledge Prerequisites:

• Basic understanding of ARM architecture and assembly.
• Familiarity with TrustZone concepts (Secure/Normal World, Monitor Mode, EL0-EL3).
• Basic understanding of JTAG/SWD debugging.
• Familiarity with Linux command line.

Hardware Prerequisites:

• A target device with ARM TrustZone (e.g., an Android phone, IoT device, or development board). For your first exploit, a development board (like a Raspberry Pi 3/4 or a specific evaluation kit with exposed JTAG) is highly recommended due to easier access to debug pins.
• A JTAG/SWD debugger (e.g., Segger J-Link, ST-Link, Bus Pirate, or an FTDI-based programmer with OpenOCD support).
• Jumper wires and possibly a soldering iron for connecting to small debug pads.

Software Prerequisites:

• OpenOCD (Open On-Chip Debugger).
• ARM GNU Embedded Toolchain (for `arm-none-eabi-gdb`).
• IDA Pro or Ghidra for static analysis (optional, but highly recommended).

Setting up your Hardware Debugger (JTAG/SWD)

The first step is gaining physical access to the debug interface. Most SoCs expose JTAG (Joint Test Action Group) or SWD (Serial Wire Debug) pins, though they might be unpopulated or hidden under test points. You’ll need to locate these on your target device’s PCB.

1. Locating Debug Headers:

Look for unpopulated pin headers (often 10-pin or 20-pin) or small test points labeled with JTAG/SWD signals (e.g., TDI, TDO, TCK, TMS for JTAG; SWDIO, SWCLK for SWD). Datasheets and schematics for development boards are invaluable here. For consumer devices, this often involves physical inspection, X-ray analysis, or searching online forums.

2. Connecting with OpenOCD:

Once identified, carefully solder wires or use pogo pins to connect your debugger to the target. For this guide, we’ll assume a JTAG connection using an FTDI-based programmer (like an FT2232H Mini Module) and OpenOCD.

# Example OpenOCD configuration for an FTDI JTAG adapter and generic ARM Cortex-A
# Save this as `openocd.cfg`
source [find interface/ftdi/jtag-lock-pick-tiny-2.cfg]

# Adjust for your specific ARM core. Check OpenOCD docs for your target.
source [find target/cortex_a.cfg]

target create $_TARGETNAME cortex_a -endian $_ENDIAN -chain-position $_CHAINPOSITION
$_TARGETNAME configure -work-area-phys 0x40000000 -work-area-size 0x4000

init
# Reset the target and halt
reset halt

Run OpenOCD:

openocd -f openocd.cfg

In a separate terminal, connect GDB:

arm-none-eabi-gdb
(gdb) target remote localhost:3333

Initial Reconnaissance: Dumping Secure World Memory

With JTAG access, we can now interact with the CPU. Our goal is to gain insight into the Secure World’s operation, which often starts with dumping its memory. TrustZone partitions memory, and initially, our debugger might only see the Normal World view. To access Secure World memory, we often need to halt the CPU while it’s in Secure Monitor or Secure World state, or manipulate its state via JTAG.

1. Halting the CPU:

If your `openocd.cfg` includes `reset halt`, the CPU should be halted immediately after power-up. If not, you can halt it from GDB:

(gdb) monitor reset halt

Or directly from OpenOCD’s telnet interface (port 4444 by default):

telnet localhost 4444
> halt

At this point, the CPU is paused. We can inspect registers and memory.

2. Memory Read Commands:

To identify Secure World memory regions, you might need to consult public documentation for your SoC or observe bootloader behavior. Common TEE OSes (like OP-TEE, Trusty) often reside in specific high memory addresses. Let’s assume a TEE OS is loaded at `0x40000000`.

From OpenOCD telnet:

> dump_image tee_os_dump.bin 0x40000000 0x100000 # Dumps 1MB from 0x40000000

This will save the raw binary image. You can then load this into Ghidra or IDA Pro for static analysis to understand the TEE’s structure and identify Trusted Applications.

Identifying Vulnerable TEE Components

After dumping the TEE OS and potentially embedded TAs, static analysis becomes crucial. Look for:

• Trusted Application (TA) Identifiers: TAs are often identified by UUIDs. Find where these are registered or used.
• Input/Output Buffers: How do Normal World applications communicate with TAs? Look for shared memory structures or IPC mechanisms.
• Sensitive Functions: Cryptographic operations, key storage, secure boot checks, DRM functions.
• Parsing Logic: Code that parses input from the Normal World is a common source of vulnerabilities (buffer overflows, integer overflows).

Our hypothetical exploit will target a simple integrity check within a TA. Imagine a TA that checks a ‘secure_boot_flag’ in memory before allowing a critical operation.

Crafting the Exploit: Runtime Modification

For a first hardware exploit, we’ll aim for a direct runtime modification. Let’s assume through static analysis, we’ve identified a `secure_flag` variable at address `0x40001234` within the TEE’s data segment, and it’s checked by a TA before performing a critical operation. Initially, this flag is `0` (indicating an insecure state). We want to change it to `1` to bypass the check.

Scenario: Bypassing a Secure Boot Flag

Let’s say a Trusted Application checks a boolean flag `is_secure_boot_completed` which is located at `0x40001234`. The Normal World application tries to call a secure function in the TA, but it fails because `is_secure_boot_completed` is `0`. We want to change it to `1` directly via JTAG.

Step-by-Step Walkthrough with OpenOCD

1. Connect and Halt:

# In terminal 1 (OpenOCD server)
openocd -f openocd.cfg

# In terminal 2 (OpenOCD telnet client)
telnet localhost 4444
> halt

Confirm the CPU is halted. You might see register dumps.

2. Read Current Flag Value:

We’ll read 4 bytes (a word) from our target address `0x40001234`.

> mdw 0x40001234 1

This command reads one word (4 bytes) at address `0x40001234`. You should see the current value, which we assume is `0x00000000`.

3. Write New Flag Value:

Now, we’ll write `1` (0x00000001) to that address.

> mww 0x40001234 0x1

You can re-read the value to confirm the write:

> mdw 0x40001234 1

It should now show `0x00000001`.

4. Resume Execution:

Once the memory is modified, we can resume the CPU’s execution.

> resume

The system will now continue its operation. The TA, when it next checks the `is_secure_boot_completed` flag, will find it set to `1`, thus bypassing the intended security check.

Verifying the Exploit

After resuming, trigger the Normal World application that calls the targeted secure function. If the exploit was successful, the application should now be able to perform the critical operation that was previously blocked. This demonstrates a successful bypass of a TEE security check via direct hardware manipulation.

Conclusion

This guide provided a hands-on approach to understanding and executing a basic TrustZone TEE hardware exploit. By leveraging JTAG/SWD, we gained unparalleled access to the Secure World, allowing us to halt the CPU, inspect memory, and even modify runtime values to bypass a hypothetical security flag. This fundamental technique is the bedrock for more complex hardware attacks, including fault injection, side-channel analysis, and deeper firmware reverse engineering.

Remember that hardware exploitation is a powerful skill. Always ensure you have proper authorization before testing on any device. Ethical hacking and responsible disclosure are paramount in contributing positively to the security ecosystem.