El firmware de banda base no es código Android. Es un sistema embebido separado en el
subsistema de radio del SoC con su propia CPU, su propio RTOS y su propio espacio de memoria,
fuera del sandbox de procesos de Android.

### 2.2 Arquitectura del módem

El análisis del binario extraído muestra que el procesador del módem ejecuta MIPS32 con
instrucciones comprimidas MIPS16e2 en modo little-endian. MIPS16e2 es una extensión de
codificación de 16 bits para la reducción del tamaño de código embebido — consistente con el
enfoque de MediaTek para las bandas base de la generación Helio, confirmado por investigación
independiente publicada sobre bandas base de esta familia de SoC.

El sistema operativo es Nucleus RTOS, que proporciona planificación de tareas, colas de
mensajes IPC y un asignador de memoria basado en pools. No hay separación de privilegios
kernel/usuario, no hay aplicación de unidad de protección de memoria entre tareas y no hay
mecanismo de protección de pila por hardware.

Todas las direcciones en este post son direcciones virtuales, tal como se cargan en Ghidra con
base `0x90000000`.

### 2.3 Mitigaciones (observadas en la compilación analizada)

| Mitigación | Estado | Efecto |
|---|---|---|
| ASLR | Ausente | Las direcciones del firmware son estáticas y predecibles a partir de la imagen |
| Stack canary | Ausente | `SAVE`/`RESTORE` almacena registros callee-saved sin valor de guarda |
| NX / W^X | Ausente | La memoria de pila es ejecutable |
| CFI | Ausente | Las direcciones de retorno no se validan contra ninguna política |

### 2.4 Enfoque de análisis

Tres vías paralelas:

**Análisis estático.** Paquete de firmware de Samsung → extracción de la partición CP → `md1img.img` →
Ghidra (MIPS LE 32-bit, base `0x90000000`) con símbolos de ingeniería de MediaTek recuperados de
la sección de depuración del firmware usando el conjunto de herramientas `mtk_bp` de NCC Group.

**Validación dinámica.** Se utilizó Unicorn Engine (emulación MIPS32) para ejecutar rutinas
específicas del firmware de forma aislada en dos fases. La Fase 1 intentó demostrar la copia sin
restricciones de `si_count` en el contexto del canal a través del par de instrucciones nativo. La
Fase 2 ejecutó el bucle vulnerable sobre bytes reales del firmware y confirmó que las propias
instrucciones del firmware corrompen la dirección de retorno guardada. Donde la Fase 1 no pudo
ejecutarse completamente de forma nativa — porque el entorno de objetos de servicio del RTOS
requerido por la ruta de despacho CPHY no fue reconstruido — el efecto secundario se modeló
directamente y se etiquetó como tal en toda la salida.

**Validación del lado de radio.** srsRAN 4G con un loopback ZMQ — solo software, sin emisión de RF —
confirmó que el payload de prueba sobrevive a la codificación PHY de NB-IoT y a la entrega del
bloque de transporte.

---

## 3. Superficie de ataque: NB-IoT y SIB1-NB

### 3.1 Superficie de ataque previa a la asociación

NB-IoT (Narrowband Internet of Things) es 3GPP Release 13, diseñado para conectar dispositivos
IoT de recursos limitados usando espectro LTE licenciado existente. Está implementado en una
amplia gama de SoCs celulares modernos, incluidos los de smartphones de consumo.

Mientras está en RRC_IDLE, antes de que se establezca cualquier conexión RRC, un dispositivo que
busca servicio:

1. Se sincroniza con las señales de temporización de la celda (NPSS/NSSS)
2. Decodifica el Master Information Block sobre NPBCH (ventana de transmisión de 640 ms)
3. Decodifica SIB1-NB desde NPDSCH (programación de 2560 ms)
4. Usa la información de programación en SIB1-NB para localizar bloques de información de sistema adicionales

En el paso 3, el módem procesa un mensaje de una entidad que no ha autenticado, antes de
cualquier conexión o interacción del usuario. Un transmisor malicioso que cumpla las condiciones
normales de selección de celda será procesado.```
+------------------+                   +---------------------+
|  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]      |

La sección de depuración CATI se descomprimió y se analizó con `mtk_dbg_extract.py symbols`, y luego
se importó en Ghidra mediante `ImportSymbolsScript.py`. El resultado fueron nombres de funciones
internas completos en toda la pila del módem — la capa ERRC, la gestión de canales L1, el subsistema IPC y la
cadena de gestores BCCH de NB-IoT — lo que permitió la reconstrucción de la cadena guiada por semántica.

Todos los nombres de funciones en esta publicación provienen de los propios símbolos de depuración
integrados de MediaTek extraídos de la imagen del firmware.

---

## 5. Vulnerabilidad

### 5.1 El bucle vulnerable

`el1_ch_nbcch_resume_req` (`0x90213940`) gestiona el evento de reanudación del canal de difusión NB-IoT.
Su prólogo de función MIPS16e2:```asm
90213940:  save  0xE8, ra, s0-s1

Desde la descompilación de Ghidra del binario de firmware real:```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
}

Stream B (escrituras de byte `sb`) comienza en `new_sp+0x78` y requeriría la iteración 108 para alcanzar
la ranura RA:```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 El constructor de ERRC — Capa A

El búfer CPHY_CFG_REQ se construye en la capa ERRC a partir del SIB1-NB decodificado. La función
`errc_chm_l1_set_bcch_si_reception` escribe `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 Ausencia de limitación en tres capas

| Capa | Función | Dirección | ¿Limitación presente? |
|---|---|---|---|
| A — constructor ERRC | `errc_chm_l1_set_bcch_si_reception` | Rango ERRC | **Ninguna** |
| B — copia L1 | `el1_ch_nbcch_start` | `0x90213444` | **Ninguna** |
| C — bucle L1 | `el1_ch_nbcch_resume_req` | `0x90213940` | **Ninguna** |

Cualquier verificación única en cualquiera de las capas habría roto la cadena.

### 5.7 Causa raíz

Un invariante violado:

> El número de entradas de planificación de SI nunca debe exceder la capacidad del array de destino.

3GPP proporciona el límite de protocolo previsto (8 entradas). El firmware necesitaba aplicar el
límite de seguridad de memoria en cada capa donde el conteo se convierte en un índice o límite de bucle. En la
compilación vulnerable, el conteo viajó desde el campo de difusión SIB1-NB a través del decodificador
ERRC, hacia el mensaje CPHY_CFG_REQ, cruzando una frontera IPC hacia la tarea L1, hacia
el contexto de canal BSS, y hacia un bucle de escritura en pila — sin que ninguna capa lo limitara.

---

## 6. La cadena de llamadas — Cómo se encontró

### 6.1 La confusión de dos rutas

Dos rutas estructuralmente similares pero distintas pueden entregar un búfer de configuración de 0x760 bytes a
`el1_ch_nbcch_main`:

| Ruta | Origen | Valor de `[+0x99]` | Relevancia |
|---|---|---|---|
| Ruta A (ERRC → L1 IPC) | ERRC construye CPHY_CFG_REQ a partir de SIB1-NB decodificado | `schedulingInfoList.count` desde OTA | **La ruta vulnerable** |
| Ruta B (L1 interna) | `el1_ch_scs_ind_send` construye el cuerpo IPC interno | `1` codificado | No vulnerable |

La Ruta B confirmó el formato del mensaje — el byte `+0x99` es el conteo de SI consumido por
`el1_ch_nbcch_start`. Debido a que su conteo siempre está codificado a 1, no puede desbordarse. La
ruta influenciada externamente es la Ruta A.

### 6.2 La búsqueda del escritor

La búsqueda por patrones en el firmware de cualquier instrucción que escriba en el desplazamiento `+0x99` produjo ruido:
T1 (`sb` directo, ~100 coincidencias), T2 (base dividida, 5 coincidencias), T3 (desplazamiento calculado, 0), T4
(`sh`/`sw` superpuestos, ~465). Las funciones de gestión de canales ERRC estaban ausentes de la
lista de referencias cruzadas de `msg_send6` porque ERRC utiliza `errc_com_send_msg`. Una sonda de emulación
confirmó que la escritura era del lado ERRC: ejecutar el arnés Unicorn desde el despachador L1 y
observar escrituras en el desplazamiento `+0x99` del búfer no capturó nada desde el lado 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. Validación

Este modelo específico SM-A145R no parece ejecutar
la ruta de código NB-IoT vulnerable en la operación normal de compilación de envío, por lo que se utilizaron
emulación híbrida y análisis estático en lugar de reproducción directa en hardware.

**Probado estáticamente.** El binario del firmware contiene el par de instrucciones vulnerable. La cadena
de llamadas se reconstruye a partir de símbolos, referencias cruzadas y cuerpos de funciones descompilados.

**Ejecutado de forma nativa en emulación.** El bucle dentro de `el1_ch_nbcch_resume_req` se ejecutó sobre bytes
reales del firmware MediaTek en Unicorn Engine (MIPS32). La instrucción `sh` del propio firmware en
`0x90213B02` escribió en la ranura de dirección de retorno guardada. La instrucción `RESTORE` cargó el
valor corrupto en `$ra`, y `jrc ra` transfirió el control.

**Modelado explícitamente.** La copia `lbu`/`sb` en `el1_ch_nbcch_start` no pudo ejecutarse completamente
de forma nativa porque la ruta de despacho de la tabla de callbacks del RTOS dentro de `el1_ch_nbcch_cphy_cfg_req_
process` esperaba objetos de heap de Nucleus activos que el emulador plano no proporcionaba. El manejador
de reanudación (`el1_ch_nbcch_resume_req`) en la Fase 2 lee únicamente del contexto de canal residente en BSS
y no alcanza esa misma ruta de despacho, por lo que la Fase 2 se ejecutó de forma nativa sin
requerir el mismo andamiaje. El efecto secundario de la Fase 1 — un byte de `IPC_msg[+0x99]`
escrito en `ch_ctx[+0x40A]` — se modeló directamente y se etiquetó como `[PHASE1-MODEL]`.

**No afirmado.** Una reproducción completa de extremo a extremo por aire en hardware.

### 7.1 Anti-manipulación

El arnés impuso una regla: no se permitió que ningún hook escribiera el marcador de prueba en la ranura
de dirección de retorno guardada. Se rastreó cada escritura en memoria que no fuera del firmware.```
[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 Entrega ZMQ

Para confirmar que el payload de prueba sobrevive a la codificación PHY de NB-IoT y a la entrega del bloque de transporte, se utilizó srsRAN 4G con un loopback ZMQ (sin emisión de RF). El payload era un vector deliberadamente no conforme — la restricción de SIZE de ASN.1 sobre `schedulingInfoList` se relajó para permitir 40 entradas, con una decodificación round-trip de pycrate que confirma el campo de conteo en el byte 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` reside en BSS y conserva el valor del atacante hasta que el módem se reinicie o una configuración de canal posterior lo sobrescriba.

### 8.2 Marco de pila```
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]

Una comprobación de límites de una sola línea aparecería como unas pocas instrucciones añadidas dentro de una función existente en la misma dirección. Lo que muestra el binario parcheado es una revisión arquitectónica: la ruta de planificación de NBCCH fue rediseñada para que el patrón de `si_count`-como-límite-de-bucle ya no exista en ningún punto de la ruta.

### 10.4 Atribución de CVE

La vulnerabilidad descrita aquí coincide con CVE-2024-20154 tal como fue publicada por MediaTek el 6 de enero de 2025. Base de la confirmación:

- La familia de firmware afectada (LR12A) coincide con el boletín de MediaTek.
- La clase de vulnerabilidad — desbordamiento de pila, comprobación de límites ausente, RCE desde una estación base maliciosa, sin interacción del usuario — coincide con la descripción del CVE y el registro de NVD.
- El firmware parcheado elimina exactamente las estructuras de código identificadas como vulnerables.
- ID de parche MOLY00720348 confirmado a partir del boletín de MediaTek y el Boletín de Seguridad de Android (A-376809176).
- El análisis asistido por IA coincidió de forma independiente con el patrón reconstruido con CVE-2024-20154 antes de la confirmación manual.

---

## 11. Ética y divulgación responsable

### 11.1 Lo que esta publicación no contiene

Ningún exploit weaponizado. Ningún contenido de binario de firmware. Ningún byte de payload malformado. Ningún procedimiento paso a paso para desencadenar la vulnerabilidad contra un dispositivo en vivo. La información necesaria para reproducir un ataque funcional — la construcción completa del payload para el decodificador de módem específico, el andamiaje de objetos del heap del RTOS para la emulación completa de la Fase 1, la configuración de radio por aire — está deliberadamente ausente.

### 11.2 Por qué el loopback ZMQ y la emulación son el enfoque ético

El loopback ZMQ significa que nunca se transmitió ninguna señal por el aire. No se atacó ningún dispositivo real. No se involucró ninguna red de operador. La prueba se ejecuta enteramente en un entorno de software contenido sobre hardware propiedad del analista. Este es el enfoque correcto para validar una vulnerabilidad de radio previa a la asociación — transmitir un broadcast malformado afectaría a cualquier dispositivo dentro del alcance.

La emulación con Unicorn demuestra que el comportamiento vulnerable está en el propio binario del firmware, de forma reproducible, independientemente de cualquier estado específico del dispositivo o entorno de radio. Esta es una afirmación técnicamente más sólida que un único fallo de hardware, y evita desplegar cualquier cosa por el aire.

### 11.3 Propiedad intelectual de MediaTek

Todo el análisis se realizó sobre firmware obtenido legítimamente de un dispositivo de consumo y de los paquetes de firmware publicados públicamente por Samsung. No se utilizó documentación propietaria. Las definiciones internas de estructuras de MediaTek y los formatos de mensajes IPC se describen solo en la medida necesaria para explicar el fallo de seguridad de memoria. No se publican como especificaciones.

---