Translated ['src/generic-hacking/esim-javacard-exploitation.md'] to fr

src/SUMMARY.md

@@ -77,6 +77,7 @@
 # 🧙‍♂️ Generic Hacking
 
 - [Brute Force - CheatSheet](generic-hacking/brute-force.md)
+- [Esim Javacard Exploitation](generic-hacking/esim-javacard-exploitation.md)
 - [Exfiltration](generic-hacking/exfiltration.md)
 - [Reverse Shells (Linux, Windows, MSFVenom)](generic-hacking/reverse-shells/README.md)
   - [MSFVenom - CheatSheet](generic-hacking/reverse-shells/msfvenom.md)

src/generic-hacking/esim-javacard-exploitation.md

@@ -0,0 +1,88 @@
+# eSIM / Exploitation de la VM Java Card
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Aperçu
+Les SIM intégrées (eSIM) sont mises en œuvre sous forme de **UICC intégrée (eUICC)** cartes intelligentes qui exécutent une **Machine Virtuelle Java Card (JC VM)** sur un élément sécurisé. 
+Étant donné que les profils et les applets peuvent être provisionnés *over-the-air* (OTA) via le Provisionnement à Distance de SIM (RSP), toute faille de sécurité mémoire à l'intérieur de la JC VM devient instantanément un primitive d'exécution de code à distance **à l'intérieur du composant le plus privilégié de l'appareil**.
+
+Cette page décrit un compromis complet dans le monde réel de l'eUICC de Kigen (Infineon SLC37 ESA1M2, ARM SC300) causé par l'absence de vérifications de sécurité de type dans les bytecodes `getfield` et `putfield`. La même technique peut être réutilisée contre d'autres fournisseurs qui omettent la vérification des bytecodes sur la carte.
+
+## Surface d'attaque
+1. **Gestion d'Application à Distance (RAM)**
+Les profils eSIM peuvent intégrer des applets Java Card arbitraires. Le provisionnement est effectué avec des APDUs standard qui peuvent être tunnélisés via SMS-PP (Short Message Service Point-to-Point) ou HTTPS. Si un attaquant possède (ou vole) les **clés RAM** pour un profil, il peut `INSTALL`/`LOAD` une applet malveillante à distance.
+2. **Exécution de bytecode Java Card**
+Après l'installation, l'applet s'exécute à l'intérieur de la VM. L'absence de vérifications à l'exécution permet la corruption de la mémoire.
+
+## Le Primitive de Confusion de Type
+`getfield` / `putfield` sont censés fonctionner uniquement sur des **références d'objet**. Dans l'eUICC de Kigen, les instructions ne valident jamais si l'opérande sur la pile est une *référence d'objet* ou une *référence de tableau*. Étant donné qu'un mot `array.length` se trouve à exactement le même décalage que le premier champ d'instance d'un objet normal, un attaquant peut :
+
+1. Créer un tableau d'octets `byte[] buf = new byte[0x100];`
+2. Le caster en `Object o = (Object)buf;`
+3. Utiliser `putfield` pour écraser *n'importe quelle* valeur de 16 bits à l'intérieur d'un objet adjacent (y compris les entrées de traduction VTABLE / ptr).
+4. Utiliser `getfield` pour lire de la mémoire *arbitraire* une fois que les pointeurs internes sont détournés.
+```java
+// Pseudo-bytecode sequence executed by the malicious applet
+// buf = newarray byte 0x100
+// o   = (Object) buf            // illegal but not verified
+// putfield <victimObject+offset>, 0xCAFE // arbitrary write
+// ... set up read-what-where gadgets ...
+```
+Le primitive fournit **une lecture / écriture arbitraire** dans l'espace d'adresses eUICC – suffisant pour extraire la clé privée ECC unique au dispositif qui authentifie la carte dans l'écosystème GSMA.
+
+## Flux de travail d'exploitation de bout en bout
+1. **Énumérer le firmware** – Utiliser l'élément `GET DATA` non documenté `DF1F` :
+```
+80 CA DF 1F 00   // → "ECu10.13" (vulnérable)
+```
+2. **Installer un applet malveillant OTA** – Abuser des clés publiquement connues du TS.48 Generic Test Profile et pousser des fragments SMS-PP qui transportent le fichier CAP (`LOAD`) suivi d'un `INSTALL` :
+```
+// chaîne APDU simplifiée
+80 E6 02 00 <data>   // LOAD (bloc n)
+80 E6 0C 00 <data>   // INSTALL pour le chargement
+```
+3. **Déclencher une confusion de type** – Lorsque l'applet est sélectionné, il effectue l'écriture-quoi-où pour détourner une table de pointeurs et divulguer de la mémoire à travers des réponses APDU normales.
+4. **Extraire la clé de certificat GSMA** – La clé EC privée est copiée dans la RAM de l'applet et renvoyée par morceaux.
+5. **Imiter l'eUICC** – La paire de clés volée + certificats permet à l'attaquant de s'authentifier auprès de *n'importe* quel serveur RSP en tant que carte légitime (le lien EID peut encore être requis pour certains opérateurs).
+6. **Télécharger et modifier des profils** – Les profils en texte clair contiennent des champs hautement sensibles tels que `OPc`, `AMF`, clés OTA et même des applets supplémentaires. L'attaquant peut :
+* Cloner un profil sur un second eUICC (détournement de voix/SMS) ;
+* Patch les applications Java Card (par exemple, insérer un spyware STK) avant de les re-télécharger ;
+* Extraire des secrets d'opérateur pour un abus à grande échelle.
+
+## Démonstration de clonage / détournement
+Installer le même profil sur **TÉLÉPHONE A** et **TÉLÉPHONE B** entraîne le Centre de commutation mobile à router le trafic entrant vers le dispositif qui s'est récemment enregistré. Une session d'interception de SMS 2FA Gmail suffit à contourner la MFA pour la victime.
+
+## Outil de test et d'exploitation automatisé
+Les chercheurs ont publié un outil interne avec une commande `bsc` (*Basic Security Check*) qui montre immédiatement si une VM Java Card est vulnérable :
+```
+scard> bsc
+- castcheck        [arbitrary int/obj casts]
+- ptrgranularity   [pointer granularity/tr table presence]
+- locvaraccess     [local variable access]
+- stkframeaccess   [stack frame access]
+- instfieldaccess  [instance field access]
+- objarrconfusion  [object/array size field confusion]
+```
+Modules expédiés avec le framework :
+* `introspector` – explorateur complet de VM et de mémoire (~1,7 Mo Java)
+* `security-test` – applet de vérification générique de contournement (~150 Ko)
+* `exploit`       – compromis Kigen eUICC 100 % fiable (~72 Ko)
+
+## Atténuations
+1. **Vérification du byte-code sur la carte** – appliquer un suivi complet du flux de contrôle et du flux de données au lieu de se limiter au sommet de la pile.
+2. **Cacher l'en-tête du tableau** – placer `length` en dehors des champs d'objet qui se chevauchent.
+3. **Renforcer la politique des clés RAM** – ne jamais expédier de profils avec des clés publiques ; désactiver `INSTALL` dans les profils de test (abordé dans GSMA TS.48 v7).
+4. **Heuristiques côté serveur RSP** – limiter le taux de téléchargements de profils par EID, surveiller les anomalies géographiques, valider la fraîcheur des certificats.
+
+## Liste de vérification rapide pour les pentesters
+* Interroger `GET DATA DF1F` – la chaîne de firmware vulnérable `ECu10.13` indique Kigen.
+* Vérifier si les clés RAM sont connues ‑> tenter `INSTALL`/`LOAD` OTA.
+* Après l'installation de l'applet, forcer le brute-force d'un type primitif simple (`objarrconfusion`).
+* Essayer de lire les clés privées du domaine de sécurité – succès = compromis total.
+
+## Références
+- [Security Explorations – eSIM security](https://security-explorations.com/esim-security.html)
+- [GSMA TS.48 Generic Test Profile v7.0](https://www.gsma.com/get-involved/working-groups/gsma_resources/ts-48-v7-0-generic-euicc-test-profile-for-device-testing/)
+- [Java Card VM Specification 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)
+
+{{#include ../banners/hacktricks-training.md}}