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.

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:
   • Clone a profile to a second eUICC (voice/SMS hijack);
   • Patch Java Card applications (e.g. insert STK spyware) before re-uploading;
   • Extract operator secrets for large-scale abuse.

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)

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 (addressed in GSMA TS.48 v7).
4. RSP server side heuristics – rate-limit profile downloads per EID, monitor geographic anomalies, validate certificate freshness.

Quick Checklist for Pentesters

• Query GET DATA DF1F – vulnerable firmware string ECu10.13 indicates Kigen.
• 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.

References

• Security Explorations – eSIM security
• GSMA TS.48 Generic Test Profile v7.0
• Java Card VM Specification 3.1