Introduction: The Evolving Landscape of Android Updates

The Android operating system has undergone significant architectural shifts over its iterations, particularly concerning how system updates are packaged and deployed. For developers, custom ROM enthusiasts, and security researchers, understanding these changes is crucial for effective reverse engineering, porting, and analysis. This guide delves into the modern Android update mechanism, specifically focusing on devices employing system_as_root and the super partition, which collectively present a new set of challenges and opportunities for those looking to peek inside OEM firmware.

Historically, the system partition was a distinct entity, separate from the root filesystem. With Android 10 and newer, many devices have adopted system_as_root, where the system partition is mounted directly as the root filesystem. Concurrently, the introduction of Dynamic Partitions, consolidated under a single super partition, further abstracts the physical layout of partitions. This tutorial will walk you through the process of extracting, unpacking, and analyzing these complex update packages.

Understanding system_as_root and the Super Partition

What is system_as_root?

Prior to system_as_root, the root filesystem was typically a ramdisk within boot.img, and the system partition was mounted on /system. With system_as_root, the system partition itself acts as the root filesystem. This change simplifies some aspects of the boot process but complicates others, especially for tools that traditionally expected a separate ramdisk for root.

The Super Partition and Dynamic Partitions

The super partition is a logical container that holds multiple dynamic partitions, such as system, vendor, product, system_ext, and potentially others. These partitions no longer have fixed physical offsets on the storage device. Instead, their layout and sizes are managed dynamically by Android’s Logical Partition Manager (LPM). This architecture enables more flexible OTA updates, allowing partitions to be resized on-the-fly, but it also means that tools must understand the super partition’s metadata to access the contained images.

Prerequisites and Essential Tools

To follow this guide, you’ll need a Linux environment (a virtual machine or WSL is sufficient) and a few command-line tools:

• unzip: For extracting ZIP archives.
• simg2img: Converts Android sparse images to raw images.
• lpunpack: Extracts logical partitions from a super.img.
• payload-dumper-go (or Python equivalent): Extracts individual images from payload.bin.
• mount: For loop-mounting raw disk images.
• ext4fuse (optional, for macOS): Mounts EXT4 images without root if loop mount isn’t feasible.

Ensure these tools are installed and accessible in your PATH. payload-dumper-go can be compiled from source or downloaded as a pre-built binary. lpunpack is often found in Android platform-tools or can be compiled from AOSP source.

# Example installation on Debian/Ubuntu: sudo apt update sudo apt install unzip android-sdk-platform-tools-core # Provides simg2img and lpunpack sudo apt install golang # If compiling payload-dumper-go from source

Step-by-Step Guide: Unpacking and Analyzing

Step 1: Obtain the OEM Update Package

The first step is to acquire the firmware package. This is typically an official OTA update ZIP file downloaded directly to the device or found on OEM firmware repositories (e.g., Xiaomi Firmware Updater, Oxygen Updater for OnePlus). For this tutorial, we’ll assume you have a .zip file containing the update.

Step 2: Extract the payload.bin

Modern A/B (seamless) update packages primarily use a payload.bin file, which contains all the updated partition images. Extract this from the main ZIP file:

unzip -j ota_update_package.zip payload.bin

Step 3: Unpack payload.bin using payload-dumper-go

payload-dumper-go is an excellent tool for extracting all individual partition images contained within the payload.bin. It will output several .img files, including super.img, boot.img, dtbo.img, and others.

./payload-dumper-go -p payload.bin

This command will create a directory (e.g., output) containing images like super.img, boot.img, dtbo.img, etc. If the update is not A/B, you might instead find system.img.ext4, vendor.img.ext4, etc., directly in the ZIP, which simplifies the process.

Step 4: Decode the Super Partition (super.img)

If your device uses dynamic partitions, the critical images like system, vendor, and product will be encapsulated within super.img. We need to unpack it to access these logical partitions.

lpunpack --input super.img --output super_extracted_images/

This command will create the directory super_extracted_images/ and place the extracted system.img, vendor.img, product.img, etc., inside it. These extracted images are typically sparse EXT4 images.

Step 5: Convert Sparse Images to Raw EXT4 and Mount

The images extracted (e.g., system.img, vendor.img) are often in a sparse format to save space. Before mounting, they need to be converted to raw EXT4 images.

simg2img super_extracted_images/system.img system_raw.img simg2img super_extracted_images/vendor.img vendor_raw.img # ... and so on for other images

Now, mount these raw EXT4 images to a temporary directory for analysis:

mkdir system_mount mkdir vendor_mount sudo mount -o loop system_raw.img system_mount/ sudo mount -o loop vendor_raw.img vendor_mount/

You can now browse the contents of these partitions as if they were mounted on a live Android device. Remember to unmount them when done:

sudo umount system_mount/ sudo umount vendor_mount/

Step 6: Analyze boot.img (Optional but Recommended)

Even with system_as_root, the boot.img still contains the kernel and a small ramdisk (used for early boot stages, device tree, and verity metadata). Analyzing it can reveal kernel versions, boot arguments, and custom init scripts. Tools like unpackbootimg (from AOSP source or Android Image Kitchen) can deconstruct it:

# Assuming unpackbootimg is in your PATH mkdir boot_img_contents unpackbootimg --input boot.img --output boot_img_contents/

This will extract the kernel, ramdisk, and other components into the specified directory.

Key Areas for Reverse Engineering and Analysis

Once the images are mounted, you can explore various aspects of the OEM’s firmware:

• System Properties and Build Information

  Examine /system/build.prop and /vendor/build.prop for device model, Android version, build number, security patch level, and OEM-specific properties.

• Init Scripts and Boot Processes

  Look into /system/etc/init (and its subdirectories) and /vendor/etc/init. These directories contain .rc scripts that control the early boot process, service startups, and device-specific configurations. Understanding these is vital for debugging boot issues or customizing device behavior.

• OEM Applications and Binaries

  Explore /system/app, /system/priv-app, /vendor/app, and /product/app for OEM-specific applications. Check /system/bin, /system/xbin, /vendor/bin for proprietary binaries, shell scripts, and utilities that differentiate the OEM’s Android flavor.

• Drivers and Libraries

  Inspect /vendor/lib and /vendor/lib64 (and their /system counterparts) for proprietary HALs (Hardware Abstraction Layers) and shared libraries that interface with device hardware. These are crucial for understanding device capabilities and for porting custom ROMs.

• SELinux Policies

  The SELinux policies, typically found in /system/etc/selinux, define access controls for processes and files. Analyzing these can reveal how the OEM restricts operations and enhance device security. This is often a pain point for custom ROM development.

Conclusion

Reverse engineering Android OEM updates, especially those leveraging system_as_root and dynamic partitions, is a complex yet rewarding endeavor. By systematically unpacking payload.bin, decoding super.img, and mounting individual partition images, you gain unparalleled insight into the OEM’s customizations, security implementations, and hardware integrations. This knowledge is invaluable for custom ROM development, security research, and deepening your understanding of the Android ecosystem. While the architecture continues to evolve, the fundamental principles of forensic analysis remain the same: extract, inspect, and comprehend.