Reverse Engineering Android TrustZone OS & Trusted Applications: A Deep Dive Lab

Introduction to Android TrustZone & TEE

The ARM TrustZone technology provides a hardware-enforced isolation mechanism within System-on-Chips (SoCs), dividing the system into two virtual worlds: the Normal World and the Secure World. In Android, this secure environment is often referred to as the Trusted Execution Environment (TEE). The TEE hosts a Secure Operating System (Secure OS) and Trusted Applications (TAs), which handle sensitive operations like cryptographic key management, biometric authentication, DRM, and secure boot. Reverse engineering these components is crucial for understanding the true security posture of an Android device and uncovering potential vulnerabilities that could compromise its root of trust.

This article provides an expert-level guide to setting up a lab, extracting TEE firmware and Trusted Applications, and performing static and dynamic analysis to understand their inner workings and identify potential attack surfaces. We will focus on methodologies applicable to common TEE implementations like Qualcomm’s QSEE and OP-TEE.

Understanding the TrustZone Architecture on Android

Before diving into practical steps, it’s vital to grasp the core components:

Normal World: Runs the standard Android OS (Linux kernel, user space applications).
Secure World: Runs the Secure OS (e.g., QSEE, OP-TEE) and Trusted Applications.
Monitor Mode: A special ARM CPU mode responsible for switching between Normal and Secure worlds.
Trusted Applications (TAs): Small, isolated programs running in the Secure World, invoked by Client Applications (CAs) in the Normal World via a TEE Client API.

Common TEE Implementations

While the TrustZone concept is ARM-defined, its implementations vary:

Qualcomm Secure Execution Environment (QSEE): Prevalent on Snapdragon-based devices. TAs often have a .mbn or .elf extension.
OP-TEE: An open-source TEE implementation, often found on Mediatek or other non-Qualcomm platforms. TAs typically use a .ta extension.

Setting Up Your Reverse Engineering Lab

A well-equipped lab is fundamental for this deep dive. Here’s what you’ll need:

Rooted Android Device: An older device with a known TEE implementation (e.g., an older Pixel, OnePlus, or a device with an unlocked bootloader). Root access is essential for dumping partitions.
ADB (Android Debug Bridge): For device interaction.
Disassembler/Decompiler: IDA Pro or Ghidra (highly recommended for ARM64 analysis).
Binary Analysis Tools: binwalk, readelf, strings, hexdump.
Frida: For dynamic instrumentation (primarily for Normal World interaction with TEE).
Linux Workstation: Ubuntu or Debian preferred.

Prerequisites Checklist:

Ensure ADB is installed and your device is recognized:adb devices
Confirm root access on your device:adb shellsu -c id

Install `binwalk` on your workstation:


sudo apt update && sudo apt install binwalk

Extracting TrustZone Components

Identifying TEE Partitions

The Secure OS firmware is typically located in dedicated partitions. Common names include tz, hyp, sbl, modem, or firmware within the /vendor partition.

To list partitions on your device:


adb shellsu -c 'ls -l /dev/block/by-name/'

Look for partitions named `tz`, `sbl1`, `hyp`, `modem`, or similar. For example, on a Qualcomm device, `tz` might contain the QSEE firmware.

Dumping TEE Firmware

Once identified, dump the raw partition image:


adb shellsu -c 'dd if=/dev/block/by-name/tz of=/data/local/tmp/tz.img'adb pull /data/local/tmp/tz.img .

Repeat this for any other suspicious partitions. These images will be the target for `binwalk` analysis.

Extracting Trusted Applications (TAs)

Trusted Applications are usually stored in specific directories within the Normal World file system, often encrypted or obfuscated. Common paths include:

/vendor/firmware/
/vendor/firmware_mnt/image/
/system/vendor/firmware/

List and pull them:


adb shellsu -c 'ls -lR /vendor/firmware_mnt/image/'adb pull /vendor/firmware_mnt/image/ <local_directory>

Look for files with extensions like `.mbn`, `.elf`, `.signed`, or `.ta`. TAs often have a unique 128-bit GlobalPlatform UUID embedded or as part of their filename.

Analyzing TEE Firmware and Trusted Applications

Initial Firmware Analysis with Binwalk

Use `binwalk` to identify embedded files, compression, or cryptographic signatures within the dumped firmware images:


binwalk -ev tz.img

This command extracts known file types and attempts to decompress them. You might find embedded bootloaders, secure kernel modules, or configuration data. Look for ARM binaries (ELF files).

Static Analysis of Trusted Applications (IDA Pro / Ghidra)

This is where the real reverse engineering begins. Load the extracted TA files into your disassembler:

Identify Architecture: Most modern TEEs run on ARM64. Configure your disassembler accordingly.
Entry Points: For GlobalPlatform TEE-compliant TAs, common entry points include TA_CreateEntryPoint, TA_OpenSessionEntryPoint, TA_InvokeCommandEntryPoint, TA_CloseSessionEntryPoint, and TA_DestroyEntryPoint. These functions handle the lifecycle and command dispatch for the TA.
TA_InvokeCommandEntryPoint: This is the most critical function. It typically contains a switch-case or a series of conditional branches that dispatch to specific internal functions based on a command ID (cmd_id) passed from the Client Application. This is where the TA’s core logic resides.
Input/Output Buffers: Pay close attention to how the TA handles input and output buffers (params argument). Look for classic vulnerabilities like buffer overflows, integer overflows, or format string bugs when copying data to or from these buffers.
Cryptographic Routines: TAs frequently implement cryptographic operations. Identify calls to `TEE_CRYPTO_xxx` functions or analyze custom implementations for weaknesses.
Memory Management: Examine how memory is allocated (e.g., `TEE_Malloc`, `TEE_Free`) and used. Use-after-free or double-free vulnerabilities are common.

Example C pseudo-code for a CA-TA interaction:


// Normal World Client Application (CA) pseudo-code#include <tee_client_api.h>#define TA_HELLO_WORLD_UUID { 0x8aa8d084, 0x5109, 0x4f17, { 0xbb, 0xbc, 0xeb, 0xd0, 0xb6, 0x8a, 0x8c, 0xcb } }#define CMD_SET_DATA 0x01#define CMD_GET_DATA 0x02void main() {    TEEC_Context context;    TEEC_Session session;    TEEC_Result res;    TEEC_UUID uuid = TA_HELLO_WORLD_UUID;    TEEC_Operation op;    uint32_t err_origin;    char input_data[] =
        
        
        
            
                
            
            
                Android Mobile Specs & Compare Directory
                Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →