Introduction to ARM TrustZone and TEE Firmware Extraction

ARM TrustZone technology provides a hardware-enforced isolation mechanism on System-on-Chips (SoCs), dividing the system into two distinct worlds: the Normal World and the Secure World. The Secure World hosts a Trusted Execution Environment (TEE), which runs a secure OS and executes Trusted Applications (TAs) to handle sensitive operations like cryptographic key management, DRM, and secure authentication. Extracting the firmware from these TEEs is a critical step in security research, vulnerability assessment, and reverse engineering, allowing researchers to analyze the secure OS and TAs for potential weaknesses.

However, the extraction process is rarely straightforward, fraught with challenges ranging from hardware-level protections to intricate software obfuscation and proprietary formats. This article outlines a systematic troubleshooting methodology, akin to a ‘script’ of steps and checks, to overcome common hurdles encountered during TrustZone TEE firmware extraction.

Prerequisites and Essential Tools

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

• Target Device: An Android device with an accessible bootloader or root privileges (preferred).
• Development Machine: A Linux-based system (Ubuntu/Kali recommended) with ADB, Fastboot, and common reverse engineering tools.
• Basic Tools:dd, binwalk, hexdump (or xxd), file, strings.
• Advanced Tools: Disassembler/Decompiler (IDA Pro, Ghidra), Hex editor (010 Editor).
• Knowledge: Familiarity with ARM architecture, Linux command line, and basic reverse engineering concepts.

Phase 1: Initial Access and Data Acquisition Challenges

H3: Gaining Device Access

The first hurdle is often gaining sufficient access to the device to read partitions. This typically involves unlocking the bootloader or achieving root access. Without these, direct partition dumping is usually impossible.

• Locked Bootloader: If the bootloader is locked, check for manufacturer-specific unlock procedures (e.g., fastboot oem unlock) or search for known exploits. Be aware this often wipes user data and may void warranties.
• Root Access: Obtain root using methods like Magisk or known kernel exploits. Root access allows privileged commands, crucial for accessing raw device partitions.

H3: Identifying TEE Partitions

Once you have access, locate the TEE firmware partition. Common partition names include tee, trustzone, tz, modem_efs (for Qualcomm QSEE), or vendor-specific names like sboot (Samsung).

Use lsblk or check /proc/partitions and /dev/block/by-name/ to list available partitions and their corresponding device paths:

adb shell
ls -l /dev/block/platform/*/by-name/

Look for names that suggest a secure environment. For example:

lrwxrwxrwx root     root              2018-01-01 00:00 sboot -> /dev/block/mmcblk0pX
lrwxrwxrwx root     root              2018-01-01 00:00 tz -> /dev/block/mmcblk0pY

H3: Raw Partition Dumping Issues

The standard method for extraction is using dd. However, this can fail due to read permissions or device integrity checks.

# On device (if rooted)
dd if=/dev/block/mmcblk0pY of=/data/local/tmp/tz.img

# Or pull from recovery/bootloader (if available)
# fastboot boot custom_recovery.img
# adb pull /dev/block/mmcblk0pY tz.img

• Permission Denied: Ensure you are running dd as root. If adb shell su -c 'dd ...' fails, try booting into a custom recovery or a modified boot image with root access.
• Read Errors / Bad Blocks: Some secure storage areas might intentionally cause read errors. In such cases, consider JTAG/SWD access (if not fused off) or direct eMMC/UFS chip-off forensics if software methods completely fail.
• dm-verity / Secure Boot: These mechanisms might prevent modification or even reading of critical partitions if they detect tampering. Ensure you are operating in a state where these are bypassed or disabled (e.g., unlocked bootloader, custom kernel).

Phase 2: Firmware Format Analysis and Initial Triage

H3: Identifying Firmware Type and Structure

Once you have a raw dump, the next step is to understand its format. TEE firmwares come in various forms, including generic ELF files, proprietary formats, or images specific to TEE OSes like OP-TEE, Trusty TEE, or Qualcomm’s QSEE.

Start with basic file identification tools:

file tz.img
binwalk tz.img
strings tz.img | less

• file command: May identify it as an ELF executable (32-bit or 64-bit ARM), data, or unknown binary.
• binwalk: Crucial for identifying embedded file systems, compression, and common file signatures within the image. Look for ELF headers, ARM code, or known TEE OS signatures.
• strings: Can reveal human-readable text, error messages, function names, or version information that hints at the TEE OS or device.

Example binwalk output for a QSEE image might show:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Qualcomm QSEE Trusted Execution Environment header
256           0x100           ELF, 32-bit LSB relocatable, ARM, version 1
... (more ELF sections, possibly TAs)

H3: Dealing with Proprietary Headers and Encryption

Many vendors wrap their TEE firmware in proprietary headers or encrypt parts of it.

• Header Analysis: If binwalk identifies a proprietary header, you’ll need to manually analyze it with a hex editor (e.g., 010 Editor, HxD). Look for magic bytes, lengths, offsets, and checksums. These headers often contain information about the TEE’s entry point, load address, and size.
• Encryption: This is often the most significant barrier. If the firmware is encrypted, direct analysis is impossible until decrypted.

Troubleshooting Encryption:

1. Look for decryption routines: If you have access to other parts of the device’s firmware (bootloader, kernel), search for code that loads and decrypts the TEE image. The decryption key might be hardcoded, derived from device-specific identifiers, or fetched from secure hardware.
2. Memory Dumps: If you can achieve execution on the device (e.g., via JTAG/SWD or a kernel exploit), attempt to dump the TEE’s memory region *after* it has been loaded and decrypted by the bootloader or secure monitor. This gives you the plaintext firmware.
3. Hardware Attacks: For highly secure devices, advanced techniques like fault injection (glitching) or side-channel analysis might be necessary to extract keys or bypass decryption. This requires specialized equipment and expertise.
4. Public Research: Check if other researchers have published details about the specific device or SoC’s TEE encryption scheme.

Phase 3: Post-Extraction and Analysis Refinement

H3: Loading into Disassemblers and Relocation Issues

Once you have a potentially decrypted or unwrapped firmware image (preferably an ELF), load it into IDA Pro or Ghidra.

• Correct Architecture: Ensure you select the correct ARM architecture (ARMv7, ARMv8/AArch64) and endianness (usually little-endian).
• Load Address: The firmware is often designed to load at a specific memory address (its ‘base address’). If you load it at 0x0, cross-references and function calls will be incorrect. You might find the load address in the proprietary header, device tree (DTS), or bootloader code. Common TEE base addresses are around 0x80000000 or 0x40000000 in the secure memory map.
• Relocation: If the firmware is a relocatable ELF (ET_REL), symbols might not be resolved until linked. If it’s a fixed-address image without ELF sections, you’ll have to manually define code and data sections.

Example: Setting base address in IDA Pro during initial load:

Processor Type: ARM (32-bit) / ARM64 (64-bit)
Loading address: 0xXXXXXXXX (e.g., 0x40000000 or 0x80000000)

H3: Identifying Trusted Applications (TAs)

TEE firmwares often contain multiple Trusted Applications. These might be embedded as separate ELF files within the TEE image, loaded dynamically, or statically linked.

• Look for distinct ELF headers or specific TA magic bytes within the TEE firmware.
• OP-TEE TAs typically have a UUID (Universally Unique Identifier) in their header.
• Trusty TEE TAs are often linked as individual binaries.

Use binwalk -e tz.img to automatically extract embedded files, or manually scan with a hex editor for ELF magic bytes (7F 45 4C 46) or known TA headers.

Conclusion

Troubleshooting TrustZone TEE firmware extraction requires a methodical approach, combining low-level hardware understanding with software reverse engineering skills. From gaining initial device access and identifying the correct partitions to analyzing proprietary formats, decrypting encrypted blobs, and correctly loading the firmware into a disassembler, each step presents unique challenges. By systematically applying the techniques outlined in this guide – utilizing tools like dd, binwalk, hex editors, and disassemblers, while understanding common protection mechanisms – researchers can significantly improve their success rate in extracting and analyzing secure world firmware, ultimately contributing to a better understanding of device security.