Modern Android ecosystems frequently leverage virtual machines (VMs) for development, testing, and even production environments. From the Android Emulator (AVD) used by developers to cloud-based Android VMs and specialized sandboxes, these virtualized environments present unique challenges and opportunities for forensic investigators. Unlike physical devices, VMs introduce layers of abstraction, but also often leave more traceable digital artifacts on the host system. Understanding how Android VMs persist data is paramount for successful forensic analysis, enabling investigators to reconstruct events, recover evidence, and uncover malicious activities.

Understanding Android Virtual Machines

An Android Virtual Machine simulates a complete Android device, including its hardware and software stack, on a host operating system. This virtualization allows developers to test applications across various Android versions and device configurations without needing physical hardware. For forensic purposes, identifying the type of VM is the first step.

Types of Android VMs

• Android Emulator (AVD): The most common type, part of Android Studio. These VMs run on a developer’s workstation and use QEMU for hardware virtualization.
• Cloud-Based Android VMs: Services like Genymotion Cloud, Google Cloud’s Android offerings, or internal testing farms often run Android VMs on remote servers.
• Custom Android-x86 Installations: Running Android OS on a generic VM platform like VirtualBox or VMware.
• Containerized Android Environments: While not traditional VMs, solutions like Anbox (Linux containers for Android) offer a similar sandbox environment with different persistence characteristics.

Key Persistence Mechanisms

The core of forensic investigation into Android VMs lies in understanding where and how data is stored persistently, even after the VM is shut down or reset. These mechanisms are primarily file-based on the host system.

Disk Image Persistence (userdata.img, Snapshots)

The primary form of data persistence in most Android VMs is through disk images, which simulate the device’s internal storage.

• userdata.img: This is a sparse disk image file that represents the user data partition (/data) of the Android VM. It contains all user-installed applications, their data, settings, databases, and often critical evidence. For AVDs, this file is typically found within the AVD’s directory.
• System and Cache Images: system.img and cache.img represent the system and cache partitions, respectively. While system.img is usually read-only, cache.img can contain temporary data and sometimes artifacts.
• AVD Snapshots (.qcow2 files): Android Emulator snapshots allow users to save the exact state of a running VM. When a snapshot is created, QEMU uses a Copy-on-Write (CoW) mechanism. The original userdata.img becomes the base, and all subsequent writes are redirected to a new .qcow2 (QEMU Copy-On-Write) image file. This snapshot file contains all changes made since the base image, along with the VM’s entire memory state.

Configuration File Persistence

Beyond the disk images, critical metadata and settings for the VM are stored in configuration files on the host system.

• AVD config.ini: For Android Emulators, the config.ini file (located in the AVD directory, e.g., ~/.android/avd/Pixel_5_API_30.avd/) specifies the VM’s hardware profile, Android version, default skin, and other crucial parameters. Changes to these settings directly impact the VM’s behavior and can reveal user intentions.
• Virtualization Software Configuration: For custom Android-x86 VMs (e.g., VirtualBox, VMware), their respective .vbox, .vmx, or other configuration files contain settings about allocated RAM, CPU cores, network adapters, and pointers to the virtual disk files.

Log Data Persistence

Log files, both from the Android VM and the host system, provide invaluable insights into activities, errors, and system events.

• Logcat Logs: The Android logging system records system messages, application events, and debugging information. While a running VM’s logcat output is transient, significant logs may be written to files within the VM’s /data/misc/logd/ directory or accessible via adb logcat -d -f <file>.
• Kernel Logs (dmesg): Linux kernel messages within the Android VM can reveal low-level system events, hardware issues, or security-related activities.
• Host System Logs: Logs from the virtualization software (e.g., QEMU logs, VirtualBox logs) on the host system can show VM start/stop times, errors, and resource allocation details.

Forensic Acquisition and Analysis Techniques

Acquiring persistent data from an Android VM often involves direct file system access on the host machine where the VM is stored.

Acquiring Disk Images

The most critical step is to obtain copies of the virtual disk images.

1. Locate AVD Files:

   # On Linux/macOScd ~/.android/avd/ls -l

   This directory typically contains subdirectories for each AVD, like Pixel_5_API_30.avd/. Inside, you’ll find userdata.img, cache.img, and the snapshots/ directory.

2. Copy Disk Images: Always work on forensic copies.

   cp Pixel_5_API_30.avd/userdata.img /mnt/forensic_drive/avd_evidence/cp -R Pixel_5_API_30.avd/snapshots/ /mnt/forensic_drive/avd_evidence/

3. Handling .qcow2 Snapshots: If multiple snapshots exist, they form a chain. Use qemu-img info to understand the parent-child relationship. You can convert a snapshot to a standalone raw image for easier analysis:

   qemu-img info snapshot_name.qcow2qemu-img convert -f qcow2 -O raw snapshot_name.qcow2 snapshot_merged.raw

   This command merges the snapshot with its base image, creating a complete raw disk image representing the VM’s state at the time of the snapshot.

4. Mounting Disk Images:

   Once you have a raw disk image (or convert .img to raw if needed), you can mount it on a Linux forensic workstation:

   # Identify partitions within the imagemmls snapshot_merged.raw# Mount a specific partition (e.g., partition 1, usually /data)mount -o loop,offset=<offset_in_bytes> snapshot_merged.raw /mnt/android_data_partition/

   The offset can be calculated from mmls output (start sector * sector size, typically 512 bytes). This allows full file system access for carving, keyword searching, and data recovery.

Extracting Configuration and Log Data

• Configuration Files: Copy the config.ini file and any other virtualization software configuration files (e.g., .vbox, .vmx) from the AVD or VM directory. These files provide crucial context about the VM’s setup.
• Logcat Data from Running VM: If the VM is still operational, adb is your primary tool.

  adb devicesadb logcat -d > android_logcat_dump.txt

  The -d flag dumps the entire buffer and exits. For persistent log files within the VM, you might need root access and adb pull.

  adb shell
  
          
          
          
  
              
  
                  
              
              
  
                  
  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 →