Understanding Android A/B Seamless Updates

Android’s A/B (Seamless) update mechanism revolutionized how device updates are applied, significantly improving reliability and user experience. Unlike traditional A-only updates that required a dedicated recovery partition and device downtime during installation, A/B updates allow updates to be downloaded and installed in the background while the device is still in use. When the user reboots, the device simply switches to the newly updated A/B slot, virtually eliminating the risk of a ‘bricked’ device due to update failures and minimizing user interruption.

This innovative approach works by maintaining two complete sets of root partitions (A and B). While the device runs on slot A, updates are applied to slot B. Upon reboot, the system switches to slot B. If any issues arise, the device can automatically revert to the previously working slot A, ensuring a robust update process. This hands-on lab will guide you through the process of reverse engineering these A/B update payloads, commonly found as `payload.bin` files, to extract and inspect their contents.

The Structure of an A/B Update Payload (payload.bin)

An A/B update payload, typically named `payload.bin`, is a highly compressed and structured file that contains all the necessary data to update the inactive slot. These payloads can be either ‘full’ updates, containing complete images for all target partitions, or ‘delta’ (incremental) updates, which only include the changes between the current and target versions of each partition. The `payload.bin` itself uses Google’s `brillo_update_payload` format, which defines a series of operations (e.g., replace, diff) to apply to specific blocks or files within partitions.

Key partitions often targeted in A/B updates include `system`, `vendor`, `product`, `boot`, `dtbo`, and critically, `super`. The `super` partition, introduced with Android 10, manages dynamic partitions, making the extraction process slightly more involved than simply extracting raw `.img` files.

Prerequisites and Tools

Before we begin, ensure you have the following tools installed on your Linux-based system (or WSL/macOS with necessary dependencies):

• payload-dumper-go: A Go-based tool for extracting images from `payload.bin` files.
• brotli: A generic-purpose lossless compression algorithm, often used to compress the `payload.bin` itself or its internal components.
• zstd: Another fast lossless compression algorithm, sometimes used for compressing partition images.
• simg2img: A utility to convert Android sparse images (`.img`) into raw images.
• lpunpack: A tool to unpack Android’s `super.img` into its constituent dynamic partition images.
• Optional: Python 3 with `pip` for alternative payload dumpers if `payload-dumper-go` isn’t available.

Installation Steps:

Most tools can be installed via package managers or compiled from source. For `payload-dumper-go`, it’s often easiest to download a pre-compiled binary or use `go install` if Go is set up.

# For Debian/Ubuntu-based systemssudo apt update && sudo apt install brotli zstd git make gcc# Install Go (if not already present), then payload-dumper-gogo install github.com/ssut/payload-dumper-go@latest# Or download pre-compiled binary from releases and add to PATH# For simg2img (often part of Android source or AOSP platform-tools/`android-image-tool` packages)git clone https://android.googlesource.com/platform/system/extrascd platform/system/extras/ext4_utilsmake simg2imgsudo cp simg2img /usr/local/bin/# For lpunpack (can be compiled from AOSP 'liblp' or found in some tool collections)git clone https://android.googlesource.com/platform/system/corecd platform/system/core/liblpmake lpunpacksudo cp lpunpack /usr/local/bin/

Hands-On Extraction Lab

Step 1: Obtain a payload.bin

The first step is to acquire a `payload.bin` file. These are typically found within official OTA (Over-The-Air) update ZIP files provided by device manufacturers. Download an OTA update ZIP for your target device and extract its contents. You’ll usually find `payload.bin` and `payload_properties.txt` inside.

unzip -j ota_update.zip payload.bin

Step 2: Extract Partitions from payload.bin

Now, use `payload-dumper-go` to extract all individual partition images from the `payload.bin`. This tool will convert the operations defined in the `payload.bin` into full `.img` files, even for delta updates.

payload-dumper-go payload.bin

This command will create a directory (e.g., `extracted_payload`) containing various `.img` files, such as `boot.img`, `dtbo.img`, `system.img`, `vendor.img`, `product.img`, and crucially, `super.img` if your device uses dynamic partitions.

Step 3: Handling Sparse and Super Images

Converting Sparse Images

Many extracted `.img` files, especially `system.img` and `vendor.img`, are sparse images. These need to be converted to raw images before they can be mounted or inspected effectively.

simg2img system.img system_raw.img

Unpacking the Super Partition

If your device uses dynamic partitions (Android 10+), you’ll have a `super.img`. This image is a container for multiple logical partitions. You need `lpunpack` to extract them.

lpunpack super.img

This will create directories like `super_dump` and place individual logical partition images (e.g., `system.img`, `vendor.img`, `product.img`, `system_ext.img`) within it. Note that these are already raw images, not sparse, and might still be compressed (e.g., `brotli` or `zstd` compressed `system.img`). You might need to decompress them first if they are not standard ext4 images.

Step 4: Mounting and Inspecting Partitions

Once you have raw partition images (e.g., `system_raw.img` or the images extracted from `super.img`), you can mount them to explore their file systems. This allows you to inspect files, identify changes, and extract specific components.

# Create a mount pointmkdir system_mount# Mount the raw system image (adjust loop device as needed)sudo mount -o loop system_raw.img system_mount# Explore the mounted file systemls system_mount/binls system_mount/app# Unmount when donesudo umount system_mount

Repeat this process for other partitions like `vendor.img` and `product.img` to gain a comprehensive understanding of the update’s contents.

Step 5: Analyzing Delta Updates (Optional)

For delta updates, `payload-dumper-go` performs the patching operations internally to give you full images. However, if you wanted to manually analyze the delta information, you’d delve into the `payload.bin` structure itself, which specifies block-level diffs or file-level changes. Tools like `brillo_update_payload_extractor` (Python-based) can sometimes expose these raw operations, but it’s significantly more complex and beyond the scope of this beginner-friendly lab.

Conclusion

Reverse engineering Android A/B update payloads provides invaluable insight into how device manufacturers push updates and allows advanced users to inspect system changes, extract proprietary files, or even prepare custom ROMs. By understanding the `payload.bin` format and utilizing the right tools, you can demystify the seamless update process and gain full control over your device’s software components. This knowledge is crucial for custom ROM development, security research, and in-depth system analysis.