Oleksandr Bazhaniuk - Blue Pill for your phone

### Overview In this Ekoparty presentation, Alex (presenting research conducted with Yuri) explores the security architecture of ARM-based mobile platforms, drawing comparisons to x86 firmware and hardware rootkits. While historically focused on x86 platform security and tools like CHIPSEC, the researchers investigated whether common attack vectors—such as poison pointer bugs in System Management Mode (SMM)—also applied to ARM TrustZone and EL2 hypervisors. Their research led to the discovery that certain commercial devices failed to isolate the hypervisor from the normal kernel, allowing a hypervisor-level rootkit ("Blue Pill") attack.

### Key Topics - **ARM vs. x86 Security Concepts**: Comparing Root of Trust (static ROM-based verification vs. Intel Boot Guard), Trusted Execution Environments (TrustZone secure/normal world separation vs. SMM/VSM), and virtualization mechanisms (ARM exception levels vs. x86 full context switches). - **Boot Architecture & Secure World Transitions**: Analyzing the boot sequence on Qualcomm Snapdragon processors (e.g., Snapdragon 810), transitioning from RPM code and application CPU ROM (read-only) through secondary bootloader SBL1, Secure Monitor (EL3), Secure Kernel / Trustlets, and finally executing non-secure code starting at EL2 (hypervisor). - **Reverse Engineering ARM TrustZone**: Extracting `bootloader` images using Benjamin's `unpack-bootloader` tool, mapping components in IDA Pro, analyzing vector tables (`VBAR_EL3`, `VBAR_EL1`, `VBAR_EL2`), and dissecting Secure Monitor Call (SMC) dispatchers, calling conventions, and buffer validation routines. - **Attack Surface & Fuzzing**: Testing vectors including poison pointers (pointing output buffers to TrustZone memory), race conditions across multiple CPUs, MMIO register targeting for secure devices, and direct physical memory modification of hypervisor memory.

### Technical Details During fuzzing and reverse engineering of Qualcomm ARMv8 implementations, the researchers found that TrustZone SMC handlers rigidly validated buffer arguments against internal address tables to prevent writes into TrustZone memory or secure MMIO devices. However, when attempting to point SMC output buffers to hypervisor memory (EL2), they discovered hypervisor physical memory could be directly read and written from the kernel (EL1).

This flaw existed because the hypervisor failed to enable Stage 2 address translation (`VTTBR_EL2`), granting the guest kernel direct access to all physical memory. Exploiting this vulnerability on Google Nexus 5X and 6P (Snapdragon 808/810), the researchers demonstrated an attack: 1. A kernel driver maps and overwrites hypervisor code by patching an entry in the EL2 vector table (`VBAR_EL2`) that executes periodically (every ~2 seconds). 2. The injected shellcode acts as a hypervisor rootkit/backdoor, locking down hypervisor access to prevent further tampering. 3. The hypervisor payload monitors memory for a magic number set by a non-privileged user-space application. 4. Upon receiving the signal, the hypervisor executes privileged commands on behalf of the user application (demonstrated by dumping arbitrary kernel physical memory).

### Takeaways The researchers noted that newer devices, such as the Google Pixel (Snapdragon 821 / Qualcomm 8996), mitigated this issue by properly configuring Stage 2 paging tables to isolate the hypervisor from EL1, along with migrating to a 64-bit TrustZone kernel. The talk underscores that hypervisor implementations must maintain a strict Trusted Computing Base (TCB) without exposing unnecessary physical memory or hardware interfaces to guest kernels, and highlights how vulnerability patterns in x86 platform firmware translate directly to ARM architectures.