Proactive SMS and a Claim of Distracted Driving
From time to time, and attorney will request cellphone activity records from a mobile operator, and those records will show text messages to and from strange numbers. There is a good chance that the person who uses the phone probably never sent or saw these messages. The resulting confusion can be a source of doubt and error, and often used as the basis of an argument, by one party or other, that the owner of the phone was distracted at some critical moment. What follows is a case study of such a message.
Some time ago, a law firm contacted me about an SMS sent to 1111340002 that had become a critical issue in their case, in a question of distracted driving. They needed to know what triggered that message. I advised them that they had two options:
1. Completely reverse-engineer whatever was sending that message to determine the trigger.
2. Identify someone at AT&T who could explain the trigger in deposition or testimony.
The client chose to start by pursuing both tracks in parallel. And so we are off to the lab...
The Phone and SIM
The original iPhone in this case was damaged and the client did not want to give up custody of the SIM. So the client provided me with an iPhone of the same model and an AT&T SIM from the same production series. (I verified that the SIM was of the same series by comparing digits of the ICCID.)
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.
Along with the client-provided iPhone, I also used a variety of other 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 Destination of the Message
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. An SMSC is for SMS what an email server is for email. Normally, this SMSC number is supplied by the SIM for an SMSC operated by the same carrier who issued 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 E.164 number, like a telephone number. A Google search turns up documents from AT&T showing that this number is used for an AT&T SMSC physically located in Atlanta, GA. As expected, this is not the SMSC number that AT&T uses for normal texting (+13123149810). The unusual RP destination means that message goes to a special SMSC that is used for special applications.
What does this mean for the case?
1. A human user has no reason to enter a message to 1111340002, because texts sent by the messaging app on the phone will not normally go to any SMSC that can route to this non-public number.
2. Very likely, someone in the AT&T building in Midtown Atlanta knows exactly how this system works.
What is in the message?
Using the same network emulator, I captured the content of the message and decoded most of it.
The SMS payload is raw binary, not the normal SMS text. The message has a very orderly format, using the same type-length-value (“TLV”) formatting that is used in many telecom protocols. Decoding the message, the following fields were obvious:
- the IMSI of the SIM
- the IMEISV of the previous phone to use 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
Some quick definitions:
- IMSI - The serial number of a SIM.
- IMEI - The serial number of the baseband processor in the phone.
- IMEISV - An IMEI, followed by the software version that is installed in the baseband processor.
Again, what does this mean for the case? The fact that the message carries the IMEISV of the previous phone means that the message is likely coming from the SIM, not the phone. The content also hints that changing the IMSISV will trigger the message.
What is really sending this message?
SIMs can send SMS on their own using a feature called “proactive MO-SMS”. The information so far pointed to the SIM as a source, but we needed absolute verification. The first and easiest verification was to just move the SIM to another phone and see the message again from the second phone. For more details, though, I used a SIM tracing tool. The tracing tool connects to the phone’s SIM tray with a special flat cable. Then the SIM plugs into the tracing tool, so that the tracing tool sits between the phone and the SIM, and can record the messages exchanged between them. And, as expected, the tracing tool recorded the SIM using proactive MO-SMS to send this message. The behavior was confirmed in several phones.
From the tracing tool, it was clear that this message goes directly between the SIM and the baseband processor and then out over the air. The application processor, where the user’s SMS messaging app runs, is not “in the loop”. The iOS or Android part of the phone has no way to know what happened.
What does this mean for the case? There was no way for the user to know that the phone was sending this message, because there was no indication to iOS of what was happening.
When does the SIM send this message? This was most important question in my scope of work.
The fact that the SIM reports the IMEISV of the phone (and of the previous phone) was a hint that moving the SIM to another phone would trigger it. And moving the SIM did trigger the message very reliably.
The fact that the message carried the IMEISV instead of just the IMEI was a hint that a change of the baseband firmware version might also trigger the message, but there was no way to verify that in the lab.
Examination of the signaling between the SIM and the phone also ruled out some possible triggers:
- 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 any 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 mobility. I ran several experiments to simulate the effects of the phone moving through the network from tower to tower or across location areas. These tests ran for a few days, simulating the equivalent of months of activity, but none of them triggered the message.
Taken as a whole, these observations point to a firmware update of the baseband processor as the mostly likely trigger for the message in this case. There was no way to prove that in the lab, but other records in the case indicated that the phone had downloaded an iOS software update not long before the message was sent, and that the iOS update in question included a baseband firmware update.
At this point, I helped the client draft a subpoena to AT&T to produce a document or witness to explain what triggers this message. This subpoena made use of the lab work and expert research to give a very clear definition of what information the client was seeking. After some resistance, and expressing surprise at the specificity of the request, AT&T produced a witness who, in deposition, confirmed that the message in this case was triggered by an automatic software update of the phone, and, more importantly, it had nothing to do with any particular actions of the user.
What does this mean for the case? This SMS message is not evidence of distracted driving.
Some people involved in this case started with a firm assumption that a phone could not just "decide" to send SMS on it own, for reasons that had nothing to do with the user, but investigation proved otherwise. And while I was certainly prepared to present my work under oath and examination, a witness directly from AT&T spoke with far more credibility. We reached the truth of the matter and it was a positive result for the client.
By David Allen BurgessABOUT THE AUTHOR: David Burgess
Telecom and Cellphone Expert Witness
Telecom and Cellphone 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.