The Scary Truth About Your Phone's SIM Card

There is a computer inside your phone's SIM card. Not a metaphorical one, a literal one, with a CPU, a small operating system, persistent storage, a file system, and a network stack. It runs programs that your carrier loaded before you ever got the card. Those programs can read data, send SMS, open URLs, prompt you with menus, and in some cases take actions on your behalf. You cannot see them. You cannot audit them. You cannot remove them. You cannot stop them. This is not a bug. This is how every SIM card has worked since the late 1990s.

Check out the full video on my YouTube channel Divide and Quantum.

What Is Actually On A SIM

A modern SIM card is technically a UICC (Universal Integrated Circuit Card). It is a smart card chip, the same family of chip in a chip-and-PIN credit card, running a specialized Java virtual machine called Java Card. Typical specs:

• An 8-bit, 16-bit, or 32-bit CPU
• 256 KB to 1 MB of flash memory, sometimes more
• A few tens of KB of RAM
• A crypto coprocessor for RSA, ECC, AES, DES
• A serial interface (ISO 7816) and, on newer cards, an SWP interface to the NFC controller

The OS is small but real. It has a file system (defined by ETSI TS 102 221), a lifecycle manager, an authentication engine that holds your Ki (the long-term key that authenticates you to the cellular network), and a Java Card runtime that executes applets.

The applets are the interesting part. Your carrier decides which applets are preloaded. You have no say. They can be updated over the air via a carrier-signed SMS using a protocol called OTA (over-the-air), defined in ETSI TS 102 225/226. The update is received by the baseband, routed to the SIM, verified by the SIM's security domain, and applied. Your phone's OS is not involved and does not see any of it.

The SIM Application Toolkit

The thing that makes this more than a passive authentication chip is the SIM Application Toolkit (SAT, or STK). It is a protocol, defined in ETSI TS 102 223, that lets applets on the SIM issue proactive commands to the phone. Examples of commands the SIM can send to the phone:

• DISPLAY TEXT: show a message to the user
• GET INPUT: ask the user to type something
• SEND SHORT MESSAGE: send an SMS
• SET UP CALL: place a phone call
• LAUNCH BROWSER: open a URL in the phone's browser
• PROVIDE LOCAL INFORMATION: read location, IMEI, IMSI, battery, network state
• REFRESH: force the phone to reload SIM data
• OPEN CHANNEL: open a TCP or UDP socket on the phone's behalf

That last category is important. The SIM can ask the phone to act as a network proxy. The SIM speaks to a remote server through the phone's data connection. The phone's OS sees a connection and routes packets, but the contents are opaque.

The original justification was useful. In the 2000s, carriers used SAT to implement mobile banking menus, prepaid top-up, and value-added services at a time when most phones did not have apps. The SIM was the only place to put cross-device logic.

The problem is that the capability never went away, and in the 2010s, attackers noticed.

Simjacker and WIBattack

In 2019, researchers at AdaptiveMobile Security disclosed Simjacker. The attack targets an applet called S@T Browser (SIMalliance Toolbox Browser), a thin wrapper around SAT commands that was standardized in the early 2000s and preloaded on SIMs in dozens of countries, mostly in regions where SIM-based menus were common.

The attack works like this. An attacker sends a specially crafted binary SMS to the target. The SMS is routed directly to the S@T applet on the SIM, not displayed to the user. The SMS contains a sequence of SAT commands. The S@T applet, on many deployed SIMs, does not require the SMS to be signed, because the original threat model assumed that only the carrier would ever talk to it. The applet executes the commands.

The commands in Simjacker were:

1. PROVIDE LOCAL INFORMATION → read the phone's IMEI and cell tower ID
2. SEND SHORT MESSAGE → send the result back to the attacker via SMS

Result: the attacker geolocates the target to the level of a cell tower, silently, with no user interaction and no on-screen indication.

A follow-up attack, WIBattack, targeted the Wireless Internet Browser (WIB) applet from a different vendor, exploiting the same missing authentication. Between them, hundreds of millions of SIMs across 30+ countries were affected.

Neither attack exploits a bug in Android or iOS. The phone OS is behaving exactly as it is supposed to: obediently executing proactive commands from the trusted SIM. The vulnerability is entirely inside the SIM's applet, which the user cannot see or remove.

Why You Cannot Defend Against This

The security model is structurally bad for the user.

The phone's OS (Android, iOS) trusts the baseband processor. The baseband trusts the SIM. The SIM trusts whichever applets the carrier preloaded. The user is not part of this trust chain.

As an iOS or Android user, you cannot:

• List the applets on your SIM
• Remove an applet
• Block proactive commands from a specific applet
• See proactive commands as they happen
• Prevent the baseband from acting on them

On Android, some debugging ROMs expose raw AT commands and let you see baseband traffic, but for a normal user on a stock device, the SIM is opaque. On iOS, it is completely opaque.

The only real mitigations are at the carrier level:

• Filter binary SMS at the SMSC so that unsigned commands directed at applets are dropped
• Disable or remove vulnerable applets via OTA
• Require signing on all proactive SMS

Some carriers have done this. Many have not.

The eSIM Does Not Fix This

An eSIM is still a UICC. It is the same chip, just soldered to the phone instead of in a removable slot. It still runs Java Card. It still runs applets. It still speaks SAT. The physical form factor changed. The threat model did not.

What changed slightly is the provisioning flow. An eSIM profile is downloaded from the carrier under a protocol (SGP.22) that includes signature checking on the profile itself. That gives you stronger guarantees that the profile came from the carrier you think it did. It does not give you any visibility into what is inside the profile, or any ability to audit or remove applets once installed.

The Broader Systems Point

The SIM is a particularly clean example of a pattern you see across modern devices: a co-processor with its own OS, its own memory, and its own network access, running code you did not choose, trusted by the host OS you do control.

Other examples:

• The baseband processor, which runs a real-time OS, has DMA access, and handles the cellular protocol stack
• The secure enclave / Titan M / TrustZone on modern SoCs
• The Management Engine on Intel CPUs
• The BMC on server motherboards
• The firmware on SSDs, NICs, GPUs, and USB controllers

In each case, the main OS you think you are using is just one participant in a network of computers inside your device. The security of the whole is bounded by the security of the least-audited co-processor.

The SIM card is the oldest and most widely deployed member of that family. It predates smartphones. It predates mobile malware. It predates the modern app store security model. And it will almost certainly outlive them, because the cellular standards are slow to change and the installed base is enormous.

What You Can Actually Do

Realistically, not much.

• Use carriers that have publicly confirmed they filter binary SMS and have remediated S@T / WIB.
• For high-risk threat models, use devices with no cellular modem at all (Wi-Fi only tablets, GrapheneOS with the SIM removed) and route traffic over a trusted network.
• Be aware that SMS-based 2FA is particularly exposed: the SIM can read SMS, and SMS routing is controllable by the carrier anyway. Prefer TOTP or FIDO2.
• Accept that your phone is a computer with several smaller computers inside it, and that the one you hold in your hand is only one of them.

The scary truth about the SIM card is not that it is malicious. Almost all of them are fine. The scary truth is that the design assumes a trust relationship that does not match the modern threat environment, and the user has no seat at the table.