Die Baseband-Firmware ist kein Android-Code. Sie ist ein separates eingebettetes System
auf dem Funk-Subsystem des SoC mit eigener CPU, eigenem RTOS und eigenem Speicherbereich,
außerhalb der Android-Prozess-Sandbox.

### 2.2 Modem-Architektur

Die Analyse des extrahierten Binaries zeigt, dass der Modem-Prozessor MIPS32 mit MIPS16e2-
komprimierten Instruktionen im Little-Endian-Modus ausführt. MIPS16e2 ist eine 16-Bit-
Kodierungserweiterung zur Reduzierung der Codegröße in eingebetteten Systemen — konsistent
mit MediaTeks Ansatz für Basebands der Helio-Generation, bestätigt durch unabhängige
veröffentlichte Baseband-Forschung zu dieser SoC-Familie.

Das Betriebssystem ist Nucleus RTOS, das Task-Scheduling, IPC-Nachrichtenwarteschlangen und
einen pool-basierten Speicherallokator bereitstellt. Es gibt keine Kernel/User-
Privilegientrennung, keine Durchsetzung einer Speicherschutzeinheit zwischen Tasks und keinen
Hardware-Stack-Guard-Mechanismus.

Alle Adressen in diesem Beitrag sind virtuelle Adressen, wie sie in Ghidra mit Basis
`0x90000000` geladen werden.

### 2.3 Mitigationsmaßnahmen (beobachtet im analysierten Build)

| Mitigation | Status | Wirkung |
|---|---|---|
| ASLR | Fehlt | Firmware-Adressen sind statisch und aus dem Image vorhersagbar |
| Stack Canary | Fehlt | `SAVE`/`RESTORE` speichert callee-saved Register ohne Guard-Wert |
| NX / W^X | Fehlt | Stack-Speicher ist ausführbar |
| CFI | Fehlt | Rücksprungadressen werden gegen keine Policy validiert |

### 2.4 Analyseansatz

Drei parallele Spuren:

**Statische Analyse.** Samsung-Firmware-Paket → CP-Partition-Extraktion → `md1img.img` →
Ghidra (MIPS LE 32-Bit, Basis `0x90000000`) mit MediaTek-Engineering-Symbolen, die aus dem
Firmware-Debug-Bereich mit dem NCC Group `mtk_bp`-Toolset wiederhergestellt wurden.

**Dynamische Validierung.** Unicorn Engine (MIPS32-Emulation) wurde verwendet, um bestimmte
Firmware-Routinen isoliert über zwei Phasen auszuführen. Phase 1 versuchte, die ungeklemmte
Kopie von `si_count` in den Kanal-Kontext durch das native Instruktionspaar zu beweisen.
Phase 2 führte die verwundbare Schleife auf echten Firmware-Bytes aus und bestätigte, dass
die Firmware-eigenen Instruktionen die gespeicherte Rücksprungadresse korrumpieren. Wo Phase 1
nicht vollständig nativ ausgeführt werden konnte — weil die vom CPHY-Dispatch-Pfad benötigte
RTOS-Service-Object-Umgebung nicht rekonstruiert wurde — wurde der Seiteneffekt direkt
modelliert und als solcher in allen Ausgaben gekennzeichnet.

**Funkseitige Validierung.** srsRAN 4G mit einem ZMQ-Loopback — rein softwarebasiert, keine
RF-Emission — bestätigte, dass die Test-Payload die NB-IoT-PHY-Kodierung und Transportblock-
Zustellung übersteht.

---

## 3. Angriffsfläche: NB-IoT und SIB1-NB

### 3.1 Angriffsfläche vor der Assoziierung

NB-IoT (Narrowband Internet of Things) ist 3GPP Release 13 und wurde entwickelt, um
ressourcenbeschränkte IoT-Geräte über vorhandenes lizenziertes LTE-Spektrum zu verbinden. Es
ist in einer breiten Palette moderner zellularer SoCs implementiert, einschließlich solcher in
Consumer-Smartphones.

Während sich ein Gerät im RRC_IDLE befindet, bevor eine RRC-Verbindung aufgebaut wird, wird
ein Gerät, das nach einem Dienst sucht:

1. Mit den Timing-Signalen der Zelle synchronisieren (NPSS/NSSS)
2. Den Master Information Block über NPBCH dekodieren (640 ms Übertragungsfenster)
3. SIB1-NB aus NPDSCH dekodieren (2560 ms Zeitplan)
4. Die Scheduling-Informationen in SIB1-NB verwenden, um zusätzliche Systeminformationsblöcke zu lokalisieren

In Schritt 3 verarbeitet das Modem eine Nachricht von einer Entität, die es nicht
authentifiziert hat, bevor irgendeine Verbindung oder Benutzerinteraktion stattfindet. Ein
bösartiger Sender, der die normalen Zellauswahlbedingungen erfüllt, wird verarbeitet.```
+------------------+                   +---------------------+
|  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]      |

Der CATI-Debug-Bereich wurde mit `mtk_dbg_extract.py symbols` dekomprimiert und geparst und
anschließend über `ImportSymbolsScript.py` in Ghidra importiert. Das Ergebnis waren vollständige interne Funktions-
namen im gesamten Modem-Stack — ERRC-Schicht, L1-Kanalverwaltung, IPC-Subsystem und die
NB-IoT-BCCH-Handler-Kette — was eine semantikgestützte Kettenrekonstruktion ermöglichte.

Alle Funktionsnamen in diesem Beitrag stammen aus MediaTeks eigenen eingebetteten Debug-Symbolen, die
aus dem Firmware-Image extrahiert wurden.

---

## 5. Schwachstelle

### 5.1 Die anfällige Schleife

`el1_ch_nbcch_resume_req` (`0x90213940`) behandelt das NB-IoT-Broadcast-Channel-Resume-Ereignis.
Sein MIPS16e2-Funktionsprolog:```asm
90213940:  save  0xE8, ra, s0-s1

Aus der Ghidra-Dekompilierung der tatsächlichen Firmware-Binärdatei:```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 (Byte-`sb`-Schreibvorgänge) beginnt bei `new_sp+0x78` und würde Iteration 108 erfordern, um
den RA-Slot zu erreichen:```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 Der ERRC-Builder — Layer A

Der CPHY_CFG_REQ-Puffer wird im ERRC-Layer aus dem dekodierten SIB1-NB aufgebaut. Die Funktion
`errc_chm_l1_set_bcch_si_reception` schreibt `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 Dreischichtiges Fehlen einer Begrenzung

| Ebene | Funktion | Adresse | Begrenzung vorhanden? |
|---|---|---|---|
| A — ERRC-Builder | `errc_chm_l1_set_bcch_si_reception` | ERRC-Bereich | **Keine** |
| B — L1-Kopie | `el1_ch_nbcch_start` | `0x90213444` | **Keine** |
| C — L1-Schleife | `el1_ch_nbcch_resume_req` | `0x90213940` | **Keine** |

Jede einzelne Prüfung auf jeder der Ebenen hätte die Kette unterbrochen.

### 5.7 Grundursache

Eine verletzte Invariante:

> Die Anzahl der SI-Scheduling-Einträge darf niemals die Kapazität des Ziel-Arrays überschreiten.

3GPP gibt die beabsichtigte Protokollgrenze vor (8 Einträge). Die Firmware musste die
Speichersicherheitsgrenze auf jeder Ebene durchsetzen, auf der die Anzahl zu einem Index oder
Schleifenlimit wird. Im verwundbaren Build wanderte die Anzahl vom SIB1-NB-Broadcast-Feld durch den
ERRC-Decoder, in die CPHY_CFG_REQ-Nachricht, über eine IPC-Grenze in die L1-Task, in den
Kanal-Kontext-BSS und in eine stack-schreibende Schleife — ohne dass eine Ebene sie begrenzte.

---

## 6. Die Aufrufkette — Wie sie gefunden wurde

### 6.1 Die Verwechslung der zwei Pfade

Zwei strukturell ähnliche, aber unterschiedliche Pfade können einen 0x760-Byte-Konfigurationspuffer an
`el1_ch_nbcch_main` liefern:

| Pfad | Quelle | `[+0x99]`-Wert | Relevanz |
|---|---|---|---|
| Pfad A (ERRC → L1 IPC) | ERRC baut CPHY_CFG_REQ aus decodiertem SIB1-NB | `schedulingInfoList.count` aus OTA | **Der verwundbare Pfad** |
| Pfad B (L1-intern) | `el1_ch_scs_ind_send` baut internen IPC-Body | Fest codiert `1` | Nicht verwundbar |

Pfad B bestätigte das Nachrichtenformat — Byte `+0x99` ist die SI-Anzahl, die von
`el1_ch_nbcch_start` konsumiert wird. Da seine Anzahl immer fest auf 1 codiert ist, kann er nicht
überlaufen. Der von außen beeinflussbare Pfad ist Pfad A.

### 6.2 Die Suche nach dem Schreiber

Die Mustersuche in der Firmware nach jeglicher Instruktion, die in Offset `+0x99` schreibt, erzeugte Rauschen:
T1 (direktes `sb`, ~100 Treffer), T2 (geteilte Basis, 5 Treffer), T3 (berechneter Offset, 0), T4
(überlappendes `sh`/`sw`, ~465). Die ERRC-Kanalverwaltungsfunktionen fehlten in der
`msg_send6`-Querverweisliste, weil ERRC `errc_com_send_msg` verwendet. Eine Emulationssonde
bestätigte, dass der Schreibvorgang auf der ERRC-Seite erfolgte: Das Ausführen des Unicorn-Harness vom L1-Dispatcher aus und die Überwachung auf Schreibvorgänge in den `+0x99`-Offset des Puffers erfasste nichts von der L1-Seite.```
[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. Validierung

Dieses spezifische SM-A145R-Modell scheint den verwundbaren NB-IoT-Codepfad im normalen Ship-Build-Betrieb nicht zu durchlaufen, weshalb Hybrid-Emulation und statische Analyse anstelle einer direkten Hardware-Reproduktion verwendet wurden.

**Statisch bewiesen.** Die Firmware-Binärdatei enthält das verwundbare Instruktionspaar. Die Aufrufkette wird aus Symbolen, Querverweisen und dekompilierten Funktionskörpern rekonstruiert.

**Nativ in der Emulation ausgeführt.** Die Schleife innerhalb von `el1_ch_nbcch_resume_req` lief auf echten MediaTek-Firmware-Bytes in Unicorn Engine (MIPS32). Die `sh`-Instruktion der Firmware bei `0x90213B02` schrieb in den gespeicherten Rücksprungadress-Slot. Die `RESTORE`-Instruktion lud den korrumpierten Wert in `$ra`, und `jrc ra` übertrug die Kontrolle.

**Explizit modelliert.** Die `lbu`/`sb`-Kopie in `el1_ch_nbcch_start` konnte nicht vollständig nativ ausgeführt werden, da der RTOS-Callback-Table-Dispatch-Pfad innerhalb von `el1_ch_nbcch_cphy_cfg_req_
process` lebende Nucleus-Heap-Objekte erwartete, die der flache Emulator nicht bereitstellte. Der Resume-Handler (`el1_ch_nbcch_resume_req`) in Phase 2 liest nur aus dem BSS-residenten Kanal-Kontext und trifft nicht auf denselben Dispatch-Pfad, weshalb Phase 2 nativ ohne dasselbe Gerüst lief. Der Seiteneffekt von Phase 1 — ein Byte aus `IPC_msg[+0x99]`, geschrieben nach `ch_ctx[+0x40A]` — wurde direkt modelliert und als `[PHASE1-MODEL]` gekennzeichnet.

**Nicht beansprucht.** Eine vollständige End-to-End-Over-the-Air-Hardware-Reproduktion.

### 7.1 Anti-Tamper

Die Harness erzwang eine Regel: Kein Hook durfte den Proof-Marker in den gespeicherten Rücksprungadress-Slot schreiben. Jeder Nicht-Firmware-Speicherschreibvorgang wurde verfolgt.```
[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-Zustellung

Um zu bestätigen, dass die Testnutzlast die NB-IoT-PHY-Codierung und die Transportblock-Zustellung übersteht, wurde srsRAN 4G mit einem ZMQ-Loopback (keine HF-Abstrahlung) verwendet. Die Nutzlast war ein bewusst nicht konformer Vektor — die ASN.1-SIZE-Einschränkung für `schedulingInfoList` wurde gelockert, um 40 Einträge zuzulassen, wobei die pycrate-Round-Trip-Dekodierung das Zählfeld bei Byte 14 bestätigte.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` liegt im BSS und behält den Wert des Angreifers, bis das Modem zurückgesetzt wird oder eine nachfolgende Kanalkonfiguration ihn überschreibt.

### 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]

Ein einzeiliger Bounds-Check würde als ein paar zusätzliche Instruktionen innerhalb einer bestehenden Funktion an derselben Adresse erscheinen. Was das gepatchte Binary zeigt, ist eine architektonische Überarbeitung: Der NBCCH-Scheduling-Pfad wurde neu gestaltet, sodass das Muster `si_count`-als-Schleifengrenze nirgendwo im Pfad mehr existiert.

### 10.4 CVE-Zuordnung

Die hier beschriebene Schwachstelle entspricht CVE-2024-20154, veröffentlicht von MediaTek am 6. Januar 2025. Bestätigungsgrundlage:

- Betroffene Firmware-Familie (LR12A) stimmt mit MediaTeks Bulletin überein.
- Schwachstellenklasse — Stack-Overflow, fehlender Bounds-Check, RCE von einer rogue Basisstation, keine Benutzerinteraktion — stimmt mit der CVE-Beschreibung und dem NVD-Eintrag überein.
- Die gepatchte Firmware entfernt genau die als verwundbar identifizierten Codestrukturen.
- Patch-ID MOLY00720348 bestätigt aus MediaTeks Bulletin und dem Android Security Bulletin (A-376809176).
- KI-gestützte Analyse stimmte das rekonstruierte Muster unabhängig mit CVE-2024-20154 ab, bevor die manuelle Bestätigung erfolgte.

---

## 11. Ethik und verantwortungsvolle Offenlegung

### 11.1 Was dieser Beitrag nicht enthält

Kein weaponisierter Exploit. Kein Firmware-Binary-Inhalt. Keine malformed Payload-Bytes. Keine Schritt-für-Schritt-Anleitung zum Auslösen der Schwachstelle gegen ein Live-Gerät. Die Informationen, die zur Reproduktion eines funktionierenden Angriffs benötigt werden — vollständige Payload-Konstruktion für den spezifischen Modem-Decoder, RTOS-Heap-Object-Scaffolding für vollständige Phase-1-Emulation, Over-the-Air-Funkkonfiguration — fehlen bewusst.

### 11.2 Warum ZMQ-Loopback und Emulation der ethische Ansatz sind

ZMQ-Loopback bedeutet, dass niemals ein Signal über die Luft übertragen wurde. Kein reales Gerät wurde angegriffen. Kein Carrier-Netzwerk war beteiligt. Der Proof läuft vollständig in einer abgeschotteten Softwareumgebung auf Hardware, die dem Analysten gehört. Dies ist der korrekte Ansatz zur Validierung einer Pre-Association-Funk-Schwachstelle — die Übertragung eines malformed Broadcast würde jedes Gerät in Reichweite betreffen.

Unicorn-Emulation demonstriert, dass das verwundbare Verhalten im Firmware-Binary selbst liegt, reproduzierbar, unabhängig von einem bestimmten Gerätezustand oder Funkumfeld. Dies ist eine technisch stärkere Aussage als ein einzelner Hardware-Crash, und es vermeidet, irgendetwas über die Luft einzusetzen.

### 11.3 MediaTek geistiges Eigentum

Die gesamte Analyse wurde an Firmware durchgeführt, die rechtmäßig von einem Consumer-Gerät und aus Samsungs öffentlich veröffentlichten Firmware-Paketen bezogen wurde. Es wurde keine proprietäre Dokumentation verwendet. Interne MediaTek-Struct-Definitionen und IPC-Nachrichtenformate werden nur in dem Umfang beschrieben, der zur Erklärung des Memory-Safety-Fehlers erforderlich ist. Sie werden nicht als Spezifikationen veröffentlicht.

---