Прошивка baseband — это не код Android. Это отдельная встроенная система в радиоподсистеме SoC с собственным CPU, собственной RTOS и собственным адресным пространством, вне песочницы процессов Android.

### 2.2 Архитектура модема

Анализ извлечённого бинарного файла показывает, что процессор модема работает на MIPS32 со сжатыми инструкциями MIPS16e2 в режиме little-endian. MIPS16e2 — это 16-битное расширение кодирования для уменьшения размера кода во встраиваемых системах — что согласуется с подходом MediaTek для модемов поколения Helio и подтверждается независимыми опубликованными исследованиями baseband этого семейства SoC.

Операционная система — Nucleus RTOS, обеспечивающая планирование задач, очереди сообщений IPC и распределитель памяти на основе пулов. Здесь нет разделения привилегий ядро/пользователь, нет принудительного применения модуля защиты памяти (MPU) между задачами и нет аппаратного механизма защиты стека.

Все адреса в этом посте являются виртуальными адресами, как они загружены в Ghidra по базе `0x90000000`.

### 2.3 Механизмы защиты (наблюдаемые в проанализированной сборке)

| Механизм защиты | Статус | Эффект |
|---|---|---|
| ASLR | Отсутствует | Адреса прошивки статичны и предсказуемы из образа |
| Stack canary | Отсутствует | `SAVE`/`RESTORE` сохраняют регистры вызываемой функции без контрольного значения |
| NX / W^X | Отсутствует | Память стека исполняемая |
| CFI | Отсутствует | Адреса возврата не проверяются на соответствие какой-либо политике |

### 2.4 Методика анализа

Три параллельных направления:

**Статический анализ.** Пакет прошивки Samsung → извлечение раздела CP → `md1img.img` → Ghidra (MIPS LE 32-bit, база `0x90000000`) с инженерными символами MediaTek, восстановленными из отладочной секции прошивки с помощью набора инструментов NCC Group `mtk_bp`.

**Динамическая проверка.** Unicorn Engine (эмуляция MIPS32) использовался для изолированного выполнения конкретных подпрограмм прошивки в два этапа. Этап 1 пытался доказать неограниченное копирование `si_count` в контекст канала через нативную пару инструкций. Этап 2 выполнял уязвимый цикл на реальных байтах прошивки и подтвердил, что собственные инструкции прошивки повреждают сохранённый адрес возврата. Там, где Этап 1 не мог быть выполнен полностью нативно — поскольку среда сервисных объектов RTOS, требуемая путём диспетчеризации CPHY, не была восстановлена — побочный эффект моделировался напрямую и помечался как таковой во всех выводах.

**Проверка на радиостороне.** srsRAN 4G с loopback через ZMQ — только программное обеспечение, без радиоизлучения — подтвердил, что тестовая полезная нагрузка корректно проходит кодирование PHY NB-IoT и доставку транспортного блока.

---

## 3. Поверхность атаки: NB-IoT и SIB1-NB

### 3.1 Поверхность атаки до установления соединения

NB-IoT (Narrowband Internet of Things, узкополосный интернет вещей) — это 3GPP Release 13, разработанный для подключения устройств с ограниченными ресурсами с использованием существующего лицензированного LTE-спектра. Он реализован в широком диапазоне современных сотовых SoC, включая те, что находятся в потребительских смартфонах.

Находясь в состоянии RRC_IDLE, до установления любого RRC-соединения, устройство, выполняющее поиск сети, будет:

1. Синхронизироваться с сигналами синхронизации соты (NPSS/NSSS)
2. Декодировать Master Information Block (MIB) через NPBCH (окно передачи 640 мс)
3. Декодировать SIB1-NB из NPDSCH (расписание 2560 мс)
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]      |

The CATI debug section was decompressed and parsed with `mtk_dbg_extract.py symbols`, then
imported into Ghidra via `ImportSymbolsScript.py`. The result was full internal function
names throughout the modem stack — ERRC layer, L1 channel management, IPC subsystem, and the
NB-IoT BCCH handler chain — allowing semantics-guided chain reconstruction.

All function names in this post come from MediaTek's own embedded debug symbols extracted
from the firmware image.

---

## 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 формирует CPHY_CFG_REQ из декодированного SIB1-NB | `schedulingInfoList.count` из OTA | **Уязвимый путь** |
| Путь B (внутренний L1) | `el1_ch_scs_ind_send` формирует внутреннее тело IPC | Жёстко заданный `1` | Не уязвим |

Путь B подтвердил формат сообщения — байт `+0x99` является количеством SI, потребляемым `el1_ch_nbcch_start`. Поскольку его значение всегда жёстко задано как 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: запуск обвязки Unicorn из диспетчера L1 и наблюдение за записью в смещение `+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 не задействует
уязвимый путь кода NB-IoT в обычном заводском режиме работы, поэтому вместо
прямого воспроизведения на оборудовании использовались гибридная эмуляция и статический анализ.

**Доказано статически.** В бинарном файле прошивки присутствует уязвимая пара инструкций. Цепочка
вызовов восстановлена по символам, перекрёстным ссылкам и декомпилированным телам функций.

**Исполнено нативно в эмуляции.** Цикл внутри `el1_ch_nbcch_resume_req` выполнялся на реальных
байтах прошивки MediaTek в Unicorn Engine (MIPS32). Собственная инструкция `sh` прошивки по адресу
`0x90213B02` записывала данные в слот сохранённого обратного адреса. Инструкция `RESTORE` загружала
повреждённое значение в `$ra`, а `jrc ra` передавала управление.

**Явно смоделировано.** Копирование через `lbu`/`sb` в `el1_ch_nbcch_start` не удалось полностью выполнить
нативно, поскольку путь диспетчеризации таблицы обратных вызовов RTOS внутри `el1_ch_nbcch_cphy_cfg_req_
process` ожидал живые объекты кучи Nucleus, которые плоский эмулятор не предоставлял. Обработчик
возобновления (`el1_ch_nbcch_resume_req`) в фазе 2 читает только из размещённого в BSS контекста канала
и не проходит через тот же путь диспетчеризации, поэтому фаза 2 выполнялась нативно без
необходимости в тех же вспомогательных конструкциях. Побочный эффект фазы 1 — один байт из `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

Чтобы подтвердить, что тестовый payload выдерживает кодирование NB-IoT PHY и доставку транспортных блоков, использовался srsRAN
4G с ZMQ loopback (без радиоизлучения). Payload был намеренно несоответствующим вектором — ограничение ASN.1 SIZE на `schedulingInfoList` было ослаблено, чтобы разрешить 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

Описанная здесь уязвимость соответствует CVE-2024-20154, опубликованной MediaTek 6 января 2025 года. Основания для подтверждения:

- Затронутое семейство прошивок (LR12A) соответствует бюллетеню MediaTek.
- Класс уязвимости — переполнение стека, отсутствие проверки границ, RCE с мошеннической базовой станции, без взаимодействия с пользователем — соответствует описанию CVE и записи NVD.
- Пропатченная прошивка удаляет именно те структуры кода, которые были определены как уязвимые.
- Идентификатор патча MOLY00720348 подтверждён бюллетенем MediaTek и Android Security Bulletin (A-376809176).
- Анализ с применением ИИ независимо сопоставил восстановленный паттерн с CVE-2024-20154 до ручного подтверждения.

---

## 11. Этика и ответственное раскрытие информации

### 11.1 Чего нет в этом посте

Никакого боевого эксплойта. Никакого содержимого бинарных файлов прошивки. Никаких байт повреждённой полезной нагрузки. Никакой пошаговой процедуры срабатывания уязвимости на реальном устройстве. Информация, необходимая для воспроизведения рабочей атаки — полная конструкция полезной нагрузки для конкретного декодера модема, каркас heap-объектов RTOS для полной эмуляции Phase 1, конфигурация радиоэфира — намеренно отсутствует.

### 11.2 Почему ZMQ loopback и эмуляция — этичный подход

ZMQ loopback означает, что ни один сигнал никогда не передавался в эфир. Ни одно реальное устройство не было целью. Ни одна сеть оператора не была задействована. Доказательство полностью выполняется в изолированной программной среде на оборудовании, принадлежащем аналитику. Это правильный подход для проверки радиоуязвимости до ассоциации — передача повреждённого широковещательного сообщения затронула бы любое устройство в зоне действия.

Эмуляция Unicorn показывает, что уязвимое поведение находится в самом бинарном файле прошивки, воспроизводимо, независимо от конкретного состояния устройства или радиоокружения. Это технически более сильное утверждение, чем одиночный сбой оборудования, и позволяет избежать развёртывания чего-либо в эфире.

### 11.3 Интеллектуальная собственность MediaTek

Весь анализ выполнялся на прошивке, легально полученной с потребительского устройства и из публично выпущенных пакетов прошивок Samsung. Никакая проприетарная документация не использовалась. Внутренние определения структур MediaTek и форматы IPC-сообщений описаны лишь в той степени, в какой это необходимо для объяснения отказа безопасности памяти. Они не публикуются в качестве спецификаций.

---