🤖 HackTricks / Esim Javacard Exploitation

eSIM / Java Card VM Exploitation

Overview

Embedded SIMs (eSIMs) are implemented as Embedded UICC (eUICC) smart-cards that run a Java Card Virtual Machine (JC VM) on top of a secure element.
Because profiles and applets can be provisioned over-the-air (OTA) via Remote SIM Provisioning (RSP), any memory-safety flaw inside the JC VM instantly becomes a remote code-execution primitive inside the most privileged component of the handset.

This page describes a real-world full compromise of Kigen’s eUICC (Infineon SLC37 ESA1M2, ARM SC300) caused by missing type-safety checks in the getfield and putfield bytecodes. The same technique can be re-used against other vendors that omit on-card byte-code verification.

Attack Surface

  1. Remote Application Management (RAM)
    eSIM profiles may embed arbitrary Java Card applets. Provisioning is performed with standard APDUs that can be tunnelled through SMS-PP (Short Message Service Point-to-Point) or HTTPS. If an attacker owns (or steals) the RAM keys for a profile, they can INSTALL/LOAD a malicious applet remotely.
  2. Java Card byte-code execution
    After installation, the applet executes inside the VM. Missing run-time checks allow memory corruption.

2024–2025 ecosystem changes

  • 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:

  1. Create a byte-array byte[] buf = new byte[0x100];
  2. Cast it to Object o = (Object)buf;
  3. Use putfield to overwrite any 16-bit value inside an adjacent object (including VTABLE / ptr translation entries).
  4. Use getfield to read arbitrary memory once internal pointers are hijacked.

// 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 ...
The primitive provides arbitrary read / write in the eUICC address space – enough to dump the device-unique ECC private key that authenticates the card to the GSMA ecosystem.

End-to-End Exploitation Workflow

  1. Enumerate firmware – Use undocumented GET DATA item DF1F: 
    80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
  2. Install malicious applet OTA – Abuse publicly-known keys of the TS.48 Generic Test Profile and push SMS-PP fragments that transport the CAP file (LOAD) followed by an INSTALL: 
    // simplified APDU chain
80 E6 02 00 <data>   // LOAD (block n)
80 E6 0C 00 <data>   // INSTALL for load
  3. Trigger type-confusion – When the applet is selected it performs the write-what-where to hijack a pointer table and leak memory through normal APDU responses.
  4. Extract GSMA certificate key – Private EC key is copied to the applet’s RAM and returned in chunks.
  5. Impersonate the eUICC – The stolen key pair + certificates let the attacker authenticate to any RSP server as a legitimate card (EID binding may still be required for some operators).
  6. Download and modify profiles – Plaintext profiles contain highly sensitive fields such as OPc, AMF, OTA keys and even additional applets. The attacker can:
  7. Clone a profile to a second eUICC (voice/SMS hijack);
  8. Patch Java Card applications (e.g. insert STK spyware) before re-uploading;
  9. 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.

Automated Test & Exploit Toolkit

The researchers released an internal tool with a bsc (Basic Security Check) command that immediately shows whether a Java Card VM is vulnerable: 

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 shipped with the framework: * introspector – full VM and memory explorer (~1.7 MB Java) * 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:

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 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 – 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 – 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.
  • 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