Introduction to TrustZone TEE and Hardware Reverse Engineering

ARM TrustZone technology is a system-wide security extension present in most modern ARM processors, providing a hardware-isolated environment known as the Trusted Execution Environment (TEE). This secure world runs a Trusted OS (e.g., OP-TEE, Trusty, QSEE) and hosts sensitive operations like cryptographic key management, secure boot, and digital rights management (DRM). Reversing the TEE firmware is crucial for security research, vulnerability discovery, and understanding device security postures, but it’s notoriously challenging due to its isolation from the normal world operating system.

While software-based attacks often face significant hurdles from TEE’s robust isolation mechanisms, hardware-assisted techniques, particularly those leveraging JTAG (Joint Test Action Group) or SWD (Serial Wire Debug) interfaces, offer a powerful avenue for low-level access. These interfaces provide direct CPU control, memory access, and debugging capabilities, often bypassing software-level security measures once physical access is achieved.

Prerequisites for Hardware-Assisted TEE Firmware Dumping

Before diving into the process, ensure you have the following:

• Target Device: An Android device or embedded system with an accessible ARM processor supporting TrustZone.
• JTAG/SWD Adapter: A compatible hardware debugger (e.g., J-Link, ST-Link, Bus Pirate, or an FT2232H-based adapter with OpenOCD support).
• Soldering Equipment: Fine-tip soldering iron, flux, solder, and thin wires for connecting to test points.
• Multimeter: For continuity checks and identifying pinouts.
• Software: OpenOCD, GDB (ARM-none-eabi-gdb), and a disassembler/decompiler like IDA Pro or Ghidra for post-dump analysis.

Identifying JTAG/SWD Pins on the Target Device

The most critical step is locating and connecting to the JTAG/SWD pins. These are often exposed as test points on the PCB, though sometimes they require more invasive techniques like decapping the chip and wire-bonding.

Methods for Pin Identification:

1. Schematics and Datasheets: The most straightforward method, if available. Check for `JTDI`, `JTDO`, `JTCK`, `JTMS`, `TRST` (JTAG) or `SWDIO`, `SWCLK` (SWD).
2. Visual Inspection: Look for clusters of small, unpopulated pads or test points near the main SoC. JTAG usually has 4-5 core signals; SWD has 2.
3. Resistance Measurement: With the device powered off, measure resistance between suspected pads and ground. Often, JTAG/SWD pads have a characteristic pull-up/down resistance.
4. Continuity Check: Trace suspicious pads to the SoC pins. Consult the SoC datasheet for potential JTAG/SWD pin locations.
5. Side-Channel Attacks / Glitching: More advanced techniques may involve power analysis or fault injection to force the SoC into a debug mode that reveals pin functionality.

Once identified, carefully solder thin wires from your JTAG/SWD adapter to these test points. Ensure stable connections to `VTref` (target voltage reference) and `GND` as well.

Configuring OpenOCD for Target Communication

OpenOCD (Open On-Chip Debugger) is an open-source tool that provides debugging, in-system programming, and boundary-scan testing for embedded systems. You’ll need a configuration file (`.cfg`) specific to your JTAG/SWD adapter and target SoC.

Example OpenOCD Configuration (Generic ARM Cortex-A):

# Adapter configuration (e.g., FT2232H-based JTAG/SWD adapter)i
interface ft2232
ft2232_device_desc "Dual RS232-HS"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0x6010

# JTAG/SWD speed
jtag_rclk_delay 1
adapter_khz 10000

# Target connection
set _TARGETNAME cortexa
cpu_type cortex_a

# Target specific setup
# Assuming a single core ARM Cortex-A processor
source [find target/arm_cortex_a.cfg]

# Or for specific devices, you might need to manually define
# target create $_TARGETNAME cortex_a -endian $_ENDIAN -chain-position $_TARGETNAME
# $_TARGETNAME configure -event reset-init { 
#    # Optional: Perform any necessary initialization steps after reset
#    # e.g., enabling caches, setting up memory controllers if needed for full memory access
# }

# TrustZone awareness is crucial. OpenOCD can operate in both secure and non-secure states.
# The default state upon connect might be non-secure. To access secure memory, 
# you might need to switch to the secure state or use specific memory access commands.
# For dumping, a direct hardware debugger often bypasses the need for explicit state switching for physical memory addresses.

Save this as `openocd.cfg`. Modify `interface` and `ft2232_vid_pid` to match your actual adapter. You might also need to find or create a specific `target/YOUR_SOC_NAME.cfg` if the generic `arm_cortex_a.cfg` doesn’t provide sufficient detail for your specific SoC’s memory map or peripherals.

Running OpenOCD:

openocd -f openocd.cfg

If successful, OpenOCD will start and report that it has connected to the target. It usually opens a telnet server on port 4444 and a GDB server on port 3333.

Dumping TEE Firmware Memory

With OpenOCD running, you can connect via telnet to issue commands directly. The primary goal is to identify the physical memory regions where the TEE OS and Trusted Applications reside and then dump them.

Identifying TEE Memory Regions:

This is often the most challenging part. TEE firmware is usually loaded into specific physical memory regions that are isolated at runtime. Clues can be found in:

• Device Tree Blobs (DTB): If you can extract the DTB from a normal world kernel, it might contain memory reserved for the TEE. Look for `optee`, `trusty`, or `secure-memory` entries.
• Bootloader Logs: Sometimes early boot logs reveal memory allocation details.
• Known Architectures: Research typical TEE memory layouts for your specific SoC family (e.g., Qualcomm QSEE often starts around 0x86000000 or 0x04000000).

Once you have a probable base address and size for the TEE’s memory region, you can attempt to dump it.

Dumping Commands via OpenOCD Telnet (port 4444):

1. Halt the CPU: First, you need to halt the CPU to ensure a consistent memory state during the dump.halt
2. Dump Memory Region: Use the `dump_image` command. Specify an output filename, the starting physical address, and the size in bytes.dump_image tee_os.bin 0x04000000 0x1000000

   (This example dumps 16MB starting from address 0x04000000. Adjust address and size based on your target’s TEE memory map.)

3. Read Individual Words (if dump_image fails or for smaller checks):mdw 0x04000000 100

   (Reads 100 32-bit words from address 0x04000000)

4. Resume CPU (after dumping):resume

Important Considerations:

• Memory Protection: While JTAG/SWD offers deep access, some SoCs might have very early hardware-level memory protection units (MPUs) or memory management units (MMUs) configured by the secure boot process that restrict even JTAG access to certain secure memory regions. In such cases, you might need to find vulnerabilities in the secure boot chain or TEE itself to disable these protections or trick the TEE into granting access.
• Power Management: Ensure the device remains powered and stable throughout the dumping process.
• Error Handling: If `dump_image` fails, check OpenOCD’s output for errors. This could indicate an incorrect address, size, or an issue with the JTAG connection.

Post-Dumping Analysis

Once you have the raw binary dump (`tee_os.bin`), you can load it into reverse engineering tools:

• IDA Pro / Ghidra: Load the binary at its identified base address (e.g., 0x04000000). Configure the processor type (ARM 32-bit or 64-bit, Thumb mode) and look for entry points, function calls, and data structures.
• String Analysis: Look for readable strings, API calls, and cryptographic constants that can give clues about the TEE’s functionality.
• Signature Identification: Some TEEs (like OP-TEE) have identifiable magic numbers or structures that can help you confirm what you’ve dumped.

Conclusion

Hardware-assisted TrustZone TEE firmware dumping via JTAG/SWD is a powerful, albeit challenging, technique for gaining unparalleled insight into a device’s secure execution environment. By carefully identifying debug pins, configuring OpenOCD, and understanding the target’s memory architecture, researchers can extract TEE binaries for in-depth analysis. This process is fundamental for advanced security research, enabling the discovery of critical vulnerabilities that might otherwise remain hidden within the secure world.