Introduction: Unveiling the Layers of Android Automotive OS

Android Automotive OS (AAOS) represents a significant shift in in-car infotainment, bringing the flexibility and rich ecosystem of Android directly to vehicles. While based on the Android Open Source Project (AOSP), Original Equipment Manufacturers (OEMs) extensively customize AAOS to integrate vehicle-specific functions, brand identities, and proprietary services. Understanding these customizations is crucial for researchers, security analysts, and developers working on the automotive platform. This guide provides a hands-on approach to reverse engineering production AAOS images, allowing us to extract and analyze OEM-specific modifications.

By dissecting production images, we can uncover hidden features, proprietary APIs, security enhancements, or vulnerabilities introduced by OEMs. This lab will cover the entire process, from acquiring the automotive image to detailed analysis of its components, focusing on the techniques used to identify and understand OEM customizations.

Prerequisites and Tools

Before diving into the analysis, ensure you have the following tools and a Linux-based environment (Ubuntu or Debian recommended):

• AOSP Build Environment: While not strictly required for analysis, familiarity with AOSP build tools and structure is beneficial.
• Disk Image Utilities: simg2img, mount, losetup.
• Android Debug Bridge (ADB) Tools: For interacting with devices if available.
• APK Decompilers: apktool, JD-GUI (for JARs).
• Hex Editor: bless or hexedit.
• Text Editors: vim, VS Code, or similar.
• Python: For scripting and various analysis tools.

Acquiring Automotive System Images

Obtaining production AAOS images can be challenging due to vendor restrictions. However, several methods can be explored:

1. Over-the-Air (OTA) Updates: OEMs often publish OTA update packages containing full or incremental system images. Monitoring network traffic during an update on a test device can reveal URLs to these packages.
2. Device Firmware Downloads: Some OEMs or third-party communities might provide downloadable firmware images for flashing.
3. Physical Device Dumps: In rare cases, if you have root access to a test device, you might be able to dump partitions directly using tools like dd. This is typically complex and beyond the scope of this initial lab.

For this lab, we’ll assume you’ve acquired a payload.bin (common for A/B OTA updates) or a set of sparse images (e.g., system.img.lz4, vendor.img.lz4). We will focus on standard sparse Android images. If you have a payload.bin, you’ll first need to extract the individual partition images using tools like payload-dumper-go or similar scripts.

# Example: Using payload-dumper-go to extract from payload.bin
git clone https://github.com/ssut/payload-dumper-go.git
cd payload-dumper-go
go build -o payload-dumper .
./payload-dumper -p payload.bin
# This will extract images like system.img, vendor.img, etc.

Deconstructing the System Image

Converting and Mounting Partitions

Android images are often distributed in sparse format. We need to convert them to raw images before mounting.

# Convert sparse image to raw image
simg2img system.img system_raw.img
simg2img vendor.img vendor_raw.img

# Create a loop device and mount the raw image
sudo losetup -f system_raw.img
# Output will be something like /dev/loop0
sudo mount /dev/loop0 /mnt/aaos_system

sudo losetup -f vendor_raw.img
sudo mount /dev/loop1 /mnt/aaos_vendor

# Explore the mounted partitions
ls /mnt/aaos_system
ls /mnt/aaos_vendor

Key partitions to examine for OEM customizations include system, vendor, product, and potentially odm. The system partition contains core AOSP components and OEM-modified AOSP apps. The vendor partition holds device-specific binaries, HALs, and OEM-provided libraries and apps. The product partition is increasingly used for OEM-specific features and pre-installed applications.

Deep Dive: Identifying OEM Customizations

Application Layer Analysis (APKs)

OEMs often replace AOSP default apps (e.g., Launcher, Settings) or add their own proprietary applications.

1. Identify OEM Applications: Navigate to /mnt/aaos_system/app, /mnt/aaos_system/priv-app, /mnt/aaos_vendor/app, /mnt/aaos_vendor/priv-app. Look for APKs with unusual names, non-Google package prefixes, or those not found in standard AOSP builds.
2. Extract and Decompile APKs: Once identified, copy suspicious APKs for detailed analysis.

# Example: Extracting a suspicious APK
cp /mnt/aaos_vendor/priv-app/OEMLauncher/OEMLauncher.apk /tmp/

# Decompile the APK
apktool d /tmp/OEMLauncher.apk -o /tmp/OEMLauncher_decompiled

# Examine AndroidManifest.xml for permissions, activities, services
cat /tmp/OEMLauncher_decompiled/AndroidManifest.xml

# Inspect resources and Smali code
ls /tmp/OEMLauncher_decompiled/res
ls /tmp/OEMLauncher_decompiled/smali

Pay attention to custom permissions, hidden activities, and any services interacting with vehicle hardware or proprietary APIs.

Framework Layer Analysis (JARs)

OEMs might modify core Android framework services or add custom framework extensions. Key JARs are framework.jar and services.jar located in /mnt/aaos_system/framework/.

1. Extract JARs: Copy these JARs for analysis.
2. Decompile JARs: Use JD-GUI or `dex2jar` + `jd-cli` to decompile the JARs.
3. Compare with AOSP: Compare the decompiled code against the corresponding AOSP versions. Tools like `diff` or specialized code comparison tools can highlight differences. Look for new classes, methods, or altered existing logic.

# Extract framework.jar
cp /mnt/aaos_system/framework/framework.jar /tmp/

# (Outside scope for direct command, but conceptually) Use a Java decompiler to analyze differences.

System Configuration and Properties

System properties and configuration files reveal much about OEM settings and hardware capabilities.

• Build Properties: Examine /mnt/aaos_system/build.prop, /mnt/aaos_vendor/build.prop, and /mnt/aaos_product/build.prop. Look for OEM-specific device names, feature flags (e.g., ro.oem.feature.ADAS=true), and custom debug settings.
• Device Overlays: Android Runtime Resource Overlays (RROs) in /mnt/aaos_vendor/overlay/ and /mnt/aaos_product/overlay/ are common for theming and minor UI adjustments without modifying AOSP directly.
• VINTF Manifests: /mnt/aaos_vendor/etc/vintf/manifest.xml and /mnt/aaos_system/etc/vintf/manifest.xml define HAL implementations and required services, often customized by OEMs.

# Examine build properties
cat /mnt/aaos_system/build.prop | grep "ro.oem"

# Check VINTF manifests
cat /mnt/aaos_vendor/etc/vintf/manifest.xml

Init Scripts and Services

OEMs can add custom services or modify boot behavior using `init.rc` files. Investigate:

• /mnt/aaos_system/etc/init/
• /mnt/aaos_vendor/etc/init/
• /mnt/aaos_system/init.rc

Look for new services that start at boot (e.g., service oem_daemon /vendor/bin/oem_daemon) and their corresponding executables or scripts.

Practical Scenario: Tracing a Custom Feature

Let’s assume we suspect an OEM has integrated a custom vehicle diagnostic tool. We’d follow these steps:

1. Initial APK Scan: Look for APKs with names like
   
   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 →