Hacktricks-skills esim-javacard-security

Security research and analysis for eSIM/JavaCard vulnerabilities. Use this skill when investigating eUICC security, analyzing Java Card VM type-safety issues, testing for Remote SIM Provisioning (RSP) vulnerabilities, or researching smart card exploitation techniques. Trigger for any queries about eSIM security, Java Card bytecode verification, GSMA TS.48 profiles, or smart card penetration testing.

install

source · Clone the upstream repo

git clone https://github.com/abelrguezr/hacktricks-skills

manifest: skills/generic-hacking/esim-javacard-exploitation/SKILL.MD

source content

eSIM / JavaCard Security Research

A skill for security researchers analyzing eSIM vulnerabilities, Java Card VM exploitation, and smart card security assessment.

When to Use This Skill

Use this skill when:

Investigating eUICC (Embedded UICC) security vulnerabilities
Analyzing Java Card Virtual Machine type-safety issues
Testing Remote SIM Provisioning (RSP) security
Researching smart card penetration testing methodologies
Understanding GSMA TS.48 profile vulnerabilities
Assessing eSIM cloning and hijacking risks
Reviewing Java Card bytecode verification bypasses

Core Concepts

Attack Surface

Remote Application Management (RAM)
- eSIM profiles embed Java Card applets
- Provisioning via APDUs tunneled through SMS-PP or HTTPS
- Compromised RAM keys enable remote
```
INSTALL
```
  /
```
LOAD
```
  of malicious applets
Java Card Bytecode Execution
- Applets execute inside the VM
- Missing runtime checks enable memory corruption
- Type confusion primitives lead to arbitrary read/write

The Type-Confusion Primitive

The

getfield

putfield

instructions should only operate on object references. Vulnerable implementations skip validation, allowing:

Create byte-array:
```
byte[] buf = new byte[0x100];
```
Cast to object:
```
Object o = (Object)buf;
```
(illegal but unverified)
Use
```
putfield
```
to overwrite 16-bit values in adjacent objects
Use
```
getfield
```
to read arbitrary memory via hijacked pointers

This provides arbitrary read/write in the eUICC address space.

Exploitation Workflow (Educational)

Step 1: Firmware Enumeration

Query undocumented

GET DATA

item

DF1F

to identify vulnerable firmware:

APDU: 80 CA DF 1F 00
Response: "ECu10.13" indicates vulnerable Kigen firmware

Step 2: Malicious Applet Installation

Abuse publicly-known keys from TS.48 Generic Test Profile (v≤6):

// LOAD command (block n)
80 E6 02 00 <data>

// INSTALL command
80 E6 0C 00 <data>

Step 3: Trigger Type Confusion

When the applet is selected, it performs write-what-where to hijack pointer tables and leak memory through APDU responses.

Step 4: Key Extraction

Private EC key is copied to applet RAM and returned in chunks via normal APDU responses.

Step 5: eUICC Impersonation

Stolen key pair + certificates enable authentication to any RSP server as a legitimate card.

Vulnerability Assessment Checklist

Pre-Engagement

Confirm authorization for testing
Document target eUICC model and firmware version
Verify legal compliance with GSMA regulations

Technical Checks

Query
```
GET DATA DF1F
```
for firmware string
Inspect loaded profiles for TS.48 test profiles (v≤6)
Check if RAM keys are publicly known
Attempt basic cast primitive (
```
objarrconfusion
```
)
Test for Security Domain private key exposure

Risk Indicators

Indicator	Risk Level	Action
Firmware `ECu10.13`	Critical	Vulnerable to type confusion
TS.48 v≤6 with static RAM keys	Critical	Directly exploitable
TS.48 v7 without RAM keys	Medium	Requires key leak
On-card bytecode verification	Low	Mitigated

Mitigations

Vendor-Level

On-card bytecode verification
- Enforce full control-flow & data-flow type tracking
- Not just stack-top validation
Hide array header
- Place
```
length
```
  field outside overlapping object fields
- Prevents type confusion via field offset collision
Harden RAM keys policy
- Never ship profiles with public keys
- Disable
```
INSTALL
```
  in test profiles
- TS.48 v7 removes RAM keysets

Operator-Level

RSP server heuristics
- Rate-limit profile downloads per EID
- Monitor geographic anomalies
- Validate certificate freshness
Profile lifecycle management
- Keep devices off legacy test profiles
- Apply OTA updates blocking applet loading with TS.48 v≤6
- Remove test profiles from factory images

Automated Testing

Basic Security Check (bsc)

The

bsc

command reveals Java Card VM vulnerability status:

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]

Test Modules

```
introspector
```
– Full VM and memory explorer (~1.7 MB Java)
```
security-test
```
– Generic verification bypass applet (~150 KB)
```
exploit
```
– Kigen eUICC compromise module (~72 KB)

Cloning/Hijacking Impact

Installing the same profile on multiple devices routes traffic to whichever device most recently registered. This enables:

Voice/SMS hijacking
2FA SMS interception
Profile cloning to secondary eUICCs
Java Card application patching (e.g., STK spyware insertion)
Operator secret extraction

References

Important Notes

This skill is for authorized security research only
Always obtain proper authorization before testing
GSMA regulations and local laws apply
Vulnerabilities described are publicly disclosed and patched in updated firmware
Focus on defensive measures and mitigation strategies