基带固件不是 Android 代码。它是 SoC 无线电子系统上的一个独立嵌入式系统，拥有自己的 CPU、自己的 RTOS 和自己的内存空间，位于 Android 进程沙箱之外。

### 2.2 调制解调器架构

对提取出的二进制文件的分析表明，调制解调器处理器运行 MIPS32，采用小端模式下的 MIPS16e2 压缩指令。MIPS16e2 是一种用于嵌入式代码体积缩减的 16 位编码扩展——这与联发科针对 Helio 代基带的方法一致，并得到了针对该 SoC 系列的独立公开基带研究的证实。

操作系统是 Nucleus RTOS，提供任务调度、IPC 消息队列和基于池的内存分配器。没有内核/用户特权分离，任务之间没有内存保护单元强制隔离，也没有硬件栈保护机制。

本文中的所有地址均为虚拟地址，在 Ghidra 中以基址 `0x90000000` 加载。

### 2.3 缓解措施（在分析的构建版本中观察到）

| 缓解措施 | 状态 | 效果 |
|---|---|---|
| ASLR | 缺失 | 固件地址是静态的，可从镜像中预测 |
| 栈金丝雀 | 缺失 | `SAVE`/`RESTORE` 存储被调用者保存寄存器时没有保护值 |
| NX / W^X | 缺失 | 栈内存可执行 |
| CFI | 缺失 | 返回地址未根据任何策略进行验证 |

### 2.4 分析方法

三条并行路径：

**静态分析。** 三星固件包 → CP 分区提取 → `md1img.img` → Ghidra（MIPS LE 32 位，基址 `0x90000000`），并使用 NCC Group 的 `mtk_bp` 工具集从固件调试段中恢复联发科工程符号。

**动态验证。** 使用 Unicorn Engine（MIPS32 仿真）分两个阶段隔离执行特定的固件例程。阶段 1 试图通过原生指令对证明 `si_count` 未经限制地复制到通道上下文中。阶段 2 在真实固件字节上执行了存在漏洞的循环，并确认固件自身的指令破坏了保存的返回地址。在阶段 1 无法完全原生运行的情况下——因为 CPHY 分发路径所需的 RTOS 服务对象环境未被重建——副作用被直接建模，并在所有输出中如此标注。

**无线电侧验证。** 使用带 ZMQ 回环的 srsRAN 4G——纯软件，无射频发射——确认测试载荷能够在 NB-IoT PHY 编码和传输块传递后存活。

---

## 3. 攻击面：NB-IoT 与 SIB1-NB

### 3.1 关联前攻击面

NB-IoT（窄带物联网）是 3GPP Release 13，旨在利用现有授权 LTE 频谱连接资源受限的 IoT 设备。它被实现在包括消费级智能手机在内的多种现代蜂窝 SoC 中。

在 RRC_IDLE 状态下，在任何 RRC 连接建立之前，搜索服务的设备将：

1. 与小区的时间信号同步（NPSS/NSSS）
2. 通过 NPBCH 解码主信息块（640 ms 传输窗口）
3. 从 NPDSCH 解码 SIB1-NB（2560 ms 调度）
4. 使用 SIB1-NB 中的调度信息定位其他系统信息块

在第 3 步，调制解调器在任何连接或用户交互之前，处理来自一个它尚未认证的实体的消息。满足正常小区选择条件的恶意发射机将被处理。```
+------------------+                   +---------------------+
|  Rogue Base Stn  |                   |  Target UE (Modem)  |
+--------+---------+                   +----------+----------+
         |                                        |
         |   NPSS/NSSS sync                      |
         |--------------------------------------->|
         |   MIB-NB (640 ms cycle)                |
         |--------------------------------------->|
         |   SIB1-NB (malformed, si_count > 8)    |
         |--------------------------------------->|   ← vulnerability triggered
         |   [no RRC connection established]      |

CATI 调试段通过 `mtk_dbg_extract.py symbols` 解压并解析，随后通过 `ImportSymbolsScript.py` 导入 Ghidra。结果是在整个调制解调器栈中获得了完整的内部函数名——ERRC 层、L1 信道管理、IPC 子系统以及 NB-IoT BCCH 处理链——从而支持语义引导的链重建。

本文中所有函数名均来自从固件镜像中提取的 MediaTek 自身嵌入的调试符号。

---

## 5. 漏洞

### 5.1 存在漏洞的循环

`el1_ch_nbcch_resume_req`（`0x90213940`）处理 NB-IoT 广播信道恢复事件。其 MIPS16e2 函数序言：```asm
90213940:  save  0xE8, ra, s0-s1

从实际固件二进制文件的 Ghidra 反编译结果来看：```c
for (uVar6 = 0; uVar6 < (byte)param_2[0x40a]; uVar6 = uVar6 + 1) {
    si_type_arr[uVar6]  = /* SI type byte */;          // 1 byte/iter, base new_sp+0x78
    si_sched_arr[uVar6] = /* SI schedule halfword */;  // 2 bytes/iter, base new_sp+0x98
}

流 B（字节 `sb` 写入）从 `new_sp+0x78` 开始，需要迭代 108 次才能到达 RA 槽位：```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 ERRC 构建器 — 层 A

CPHY_CFG_REQ 缓冲区在 ERRC 层中由解码后的 SIB1-NB 构建。函数
`errc_chm_l1_set_bcch_si_reception` 写入 `IPC_msg[+0x99]`：```c
// errc_chm_l1_set_bcch_si_reception — Layer A
// Loop bound: decoded schedulingInfoList entry count from SIB1-NB

while (bVar3 < *(byte *)(param_3 + 0x44) && (param_2 != 0)) {
    bVar3++;
    if (uVar2 != param_2) {
        *param_5 = *param_5 + 1;   // CPHY_CFG_REQ[+0x99]++ — no upper bound check
    }
}

### 5.6 三层缺失的钳位

| 层级 | 函数 | 地址 | 是否存在钳位？ |
|---|---|---|---|
| A — ERRC 构建器 | `errc_chm_l1_set_bcch_si_reception` | ERRC 范围 | **无** |
| B — L1 拷贝 | `el1_ch_nbcch_start` | `0x90213444` | **无** |
| C — L1 循环 | `el1_ch_nbcch_resume_req` | `0x90213940` | **无** |

任何一层中的任何单一检查都会打破这条链。

### 5.7 根本原因

一个被违反的不变量：

> SI 调度条目的数量绝不能超过目标数组的容量。

3GPP 提供了预期的协议边界（8 个条目）。固件需要在每一层强制实施内存安全边界，即计数变为索引或循环限制的地方。在易受攻击的构建中，计数从 SIB1-NB 广播字段出发，经过 ERRC 解码器，进入 CPHY_CFG_REQ 消息，跨越 IPC 边界进入 L1 任务，进入通道上下文 BSS，并进入一个栈写入循环——没有任何一层对其进行钳位。

---

## 6. 调用链——如何被发现

### 6.1 两条路径的混淆

两条结构相似但不同的路径可以将一个 0x760 字节的配置缓冲区传递给 `el1_ch_nbcch_main`：

| 路径 | 来源 | `[+0x99]` 值 | 相关性 |
|---|---|---|---|
| 路径 A（ERRC → L1 IPC） | ERRC 从解码的 SIB1-NB 构建 CPHY_CFG_REQ | 来自 OTA 的 `schedulingInfoList.count` | **易受攻击的路径** |
| 路径 B（L1 内部） | `el1_ch_scs_ind_send` 构建内部 IPC 主体 | 硬编码 `1` | 不易受攻击 |

路径 B 确认了消息格式——字节 `+0x99` 是 `el1_ch_nbcch_start` 所消费的 SI 计数。由于其计数始终硬编码为 1，因此不会溢出。受外部影响的路径是路径 A。

### 6.2 写入者搜索

在固件中模式搜索任何写入偏移 `+0x99` 的指令产生了噪声：T1（直接 `sb`，约 100 次命中），T2（拆分基址，5 次命中），T3（计算偏移，0 次），T4（重叠的 `sh`/`sw`，约 465 次）。ERRC 通道管理函数在 `msg_send6` 交叉引用列表中缺失，因为 ERRC 使用 `errc_com_send_msg`。一次仿真探测确认写入发生在 ERRC 侧：从 L1 调度器运行 Unicorn 测试框架并监视对缓冲区 `+0x99` 偏移的写入，从 L1 侧没有捕获到任何内容。```
[RUN] dispatcher=0x90214418  watching IPC_msg+0x99

NO writes to IPC_msg+0x99 caught from dispatcher.
Write happened before el1_ch_nbcch_main — confirmed ERRC-side.

---

## 7. 验证

这个特定的 SM-A145R 型号在正常的 ship-build 操作中似乎不会触发存在漏洞的 NB-IoT 代码路径，这就是为什么使用了混合仿真和静态分析，而不是直接进行硬件复现。

**静态验证。** 固件二进制文件中包含存在漏洞的指令对。调用链是根据符号、交叉引用和反编译的函数体重建的。

**在仿真中本机执行。** `el1_ch_nbcch_resume_req` 内部的循环在 Unicorn Engine（MIPS32）中基于真实的 MediaTek 固件字节运行。固件自身的 `sh` 指令在 `0x90213B02` 处写入了保存的返回地址槽。`RESTORE` 指令将损坏的值加载到 `$ra` 中，`jrc ra` 转移了控制流。

**显式建模。** `el1_ch_nbcch_start` 中的 `lbu`/`sb` 复制无法完全本机运行，因为 `el1_ch_nbcch_cphy_cfg_req_process` 内部的 RTOS 回调表分发路径需要活跃的 Nucleus 堆对象，而扁平仿真器无法提供这些对象。第二阶段中的恢复处理程序（`el1_ch_nbcch_resume_req`）仅从驻留在 BSS 中的通道上下文读取，不会命中相同的分发路径，这就是为什么第二阶段无需相同的脚手架即可本机运行。第一阶段的副作用——从 `IPC_msg[+0x99]` 写入 `ch_ctx[+0x40A]` 的一个字节——被直接建模并标记为 `[PHASE1-MODEL]`。

**未声称。** 完整的端到端空中硬件复现。

### 7.1 防篡改

测试框架强制执行了一条规则：不允许任何钩子将证明标记写入保存的返回地址槽。每一次非固件内存写入都被跟踪。```
[PROOF-W] saved_RA write: pc=0x90213b02  addr=new_sp+0xE4  value=0xbeef
[PROOF-W] saved_RA write: pc=0x90213b02  addr=new_sp+0xE6  value=0xdead
[ANTI-TAMPER] no hook wrote RA=0xDEADBEEF — firmware only
anti_tamper_fail = False

### 7.3 ZMQ 传递

为确认测试载荷在 NB-IoT PHY 编码和传输块传递后仍能保持完整，使用了带 ZMQ 回环（无射频发射）的 srsRAN 4G。载荷是一个刻意构造的非合规向量——`schedulingInfoList` 上的 ASN.1 SIZE 约束被放宽以允许 40 个条目，并通过 pycrate 往返解码确认了第 14 字节处的计数字段。```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` 位于 BSS 中，并保留攻击者的值，直到调制解调器重置或后续通道配置将其覆盖。

### 8.2 栈帧```
old_sp  (= new_sp + 0xE8)
new_sp + 0xE4   saved ra
new_sp + 0xE0   saved s1
new_sp + 0xDC   saved s0
new_sp + 0x98   si_sched_arr  [34 halfwords = 68 bytes]
new_sp + 0x78   si_type_arr   [32 bytes]

单行边界检查会表现为在相同地址的现有函数内部添加的几条指令。而修补后的二进制文件所展示的是一次架构层面的修订：NBCCH 调度路径被重新设计，使得 `si_count` 作为循环边界的模式在该路径中不再存在。

### 10.4 CVE 归属

此处描述的漏洞与 MediaTek 于 2025 年 1 月 6 日发布的 CVE-2024-20154 相符。确认依据：

- 受影响的固件系列（LR12A）与 MediaTek 的公告相符。
- 漏洞类别——栈溢出、缺少边界检查、来自恶意基站的 RCE、无需用户交互——与 CVE 描述及 NVD 记录相符。
- 修补后的固件恰好移除了被识别为存在漏洞的代码结构。
- 补丁 ID MOLY00720348 已从 MediaTek 的公告和 Android 安全公告（A-376809176）中确认。
- AI 辅助分析在人工确认之前，独立地将重建的模式匹配到了 CVE-2024-20154。

---

## 11. 伦理与负责任披露

### 11.1 本文不包含的内容

没有武器化的漏洞利用。没有固件二进制内容。没有畸形的载荷字节。没有针对真实设备触发该漏洞的分步操作流程。复现一个可工作的攻击所需的信息——针对特定调制解调器解码器的完整载荷构造、用于完整 Phase 1 仿真的 RTOS 堆对象脚手架、空口无线电配置——均被有意省略。

### 11.2 为什么 ZMQ 回环与仿真是合乎伦理的方法

ZMQ 回环意味着从未通过空口发送任何信号。没有针对任何真实设备。没有涉及运营商网络。该验证完全在分析师自有硬件上的受控软件环境中运行。这是验证预关联无线电漏洞的正确方法——发送畸形广播会影响范围内的任何设备。

Unicorn 仿真证明，该易受攻击的行为存在于固件二进制文件本身之中，可复现，且独立于任何特定设备状态或无线电环境。这比单次硬件崩溃在技术上更具说服力，并且避免了通过空口部署任何内容。

### 11.3 MediaTek 知识产权

所有分析均基于从消费级设备合法获取的固件以及三星公开发布的固件包进行。未使用任何专有文档。MediaTek 内部结构体定义和 IPC 消息格式仅在解释内存安全故障所必需的范围内进行描述。它们并未作为规范发布。

---