Il firmware del baseband non è codice Android. È un sistema embedded separato sul sottosistema radio del SoC con la propria CPU, il proprio RTOS e il proprio spazio di memoria, al di fuori del 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 embedded — coerente con l'approccio di MediaTek per i baseband della generazione Helio, confermato da ricerche indipendenti pubblicate sui 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/user, né applicazione della memory protection unit tra i task, né 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 sono validati rispetto ad alcuna policy |

### 2.4 Approccio di analisi

Tre percorsi paralleli:

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

**Validazione dinamica.** Unicorn Engine (emulazione MIPS32) è stato usato per eseguire specifiche
routine del firmware in isolamento attraverso due fasi. La Fase 1 ha tentato di dimostrare la copia
non limitata di `si_count` nel contesto del canale attraverso 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. Dove la Fase 1 non ha potuto essere eseguita completamente in modo nativo — perché
l'ambiente degli oggetti di servizio RTOS richiesto dal percorso di dispatch CPHY non è stato ricostruito —
l'effetto collaterale è stato modellato direttamente ed etichettato come tale in tutto l'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 di attacco: NB-IoT e SIB1-NB

### 3.1 Superficie di attacco pre-associazione

NB-IoT (Narrowband Internet of Things) è 3GPP Release 13, progettato per connettere dispositivi
IoT vincolati usando lo spettro LTE concesso esistente. È implementato in un'ampia gamma di SoC
cellulari moderni, inclusi quelli degli smartphone di consumo.

Mentre è in RRC_IDLE, prima che qualsiasi connessione RRC sia stabilita, un dispositivo in ricerca del servizio:

1. Si sincronizza con i segnali di timing 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 scheduling in SIB1-NB per localizzare ulteriori system information block

Al passo 3, il modem elabora un messaggio da un'entità che non ha autenticato, prima di qualsiasi
connessione o interazione utente. Un trasmettitore malevolo 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`, poi
importata in Ghidra tramite `ImportSymbolsScript.py`. Il risultato è stato la completa
denominazione delle funzioni interne in tutto lo stack del modem — livello ERRC, gestione dei canali L1, sottosistema IPC e la
catena di gestione NB-IoT BCCH — consentendo la ricostruzione della catena guidata dalla semantica.

Tutti i nomi delle funzioni in questo post provengono dai simboli di debug incorporati di MediaTek estratti
dall'immagine del firmware.

---

## 5. Vulnerabilità

### 5.1 Il ciclo 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 di 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 — Livello A

Il buffer CPHY_CFG_REQ viene costruito nel livello ERRC 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 clamping su tre livelli

| Livello | Funzione | Indirizzo | Clamp presente? |
|---|---|---|---|
| A — builder ERRC | `errc_chm_l1_set_bcch_si_reception` | range ERRC | **Nessuno** |
| B — copia L1 | `el1_ch_nbcch_start` | `0x90213444` | **Nessuno** |
| C — loop L1 | `el1_ch_nbcch_resume_req` | `0x90213940` | **Nessuno** |

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

### 5.7 Causa radice

Un invariante violato:

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

3GPP fornisce il limite di protocollo previsto (8 voci). Il firmware doveva far rispettare il
limite di memory-safety a ogni livello in cui il conteggio diventa un indice o un limite di
ciclo. Nella build vulnerabile, il conteggio viaggiava dal campo di broadcast SIB1-NB attraverso
il decoder ERRC, nel messaggio CPHY_CFG_REQ, oltre un confine IPC nel task L1, nel contesto
canale BSS, e in un ciclo di scrittura sullo stack — senza che alcun livello lo limitasse.

---

## 6. La Catena di Chiamate — Come È Stato Trovato

### 6.1 La confusione tra i due percorsi

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

| Percorso | Sorgente | Valore `[+0x99]` | Rilevanza |
|---|---|---|---|
| Percorso A (ERRC → L1 IPC) | ERRC costruisce CPHY_CFG_REQ dal SIB1-NB decodificato | `schedulingInfoList.count` da OTA | **Il percorso vulnerabile** |
| Percorso B (L1 interno) | `el1_ch_scs_ind_send` costruisce il corpo IPC interno | Hardcoded `1` | 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ò andare in overflow. Il
percorso influenzato esternamente è il Percorso A.

### 6.2 La ricerca del writer

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

Questo specifico modello SM-A145R non sembra percorrere il codice NB-IoT vulnerabile durante
il normale funzionamento di ship-build, motivo per cui sono state utilizzate l'emulazione ibrida
e l'analisi statica anziché la riproduzione diretta su hardware.

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

**Eseguito nativamente in emulazione.** Il loop 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 dell'indirizzo di ritorno salvato. 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 attivi che l'emulatore flat non forniva. Il gestore
di resume (`el1_ch_nbcch_resume_req`) nella Fase 2 legge solo dal contesto di canale residente in BSS
e non incontra 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 rivendicato.** Una riproduzione hardware over-the-air completa end-to-end.

### 7.1 Anti-manomissione

L'harness ha imposto una regola: nessun hook era autorizzato a scrivere il marcatore di prova nello slot
dell'indirizzo di ritorno salvato. Ogni scrittura in memoria non proveniente dal 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, è stato utilizzato srsRAN 4G con un loopback ZMQ (nessuna emissione RF). Il payload era un vettore deliberatamente non conforme — il vincolo ASN.1 SIZE su `schedulingInfoList` è stato allentato per consentire 40 voci, con la decodifica round-trip di pycrate che conferma il campo count al byte 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` risiede in BSS e mantiene il valore dell'attaccante fino al riavvio del modem o finché 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 semplice controllo dei limiti su una singola riga apparirebbe come poche istruzioni aggiunte all'interno di una funzione esistente allo stesso indirizzo. Ciò che il binario corretto mostra è una revisione architetturale: il percorso di scheduling NBCCH è stato riprogettato in modo che il pattern `si_count`-come-limite-di-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 della conferma:

- La famiglia di firmware interessata (LR12A) corrisponde al bollettino di MediaTek.
- La classe di vulnerabilità — stack overflow, controllo dei limiti mancante, RCE da stazione base malevola, nessuna interazione utente — corrisponde alla descrizione della CVE e al record NVD.
- Il firmware corretto rimuove esattamente le strutture di codice identificate come vulnerabili.
- Patch ID MOLY00720348 confermato dal bollettino di MediaTek e dall'Android Security Bulletin (A-376809176).
- L'analisi assistita da AI ha autonomamente associato 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 weaponizzato. 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 — la costruzione completa del payload per lo specifico decoder del modem, l'impalcatura degli oggetti heap RTOS per l'emulazione completa della Fase 1, la 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 prova 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 un broadcast malformato influenzerebbe 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ù solida rispetto a un singolo crash hardware, ed evita di distribuire qualsiasi cosa via etere.

### 11.3 Proprietà intellettuale di MediaTek

Tutta l'analisi è stata eseguita su firmware ottenuto legittimamente da un dispositivo di consumo e dai pacchetti firmware rilasciati pubblicamente da Samsung. Nessuna documentazione proprietaria è stata utilizzata. Le definizioni interne delle struct di MediaTek e i formati dei messaggi IPC sono descritti solo nella misura necessaria a spiegare il fallimento della sicurezza della memoria. Non sono pubblicati come specifiche.

---