Il firmware di baseband non è codice Android. È un sistema embedded separato nel sottosistema radio del SoC, con la propria CPU, il proprio RTOS e il proprio spazio di memoria, al di fuori della sandbox dei processi Android.

### 2.2 Architettura del modem

L'analisi del binario estratto mostra che il processore del modem esegue MIPS32 con istruzioni compresse MIPS16e2 in modalità little-endian. MIPS16e2 è un'estensione di codifica a 16 bit per la riduzione della dimensione del codice negli embedded — in linea con l'approccio di MediaTek per le baseband della generazione Helio, confermato da ricerche indipendenti pubblicate sulla baseband di questa famiglia di SoC.

Il sistema operativo è Nucleus RTOS, che fornisce scheduling dei task, code di messaggi IPC e un allocatore di memoria basato su pool. Non esiste separazione dei privilegi kernel/utente, nessuna applicazione della memory protection unit tra i task e nessun meccanismo hardware di stack guard.

Tutti gli indirizzi in questo post sono indirizzi virtuali, come caricati in Ghidra alla base `0x90000000`.

### 2.3 Mitigazioni (osservate nella build analizzata)

| Mitigazione | Stato | Effetto |
|---|---|---|
| ASLR | Assente | Gli indirizzi del firmware sono statici e prevedibili dall'immagine |
| Stack canary | Assente | `SAVE`/`RESTORE` salva i registri callee-saved senza valore di guardia |
| NX / W^X | Assente | La memoria dello stack è eseguibile |
| CFI | Assente | Gli indirizzi di ritorno non vengono validati rispetto ad alcuna policy |

### 2.4 Approccio di analisi

Tre percorsi paralleli:

**Analisi statica.** Pacchetto firmware Samsung → estrazione della partizione CP → `md1img.img` → Ghidra (MIPS LE 32-bit, base `0x90000000`) con i simboli engineering MediaTek recuperati dalla sezione di debug del firmware utilizzando il toolset NCC Group `mtk_bp`.

**Validazione dinamica.** Unicorn Engine (emulazione MIPS32) è stato utilizzato per eseguire routine specifiche del firmware in isolamento in due fasi. La fase 1 ha tentato di dimostrare la copia non limitata di `si_count` nel contesto del canale tramite la coppia di istruzioni native. La fase 2 ha eseguito il loop vulnerabile su byte reali del firmware e ha confermato che le istruzioni del firmware stesso corrompono l'indirizzo di ritorno salvato. Laddove la fase 1 non poteva essere eseguita completamente in modo nativo — poiché l'ambiente degli oggetti di servizio RTOS richiesto dal percorso di dispatch CPHY non era stato ricostruito — l'effetto collaterale è stato modellato direttamente ed etichettato come tale in tutti gli output.

**Validazione lato radio.** srsRAN 4G con un loopback ZMQ — solo software, nessuna emissione RF — ha confermato che il payload di test sopravvive alla codifica PHY NB-IoT e alla consegna del transport block.

---

## 3. Superficie d'attacco: NB-IoT e SIB1-NB

### 3.1 Superficie d'attacco pre-associazione

NB-IoT (Narrowband Internet of Things) è la Release 13 del 3GPP, progettata per connettere dispositivi IoT vincolati utilizzando lo spettro LTE concesso in licenza esistente. È implementato in un'ampia gamma di SoC cellulari moderni, inclusi quelli negli smartphone consumer.

Mentre è in RRC_IDLE, prima che venga stabilita qualsiasi connessione RRC, un dispositivo in cerca di servizio:

1. Si sincronizza con i segnali di temporizzazione della cella (NPSS/NSSS)
2. Decodifica il Master Information Block su NPBCH (finestra di trasmissione di 640 ms)
3. Decodifica SIB1-NB da NPDSCH (pianificazione di 2560 ms)
4. Usa le informazioni di pianificazione in SIB1-NB per individuare ulteriori blocchi di informazioni di sistema

Al passaggio 3, il modem elabora un messaggio da un'entità che non ha autenticato, prima di qualsiasi connessione o interazione con l'utente. Un trasmettitore rogue che soddisfa le normali condizioni di selezione della cella verrà elaborato.```
+------------------+                   +---------------------+
|  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 sezione di debug CATI è stata decompressa e analizzata con `mtk_dbg_extract.py symbols`, quindi
importata in Ghidra tramite `ImportSymbolsScript.py`. Il risultato è stato un insieme completo di nomi di funzione
interni in tutto lo stack del modem — livello ERRC, gestione canali L1, sottosistema IPC e la
catena di handler BCCH NB-IoT — consentendo una ricostruzione della catena guidata dalla semantica.

Tutti i nomi di funzione in questo post provengono dai simboli di debug embedded di MediaTek estratti
dall'immagine del firmware.

---

## 5. Vulnerabilità

### 5.1 Il loop vulnerabile

`el1_ch_nbcch_resume_req` (`0x90213940`) gestisce l'evento di ripresa del canale broadcast NB-IoT.
Il suo prologo di funzione MIPS16e2:```asm
90213940:  save  0xE8, ra, s0-s1

Dalla decompilazione Ghidra del binario firmware effettivo:```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 (scritture del byte `sb`) inizia a `new_sp+0x78` e richiederebbe l'iterazione 108 per raggiungere lo slot RA:```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 Il builder ERRC — Layer A

Il buffer CPHY_CFG_REQ viene costruito nel layer ERRC a partire dal SIB1-NB decodificato. La funzione
`errc_chm_l1_set_bcch_si_reception` scrive `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 Assenza di limitazione su tre livelli

| Livello | Funzione | Indirizzo | Limitazione presente? |
|---|---|---|---|
| A — Costruttore ERRC | `errc_chm_l1_set_bcch_si_reception` | Intervallo ERRC | **Nessuna** |
| B — Copia L1 | `el1_ch_nbcch_start` | `0x90213444` | **Nessuna** |
| C — Ciclo L1 | `el1_ch_nbcch_resume_req` | `0x90213940` | **Nessuna** |

Un singolo controllo su uno qualsiasi dei livelli avrebbe spezzato la catena.

### 5.7 Causa principale

Una singola invariante violata:

> Il numero di voci di pianificazione SI non deve mai superare la capacità dell'array di destinazione.

Il 3GPP fornisce il limite di protocollo previsto (8 voci). Il firmware doveva imporre il
limite di sicurezza della memoria a ogni livello in cui il conteggio diventa un indice o un limite di ciclo. Nella
build vulnerabile, il conteggio viaggiava dal campo broadcast SIB1-NB attraverso il
decoder ERRC, nel messaggio CPHY_CFG_REQ, oltre il confine IPC nel task L1, nel
contesto di canale BSS e in un ciclo di scrittura sullo stack — senza alcuna limitazione a nessun livello.

---

## 6. La Catena di Chiamate — Come è stata Trovata

### 6.1 La confusione tra due percorsi

Due percorsi strutturalmente simili ma distinti possono consegnare un buffer di configurazione da 0x760 byte a
`el1_ch_nbcch_main`:

| Percorso | Origine | Valore `[+0x99]` | Rilevanza |
|---|---|---|---|
| Percorso A (ERRC → IPC L1) | ERRC costruisce CPHY_CFG_REQ dal SIB1-NB decodificato | `schedulingInfoList.count` da OTA | **Il percorso vulnerabile** |
| Percorso B (interno L1) | `el1_ch_scs_ind_send` costruisce il corpo IPC interno | `1` hardcoded | Non vulnerabile |

Il percorso B ha confermato il formato del messaggio — il byte `+0x99` è il conteggio SI consumato da
`el1_ch_nbcch_start`. Poiché il suo conteggio è sempre hardcoded a 1, non può causare overflow. Il
percorso influenzato esternamente è il Percorso A.

### 6.2 La ricerca dello scrittore

La ricerca per pattern nel firmware di qualsiasi istruzione che scrivesse all'offset `+0x99` ha prodotto rumore:
T1 (`sb` diretto, ~100 hit), T2 (base suddivisa, 5 hit), T3 (offset calcolato, 0), T4
(`sh`/`sw` sovrapposti, ~465). Le funzioni di gestione del canale ERRC erano assenti dall'elenco dei
cross-reference di `msg_send6` perché ERRC usa `errc_com_send_msg`. Una sonda di emulazione
ha confermato che la scrittura avveniva lato ERRC: eseguendo l'harness Unicorn dal dispatcher L1 e
monitorando le scritture all'offset `+0x99` del buffer non è stato catturato nulla dal lato 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. Validazione

Questa specifica variante SM-A145R non sembra esercitare il percorso di codice NB-IoT vulnerabile nelle normali operazioni della build di produzione, motivo per cui sono state utilizzate emulazione ibrida e analisi statica anziché riproduzione diretta su hardware.

**Provato staticamente.** Il binario del firmware contiene la coppia di istruzioni vulnerabile. La catena di chiamate è ricostruita da simboli, riferimenti incrociati e corpi di funzioni decompilati.

**Eseguito nativamente in emulazione.** Il ciclo all'interno di `el1_ch_nbcch_resume_req` è stato eseguito su byte reali del firmware MediaTek in Unicorn Engine (MIPS32). L'istruzione `sh` del firmware stesso a `0x90213B02` ha scritto nello slot salvato dell'indirizzo di ritorno. L'istruzione `RESTORE` ha caricato il valore corrotto in `$ra` e `jrc ra` ha trasferito il controllo.

**Modellato esplicitamente.** La copia `lbu`/`sb` in `el1_ch_nbcch_start` non ha potuto essere eseguita completamente in modo nativo perché il percorso di dispatch della tabella di callback RTOS all'interno di `el1_ch_nbcch_cphy_cfg_req_process` si aspettava oggetti heap Nucleus live che l'emulatore piatto non forniva. L'handler di ripresa (`el1_ch_nbcch_resume_req`) nella Fase 2 legge solo dal contesto del canale residente in BSS e non passa attraverso lo stesso percorso di dispatch, motivo per cui la Fase 2 è stata eseguita nativamente senza richiedere lo stesso scaffolding. L'effetto collaterale della Fase 1 — un byte da `IPC_msg[+0x99]` scritto in `ch_ctx[+0x40A]` — è stato modellato direttamente ed etichettato `[PHASE1-MODEL]`.

**Non affermato.** Una riproduzione hardware completa end-to-end over-the-air.

### 7.1 Anti-manomissione

L'harness ha imposto una sola regola: nessun hook era autorizzato a scrivere il marker di prova nello slot salvato dell'indirizzo di ritorno. Ogni scrittura di memoria non appartenente al firmware è stata tracciata.```
[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 Consegna ZMQ

Per confermare che il payload di test sopravvive alla codifica PHY NB-IoT e alla consegna del transport-block, srsRAN
4G con un loopback ZMQ (nessuna emissione RF) è stato utilizzato. Il payload era un vettore volutamente
non conforme: il vincolo SIZE ASN.1 su `schedulingInfoList` è stato allentato per
consentire 40 voci, con decodifica round-trip di pycrate che conferma il campo contatore al byte 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` risiede in BSS e conserva il valore dell'attaccante finché il modem non si riavvia o una successiva configurazione del canale non lo sovrascrive.

### 8.2 Stack frame```
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]

Un controllo dei limiti di una sola riga apparirebbe come poche istruzioni aggiunte all'interno di una funzione esistente allo stesso indirizzo. Ciò che mostra il binario corretto è una revisione architetturale: il percorso di pianificazione NBCCH è stato riprogettato in modo che il pattern `si_count`-come-limite-del-ciclo non esista più da nessuna parte nel percorso.

### 10.4 Attribuzione CVE

La vulnerabilità qui descritta corrisponde a CVE-2024-20154 come pubblicato da MediaTek il 6 gennaio 2025. Base di conferma:

- La famiglia di firmware interessata (LR12A) corrisponde al bollettino di MediaTek.
- Classe di vulnerabilità — stack overflow, controllo dei limiti mancante, RCE da stazione base rogue, nessuna interazione dell'utente — corrisponde alla descrizione della CVE e al record NVD.
- Il firmware corretto rimuove esattamente le strutture di codice identificate come vulnerabili.
- L'ID della patch MOLY00720348 è stato confermato dal bollettino di MediaTek e dall'Android Security Bulletin (A-376809176).
- L'analisi assistita da IA ha associato in modo indipendente il pattern ricostruito a CVE-2024-20154 prima della conferma manuale.

---

## 11. Etica e Divulgazione Responsabile

### 11.1 Cosa non contiene questo post

Nessun exploit armato. Nessun contenuto binario del firmware. Nessun byte di payload malformato. Nessuna procedura passo-passo per attivare la vulnerabilità contro un dispositivo reale. Le informazioni necessarie per riprodurre un attacco funzionante — costruzione completa del payload per il decoder modem specifico, scaffolding degli oggetti heap RTOS per la piena emulazione della Fase 1, configurazione radio over-the-air — sono deliberatamente assenti.

### 11.2 Perché il loopback ZMQ e l'emulazione sono l'approccio etico

Il loopback ZMQ significa che nessun segnale è mai stato trasmesso via etere. Nessun dispositivo reale è stato preso di mira. Nessuna rete di operatore è stata coinvolta. La dimostrazione viene eseguita interamente in un ambiente software contenuto su hardware di proprietà dell'analista. Questo è l'approccio corretto per validare una vulnerabilità radio pre-associazione — trasmettere una trasmissione broadcast malformata colpirebbe qualsiasi dispositivo nel raggio d'azione.

L'emulazione Unicorn dimostra che il comportamento vulnerabile è nel binario del firmware stesso, in modo riproducibile, indipendentemente da qualsiasi stato specifico del dispositivo o ambiente radio. Questa è un'affermazione tecnicamente più forte di un singolo crash hardware ed evita di distribuire qualsiasi cosa via etere.

### 11.3 Proprietà intellettuale di MediaTek

Tutte le analisi sono state eseguite su firmware ottenuto legittimamente da un dispositivo consumer e dai pacchetti di firmware rilasciati pubblicamente da Samsung. Nessuna documentazione proprietaria è stata utilizzata. Le definizioni interne delle struct MediaTek e i formati dei messaggi IPC sono descritti solo nella misura necessaria a spiegare il fallimento della memory safety. Non vengono pubblicati come specifiche.

---