Layer 4 — UE / Android & SIM Level Attacks (4G/5G)

Overview

The User Equipment (UE) and its SIM card form the subscriber-side of the cellular stack. This layer covers attacks on:

• The Android modem interface (AT commands, RIL)
• SIM card security (SIMjacker, WIBattack, ADM key extraction, cloning)
• VoLTE/ViLTE protocol exposure
• Baseband firmware interface

With just an Android phone, you have access to a surprising attack surface — no USRP required for most of this layer.

Architecture Reference

flowchart TB
    APP["Android App Layer"]
    RIL["Android RIL\n(Radio Interface Layer)"]
    BB["Baseband Processor\n(Qualcomm MDM, Samsung Shannon, MediaTek)"]
    AT["AT Command Interface\n(/dev/ttyS*, /dev/smd*, /dev/ttySAC*)"]
    SIM["SIM Card (UICC)\npySIM-shell / SIMtrace2 / PC/SC reader"]

    APP --> RIL --> BB --> AT --> SIM

Threat Points

4.1 AT Command Interface

What it is: The baseband processor exposes a serial AT command interface to the application processor. Many commands are standardized (3GPP TS 27.007); many are vendor-specific and undocumented.

Access methods on Android:

# Via ADB (requires USB debugging + root or adb shell)
adb shell

# Common modem device paths:
ls /dev/ttyS*      # older devices
ls /dev/ttyUSB*    # USB modems
ls /dev/smd*       # Qualcomm SMD transport
ls /dev/gsmtty*    # Samsung/Exynos
ls /dev/ttySAC*    # some MTK devices

# Check RIL socket
ls /dev/socket/rild*

Standard AT commands (3GPP TS 27.007):

AT+CIMI        # Read IMSI from SIM
AT+CGSN        # Read IMEI
AT+CREG?       # Network registration status
AT+COPS?       # Current operator (PLMN)
AT+CGDCONT?    # PDP context (APN)
AT+CUSD=1,"*100#"  # Send USSD code
AT+CLAC        # List all supported commands (if enabled)
AT+CFUN=0      # Disable modem (DoS self)
AT+CFUN=1      # Enable modem
AT^SYSCONN?    # Qualcomm: connection type
AT+QGDCNT?     # Quectel: data counter

Vendor-specific / privileged commands (examples):

AT*ENAP         # Ericsson/Sony: network attach params
AT+XGENDATA     # Intel XMM: internal diagnostics
AT$QCPWRDN      # Qualcomm: power down
AT+REMOTESIM    # Some chipsets: remote SIM switching

Security implications:

• AT+CUSD allows USSD relay → potential USSD-based account takeover
• AT+CGDCONT manipulation → change APN → intercept data at rogue APN
• AT^SYSCONN / AT+COPS manipulation → force connection to specific cell

Tools:

• minicom / screen — serial terminal for AT commands
• ModemManager (CLI) — mmcli
• AT Modem Commander (Android app, root required)
• Custom Python: pyserial

import serial, time

port = serial.Serial('/dev/ttyUSB0', 115200, timeout=1)
port.write(b'AT+CIMI\r\n')
time.sleep(0.5)
print(port.read(100))  # returns IMSI

4.2 RIL (Radio Interface Layer) Attacks

What it is: Android's RIL daemon (rild) is the bridge between Android telephony frameworks and the baseband. It communicates with the baseband via a proprietary socket or serial interface.

Attack surface:

• RIL socket injection — if rild socket is accessible (/dev/socket/rild), send crafted RIL requests
• RIL response spoofing — modify responses from modem (requires root + Frida hooking)
• Fake RIL module — replace libril.so or intercept with LD_PRELOAD (requires root)

Useful for:

• Observing raw network registration events (cell changes, handover)
• Injecting fake signal strength / network type
• USSD manipulation at RIL layer

Tools:

• Frida — hook libril.so functions at runtime
• rild source (AOSP) — understand message formats
• rilanalyzer — log and replay RIL messages (research tool)

// Frida hook — intercept RIL_REQUEST_GET_IMSI
Java.perform(function() {
    var TelephonyManager = Java.use("android.telephony.TelephonyManager");
    TelephonyManager.getSubscriberId.implementation = function() {
        var imsi = this.getSubscriberId();
        console.log("[RIL] IMSI intercepted: " + imsi);
        return imsi;
    };
});

4.3 SIM Card Attacks

4.3.1 SIMjacker (CVE-2019-16256)

What it is: A vulnerability in the S@T (SIM Application Toolkit) browser, present on many SIMs deployed by operators. Attackers send a specially crafted SMS (binary OTA SMS) that executes commands on the SIM silently.

How it works:

1. Attacker sends SMS containing S@T Browser commands
2. SIM processes the OTA message without user notification
3. Commands can: request device location (via PROVIDE LOCAL INFORMATION), send SMS to attacker, make calls, launch browser

Why it works:

• SIM accepts OTA commands over SMS without cryptographic validation (many deployed SIMs)
• S@T browser enabled by default on vulnerable SIMs
• No user interaction required

Affected: Estimated 700M+ SIMs globally at disclosure (2019) across 30+ countries

Mitigation: Operator must push OTA update disabling S@T browser; device-level filtering of binary SMS

Testing on your own SIM:

# Check if your SIM has S@T browser
# Use pySIM-shell to inspect EF_SSTA and EF_UST on your SIM
pySIM-shell$ select ADF.USIM
pySIM-shell$ select EF.UST    # USIM Service Table — check bit 31 (S@T)
pySIM-shell$ select EF.SST    # SIM Service Table (2G SIM)

4.3.2 WIBattack

What it is: Similar to SIMjacker but targets the WIB (Wireless Internet Browser) application on SIM cards.

Same OTA SMS vector, same impact. Disclosed by Ginno Security Lab (2019) independently of SIMjacker.

4.3.3 SIM Cloning / IMSI Extraction

What it is: Extracting Ki (authentication key) from a SIM to clone it.

Methods:

• ADM key brute force: SIM files are protected by Administrative Key (ADM). Some operators use weak/default ADKs. With the ADK you can read/write Ki.
• COMP128v1 attack (legacy): Old 2G COMP128v1 SIM algorithm was vulnerable to ~150,000 chosen-challenge queries → full Ki recovery
• Physical extraction: Decapping SIM chip and reading flash (advanced)

Tools:

• pySIM-shell — communicate with SIM via PC/SC reader

# Install
pip install pySIM

# Connect to SIM (via USB PC/SC reader)
pySIM-shell$ connect -p 0  # PC/SC reader index 0

# Read basic SIM info
pySIM-shell$ select MF
pySIM-shell$ select DF.GSM
pySIM-shell$ select EF.IMSI
pySIM-shell$ decode   # decode IMSI from EF

# Read ICCID
pySIM-shell$ select EF.ICCID
pySIM-shell$ decode

# Try ADM authentication (if you know the ADK)
pySIM-shell$ verify_adm 0x1234567890123456

# After ADM unlock — read/write EF files
pySIM-shell$ select EF.Ki   # proprietary — may not be accessible

Tools needed: USB SIM card reader (e.g. Omnikey CardMan 3021, ~$15)

Legal note: SIM cards are "access devices" under 18 U.S.C. § 1029. Cloning a SIM card, extracting a Ki key with intent to duplicate a subscriber identity, or possessing a cloned SIM with intent to defraud are federal crimes carrying up to 15 years imprisonment. The COMP128v1 attack described applies only to legacy 2G SIMs and is presented as historical context. ADM key verification (verify_adm) is lawful only when performed on SIM cards you own and are authorized to administer (e.g., programmable test SIMs from a hobbyist SIM supplier).

What it is: Operators update SIM applets via binary SMS (OTA). The OTA mechanism uses SCP02/SCP03 (Secure Channel Protocol) for integrity and confidentiality.

Attack surface:

• Weak OTA keys (some operators use default test keys)
• SCP02 is older and has known weaknesses
• If OTA keys are known: can push malicious applets, delete applets, extract EF data

Tools:

• GlobalPlatformPro (gp.jar) — GlobalPlatform card management
• pySIM — OTA message construction/parsing

4.4 VoLTE / ViLTE Protocol Attacks

What it is: Voice over LTE uses IMS (IP Multimedia Subsystem) with SIP and RTP over the LTE data plane.

Attack surface:

4.4.1 SIP Signaling Exposure

• VoLTE SIP traffic passes through Ue → P-CSCF in cleartext (before TLS setup)
• SIP REGISTER, INVITE messages contain: IMSI/IMEI in P-Preferred-Identity header, phone number, codec preferences
• On rogue eNB: capture SIP messages before IPSec/TLS is established

4.4.2 RTP Media Interception

• If SIP is intercepted (via MitM), SDP body reveals RTP port/IP for media
• RTP (voice stream) is unencrypted in many VoLTE implementations unless SRTP is enforced
• On rogue eNB: forward SIP but passively capture RTP → decode voice with Wireshark/rtpdump

Legal note: Intercepting VoLTE voice streams (RTP) from third-party calls violates 18 U.S.C. § 2511 (Wiretap Act), which carries up to 5 years imprisonment per violation. The rtpdump/sox decode workflow shown in this section is only lawful when capturing traffic you generated yourself in a lab environment (e.g., a call between two UERANSIM UEs or two test phones on your own Open5GS IMS). Never use these commands on traffic from a production network or any call involving a third party.

4.4.3 VoLTE Billing Fraud

• Craft SIP INVITE with spoofed calling number
• If P-CSCF doesn't validate identity header against authenticated subscriber → caller ID spoofing
• Some implementations bill based on SIP headers, not authenticated identity

Legal note: Spoofing caller ID in SIP INVITE messages to alter billing or misrepresent identity on a production network constitutes wire fraud under 18 U.S.C. § 1343 (up to 20 years imprisonment) and unauthorized access under 18 U.S.C. § 1030 (CFAA). This section describes the vulnerability as a threat modeling scenario; it must only be tested in an isolated lab IMS environment you control end-to-end.

Tools:

• Wireshark with sip + rtp filters on GSMTAP interface
• rtpdump / sox — capture and decode RTP audio
• SIPp — SIP traffic generator / fuzzer
• Sngrep — SIP message flow visualizer

# Capture VoLTE SIP on rogue eNB (via srsRAN GSMTAP)
wireshark -i lo -k -f "udp port 4729" &

# Decode RTP audio from pcap
rtpdump -F audio -t 999 /127.0.0.1/5004 dump.pcap | sox -t raw -r 8000 -e a-law -c 1 - out.wav

4.5 Baseband Firmware Interface

What it is: The baseband processor runs its own OS/firmware (e.g., Qualcomm AMSS/MPSS, Samsung Shannon, MediaTek RTOS). It handles all radio protocol stacks independently of Android.

Attack surface:

• Qualcomm Diag interface (/dev/diag) — proprietary diagnostic protocol; exposes raw protocol logs, packet injection, memory read
• Samsung Shannon debug — QXDM-equivalent on Exynos/Shannon
• Over-the-air baseband fuzzing — send malformed RRC/NAS messages to real device to find crashes

Qualcomm Diag (QXDM):

# Access via ADB (requires root or special permissions)
adb shell ls /dev/diag

# Tools
# QXDM (Qualcomm proprietary — Windows)
# QPST (Qualcomm Provisioning & Sustaining Tool)
# SCAT (open-source Diag analyzer by Byeong-il Jeon)
# https://github.com/fgsect/scat

# Capture Diag messages with SCAT
python scat.py -t qc -d /dev/ttyUSB0 -l output.pcap

Baseband RCE research:

• Baseband is a high-value target — runs privileged, has direct radio access
• Past CVEs: Qualcomm MSM (CVE-2020-11292), Samsung Shannon (multiple)
• Fuzzing vectors: malformed SIBs, NAS messages, RRC via rogue eNB

Tools:

• BaseSAFE (academic) — baseband fuzzing framework
• FirmWire (Herr et al., NDSS 2022) — Samsung Shannon/MTK baseband emulator
• BaseSpec (Kim et al.) — differential analysis of baseband implementations

Android-Specific Test Checklist

[ ] Enable USB debugging (Settings → Developer options)
[ ] Enable root via Magisk (test device only)
[ ] Identify modem device path (ls /dev/tty* /dev/smd*)
[ ] Read IMSI, IMEI, ICCID via AT commands
[ ] Enumerate supported AT commands (AT+CLAC)
[ ] Test USSD relay via AT+CUSD
[ ] Install SIM reader app or use PC/SC reader for pySIM
[ ] Check EF.UST for S@T browser bit (SIMjacker check)
[ ] Capture baseband diagnostic output via SCAT/Diag
[ ] Hook RIL with Frida to observe registration events

Tools Summary

Key References

Next Layer

→ Layer 5: 5G-Specific Attacks — network slicing isolation bypass, SUPI de-anonymization, NRF API enumeration, O-RAN open interface security, AMF/SMF REST API exposure.