Securing the System: A Deep Dive into Reversing Android Pre-Installed Apps

## Overview

Matty Stone (security researcher Project Zero, formerly Android Security team reverse-engineer) presented deep-dive into Android preinstalled app security. Core problem: devices ship with 100-400 preinstalled apps on read-only file system; security issues harder to remediate than user-space apps (requires security update, not user delete). Attackers targeting supply chain: if they compromise one OEM (rather than convincing thousands of users to install malware), they infect thousands to millions of devices. Motivation: security research tools/processes developed for user-space app reverse engineering transfer poorly to preinstalled context; talk presents lessons learned and case studies to lower barrier to entry for researchers analyzing OEM firmware builds. Team reviewed 1000+ OEM build images annually; goal is democratizing preinstalled security research.

## Android Ecosystem, Permissions Model, and Dynamic Analysis Challenges

**Ecosystem Structure**: Android ecosystem split between certified devices (Samsung, Google Pixel—work with Google, license Google Apps, pass full Build Test Suite/BTS) and uncertified/AOSP-only devices (Amazon Fire tablets—use open-source OS without Google certification, pass only CTS compatibility tests). Certified devices undergo rigorous test suites including BTS (security review of firmware images before shipping to catch potentially harmful apps/PHA). BTS introduced to find security issues pre-launch but operates at last step before firmware ships, meaning some issues discovered after deployment requiring OTA patches and Google Play Protect detection distribution.

**Permission Architecture and Signature/Privileged Permissions**: Android apps declare signature permissions (granted only to apps signed with OS private key—OEM code only) and privileged permissions (granted to system-partition apps from trusted parties like carriers). Examples of sensitive signature permissions include INSTALL_PACKAGES (install apps), ACCESS_DEVICE_IDENTIFIERS. Dynamic analysis tools sideloading preinstalled apps fail to grant these permissions, masking dangerous privileged behaviors. Additionally, preinstalled apps often use shared user IDs (declaring in manifest that multiple apps run as single process with superset of all declared permissions)—sideloading individual apps breaks this collusion mechanism, preventing behaviors requiring cross-app coordination from executing.

**Dynamic Analysis Obstacles**: Headless preinstalled apps (no UI) don't have launcher activities and require static analysis to identify services/receivers with intent filters that trigger code execution; standard automated dynamic analysis pipelines fail. Hardware dependencies: apps built for specific device hardware; dynamic analysis environments lack custom hardware/abstraction layers. Critical system apps (Settings, Dialer, SystemUI) can't be sideloaded to different devices without breaking expected behavior. Solution: depends on use-case—single-device deep-dive researchers can instrument specific device; at-scale reviewers (1000+ builds) must selectively re-sign apps to grant signature permissions and instrument environment for highest-ROI behaviors.

## App Collusion Patterns and Multi-Component Attack Architecture

**Shared User ID Collusion**: Apps signing with same key and declaring shared user ID behave as single process with combined permissions. Example: SMS fraud case where app-1 declares SEND_SMS permission but contains no SMS API calls; app-2 lacks SEND_SMS permission but contains API calls to send text messages. Independently benign, but together achieve SMS fraud (premium SMS charges to user bill). Pattern: split malicious behavior across components so individual static analysis appears innocent while combined execution is harmful.

**Custom Permission Proxying**: Apps define custom permissions then protect services with those permissions, allowing other apps to interact with privileged functionality. Dangerous variant: service actually uses signature/privileged permissions (e.g., INSTALL_PACKAGES) but exposes it via custom permission visible to all apps—bypassing permission model intended to restrict privilege. App B can request userspace custom permission and gain access to sensitive capability (package installation) without requesting sensitive signature permission.

**Binary Daemon and Framework Collusion**: Preinstalled apps depend on binary daemons running in system/bin or OS framework modifications. Example: triada backdoor modified Android log API to accept second argument, allowing any app to interact with backdoor by calling overloaded logging function. Apps can coordinate across native daemon boundaries: app sends commands to socket, daemon reads from kernel character device, executes commands received, sends output back to app via hardcoded email address.

## Case Studies: Remote Code Execution and Privilege Escalation

**Complex Diagnostic Backdoor (Arbitrary RCE, Multi-Component)**: Production firmware included diagnostic software with pre-installed application, two native daemons, modified SELinux policy, and custom kernel character device. Attack flow: (1) App connects to socket, handshakes with remote entity via seven iterations of "hit enter" passing device info, (2) Remote sends base64-encoded string decoded and written to app cache file, (3) First daemon reads cache file content and writes directly to kernel character device (via modified SELinux), (4) Second daemon monitors kernel device, detects new data, parses for XML tags (<exsh></exsh>), passes content between tags directly to system() call (arbitrary command execution). Impact: discovered first day of BTS submission but already deployed to 223 different build fingerprints affecting 6 million users across 16 SKUs. Mitigation: 70% users received OTA within 2 weeks, 100% within month; Google Play Protect disabled app on protected devices.

**Enterprise Diagnostic Service RCE (Shared User ID + Exported Service)**: Single preinstalled app designed for remote fleet management in industrial/factory control environments. Vulnerability chain: (1) App declared shared user ID "system" (most privileged process besides root, has all Android permissions), (2) Service exported=true (any component can bind/call it), (3) Service implemented binder interface exposing methods to client processes, (4) executeCommand() method directly calls runtime.exec() with user-supplied arguments. Attack: any app on device binds to service and calls executeCommand with arbitrary command executing as system process. Detection challenge: runtime.exec() calls legitimate in system apps (e.g., command execution in diagnostics, firmware updates) creating high false-positive rates for user-space malware detection models. Solution: context-aware detection tuned for preinstalled-specific behaviors.

## Organizational and Defense Implications

**Supply Chain as Primary Attack Vector**: Rather than exploiting individual devices, attackers compromise one OEM production pipeline affecting millions. Over years, exploiting raw Android privilege escalations became harder; preinstalled compromise bypasses exploit need entirely. OEM incentivizes supply-chain attacks: easier return-on-investment than mass user social engineering.

**Research Democratization and Tooling Gap**: Lack of public resources/tools for preinstalled analysis means barrier to entry high; community lacks scalable reverse-engineering practices. Google Play Protect and BTS provide signal/detection pipeline but operate at last-mile (devices already built), requiring OTA patches for remediation. Open sourcing tools and methodologies critical to expanding researcher pool monitoring diverse OEM ecosystem.

**Testing and Maturity Challenges**: CTS testing (basic compatibility) insufficient for uncertified devices; BTS for certified only. Complex behaviors requiring hardware/colluding components not caught by standard dynamic analysis. False positives from user-space detection models require significant tuning for preinstalled context. Organizational challenge: single researcher can deep-dive one device over months; teams reviewing 1000+ builds need different strategies (sampling, targeted analysis, automated signature-based filtering).