Have you ever said something and later regretted it? Or written an email to someone and then wished it had not happened? Or sent an SMS message but afterward desired to change its content? Well, replacing the content of previously sent SMSs is actually possible.
SMS messages can be constructed in one of two modes: the text mode, commonly used by the vast majority of smartphone users; or the PDU mode, which allows modifying the message settings not available in the standard text mode. Among a few settings, there is one that allows to specify how the receiving device should handle the SMS, in particular, the receiving device can be advised to overwrite a message previously sent by the same sender.
The main advantage of being able to send replaceable SMS messages is the fact that most telephone users do not realize overwriting previously received messages is at all possible. Imagine you set up a meeting at 7pm. But then, for whatever reason, you realize you will not be able to arrive at the given place on time. You could either send a new message informing the recipient that you will be late, or just send a new text message with an updated meeting time and make the other party believe that he or she came too early to the meeting.
Messages displayed on the recipient’s mobile device before and after receiving the replacement SMS.
Although it is not guaranteed how the device will behave upon receiving an overwritable SMS, during the tests performed in the Swisscom mobile network, all examined devices (these are: Samsung Galaxy S7 [Android 8.0], iPhone 8 [iOS 12], NOKIA Lumia [Windows 10 Mobile]) replaced the previous message with the new one. Furthermore, no special information was shown to the user indicating that one of the saved messages can be deleted and replaced. From the user’s perspective, getting an overwritable SMS looks exactly the same as receiving a standard message.
Technical details
In the following I will describe how to craft SMS text messages in PDU mode.
Introduction
The simplest way to access low-level functionalities of the SMS protocol seems to be treating a smartphone as a GSM modem and issuing appropriate AT (ATtention) commands. AT commands were developed in the 80s for controlling modems. Interestingly, those commands are still implemented in the latest smartphones. In some of the smartphones it even is possible to bypass their security mechanisms by executing AT commands.
AT commands can be sent via the USB interface of the device. However, the exposure of AT functionalities depends on the smartphone model. Whereas some smartphones provide the AT interface just after attaching them via USB to a computer, others need to be jailbroken or rooted. The accessibility of AT commands for a particular device may be quite cumbersome to figure out, nevertheless, the information how it is exposed in a few popular smartphones can be found in this paper.
For sending overwritable SMSs I used a LG Nexus 5X running Android 6.0. This device had to be rooted before the AT interface was exposed. After connecting it to the computer via USB and spawning a root shell on the device, the port which listens for AT commands needs to be found. Usually it is either one of /dev/tty* or /dev/smd* ports. The quickest way to identify the correct one is to issue an AT command to every port and subsequently read from the ports to detect which one understood the command. In the used Nexus 5X, /dev/smd8 executes and answers AT commands.
To check whether the port processes AT commands, it suffices to send “AT” as a command:
# echo -e 'AT\r' > /dev/smd8
To get the answer, just read from the port:
# cat /dev/smd8 AT OK
Output “OK” indicates that this is the correct port.
Sending SMS messages
Before the first SMS in PDU mode can be sent, a few settings need to be verified or adjusted. First, the correct number of the SMS Service Center has to be specified. This setting can be verified by sending the following commands:
# echo -e 'AT+CSCA?\r' > /dev/smd8 # cat /dev/smd8 AT+CSCA? +CSCA: "+41794999000",145 OK
The number +41794999000 is the Service Center of the Swisscom mobile network, so this setting does not require changes.
Next, the PDU mode has to be set:
# echo -e 'AT+CMGF=0\r' > /dev/smd8 # cat /dev/smd8 AT+CMGF=0 OK
Value “0” indicates the PDU mode is used, “1” would mean the standard text mode is set. Checking which mode is set can be accomplished with a command “AT+CMGF?”.
Now, assuming the device is connected to the mobile network, we can send the first SMS in PDU mode (this will not be an overwritable SMS yet).
Firstly, the command “AT+CMGS” with the PDU payload length as its parameter has to be invoked:
# echo -e 'AT+CMGS=23\r' > /dev/smd8
Then the actual PDU payload ending with ^Z needs to be provided. The character ^Z is a one-byte character that can be entered into the console by pressing Ctrl+v and then Ctrl+z:
# echo -e '0001000A81701932547600000CC8329BFD065DDF72363904^Z' > /dev/smd8
To verify whether everything went well, just print the output:
# cat /dev/smd8 AT+CMGS=23 > +CMGS: 27 OK
The SMS has been sent successfully. Number “27” from the command output is the sequential ID of the sent message.
Understanding the PDU
The text message encoded as a PDU consists of hexadecimal characters. To understand values used in the PDU, the message sent previously will be decomposed 0001000A81701932547600000CC8329BFD065DDF72363904.
- The first 00 means that the number of the SMS Service Center is not provided in the PDU itself but should be fetched from the device’s memory. In one of the previous steps it has already been checked that the device knows the correct number.
- The next byte: 01 specifies six different message flags: Reply Path, User Data Header Indication, Status Report Request, Validity Period, Reject Duplicates and Message Type. Five of the parameters are set to null as they play no crucial role in sending normal or replaceable messages. The only set parameter indicates the message type SMS-SUBMIT as this PDU is meant to be submitted from the mobile device. Another value would be SMS-DELIVER but the Service Center will reject incoming messages with that value. Only the Service Center may submit SMS-DELIVER messages.
- Next 00 is the message reference number that can be simply set to zero since the device will assign a reference number automatically if none is specified.
- 0A is the number 10 presented in hexadecimal and indicates the length of the SMS recipient’s phone number.
- 81 specifies that the recipient’s number will be encoded in the national format, that is without +41 needed for numbers in the international format.
- 7019325476 is the encoded recipient’s phone number: 079 123 45 67. To decode it, just read every pair of digits in reverse.
- The first byte after the phone number is the Protocol Identifier. Value 00 means the default SMS message.
- The next null byte: 00 indicates that the used Data Coding Scheme is set to the default, uncompressed, GSM 7-bit coding.
- The following byte: 0C specifies how long the text payload of the SMS message will be. Here 0C represents 12 in the decimal system.
- Next 11 bytes: C8329BFD065DDF72363904 is the actual text content of the SMS message. Thanks to the fact that every character of the text is encoded as a 7-bit value, it was possible to fit 12 characters into 11 bytes. Decoding the GSM 7-bit encoded message can be accomplished manually or online resulting in the content: “Hello World!”.
Finally, the PDU length provided as a parameter to the “AT+CMGS” command is calculated as the number of octets in the PDU payload but without the address of the SMS Service Center. The examined PDU consisted of 48 hexadecimal characters. The first two (00) denote the SMS Service Center so should be disregarded, thus the PDU length amounts to 23 octets.
Sending replaceable PDU messages
As the structure of PDU is now more comprehensible, the procedure of sending overwritable SMS messages will be described. It may seem surprising but to change a standard message into an overwritable one, it suffices to change the Protocol Identifier value. According to the GSM standard, if the Protocol Identifier is set to 65 the SMS message will be of type: “Replace Short Message Type 1”. The recipient’s device after receiving the message with such a Protocol Identifier value should store the SMS but also remove the previous message with the same Protocol Identifier received from the same sender.
The AT command needed to send the messages shown at the beginning of the article may look as follows:
#echo -e 'AT+CMGS=47\r' > /dev/smd8 #echo -e '0001000A817019325476410027CC32FD3407B5CB653A284C07DDE06D50980EA2A3CB20BA3C9C7683E6F4303DFD76BB00^Z' > /dev/smd8 #cat /dev/smd8 AT+CMGS=47 > +CMGS: 28 OK
Note that the byte representing the Protocol Identifier is set to 41. This is the hexadecimal representation of the decimal 65.
Then, the second message can be sent with:
#echo -e 'AT+CMGS=47\r' > /dev/smd8 #echo -e '0001000A817019325476410027CC32FD3407B5CB653A284C07E1E06D50980EA2A3CB20BA3C9C7683E6F4303DFD76BB00^Z' > /dev/smd8 #cat /dev/smd8 AT+CMGS=47 > +CMGS: 29 OK
The only difference between the first overwritable PDU message and the second one is their text content. If further replacements are needed, the next SMS with the same Protocol Identifier will overwrite the last one.
Limitations
The main limitation is the fact that you cannot overwrite previously sent standard SMS messages. Before you send the message, you have to decide whether you want to have the option to overwrite the text message in the future. Moreover, the GSM standard specifies only seven types of replaceable short messages. This means that you can keep up to 7 SMS messages with an option to overwrite for every recipient. Once all 7 replaceable messages are sent, you either have to replace one of the previously sent messages or send a normal SMS without the possibility to overwrite its content later. Furthermore, received messages are usually presented chronologically on most devices. If the recipient answered to the replaceable message, replacing it afterwards will position the new message after the recipient’s answer.
Messages displayed on the recipient’s mobile device after replying to the original message and subsequently receiving the replacement SMS text message.
Furthermore, spoofing the SMS sender number cannot be achieved by manipulating the sent PDU. The identity of the sender is added to the message by the network operator before the SMS is delivered to the recipient. Of course, falsifying the SMS sender’s name is possible but it requires cooperation from a mobile network element, the SMS Service Center. Naturally, there are several service providers which will put whatever value you like into the SMS sender’s ID.
Leave a Reply