Defcon 21 - The Secret Life of SIM Cards on HackerTube: recommended by 3 Hacker News commenters across 3 separate months, 2014–2026.
talk · intermediate · evergreen
A DEF CON 21 talk by Karl Koscher and Eric Butler on how SIM cards work, including Java Card applets, the SIM toolkit and the OS running on the card. It shows how much control the network and the card have independent of the phone.
HN cites it as the go-to overview of what SIM cards can run and do, usually in threads about Java Card, SIM attacks or phone security.
“This video from defcon gives a good overview of what Java Card applets is”
12 Hacker News comments link this video. Each one links back to its thread.
There was one really good talk about from black hat or defcon [1] but there's also this [2] which seems more thorough so I'm gonna watch it too later. I happen to have a friend who writes software for simcards so that's what really was my main source. 1. [link] 2. ▶ this video
in “Apple said to be preparing for iPhones without SIM card slot in 2022” · View on HN
This video from defcon gives a good overview of what Java Card applets is, the limitations and what it can do: ▶ this video
in “What is AT&T doing at 1111340002?” · View on HN
Seeing the ShadySIM project mentioned on that page reminded me of this DEFCON talk, which talks about some of the capabilities of the SIM OS (some of them run Java!) and what power they grant you over phones if you have control over the underlying cell network (legitimately or otherwise). ▶ this video
in “This Blog is now hosted on a GPS/LTE modem” · View on HN
None of it matters. If the device has a SIM card (virtual or physical), it will execute commands sent over the network. It's required by the GSM/LTE standards. The best you can hope for is to have separate SoC for the OS and separate SoC for the GSM/LTE connectivity, but that means double the power consumption. See presentation at DEFCON21 about SIM cards: ▶ this video
in “Motorola GrapheneOS devices will be bootloader unlockable/relockable” · View on HN
also every SIM card. which is potentially quite a bit less benign - the baseband chip is this completely separate processor which the SOC can't see into, and the SIM card can snoop messages, send commands, and generally act like a secure enclave. It is/was? used for a couple banking systems for feature-phones like MPESA, where the app can run as a featurephone app with the menu item toolkits the phone provides. ▶ this video I think the e-sim idea is probably a net security benefit imo, apple has leveraged the carriers out of a fairly dangerous tool. I was thinking about what a program written to take advantage of Optane's persistent-memory model would have looked like, if you use it like RAM it's forever gonna be slow shitty RAM. Javacard seems to be the closest hit for that, in some ways.
in “I have written a JVM in Rust” · View on HN
This is all very confusing because you're mixing up your definitions of what precisely is "inactive" here. It's like the OSI model, there are multiple layers here representing different things. An IMEI is a representation of piece of equipment. A SIM is a representation of a subscriber (or, to be more precise, it's a cryptographic 2fa token that a subscriber carries), so a piece of equipment may have multiple SIMs and a subscriber may have multiple SIMs each associated with at most 1 piece of equipment (at a time). A SIM may be associated with a phone number, and may be associated with a plan which may be active or inactive. The data model is really: user <-one to many-> SIM token <-many to one-> IMEI And a phone number is an at-most-one feature of a particular SIM token. The fact that you didn't pay your bill this month doesn't mean your phone number is inactive - someone who dials that will get a "call cannot be connected" message because the phone network still knows it's you. The carrier just chooses not to connect your call, the phone number is still actually mapped underneath. And even if your number eventually gets reallocated, the fact that your SIM doesn't have a number associated with it is irrelevant - the network still knows you by your SIM and knows your phone by its IMEI. The phone number is really like a domain - it's a human-readable abstraction for the physical reality of the routing layer (SIM/IMEI). And the SIM is a representation of what user-token (a user
in “Requiring MFA on popular gem maintainers” · View on HN
> Postgres allows you to run python in the database, Oracle has support for java, Postgres can do limit 100, you can build subqueries using views, and reuse these in larger queries... Compiling down to fast bytecode is important and what I am thinking is more of a "pythonesque"/"javaesque" than an actual thing on a python VM / java VM. Limit the allowable syntax, it doesn't need to be full-spectrum python/java where you can recursively declare objects/etc, just what can be mapped into SQL. Give me Javacard+LINQ that compiles to bytecode with cursors. ▶ this video (OK not real javacard but... a minimal java equivalent that compiles to C bytecode, with LINQ, and with stack allocated variables/etc.) Views as subqueries are a good idea though, we don't hardly ever use them so I mostly don't think about it. It takes more authorization to modify a DB object (view) than program code, so we have a political bias against it... > Problem with query optimization is that it needs to be done at runtime, you can't optimize it in some procedure language easily. The optimal way to retrieve data depends on the number of records in your tables, the where clauses you use, the actual values you are filtering by, the records already in cache, etc. > 99% of all programmers would not be able to program better performing queries when doing this with a procedural language or streams expressions or it would take them way too long. That's probably fair but also leaves you at the mercy of the stats/query pla
in “Against SQL” · View on HN
Wonder if it's written itself into recovery. Or the SIM card/baseband - SIM card in particular usually includes functionality for triggering a sideload of apps (eg for carrier apps), sending notifications, etc into the main SOC so it fits. Maybe the second instance of SIM card malware ever. ▶ this video There are only so many places it can be hiding if it's surviving a factory reset. --Guy who is undoubtedly vastly underestimating the problem given that it's resisted AV vendors for a while
in “New 'unremovable' xHelper malware has infected 45,000 Android devices” · View on HN
When I recently watched this talk, ▶ this video , I wondered about that, that is if malicious STK app from network operator could execute AT commands on phone (and compromise device using commands from [link] ). But from what I gathered from cursory search, RUN AT COMMAND isn't supported by most devices. (ETSI TS 102 223 states "This clause applies if class "b" is supported by the terminal and enabled by the subscriber through the terminal. ")
in “SIM Vulnerability leads to information disclosure via malicious SMS” · View on HN
> Java is essentially never used for serious embedded work. I don't know whether it counts as "serious" to you, but literally billions of SIM cards and credit cards are running JavaCard: [link] ▶ this video
in “Go Is on a Trajectory to Become the Next Enterprise Programming Language” · View on HN
The SIM card is a separate OS that gets underneath the SOC's OS. It can run its own applets without the knowledge or permission of the SOC OS. ▶ this video The baseband is a completely different RTOS as well. And then there's also TrustZone running in the SOC as well.
in “US cell carriers are selling access to real-time phone location data” · View on HN
Indeed. And it runs today (on among other things) sim cards. See eg: "Defcon 21 - The Secret Life of SIM Cards" ▶ this video
in “The Elephant was a Trojan Horse: On the Death of Map-Reduce at Google” · View on HN