Detection of Silent (Stealth) SMS Type 0 [$115 awarded]

[SecUpwN]

Law enforcement agencies are very often sending out so-called "silent SMS" (see this German article) which do not show up on a display of a target device, nor trigger any acoustical signal when received. But when they are delivered they generate a delivery receipt and, most importantly, are recorded in a data retention database together with the location of a mobile phone which received it. There's no need for an IMSI-Catcher then. Reliable detection of silent SMS will be crucial to the usefulness of AIMSICD.

A Silent SMS / Stealth SMS / Ping SMS is a Type0 SMS which is specified in GSM 03.40 as follows: "A short message type 0 indicates that the ME must acknowledge receipt of the short message but may discard its contents."

I have already contacted Michael (@SilentServices), the developer of the useful tool called HushSMS, which also enables its users to send out different types of SMS (including type Class 0, but without the location request). Check out his company Silent Services. I have bought his app a long time ago and am hoping he'll contribute some code snippets for detection of such SMS. Stay tuned.

The $115 bounty on this issue has been claimed at Bountysource.

[He3556]

very good! i bought it also two years ago :) but on my shitty HTC Wildfire nothing ever worked.

[xLaMbChOpSx]

@SecUpwN I will push some commits tomorrow that address some more existing bugs but also implements a Sms broadcast receiver to check for Class 0 messages, I just need to finish the preferences and modify the way the fragments are implemented to make it easier to show and hide individual pages in the app so if a Class 0 message is intercepted it can display information and notify of the threat.

[SecUpwN]

Thank you so much, @xLaMbChOpSx - I don't know what this project would be without you! 👍

[E3V3A]

@xLaMbChOpSx 👍

[mr1smith]

If this is implemented, I can actually test this in real network environment.

[SecUpwN]

What exactly do you mean by "real network environment", @mr1smith?

[mr1smith]

This means that I'll be able to test if this (detection of silent sms's for location tracking) works in commercial gsm network.

[xLaMbChOpSx]

I will be pushing a commit for this and other stuff tomorrow after my exam, I have another next Wednesday then I will be back.

[SecUpwN]

Do I smell awesome times ahead? THANK YOU, @xLaMbChOpSx!

[E3V3A]

@xLaMbChOpSx I'm not going to be able to sleep until then!

[SecUpwN]

Yet again another very awesome WIP-Release @xLaMbChOpSx! The new Silent SMS Detection feature has been implemented just fine, only two things that I noticed when testing the feature through a self-sent Silent SMS using HushSMS:

• The Alert has no "OK"-Button. Users must lick on the side of the screen to return to the main window.
• AIMSICD keeps displaying the Alert in the notification bar and does not return into normal state.

Other than that: Awesome work! @E3V3A, have you been testing this feature yet? Anything to add?

[E3V3A]

@SecUpwN I haven't, we need to post instructions for people how to test for Silent SMS! I'll download and test very soon.

[SecUpwN]

@E3V3A, I'm about to create an official User Guide for AIMSICD with Screenshots within our GitHub WIKI. Please stay tuned, this may take a few days. But testing for Silent SMS is really simple: Just download HushSMS and send yourself a Class-0 SMS. The latest WIP-Release will immediately display the alert.

[mr1smith]

OK, first impressions. Dection of standard class-0 sms's works, as stated above this can be tested with tools like HushSMS. Notification about such messages is always displayed by phone, even without AIMSICD and actual implemenetation depends on phone software.

However, detection of real "silent sms" messages which are used for location tracking (similar thing is implemented in HushSMS as sms ping, type0) is not working.

[E3V3A]

@mr1smith Thanks for info! Can you elaborate? (Or I'll have to go back and check what subclasses of class-0 and type-0 there are.)
@SecUpwN Can you provide a download link, or do we have to pay for that app to test?

[SecUpwN]

@E3V3A, check your PMs on XDA, please. 😈

[mr1smith]

A short message type 0 indicates that the ME must acknowledge receipt of the short message but may discard its contents.

http://www.etsi.org/deliver/etsi_gts/03/0340/05.03.00_60/gsmts_0340v050300p.pdf

Here is the document explaining silent sms dos attack:

http://mo.co.za/open/silentdos.pdf

I assume that the author of HushSMS could help in differentiating class 0 (flash sms) and type 0 (silent sms) messages.

[mr1smith]

SMS Class:

MT SMS - Class 0 (Displayed, but not directly stored)
MT SMS - Class 1 (Storing on DUT)
MT SMS - Class 2 (Storing on SIM)
MT SMS - Class 3 (Direct to Terminal Equipment)

Additional MT SMS Functionality:

MT SMS - Type 0

TS.11 Device Field and Lab Test Guidelines v.11.7:
http://www.gsma.com/newsroom/wp-content/uploads/2014/05/TS.11-v11.7.zip

[E3V3A]

@mr1smith Thanks for links. I remember some of those, but it was well over 2 years ago I last looked at those. I'll need to look again, because from what you say above, "class 0" is really just the flash SMS we were used to from Nokia days. What we need to look for, are the other ones.

[He3556]

here is a PDU Converter :) maybe useful sometimes... http://rednaxela.net/pdu.php

[mr1smith]

I think I already found the way to detect type 0 messages but I'm currently having problems with compiling the project with android studio. class 0 detection should be replaced with type 0 detection, each phone is already processing and notifying user about class 0 messages.

[E3V3A]

@mr1smith Can you be more specific, regarding the compilation problems, so that perhaps @xLaMbChOpSx or someone else could help you?

[mr1smith]

I was able to resolve compilation problems which were related to Pro Guard. Anyway, type 0 sms messages can be identified by Protocol Identifier (TP-PID) value (0x40 - bit 7: 0, bit 6: 1, bits 5-0: 0). However, detection seems to be impossible in a way we are currently trying to accomplish this since handling of silent sms's is done in baseband layer and these messages are never reaching application level at all.

Updating existing class 0 check:

if (sms.getMessageClass().equals(SmsMessage.MessageClass.CLASS_0))

with

if (sms.getProtocolIdentifier() == 0x40)

will still not detect silent sms's. I already tested this...

[andr3jx]

I took a look at logcat -b radio and it displays every received message as raw PDU data. If type 0 messages appear there we can detect them. But you can access logcat from an app only on rooted devices. I tried to send a type 0 message with HushSMS and their Xposed module but I get "generic error" regardless of what type of message I try to send.
I found an other Xposed Module named "Xposed Send Raw SMS" which should add the sendrawPDU method and there is even the possibility to send PDU data direct with AT commands. But I don't need to figure this out if you already can send type 0 message and can take a look at logcat.

[He3556]

@mr1smith yes, exactly it doesn't even reach the Application Processor. With a SIM-Proxy we could catch the signal if it reaches the SIM-Card. That is for example when a OTA Messages is send as WAP-Push. So its possible to install software on the SIM-Card, silently. But it would be better if we could catch it in the Baseband of cause :) so we are at the same point, like we are with AT Commands.

[andr3jx]

Really frustrating if this is really the case :(
Well at least on my MTK phone I can log all AT commands. Wouldn't be hard to analyze the logs for such messages.

[He3556]

i am just thinking now... if we could get some code working in the baseband that copys all incoming signals we need to the AP, we would be lucky. I know most Radios work with shared memory. But who can programm on that kind of Realtime-OS? I was also looking for some kind of open-source that would work on the Radio-hardware. But nobody could do it, as far as i saw it...

[scintill]

If you pass the -v time argument to logcat, it will include a timestamp for each line. If you process that timestamp, you have some options for dealing with this issue, such as saving the timestamps of SMS events that have already been logged/alerted, simply ignoring anything older than 5 seconds, etc. Maybe there is also an option to skip printing historical logs and only output new ones as they come, but I didn't see it.

[E3V3A]

Hi @scintill, nice to see you back. I think the time stamp is the best idea, which is why we already have a timestamp in the DB in the first place...

[ghost]

Yea I was thinking that about using the timestamp but will the timestamp remain the same for each line everytime we access the buffer?

This will also help with other detection methods like if we recieve an sms acknowledged in buffer and didn't receive in the sms broadcast receiver then it would indicate some sort of silent sms. If the logcat timestamp remains the same for each line everytime we access buffer then this method would be possible. At the moment I programmatically create one when sms spotted in logcat.

[SecUpwN]

@E3V3A, I know this sounds like I'm a freak, but would you actually please take some quality time to re-read this whole Issue and find out what needs to be implemented by @banjaxbanjo to actually close it as fixed or at least know where we need to continue with this (other than #491 for testing everything)?

[E3V3A]

Detection works in some cases, but (not for me) and will surely need to be re-tested after new DB structure #215 has been put in place.

[ghost]

@SecUpwN So far logcat sms detection is working from what basebands (phones) I have but is impossible for me to create a one for all sms detection unless I had a crap load of different baseband logs with incoming sms. My galaxy S5 detects wap/mwi/type0 and sony xperia detects mwi/wap.

As for automatic testing I wouldn't know where to find a web service like that.

[E3V3A]

The detection strings as shown in the Database Viewer are truncated instead of wrapped. Hard to tell what works...

[ghost]

@E3V3A these will also be removed in new update as we are going with a pre populated db so I wont be loading from json file. I think I might also add a boolean in database table to tell which string works in the database. This will come in useful for identifying with strings work on what phones.

[E3V3A]

Actually, being able to load these strings from a json file, may not be such a bad idea, especially for debugging. Also, I'm a little concerned how 's (single quotes) are treated...

[ghost]

@E3V3A Their currently is no issue with single quotes with the pre-populated database and when inserting a new detection string in the AdvancedUserActivity.java but I have tested and if you enter " a double quote it will cause an error. I haven't come across a detection string yet that has a double quote.

I've added a little check on the insert function to alert advanced users

if (edit_adv_user_det.getText().toString().contains("\"")) 
{
     Toast.makeText(getApplicationContext(), "String not added\n \" double quote will cause db error",   Toast.LENGTH_SHORT).show();
}

Here is the DB function that inserts the string

    public boolean insertNewDetectionString(ContentValues newstring) {
        // First check that string not in DB

        String check4String = String.format("SELECT * FROM %s WHERE %s = \"%s\"",
                DBTableColumnIds.DETECTION_STRINGS_TABLE_NAME,
                DBTableColumnIds.DETECTION_STRINGS_LOGCAT_STRING,
                DatabaseUtils.sqlEscapeString(newstring.get(DBTableColumnIds.DETECTION_STRINGS_LOGCAT_STRING).toString()));

        Cursor cursor = mDb.rawQuery(check4String, null);
        int count = cursor.getCount();
        cursor.close();
        if (count > 0) {
            Log.i(TAG, "Detection String already in Database");
        } else {

            try {
                mDb.insert(DBTableColumnIds.DETECTION_STRINGS_TABLE_NAME, null, newstring);
                Log.i(TAG, "Detection String Added");
                return true;
            } catch (Exception ee) {
                Log.i(TAG, "Detection String failed");
            }
        }
        return false;
    }

[E3V3A]

@banjaxbanjo Ok then there is a problem with the strings you use. I don't get any app detection, but with logcat they are there. I'm using these strings:

ZSMS1="Received short message type 0"
ZSMS2="SMS_ACKNOWLEDGE true 0"
ZSMS3="Inside qmi_client_decode_msg_async  Callback"

and detecting with:
(a)

# logcat -v time -b radio -b main |grep "Received short message type 0"
07-07 00:25:43.889 D/GsmSmsDispatcher( 1234): Received short message type 0, Don't display or store it. Send Ack

(b)

# logcat -b radio -b main |grep "SMS_ACKNOWLEDGE true 0"
D/RILJ    ( 1234): [66918]> SMS_ACKNOWLEDGE true 0

And sending a PING3: (0-byte WAP push), results in this:

I/RILQ    (  289): (0/289): RIL[0][qmi_cb] qcril_qmi_nas_unsolicited_indication_cb: invoked msg 0x4e

[ghost]

@E3V3A did you enter this in the detection activity

Received short message type 0

And set type0 from drop down menu

SMS_ACKNOWLEDGE true 0 is going to give you a crap load of popups. And its pretty strange that its not detecting since the strings are char for char the same. Did this work before the timestamp PR?

Also one thing I noticed and I had the same issue is delete AIMSICD from superuser and let it ask again for root when enabling sms detection this will probably solve your issue and any time I install a new dev I get this problem. 99% sure this is your issue

[E3V3A]

@banjaxbanjo

No it doesn't work. (And I didn't try before timestamp thing.) I tried:

1. Clear AIMSICD form SuperSU
2. Reinstall latest Buildozer
3. Run and go into Preferences and enter OCID key
4. Download OCID (ok)
5. Go into Preferences and check Enable SMS Detection
6. Go into Preferences and open Detection Strings and enter SMS_ACKNOWLEDGE true 0 and hit INSERT button.
7. Send Type-0 ping from other phone.
8. Wait...

Nothing!

EDIT!

Ooopah!! Restarting app and repeating (7-8) indeed results in detection! Fantastic!
But none of the other strings are detected...

A few problems noted:

a) Is there any timeout or time limit here? What is the minimum waiting time, to ensure detection?
I noticed my logcat is very spammy, filling buffer very quickly, thus recirculating and loosing any potential info. We could consider putting a filtered logcat in a specific ramdisk with much less spam in it.

b) There seem to be some app caching taking place, as I need to restart app AND toggling SMS Detection after adding a new string.

A few UX/UI things:

1. Remove default text in detection string entry "box"
2. When clicking an already entered string allow to edit it
3. Make string entry box font bigger.

[ghost]

@E3V3A hmm when I think of it the detection strings are loaded on app start so that would explain why it didn't detect new string before restart, I will look into it soon.

update

Sms strings are loaded when SmsDetector is started

ArrayList silent_string = dbacess.getDetectionStrings();

Still weird that the others strings are not detecting tho I will put in more _Log.i()_ to output events for you also when tackling this.

[E3V3A]

I think this is the problem:

String MODE = "logcat -v time -b radio\n";// default

The D/GsmSmsDispatcher string come from the main buffer.

We need to keep an annotation about all our strings and from what buffer they can be found in.

[ghost]

@E3V3A That's new I always thought all this low level baseband radio data would come from the logcat radio. I guess thats the problem can you email an edited version of your logcat EVA and send a wap wmi and a type 0 sms. (remove personal data) just need to lines from start of incomming sms to the end of the last bit of useful sms data.

We could consider putting a filtered logcat in a specific ramdisk with much less spam in it.

I really don't want to use a filter because the more baseband/phones add the bigger and more complicated the filter will become plus we will probably miss important data like the senders number etc, also where ye having issues before with users not having grep installed?. What you think?

a) Is there any timeout or time limit here?

There isn't really a time limit soon as the string is seen in log it alerts user.

Will I add an option in prefs menu for verbose logging

String MODE = "logcat -v time -b radio -b main\n";//Do we need system or event?

Detection Strings are loaded when SmsDetector is called

    public SmsDetector(Context newcontext){
        tContext = newcontext;
        dbacess =  new AIMSICDDbAdapter(newcontext);//SmsDetectionDbAccess(newcontext);

        //#  dbacess.open();
        ArrayList<AdvanceUserItems> silent_string = dbacess.getDetectionStrings();//<--loaded strings
        //#   dbacess.close();
        SILENT_ONLY_TAGS = new String[silent_string.size()];
        for(int x = 0;x <silent_string.size();x++)
        {
        SILENT_ONLY_TAGS[x] = silent_string.get(x).getDetection_string()+"#"+silent_string.get(x).getDetection_type();
        }
        prefs = newcontext.getSharedPreferences(AimsicdService.SHARED_PREFERENCES_BASENAME, 0);
    }

[E3V3A]

Added main buffer in 908ed98.

[E3V3A]

After the great HackTeam leak, it is apparent that it is very important that we detect various WAP push messages. Here they write:

WAP push messages are not always sent, some providers block them. 
Also, some phone devices do not support the WAP stack (e.g. some 
HTC and Motorola models) and Cyanogenmod blocks WAP push.

And here:

HackingTeam will then provide a URL where the exploit is hosted. A link 
pointing to the exploit can finally be sent to the target, for instance via 
SMS or email. The full exploit will be served exclusively to 
Android 4.0.*- 4.3.* devices. If the exploit URL is visited from a different 
browser or device no payload will be executed and the redirect will 
happen immediately.

[ghost]

@E3V3A Some stuff here also https://github.com/hackedteam/fuzzer-android

[E3V3A]

@banjaxbanjo

a) Is there any timeout or time limit here?

There isn't really a time limit soon as the string is seen in log it alerts user.

No you're missing the point. How many times a minute, is the logcat -b main ... executed?
When SMS detection is on, my phone runs very hot and laggy, we're overloading something...

[ghost]

@E3V3A ah I see, I continously read and keep buffer open if I had to put a timer to check every x seconds minutes we would prob miss data and Id say the average users phone wouldn't have the high logging like you have set eva.

It's not very cpu intensive from short test Ive done. What you think?

[E3V3A]

This thread is getting too long!

PLEASE CONTINUE DISCUSSION HERE!