| Component | Role | Security Mechanism | |-----------|------|---------------------| | | First-stage immutable code | eFuse-based secure boot (RSA-2048/SHA-256) | | Preloader | Second-stage loader | Signature verification of next stage (LK/TEE) | | TEE (TrustZone) | Secure world OS (Kinibi/Trustonic) | Secure storage, cryptographic ops | | Secure Boot | Chain of trust from ROM to kernel | Image signing via OEM keys | | DA (Download Agent) | Flash programming mode (Preloader/BROM) | Signed DA required; anti-rollback via eFuses |
: The BootROM USB handler implements a DOWNLOAD command that expects a signed DA. However, a sequence of crafted USB control transfers (specifically using CMD_SEND_DA with specific length/hash checks bypass) causes the BootROM to skip signature verification and execute arbitrary code from the USB host.
: The preloader checks the signature of the Little Kernel (LK) bootloader using a stored public key. However, due to an integer overflow in the signature length field (or improper handling of malformed headers), the preloader may treat an unsigned image as valid.
: BootROM does not allow arbitrary code execution over USB unless a signed DA is provided. However, logic flaws in the DA handshake or USB command parsers have proven fatal. 3. Attack Vectors & Deep Dive 3.1 BootROM USB Bypass (MTK Bypass Tool Family) CVE(s) : Various undisclosed / publicly known as “MTK Meta Mode bypass”, “BROM exploit” Affected chips : MT6735, MT6750, MT6761, MT6762, MT6765, MT6580, MT8163, MT8173, many pre-2020 chips.
