Introduction: Why Audit Android System Integrity?

Android’s open-source nature, while a strength, also allows for extensive system modifications. Users often customize their devices with custom ROMs, kernels, root access, or various system-level tweaks to enhance functionality or remove OEM bloatware. However, these modifications, intentional or otherwise, can introduce security vulnerabilities, instability, or performance degradation. An Android system integrity audit is crucial for diagnosing issues, ensuring device security, and restoring a pristine operating system baseline. This guide delves into the tools and methods necessary to identify and reverse such modifications, returning your device to a factory-fresh state.

Understanding Android System Modifications

Before an audit, it’s vital to understand the common vectors of Android system modification. These can range from benign user-initiated changes to malicious alterations by malware.

Common Modification Vectors

• Bootloader Unlocking: The first step for most advanced modifications, allowing custom binaries to be flashed.
• Custom Recovery (e.g., TWRP): Replaces the stock recovery, enabling flashing of unsigned ZIP files, backups, and restores.
• Root Access (e.g., Magisk, SuperSU): Grants superuser permissions to apps, allowing deep system changes.
• Custom ROMs (e.g., LineageOS): Completely replaces the stock Android OS with an alternative, often updated, and feature-rich version.
• Custom Kernels: Replaces the device’s core operating system component, affecting performance, battery life, and hardware interaction.
• System Partitions: Direct modification of system files, framework resources, or `system_ext` partition content.
• Dynamic Partitions: Devices using Android 10+ often employ dynamic partitions (`super` partition), adding complexity to modifications and flashing.

Phase 1: Detecting Modifications

The first step in restoring integrity is identifying what has been changed. This requires inspecting various aspects of the device’s software.

1. Bootloader Status & OEM Unlocking

The bootloader’s state is the most fundamental indicator of modification potential. An ‘unlocked’ bootloader allows flashing. A ‘re-locked’ bootloader on a device that previously had an unlocked one might still indicate prior tampering, especially if it doesn’t display a verified boot status.

adb reboot bootloaderfastboot oem device-info

Or for some devices:

fastboot getvar all

Look for `device unlocked: true` or similar indicators. If `fastboot` commands fail, ensure your device is in fastboot mode and connected correctly.

2. Custom Recovery & Root Presence

A custom recovery replaces the stock recovery image. You can often check this by booting into recovery mode. Root presence can be detected via specific apps or by attempting to run a `su` command.

adb shell su -c 'id'

If this returns `uid=0(root) gid=0(root)`, the device is rooted. If `su` is not found or permission is denied, it’s likely not rooted (or root access is cleverly hidden).

3. Filesystem Integrity & dm-verity

Android Verified Boot (AVB) and `dm-verity` are critical for ensuring the integrity of system partitions. `dm-verity` cryptographically verifies the system partition’s blocks against a known good state. If modifications are detected, it prevents booting or flags a warning.

adb shell getprop | grep 'verity'

Look for properties like `ro.boot.flash.locked` (should be `1` for locked), `ro.boot.verifiedbootstate` (should be `green` for healthy, `yellow` or `orange` indicates modification), and `ro.boot.vbmeta.device_state` (should be `locked`).

You can also manually verify system file hashes if you have a known good stock image. For example, comparing the hash of `/system/bin/app_process` from the device against a stock image.

adb pull /system/bin/app_processapp_process.sha256sum # calculate hash on pulled file

4. Kernel & Boot Image Analysis

A custom kernel or boot image is a common modification. While difficult to detect without a reference, a modified kernel might expose different `proc` or `sysfs` entries, or have different version strings.

adb shell cat /proc/versionadb shell dmesg | grep 'Linux version'

Compare this output to the expected stock kernel version for your device and OS build.

Phase 2: Restoring a Clean OS Baseline

Restoring a clean baseline typically involves flashing stock firmware, which overwrites all modified partitions with original manufacturer images.

1. Obtaining Stock Firmware

This is the most crucial step. You MUST obtain the correct factory image for your specific device model and region. Using an incorrect image can permanently brick your device. Sources include:

• Official OEM websites (e.g., Google’s factory images for Pixel devices).
• Reputable community forums (e.g., XDA Developers, with caution and verification).
• Carrier websites (less common, but possible).

Ensure the downloaded firmware is the exact version you intend to install, and ideally, cryptographically verify its integrity if a hash is provided by the source.

2. Flashing Factory Images via Fastboot

Most stock firmwares come as a bundle of `.img` files (boot, system, vendor, etc.) and a flashing script (e.g., `flash-all.sh` for Google Pixel). Always backup your important data before proceeding, as flashing will wipe your device.

1. Extract Firmware: Unzip the downloaded factory image.
2. Enter Fastboot Mode:

adb reboot bootloader

3. Flash Partitions: Navigate to the extracted firmware directory and execute the flashing commands. A generic sequence for newer devices (A/B partition scheme, dynamic partitions) might involve:

fastboot flash boot boot.imgfastboot flash dtbo dtbo.imgfastboot flash product product.imgfastboot flash system_ext system_ext.imgfastboot flash vendor vendor.imgfastboot flash vbmeta vbmeta.imgfastboot flash vbmeta_system vbmeta_system.imgfastboot update <image_name>.zip # For newer Android versions using `update` command

For some devices, you might need to flash a `super.img` or use a specific `fastboot update` command with a full factory image zip.

4. Wipe Data (Factory Reset): This is crucial to clear any residual user data or app modifications.

fastboot -w # or fastboot erase userdata && fastboot erase cache

5. Reboot:

fastboot reboot

If a `flash-all.sh` (Linux/macOS) or `flash-all.bat` (Windows) script is provided with your factory image, it’s generally safest to use that, as it handles the correct flashing order and necessary wipes automatically. Ensure `adb` and `fastboot` are in your PATH.

3. Relocking the Bootloader (Caution!)

After flashing stock firmware, relocking the bootloader restores the highest level of security and re-enables Android Verified Boot fully. This step is irreversible without another data wipe and potentially requires OEM unlocking again.

fastboot flashing lock

WARNING: This command will perform a factory reset. Only relock if you are absolutely certain the device is running 100% stock firmware. Relocking with a custom ROM or kernel can brick your device.

4. Verifying dm-verity and Android Verified Boot (AVB)

Once the device reboots, re-run the `getprop` commands from Phase 1 to ensure that `ro.boot.verifiedbootstate` is `green` and `ro.boot.vbmeta.device_state` is `locked`. This confirms that AVB and `dm-verity` are active and verifying the system’s integrity.

Conclusion

Auditing and restoring an Android device to a clean OS baseline is a critical process for maintaining security, stability, and performance. By understanding the common modification vectors, utilizing tools like `adb` and `fastboot` to detect changes, and carefully flashing official factory images, you can effectively reverse system modifications. Always proceed with caution, ensure you have the correct firmware, and back up your data, as these procedures can lead to data loss or device bricking if performed incorrectly. A clean OS baseline ensures your device operates as intended by the manufacturer, free from unintended alterations.