Full Report
Introduction: New types of mobile applications based on Trusted Execution Environments (TEE) and most notably ARM TrustZone micro-kernels are emerging which require new types of security assessment tools and techniques. In this blog post we review an example TrustZone application on a Galaxy S3 phone and demonstrate how to capture communication between the Android application and TrustZone OS using an instrumented version of the Mobicore Android library. We also present a security issue in the Mobicore kernel driver that could allow unauthorised communication between low privileged Android processes and Mobicore enabled kernel drivers such as an IPSEC driver.
Analysis Summary
# Research: A software level analysis of TrustZone OS and Trustlets in Samsung Galaxy Phone
## Metadata
- Authors: behrang (SensePost)
- Institution: SensePost
- Publication: SensePost Blog
- Date: June 4, 2013
## Abstract
This research provides a software-level analysis of the ARM TrustZone implementation, specifically the Mobicore micro-kernel, on the Samsung Galaxy S3. The authors demonstrate a technique for instrumenting the Mobicore Android library to intercept and capture communication flowing between the Android (Normal World) application layer and the isolated TrustZone OS (Secure World). Furthermore, the analysis uncovered a security vulnerability within the Mobicore kernel driver that permits unauthorized communication between low-privileged Android processes and trusted kernel drivers, such as those managing IPSEC functions.
## Research Objective
The primary objective was to develop and demonstrate novel security assessment techniques suitable for emerging mobile Trusted Execution Environments (TEE), particularly those utilizing ARM TrustZone like Samsung's Mobicore. A specific goal was to characterize the communication mechanism between the Normal World (Android) and the Secure World (Mobicore/Trustlets) and to identify potential security weaknesses in the Mobicore implementation.
## Methodology
### Approach
The methodology involved reverse engineering and instrumentation of the Mobicore components running on the target device. This included modifying the Mobicore components, recompiling the kernel, and observing resulting behavior via verbose device driver logs. Fuzzing techniques were subsequently applied to test input validation within the communication channel.
### Dataset/Environment
The primary environment studied was a **Samsung Galaxy S3 phone**, running an operating system that leverages the **ARM TrustZone** architecture via the **Mobicore micro-kernel** developed by Giesecke & Devrient (G&D).
### Tools & Technologies
1. **Instrumentation:** Modifying and recompiling the Samsung S3 kernel to enable verbose debug messages in the Mobicore kernel driver.
2. **ROM Building:** Utilizing "Android ROM Kitchen 0.217" to unpack the stock `zImage`, insert the modified kernel, and repack the custom ROM.
3. **Analysis:** Observing kernel driver debug output and studying the source code of the User API library (`libMcClient.so`).
4. **Fuzzing:** Writing custom C programs linked against `libMcClient.so` to manipulate parameters (e.g., memory addresses and buffer sizes) passed to a specific Trustlet (PlayReady DRM).
## Key Findings
### Primary Results
1. A detailed data flow for establishing sessions and communication between Android applications and Secure World Trustlets via the Mobicore API was mapped out (involving `mcOpenDevice()`, `mcMallocWsm()`, and Secure Monitor Calls (SMC)).
2. The instrumentation successfully allowed for the **capture and analysis of communication** between the Android application and the TrustZone OS.
3. A **security vulnerability was identified in the Mobicore kernel driver** that allowed unauthorized network messages (via Netlink) to be processed from low-privileged Android processes, potentially enabling communication with Mobicore-enabled drivers like the IPSEC driver.
4. Fuzzing the PlayReady DRM Trustlet exposed basic input validation points, specifically checks on memory addresses pointing to Shared Memory Buffers (WSM).
### Supporting Evidence
* The vulnerability exploitation was demonstrated by showing a Netlink message being sent from a low-privileged process and subsequently processed by the Mobicore kernel driver.
* Fuzzing revealed that manipulating the WSM offset parameters caused the Trustlet to terminate with specific errors, such as: "parameter refers to secure memory area" or "malloc() failed" when attempting to allocate large buffers.
### Novel Contributions
1. Demonstration of a method to **capture inter-world communication** by instrumenting the Mobicore Android client library.
2. Identification of a specific **kernel driver vulnerability** allowing unauthorized communication paths to Trusted OS drivers from unprivileged Android space.
3. Initial exploration of **black-box security assessment** techniques for mobile TEEs by combining data interception with protocol fuzzing.
## Technical Details
The Mobicore architecture divides the CPU into a **Normal World (NWd)** running Android and a **Secure World (SWd)** running the Mobicore micro-kernel and security-critical **Trustlets**. Communication relies on a three-component API in the NWd: the **client library (`libMcClient.so`)**, the **Daemon (`mcDriverDaemon`)**, and the **device driver (`/dev/mobicore`)**, which performs ARM **Secure Monitor Calls (SMC)** to switch context to SWd.
The communication relies heavily on **Worlds Share Memory (WSM)** buffers allocated via `mcMallocWsm()`. The analysis showed that unauthorized attempts to manipulate the virtual addresses or sizes of these shared buffers during fuzzing resulted in error conditions within the Trustlet, suggesting some level of runtime boundary checks, though an exploitable kernel driver flaw was found independently.
## Practical Implications
### For Security Practitioners
The findings demonstrate that TEE security is not absolute at the software layer. Tools and analysis techniques must evolve beyond traditional application layers to specifically target the communication channels between the rich OS and the TEE.
### For Defenders
Defenders relying on hardware isolation must recognize that kernel drivers facilitating the TEE interface (like the Mobicore driver) represent a critical attack surface. Patching vulnerabilities in these drivers, particularly concerning input validation from the Normal World, is essential. Proper validation of parameters (like memory addresses and sizes) passed via Netlink or other IPC mechanisms between NWd and SWd components is mandatory.
### For Researchers
The methodology presented (instrumentation + driver logging) is a viable blueprint for analyzing proprietary TEE implementations. The success in intercepting WSM traffic suggests future research should focus on combining these techniques with side-channel measurements across the context-switching boundary.
## Limitations
The initial fuzzing effort did not fully explore malicious manipulation of the *content* (e.g., XML data) being sent *within* the valid WSM structure, focusing instead on structural parameters (offsets and sizes). Furthermore, the analysis was confined to the Samsung S3/Mobicore TEE implementation.
## Comparison to Prior Work
This work focuses specifically on gaining software-level insight into the Mobicore TEE, which was a relatively new feature at the time (Galaxy S3). It addresses the need for new security assessment techniques tailored to TEEs, differentiating itself by providing a practical demonstration of interception via library instrumentation rather than relying solely on static code analysis or high-level interaction.
## Real-world Applications
* **Security Auditing:** Auditing commercial TEE deployments (e.g., digital wallets, DRM systems) that rely on the Mobicore/TrustZone stack.
* **Exploit Development:** Developing exploits targeting specific Trustlets by understanding how they handle initialization and data transfer from the less trusted environment.
## Future Work
The authors explicitly state future work will focus on combining the developed interception techniques with **side-channel measurements** to further probe the context switching and memory sharing mechanisms between the Normal and Secure Worlds, suggesting a path toward comprehensive black-box TEE assessment.
## References
* ARM TrustZone documentation (referenced via URL).
* Giesecke & Devrient (G&D) Mobicore architecture overview.
* ARM Secure Monitor Call (SMC) documentation.