Introduction: The Unseen Layers of Android OEM Firmware

Android devices, while offering a semblance of openness, often ship with highly customized Original Equipment Manufacturer (OEM) firmware. This firmware contains not just the Android Open Source Project (AAOSP) components but also proprietary drivers, services, applications, and often, undocumented modifications. For security researchers, privacy advocates, and ethical hackers, dissecting this OEM firmware is crucial for uncovering hidden functionalities, potential backdoors, security vulnerabilities, or even pre-installed malware. This guide provides a practical, expert-level walkthrough on how to acquire, extract, and begin reverse-engineering Android OEM firmware.

The goal is to demystify the black box that many OEMs present, enabling deeper scrutiny of what truly runs on our devices. We’ll cover obtaining firmware images, the tools and techniques for extracting various partition images, and initial steps for analyzing the contained binaries and applications.

Phase 1: Acquiring the Firmware Image

Over-The-Air (OTA) Updates & Manufacturer Websites

The simplest and often safest method to obtain firmware is through official channels. Many OEMs provide firmware images directly on their support websites, particularly for devices that allow manual flashing. Alternatively, monitoring OTA update traffic can reveal direct download links to full or incremental update packages.

• Manufacturer Support Sites: Check sections like “Downloads,” “Support,” or “Developer Resources” for your specific device model.
• Third-Party Firmware Repositories: Sites like XDA-Developers or specific brand forums often host firmware files. Exercise caution and verify sources.
• Capturing OTA Updates: While an update is downloading, you can often locate the temporary update package in directories like /data/data/com.android.providers.downloads/cache or /cache on a rooted device. You might need a network proxy (e.g., Burp Suite) to intercept the download URL.

Direct Device Dumping (Advanced)

When official sources fail, direct dumping from a physical device is the last resort. This typically requires root access, booting into a special mode (like Qualcomm’s EDL mode, MediaTek’s BROM mode), or exploiting vulnerabilities.

If you have root access, you can use the dd command to dump partitions:

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

Identify partition names using ls -l /dev/block/by-name. For EDL mode, specific tools like QPST or community-developed alternatives are needed to interact with the device’s bootloader and extract raw flash images.

Phase 2: Extracting and Dissecting the Firmware Bundle

Understanding Common Firmware Formats

OEM firmware packages come in various forms. Common formats include:

• Standard ZIP archives containing partition images (e.g., system.img, boot.img, vendor.img).
• payload.bin: Used by OnePlus, Oppo, Realme, and others, containing a collection of sparse partition images.
• super.img: Introduced with Android 10, this dynamic partition super-image consolidates multiple logical partitions (e.g., system, vendor, product, odm).
• Sparse images: Compressed raw disk images, often identifiable by the .img extension, but requiring conversion before mounting.

Tooling for Initial Extraction

Handling payload.bin

The payload_dumper tool is excellent for extracting partitions from payload.bin files.

git clone https://github.com/ssut/payload-dumper-go.git
cd payload-dumper-go
go build .
./payload-dumper-go -p /path/to/payload.bin -o output_directory

This will extract all included partition images (e.g., system.img, vendor.img) into the specified output directory.

Handling super.img (Dynamic Partitions)

For Android 10+ devices, super.img bundles logical partitions. You’ll need lpunpack (part of AOSP utilities) or tools like ext4_unpacker/simg2img combined with loop mounting.

# Using lpunpack (requires building from AOSP or finding a pre-compiled binary)
lpunpack --output=extracted_partitions /path/to/super.img

# Alternative for sparse images within super.img (if lpunpack fails or for other sparse .img files)
simg2img /path/to/super.img /tmp/super.raw.img
mount -t ext4 -o loop /tmp/super.raw.img /mnt/super_mount

After extraction, you’ll have individual partition images, typically in ext4 format, ready for detailed analysis.

Phase 3: Filesystem Analysis and Key Component Identification

Navigating the Android Filesystem Structure

Once partitions like system.img and vendor.img are extracted, mount them to explore their contents:

sudo mount -t ext4 -o loop /path/to/system.img /mnt/system_mount
sudo mount -t ext4 -o loop /path/to/vendor.img /mnt/vendor_mount

Key directories to investigate for OEM customizations and potential threats:

• /system/app: User-facing system applications.
• /system/priv-app: Privileged system applications with elevated permissions.
• /system/bin & /vendor/bin: Native executables and shell scripts.
• /system/lib & /vendor/lib: Shared libraries (often containing proprietary code).
• /etc/init, /etc/init.d, /vendor/etc/init: Init scripts defining system services.
• /system/etc/security: Certificate authorities, SELinux policies.
• /vendor/overlay: Runtime resource overlays, often for OEM themes or features.

Focusing on APEX Modules and APKs

Android Package (APKs) files are the primary distribution format for applications. APEX (Android Pony EXpress) modules, introduced in Android 10, are similar but for system components that can be updated outside full system updates.

Analyzing APKs

Use `apktool` to decompile APKs into smali code and resources. Focus on apps found in /system/app, /system/priv-app, and any suspicious APKs within /vendor or other custom directories.

java -jar apktool.jar d com.oem.customapp.apk -o com_oem_customapp_decoded

Examine the AndroidManifest.xml for permissions, services, receivers, and content providers. Review the smali code for network activity, SMS/call interactions, hidden APIs, and unusual data access.

Analyzing APEX Modules

APEX files are essentially squashfs images. They can be mounted and explored like regular filesystems:

sudo mount -t squashfs -o loop /path/to/com.android.some.apex /mnt/apex_mount

Inside, you’ll find native libraries (.so files) and executables that need further reverse engineering.

Phase 4: Reverse Engineering Native Binaries and Services

Tools of the Trade: Ghidra and IDA Pro

For native ARM/ARM64 binaries (e.g., .so libraries, executables in /system/bin), powerful reverse engineering tools are indispensable.

• Ghidra: A free and open-source software reverse engineering (SRE) suite developed by the NSA. It supports a wide range of processors, including ARM, and provides excellent decompilation capabilities.
• IDA Pro: A commercial disassembler and debugger, considered an industry standard, with extensive features for complex binary analysis.

Load suspicious executables or libraries into Ghidra or IDA Pro. Pay close attention to imported and exported functions, system calls, network-related functions (socket, connect, send, recv), and any obfuscated or encrypted sections.

Identifying Potential Backdoors or Undocumented Features

When analyzing, look for patterns or code that suggests malicious intent or hidden capabilities:

• Unusual Network Activity: Hardcoded IP addresses, domains, or communication protocols that bypass standard Android network security.
• Hidden Diagnostic Modes/APIs: Services or activities triggered by specific intents, secret codes, or undocumented ADB commands that grant privileged access.
• Excessive Permissions: System services or background applications with permissions that far exceed their stated functionality (e.g., a
  
  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 →