HackersOnBoard
3 HN recommenders · recommended in 12 months, 2014–2026
42:36 · 708K views · Nov 16, 2013
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.
12 comments from Hacker News
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
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
This video from defcon gives a good overview of what Java Card applets is, the limitations and what it can do: this video
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
> 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