Binary SMS Encoding in NowSMS

For those who are using the NowSMS application, the sent/outgoing SMS is logged in its log file. The file name of the log file is usually in the form of SMSOUT-YYYYMMDD.LOG.

Inside the log file, the sent SMS data is sometime in the form of text when there are only one message, or in the binary form when there are multipart SMS data.

In theory, it should use the 7-bit binary encoding, as specified in their official documentation, so at first, I think it should be easy to decode the binary message, given the ubiquitous PDU decoder softwares available over the internet.

One day, one of my co-workers ask me to decode some binary SMS data in the log file. That one should be easy, I said, and try to obtain one of the PDU decoder (PDUDecoder) software from CodeProject website.

Because I don’t have the exact format of the PDU string, I use the sample given by the PDUDecoder documentation and replace the data string with portion of the hexadecimal SMS binary data string from NowSMS’s log file :

After hitting the decode button , to my astonishment, the decoded text result is a garbage, instead of meaningful text :

Because I don’t know the message content, I proceed to sent the known message text, a successive of uppercase alphabet, ABCDE, etc and got the binary form (for first 5 characters) :

82 C2 21 B1 68

Then, using the PDU Encoder from CodeProject, I try to encode the same message with this result :

41 E1 90 58 04

It is clearly the NowSMS application is using the different encoding scheme from the theory of 7-bit binary encoding.

To find its differences, I try to figure out the encoding method used by NowSMS. Because I am using the known character, so I can write :

41 = 1000001 -> 10000010
42 = 1000010 -> 11000010
43 = 1000011 -> 00100001
44 = 1000100 -> 10110001
45 = 1000101 -> 01101000

The value of 0x41, 0x42, etc is the ASCII code for character A, B, C, etc. The left hand side of the binary form is its binary format, the right hand is the encoding result by NowSMS.

After spending some time tinkering the bytes and bits, I realized that the encoding scheme is still 7-bit binary encoding (i.e. transforming the sextet to octet), but slightly different on first and second byte :

Let me illustrate the encoding supposedly performed by NowSMS application in transforming the original message.

1. Let’s get the first two byte of original message :

2. The zero – one with bold blue in the second byte is copied to the first byte to make it an octet :

3. The second byte is made to octet by borrowing it from 3rd byte :

4. The 3rd byte is again made to octet by borrowing the deficit bits (2 bits) from 4rd byte :

5. The 4rd byte is again made to octet by borrowing the deficit bits (now 3 bits) from 5rd byte :

This process is repeated, hence, will end with the above result.

As for the decoding, it is simply the reverse process of encoding process :

1. The LSB (Least Significant Bit) of first byte is discarded to make it sextet :

2. The MSB (Most Significant Bit) of 2nd byte is move to 3rd byte to make is sextet, this will result the surplus of 2 bits (orange) in the 3rd byte :

3. The 2 bits surplus in 3rd byte is then move to the 4th byte, this will result the surplus of 3 bits (orange) in the 4th byte :

4. The process goes on for the rests of the octets, i.e. surplus bits will be move to the next byte.

Using this method, I can now manually perform the decoding of portions SMS message given by my co-worker.

I’ll leave it to the hand of reader forum of the task for creating the encoding/decoding program 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: