Introduction: The Imperative of System Integrity in Android Forensics

In the realm of digital forensics and cybersecurity, ensuring the integrity of a device’s operating system is paramount. For Android devices, the system partition (/system) is designed to be immutable, meaning it should remain unchanged after being flashed. Any modification to this partition could indicate malware, unauthorized rooting, or tampering, significantly compromising the device’s security and trustworthiness. This expert-level guide delves into practical methodologies using adb and fastboot to perform robust integrity checks on Android’s system partition, crucial for both forensic investigations and maintaining a secure device posture.

While Android incorporates built-in security mechanisms like Android Verified Boot (AVB) and dm-verity to protect system integrity, a forensic approach often requires independent verification, especially when investigating potential bypasses or compromised states. Our focus will be on acquiring a reference image and comparing its cryptographic hash against subsequent acquisitions to detect even the most subtle changes.

Understanding Android Verified Boot (AVB) and dm-verity

Before diving into practical steps, it’s essential to grasp the foundational security features safeguarding Android’s system partitions:

• Android Verified Boot (AVB): This process ensures that all executed code, from the bootloader to the system partition, comes from a trusted source (usually the OEM) and hasn’t been tampered with. It cryptographically verifies each stage of the boot process.
• dm-verity: A Linux kernel feature, dm-verity is specifically designed to detect and prevent persistent rootkits and integrity compromises on block devices. For the /system partition, it creates a cryptographic hash tree where each block’s hash is verified against a root hash stored in the boot image. If any block is modified, the hash mismatch is detected, and the system typically enters a degraded mode or fails to boot.

While these mechanisms are robust, a sophisticated attacker might attempt to bypass them or modify components before AVB’s checks, necessitating independent forensic verification.

Prerequisites for Forensic Integrity Checks

To effectively perform the checks outlined in this guide, ensure the following:

• Android SDK Platform Tools: Install adb and fastboot on your forensic workstation.
• Developer Options Enabled: On the Android device, navigate to ‘Settings > About Phone’ and tap ‘Build Number’ seven times to enable ‘Developer Options’.
• USB Debugging Enabled: Within ‘Developer Options’, enable ‘USB Debugging’.
• OEM Unlocking Enabled: If you intend to unlock the bootloader or boot a custom recovery, ‘OEM Unlocking’ must be enabled in ‘Developer Options’. Be aware that unlocking the bootloader typically wipes the device, which is a critical consideration for forensics. For integrity checks without wiping, we often rely on a temporarily booted custom recovery.
• Appropriate USB Drivers: Ensure your computer has the correct USB drivers for your Android device.

Step 1: Assessing Device State via Fastboot

The fastboot tool provides crucial initial insights into the device’s bootloader and AVB status. This step can often be performed without unlocking the bootloader or wiping the device.

1. Boot the device into Fastboot Mode: This usually involves powering off the device and then holding a specific button combination (e.g., Volume Down + Power) while powering on. The exact combination varies by OEM.
2. Connect the device to your workstation: Use a reliable USB cable.
3. Verify Fastboot connection: Open a terminal or command prompt and run:

   fastboot devices

   You should see your device’s serial number listed.

4. Query device variables: To get an overview of the device’s state, including bootloader lock status and verified boot information, run:

   fastboot getvar all

   Pay close attention to outputs like (bootloader) device-state and (bootloader) verified-boot. A device-state of ‘locked’ and verified-boot showing ‘green’ (or ‘production’) indicates a generally secure boot chain. Any other state (e.g., ‘unlocked’, ‘yellow’, ‘orange’, ‘red’) warrants further investigation, as it suggests modifications or a non-standard boot process.

Step 2: Acquiring a Reference (Golden) Image of the System Partition

The cornerstone of integrity checking is having a known good baseline. This involves acquiring a byte-for-byte copy of the system partition from a trusted, factory-fresh device (or a trusted source) and calculating its cryptographic hash. This will be your ‘golden image’.

Acquiring the system partition directly via fastboot for modern devices is not typically possible as fastboot is primarily for flashing. Instead, we’ll leverage adb within a custom recovery environment.

Method: Using a Temporarily Booted Custom Recovery (e.g., TWRP)

This method allows you to acquire partition images without permanently modifying the device’s recovery partition, which is crucial for forensic soundness. It does, however, require an unlocked bootloader.

1. Obtain a compatible custom recovery image: Download the appropriate TWRP (Team Win Recovery Project) .img file for your specific device model.
2. Boot the custom recovery temporarily: With the device in fastboot mode, execute:

   fastboot boot /path/to/twrp.img

   The device should boot directly into TWRP without flashing it permanently.

3. Enable ADB in TWRP: Once TWRP loads, it usually enables adb automatically. If prompted to allow modifications, choose ‘Read Only’ to maintain the original state as much as possible, or decline if you’re only pulling data.
4. Verify ADB connection: In your workstation’s terminal:

   adb devices

   You should see your device listed as ‘recovery’.

5. Identify the system partition block device: Enter an adb shell to interact with the device’s filesystem:

   adb shell

   Then, list the block devices to find the one corresponding to the system partition. Common paths include /dev/block/by-name/system or /dev/block/platform/ABCD.0/by-name/system:

   ls -l /dev/block/by-name/system

   This command will show you the actual block device path (e.g., /dev/block/mmcblk0pXX or /dev/block/sdaXX).

6. Dump the system partition: Use the dd command to create an image of the system partition. Due to size limitations in /tmp or `/sdcard` in recovery, it’s often best to directly pipe the output over ADB:

   adb shell "dd if=/dev/block/by-name/system bs=4096 status=progress" > system_golden.img

   Replace /dev/block/by-name/system with the actual path identified in the previous step. The bs=4096 specifies a block size, and status=progress provides real-time progress. This command will take time depending on the partition size and USB speed.

7. Calculate the cryptographic hash: Once system_golden.img is fully transferred to your workstation, calculate its SHA256 hash:

   sha256sum system_golden.img

   Record this hash securely. This is your ‘golden hash’.

8. Reboot the device: After acquisition, safely reboot the device:

   adb reboot

   Or manually reboot from TWRP.

Step 3: Performing Subsequent Integrity Checks on the Device Under Investigation

When you need to verify the integrity of another device, or the same device at a later date, you repeat the acquisition process and compare hashes.

1. Repeat Step 2: Acquire the system partition image from the device under investigation using the same custom recovery method. Ensure you name the output file differently, e.g., system_investigation.img.
2. Calculate the hash of the new image:

   sha256sum system_investigation.img

3. Compare the hashes: Compare the SHA256 hash of system_investigation.img with your recorded ‘golden hash’.

   diff <(sha256sum system_golden.img) <(sha256sum system_investigation.img)

   If the hashes are identical, the system partition’s integrity is intact (relative to your golden image). If they differ, even by a single byte, it indicates modification or corruption, requiring further in-depth analysis to determine the cause and nature of the change.

Step 4: Deep Dive into dm-verity Runtime Status (If OS is Bootable)

If the device can boot into its operating system, you can perform additional checks to understand the runtime status of dm-verity.

1. Check Kernel Command Line: Connect via adb while the device is booted and run:

   adb shell cat /proc/cmdline | grep verity

   Look for androidboot.veritymode=enforcing, which indicates dm-verity is actively enforcing integrity. If it shows disabled or logging, it means dm-verity is either bypassed or in a non-enforcing mode.

2. Verify dm-verity state (requires root on most devices): For a more granular view of dm-verity status for specific block devices, root access might be necessary to query /sys/block. For example:

   adb shell su -c 'dmsetup table'

   This command lists active device-mapper targets, including those for dm-verity. You would look for entries related to your system partition.

Challenges and Limitations

• OEM Variations: Fastboot commands and partition names can vary slightly between manufacturers. Always consult device-specific documentation.
• Locked Bootloaders: Many forensic scenarios involve devices with locked bootloaders. Acquiring a golden image via custom recovery requires an unlocked bootloader, which often factory resets the device, making it unsuitable for post-compromise forensic analysis if data preservation is critical. In such cases, the fastboot getvar all command is your primary non-destructive tool.
• Encrypted Data Partition: While this guide focuses on the /system partition, remember that the /data partition is almost always encrypted, and accessing its contents requires knowledge of the encryption key or a bypass.
• Time-consuming Process: Acquiring large partition images can take a significant amount of time.
• Rooted Devices: On rooted devices, adversaries might have manipulated dm-verity or AVB. Independent hash comparison remains crucial.

Conclusion

Maintaining and verifying the integrity of Android’s system partition is a cornerstone of device security and forensic analysis. By mastering the use of adb and fastboot to acquire baseline images and perform subsequent cryptographic hash comparisons, security professionals and forensic examiners gain a powerful tool to detect tampering and ensure the trustworthiness of an Android device. While Android’s built-in security features are robust, independent verification provides an essential layer of assurance, helping to identify sophisticated compromises that might otherwise go unnoticed.