Proactive SMS and a Claim of Distracted Driving
From time to time, an attorney will request cellphone activity records from a mobile operator, and those records will show some text messages to and from strange numbers. There is a good chance that the person who uses the phone never sent or saw these messages. And if this happens in the middle of a legal case where cellphone activity is an issue, the resulting confusion can be a source of doubt and error.
In the Spring of 2021, an attorney contacted me about a mysterious SMS to 1111340002, at the center of a wrongful death lawsuit, with allegations of distracted driving. Here is what I found…
Summary: The driver’s AT&T SIM sent an SMS to 1111340002 to report that the phone had installed an automatic software update. The SMS event had nothing to do with any specific actions by the driver. It took some lab work and a subpoena to AT&T to sort this out.
The tools used for this investigation are well known in the mobile network security research community, and all based on open source designs that can be verified by other parties:
* YateBTS, based on OpenBTS, used to simulate a cellular network.
* SimTrace2, a tool for monitoring communication between the SIM and the phone.
* Wireshark, a protocol analyzer that can decode the outputs of YateBTS and SimTrace2.
I also used a variety of phones, from Nokia, Samsung, and others.
With this test bench, I could simulate a cellular network and then record examples of the phones sending the SMS to 1111340002. The actual test bench was located in Romania. This was convenient because it means that I never had the risk of the SIM contacting the real AT&T network and getting disabled by AT&T, or the risk of handsets in the room accidentally trying to attach to my fake AT&T cell site.
Summary: The destination is a special server somewhere inside AT&T.
Any outgoing SMS from a phone has two destination numbers (“addresses”):
* There is the transport layer (“TP”) destination address, the address of the final recipient, which in this case is 1111340002. (Normally, this is the number that the user specifies.)
* There is the relay layer (“RP”) destination address, the address of the SMSC to use for outgoing routing, which in this case is +14047259800. (Normally, this number is supplied by the SIM.)
The 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.
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.
Summary: The message reports information about the SIM, about the phone, and about the phone that the SIM was previously installed in, and some other information not yet determined.
The SMS payload is indicated as being raw binary, not normal SMS text. A little reverse-engineering revealed that it has the same type-length-value (“TLV”) formatting that is used in many telecom protocols. Decoding the payload, I found these fields:
* the IMSI of the SIM
* the IMEISV of the previous phone using this SIM
* the IMEISV of the current phone using this SIM
* the terminal profile of the current phone
* the ICCID of the SIM
* the location area in the current serving network
* three other fields of unknown purpose
Summary: This message originates in the SIM.
The fact that the message carries information about the previous phone that used the SIM is a strong hint that the SIM itself is sending the message, because only the SIM would “remember” this information as it moves from one phone to another. Many people do not realize it, but SIMs can send SMS on their own using a feature called “proactive MO-SMS”, and nearly every SIM in the market today supports this feature.
To verify that the the SIM was the source, I used the SIMTrace2 SIM tracing tool. The tracing tool connects to the phone’s SIM tray with a special flat cable. The SIM plugs into the tracing tool. Now the tracing tool sits between the phone and the SIM, and it can record the commands and responses exchanged between them. And, sure enough, the tracing tool recorded the SIM using proactive MO-SMS to send this message, just a second or two before the message arrived in the YateBTS cell simulator.
The signaling that is used by the SIM to send this message goes directly between it and the baseband processor, the part of the phone that provides its actual telecommunication features. The application processor, where the user’s SMS messaging app runs, is not “in the loop”. In other words, the iOS or Android part of the phone has no way to know what happened, and so there is no indication to the user. The SIM does not save a copy of the message, either. If everything is working correctly, there will be no traces left in the SIM or in the phone that this message was sent. The only records of the event will be at AT&T.
Summary: The SIM sends this message whenever it is moved to another phone and whenever the firmware is updated in the phone’s baseband processor.
The fact that the SIM reports the IMEISV of the phone (and of the previous phone) is a sign that a change of IMEI probably triggers the message. And, sure enough, moving the SIM from one phone to another, exposing the SIM a new IMEI, does trigger the message. In fact, that is how I learned to trigger the message on demand to do some of the examinations that I describe here.
Judging from AT&T activity records, there are other triggers as well, because the IMEI appears in several places in a typical AT&T activity record, and that IMEI is usually not changing. Just determining these triggers through reverse-engineering may not be possible and is certainly not practical. However, examination of the signaling between the SIM and the phone does rule out some causes:
* The triggers are not time-based. There is no clock in the SIM and the SIM never asks the phone for the current time, even though it has many opportunities.
* The triggers are not based on user activity. There is no signaling between the SIM and the phone that would indicate user activities that do not explicitly require the SIM. Again, the SIM has opportunities to request information about user activities, but it does not make such requests.
* The triggers are probably not based on movement. The SIM reports cell tower data, but changes in call tower data do not appear to trigger the message. I ran several experiments to simulate the effects of the phone moving through the network from tower to tower or across location areas, for days at a time, but none of them triggered the message.
Based on this lab work, I helped the attorney issue a special subpoena to AT&T for documentation or witnesses to explain what triggers this message. After some resistance, AT&T finally produced a witness with enough technical background to have a meaningful conversation about it. Deposition of this AT&T employee revealed that the only other trigger for this "service update message" 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, other records showed the phone had recently downloaded an update that included new baseband firmware. The AT&T witness agreed that the update was almost certainly the trigger for this specific message in the activity records. More importantly, the attorney got a deposition with an AT&T representative saying not once but twice that the SMS in question had nothing to do with any actions of the driver in the time leading up to the accident.
AT&T says nothing publicly about why their SIMs send these reports, and said as little as possible in deposition, but it seems that they are trying to keep a database of what
phones their customers are using, and where. That is obviously useful information for an operator, although it would be nice if they were transparent about it.
And there is other information in the message whose purpose is not yet known.
AT&T is not the only operator to use pro-active SIMs to send automatic SMS back to their network. They are given here only as an example. 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.
By David Allen BurgessABOUT THE AUTHOR: David Burgess
Telecom, Cellphone, and Cell Tower Expert Witness
Telecom, Cellphone, and Cell Tower Expert Witness
David Burgess has worked in telecommunications since 1998, first in signals intelligence and then in commercial network equipment. He is probably best known as the primary author of OpenBTS, a widely used tool in cellular security testing. David’s company, Legba, provides mobile network equipment and test equipment for small network operators, embedded systems developers, and special applications. Prior to his commercial work, David worked on tactical SIGINT systems used by US military forces. He also writes about telecommunications and does work as an expert in legal cases.
Copyright David Allen Burgess
Disclaimer: While every effort has been made to ensure the accuracy of this publication, it is not intended to provide legal advice as individual situations will differ and should be discussed with an expert and/or lawyer.For specific technical or legal advice on the information provided and related topics, please contact the author.