Understanding Android Boot Image Integrity

The Android operating system, while open-source, relies heavily on a secure boot process to maintain device integrity. At the heart of this process lies the boot.img, a crucial component that houses the kernel, ramdisk, and often the Device Tree Blob (DTB). Malicious actors or even well-intentioned but misguided modifications can introduce “stealthy” kernel patches, altering system behavior, bypassing security features, or injecting persistent backdoors. This guide will walk you through the expert-level process of unpacking, analyzing, identifying, and ultimately reverting these hidden modifications.

Why Inspect and Revert?

• Security Vulnerabilities: Patches might disable SELinux, bypass dm-verity, or introduce arbitrary code execution paths.
• Performance Degradation: Unoptimized or rogue patches can significantly impact system responsiveness and battery life.
• Stability Issues: Incompatible or poorly implemented modifications can lead to system crashes or boot loops.
• Maintaining Device Integrity: Ensuring your device runs a clean, untampered kernel is paramount for trust and security, especially for sensitive data.

Prerequisites and Tools

Before diving in, ensure you have the following tools and knowledge:

• Android SDK Platform Tools: For adb and fastboot.
• Basic Linux Command Line Proficiency: Essential for navigation and script execution.
• magiskboot: A powerful tool for unpacking/repacking boot images.
• unpackbootimg/mkbootimg: Alternative tools often found in AOSP source or custom kernel projects.
• Hex Editor: (e.g., hexedit, xxd, or graphical like HxD) for binary inspection.
• Disassembler/Decompiler: (e.g., Ghidra, IDA Pro, objdump) for advanced kernel binary analysis.
• dtbtool/dtc (Device Tree Compiler): For DTB analysis.

Step 1: Extracting the Boot Image

The first step is to obtain the boot.img from your device. This can be done via adb if your device is rooted, or through fastboot if you have an unlocked bootloader and the ability to dump partitions.

Method A: Rooted Device (ADB)

If your device is rooted, you can directly pull the boot partition. Locate your boot partition using cat /proc/partitions or ls -l /dev/block/by-name/.

adb shell
sudo su
dd if=/dev/block/by-name/boot of=/sdcard/boot.img
exit
exit
adb pull /sdcard/boot.img .

Method B: Unlocked Bootloader (Fastboot)

If you have an unlocked bootloader, you can often dump the boot partition directly from the bootloader interface. This command varies slightly by device, but generally involves:

fastboot devices
fastboot flash boot_a boot.img (if you have a known good image to flash after dumping)
fastboot --slot all dump boot boot.img (or similar command depending on device)

Alternatively, if you have access to a factory image for your device, the boot.img can usually be found within the provided ZIP file.

Step 2: Unpacking the Boot Image

Once you have boot.img, it’s time to unpack its contents. We’ll primarily use magiskboot due to its robust support for various boot image formats.

# Make sure magiskboot is executable
chmod +x magiskboot

# Unpack the boot image
./magiskboot unpack boot.img

# This will output several files:
# boot.img-kernel: The raw kernel image
# boot.img-ramdisk.cpio: The compressed ramdisk archive
# boot.img-dtb (if present): The Device Tree Blob
# boot.img-cmdline, boot.img-base, etc.: Configuration parameters

Alternatively, if magiskboot isn’t an option, you can use unpackbootimg:

unpackbootimg -i boot.img -o unpacked_boot

This will create an unpacked_boot directory with similar components.

Step 3: Analyzing the Kernel Image

The kernel image (boot.img-kernel or kernel) is the most critical component for identifying stealthy patches. These patches often target security functions, system calls, or low-level hardware interactions.

Initial Inspection: Binary Diffing

If you have a known-good, unmodified kernel image for your device and Android version, a binary diff is the fastest way to spot differences.

# Assuming original_kernel is your reference kernel
diff -uw original_kernel boot.img-kernel

A textual diff on a binary file won’t be very readable, but it will quickly tell you if the files are identical. If they differ, deeper analysis is required.

Disassembly and Heuristic Analysis

For deeper analysis, you’ll need a disassembler. Using objdump or a graphical tool like Ghidra/IDA Pro, you can convert the raw kernel binary into assembly code.

# Assuming it's an ARM64 kernel (adjust arch if needed)
file boot.img-kernel # To confirm architecture
objdump -D -M arm boot.img-kernel > kernel.s

Look for:

• Hooks: Jumps (B, BL) or load-register-and-branch instructions (LDR PC, [SP, #offset]) at the beginning of critical functions (e.g., related to SELinux, ptrace, mmap, do_execve).
• Modified System Calls: System call tables (`sys_call_table`) are prime targets. Any changes here could redirect calls to malicious functions.
• Patched Security Checks: Look for modifications to functions like selinux_enforcing_enabled(), security_task_prctl(), do_cred_init(), or other security hooks. Search for common patch patterns like `mov w0, #0` (return 0, indicating success/disabling a check) where a security check should normally return an error or perform validation.
• Unusual Data Segments: Added read-write or executable sections could indicate injected code.

Step 4: Analyzing the Ramdisk

The ramdisk contains the initial file system that the kernel mounts at boot. It’s often used for early system initialization, SELinux policy, and critical binaries. Stealthy patches here might involve:

• Modified init.rc scripts: Adding new services, modifying existing ones, or changing execution permissions.
• Altered Binaries: Replacing or patching essential tools like init, adbd, or other system daemons.
• SELinux Policy Changes: Weakening security policies to allow unauthorized operations.

Extracting the Ramdisk

# Create a directory for the ramdisk contents
mkdir ramdisk_contents
cd ramdisk_contents

# Extract the CPIO archive
cpio -idm < ../boot.img-ramdisk.cpio

What to Look For:

• init.rc and fstab.*: Check for unusual commands, service declarations, or modifications to mount points that could bypass dm-verity or remount partitions as writable.
• sbin/init: Compare this binary against a known-good version. Any changes could indicate a rootkit or backdoor.
• sepolicy/file_contexts: Inspect SELinux policy files for permissive rules or new domains that allow privileged operations.
• New/Modified Binaries: Look for any unfamiliar executable files in /sbin, /bin, or other critical directories.

Step 5: Analyzing the Device Tree Blob (DTB)

While less common for directly injecting malicious code, the DTB can be modified to alter hardware behavior, disable security features (e.g., trustzone), or change boot parameters in subtle ways. Using dtc (Device Tree Compiler) or dtbtool, you can decompile the DTB:

# If you have dtbtool
./dtbtool -s 2048 -o dt.img -i boot.img-dtb

# Or using dtc (device tree compiler, often part of kernel build tools)
dtc -I dtb -O dts -o dtb.dts boot.img-dtb

Examine the decompiled .dts file for unexpected node properties, memory region changes, or disabled security features related to hardware. Compare with an original DTB if available.

Step 6: Reverting Patches and Rebuilding

Once you’ve identified a patch, reverting it depends on its nature:

• Ramdisk Changes: Replace modified files (e.g., init.rc, binaries) with their original counterparts. Then, repack the ramdisk:

cd ramdisk_contents
find . | cpio -H newc -o > ../new_ramdisk.cpio
cd ..

• Kernel Patches: This is more complex. Ideally, you would revert the specific commit in the kernel source code and recompile. If a binary patch, you might need to use a hex editor to restore original bytes, but this is extremely risky and error-prone. Replacing the entire kernel with a known-good stock kernel is often the safest binary-level reversion.

Rebuilding the Boot Image

After making your changes (e.g., replacing boot.img-ramdisk.cpio with new_ramdisk.cpio), you can rebuild the boot.img using magiskboot or mkbootimg.

# Using magiskboot (replace files in the current directory)
./magiskboot repack boot.img

# Using mkbootimg (you'll need the original parameters from `magiskboot unpack` output)
mkbootimg --kernel boot.img-kernel --ramdisk new_ramdisk.cpio --dtb boot.img-dtb --cmdline "$(cat boot.img-cmdline)" --base "$(cat boot.img-base)" --pagesize "$(cat boot.img-pagesize)" --board "$(cat boot.img-board)" -o new_boot.img

Important: Ensure all parameters (cmdline, base, pagesize, board, etc.) exactly match the original `boot.img`. Incorrect parameters will lead to a bricked device.

Conclusion

Identifying and reverting stealthy Android kernel patches is a critical skill for anyone serious about device security and integrity. It requires a deep understanding of the Android boot process, familiarity with command-line tools, and a meticulous approach to binary analysis. By following these steps, you empower yourself to diagnose and rectify potentially harmful modifications, ensuring your Android device operates as intended, free from hidden intrusions.