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

### 2.2 Architecture du modem

L'analyse du binaire extrait montre que le processeur du modem fonctionne en MIPS32 avec des instructions compressées MIPS16e2 en mode petit-boutiste. MIPS16e2 est une extension d'encodage 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 les bandes de base de cette famille de SoC.

Le système d'exploitation est Nucleus RTOS, fournissant l'ordonnancement des tâches, des files de messages IPC et un allocateur de mémoire basé sur des pools. Il n'y a pas de séparation des privilèges noyau/utilisateur, pas d'application d'unité de protection mémoire entre les tâches, et pas de 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 build analysée)

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

### 2.4 Approche d'analyse

Trois axes parallèles :

**Analyse statique.** Package 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
depuis la section de débogage du firmware à l'aide de l'outillage `mtk_bp` de NCC Group.

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

**Validation côté radio.** srsRAN 4G avec une boucle locale ZMQ — logiciel uniquement, sans
émission RF — a confirmé que la charge utile de test survit à l'encodage PHY NB-IoT et à la
livraison du bloc de transport.

---

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

### 3.1 Surface d'attaque pré-association

NB-IoT (Narrowband Internet of Things) est la version 3GPP Release 13, 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'une connexion RRC ne soit établie, un appareil recherchant un service
va :

1. Se synchroniser avec les signaux de timing de la cellule (NPSS/NSSS)
2. Décoder le Master Information Block 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é des noms de fonctions internes
complets dans toute la pile du modem — couche ERRC, gestion des canaux L1, sous-système IPC, et la
chaîne de gestionnaires NB-IoT BCCH — permettant une reconstruction de chaîne guidée par la sémantique.

Tous les noms de fonctions dans cet article proviennent des propres 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
}

Le flux B (écritures d'octets `sb`) 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 clamping à trois couches

| Couche | Fonction | Adresse | Clamp 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** |

N'importe quelle vérification unique à n'importe laquelle de ces couches 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 borne protocolaire prévue (8 entrées). Le firmware devait faire respecter la
borne de sûreté mémoire à chaque couche où le compteur devient un index ou une limite de boucle. Dans la
version vulnérable, le compteur voyageait 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 clampe.

---

## 6. La chaîne d'appel — 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 `[+0x99]` | Pertinence |
|---|---|---|---|
| Chemin A (ERRC → L1 IPC) | 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 compteur SI consommé par
`el1_ch_nbcch_start`. Comme son compteur 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'écrivain

La recherche par motif dans le firmware de toute instruction écrivant à l'offset `+0x99` a produit du bruit :
T1 (`sb` direct, ~100 résultats), T2 (base scindée, 5 résultats), 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` parce qu'ERRC utilise `errc_com_send_msg`. Une sonde d'émulation
a confirmé que l'écriture était côté ERRC : exécuter le harnais Unicorn depuis le dispatcheur L1 et
surveiller les écritures à l'offset `+0x99` du tampon n'a 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 spécifique SM-A145R ne semble pas emprunter le chemin de code NB-IoT vulnérable lors d'un fonctionnement normal en configuration de série, ce qui explique pourquoi l'émulation hybride et l'analyse statique ont été utilisées plutôt qu'une reproduction directe sur matériel.

**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` s'est exécutée sur de véritables octets de firmware MediaTek dans Unicorn Engine (MIPS32). L'instruction `sh` du firmware à l'adresse `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 exécutée entièrement nativement car le chemin de dispatch de la table de rappel RTOS au sein de `el1_ch_nbcch_cphy_cfg_req_
process` attendait des objets de tas Nucleus actifs que l'émulateur plat ne fournissait pas. Le gestionnaire de reprise (`el1_ch_nbcch_resume_req`) en Phase 2 lit uniquement depuis le contexte de canal résidant en BSS et n'emprunte pas ce même chemin de dispatch, ce qui explique pourquoi la Phase 2 s'est 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-falsification

Le harnais a appliqué 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 liée au 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 du bloc de transport, srsRAN 4G avec une boucle locale ZMQ (sans émission RF) a été utilisé. La charge utile était un vecteur délibérément non conforme — la contrainte ASN.1 SIZE sur `schedulingInfoList` a été assouplie pour autoriser 40 entrées, avec un décodage aller-retour pycrate confirmant le champ de comptage à l'octet 14.```
SIB1 received
SIB2 activated
exit 0

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

### 8.2 Pile d'appels```
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]

Une vérification 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 le binaire corrigé montre est une révision architecturale : le chemin de planification NBCCH a été repensé de sorte que le motif `si_count`-comme-borne-de-boucle n'existe plus nulle part dans le 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, vérification de limites manquante, RCE depuis une station de base malveillante, aucune interaction utilisateur — correspond à la description de la CVE et à l'enregistrement NVD.
- Le firmware corrigé supprime exactement les structures de code identifiées comme vulnérables.
- L'ID de correctif MOLY00720348 confirmé à partir du bulletin de MediaTek et du Android Security Bulletin (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 ce billet ne contient pas

Aucun exploit weaponisé. Aucun contenu binaire de firmware. Aucun octet de charge utile malformée. Aucune procédure étape par étape pour déclencher la vulnérabilité contre un appareil en fonctionnement. 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 de tas RTOS pour l'émulation complète de la Phase 1, configuration radio over-the-air — sont délibérément absentes.

### 11.2 Pourquoi la boucle locale ZMQ et l'émulation constituent l'approche éthique

La boucle locale ZMQ signifie qu'aucun signal n'a jamais été transmis par les ondes. 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 contenu 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 ou environnement radio spécifique. C'est une affirmation techniquement plus solide qu'un simple plantage matériel, et cela évite de déployer quoi que ce soit par les ondes.

### 11.3 Propriété intellectuelle 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 MediaTek et les formats de messages IPC sont décrits uniquement dans la mesure nécessaire pour expliquer la défaillance de sûreté mémoire. Ils ne sont pas publiés en tant que spécifications.

---