# eSIM / Java Card VM Exploitation

{{#include ../banners/hacktricks-training.md}}

## Overview
Wbudowane karty SIM (eSIM) są implementowane jako **Embedded UICC (eUICC)**, które działają na **Java Card Virtual Machine (JC VM)** na secure elemencie. Ponieważ profile i aplety mogą być dostarczane *over-the-air* (OTA) za pomocą Remote SIM Provisioning (RSP), każda wada związana z bezpieczeństwem pamięci wewnątrz JC VM natychmiast staje się zdalnym prymitywem wykonania kodu **wewnątrz najbardziej uprzywilejowanego komponentu urządzenia**.

Ta strona opisuje rzeczywiste pełne kompromitacje eUICC Kigen (Infineon SLC37 ESA1M2, ARM SC300) spowodowane brakiem kontroli bezpieczeństwa typów w bajtkodach `getfield` i `putfield`. Ta sama technika może być ponownie użyta przeciwko innym dostawcom, którzy pomijają weryfikację bajtkodu na karcie.

## Attack Surface
1. **Remote Application Management (RAM)**
Profile eSIM mogą zawierać dowolne aplety Java Card. Provisioning odbywa się za pomocą standardowych APDU, które mogą być tunelowane przez SMS-PP (Short Message Service Point-to-Point) lub HTTPS. Jeśli atakujący posiada (lub ukradnie) **klucze RAM** dla profilu, może zdalnie `INSTALL`/`LOAD` złośliwy aplet.
2. **Wykonanie bajtkodu Java Card**
Po zainstalowaniu, aplet wykonuje się wewnątrz VM. Brak kontroli w czasie wykonywania pozwala na uszkodzenie pamięci.

## The Type-Confusion Primitive
`getfield` / `putfield` powinny działać tylko na **referencjach obiektów**. W eUICC Kigen instrukcje nigdy nie weryfikują, czy operand na stosie jest referencją *obiektu* czy *tablicy*. Ponieważ słowo `array.length` znajduje się w dokładnie tym samym przesunięciu co pierwsze pole instancji normalnego obiektu, atakujący może:

1. Utworzyć tablicę bajtów `byte[] buf = new byte[0x100];`
2. Rzucić ją na `Object o = (Object)buf;`
3. Użyć `putfield`, aby nadpisać *dowolną* 16-bitową wartość wewnątrz sąsiedniego obiektu (w tym wpisy VTABLE / translacji wskaźników).
4. Użyć `getfield`, aby odczytać *dowolną* pamięć, gdy wewnętrzne wskaźniki zostaną przejęte.
```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 ...
```
Prymityw zapewnia **dowolne odczyty / zapisy** w przestrzeni adresowej eUICC – wystarczająco, aby zrzucić unikalny dla urządzenia klucz prywatny ECC, który autoryzuje kartę w ekosystemie GSMA.

## Workflow Eksploatacji End-to-End
1. **Enumeracja oprogramowania układowego** – Użyj nieudokumentowanego elementu `GET DATA` `DF1F`:
```
80 CA DF 1F 00   // → "ECu10.13" (wrażliwy)
```
2. **Instalacja złośliwego apletu OTA** – Wykorzystaj publicznie znane klucze profilu testowego TS.48 i przesyłaj fragmenty SMS-PP, które transportują plik CAP (`LOAD`), a następnie `INSTALL`:
```
// uproszczony łańcuch APDU
80 E6 02 00 <data>   // LOAD (blok n)
80 E6 0C 00 <data>   // INSTALL dla załadunku
```
3. **Wywołanie pomyłki typów** – Gdy aplet jest wybierany, wykonuje zapis-co-gdzie, aby przejąć tabelę wskaźników i wyciekać pamięć przez normalne odpowiedzi APDU.
4. **Ekstrakcja klucza certyfikatu GSMA** – Prywatny klucz EC jest kopiowany do RAM apletu i zwracany w kawałkach.
5. **Impersonacja eUICC** – Sk stolen para kluczy + certyfikaty pozwalają atakującemu autoryzować się na *dowolnym* serwerze RSP jako legalna karta (powiązanie EID może być nadal wymagane dla niektórych operatorów).
6. **Pobieranie i modyfikowanie profili** – Profile w postaci jawnej zawierają wysoce wrażliwe pola, takie jak `OPc`, `AMF`, klucze OTA, a nawet dodatkowe aplety. Atakujący może:
* Skopiować profil na drugi eUICC (przechwycenie głosu/SMS);
* Zmodyfikować aplikacje Java Card (np. wstawić złośliwe oprogramowanie STK) przed ponownym przesłaniem;
* Ekstrahować sekrety operatora do masowego nadużycia.

## Demonstracja Klonowania / Przechwytywania
Instalacja tego samego profilu na **TELEFONIE A** i **TELEFONIE B** skutkuje tym, że Centrum Przełączania Mobilnego kieruje przychodzący ruch do urządzenia, które ostatnio się zarejestrowało. Jedna sesja przechwytywania SMS 2FA Gmaila wystarczy, aby obejść MFA dla ofiary.

## Zautomatyzowany Zestaw Narzędzi Testowych i Eksploatacyjnych
Badacze wydali wewnętrzne narzędzie z komendą `bsc` (*Basic Security Check*), która natychmiast pokazuje, czy maszyna wirtualna Java Card jest wrażliwa:
```
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]
```
Moduły dostarczone z frameworkiem:
* `introspector` – pełny eksplorator VM i pamięci (~1.7 MB Java)
* `security-test` – ogólny aplet weryfikacji obejścia (~150 KB)
* `exploit`       – 100 % niezawodne kompromitowanie Kigen eUICC (~72 KB)

## Mitigacje
1. **Weryfikacja kodu bajtowego na karcie** – wymuszaj pełne śledzenie przepływu kontrolnego i danych zamiast tylko na szczycie stosu.
2. **Ukryj nagłówek tablicy** – umieść `length` poza nakładającymi się polami obiektów.
3. **Wzmocnij politykę kluczy RAM** – nigdy nie dostarczaj profili z kluczami publicznymi; wyłącz `INSTALL` w profilach testowych (omówione w GSMA TS.48 v7).
4. **Heurystyki po stronie serwera RSP** – ogranicz pobieranie profili na EID, monitoruj anomalie geograficzne, weryfikuj świeżość certyfikatu.

## Szybka lista kontrolna dla pentesterów
* Zapytaj `GET DATA DF1F` – podatny ciąg firmware `ECu10.13` wskazuje na Kigen.
* Sprawdź, czy klucze RAM są znane ‑> spróbuj OTA `INSTALL`/`LOAD`.
* Po zainstalowaniu apletu, przeprowadź brute-force na prostym typie rzutowania (`objarrconfusion`).
* Spróbuj odczytać prywatne klucze Security Domain – sukces = pełne kompromitowanie.

## Odniesienia
- [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}}