Introduction to Android Automotive OS Forensics

Android Automotive OS (AAOS) represents a significant paradigm shift in vehicle infotainment systems, moving beyond simple smartphone projection to a full, embedded Android operating system. As vehicles become increasingly connected and intelligent, the data generated and stored by AAOS devices presents a goldmine for forensic investigators. From tracking app usage patterns to pinpointing precise location histories, understanding how to forensically acquire and analyze this data is crucial for incident response, intellectual property theft investigations, and even criminal cases.

This article provides an expert-level technical guide to the forensic analysis of app usage and location data within Android Automotive OS. We will delve into acquisition strategies, identify key data artifacts, and demonstrate methods for extracting and interpreting this critical evidence.

Challenges in AAOS Forensic Acquisition

Forensically acquiring data from an AAOS device introduces unique challenges compared to standard mobile phone forensics:

• Integrated Systems: AAOS is deeply integrated into vehicle hardware, often making physical access difficult without specialized tools or even partial vehicle disassembly.
• Limited Accessibility: Debugging interfaces (like ADB) might be disabled or restricted in production vehicles, requiring advanced techniques to bypass.
• Proprietary Implementations: While the core is Android, vehicle manufacturers can customize AAOS extensively, leading to variations in data storage locations and formats.
• Power Management: Vehicles have complex power states; ensuring persistent power during acquisition and preventing data corruption requires careful planning.

Data Acquisition Strategies

Logical Acquisition via ADB

If ADB (Android Debug Bridge) access is enabled on the AAOS head unit, it offers the most straightforward method for logical data acquisition. ADB allows for shell access and file transfer.

First, verify ADB connectivity:

adb devices

If your device is listed, you can proceed. Many critical files are within `/data`, which typically requires root access. If the device is rooted or ADB is running as root, you can pull files directly:

adb pull /data/system/usagestats/0/daily/usage-history.xml ./usage-history.xmladb pull /data/data/com.google.android.gms/databases/gls_nav.db ./gls_nav.db

For non-rooted devices, access to certain system directories will be restricted. In such cases, exploiting vulnerabilities or leveraging a custom recovery might be necessary, though these are often unavailable or patched in production AAOS units.

Physical Acquisition Methods

When logical acquisition is not feasible, physical acquisition becomes the alternative, albeit a more invasive one:

• Chip-Off Forensics: This involves physically removing the NAND or eMMC memory chip from the AAOS head unit’s circuit board and reading its contents using a universal memory programmer. This provides a raw image of the entire storage, bypassing OS-level restrictions. However, it requires specialized equipment, soldering skills, and can damage the device.
• JTAG/UART Access: If accessible debugging ports (JTAG, UART) are present and active, they can provide a low-level interface to the device’s bootloader or memory, allowing for memory dumping. This method is highly hardware-dependent and often requires custom adapters and expertise.

Key Data Artefacts: App Usage

Usage Stats Database (`usage-history.xml` and SQLite)

Android’s UsageStatsManager records app usage events, which are vital for understanding user interaction with the AAOS system. This data is often stored in XML files and/or SQLite databases.

XML Artifact: `usage-history.xml`

The file `/data/system/usagestats/0/daily/usage-history.xml` (or similar path depending on AAOS version/user profile) can contain aggregated app usage statistics. This XML file records packages, their last active times, and total active durations.

<usagestats version="1">    <package pkg="com.android.settings" lastTimeActive="1678886400000" totalTimeActive="60000" />    <package pkg="com.google.android.apps.maps" lastTimeActive="1678890000000" totalTimeActive="1200000" />    <package pkg="com.spotify.music" lastTimeActive="1678895000000" totalTimeActive="300000" /></usagestats>

The `lastTimeActive` and `totalTimeActive` attributes are typically in milliseconds since the Unix epoch. Convert these timestamps to human-readable format for analysis.

SQLite Artifact: `appusagestats.db`

More detailed usage events are often found in SQLite databases, such as `/data/system/appusagestats/0/appusagestats.db` or similar within the `/data/system/appusagestats/` directory. These databases contain tables like `events` and `packages`.

To extract specific app launch events, you might use a query like this:

SELECT    datetime(timestamp/1000, 'unixepoch') AS event_time,    case event_type        when 1 then 'ACTIVITY_RESUMED'        when 2 then 'ACTIVITY_PAUSED'        when 7 then 'FOREGROUND_SERVICE_START'        when 8 then 'FOREGROUND_SERVICE_STOP'        when 10 then 'ACTIVITY_STOPPED'        else 'UNKNOWN'    end AS event_type,    package_nameFROM    eventsWHERE    event_type = 1 -- ACTIVITY_RESUMED, indicating app launch or foreground switchORDER BY    timestamp ASC;

This query provides a timeline of when applications were brought to the foreground, which is a strong indicator of user interaction.

Key Data Artefacts: Location Data

Google Location Services (GLS) Cache

For AAOS devices with Google Automotive Services (GAS) enabled, Google Location Services (GLS) caches location data. This data is often found in SQLite databases within `/data/data/com.google.android.gms/databases/`, typically named `gls_*.db` (e.g., `gls_nav.db`, `gls_power.db`).

These databases can contain tables such as `cell_details`, `wifi_details`, and `location_cache`.

An example query to extract cached GPS locations from the `location_cache` table:

SELECT    datetime(timestamp/1000, 'unixepoch') AS location_time,    latitude,    longitude,    altitude,    accuracy,    providerFROM    location_cacheWHERE    latitude IS NOT NULL AND longitude IS NOT NULLORDER BY    timestamp ASC;

This provides a chronological list of geocoordinates, often with associated accuracy and timestamp information. Correlating these with app usage can reveal routes traveled during specific app interactions, such as navigation or music streaming.

Vehicle-Specific Telemetry

Beyond standard Android location services, AAOS can integrate deeply with vehicle sensors. This means additional location and movement data (e.g., speed, odometer readings, turn-by-turn navigation logs, accelerometer data) might be stored by the vehicle’s proprietary systems or within specific AAOS applications provided by the OEM. Identifying these proprietary data stores requires specific knowledge of the vehicle’s AAOS implementation, but they should always be considered potential sources of forensic evidence. Look for OEM-specific app data directories within `/data/data/` or `/data/user/0/`.

Analysis and Correlation

Once data artifacts are acquired, the next step is comprehensive analysis and correlation. Forensic tools like Autopsy, Magnet AXIOM, or open-source solutions combined with custom Python scripts can assist in:

• Timeline Reconstruction: Aligning app usage events, Wi-Fi connections, and GPS coordinates on a single timeline to reconstruct user activities and movements.
• Geofencing Analysis: Identifying if the vehicle was present in specific areas of interest during certain timeframes.
• Pattern Recognition: Detecting routine commutes, frequent stops, or unusual travel patterns.

By correlating `ACTIVITY_RESUMED` events for navigation apps with `location_cache` entries, investigators can precisely map when and where navigation was used. Similarly, relating music app usage to location data can help establish a user’s presence at various locations.

Conclusion

Forensic analysis of Android Automotive OS data is a complex yet critical endeavor for modern digital investigations. By understanding the unique challenges of AAOS, mastering acquisition techniques—from logical ADB pulls to physical chip-off methods—and knowing where to look for key artifacts like app usage statistics and location caches, investigators can uncover a wealth of information. The ability to reconstruct user activities and movements from an AAOS head unit provides invaluable evidence, highlighting the growing importance of specialized expertise in automotive forensics.