SMS Forensics

In a previous post, SMS forensics was briefly introduced. This post is dedicated to an elaborate explanation of the forensics analysis of SMS messages.

Short Message Service (SMS)

Short Message Service (SMS) is a text messaging service component of phone, web, or mobile communication systems. It uses standardized communications protocols to allow fixed line or mobile phone devices to exchange short text messages. It is a globally accepted wireless service that enables the transmission of alphanumeric messages between mobile subscribers and external systems such as electronic mail, paging, and voice-mail systems.

SMS was first introduced in 1991 in Europe as a text messaging service based on the European Telecommunications Standards Institute (ETSI) standards for mobile networks GSM 03.40. In North America, SMS was made available initially on digital wireless networks built by early pioneers such as BellSouth Mobility, PrimeCo, Nextel, among others. These digital wireless networks are based on GSM, Code Division Multiple Access (CDMA), and Time Division Multiple Access (TDMA) standards.

The SMS message, as specified by the ETSI standards GSM 03.40 and GSM 03.38 can be up to 160 characters long, where each character is 7 bits according to the 7-bit default alphabet. SMS Text messages may also be encoded in the 8-bit data alphabet, and the 16-bit UCS2 alphabet. Depending on the alphabet, maximum individual SMS sizes range from 160 7- bit characters, 140 8-bit characters, or 70 16-bit characters. It is mandatory for all GSM handsets to support the GSM 7-bit ASCII + additional European characters (which are shown below).

Special characters though, like those found in languages such as Arabic, Chinese, Korean, Japanese or Russian must be encoded using the 16-bit UCS2 character encoding (Unicode). SMS is currently supported on the major mobile network technologies including:

• Global System for Mobile communication (GSM)
• General Packet Radio Service (GPRS)
• Code Division Multiple Access (CDMA)

SMS Network Architecture  

When the Short Message Entity (SME) sends an SMS text message, the message is delivered to a Short Message Service Centre (SMSC). The SMSC will attempt to deliver the message to the intended recipient.

Examples of SMEs are: mobile phones; servers; personal computers.

The message is sent between the SME and the SMSC using the Mobile Application Part (MAP) of the System Signalling #7 (SS7) protocol. The MAP provides an application layer to the various GSM, UMTS and GPRS nodes for intercommunication and delivery of services. The SS7 are a set of telephony protocols widely used in Public Switched Telephone Networks (PTSN).

 When the SMS is delivered to the SMSC it is processed. After the processing the following steps occur.

• The SMSC stores and forwards the message to the Gateway Mobile Switching Centre for SMS (SMS-GMSC)
• The SMS-GMSC uses the SS7 network to interrogate the Home Location Register (HLR) for routing information and upon receipt of this, sends the short message to the appropriate Mobile Switching Centre (MSC). Once the HLR receives the request, it will respond to the SMSC  with the subscriber's status which could be any of the following:
• inactive.
• active (where subscriber is roaming).
  
• If the response is "inactive", then the SMSC will hold onto the message for a period of time. When the subscriber accesses his device, the HLR sends an SMS Notification to the SMSC, and the SMSC will attempt delivery.
  
• The MSC collects the recipient's information from the Visitor Location Register (VLR) and, sometimes, proceeds with an authentication operation.
  
• The MSC forwards the message to the Base Station System (BSS) which transmits the short message to the Mobile Station (the receiving mobile phone). The BSS consists of transceivers, which send and receive information over the air interface, to and from the mobile station.
  
• The MSC returns the outcome of the Forward Short operation to the SMSC.
•  The SMSC receives verification that the message was received by the end user, then categorizes the message as "sent" and will not attempt to send again.
• The SMSC reports delivery status of the short message back to the sender.

SMS is a point-to-point store and forward technology with 2 basic services:

• Short Message Mobile Originated (SM-MO) - Mobile-originated SMS is transported  from a mobile station to the Service Centre. These may be intended for other mobiles or may even be intended for other services which the GSM network and Service Centre support.
  
• Short Message Mobile Terminated (SM-MT) - A mobile-terminated SMS will be transported from a Service Centre to a Mobile Station.

To aid better understanding, let us assume that Mobile Station A (MS-A) is sending SMS to Mobile Station B (MS-B) as shown in the figure below. The SMS delivery will go through two phases before it is finally delivered. The phase of SMS travelling from originating mobile subscriber A to the SMSC is referred as MO (Mobile Originated) call and the phase from SMSC to mobile subscriber B is referred as MT (Mobile Terminated) call with respect to SMS.

The following are the steps for the entire SMS process from originating mobile (MO) to terminating mobile (MT).

• The SMS-SUBMIT is the MO FSM (Mobile Originating Forward Short Message) which is between origin MSC and origin SMSC.
• The message received by SMSC is acknowledged to the origin subscriber MS-A by SMS-SUBMIT REPORT. The MS-A gets the indication message as "message sent" from origin SMSC.
• Origin SMSC gets the required information from HLR regarding destination MSC/VLR to route the SMS. This information is obtained by SRI SM request (Send Routing Information for Short Message). HLR responds with the required information to the origin SMSC in RESP message.
•  After receiving the routing information, the origin SMSC delivers the message to respective destination MSC/VLR, which in turn delivers the SMS to MS-B. The same is indicated in the figure by MT-FSM and MT-FSM ACK.
•  Once the SMS is delivered to the MS-B, MS-A gets indication message as "message delivered” OR “message successfully delivered". The same is mentioned by SMS-STATUS REPORT in the figure.

The Protocol Data Unit (PDU)

 

The protocol layer for SMS is shown in the figu above. The short message transfer layer (SM-TL) services the short message application layer (SM-AL) and enables it to exchange short messages with a peer as well as receive confirmation of reception reports from earlier requests. The SM-TL exchanges PDUs with its peer entity. The short message relay layer (SM-RL) conveys the PDUs via the short message link layer (SM-LL). Refer to GSM 03.40 for further details.

A PDU consists of the Serving Center Address (SCA) and the Transport Protocol Data Unit (TPDU). The SCA is the number of the SMSC that handles the messaging service for the user.

PDU = SCA + TPDU

GSM 03.40 defines six types of messages, which are distinguished by the message direction and the two least significant bits in the first octet of Short Message Transfer Protocol (SM-TP) message (the TP-MTI field):

TPDU Types

TP-MTI	Direction	Message type
0 0	MS → SC	SMS-DELIVER-REPORT
0 0	SC → MS	SMS-DELIVER
0 1	MS → SC	SMS-SUBMIT
0 1	SC → MS	SMS-SUBMIT-REPORT
1 0	MS → SC	SMS-COMMAND
1 0	SC → MS	SMS-STATUS-REPORT
1 1	any	Reserved

• SMS-SUBMIT is used to submit a short message from a mobile phone (Mobile Station, MS) to a Short Message Service Center (SMSC, SC). 
• SMS-SUBMIT-REPORT is an acknowledgement to the SMS-SUBMIT; a success means that the message was stored (buffered) in the SMSC, a failure means that the message was rejected by the SMSC. 
•  SMS-COMMAND may be used to query for a message buffered in the SMSC, to modify its parameters or to delete it. 
•  SMS-DELIVER is used to deliver a message from SMSC to a mobile phone. The acknowledgement returned by the mobile phone may optionally contain a SMS-DELIVER-REPORT. When home routing applies, SMS-DELIVER is used to submit messages from an SMSC to another one. 
•  SMS-STATUS-REPORT may be sent by the SMSC to inform the originating mobile phone about the final outcome of the message delivery or to reply to a SMS-COMMAND.

We will be discussing SMS-SUBMIT and SMS-DELIVER TPDU types.

The TPDU contains a variety of data, depending upon whether the message was sent (SMS-SUBMIT) or received (SMS-DELIVER). For an SMS-SUBMIT message, the figure below shows the various types of data stored within the TPDU.

The content of the SMS-SUBMIT TPDU shown in the figure above is explained in the table below.

Type	Description	Need
SCA	Service Centre Address - Telephone number of the Service Centre	Optional
PDU Type	Protocol Data Unit Type - There are six types as discussed earlier. In this case, it is SMS-SUBMIT.	Mandatory
TP-RP	Reply Path - Parameter indicating that Reply Path exists	Mandatory
TP-UDHI	User Data Header Indicator - Parameter indicating that UD field contains a header	Optional
TP-SRR	Status Report Request - Parameter indicating if the SME has requested a status report	Optional
TP-VPF	Validity Period Format - Parameter indicating whether or not the VP field is present	Optional
TP-RD	Reject Duplicated – parameter indicating if SMSC will accept a message with same MR and DA from the same originator address.	Mandatory
TP-MTI	Message Type Indicator - Parameter describing the message type (01 means SMS-Submit)	Mandatory
TP-MR	Message Reference - The single octet is found in sent messages that   indicate the integer value of a message reference. This value will typically be x00, but can be a value from 0 to 255.	Mandatory
TP-DA	Destination Address - Address of the destination SME	Mandatory
TP-PID	Protocol Identifier - This octet will identify the protocol that has been  used for the transmission of the message. For standard ME to SMSC communication, this   value will most likely be 00 as defined by ETSI TS 123 040 V12.2.0 (2014-10)	Mandatory
TP-DCS	Data Coding Scheme - This octet represents the coding that has been used to encode the message. This value will assist the ME in decoding the format once received. As with all other values, this octet, when converted to binary data, can be   interpreted to determine the value. In the figure below, values are given as represented in   3GPP 3G TS 23.038 V2.0.0 (1999-06). Most often, the value for the TP-DCS will be 00 to indicate that the default 7-bit data code scheme will be used. However, in countries such   as China, Korea, Japan, and others that use characters outside the ASCII range, this value will be different because UCS2 will most likely be used. An example would be x04 in the  TP-DCS section of the SIM record. The x04 in binary would be 01 00, which indicates   8-bit data and class 0 message	Mandatory
TP-UDL	User Data Length - This integer value, represented in hexadecimal, is the  length of data that is contained within the message. This value is also determined by the TP-DCS. If the TP-DCS is the default, 7-bit is the length represented by septets (2 bytes) and 8-bit and UCS2 are represented by octets (1 byte). After converting this number into a decimal value, the examiner can identify the length of the message data immediately following as displayed in octets.	Mandatory
TP-UD	User Data - The User Data portion of the SMS contains the message in 7-bit, 8-bit, or UCS2 format as specified in the TP-DCS. This data is represented in   forensic tools as hexadecimal values.	Optional

The figure below shows the Binary Representation of TP-DCS Byte of SMS Messages, which indicates the Data Coding Protocol Used.

 

For an SMS-DELIVER message, the content differs slightly, as shown in the figure below.

 

 

The content of the SMS-DELIVER TPDU shown in the figure above is explained in the table below.

 

Type	Description	Need
SCA	Service Centre Address - Telephone number of the Service Centre	Optional
PDU Type	Protocol Data Unit Type	Mandatory
RP	Reply Path - Parameter indicating that Reply Path exists	Mandatory
UDHI	User Data Header Indicator - Parameter indicating that UD field contains a header	Optional
SRI	Status Report Indication - Parameter indicating if the SME has requested a status report	Optional
MSS	More Messages to Send - Parameter indicating whether or not there are more messages to send	Mandatory
MTI	Message Type Indicator - Parameter describing the message type (00 means SMS-Deliver)	Mandatory
OA	Originator Address - Address of the originating SME	Mandatory
PID	Protocol Identifier - This octet will identify the protocol that has been  used for the transmission of the message. For standard ME to SMSC communication, this   value will most likely be 00 as defined by ETSI TS 123 040 V12.2.0 (2014-10)	Mandatory
DCS	Data Coding Scheme - This octet represents the coding that has been used to encode the message. This value will assist the ME in decoding the format once received. As with all other values, this octet, when converted to binary data, can be  interpreted to determine the value. In the figure above, values are given as represented in 3GPP 3G TS 23.038 V2.0.0 (1999-06). Most often, the value for the TP-DCS will be 00 to indicate that the default 7-bit data code scheme will be used. However, in countries such   as China, Korea, Japan, and others that use characters outside the ASCII range, this value will be different because UCS2 will most likely be used. An example would be x04 in the  TP-DCS section of the SIM record. The x04 in binary would be 01 00, which indicates   8-bit data and class 0 message	Mandatory
TP-SCTS	Service Centre Time Stamp - This value is represented by semi-octets and reverse nibble (BCD) in the ordering of Year, Month, Day, Hour, Minute, Second,   and Timezone. The Timezone is the number of quarter hours from the local time to GMT time, and the most significant bit of the first octet indicates whether the number is positive or negative GMT. The Timezone is significant because if the ME has knowledge of the local time zone, the ME can display the received time in the local format. The time zone and time are local to the sending entity, which is important for the examiner to understand, especially when time and date are critical to the case	Mandatory
TP-UDL	User Data Length - Parameter indicating the length of the UD-field	Mandatory
TP-UD	User Data - The User Data portion of the SMS contains the message in 7-bit, 8-bit, or UCS2 format as specified in the TP-DCS. This data is represented in   forensic tools as hexadecimal values.	Optional

Both SMS-SUBMIT and SMS-DELIVER use a combination of the items outlined in this section and others outlined in ETSI TS 123 040.

SMS Forensic Analysis

 

Please refer to this post for a good understanding of the SIM file system.

On a Subscriber Identity Module (SIM) card, SMS messages are stored in the EF_SMS elementary file beneath the DF_TELECOM dedicated file. EF_SMS is linear fixed file meaning that each record in the sequence of records stored there has a fixed length. The length of the SMS messages stored on the SIM card are 176 bytes in length and are identified by the header of 0x6F3C.

The first byte of the SMS record is the status byte. The status byte takes the following values in binary.

The status byte of the record, shown in the figure above, will tell the examiner several interesting facts. If the status byte indicates “Unused” and content is still contained within bytes 2–176, the examiner should assume, with great certainty, that the message has been deleted.

Two things are notable to the examiner (besides the message itself) in regard to SMS messages on SIM cards.

• First, when an SMS message is “deleted”, only its status byte is set to 0x00. The record retains its data until it is overwritten by another message.
• The second thing of note is that there is no slack space in the records where an examiner may recover a partial message. When a previous message is overwritten by another message that does not completely take up the full space allotted, the remainder of the record is written over with 0xFF. Therefore, it behoves the examiner to take extreme care to prevent other messages from being sent that may potentially wipe out deleted messages. When a SIM card is written to, it is all or nothing.
  

The figure below shows the hex dump of an SMS.

 

1.  The first byte has the value “01” which indicates that this SMS was read.
2.  The second byte indicates the number of bytes used for the short message service center (SMSC) number. In this case, it has the value of 7, which means the next 7 bytes “91 21 60 13 03 10 F2” determine the service center number.
3.  Type-of-address of the SMSC. (91 means international format of the
   phone number)
4.  The rest of 6 bytes “21 60 13 03 10 F2” give the SMS center number in reverse nibble format. Thus, the SMSC number is “+1 206-313 0012”.
5.  First octet of SMS-DELIVER message (04 = SMS-DELIVER).
6.  Address-Length. Length of the sender number (0B hex = 11 dec)
7.  This byte identifies the type of sender  SMSC number (0x81 - unknown or 0x91 - international number).
8.  The following bytes “21 80 53 33 97 F2” of specific length give the contact number of the sender of the message which is “+1 208-353 3792”.
9.  TP-PID - Protocol identifier. The value here is 0x00 (mobile to mobile).
   
10. TP-DCS - This byte is used to indicate the encoding type of message body (0x00 means the default 7-bit encoding is used).
11. TP-SCTS - This is the 6-bytes timestamp data “60 60 71 12 41 62” which contains the date and the time when the SMS was sent. The date (Year, Month, Day) and time (Hour, Minute, Second) are stored in reverse nibble format. Thus, “60” means “2006” year, “60” means “June” month, and “71” means “17th” day. Also for the time, “12 41 62” is decoded to “21:14:26” in the format (hh: mm:ss). Finally, we can observe that the message was sent in (June 17, 2006 21:14:26 PM).
12.  TP-UDL - This byte indicates the length of user data (1E = 30).
13. TP-UD - The last record is used for the message content (7-bit encoding). In our example, the SMS content data is “57 74 98 0E CA 87 41 E4 77 DA 0D 02 81 86 61 76 DA F6 9C BB D3 61 90 58 5E 26 03”. This data can be decoded using any simple 7-bit encoder. We use the encoder provided at the link. The message content is  "What ya doin Cali6Osnia bred" as shown below:

 

 

If you have read to this point, you have been armed with enough skills to successfully investigate SMS messages. Happy Forensicating!!!