Android Hardware Reverse Engineering

Reverse Engineering Lab: Unpacking, Modifying, and Re-signing Android Boot Images to Bypass Secure Boot

Google AdSense Native Placement - Horizontal Top-Post banner

Introduction to Android Secure Boot and Verified Boot

Android Secure Boot is a critical security feature designed to ensure the integrity of the device’s software from the moment it powers on. It establishes a ‘chain of trust’ starting from a hardware root of trust, typically fused into the SoC, verifying each stage of the boot process before executing it. This chain typically includes the bootloader, kernel, ramdisk, and system partitions.

Android Verified Boot (AVB), specifically AVB 2.0, extends this protection by employing cryptographic signatures to verify the authenticity and integrity of all executable code and data within the boot partition and other critical partitions (like system, vendor, dtbo). If any component is tampered with and the signature doesn’t match, the device will either refuse to boot, boot into a restricted mode, or display a warning to the user, effectively preventing unauthorized modifications.

For reverse engineers, developers, and security researchers, bypassing or managing Secure Boot is often necessary to deeply customize devices, perform security audits, or root Android. This guide will walk through the process of unpacking, modifying, and re-signing an Android boot image, focusing on methodologies relevant to a lab environment where OEM unlocking is available.

Understanding the Android Boot Image Structure

An Android boot image (boot.img) is a composite file crucial for the initial boot process. It typically contains:

  • Kernel: The core operating system.
  • Ramdisk: A small filesystem loaded into RAM, containing crucial initialization scripts (e.g., init.rc), binaries, and libraries required to mount the real root filesystem.
  • Device Tree Blob (DTB): (On ARM devices) A binary representation of the device’s hardware, passed to the kernel.

These components are bundled together with a header containing metadata like kernel load address, ramdisk size, and command-line arguments. Tools like mkbootimg and unpackbootimg are used to create and deconstruct these images.

Step 1: Extracting the Boot Image

Before modification, you need the original boot.img. There are several ways to obtain it:

  1. From Stock Firmware: The safest method is to download the official factory image for your device. The boot.img is usually found within the archive.
  2. Directly from Device (requires root or unlocked bootloader): If your device is already rooted or has an unlocked bootloader, you can use dd to pull the image directly. First, identify the boot partition:

    adb shell su -c 'find /dev/block/platform/ -name boot -o -name by-name/boot'

    Then, pull it:

    adb pull /dev/block/by-name/boot boot.img
  3. Using Fastboot (if a custom recovery is not flashed): Some devices allow dumping specific partitions via fastboot if the bootloader is unlocked and specific commands are supported (less common for boot.img directly, usually done via flashing a temporary custom recovery).

Step 2: Unpacking the Boot Image

Once you have boot.img, you can unpack it using tools like unpackbootimg (available in projects like Android Image Kitchen, or as a standalone utility).

First, install necessary tools:

sudo apt-get install abootimg android-sdk-platform-tools-core

For `unpackbootimg` (often part of `android-image-kitchen` or similar projects):

git clone https://github.com/cfig-xz/Android_Image_Kitchen.git ~/AIK_Linux_V2.1-All-in-One-Android-Tool-Kitcd ~/AIK_Linux_V2.1-All-in-One-Android-Tool-Kit./unpackimg.sh /path/to/your/boot.img

This will create a new directory (e.g., ramdisk) and extract the kernel (boot.img-zImage), ramdisk (ramdisk.cpio.gz), and other metadata files (boot.img-base, boot.img-cmdline, etc.). Keep all these metadata files; you’ll need them for repacking.

Step 3: Modifying the Ramdisk

The ramdisk is where most of our modifications will take place. It controls initial system setup, including mounting partitions, starting services, and applying security policies like dm-verity and forceencrypt.

Navigate into the extracted ramdisk directory (e.g., ~/AIK_Linux_V2.1-All-in-One-Android-Tool-Kit/ramdisk):

cd ramdisk

Common modifications include:

  • Disabling DM-Verity: Edit fstab. (e.g., fstab.qcom, fstab.pixel) to remove verify or avb flags from the system and vendor partitions. Change /dev/block/by-name/system /system ext4 ro wait,verify to /dev/block/by-name/system /system ext4 rw wait.
  • Disabling ForceEncrypt: Similarly, in fstab., remove forceencrypt or change it to encryptable for userdata partition.
  • Adding Custom Services or Binaries: Modify init.rc or other init.*.rc files to execute custom scripts or binaries upon boot (e.g., a simple ‘hello world’ script, or adding `su` binary for root access).

Example: Adding a simple script to init.rc

# In init.rc (or an appropriate .rc file)on post-fs-data    mkdir /data/local/tmp/myscript 0777 root root    write /data/local/tmp/myscript/test.txt

Android Mobile Specs & Compare Directory

Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!

Compare Devices Specs →
Google AdSense Inline Placement - Content Footer banner