Iran, secret text messages and a toy for a holiday break

So I recently tweeted about some interesting Android app sample. This app either is or pretends to be an Iranian banking app. I couldn't take a closer look at it (there is a bit of a language problem for me), however it uses the Ansar Bank name and graphics (as you can see on a screenshot below) and also uses a very interesting text messages feature that I was not aware at all.

The curious case of the SMS protocol

Text message protocol is pretty straightforward on the high level: it allows you to send a 140-byte message to the other phone. Wait, I surely meant 160 bytes, right? No, it's a 140 bytes, but it's using a plain 7-bit ASCII encoding without those fancy characters like the one at the beginning of my name. This allows you to send precisely 160 ASCII characters.

As you probably all know, we can send more than 160 characters, but it will be broken into several messages. However, mobile phones seem to be OK with that and let you create a long message and the receiver also can read a one, long message without even noticing the split. How is that possible? SMS protocol specifies something called User Data Headers (UDH for short). These headers are sometimes present at the beginning of the text message and allow to send multipart messages, ringtones or include fancy characters with their pretentious UTF-whatever encoding. There is also a flag bit to indicate whether the message contains these UDH or not.

Let's have a look at the example of multipart message header (taken from here):

05 00 03 5F 02 01

This header would be at the beginning of your text message and, if your phone wasn't so ergonomically designed, it would be rendered as a bunch of characters. First number of the UDH specifies the header length (5 bytes, excluding the length byte). Then there is a header type, in this case meaning that this is a concatenated message. Then there is another length (3 bytes). Then there is one byte message ID, shared among all of the message parts, then the number of message parts and, finally, this part identifier. 

Header in the given example means that this is first of 2 messages with "thread" id 5F. So, why am I explaining all of this? Because there is a little known (at least I didn't know about it) feature of the SMS protocol that allows you to specify "port" information. This is used e.g. for the WAP Push messages, which are just plain SMS messages but with a specific UDH. This UDH looks like that:

05 04 03 <destination port (2 bytes)> <originator port (2 bytes)>

The 2-byte values are called "ports" because they are meant to be used to identify a service. Some app in your phone "binds" to a port and listens for all the messages to that port. Another app "binds" to a port and sends SMS from that port to your app - directly. You can also use 00 00 as the originator port if you don't need a specific port.

How are these ports handled on Android?

This is a really good question! First of all on Android they are called "binary SMS" or "data SMS". Apps that want to use them have to have the standard SMS permissions: android.permission.RECEIVE_SMS and android.permission.SEND_SMS. Next, the Broadcast Receiver has to have somewhat different declaration, like the one in the picture below (taken from an Iranian app mentioned previously).

As you can see you have to declare a port and the scheme. Apparently there are two different addressing schemes - one which uses two byte port number and one which uses 4 byte port numbers.

So, I wanted to experiment with it. After some Googling (which is nowadays an equivalent of "Research") I found out the the Android emulator does not handle port messages very well. Or even at all. So I decided to have fun with it using my real phone. My very real phone has Android 4.3 installed and my other test phone has Android 2.3.6. I've sent a binary message to both phones and neither of them displayed it. It just went to the dark hole. No notification, nothing. However, my billing statement showed that I indeed have sent the messages. That's a covert C&C channel for you! 

Summing up the features of a new (at least for me) SMS C&C protocol:

• Binary text messages received to a custom port are not displayed in any way (not even in a form of notification) - that means no more abortBroadcast() nonsense and no problems with KitKat and above!
• They are not saved in the "Sent" folder!
• They require the same permissions as "normal" text messages.

So go and have fun with binary text messages during Christmas! If you'd like to experiment with them as I did, I suggest you use the kvarma-android-samples SMSDemo app which I also conveniently compiled and signed just for you! Usual disclaimer: I do not take any responsibility for your phone bill or any other material and non-material damage the app makes to your phone or to you.

Have fun!