Introduction to MediaTek’s Boot ROM and Preloader

MediaTek System-on-Chips (SoCs) power a vast array of devices, from smartphones and tablets to smart TVs and IoT gadgets. Understanding their boot process is crucial for security researchers, device developers, and enthusiasts looking to gain deeper control or uncover vulnerabilities. At the heart of this process lies the Boot ROM (BROM) and the Preloader, two fundamental stages responsible for initializing the hardware and preparing the system for the operating system.

The BROM is an immutable, mask-ROM embedded within the SoC, serving as the very first piece of code executed upon power-on. Its primary role is to perform initial hardware setup and, critically, to verify and load the Preloader. BROM mode, often referred to as the ‘download mode’ or ‘factory mode,’ is a special state the SoC can enter if the Preloader fails its integrity checks, or if specific hardware/software triggers are met. This mode is a powerful diagnostic and flashing interface, often allowing low-level access to the device.

The Preloader, loaded and verified by BROM, is the second stage of the boot process. It’s stored on non-volatile memory (like eMMC or UFS) and loaded into SRAM (Static RAM) by the BROM. Its responsibilities include initializing DRAM, setting up essential peripherals like USB and storage controllers, and then loading the subsequent boot stages (like LK/U-Boot). Because the Preloader is responsible for many critical initializations and integrity checks, it often harbors the vulnerabilities that can be exploited to force the device into BROM mode, bypassing higher-level security measures.

The MediaTek Boot Process: A Hierarchical Overview

To effectively reverse engineer the Preloader, one must first grasp the entire MediaTek boot hierarchy.

Boot ROM (BROM)

The BROM is the immutable root of trust. It executes immediately after reset, performs minimal hardware initialization, checks for specific boot conditions (e.g., preloader integrity, specific pin states), and then attempts to load the Preloader from designated storage. If loading fails or specific conditions are met, the BROM can fall back into its secure ‘BROM mode,’ exposing a USB-based interface for flashing and debugging, often restricted by hardware fuses but occasionally vulnerable to bypasses.

Preloader (BL1/BL2)

The Preloader is the first mutable boot stage. The BROM loads a small initial portion (BL1) into SRAM, which then initializes DRAM and copies the full Preloader (BL2) into DRAM for execution. The Preloader initializes more complex peripherals, performs further integrity checks on the next boot stage (typically LK/U-Boot), and then hands off control. Vulnerabilities in the Preloader’s integrity checks, hardware initialization, or error handling routines are prime targets for forcing a return to BROM mode.

Subsequent Stages

After the Preloader successfully executes, it loads and transfers control to the next stage, which is commonly the Little Kernel (LK) or U-Boot. These stages are responsible for more advanced hardware initialization, loading the kernel, and ultimately booting the Android or Linux operating system.

Essential Tools and Setup for Preloader Analysis

Successful reverse engineering requires a combination of specialized hardware and software.

Hardware Requirements

• MediaTek-based device: A smartphone, tablet, or development board (e.g., a Helio-based phone) is essential.
• USB-TTL serial adapter: For monitoring serial console output, which can provide invaluable debugging information.
• JTAG/SWD debugger (Optional): For advanced, low-level debugging, though often challenging to enable on retail devices.

Software Tools

• Disassemblers/Decompilers: Ghidra (free and open-source) or IDA Pro (commercial) are indispensable for static analysis of the binary.
• Binary Analysis: Binwalk for identifying embedded filesystems, compression, or other binary structures. hexdump for byte-level inspection.
• Disk Utilities: dd for extracting raw partition images from rooted devices.
• Flash Tools: MediaTek SP Flash Tool, along with appropriate DA (Download Agent) files, for interacting with devices in BROM/Preloader mode, and for readback operations.
• Terminal Emulator: minicom or screen for interacting with the device via the USB-TTL serial adapter.

Extracting and Initializing Preloader for Reverse Engineering

The first step is always to obtain the Preloader binary.

Obtaining the Preloader Image

There are several methods to acquire the Preloader:

• From stock firmware: Download the official firmware package for your device. Often, the Preloader is a distinct file (e.g., preloader_*.bin) within the archive.
• Using SP Flash Tool (Readback): If your device can enter BROM or a special factory mode, you can use SP Flash Tool’s ‘Readback’ feature to dump specific memory regions, including the Preloader partition.
• From a rooted device via dd: If you have root access to a running Android device, you can extract the Preloader partition directly. First, identify the Preloader partition:

  adb shell ls -l /dev/block/by-name/ | grep preloader

  Then, dump the image:

  adb shell su -c
  
          
          
          
  
              
  
                  
              
              
  
                  
  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 →