Le firmware de la bande de base n'est pas du code Android. Il s'agit d'un système embarqué séparé sur le sous-système radio du SoC avec son propre CPU, son propre RTOS et son propre espace mémoire, en dehors du sandbox des processus Android.

### 2.2 Architecture du modem

L'analyse du binaire extrait montre que le processeur du modem exécute du MIPS32 avec des instructions compressées MIPS16e2 en mode little-endian. MIPS16e2 est une extension de codage 16 bits pour la réduction de la taille du code embarqué — cohérente avec l'approche de MediaTek pour les bandes de base de la génération Helio, confirmée par des recherches indépendantes publiées sur cette famille de SoC.

Le système d'exploitation est Nucleus RTOS, fournissant l'ordonnancement des tâches, les files de messages IPC et un allocateur mémoire basé sur des pools. Il n'y a pas de séparation des privilèges noyau/utilisateur, aucune application d'unité de protection mémoire entre les tâches, et aucun mécanisme matériel de protection de pile.

Toutes les adresses dans cet article sont des adresses virtuelles, telles que chargées dans Ghidra à la base `0x90000000`.

### 2.3 Atténuations (observées dans la version analysée)

| Mitigation | Status | Effect |
|---|---|---|
| ASLR | Absent | Les adresses du firmware sont statiques et prévisibles à partir de l'image |
| Stack canary | Absent | `SAVE`/`RESTORE` stocke les registres sauvegardés par l'appelé sans valeur de garde |
| NX / W^X | Absent | La mémoire de la pile est exécutable |
| CFI | Absent | Les adresses de retour ne sont validées par aucune politique |

### 2.4 Approche d'analyse

Trois pistes parallèles :

**Analyse statique.** Paquet firmware Samsung → extraction de la partition CP → `md1img.img` → Ghidra (MIPS LE 32 bits, base `0x90000000`) avec les symboles d'ingénierie MediaTek récupérés de la section de débogage du firmware à l'aide de la boîte à outils `mtk_bp` du NCC Group.

**Validation dynamique.** Unicorn Engine (émulation MIPS32) a été utilisé pour exécuter des routines spécifiques du firmware de manière isolée en deux phases. La phase 1 a tenté de prouver la copie non limitée de `si_count` dans le contexte du canal via la paire d'instructions natives. La phase 2 a exécuté la boucle vulnérable sur des octets réels du firmware et a confirmé que les propres instructions du firmware corrompent l'adresse de retour sauvegardée. Là où la phase 1 n'a pas pu s'exécuter entièrement de manière native — parce que l'environnement des objets de service RTOS requis par le chemin de dispatch CPHY n'a pas été reconstruit — l'effet secondaire a été modélisé directement et étiqueté comme tel dans toutes les sorties.

**Validation côté radio.** srsRAN 4G avec une boucle de retour ZMQ — uniquement logiciel, sans émission RF — a confirmé que la charge utile de test survit au codage PHY NB-IoT et à la livraison des blocs de transport.

---

## 3. Surface d'attaque : NB-IoT et SIB1-NB

### 3.1 Surface d'attaque avant association

Le NB-IoT (Narrowband Internet of Things) est la version 13 de la 3GPP, conçue pour connecter des appareils IoT contraints en utilisant le spectre LTE sous licence existant. Il est implémenté dans une large gamme de SoC cellulaires modernes, y compris ceux des smartphones grand public.

En état RRC_IDLE, avant qu'aucune connexion RRC ne soit établie, un appareil recherchant un service va :

1. Se synchroniser avec les signaux de synchronisation de la cellule (NPSS/NSSS)
2. Décoder le bloc d'informations principales (MIB) sur NPBCH (fenêtre de transmission de 640 ms)
3. Décoder SIB1-NB depuis NPDSCH (planification de 2560 ms)
4. Utiliser les informations de planification dans SIB1-NB pour localiser des blocs d'informations système supplémentaires

À l'étape 3, le modem traite un message provenant d'une entité qu'il n'a pas authentifiée, avant toute connexion ou interaction utilisateur. Un émetteur malveillant satisfaisant les conditions normales de sélection de cellule sera traité.```
+------------------+                   +---------------------+
|  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 section de débogage CATI a été décompressée et analysée avec `mtk_dbg_extract.py symbols`, puis importée dans Ghidra via `ImportSymbolsScript.py`. Le résultat a été les noms complets des fonctions internes dans toute la pile modem — couche ERRC, gestion de canal L1, sous-système IPC, et la chaîne de gestionnaire BCCH NB-IoT — permettant une reconstruction de chaîne guidée par la sémantique.

Tous les noms de fonctions dans cet article proviennent des symboles de débogage intégrés de MediaTek extraits de l'image du firmware.

---

## 5. Vulnérabilité

### 5.1 La boucle vulnérable

`el1_ch_nbcch_resume_req` (`0x90213940`) gère l'événement de reprise du canal de diffusion NB-IoT. Son prologue de fonction MIPS16e2 :

````asm
90213940:  save  0xE8, ra, s0-s1

À partir de la décompilation Ghidra du binaire du firmware réel :```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
}

Flux B (byte `sb` writes) commence à `new_sp+0x78` et nécessiterait l'itération 108 pour atteindre l'emplacement RA :```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 Le constructeur ERRC — Couche A

Le tampon CPHY_CFG_REQ est construit dans la couche ERRC à partir du SIB1-NB décodé. La fonction `errc_chm_l1_set_bcch_si_reception` écrit `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 Absence de limitation sur trois couches

| Couche | Fonction | Adresse | Limiteur présent ? |
|---|---|---|---|
| A — Constructeur ERRC | `errc_chm_l1_set_bcch_si_reception` | Plage ERRC | **Aucun** |
| B — Copie L1 | `el1_ch_nbcch_start` | `0x90213444` | **Aucun** |
| C — Boucle L1 | `el1_ch_nbcch_resume_req` | `0x90213940` | **Aucun** |

Un seul contrôle à n'importe quelle couche aurait brisé la chaîne.

### 5.7 Cause racine

Un invariant violé :

> Le nombre d'entrées de planification SI ne doit jamais dépasser la capacité du tableau de destination.

La 3GPP fournit la limite protocolaire prévue (8 entrées). Le firmware devait appliquer la
limite de sécurité mémoire à chaque couche où le nombre devient un indice ou une limite de boucle. Dans la
version vulnérable, le nombre a voyagé depuis le champ de diffusion SIB1-NB à travers le décodeur
ERRC, dans le message CPHY_CFG_REQ, à travers une frontière IPC dans la tâche L1, dans
le contexte de canal BSS, et dans une boucle d'écriture sur la pile — sans qu'aucune couche ne le limite.

---

## 6. La chaîne d'appels — Comment elle a été trouvée

### 6.1 La confusion des deux chemins

Deux chemins structurellement similaires mais distincts peuvent livrer un tampon de configuration de 0x760 octets à
`el1_ch_nbcch_main` :

| Chemin | Source | Valeur de `[+0x99]` | Pertinence |
|---|---|---|---|
| Chemin A (ERRC → IPC L1) | ERRC construit CPHY_CFG_REQ à partir du SIB1-NB décodé | `schedulingInfoList.count` depuis l'OTA | **Le chemin vulnérable** |
| Chemin B (interne L1) | `el1_ch_scs_ind_send` construit le corps IPC interne | 1 codé en dur | Non vulnérable |

Le chemin B a confirmé le format du message — l'octet `+0x99` est le nombre SI consommé par
`el1_ch_nbcch_start`. Comme son nombre est toujours codé en dur à 1, il ne peut pas déborder. Le
chemin influencé de l'extérieur est le Chemin A.

### 6.2 La recherche de l'écriture

La recherche par motif dans le firmware de toute instruction écrivant à l'offset `+0x99` a produit du bruit :
T1 (`sb` direct, ~100 hits), T2 (base scindée, 5 hits), T3 (offset calculé, 0), T4
(`sh`/`sw` chevauchants, ~465). Les fonctions de gestion de canal ERRC étaient absentes de la
liste de références croisées `msg_send6` car ERRC utilise `errc_com_send_msg`. Une sonde
d'émulation a confirmé que l'écriture était côté ERRC : l'exécution du harnais Unicorn depuis le dispatcher L1
et la surveillance des écritures sur l'offset `+0x99` du tampon n'ont rien capturé du côté 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. Validation

Ce modèle SM-A145R spécifique ne semble pas exercer le chemin de code NB-IoT vulnérable en fonctionnement normal du ship build, c'est pourquoi l'émulation hybride et l'analyse statique ont été utilisées plutôt qu'une reproduction matérielle directe.

**Prouvé statiquement.** Le binaire du firmware contient la paire d'instructions vulnérable. La chaîne d'appel est reconstruite à partir des symboles, des références croisées et des corps de fonctions décompilés.

**Exécuté nativement en émulation.** La boucle à l'intérieur de `el1_ch_nbcch_resume_req` a été exécutée sur des octets réels du firmware MediaTek dans Unicorn Engine (MIPS32). L'instruction `sh` du firmware à `0x90213B02` a écrit dans l'emplacement de l'adresse de retour sauvegardée. L'instruction `RESTORE` a chargé la valeur corrompue dans `$ra`, et `jrc ra` a transféré le contrôle.

**Modélisé explicitement.** La copie `lbu`/`sb` dans `el1_ch_nbcch_start` n'a pas pu être entièrement exécutée nativement parce que le chemin de dispatch de table de callback du RTOS à l'intérieur de `el1_ch_nbcch_cphy_cfg_req_process` attendait des objets heap Nucleus vivants que l'émulateur plat ne fournissait pas. Le gestionnaire de reprise (`el1_ch_nbcch_resume_req`) en phase 2 ne lit que depuis le contexte de canal résident BSS et n'emprunte pas ce même chemin de dispatch, c'est pourquoi la phase 2 a été exécutée nativement sans nécessiter le même échafaudage. L'effet de bord de la phase 1 — un octet de `IPC_msg[+0x99]` écrit dans `ch_ctx[+0x40A]` — a été modélisé directement et étiqueté `[PHASE1-MODEL]`.

**Non revendiqué.** Une reproduction matérielle complète de bout en bout par liaison radio.

### 7.1 Anti-altération

Le harness a imposé une règle : aucun hook n'était autorisé à écrire le marqueur de preuve dans l'emplacement de l'adresse de retour sauvegardée. Chaque écriture mémoire non firmware a été tracée.```
[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 Livraison ZMQ

Pour confirmer que la charge utile de test survit à l'encodage PHY NB-IoT et à la livraison de blocs de transport, srsRAN
4G avec une boucle de retour ZMQ (aucune émission RF) a été utilisé. La charge utile était un vecteur délibérément
non conforme — la contrainte SIZE de l'ASN.1 sur `schedulingInfoList` a été assouplie pour
autoriser 40 entrées, avec un décodage aller-retour pycrate confirmant que le champ de comptage se trouve à l'octet 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` réside dans BSS et conserve la valeur de l'attaquant jusqu'à ce que le modem se réinitialise ou qu'une configuration de canal ultérieure l'écrase.

### 8.2 Trame de pile```
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 contrôle de limites sur une seule ligne apparaîtrait comme quelques instructions ajoutées à l'intérieur d'une fonction existante à la même adresse. Ce que montre le binaire corrigé, c'est une révision architecturale : le chemin de planification NBCCH a été repensé de sorte que le motif `si_count` utilisé comme limite de boucle n'existe plus nulle part dans ce chemin.

### 10.4 Attribution CVE

La vulnérabilité décrite ici correspond à CVE-2024-20154 telle que publiée par MediaTek le 6 janvier 2025. Base de confirmation :

- La famille de firmware affectée (LR12A) correspond au bulletin de MediaTek.
- La classe de vulnérabilité — débordement de pile, absence de contrôle des limites, RCE à partir d'une station de base malveillante, aucune interaction utilisateur — correspond à la description CVE et à l'enregistrement NVD.
- Le firmware corrigé supprime exactement les structures de code identifiées comme vulnérables.
- L'ID de correctif MOLY00720348 est confirmé à partir du bulletin de MediaTek et du Bulletin de sécurité Android (A-376809176).
- L'analyse assistée par IA a indépendamment fait correspondre le motif reconstruit à CVE-2024-20154 avant confirmation manuelle.

---

## 11. Éthique et Divulgation Responsable

### 11.1 Ce que cet article ne contient pas

Aucun exploit militarisé. Aucun contenu binaire du firmware. Aucun octet de charge utile malformé. Aucune procédure pas à pas pour déclencher la vulnérabilité sur un appareil réel. Les informations nécessaires pour reproduire une attaque fonctionnelle — construction complète de la charge utile pour le décodeur de modem spécifique, échafaudage d'objets tas RTOS pour une émulation complète de la phase 1, configuration radio over-the-air — sont délibérément absentes.

### 11.2 Pourquoi la boucle de retour ZMQ et l'émulation sont l'approche éthique

La boucle de retour ZMQ signifie qu'aucun signal n'a jamais été transmis par voie hertzienne. Aucun appareil réel n'a été ciblé. Aucun réseau d'opérateur n'a été impliqué. La preuve s'exécute entièrement dans un environnement logiciel confiné sur du matériel appartenant à l'analyste. C'est l'approche correcte pour valider une vulnérabilité radio de pré-association — transmettre une diffusion malformée affecterait tout appareil à portée.

L'émulation Unicorn démontre que le comportement vulnérable se trouve dans le binaire du firmware lui-même, de manière reproductible, indépendamment de tout état d'appareil spécifique ou environnement radio. C'est une affirmation techniquement plus solide qu'un simple crash matériel, et cela évite de déployer quoi que ce soit par voie hertzienne.

### 11.3 Propriété intellectuelle de MediaTek

Toute l'analyse a été effectuée sur un firmware obtenu légitimement à partir d'un appareil grand public et des packages de firmware publiés publiquement par Samsung. Aucune documentation propriétaire n'a été utilisée. Les définitions de structures internes de MediaTek et les formats de messages IPC ne sont décrits que dans la mesure nécessaire pour expliquer la défaillance de sécurité mémoire. Ils ne sont pas publiés en tant que spécifications.

---