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

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,87 @@
+# eSIM / Java Card VM Exploitation
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Übersicht
+Embedded SIMs (eSIMs) werden als **Embedded UICC (eUICC)** Smartcards implementiert, die eine **Java Card Virtual Machine (JC VM)** auf einem sicheren Element ausführen. Da Profile und Applets *over-the-air* (OTA) über Remote SIM Provisioning (RSP) bereitgestellt werden können, wird jeder Speicherfehler innerhalb der JC VM sofort zu einem Remote-Code-Ausführungsprimitive **innerhalb der privilegiertesten Komponente des Geräts**.
+
+Diese Seite beschreibt einen realen vollständigen Kompromiss von Kigens eUICC (Infineon SLC37 ESA1M2, ARM SC300), verursacht durch fehlende Typ-Sicherheitsprüfungen in den `getfield` und `putfield` Bytecodes. Die gleiche Technik kann gegen andere Anbieter wiederverwendet werden, die die Überprüfung des Bytecodes auf der Karte weglassen.
+
+## Angriffsfläche
+1. **Remote Application Management (RAM)**
+eSIM-Profile können beliebige Java Card Applets einbetten. Die Bereitstellung erfolgt mit standardmäßigen APDUs, die über SMS-PP (Short Message Service Point-to-Point) oder HTTPS tunneln können. Wenn ein Angreifer die **RAM-Schlüssel** für ein Profil besitzt (oder stiehlt), kann er ein bösartiges Applet remote `INSTALL`/`LOAD`en.
+2. **Java Card Bytecode-Ausführung**
+Nach der Installation wird das Applet innerhalb der VM ausgeführt. Fehlende Laufzeitprüfungen ermöglichen Speicherbeschädigungen.
+
+## Der Typ-Verwirrungsprimitive
+`getfield` / `putfield` sollen nur auf **Objektverweisen** arbeiten. In Kigen eUICC validieren die Anweisungen niemals, ob der Operand auf dem Stack ein *Objekt* oder ein *Array*-Verweis ist. Da ein `array.length` Wort an genau demselben Offset wie das erste Instanzfeld eines normalen Objekts liegt, kann ein Angreifer:
+
+1. Ein Byte-Array erstellen `byte[] buf = new byte[0x100];`
+2. Es in `Object o = (Object)buf;` umwandeln.
+3. `putfield` verwenden, um *irgendeinen* 16-Bit-Wert innerhalb eines benachbarten Objekts (einschließlich VTABLE / ptr Übersetzungseinträge) zu überschreiben.
+4. `getfield` verwenden, um *willkürlichen* Speicher zu lesen, sobald interne Zeiger übernommen wurden.
+```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 ...
+```
+Die Primitive bietet **willkürlichen Lese-/Schreibzugriff** im eUICC-Adressraum – genug, um den gerätespezifischen ECC-Privatschlüssel zu dumpen, der die Karte im GSMA-Ökosystem authentifiziert.
+
+## End-to-End-Ausbeutungsworkflow
+1. **Firmware auflisten** – Verwenden Sie den nicht dokumentierten `GET DATA`-Eintrag `DF1F`:
+```
+80 CA DF 1F 00   // → "ECu10.13" (anfällig)
+```
+2. **Bösartiges Applet OTA installieren** – Missbrauch von öffentlich bekannten Schlüsseln des TS.48 Generic Test Profile und Push von SMS-PP-Fragmenten, die die CAP-Datei (`LOAD`) transportieren, gefolgt von einem `INSTALL`:
+```
+// vereinfachte APDU-Kette
+80 E6 02 00 <data>   // LOAD (Block n)
+80 E6 0C 00 <data>   // INSTALL für Load
+```
+3. **Typverwirrung auslösen** – Wenn das Applet ausgewählt wird, führt es den Write-What-Where aus, um eine Zeigertabelle zu übernehmen und Speicher durch normale APDU-Antworten zu leaken.
+4. **GSMA-Zertifikatschlüssel extrahieren** – Der private EC-Schlüssel wird in den RAM des Applets kopiert und in Stücken zurückgegeben.
+5. **Das eUICC impersonifizieren** – Das gestohlene Schlüsselpaar + Zertifikate ermöglichen es dem Angreifer, sich als legitime Karte bei *irgendeinem* RSP-Server zu authentifizieren (EID-Bindung kann für einige Betreiber weiterhin erforderlich sein).
+6. **Profile herunterladen und modifizieren** – Klartextprofile enthalten hochsensible Felder wie `OPc`, `AMF`, OTA-Schlüssel und sogar zusätzliche Applets. Der Angreifer kann:
+* Ein Profil auf ein zweites eUICC klonen (Voice/SMS-Hijack);
+* Java Card-Anwendungen patchen (z. B. STK-Spyware einfügen), bevor sie erneut hochgeladen werden;
+* Betreibergeheimnisse für großflächigen Missbrauch extrahieren.
+
+## Klon- / Hijacking-Demonstration
+Die Installation desselben Profils auf **PHONE A** und **PHONE B** führt dazu, dass das Mobile Switching Centre den eingehenden Verkehr an das Gerät weiterleitet, das sich zuletzt registriert hat. Eine Sitzung der Gmail 2FA-SMS-Abfangung reicht aus, um MFA für das Opfer zu umgehen.
+
+## Automatisiertes Test- und Exploit-Toolkit
+Die Forscher veröffentlichten ein internes Tool mit einem `bsc` (*Basic Security Check*)-Befehl, der sofort zeigt, ob eine Java Card VM anfällig ist:
+```
+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]
+```
+Module, die mit dem Framework geliefert werden:
+* `introspector` – vollständiger VM- und Speicherscanner (~1,7 MB Java)
+* `security-test` – generische Verifizierungs-Bypass-Applet (~150 KB)
+* `exploit`       – 100 % zuverlässiger Kigen eUICC-Kompromiss (~72 KB)
+
+## Minderung
+1. **On-Card-Bytecode-Verifizierung** – vollständige Kontrolle über den Kontrollfluss & Datenfluss-Tracking durchsetzen, anstatt nur den Stack-Top.
+2. **Array-Header verbergen** – `length` außerhalb von überlappenden Objektfeldern platzieren.
+3. **RAM-Schlüsselrichtlinie härten** – niemals Profile mit öffentlichen Schlüsseln ausliefern; `INSTALL` in Testprofilen deaktivieren (behandelt in GSMA TS.48 v7).
+4. **RSP-Server-seitige Heuristiken** – Download von Profilen pro EID drosseln, geografische Anomalien überwachen, Frische der Zertifikate validieren.
+
+## Schnelle Checkliste für Pentester
+* Abfrage `GET DATA DF1F` – verwundbare Firmware-Zeichenfolge `ECu10.13` weist auf Kigen hin.
+* Überprüfen, ob RAM-Schlüssel bekannt sind ‑> OTA `INSTALL`/`LOAD` versuchen.
+* Nach der Installation des Applets einfache Cast-Primitiven brute-forcen (`objarrconfusion`).
+* Versuchen, private Schlüssel des Sicherheitsbereichs zu lesen – Erfolg = vollständiger Kompromiss.
+
+## Referenzen
+- [Security Explorations – eSIM-Sicherheit](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-Spezifikation 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)
+
+{{#include ../banners/hacktricks-training.md}}