You know, I decided to take a break from the #hacktheone effort. Despite its apparent simplicity, it’s actually very time-consuming and nerve-draining. I’ll definitely return to it someday. But as of now, I focused on a much more fundamental thing affecting every mobile user…
Which is…
…SMS.
Yep, your plain old SMS. A universal messenger every GSM and CDMA subscriber doesn’t have to install. Some narrow-minded first-world-fags pronounce the death of SMS from year to year, but they have absolutely no idea that it’s a backbone for all non-voice activity in GSM and UMTS networks that involves an end subscriber. MMS? Pretext SMS messages are delivered first. Cell broadcasts? WAP Push? Internet autoconfiguration messages? EMS? Voicemail notifications? They are all SMS-based. This service is so ubiquitious now that it’s hard to NOT use it if you own a working cellular phone of any “smartness” level.
Now, I won’t go into explanation of what SMS PDU mode is and how it differs from text-only mode. If you’re reading my posts, you should be already familiar with the basic stuff. If you aren’t, all I can do is redirect you to the standard which I’ll refer to often in this and some of the following posts. Anyway, I’ll begin with a commonly-known stuff.
For example, I think everyone more or less tech savvy had heard of so-called “Flash SMS”, a.k.a. “Class 0 SMS” (and message class is something defined in the TP-DCS field which denotes the data coding scheme for the message). Some carriers even allow to send them normally with # or #flash# prefix before your text, and do the necessary conversion on their side. Anyway, what are they? Well, there is another standard for this that says the following:
When a mobile terminated message is class 0 and the MS has the capability of displaying short messages, the MS shall
display the message immediately and send an acknowledgement to the SC when the message has successfully reached
the MS irrespective of whether there is memory available in the SIM or ME. The message shall not be automatically
stored in the SIM or ME.
This is all it requires from the phone that deals with Flash SMS messages: display them immediately and don’t automatically store them. And you know how some vendors decided to interpret this paragraph in the standard? They literally pushed the restrictions to the maximum and added their own against all common sense: when a Flash SMS arrives, they don’t allow the user to store it at all (!), don’t log the arrival (!!) and don’t even display the message sender (!!!) - ehmm… what? Really?
And who would be surprised if I said that Apple is among such vendors? Yep, Flash SMS messages are the easiest way to troll iNoobs. If you know the victim has an iPhone (or a very old S40-based Nokia like 3100, or an Elari Nanophone series), then your identity will not be discovered unless and until someone inquires the carrier. What a fucking mess.
Not-so-old Nokias allow you to both save the Flash SMS and see the sender. Modern MAUI-based (including Nokias) and KaiOS-based phones allow you to see the Flash SMS sender number, although don’t allow you to save it. Same goes for Androids, if anything (except some of them, like MIUI, allow you to save the message, and you’ll be only able to see the sender after saving it). But fingerprinting of the target platform is a story for another time.
Anyway, when I discovered all this a year or two ago, I was very proud to implement carrier-agnostic Flash SMS sending within my TekBuster tool. And it really worked, although with 70-char limitation because I was too lazy to implement different encodings and concatenation back then, and I must admit I wasn’t as familiar with PDU format back then as I am now. However, I didn’t realize one thing because of this: actually, Flash SMS are just a tip of this giant iceberg of SMS hacking.
My interest in this topic resurrected not so long ago, this year, when I came across something that really left me with a WTF-like face. No, that wasn’t the fact that Class 2 messages, as opposed to Class 0, Class 1 and Class 3, are forced to be saved into SIM card and can overflow its internal memory in no time. It was something much heavier. See for yourselves.
So, it turned out that there is a type of messages (not to be confused with message class) which is called Type 0 for some reason (again, not to be confused with Class 0) and denoted with TP-PID field value 64, which has the properties that make every paranoid person like me want to throw all phones out of the window. Let me quote the standard for this matter:
A short message type 0 indicates that the ME must acknowledge receipt of the short message but shall discard its contents. This means that
- the MS shall be able to receive the type 0 short message irrespective of whether there is memory available in the (U)SIM or ME or not,
- the MS shall not indicate the receipt of the type 0 short message to the user,
- the short message shall neither be stored in the (U)SIM nor ME.
What. The. Fuck.
Pure Orwellian surveillance. Or Survellian orweillance. Or… whatever. Straight in the standard. Once again, who would be surprised that a recent report came out about excessive use of this “feature” by German law enforcement agencies.
I know that the mere fact of base station connection is sufficient for the government to track your location, it’s just that you don’t know about the incoming SMS to trigger that connection in this case. But fuuuuck, anyone can shape a PDU with TP-SRR bit set to 1 and TP-PID set to 64. I repeat, anyone. You don’t have to be a government agency to do this. You can ping whether someone’s phone is on without them knowing it. I tested this on my 216, it perfectly works with MS origination. Moreover, you can set the TP-SRR bit to 0 and spam the target with such messages until it drains the battery (not to mention radiomodule processing DoS) and probably money, if the target lives in the US (where, for some crazy reason, they still pay for incoming calls and messages) and doesn’t have unlimited texts in the carrier plan.
For GerdaOS, I created a patch that violates the standard and doesn’t acknowledge the reception of Type 0 messages. I also need to create an alerting mechanism for this because the BS connection itself would be, in a general case, sufficient to track you anyway. So an alert would at least let you know that someone is trying to do so.
After this very disturbing signal, I continued the research and got myself fully immersed into the standard. And now, let’s prepare for some surrealism we’re already living in.
Well, it turns out that there are other, no less interesting TP-PID values. My favorites (besides the Stasi-stealth 64) are definitely 65 to 71. These are so called “replace message identifiers”. What does it mean? Simple as a stick (into your private ass):
The Replace Short Message feature is optional for the ME and the (U)SIM but if implemented it shall be performed as described here.
For MT short messages, on receipt of a short message from the SC, the MS shall check to see if the associated Protocol Identifier contains a Replace Short Message Type code.
If such a code is present, then the MS shall check the originating address and replace any existing stored message
having the same Protocol Identifier code and originating address with the new short message and other parameter
values. If there is no message to be replaced, the MS shall store the message in the normal way. The MS may also check
the SC address as well as the Originating Address. However, in a network which has multiple SCs, it is possible for a
Replace Message type for a SM to be sent via different SCs and so it is recommended that the SC address should not be
checked by the MS unless the application specifically requires such a check.
If a Replace Short Message Type code is not present then the MS shall store the message in the normal way.
To put it straightforward: you can send a message with a Replace type TP-PID (from 65 to 71) and assign some fixed message reference number to it (non-zero). And when you send another message with the same Replace type TP-PID and the reference number, it will… replace the first one if it’s still stored in the target’s memory. And yes, it works in pretty much all modern handsets despite being declared as optional.
This is your fucking “Edit sent message” function in the universal messenger called SMS. There also are not-so-favorite TP-PID values like 124, 125 and 127 which allow the carrier to unsolicitedly download anything it wants to your device and/or USIM. Welcome to the brave new world.
But some interesting things also happen outside TP-PID. For instance, the same TP-DCS field which defines the data encoding alongside the message class, can also have some interesting values, namely when its higher 4 bits are equal to:
- 12 - deliver “new voicemail/fax/email waiting” signal and discard the message contents;
- 13 - deliver “new voicemail/fax/email waiting” signal and store the message contents in GSM-7 encoding;
- 14 - deliver “new voicemail/fax/email waiting” signal and store the message contents in UCS2 encoding.
In this case, lower TP-DCS bits change their meaning from usual “alphabet + class” to “indication + type”. Bit 3 sets or unsets the indication, bit 2 is always 0, and the pair of bits 1 and 0 defines the type: 0 is voicemail, 1 is fax, 2 is email and 3 is “other/reserved”. So, what the phone really does when this monster arrives, depends on the manufacturer, but it sets the indication if the bit is set and proposes the voicemail action according to the set notification type to the user. Pretty simple, huh? Oh, did I mention that the sender number is also not displayed in case the type was set to the discarding one (12)?
For Android smartphones, it’s actually not that bad. As for the TP-DCS, they only react to the voicemail type (no fax or email) and the notifications are easy to discard. But still, there’s no way to know the sender if the type is set to 12. So, at the end of the day, the TP-DCS value 200 (0xC8) is a universal piss-off value for both feature phone and smartphone users, as well as a way to send fake voicemail notifications without disclosing your identity.
So, here’s an already huge SMS attack surface:
- Flash SMS messages which iNoobs can’t even see the sender of;
- stealth pings that can be done by everybody, not only 3-letter agencies;
- messages whose content can be replaced anytime;
- ability for the carriers to download arbitrary data to your phones;
- SIM memory overflow with Class 2 messages;
- fake voicemail notifications which don’t disclose the sender.
And now imagine that all this only relates to the very basic SMS structure. And we haven’t even touched the UDH yet. And when we do… Things will start getting really crazy. Plumbers don’t wear ties, and SMS capabilities don’t have firewalls.
Stay tuned!