Merge pull request #2304 from HackTricks-wiki/research_update_src_generic-hacking_esim-javacard-exploitation_20260531_135717

Research Update Enhanced src/generic-hacking/esim-javacard-e...

Author: carlospolop

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

@@ -15,9 +15,10 @@ This page describes a real-world full compromise of Kigen’s eUICC (Infineon SL
    After installation, the applet executes inside the VM.  Missing run-time checks allow memory corruption.
 
 ### 2024–2025 ecosystem changes
-* **GSMA TS.48 v7.0 (18 Jun 2025)** removed public RAM keysets from the Generic Test Profile and blocks `INSTALL` unless randomized keys are provided; cached v≤6 profiles still expose static RAM keys and remain exploitable.
-* **GSMA AN‑2025‑07 (09 Jul 2025)** recommends on-card bytecode verification; most eUICCs still skip full verification so VM memory bugs stay reachable after applet install.
-* **Kigen OTA hardening (Jul 2025)** blocks applet loading when legacy TS.48 test profiles are active and adds runtime checks, but unpatched devices stay vulnerable.
+* **TS.48 v7.x rollout** – the public GSMA TS.48 repository now deprecates all Generic Test Profile versions `v1`–`v6`, tells testers to use `v7.0`, and notes that `v7.1` is only an editorial change. For pentests this matters because many labs, factory images and cached profiles still carry legacy TS.48 material.
+* **Security-driven profile restrictions** – public reporting around the `v7.0` change indicates new separation between **Certified** and **Test** eUICCs, deprecation of older public test profiles, and tighter rules around RAM / public credentials in certified-eUICC test scenarios. In practice, old cards and leaked test credentials remain the most valuable entry point.
+* **GSMA operator guidance** – 2025 guidance explicitly treats malicious Java Card installation through profile misuse as an ecosystem-level risk, but that does not remove the underlying VM bug from already deployed cards.
+* **Vendor OTA mitigations** – Kigen publicly stated that OTA mitigations and a security bulletin were issued in July 2025, but researchers still observed vulnerable cards outside the narrow product descriptions from the bulletin. Treat vendor model lists as hints, not as proof that a target card is safe.
 
 ## The Type-Confusion Primitive
 `getfield` / `putfield` are supposed to operate only on **object references**.  In Kigen eUICC the instructions never validate whether the operand on the stack is an *object* or an *array* reference.  Because an `array.length` word lives at the exact same offset as the first instance field of a normal object, an attacker can:
@@ -55,6 +56,12 @@ The primitive provides **arbitrary read / write** in the eUICC address space –
    * Patch Java Card applications (e.g. insert STK spyware) before re-uploading;
    * Extract operator secrets for large-scale abuse.
 
+### Persistence & Post-Exploitation Targets
+Once arbitrary read / write exists, the attacker is not limited to a one-shot ECC key dump:
+* **Stealthy firmware patching / backdoor ideas** – Security Explorations described a post-exploitation scenario where normal APDU handlers (for example `GET DATA`) are patched so the card returns sensitive material without re-running the whole exploit chain.
+* **Profile tampering** – The researchers explicitly verified that a downloaded profile can be modified offline, loaded into another eUICC and still operate for calls / SMS while carrying an injected custom Java STK app.
+* **Secret harvesting order** – In practice, dump the eUICC identity key first, then operator material such as `OPc`, `AMF`, OTA keysets and sensitive applets. Losing OTA keys may be as damaging as stealing the subscriber profile itself.
+
 ## Cloning / Hijacking Demonstration
 Installing the same profile on **PHONE A** and **PHONE B** results in the Mobile Switching Centre routing incoming traffic to whichever device most recently registered.  One session of Gmail 2FA SMS interception is enough to bypass MFA for the victim.
 
@@ -74,25 +81,40 @@ Modules shipped with the framework:
 * `security-test` – generic verification bypass applet (~150 KB)
 * `exploit`       – 100 % reliable Kigen eUICC compromise (~72 KB)
 
+## Lab Validation Without OTA
+If you have a lab card or removable UICC with card-management credentials, you can validate the same applet-loading path locally before moving to SMS-PP / HTTPS delivery:
+
+```bash
+verifycap -target 3.1.0 exports/*.exp poc.cap -outfile cap.hashes
+pySIM-shell (00:MF)> select ADF.ISD
+pySIM-shell (00:MF/ADF.ISD)> establish_scp02 --key-dek <DEK> --key-enc <ENC> --key-mac <MAC> --security-level 1
+pySIM-shell (SCP02[01]:00:MF/ADF.ISD)> install_cap ./poc.cap --install-parameters-non-volatile-memory-quota 255 --install-parameters-volatile-memory-quota 255
+```
+
+`verifycap` only proves that the CAP is structurally valid against the expected export files. It does **not** protect a target whose VM still lacks run-time type checks. This is useful in practice because it separates **CAP formatting mistakes** from **target-side bytecode verification failures** before you burn OTA attempts or risk key lockout.
+
 ## Mitigations
 1. **On-card byte-code verification** – enforce full control-flow & data-flow type tracking instead of stack-top only.
 2. **Hide array header** – place `length` outside of overlapping object fields.
-3. **Harden RAM keys policy** – never ship profiles with public keys; disable `INSTALL` in test profiles (TS.48 v7 removes RAM keysets).
+3. **Harden RAM keys policy** – never ship profiles with public or reusable credentials; constrain or disable `INSTALL`/`LOAD` in test profiles and migrate to the `TS.48 v7.x` handling model.
 4. **RSP server side heuristics** – rate-limit profile downloads per EID, monitor geographic anomalies, validate certificate freshness.
-5. **Keep devices off legacy test profiles** – apply the July 2025 OTA that blocks applet loading with TS.48 v≤6 or remove the test profile from factory images.
+5. **Keep devices off legacy test profiles** – retire / remove `TS.48 v≤6` material, apply vendor OTA fixes, and avoid shipping factory images with leftover test profiles.
 
 ## Quick Checklist for Pentesters
-* Query `GET DATA DF1F` – vulnerable firmware string `ECu10.13` indicates Kigen.
-* Inspect loaded profiles: TS.48 test profiles with static RAM keys (v≤6) are directly exploitable; v7 without RAM keys need a new key leak.
+* Query `GET DATA DF1F` – `ECu10.13` is a known vulnerable Kigen string, but do **not** assume other returned strings are safe without testing.
+* Inspect loaded profiles: legacy TS.48 material and any reusable test credentials are the most valuable entry points; `v7.x` reduces exposure, but cached / preloaded older profiles still matter.
 * Check if RAM keys are known ‑> attempt OTA `INSTALL`/`LOAD`.
-* After applet installation, brute-force simple cast primitive (`objarrconfusion`).
-* Try to read Security Domain private keys – success = full compromise.
+* If OTA is unavailable, reproduce locally through ISD access and a secure channel (`SCP02`/equivalent) to confirm that the card accepts your CAP and that failures are due to target-side checks, not packaging mistakes.
+* After applet installation, brute-force simple cast primitive (`objarrconfusion`) and prioritize Security Domain / eUICC identity keys before moving to operator secrets.
+* Treat vendor advisories as incomplete coverage; run `bsc` or a minimal object/array confusion probe even on cards that do not exactly match the public bulletin wording.
 
 ## References
 - [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/)
 - [GSMA AN-2025-07 Preventing misuse of an eUICC Profile](https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/an-2025-07-preventing-misuse-of-an-euicc-profile-and-installation-of-malicious-java-card-application-v1-0/)
 - [The Hacker News – eSIM vulnerability in Kigen eUICC (July 2025)](https://thehackernews.com/2025/07/esim-vulnerability-in-kigens-euicc.html)
 - [Java Card VM Specification 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)
+- [GSMA public TS.48 Generic eUICC Test Profile repository](https://github.com/GSMATerminals/Generic-eUICC-Test-Profile-for-Device-Testing-Public)
+- [Osmocom pySIM – Installing Java Card applets](https://downloads.osmocom.org/docs/pysim/master/html/cap-tutorial.html)
 
 {{#include ../banners/hacktricks-training.md}}