Hacktricks-skills mediatek-secure-boot-analysis
Analyze MediaTek bootloader vulnerabilities, particularly bl2_ext secure-boot bypasses. Use this skill when investigating MediaTek device boot chains, analyzing secure boot verification gaps, triaging boot logs for authentication bypasses, or documenting firmware security issues. Trigger when users mention MediaTek bootloaders, bl2_ext, secure boot bypass, EL3 vulnerabilities, seccfg manipulation, or firmware analysis on MediaTek devices.
git clone https://github.com/abelrguezr/hacktricks-skills
skills/hardware-physical-access/firmware-analysis/android-mediatek-secure-boot-bl2_ext-bypass-el3/SKILL.MDMediaTek Secure Boot Analysis
A skill for analyzing MediaTek bootloader vulnerabilities, particularly the bl2_ext secure-boot bypass that allows EL3 code execution when seccfg is unlocked.
When to Use This Skill
Use this skill when:
- Analyzing MediaTek device boot chains for security vulnerabilities
- Investigating bl2_ext verification gaps or secure boot bypasses
- Triaging boot/expdb logs for authentication status
- Documenting firmware security issues on MediaTek platforms
- Understanding seccfg manipulation and DA-mode operations
- Researching EL3-level vulnerabilities in MediaTek bootloaders
Safety Warnings
Critical: Early-boot patching can permanently brick devices if offsets are wrong. Always:
- Keep full dumps of all partitions before modification
- Maintain a reliable recovery path (EDL/DA access, test points)
- Test on disposable hardware first
- Use board-specific logging/UART to validate execution paths
MediaTek Boot Flow
Normal Boot Path
BootROM → Preloader → bl2_ext (EL3, verified) → TEE → GenieZone (GZ) → LK/AEE → Linux kernel (EL1)
Vulnerable Path (seccfg unlocked)
BootROM → Preloader → bl2_ext (EL3, NOT verified) → [attacker-controlled] → TEE/GZ/LK/Kernel (unsigned)
Key Trust Boundary: bl2_ext executes at EL3 and verifies TEE, GenieZone, LK/AEE, and kernel. If bl2_ext itself is not authenticated, the entire chain collapses.
Root Cause Analysis
On affected devices, the Preloader does not enforce authentication of the bl2_ext partition when seccfg indicates an "unlocked" state. This allows:
- Flashing attacker-controlled bl2_ext that runs at EL3
- Patching the verification policy function to unconditionally report success
- Loading unsigned TEE/GZ/LK/Kernel images downstream
Triage Workflow
Step 1: Dump Boot/Expdb Logs
Capture boot logs around the bl2_ext load phase. Look for these indicators:
# Search for authentication status grep -i "img_auth_required" boot.log grep -i "cert vfy" boot.log
Step 2: Analyze Authentication Status
Verification SKIPPED (vulnerable):
[PART] img_auth_required = 0 [PART] Image with header, name: bl2_ext, addr: FFFFFFFFh, mode: FFFFFFFFh, size:654944, magic:58881688h [PART] part: lk_a img: bl2_ext cert vfy(0 ms)
Verification ENFORCED (not vulnerable via this path):
[PART] img_auth_required = 1 [PART] part: lk_a img: bl2_ext cert vfy(127 ms)
Step 3: Check seccfg Status
Use Penumbra or similar DA tools to check target configuration:
# Check if SBC (Secure Boot Chain) is enabled # bit 0 set → SBC enabled
Verification Logic Locations
The relevant check typically resides inside the bl2_ext image:
- Function names:
,verify_img
, or similarsec_img_auth - Patch approach: Force function to return success or bypass verification call entirely
- Requirements: Preserve stack/frame setup and return expected status codes
Practical Analysis Chain
- Obtain bootloader partitions via OTA/firmware packages, EDL/DA readback, or hardware dumping
- Identify bl2_ext verification routine using disassembly/reverse engineering
- Analyze patch points for verification bypass
- Document affected components (TEE, GZ, LK, Kernel)
Tooling References
Fenrir (PoC Patching Toolkit)
Reference implementation for Nothing Phone (2a) and CMF Phone 1:
./build.sh pacman # build from bin/pacman.bin ./build.sh pacman /path/to/boot.bin # build from custom bootloader ./flash.sh # flash via fastboot
Supported devices:
- Nothing Phone (2a) (Pacman) - fully supported
- CMF Phone 1 (Tetris) - partial support
Penumbra (MTK DA Operations)
Rust crate/CLI for MTK preloader/bootrom interaction:
Capabilities:
- Discover MTK USB port
- Load Download Agent (DA) blob
- Issue privileged commands (seccfg lock flipping, partition readback)
Environment setup:
# Linux sudo apt install libudev-dev sudo usermod -aG dialout $USER # Create udev rules or run with sudo
Device-Specific Notes
| Device | Status | Notes |
|---|---|---|
| Nothing Phone (2a) | Confirmed | Pacman, fully supported |
| CMF Phone 1 | Known working | Tetris, incomplete support |
| Vivo X80 Pro | Observed | Did not verify bl2_ext even when locked |
| NothingOS 4 stable | Patched | BP2A.250605.031.A3 re-enabled verification |
Security Implications
- EL3 code execution after Preloader
- Full chain-of-trust collapse for rest of boot path
- Ability to boot unsigned TEE/GZ/LK/Kernel
- Persistent compromise possible via modified boot images
Analysis Scripts
Use the bundled scripts for common analysis tasks:
# Analyze boot logs for authentication status python scripts/analyze-boot-logs.py <boot.log> # Check seccfg status from DA output python scripts/check-seccfg-status.py <da-output.json>
References
- Fenrir – MediaTek bl2_ext secure‑boot bypass
- Penumbra – MTK DA flash/readback & seccfg tooling
- Cyber Security News – Nothing Phone PoC
Output Format
When analyzing a MediaTek device, provide:
- Device identification (model, chipset, firmware version)
- Boot chain analysis (normal vs. vulnerable path)
- Authentication status (img_auth_required value, verification time)
- Vulnerability assessment (affected, patched, unknown)
- Recommended next steps (further analysis, tooling, safety precautions)