Introduction

Android Virtual Machine (VM) disk images are crucial sources of digital evidence in mobile forensics, debugging, and incident response. However, these images can become corrupted due to various factors like abrupt shutdowns, hardware failures, or malicious activity. When a VM disk image is corrupted, traditional mounting techniques often fail, making it impossible to directly access the filesystem. This expert-level guide delves into advanced techniques for carving valuable files and artifacts from severely damaged Android VM disk images, transforming seemingly lost data into actionable intelligence.

Understanding Android VM Disk Structures

Before attempting recovery, it’s essential to understand how Android VM disks are typically structured. Android VMs often utilize disk images that mimic physical device storage, containing several partitions. Common formats include QCOW2 (QEMU Copy-On-Write), VMDK (VMware Virtual Disk), VDI (VirtualBox Disk Image), or simply raw disk images. Internally, these images frequently contain an Android-specific partition layout, typically with a boot partition, a system partition (read-only), a vendor partition, and critically, a user data partition (/data), often formatted as ext4 or f2fs.

Common Formats

• QCOW2/VMDK/VDI: These are container formats that encapsulate the virtual disk. They often need to be converted to a raw format for easier forensic analysis.
• Raw Disk Images: A bit-for-bit copy of the virtual disk, directly representing the underlying partitions.
• Partition Layout: Forensic tools need to identify partition offsets within the raw image to access individual filesystems. Tools like mmls or fdisk -l can help here.

Initial Assessment and Integrity Check

The first step involves assessing the extent of corruption. This helps determine whether simple repair or advanced carving is necessary.

# For QCOW2 images, check integrity and convert to raw if neededqemu-img check android_vm.qcow2qemu-img convert -f qcow2 -O raw android_vm.qcow2 android_vm.raw# Identify partition layout (example for a raw image)fdisk -l android_vm.raw# Or using mmls from Sleuth Kit (more forensic-focused)mmls android_vm.raw

If fdisk or mmls fail to detect a valid partition table, or if filesystem checks (like e2fsck) report severe errors, then direct data carving is likely the most viable path.

Mounting and Accessing Intact Partitions

If the partition table is partially intact, you might be able to mount individual partitions. This is often the quickest way to recover data if corruption is localized.

# Use losetup to create a loop device for the raw image.substituting 'X' with the assigned loop number.sudo losetup -f --show android_vm.raw# Use kpartx to map partitions within the loop devicesudo kpartx -a /dev/loopX# Identify the data partition. Often it's the largest.Example: /dev/mapper/loopXpY where Y is the partition number.ls /dev/mapper/# Attempt to mount the data partition (assuming ext4)mkdir /mnt/android_vm_datamodevicesudo mount -o ro /dev/mapper/loopXpY /mnt/android_vm_data# If f2fs, try this:sudo mount -t f2fs -o ro /dev/mapper/loopXpY /mnt/android_vm_data# Unmount and clean up after analysis (always unmount first)sudo umount /mnt/android_vm_datamodevicesudo kpartx -d /dev/loopXsudo losetup -d /dev/loopX

If mounting fails, or only a subset of partitions are accessible, you’ll need to resort to data carving.

Advanced Data Carving from Corrupted Images

When filesystem metadata is destroyed, data carving becomes essential. This process involves scanning the raw disk image for file headers and footers (signatures) to identify and extract known file types.

Signature-Based Carving with Foremost

Foremost is a classic tool for carving files based on their headers, footers, and internal data structures. It’s highly configurable.

# Example: Carve JPEG, PDF, and SQLite database filesforemost -t jpg,pdf,sqlite -i android_vm.raw -o carved_data_foremost

Foremost will create an output directory (carved_data_foremost) containing subdirectories for each file type found.

Leveraging Scalpel for Precision

Scalpel is a more advanced file carving tool, often faster and more resource-efficient than Foremost, especially for large images. It uses a configuration file to define file types.

# Create a custom scalpel.conf file for Android artifacts# Example scalpel.conf entries (add more as needed)# jpg y 100000000 	 FF D8 FF E0 ?? ?? 4A 46 49 46 00 01 ?? ?? ?? ?? ?? ?? 00 00 00 00 	 FF D9# sqlite y 100000000 	 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 	 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (adjust footer if needed, SQLite has variable footer)scalpel -o carved_data_scalpel -c scalpel.conf android_vm.raw

Scalpel’s configuration allows for fine-tuning based on observed file structures within Android, such as specific SQLite database headers from common apps or APK file signatures.

Filesystem-Aware Recovery with TestDisk/PhotoRec

While often used for recovering deleted files from intact filesystems, TestDisk’s companion tool, PhotoRec, can be very effective against severely corrupted images. PhotoRec ignores the filesystem and carves files based on signatures, similar to Foremost/Scalpel, but with an extensive built-in list of file types.

# Run PhotoRec (interactive mode)photorec /log /d carved_data_photorec android_vm.raw

Follow the on-screen prompts, selecting the raw image, specifying the file system type as ‘None’ or ‘Other’ if the main filesystem is unrecognizable, and choosing the output directory.

Identifying Key Android Artifacts

Once files are carved, the next step is to identify forensically relevant Android artifacts:

• SQLite Databases: Core of Android data (SMS, call logs, contacts, browser history, app data). Look for .db, .sqlite, .sqlitedb extensions.
• APKs: Installed application packages. Look for .apk.
• Images/Videos: User media. Look for .jpg, .png, .mp4.
• User Data: Files from /data/data/<package_name>/. Often found in specific app directories.
• Logs: Search for patterns typical of logcat output or other system logs using grep -a on the raw image or carved text files.
• Browser Artifacts: Bookmarks, history, cookies often stored in SQLite databases (e.g., Default/History, Default/Bookmarks).

Workflow for Comprehensive Artifact Recovery

1. Image Acquisition: Create a bit-for-bit raw copy of the corrupted VM disk image using dd. Never work on the original.
2. Initial Analysis: Use fdisk -l, mmls, and file to understand the image structure and filesystem types.
3. Filesystem Repair (Optional): Attempt e2fsck or fsck.f2fs if partition metadata is only lightly damaged.
4. Partition Mounting: If repair or initial analysis allows, mount accessible partitions in read-only mode to extract easily recoverable data.
5. Signature-Based Carving: Employ Foremost, Scalpel, and/or PhotoRec on the entire raw image to recover files by signature. Run them multiple times with different configurations if needed.
6. Keyword and String Search: Use strings -e l android_vm.raw | grep -i 'keyword' or grep -a -i 'pattern' android_vm.raw to find specific text artifacts (e.g., email addresses, phone numbers, unique identifiers) that carving tools might miss or for data within unallocated space.
7. Manual Binary Analysis: For very specific artifacts, use a hex editor (e.g., bless, hexedit) to manually examine suspect areas of the disk.
8. Artifact Analysis: Use specialized Android forensic tools or manual examination to analyze the carved files (e.g., SQLite Browser for databases, APK parsers for APKs).

Conclusion

Recovering data from corrupted Android VM disk images is a challenging but often successful endeavor. By systematically applying a combination of initial assessment, partition mounting, and advanced data carving techniques, forensic investigators and debuggers can salvage critical files and artifacts that would otherwise be considered lost. The key lies in understanding the underlying disk structures, utilizing the right tools, and maintaining a meticulous workflow to piece together the digital puzzle.