26 ms·
What is AT&T doing at 1111340002?
- beeforpork 5y agoWhy is this number even on the list of SMS activities? Isn't that list compiled and issued by AT&T? Couldn't they just hide those target SMS numbers because they are, well, they could say, needed for technical implementation of SMS processing? It puzzzles me that they list these and afterwards do not tell what they really are.
- rwmj 5y agoPresumably when AT&T is answering a court subpoena they have a duty to supply complete information, and in any case the legal and technical parts of the company don't talk to each other much.
- mensetmanusman 5y agoThis must be why the carriers are resistant to phones going to e-sims.
- ChrisMarshallNY 5y agoIt should be interesting to see what voice-sent messages will do to "driving while txting" charges/lawsuits. I have an iPhone. I often send "Siri-texts" while driving ("Hey Siri, send a text to my wife, saying that I will be home in fifteen minutes."). There's no way to tell, upon reviewing the conversation, whether or not the text was sent by hand, or by voice.
- thrwyoilarticle 5y agoYet another win for Android users whose wives receive: 'Only way home no change on my way home yes send' No jury would convict.
- robniep 5y agoiMessages dictated through Siri are labeled as “Sent by Siri” for recipient. I’m not sure why Apple doesn’t display it for the sender.
- marcellus23 5y agoYep, there must be some kind of flag on the message payload to indicate Siri dictation. I wonder if that flag gets sent through SMS at all though, if the recipient is not on iMessage. My guess is there’s nothing in the SMS spec for arbitrary user data like that, but maybe I’m wrong.
- deleted 5y ago[deleted]
- WaitWaitWha 5y agoIt is always a pleasure to watch the young ones rediscover the world. :D Yes, carriers should be more transparent. Yes, even in general IT circles, this is not well known. This is known and not surprising in digital forensics circles. You should have seen the SS7 shenanigans! I have a special corner in my heart for AT&T. The dark, dank, where all-my-monsters-live corner. Once, I have asked them to send me telco logs, they sent me 30 some CDs with the logs, but only origination details. Then, on further legal nudging they send me the other half, again in 30 some CDs. 60 CDs. They didn't even fill the discs, so the entire DB ended up to be ~17GB.
- unethical_ban 5y agoThis is something at home in the pages of 2600 Magazine. I didn't know the SIM could send things without the main OS knowing. Could that SimTrace2 device could be used as a kind of firewall to prevent the SIM from acting independently of the phone?
- Isamu 5y ago> SIMs can send SMS on their own using a feature called “proactive MO-SMS” So many interesting tidbits in this article. This is what I come to HN for.
- rvnx 5y agoI'm not sure why this would make the suspect innocent ? Couldn't it be the situation that the person was doing an update and that distracted him during driving ?
- rvnx 5y agoor even changing the SIM card and putting it into another phone while driving ?
- jaclaz 5y agoChanging a mini/micro/nano SIM, removing it from one phone to insert it in another one while driving would be IMHO the "essence" of distracted driving, BUT in this specific case it was an (automatic? or previous?) update, from the article: >In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message. The "recently" is "vague" enough, as we don't know how much time passes after tyhe update for the SMS to be sent by the SIM, it could be milliseconds but as well several minutes or even hours.
- avs733 5y agoBoth of those are hypotheticals the other side would have to provide some evidence to support in court The investigation here was grounded in an attorney reading a report and saying “look person sent a text message at time x just before crash” and a forensic analysis instead showing that the SIM card sent the message not the person. That debunks the claim of distracted driving based on the text message timing. That’s the point, if they have evidence someone was swapping sims or interacting with the phone to run and update that’s an entirely separate matter
- emodendroket 5y agoI have to say that someone swapping SIM cards or initiating a phone update while driving also seems pretty improbable.
- 5y ago
- 0cVlTeIATBs 5y agoWhen I read about "binary blobs" present in electronics like in a SIM, a baseband processor, or DDR memory controller or CPU management engine, the risks they pose seem distant. This opens my eyes a bit to that they actually do phone home, hidden from and unblockable by the OS.
- jcun4128 5y ago> binary blobs Was a concern with Pinephone but doesn't seem to be the case anymore from what I saw. (referring to modem)
- tmzt 5y agoDoes it allow disabling STK apps out of the box or just with modified Linux on the Quectel? Are there any details?
- jcun4128 5y agoI don't know about that, here is more info: https://www.pine64.org/2020/01/24/setting-the-record-straight-pinephone-misconceptions/ https://www.pine64.org/2020/01/24/setting-the-record-straigh... > In short, unless you explicitly send data to the modem, it is never in contact with the blobs running inside it. The modem cannot send any data to the phone unless phone is willing to receive it I guess there are some legal concerns with open source modems http://wiki.openmoko.org/wiki/Open_GSM_modem http://wiki.openmoko.org/wiki/Open_GSM_modem
- lxgr 5y agoYou can't disable STK applications: They are an integral part of the SIM card. If anything, you could hide the user-facing icon, but that wouldn't do anything about any background processing the applications might be doing. However, they can only interact with the baseband in any case: While that still allows extensive tracking and potential mischief (like making expensive calls on your behalf), this is nothing your phone provider can't already do, i.e. knowing where you are and bill you arbitrary amounts for services you might not have initiated (when on postpaid).
- nulbyte 5y ago> what a telecom engineer would call an “NANP E.164”. NANP and E.164 are standards. NANP stands for North America Numbering Plan. E.164 is the international analog to NANP for public numbers. No telecom engineer would call a number an "NANP E.164." The number of a network element like an SMSC is simply called an address.
- daneel_w 5y agoAs a former software developer in telecom who worked a lot with SMPP, I'd just call it a special-purpose MSISDN.
- nulbyte 5y agoThat sounds entirely reasonable. I just wish authors would stop trying to add random (and wrong) technical information to sound cool. The topic was interesting on its own without embellishment.
- djbusby 5y agoAuthor is in Romania, and those two items are each unique links to their respective Wikipedia articles. It's not embellishments, it's information
- fortran77 5y agoIt's interesting that this message even came up when the user's messages were subpoenaed. This was not in the set of "user messages" and a case could be made for not including it at all.
- daneel_w 5y agoI bet they bill for it, on purpose, like with so many other "mystery charges". It's after all hundreds of millions of dollars per year worth.
- KennyBlanken 5y agoNot sure why you got downvoted. All the carriers make a lot of money on charges related to subpoenas and warrants from LEO.
- easton 5y agoI was wondering how AT&T knew I got a new phone when I just moved my SIM over. That seems like a over complicated way to do that. Seems like when it does the initial handshake with the network the different IMEI would be enough (unless this is the initial handshake).
- kevingadd 5y agoJust looking at the IMEI would require AT&T to look stuff up in a database, this way the SIM itself can report the phone change instead
- emodendroket 5y agoThis seems like a terrible series of individually reasonable decisions that could easily lead to wrongful legal outcomes.
- tata71 5y agohttps://grapheneos.org/faq#cellular-tracking https://grapheneos.org/faq#cellular-tracking
- rsync 5y agoEven in relatively technical circles, like HN, many people are not aware of this and I use every opportunity I have to reiterate: A SIM card is a full blown computer with its own CPU and memory. Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time. This means that your "phone" is actually three different computers running in concert - the actual phone itself (iOS or Android or Symbian), the baseband processor running the baseband code, and the SIM card.
- throwaway9870 5y agoMany years ago, I worked on a serial link (think SATA, PCIe, USB 3, etc.) that had a small embedded processor to self test the link, perform analog component calibration, link equalizer calibration, and even make an eye diagram for link characterization. We could patch it with a few instructions over the JTAG port. There are way more processors in ICs than you would ever imagine.
- criddell 5y ago> Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time. Is that equally true of SIM cards and eSIMs? I'm in the process of setting up a new T-Mobile phone and they say they support eSIM but they are really pushing me to use a traditional SIM card. I've been wondering why they care.
- matheusmoreira 5y ago> A SIM card is a full blown computer with its own CPU and memory. Yeah. They even run Java, that was the most surprising fact. > Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time. So what can this code do? Can my phone be compromised somehow?
- bitexploder 5y agoMore really. Secure Enclave on iOS is its own computer as well.
- 5y ago
- rootsudo 5y ago" The point here is that the cellphone literally has a mind of its own, in fact multiple “minds”, including in the SIM. These various minds might not even be talking to each other, and just because a phone did something, that doesn’t mean that user caused it." Yes, baseband, modem f/w and the operating system work together but don't have to talk to one another. A great read about be REX, from Qualcomm that goes into more detials - https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attachments/2022_11-ccc-qcombbdbg.pdf https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attach... All the fun Qualcomm PDF's seem to be missing from the net now, but there were more official/confidental PDF's that went into details besides this: https://en.wikipedia.org/wiki/REX_OS https://en.wikipedia.org/wiki/REX_OS BUt even reading from the old dead CDMA2000/eVDO standard you can see more of this too - https://ftp.unpad.ac.id/orari/library/library-ref-eng/ref-eng-2/physical/wireless/CDMA-Qualcomm/CDMA%20UMTS%20University%201xEV-DO%20Overview.pdf https://ftp.unpad.ac.id/orari/library/library-ref-eng/ref-en... And more on "what is a qualcomm chipset" https://ftp.unpad.ac.id/orari/library/library-ref-eng/ref-eng-2/physical/wireless/CDMA-Qualcomm/QUALCOMM%20CDMA%20Technologies%20Presentation.pdf https://ftp.unpad.ac.id/orari/library/library-ref-eng/ref-en... Yes, these links are not for GSM, but Qualcomm makes GSM and these carry over as a standard, and these 10-15yr old slides are amazing and should be archived too - they used to be public even on Qualcomm sites too. But thank you for the https://yatebts.com/ https://yatebts.com/ link - that is so cool, what I do with diagnostic and fun tinkering is with Qualcomm Tools that I no longer have access too. QPST, QXDM, etc.
- userbinator 5y agoWhenever I think the Internet protocol stack is too complex, I take a glance through the (also freely available) 3GPP specifications to refresh my perspective. They are so thick and dense it's a miracle that everything works, and I remind myself that people came up with all of it and there are probably experts who know far more than I ever will about that area. Nonetheless, I'm not surprised that they are full of little-known features like this.
- dilyevsky 5y agoThey are likely thick and dense on purpose tho - the cartel doesn’t want more competition
- boppo1 5y agoWho even has infrastructure to compete?
- BelenusMordred 5y agoBaseband chips and sim cards aren't infrastructure, but you still can't compete because getting permission to run one on modern networks is financially well out of reach for most. This is why open source inspectable firmware simply doesn't exist for these things. All we currently have is leaked 2G and 3G source code for people to build their own off, most notable would be omsocombb
- exikyut 5y ago> leaked "License: Affero GPLv3 for all cellular software, GPLv2+ for some remaining software (libosmocore, OsmoPCU, OsmoSTP, OsmoGGSN)[1]" (https://en.wikipedia.org/wiki/Osmocom https://en.wikipedia.org/wiki/Osmocom) O.o?
- userbinator 5y agoI think that comment may be referring to the leaked Mediatek baseband source. That is capable of 3G/HSPA+ at least, maybe LTE.
- walterbell 5y agoFollow-up article by same researcher, including Verizon and T-Mobile SIMs, https://medium.com/telecom-expert/more-proactive-sims-f8da2ef8b189 https://medium.com/telecom-expert/more-proactive-sims-f8da2e... > Of the five tier-1 SIMs I just have “laying around”, four of them proactively send messages or initiate connections through the cellular modem. Since these operations are happening between the SIM and the baseband processor, they are probably completely undetectable from the application processor and its Android/iOS/whatever software. > I hope this is the start of a much larger exploration of proactive SIMs from around the world.
- mschuster91 5y ago> I hope this is the start of a much larger exploration of proactive SIMs from around the world. I fear that the rise of eSIM modules will make that research ever more complex. In the worst case we'll either see BGA chips with vias to the BB chipset that can't be probed without extensive reflow work (which, in turn, may be impractical/too risky to do in scenarios where the module or the phone is evidence in court) or, even worse, eSIM as part of the BB chip or SoC.
- mdaniel 5y agoOr in keeping with the URL scheme used by the submitted link: https://scribe.rip/telecom-expert/more-proactive-sims-f8da2ef8b189 https://scribe.rip/telecom-expert/more-proactive-sims-f8da2e...
- pugworthy 5y agoClearly you can set it somehow, but is is hardwired? Or changeable? What if I buy a phone from AT&T and move to Verizon, does it still talk to AT&T or now Verizon? It would be an interesting security hole if one could modify the destination number and have it just send to a third party.
- jfrunyon 5y agoThis is about where you bought the SIM from, not where you bought the phone from.
- desktopninja 5y agoTo me the process sounds like a regular ping and registration process. After all SMS was designed as a "ping protocol" and someone with a bright idea monetized it! #respect
- 14 5y agoReminds me of how I ended up with a U2 album on my iPhone. I never put those files there not asked for them or gave permission. Made me wonder what else could they plant on my phone.
- dang 5y agoWe detached this subthread from https://news.ycombinator.com/item?id=29136253 https://news.ycombinator.com/item?id=29136253.
- nucleardog 5y agoI mean, you're talking about a bit of a different thing here--something done by the operating system and hardware vendor. So the answer would be "literally anything". Apple could push an update tomorrow that bricked your phone, turned it into a listening device, caused it to _only_ play that U2 album, etc. Ditto for Google (Android), Microsoft (Windows), etc.
- boramalper 5y agoWould eSIM[0] improve the state of affairs with respect to privacy? On the one hand, as SIM circuits are now being shipped with phones, I can imagine the manufacturers having the opportunity, for the first time ever, to control the operations of a SIM such that it’s no longer a black-box. On the other hand, due to legislative and practical reasons, eSIM modules would likely be no different than those black-box baseband processors with the further downside than we would also become unable to intercept the communication between a SIM (whose circuitry is now embedded) and a phone. I would love to read the answers of those who are more knowledgeable on the subject. [0] https://en.wikipedia.org/wiki/ESIM https://en.wikipedia.org/wiki/ESIM
- mike_d 5y agoeSIMs are just the SIM chip implemented in a surface mount component soldered directly onto the board. The only difference is some limited parts of the cards memory are not write protected so it can be provisioned from software.
- b112 5y agoMeaning it is easier to hack, and also, debug/monitor, for now it is harder to place a device between sim and phone, as in this article.
- lxgr 5y ago> some limited parts of the cards memory are not write protected This is a huge oversimplification. The card is running software that allows downloading and installing new profiles, but it will perform cryptographic validation of any payload handed to it. Even if a SIM profile passes that validation, the resulting SIM application will be instantiated with limited privileges on the smart card (which is arguably quite powerful since it matches that of SIM applications on physical SIMs).
- zinekeller 5y agoA SIM Card* is a ISO card running a variant of JavaCard OS with standard APIs mandated by GSMA or 3GPP (despite it's already 5G) implemented, but carriers can (and do) add internal features for their use, to the point that some weird SIMs (no longer seen today) could also function as a debit card¤. Think of it as roughly similar to the POSIX compatibilty between Linux, macOS and *BSD, while having widly different capabilities tacked on. eSIMs just remove the physical ISO card package and put it instead into a dedicated chip inside your phone, so in theory and in practice it could do anything a regular SIM can do. * To be fair, I'm not familiar with how CDMA networks handle this, but this is irrelevant in the sense that CDMA (depending on the carrier) is dying or even dead already (in favour of LTE et al.). ¤ Payment cards and original SIM cards are ISO/IEC Card ID-1, the "mini" SIM cards are ISO/IEC Card ID-000, and micro and nano SIM cards are non-ISO additions by 3GPP.
- kylehotchkiss 5y agoThis type of stuff makes keeping phone in a faraday bag carrier when not using it seem much more appealing. Pacsafe sells a nice one (or used to?) for like $40-50.
- runnably 5y agoThis is a very well-written post! I don't know much about telecom stuff, but I didn't need to to understand this.
- kaycebasques 5y agoThe author used a nice trick at the beginning of each section: phrasing the main idea of the section as a question and then answering that question.
- C19is20 5y agoAlso, the tldr is at the beginning!
- Scoundreller 5y agoNow somebody needs to create a shim/blocker board. Some shims already exist that intercept phone<->SIM comms for carrier unlocking and ??? https://www.geveypro.com/ https://www.geveypro.com/ https://www.dhgate.com/product/ios14-x-5g-unlocking-turbo-sim-mksd-iccid/652561200.html https://www.dhgate.com/product/ios14-x-5g-unlocking-turbo-si...
- mike_d 5y agoThere are all sorts of carrier specific messages that phones communicate. Carriers have systems that detect anomalous activity and blacklist them from towers because they assume the handset is broken and they don't want it to cause problems for other subscribers.
- numair 5y agoAhh this is so useful that it's at the top of HN. We've (probably) arrived at one of those "hidden" dominant operating systems out there in the world: JavaCard OS. It's not just (probably) in your cell phone SIM, it's also (probably) in your credit cards. Add all of those devices up, and you realize that, in a weird way, if aliens were to inspect the activity of humans, they'd say, "the humans seem to be using some sort of weird thing they call 'JavaCard OS' to run their society." If anyone is a JavaCard OS master, shoot me an email - numair@numair.com. I'm having some IC card issues that could use some external input... In terms of the linked article, I think this part makes it clear what's going on, if we are to take an innocent view on things: > After the lab work, deposition of an AT&T employee revealed that the only other trigger is a firmware update of the baseband processor. That is also consistent with the SIM requesting the IMEISV, since the “SV” part means “software version”, and it is updated every time the baseband processor loads new firmware. In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message. If I was a network engineer, I'd probably want a way to figure out whenever someone's putting new equipment on my network. This is a brilliantly sneaky way to do it. There's probably other uses for this, though, and you can imagine that your favorite intelligence agencies have thought about it long before it showed up in a Hacker News article...
- TheRealDunkirk 5y agoIs this the card "technology" that ran DirectTV tuners as well? I had a friend who was, at one point, running 7 hacked systems, and recording everything he could to burn to DVD, but I never got into that.
- rramadass 5y agoCan somebody recommend a good book/paper/video/etc. on Cell/Mobile phone HW/SW/Internals and Hacking (everything other than the Application Processor and its OS i.e. Android/iOS). The only one that i am aware of is an old paper by Harald Welte named Anatomy of contemporary GSM cellphone hardware.
- aaronleather 5y agoThe TP destination number 1111340002 does not fit into any public network numbering plan. It must be a private address inside AT&T. This number does not exist in the public network. You cannot call it or text in through normal means. For a message to get delivered to that private address, it must go to a particular AT&T SMSC that knows how to route it.
- DeathArrow 5y agoI'm not sure that I would like the SIM to send data to anyone without me knowing it. But since both Android and iOS send user data without the user acknowledging, it might not be the biggest privacy issue.
- sdoering 5y agoI am wondering if this is also happening in the EU or with customers from the European Union. The provider would probably put something to the effect of "we can do what we want" into their fine print. But I am not sure if this is legally clear cut under the regulations of the GDPR.
- p_l 5y ago> I am wondering if this is also happening in the EU or with customers from the European Union. The provider would probably put something to the effect of "we can do what we want" into their fine print. > But I am not sure if this is legally clear cut under the regulations of the GDPR. > I am wondering if this is also happening in the EU or with customers from the European Union. The provider would probably put something to the effect of "we can do what we want" into their fine print. > But I am not sure if this is legally clear cut under the regulations of the GDPR. Those messages are part of the original reason for SMS existence, and yes all networks use them - both remotely triggered and unsolicited like in the article. They are vital to operation of the network. Allowing end users to message over this channel was a relatively late addition to the spec. Effectively, for many good reasons, the demarcation point between your part of the device and provider part is the interface between application processor (what runs Android/iOS etc) and the baseband processor which handles the stuff you need a license for, with the licensed party being effectively the provider. When it comes to GDPR, what actually happens is that the providers can't escape handling PII anyway, as it is crucial for their operation. Usually it means that there are some heavy safeties on access to PII, both practical and legal, but operations crew has a lot of capability and thus responsibility. Main difference seems to be that in EU, the carriers can't get away with as much monetization of this as they can in USA.
- lxgr 5y agoThe mechanism described does not give any information to the network that it doesn't already have: The IMEISV is part of the regular network sign-on procedure. This is probably just an optimization so that they don't have to keep track of changing IMEISV/IMSI-pairs in their database, for whatever they do with that. In fact, it might be even more GDPR-respecting than the database alternative: If the purpose is to trigger some updates that should happen with every phone switch, it removes the need to track this data server-side. Realistically, it will be stored anyway, as mandated by many countries' data retention laws.
- lxgr 5y agoNot wanting to downplay the security implications of the SIM OTA/SAT infrastructure at all, but I think in this case, there is also a non-nefarious explanation: Back in the day of feature phones and early smartphones, carriers would proactively send device connectivity profiles (not sure what the technical term is) containing things like MMS and WAP configuration data to any new phone on their network. This might just be AT&Ts way of implementing the trigger for such a system. Obviously it would be unused today (iOS and Android don't support these profiles anymore to my knowledge), but these technologies generally have a very long tail.
- mintplant 5y ago> iOS and Android don't support these profiles anymore to my knowledge Sure they do. You can configure them under the "Access Point Names" setting page in Android (buried under advanced network settings). Some MVNOs need you to input all that configuration manually when you first connect.
- lxgr 5y agoAh, I think I was unclear – iOS and Android phones don't support updating these profiles via SMS anymore in the way that some older feature- and smartphones did. The first time a network would see a new device (or after a long period of inactivity), it would send these out automatically, which was mostly useful but at times annoying when switching phones regularly. There was usually also a way to manually trigger them, like sending a certain text (e.g. SETUP) to a short code. Of course iPhones and Android smartphones still need APN and MMS data to function correctly, but these days that data seems to be part of the OS. In my view, that's a step back – I've had to get onto Wi-Fi to look for the correct APN for a travel SIM more than once. Arguably, it should be part of the SIM these days, just like the SMSC configuration.
- jaclaz 5y agoSide question: >The RP destination number, +14047259800, is a normal-looking US number, what a telecom engineer would call an “NANP E.164”. A Google search turns up documents showing that this number is associated with an AT&T “service control point” (a sort of server) that was made by Sun Microsystems. This is most likely a Sun Solaris server running an Oracle SMSC package, physically located in Atlanta, GA. Interestingly, this is not the SMSC number that AT&T uses for normal texting (+13123149810). This is a special SMSC that is used for special applications. How many SIMs has AT&T around? (I assume millions.) A single Solaris server (which I imagine to be a little dated) can manage the whole stuff? It must be pretty much efficient or these data must be transmitted very seldom.
- lxgr 5y agoIn this case, it would be transmitted only when a SIM is turned on in a new device for the first time. Probably still a lot of traffic, but a drop in the bucket compared with the remaining signalling traffic a large mobile network sees every day. These systems can probably also be scaled almost without limitation for the same reason.
- jaclaz 5y ago>In this case, it would be transmitted only when a SIM is turned on in a new device for the first time. But this is seemingly not what happened in the case at hand. >In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message. So, every time the baseband firmware is updated, likely millions of devices need to send that SMS to that single server, unlesss the updates are deployed somehow sequentially. And if these firmware updates happen not very often, which probabilities were that just after such an update the person (suspected of distracted driving) crashed with the car? Like 0.00000000001 or very, very, very rare chance.
- lxgr 5y agoThat's a very valid concern, and maybe there was just such an "event flooding prevention" mechanism at play, deferring the IMEISV report by a random time?