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

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

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

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

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

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

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

### 2.4 Подход к анализу

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

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

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

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

---

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

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

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

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

1. Синхронизироваться с сигналами тайминга соты (NPSS/NSSS)
2. Декодировать Master Information Block по 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]      |

Секция отладки CATI была распакована и разобрана с помощью `mtk_dbg_extract.py symbols`, затем
импортирована в Ghidra через `ImportSymbolsScript.py`. Результатом стали полные внутренние имена
функций по всему стеку модема — слой 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` и для достижения слота RA потребовал бы итерации 108:```
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

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

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

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

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

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

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

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

---