El firmware de banda base no es código de Android. Es un sistema embebido independiente 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
reducir el tamaño del 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 esta publicación son direcciones virtuales, tal como se cargan en Ghidra en la 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 |
| Canario de pila | Ausente | `SAVE`/`RESTORE` almacena registros guardados por el callee sin valor centinela |
| 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 del 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 mediante 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ó probar la copia sin límites
de `si_count` en el contexto del canal a través del par de instrucciones nativas. 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. Cuando 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 se reconstruyó —
el efecto secundario se modeló directamente y se etiquetó como tal en todas las salidas.

**Validación del lado de radio.** srsRAN 4G con un loopback ZMQ — solo software, sin emisión de RF —
confirmó que la carga útil 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 (Internet de las Cosas de Banda Estrecha) es 3GPP Release 13, diseñado para conectar
dispositivos IoT limitados utilizando el espectro LTE con licencia existente. Está implementado en una amplia gama de
SoC celulares modernos, incluidos los de los teléfonos inteligentes de consumo.

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

1. Sincronizarse con las señales de temporización de la celda (NPSS/NSSS)
2. Decodificar el Bloque de Información Maestro a través de NPBCH (ventana de transmisión de 640 ms)
3. Decodificar SIB1-NB desde NPDSCH (programación de 2560 ms)
4. Usar 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 rogue que satisfaga 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 fue descomprimida y analizada con `mtk_dbg_extract.py symbols`, y luego importada en Ghidra mediante `ImportSymbolsScript.py`. El resultado fueron nombres completos de funciones internas en todo el stack del módem — capa ERRC, gestión de canales L1, subsistema IPC y la cadena de manejadores BCCH de NB-IoT — lo que permitió una reconstrucción de la cadena guiada por semántica.

Todos los nombres de funciones en esta publicación provienen de los símbolos de depuración embebidos propios de MediaTek, extraídos de la imagen de 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

De 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
}

Flujo B (escrituras del 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 ERRC — Capa A

El buffer `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 comprobación única en cualquiera de las capas habría roto la cadena.

### 5.7 Causa raíz

Una invariante vulnerada:

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

3GPP proporciona el límite de protocolo previsto (8 entradas). El firmware debía imponer el límite de seguridad de memoria en cada capa donde el recuento se convierte en un índice o límite de bucle. En la compilación vulnerable, el recuento viajaba desde el campo de difusión SIB1-NB a través del decodificador ERRC, hasta el mensaje CPHY_CFG_REQ, cruzando un límite de IPC hacia la tarea L1, hacia el contexto de canal BSS, y hasta 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 las 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 `[+0x99]` | Relevancia |
|---|---|---|---|
| Ruta A (ERRC → IPC L1) | 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 del IPC interno | Valor fijo `1` | No vulnerable |

La ruta B confirmó el formato del mensaje: el byte `+0x99` es el recuento de SI consumido por `el1_ch_nbcch_start`. Como su recuento está siempre codificado de forma fija a 1, no puede desbordarse. La ruta influenciada externamente es la ruta A.

### 6.2 La búsqueda del escritor

La búsqueda de patrones en el firmware de cualquier instrucción que escriba en el desplazamiento `+0x99` produjo ruido: T1 (`sb` directa, ~100 coincidencias), T2 (base dividida, 5 coincidencias), T3 (desplazamiento calculado, 0), T4 (`sh`/`sw` superpuestas, ~465). Las funciones de gestión de canal de ERRC estaban ausentes de la lista de referencias cruzadas de `msg_send6` porque ERRC usa `errc_com_send_msg`. Una sonda de emulación confirmó que la escritura estaba en el lado de ERRC: ejecutar el harness de Unicorn desde el despachador de L1 y observar las escrituras al desplazamiento `+0x99` del búfer no capturó nada del lado de 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 ejercitar
la ruta de código vulnerable de NB-IoT en la operación normal de compilación de fábrica, por lo que se utilizaron emulación híbrida
y análisis estático en lugar de reproducción directa en hardware.

**Comprobado 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 nativamente en emulación.** El bucle dentro de `el1_ch_nbcch_resume_req` se ejecutó sobre bytes reales
de firmware de MediaTek en Unicorn Engine (MIPS32). La propia instrucción `sh` del 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 vivos del heap de Nucleus que el emulador plano no proporcionaba. El manejador de reanudación
(`el1_ch_nbcch_resume_req`) en la Fase 2 solo lee del contexto de canal residente en BSS
y no pasa por esa misma ruta de despacho, por lo que la Fase 2 se ejecutó nativamente 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 over-the-air en hardware.

### 7.1 Antimanipulación

El harness impuso una regla: ningún hook podía escribir el marcador de prueba en la ranura
de dirección de retorno guardada. Se rastreó cada escritura de 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 la carga útil de prueba sobrevive a la codificación PHY de NB-IoT y a la entrega de bloques de transporte, se utilizó srsRAN 4G con un loopback ZMQ (sin emisión de RF). La carga útil era un vector deliberadamente no conforme: la restricción ASN.1 SIZE en `schedulingInfoList` se relajó para permitir 40 entradas, y la decodificación de ida y vuelta con pycrate confirmó el campo de recuento en el byte 14.```
SIB1 received
SIB2 activated
exit 0

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

### 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 programación de NBCCH fue rediseñada de modo que el patrón de `si_count` como límite de bucle ya no
existe en ninguna parte de la ruta.

### 10.4 Atribución de CVE

La vulnerabilidad descrita aquí coincide con CVE-2024-20154 según lo publicado por MediaTek el 6 de
enero de 2025. Base de confirmación:

- La familia de firmware afectada (LR12A) coincide con el boletín de MediaTek.
- La clase de vulnerabilidad — desbordamiento de pila, falta de comprobación de límites, 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.
- El ID de parche MOLY00720348 se confirmó a partir del boletín de MediaTek y del Android Security Bulletin
  (A-376809176).
- El análisis asistido por IA relacionó de forma independiente 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

Sin exploit armamentizado. Sin contenido binario de firmware. Sin bytes de payload malformados. Sin
procedimiento paso a paso para desencadenar la vulnerabilidad contra un dispositivo real. La
información necesaria para reproducir un ataque funcional — construcción completa del payload para el
decodificador de módem específico, andamiaje de objetos de heap de RTOS para la emulación completa de la Fase 1, 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 aire. Ningún dispositivo real fue objetivo.
Ninguna red de operador estuvo involucrada. La prueba se ejecuta enteramente en un entorno de software contenido
en hardware propiedad del analista. Este es el enfoque correcto para validar una vulnerabilidad de radio previa
a la asociación — transmitir una emisión malformada 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 e independiente 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 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 struct 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.

---