BROM 模式：联发科设备的“上帝协议”
“在高通用户苦寻 9008 Programmer 时，MTK 用户正在通过 BootROM 漏洞接管整个 SoC。这是由硅片逻辑定义的物理级权限。”
1. 身份识别：BROM 与 Preloader
联发科（MTK）设备的底层救砖环境由两个截然不同的阶段组成。这是硬件引导链条中的“接力棒”逻辑，混淆它们是新手失败的第一步：
BROM (Boot ROM)
层级：硬件固化层（SoC 内部 Mask ROM）。
原理：这是处理器出厂即存在的指令。当 eFuse 校验发现启动盘（UFS/EMMC）为空、引导头损坏或探测到特定的 USB 握手信号时，CPU 将不加载任何外部代码，直接跳转至内部 BROM 地址。
识别：MediaTek USB Port (COMx)
特性：不消失，稳定连接。它是真正的“最后防线”。
Preloader
层级：软件分区层（存储器头部的第一阶段引导）。
原理：当 BROM 完成 SRAM 初始化后，会将权限移交给物理闪存中的 Preloader 分区。它负责初始化 DRAM 驱动。
识别：MTK Preloader USB VCOM
特性：几秒后自动消失（尝试跳转至 LK/Little Kernel）。如果线刷在此处断开，通常是驱动未能及时枚举。
2. 翻译官：DA (Download Agent) 的三阶段接力审计
由于 BROM 环境下手机没有任何操作系统，它无法识别复杂的镜像文件。你必须选择一个后缀为 .bin 的 DA 文件。这个文件并不是普通的镜像，而是运行在 SoC SRAM 空间里的微型系统，它分三阶段完成硬件接管：
1 UART/USB 握手序列 (Handshake)
电脑发送特定的十六进制同步信号（如 0xA1, 0xFE）。此时 BROM 正在等待指令。
审计点：如果此阶段识别不到芯片 ID，通常是数据线 D+/D- 总线阻抗过大 或 USB 2.0/3.0 控制器驱动兼容性导致的握手丢失。
2 加载第 1 段 DA (Initializing DRAM)
BROM 会将 DA 的第一部分推入 SoC 内部的 Static RAM (SRAM)。这一阶段唯一的任务是 枚举 DRAM 控制器。
审计点：如果加载进度条卡在 100% 红色不动，说明 DA 文件虽然被接受，但无法完成内存初始化。这通常是由于 UFS/EMMC 的电压控制逻辑在 DA 中未正确适配该特定机型的 PMIC（电源 IC）。
3 完全控制权转移 (Full Execution)
一旦内存跑起来，完整的 DA 会被加载。此时芯片正式具备了 LBA (逻辑块寻址) 能力，可以解析 Scatter 文件定义的物理偏移，正式开启分区的读取或写入流。
底层审计：BROM ERROR 0xC0020001
这是厂商设置的 SLA (Serial Link Authentication) 防线。在发送 `WRITE` 指令前，BROM 会通过 RSA-2048 算法要求电脑提供公钥签名。如果没有绕过（Bypass）授权，BROM 会因非法指令直接重置连接。
3. 降维打击：利用漏洞绕过授权 (Auth Bypass)
现代 MTK 机型（如天玑 9000+）大多开启了 SLA。正常情况下，没有厂商的数字签名，BROM 会处于写保护状态。但我们可以通过溢出攻击重置其安全状态位。
漏洞原理：Kamakiri 协议栈注入
MTK BROM 在解析 USB 描述符（Descriptors）时未对输入长度做严格校验。通过发送精心构造的 Payload (载荷)，我们可以改写 BROM 指令指针，强行跳转到内存中“校验通过”的逻辑分支。
mtk-client 注入阶段审计：
[#] Identified SoC: MT6893 (Dimensity 1200)
[#] Initializing exploit on device 1.14...
[+] Exploit stage 1: Payload injected into SRAM.
[+] Exploit stage 2: Security flags disabled via register patching.
[+] BROM is now Pwned. Authentication skipped.
4. 寻址核心：Scatter 文件的物理拓扑解构
Scatter（离散文件）是 MTK 刷机包的灵魂。它不仅仅是一份清单，更是对物理闪存（EMMC/UFS）的空间坐标定义。在 BROM 模式下，DA (Download Agent) 完全依赖这份文件来执行物理寻址。
- partition_index: SYS0
partition_name: preloader
linear_start_addr: 0x0
physical_start_addr: 0x0
partition_size: 0x80000
region: EMMC_BOOT_1 // 物理层关键标志
扇区对齐审计 (Sector Alignment)
对于 UFS 存储，Scatter 必须遵循 4096 字节（4KB） 对齐。如果定义的 linear_start_addr 无法被物理页大小整除，DA 将无法在物理层完成扇区锁，导致报错 0xC0050005。
物理区段锁定 (Region Mapping)
MTK SoC 默认去 EMMC_BOOT_1 (或 UFS LUN0) 寻找 Preloader。如果在 Scatter 中错误地将 Region 指向了 USER 区，即使刷机 100% 完成，设备依然会因为找不到引导头而死循环在 BROM 模式。
深度风险审计：Format All 的逻辑陷阱
在 SP Flash Tool 中选择 Format All + Download 会下发 ERASE_ALL 指令。该指令会抹除闪存中除了 RPMB (受保护管理块) 之外的所有数据，包括存放串号、射频参数和基带校准信息的 NVRAM 分区。一旦这些分区被抹除，且没有事先 Dump 备份，你的设备将面临永久性的射频故障（无信号）。
5. 刷机模式的致命选择：底层操作逻辑
在 SP Flash Tool 顶部的下拉框中，你必须基于对分区表（GPT）的理解做出选择：
- [Download Only] 逻辑：根据现有分区表（GPT）写入镜像。如果你的手机分区表未被破坏，此模式是救砖的最优解，不会触碰敏感数据。
- [Firmware Upgrade] 逻辑：先格式化所有分区，再根据 Scatter 重新构建 GPT 分区表，然后写入镜像。适用于降级系统或分区表结构发生变动的场景。
- [Format All + Download] 逻辑：彻底抹除物理闪存的所有索引。这是最后的手段。仅在闪存文件系统严重损毁、无法重建 GPT 时使用。必须搭配全盘备份恢复流程。
6. 终极自救：mtk-client 的逻辑重构
mtk-client 是基于 Python 的开源底层审计工具。与官方工具不同，它最大的技术优势在于能够在不加载 DA（Download Agent）的情况下，先利用漏洞挂载 SoC 总线，从而绕过文件系统的读写限制。
# 逻辑挂载审计：强制从 BROM 获取 GPT 结构
python3 mtk printgpt
# 分区级重构：在文件系统损毁时强行擦除 Userdata
python3 mtk e userdata
# 完整性备份：Dump 包含硬件密钥的 NVRAM 分区
python3 mtk r nvram,nvdata,nvcfg backup.bin
协议审计：为什么 mtk-client 更强？
官方工具（SP Flash Tool）在 GPT 损坏时会直接报错终止。而 mtk-client 通过 **Handshake-to-Memory** 映射，允许你在没有任何分区表的情况下，直接向存储器物理偏移地址（如 0x0）写入原始 GPT 结构。这是重建文件系统的底层核武。
7. 签名高墙：AVB 2.0 与 MTK 启动校验审计
即使在 BROM 模式下成功刷入了镜像，手机可能依然无法开机。这是因为 MTK 硬件在从 Preloader 跳转到 Kernel 时，会强制执行 AVB (Android Verified Boot) 2.0 签名审计。
核心阻碍：VBMETA 校验锚点
在 MTK 架构中，vbmeta 分区存储着所有关键分区（Boot, System, Vendor）的公钥。如果你在 BROM 下刷入了 Root 过的 Boot，哈希校验链就会断裂，导致设备陷入 Red State 循环。
"Red State: Your device has failed verification and will reboot in 5 seconds."
必须通过 BROM 刷入一个带有 --disable-verity 标志的空 VBMETA 镜像，从物理源头切断哈希审计链。
TEE 隔离区与 RPMB 的物理屏障
在 MTK 的深度审计中，你会发现某些分区（如 seccfg 或 tee）即使在 BROM 模式下刷写成功，重启后仍会复原。
这是因为 TEE (Trusted Execution Environment) 是运行在芯片内部受保护区域的。它与存储芯片中的 RPMB (Replay Protected Memory Block) 物理分区进行了双向绑定。RPMB 使用了带有密钥的 HMAC 校验，除非拥有 SoC 内部的私钥签名，否则任何通过 BROM 下发的非授权写入指令都会被 EMMC/UFS 控制器在硬件级静默丢弃。
8. 报错审计：读懂 BROM 的“十六进制遗言”
当 SP Flash Tool 或 mtk-client 弹出红色对话框时，这是 SoC 通过 UART 或 USB 接口返回的硬错误码。每一个代码都对应着引导链中特定的逻辑断裂点。
底层机理： 目标设备的安全链路认证（SLA）未通过。这是 2023 年后机型的标配。如果不先运行 Auth Bypass 脚本利用 Kamakiri 漏洞重置 SoC 的安全状态寄存器，BROM 将拦截一切非法写入。
底层机理： DA 协议指令集不匹配。常见于在天玑 9000 等 UFS 4.0 机型上尝试加载旧版 eMMC 时代的 Download Agent。芯片无法解析 DA 传入的存储器初始化指令。
底层机理： 物理寻址未对齐。MTK 的 DMA 传输要求地址必须位于扇区边界（Sector Boundary）。如果你手动修改了 Scatter 文件且地址不是 512 或 4096 的倍数，硬件将抛出内存对齐异常以防止数据污染。
硬件级电平抢占：强制 BROM 握手技巧
如果设备在插入瞬间反复重连（Boot Loop），通常是 Preloader 驱动抢占了 USB 总线。物理逻辑： 联发科 SoC 在上电瞬间会检测音量键对应的 GPIO 电平。同时按住“音量上+音量下”并连接数据线，会向芯片发送一个硬件中断信号，强制其跳过闪存寻址逻辑，直接锁死在 BROM 状态。若依然失败，则需通过 Test Point 短接基准电压点。
9. 工具选型：MTK 救砖武器库审计
针对不同的引导链损坏程度，必须匹配相应的驱动堆栈和工具。选择错误将导致 Payload 注入失败。
| 核心工具 | 审计维度 | 技术优势 |
|---|---|---|
| SP Flash Tool (v6+) | 全固件镜像刷写、物理扇区对齐校验。 | 严格遵循 Scatter 协议映射，适合分区表完整的恢复。 |
| mtk-client (Python) | BROM 寄存器级控制、RPMB 区域读写、Auth 绕过。 | 审计级利器。支持在无分区表状态下强制注入 GPT 结构。 |
| LibUSB-Win32 Filter | USB 握手拦截、驱动过滤器注入。 | 解决 Windows 自带驱动对 MediaTek USB Port 抢占失败的关键补丁。 |
—— 联发科底层引导审计终语 ——
BROM 模式不是失败的象征，它是芯片固件中预设的最终逻辑契约。
当你掌握了从 Handshake 握手、Payload 溢出注入，再到 Scatter 物理空间映射的全链路逻辑，
所谓的“变砖”就仅仅是一次由于物理地址对齐或哈希校验失败导致的暂时性挂起。