Detection of Silent (Stealth) SMS Type 0 [$115 awarded] about android-imsi-catcher-detector HOT 166 CLOSED

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

from android-imsi-catcher-detector.

@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.

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

@xLaMbChOpSx 👍

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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.

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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?

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

@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.

from android-imsi-catcher-detector.

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.

from android-imsi-catcher-detector.

@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?

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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.

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

@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.

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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.

from android-imsi-catcher-detector.

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

from android-imsi-catcher-detector.

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...

from android-imsi-catcher-detector.

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.

from android-imsi-catcher-detector.

@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.

from android-imsi-catcher-detector.

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.

from android-imsi-catcher-detector.

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...

from android-imsi-catcher-detector.

@andr3jx At commands between BP and AP? or the log of all incoming signals at the radio part?

from android-imsi-catcher-detector.

Again, I believe getting AT access is key. It's late here and I'm currently out of ideas, but there are still several search paths we have not explored in trying to get AT command. Unfortunately I don't have a current working cross compiler, or I'd try to modify some of the binaries I mentioned before, i.e. ipctool and radiooptions etc. (I can't find where I mentioned these, because the github search function still sucks!)

from android-imsi-catcher-detector.

hello @E3V3A i have this URL i want to show you for quite a while. Its maybe old information for you, i just want to be sure it is, so if you have the time pls check. https://groups.google.com/forum/m/#!topic/android-platform/tVyNMnXtcEI

from android-imsi-catcher-detector.

this is the post i prepared for our new thing :) On GoogleGroups i found some guys who try to get data from the FieldTest app

I copied a few examples here – i don’t know if this is new information, but i thought it is quite interesting….

Chrisnew wrote:

Hi Felix the FieldTest app on the XDA forum is signed with test keys. To run it on a production HTC One X it needs to be signed with the live keys otherwise it really shouldn’t work. Unless you have the live HTC Android platform key (!) to sign it with you will need to flash on something like the CyanogenMod firmware or your own. Then you will have a firmware signed with the same test keys. You’ll need to do this for you own stuff but you could extract HTC’s FieldTest from a normal production phone and use that instead of the XDA one without flashing. I’m surprised the One X doesn’t already have it though.

Shrawan Gupta wrote:

Thanks Felix for your response. I am able to access Phone object using PhoneFactory.getDefaultPhone() for my targat device HTC Hero (2.3.3).

1. I have called invokeOemRILRequestString() & passed the AT command:

String[] commandString = {“UNIAT”, “AT+CCED?\r”};
Message msg = mHandler
.obtainMessage(EVENT_RIL_OEM_HOOK_CMDSTR_COMPLETE);
// Send request
mPhone.invokeOemRilRequestStrings(commandString, msg);

My observation: I am getting proper response for AT+CSQ?, but always getting Rx::> 4\r for AT+CCED?.
Ques 1: Do I need to always pass “UNIAT” in 1st argument & for what is means for?
Ques 2: Can anyone plz let me know if I am on wrong track.

1. I have called invokeOemRILRequestRaw() & passed the hexa decimal byte array as a input:

/*
* Sending request to RIL
*/
public void onRun(View view) {
// Get the checked button
int idButtonChecked = mRadioGroupAPI.getCheckedRadioButtonId();

byte[] oemhook = null;
switch (idButtonChecked) {
case R.id.radio_api1:
oemhook = new BigInteger(“0000000008000000010000005f000000″, 16).toByteArray();//hexStringToBytes(“0000000008000000010000005f000000″);
break;
case R.id.radio_api2:
oemhook = new BigInteger(“0100000000000000″, 16).toByteArray();
break;
case R.id.radio_api3:
oemhook = new BigInteger(“0200000000000000″, 16).toByteArray();
break;
case R.id.radio_api4:
// Send OEM/AT command string given by user
break;
default:
log(“unknown button selected”);
break;
}

if (idButtonChecked != R.id.radio_api4) {
Message msg = mHandler
.obtainMessage(EVENT_RIL_OEM_HOOK_CMDRAW_COMPLETE);
mPhone.invokeOemRilRequestRaw(oemhook, msg);
responseTextView.setText(“”);
} else {
// Copy string from EditText and add carriage return
String oemhookstring =  ((EditText) findViewById(R.id.edit_cmdstr))
.getText().toString() + ‘\r’ ;

String[] commandString = new String[2];
commandString[0] = “UNIAT”; //In 1 of post, citus told to add {“UNIAT”, “AT$GSM?\r”};
commandString[1] = oemhookstring; //AT-command/String from user input
// Create message
Message msg = mHandler
.obtainMessage(EVENT_RIL_OEM_HOOK_CMDSTR_COMPLETE);
// Send request
mPhone.invokeOemRilRequestStrings(commandString, msg);
responseTextView.setText(“—Wait response—”);
}
}

/*
* Parsing the response coming from RIL
*/

void displayRILRawResponse(byte[] byteArray){

ByteBuffer bb = ByteBuffer.wrap(byteArray);
bb.order(ByteOrder.LITTLE_ENDIAN);

System.out.println(“ARFCN: ” + bb.getInt());
System.out.println(“LAC: ” + getStringFromBytes(bb, 20));
System.out.println(“RAC: ” + getStringFromBytes(bb, 20));
System.out.println(“MNC/MCC:” + getStringFromBytes(bb, 20));
System.out.println(“RSSI:” + bb.getInt());
System.out.println(“Ncell Info1:” + getStringFromBytes(bb, 20));
System.out.println(“Ncell Info2:” + getStringFromBytes(bb, 20));
System.out.println(“Ncell Info3:” + getStringFromBytes(bb, 20));
System.out.println(“Ncell Info4:” + getStringFromBytes(bb, 20));
System.out.println(“Ncell Info4:” + getStringFromBytes(bb, 20));
System.out.println(“Ncell Info6:” + getStringFromBytes(bb, 20));
System.out.println(“RX Quality:” + bb.getInt());
System.out.println(“Frequent Hopping:” + bb.getInt());
System.out.println(“Last registered network:”
+ getStringFromBytes(bb, 20));
System.out.println(“TMSI:” + getStringFromBytes(bb, 20));
System.out.println(“Periodic Location Update Value:” + bb.getInt());
System.out.println(“BAND:” + bb.getInt());
System.out.println(“Channel In USe:” + bb.getInt());
System.out.println(“RSSI 1:” + getStringFromBytes(bb, 20));
System.out.println(“Last cell release cause:” + bb.getInt());
}

My observation: I am getting the (272-500 digit)long hx output similar to as mentioned by Joao but after formatting it in my displayRILRawResponse() most of the fields are zero (0).
Question: Am I passing some wrong input value to mPhone.invokeOemRilRequestRaw() ?

Shrawan Gupta wrote:

My end-to-end approach on fetching the low level information for my rooted HTC Hero (2.3.3) & hence want to share it.

RILRsponse 4

FelixG wrote:

I decided to write complete open source verion of the whole HTC FieldTest app. I am just coding under the Nexus One and HTC One S. The European version of the HTC One X was not possible to adapt because it has no Qualcomm chipset. But I have seen, that there are some changes in the responses if I compare my app with the FiledTest app on the HTC Magic 32B.

After a long interval, back to Android RIL. I’ve managed to fetch and parse a GSM Page request from the ril. Using invokeOemRilRequestRaw method in com.android.internal.telephony.Phone.

The approach - see URL in the post before

from android-imsi-catcher-detector.

@He3556 Probably I was wrong. AT logs are like from logcat, but there are memory dumps which I didn't manage to read.

from android-imsi-catcher-detector.

just 1 sec to the cat log, just that i understand it right.

On the picture is the red line for silent-sms, radio signaling like paging, location update, cell selection and so on... the blue line is the signaling for the SIM like IMSI-request, Authentication A3/A8 and A/5 for encrypting audio. And the green line is all the rest, where the telephony API handles the communication (usual stuff - documentated on the Andoid developer webside) + the part you can see on that vendor APPs like filed-test on HTC. We could get this infos with AT commands somehow into our App. Is that right? But where is the log from? - can we get a log of the part where all 3 lines comes in?

from android-imsi-catcher-detector.

@He3556 Yes, I have seen that, but since I'm handicapped with the Java parts, it's not much I can do, apart trying to dig up the correct SMD map for various CPs or find the correct way to talk to smd0.
Another issue is that, as I mentioned in both XDA thread and another way in #23, we could try to use some service calls. However, I was not able to format the AT command correctly, because it may require UNICODE (UTF-16LE) formatting from command line and my shell control characters & readline is broken due to SELinux/KNOX BS. So I could not test this.

Something like:

String[] commandString = {"UNIAT", "AT+CCED?\r"};

We need to cover with an exhaustive and well organized search.

Also xLaMbChOpSx has already implemented a lot of the OEM_HOOK_RAW related stuff, but he was having trouble implementing Ilarianov's multiril-client method with the previously working AT interface. This was discussed in #27 and #66. Unfortunately I was under the false impression that most these problems had been resolved (but not activated) in the latest WIP release. This was my error.

Sorry I can't provide a quick answer to the AT Command injection it is unfortunately something that although simple in principle is not so easily achieved within our application, I have spent a significant amount of time attempting to extend upon the MultiRil work we are using for the Samsung Service Mode OEM_RAW requests and have had varying degrees of success but still not been able to receive any form of response.

Even if I do successfully implement this it will unfortunately be specific to Samsung devices, I would love to be able to spend time on trying to get some form of root terminal responses instead of the MultiRil method but really don't even know where to start I can go back over the xda threads about this and devote my time to trying to receive a response through the terminal on the device.

And later:

... it currently DOES NOT FUNCTION hence the reason it is disabled, I have attempted to extend the MultiRil implementation to incorporate the OEM_STRINGS method and also investigated how to convert the AT command string into an acceptable OEM_RAW request but have not been successful.

Thus to summarize the option we need to search:

• Find and use pre-existing OEM java application
• Find how to use a proper socket on: /dev/socket/rild-debug or /dev/socket/rild to get direct radio access
• Find if there are any /dev/ serial character device to directly use with echo etc as shown in @He3556 links above, and elsewhere.
• Find out how to properly code ipc messages into/with ipctool to send directly to modem. Some older versions of ipctool also claim to have AT support, but only works on some devices.
• Build our own AT binary from scratch (but we have many examples) that can use whatever RIL devices/sockets we have. (Some code in replicant rep's and elsewhere.)
• Ask the Replicant guys if they care to help us out.
• Use the SIM card AT command interface, as mentioned in xda thread. (I have no idea how to do this, but may require sending formatted command using the STK API.)

from android-imsi-catcher-detector.

@andr3jx What memory dumps? Where/how do you get them? Maybe I can fill in the blanks.

from android-imsi-catcher-detector.

ok @E3V3A thanks for this update - i have to read it a few more times :) then i can put it into our documentation and stuff. But last question :) how do we know what exactly we are getting from a direct radio access? why should it be possible to get data from that "red and blue" part to the AP? The Baseband handles everything alone and passes only the voice call and sms... to the AP. The most we can get is that info of Apps like Field-Test, right? Of cause this would be great, i am just asking...

you can write back tomorrow, its late already

from android-imsi-catcher-detector.

@He3556 You asked where the logs come from. The logs for radio come from RIL, or isn't this answer specific enough? So Silent SMS don't reach RIL?
@E3V3A You know I did some digging with MTKlogger. And I showed you this picture: https://i.imgur.com/8P5oKjM.png . The .dmp files interest me. I also found some MTK docs where they explained how to read L1 dumps.

from android-imsi-catcher-detector.

@He3556

Q: Why should it be possible to get data from that "red and blue" part to the AP?

A: Basically there are 2-3 ways.

1. Google need access to all variables for future development of API. Thus the shared memory device (SMD) should present a memory image where all possible future relevant radio data are present. (just as we saw in the old google support thread above.)
2. The USB mux when set to BP (aka CP). let's us see everything (GSM-TAP + more) on the debug port, as used by QXDM and Xgoldmon. There should be a way to re-route this to AP (if not already there.) That would allow us to use a USB splitter/spy and send part of the output to a serial device of our choice.
3. AP certainly is using the AT stuff all over the place, so we know there's full AT access to BP somewhere. But the AT command Processor (ATCoP) contains full access to BP (on the XMM modems) and very likely also in the Qualcomm ones.

@andr3jx
Yes, be as specific as possible so other people can follow. What exact /dev/device and what HW are you using? MTK is much more AT friendly, as i believe (and somebody correct me if wrong) they don't use SMD, but /dev/"char dev", for AP-CP communication.

from android-imsi-catcher-detector.

@andr3jx thanks, there is a ril part of Android and a vendor ril which communicates with the baseband. But like @mr1smith i am also sure these sms don't leave the baseband, so there is no log from the Ril. Good night everybody, ceeya later

from android-imsi-catcher-detector.

The best way to test for "reach-ability" is by connecting your phone as a modem to PC via USB. You need to go into ServiceMenu and make the (MUX) mode change from USB:AP to USB:CP. (On some devices there's both). You can then set the unsolicited AT messages to be more verbose and select what type of messages you get. You should get a lot and hopefully also SMS type messages... But this would be very modem dependent.

from android-imsi-catcher-detector.

@E3V3A Ok, I managed to READ the dumps I showed you.
I took again a look at https://www.dropbox.com/sh/3dr3bu0z4cq46tc/AAAH4fAV5uSP6zRTgjnAEcmMa/CatcherLogging.pdf
All I needed to do is to start up my Windows XP machine, find the MTK Catcher software and install it. I found a way to load the dmp files and it shows me for example a "Sys Trace" with interesting commands I don't know about. I will look deeper what this soft can do. I should have done this 2 months ago, but it is extremely annoying for me to work with XP.

from android-imsi-catcher-detector.

Great discussion going on here, I really enjoy following along. Keep that flow movin'! @andr3jx, I perfectly understand what you mean but also feel you're on a hot path. Keep digging! THANK YOU!

from android-imsi-catcher-detector.

i googled for MTK Catcher - that is cool shit, i need to read more about it later,,, thx @andr3jx

from android-imsi-catcher-detector.

@andr3jx What device do you have and what AOS is it running? I'm thinking to get my hands on an MTK based device with a recent AOS on. I'd like to see how AOS uses the modem on those. Also can you provide a download link (or exact google search you used to find it) for that MTK Catcher. (Why they choose to call it that, I have no idea...)

Also I hope to finish and post my writeup on how to install and use the xgoldmon and wireshark soon.

from android-imsi-catcher-detector.

I got Wiko Darkmoon running Android 4.2.2. If you want to get a cheap MTK device you can go for Wiko Ozzy (70 EUR) or Wiko Fizz (90 EUR). You can get them at least on german and french amazon - so I don't know if they are available where you live. You can download MTK catcher with manual Here. Today I found out it also runs on Windows 7 - not only on Windows XP (but all screenshots I saw were taken on XP). EDIT: There also phones cheaper - Cubot C9+ has MTK6572 and costs 54 EUR.

from android-imsi-catcher-detector.

Hey @E3V3A, @andr3jx, @He3556 and @xLaMbChOpSx, I have just received a friendly message of @c0rnholio, the creator of HushSMS that we shall not confuse Class 0 SMS with Type 0 SMS:

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."

VS.

A Class0 SMS is a Flash-SMS / Popup SMS / Alert SMS: "Indicates that this message is to be displayed on the MS immediately and a message delivery report is to be sent back to the SC. The message does not have to be saved in the MS or on the SIM card (unless selected to do so by the mobile user).

So please be aware that we are actually looking for TYPE 0. I added this to the OP and will edit our WIKI shortly. Hope we'll find a way to successfully detect Type Zero SMS. Thank you for your attention.

from android-imsi-catcher-detector.

heyho @E3V3A, @SecUpwN , @He3556,
the last days I tried to make my phone work with MTK Catcher.

I connected my phone with USB cable to my Windows XP PC. At first the phone was not detected. I searched for all drivers that I could need. I uploaded everything I found HERE.

The result was that my phone worked over adb. I tried to connect using "Smart Phone USB Logging" but it didn't work. There are screenshots in the manual which show how I need to switch from SDCARD logging to USB logging, but I didn't find such option. ADBrelayer popped up, and this error appeared , log was not helpful - It tries to create a file but there is no directory /sys/module/android and I didn't manage to create it there. It seems it is read-only or there is no permission to write.

Next I try to get a RS232-cable and connect the phone using UART to COM-port as shown in the manual.

I searched the whole net for all docs I could find about MTK catcher (not so easy to download them from chinese websites). Check them out if you want to know more about how it works.

I could load the L1 dump, but it didn't display any info except how many L1 bytes the dump has.
In this document it says "Layer 1 traces can be set to capture L1 trace messages. However, while these trace messages are saved, they are not viewable by the user." Maybe there is an other way to obtain info from them. But I could open PS dump. You see in Wireshark-style log "traces" with different types of low-level events with different values. I did the dump while I did a call for 1 minute and it has generated 7000+ traces! Sick! I can't upload the log because of privacy issues. But I did small search for "ciph" in the logs and here you can see what there was.

from android-imsi-catcher-detector.

@andr3jx That is very good info, that I wish you could describe in more detail, in our XDA thread, and how you went about doing all this. It's certainly not clear from above. Also, I'm very busy right now, so I cannot respond properly. But I urge everyone to post your findings in our XDA thread. Github is not meant for this and useful info can easily get lost here. Thanks in advance, and I'll be back soon.

from android-imsi-catcher-detector.

@xLaMbChOpSx, I'm sure you have noticed that I merged your latest commit on improving Silent SMS detection. There are some things that I would like you to change with a follow-up commit (my hands are itching to mess up the code) 😄

• We are essentially looking out for SMS TYPE 0 and NOT CLASS 0
• (just a quick reminder: Type 0 = Silent SMS, Class 0 = Flash SMS)
• Within our codebase, multiple files say stuff like ClassZeroSmsDetected. Can you change that into TypeZeroSmsDetected, please? All references reagrding "Class 0" should be transformed into "Type 0" if we really want to follow our focused mindset. It is when I discovered that you use the term "Class 0" in our code that I began to replace "Silent" with "Flash" yesterday.

As a result of the confusion, we also currently have a "wrong" notification saying "Class Zero Silent SMS Detected" - it should say "Type Zero Silent SMS Detected". I added the difference between Class 0 and Type 0 to our User Guide (see Special SMS Interception. Thanks for updating the code to remove all Class 0 references, I just want to avoid further confusion to other contributers and developers.

from android-imsi-catcher-detector.

@E3V3A Ok, I will post my findings in our XDA thread! I have good news! I figured out how to use MTK Catcher in live monitoring mode! I can attach my phone with usb and see low level events live! Great! I will explain later how I did this, now time to sleep, spend much time on this.

from android-imsi-catcher-detector.

Ok I have updated the Class Zero references to reflect Type Zero and testing with HushSMS does not fire the broadcast receiver I have left a log call which will show details of any Sms received (Class and PID) but absolutely nothing for the Type 0. Kitkat does force the Type 0 message to be displayed in your Messages but it is not being routed as per a standard Sms.

I will look at this further after I have tackled some more bugs but I am thinking we may need to consider the addition of an Xposed module to hook some of the hidden API methods to intercept these types of messages correctly.

Let me know your thoughts.

from android-imsi-catcher-detector.

Thanks for digging into it, @xLaMbChOpSx. Regarding the consideration of having to have an Xposed Module to digg deeper, I'd prefer to have everything we need in our own unified App. Maybe we can prompt users that ROOT is needed for this to function? I know @E3V3A aims to let our App to be working for people who are not rooted, but I think in certain cases like this it might be inevitable.

from android-imsi-catcher-detector.

@xLaMbChOpSx Hi, you wrote above:

Kitkat does force the Type 0 message to be displayed in your Messages but it is not being routed as per a standard Sms.

Can you look at their code to see how that (routing) is done? If you could also provide a link to that code, I could also have look at it. Oh and another thing, you said:

Even if I do successfully implement this it will unfortunately be specific to Samsung devices, I would love to be able to spend time on trying to get some form of root terminal responses instead of the MultiRil method but really don't even know where to start I can go back over the xda threads about this and devote my time to trying to receive a response through the terminal on the device. [And later] .., I have attempted to extend the MultiRil implementation to incorporate the OEM_STRINGS method and also investigated how to convert the AT command string into an acceptable OEM_RAW request but have not been successful.

Two comments:

1. Can you send me via any way possible (PM, email or XDA etc.) some more details of what is happening and why it fails? From what little I have understood, OEM_STRINGS are almost never used, and possibly deprecated. All AT's I've seen in OEM Java code has been sent in RAW, byte-by-byte. But I could of course be wrong here as well...
2. If we can manage to use the multi-RIL implementation instead of direct device one, I really think that is the preferred way, since it should be (?) more portable across devices, than using specific /dev's.

And also to @SecUpwN, I thought we had already agreed that having a rooted device should be required for full functionality, but not necessary for installation?

Finally, lets move the discussion of the details about the two methods to their own issue threads:

1. Muiti-RIL and OEM_HOOK_RAW methods in #27, and
2. AT command interface in #23. (using /dev/XXX and/or OEM_HOOK_RAW)

from android-imsi-catcher-detector.

@E3V3A, thanks for the clarification. That's what I actually meant. 👍

The current HushSMS actually seems to be capable of displaying a warning about receiving a Type 0 Silent SMS which has been sent through HushSMS. Too bad c0rnholio has no time to help us on improving this. Side-note: I've noticed that HushSMS displays a Protocol Identifier (PID): 64 when receiving Silent SMS. Also, the Protocol Data Unit seems to stay the same one. Couldn't we detect Silent SMS based on their PID? What else can I do (via terminal) to drive development?

from android-imsi-catcher-detector.

@SecUpwN @E3V3A
HushSMS can't detect Type0: Type0 aka Silent Ping cannot be detected as these are handled in the baseband

Installed HushSMS with Xposed Module on my Nexus7 3G (4.4.4), but Type0 ping generated visible empty message, so I changed ROM to 4.2.2 to make this work.

Ping3 and Ping4 leave traces in radio logcat.
For example: "Unsupported SMS data coding scheme 4"

Type0 SMS don't leave traces in logcat. But I could analyze them using MTK Catcher.
Side channel attack: We need to find where some kind of information is "leaked" when SMS get received.

On my MTK device: In radio logcat multiple AT commands are send when (silent) SMS/Calls are received: +ECIPH:1,0,1,255 (some kind of ciphering check). Approach: Monitor phone for different events which generate this AT command and detect when no event was registered when the command was send. Unfortunately it is very baseband specific if some kind of traces are generated when silent SMS are received (on my Nexus7 3G no traces). Everybody needs to check by sending a Silent SMS to himself.

Do silent SMS leave traces on SIM card? I observed in MTK Catcher "Writing Requests" to SIM (exactly after the SMS was received). I wanted to do here more research but I can't use MTK Catcher over USB anymore (I want to try SIM reader, but no chance) - something messed up the debugging procedure, I get errors, even full ROM reflash didn't help. It would be good to compare the data on the simcard before and after the message was received and look if we can access it using AT-commands. Is there any way to get any additional info from baseband which can provide evidence that "something happened"?

from android-imsi-catcher-detector.

Type0 SMS don't leave traces in logcat.

Interesting. When I hook up my phone to my computer and run logcat -b radio when sending a Silent SMS to myself, I get very unique responses in those logs which hardly seem to change. A short example:

V/RILJ    ( 1578): [UNSL]< UNSOL_OEM_HOOK_RAW XXXXXXXXXXXXXXXXXXXXXXXXXXXXX..
D/RILJ    ( 1578): [UNSL]< UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED
D/RILJ    ( 1578): [4685]> OPERATOR
D/RILJ    ( 1578): [4686]> DATA_REGISTRATION_STATE
D/RILJ    ( 1578): [4687]> VOICE_REGISTRATION_STATE
D/RILJ    ( 1578): [4688]> QUERY_NETWORK_SELECTION_MODE
D/RILJ    ( 1578): [4688]< QUERY_NETWORK_SELECTION_MODE {0}
D/RILJ    ( 1578): [4687]< VOICE_REGISTRATION_STATE {1, 0587, 04ba1c6b, 3, null, null, null,..}

Please give me some further advice what exactly to look for or even some commands I could paste into terminal to catch valuable Information during receival of such Type 0 SMS. Thank you, @andr3jx.

EDIT: Discovered a line in the logfile I am wondering about. What is that and why is it disabled?

V/RILJ    ( 1578): Incoming UUS : NOT present!
D/RILJ    ( 1578): InCall VoicePrivacy is disabled

from android-imsi-catcher-detector.

@SecUpwN
I advice you to be careful with such logs, your number(or other identifiable info) could be encoded in this hexchars. You should send a silent SMS from your phone to another phone. Then you should send a silent SMS to yourself. Compare the logs if they differ somehow.

Info about "VoicePrivacy" can be found here.

from android-imsi-catcher-detector.

Thanks for your recommendations. Which tool do you recommend for diffing on Linux, @andr3jx?

from android-imsi-catcher-detector.

@SecUpwN
If you really need to use diff, just google "diff online", there are many sites where you can compare text.
But I think you won't need it. There is not that much in radio logcat. You don't need to log long. Start logging, send silent ping to your number, wait for delivery confirmation, stop log. Then do the same, just send a silent ping now to another number, compare the logs.

from android-imsi-catcher-detector.

@andr3jx, if I issue logcat -b radio, I get pages of logs! Or shall I use something else?

from android-imsi-catcher-detector.

@SecUpwN, if you issue it like that you get the whole buffer. Install the app catlog, it is very easy to use. Change in catlog settings log type to radio and use the record function, so it can record logcat in the background.

from android-imsi-catcher-detector.

@andr3jx, I now have logged receival of a Silent SMS on an HTC One as well as an HTC Desire X. Both logs seem to completely differ in content and size. While the log of the HTC One is huge, the other is tiny. Is there anything specific I can filter for that would help us with detection?

from android-imsi-catcher-detector.

@SecUpwN Maybe my explanation was misleading. You need only one phone with logcat, which you use for sending and receiving silent SMS.

Log 1: You send a silent sms to yourself (number of the phone where you use HushSMS, sender and receiver number is the same).
Log 2: You send a silent sms to any other phone. You log again this on the sender side, where you use HushSMS.
--> Compare the logs (compare what happened between SMS sending event and delivery confirmation).

from android-imsi-catcher-detector.

Oh ok, now I got it. While I now have the differences in front of my eyes, I compared and found this:

This is seems to be when the Silent SMS is sent out:

07-15 05:56:58.862 D/RIL_ImsSms(11177): sendText
07-15 05:56:58.892 D/GsmSMSDispatcher(11177): sendSms:  isIms()=false mRetryCount=0 mImsRetry=0 mMessageRef=0 SS=0
07-15 05:56:58.892 D/RILJ    (11177): [4025]> SEND_SMS
07-15 05:56:58.892 D/use-Rlog/RLOG-QC-QMI(  198):  Getting maximum message length
07-15 05:56:58.892 D/use-Rlog/RLOG-QC-QMI(  198): Encoding buffer 
07-15 05:56:58.892 D/use-Rlog/RLOG-QC-QMI(  198):  Setting up transaction 
07-15 05:56:58.892 D/use-Rlog/RLOG-QC-QMI(  198):  Sending message 
07-15 05:56:58.892 D/use-Rlog/RLOG-QC-QMI(  198):  Releasing Transaction 
07-15 05:56:59.452 V/RILJ    (11177): [UNSL]< UNSOL_OEM_HOOK_RAW XXXXXXXXXXXX..

...[cut more messages]...

07-15 05:57:01.915 D/RILJ    (11177): [4025]< SEND_SMS { mMessageRef = 118, mErrorCode = -1, mAckPdu = null}
07-15 05:57:02.035 D/RILJ    (11177): [UNSL]< UNSOL_RESPONSE_NEW_SMS

And this happens when receiving the Silent SMS:

07-15 05:57:02.075 D/GsmInboundSmsHandler(11177): Received short message type 0, Don't display or store it. Send Ack
07-15 05:57:02.075 D/RILJ    (11177): [4038]> SMS_ACKNOWLEDGE true 0
07-15 05:57:02.075 D/GsmInboundSmsHandler(11177): leaving Delivering state
07-15 05:57:02.075 D/GsmInboundSmsHandler(11177): entering Idle state
07-15 05:57:02.075 D/use-Rlog/RLOG-QC-QMI(  198):  Getting maximum message length
07-15 05:57:02.075 D/use-Rlog/RLOG-QC-QMI(  198): Encoding buffer 
07-15 05:57:02.075 D/use-Rlog/RLOG-QC-QMI(  198):  Setting up transaction 
07-15 05:57:02.075 D/use-Rlog/RLOG-QC-QMI(  198):  Sending message 
07-15 05:57:02.075 D/use-Rlog/RLOG-QC-QMI(  198):  Releasing Transaction 
07-15 05:57:02.325 D/use-Rlog/RLOG-QC-QMI(  198):  Calling cooked async Callback 
07-15 05:57:02.325 D/use-Rlog/RLOG-QC-QMI(  198):  Inside qmi_client_decode_msg_async  Callback 
07-15 05:57:02.325 D/RILJ    (11177): [4038]< SMS_ACKNOWLEDGE 

Indeed interesting that it says in complete words Received short message type 0, Don't display or store it. Send Ack - Not sure if we couldn't add monitoring for this wording? Just a thought.

This is coming back after sending it to another phone:

07-15 05:59:04.484 D/RILJ    (11177): [UNSL]< UNSOL_RESPONSE_NEW_SMS_STATUS_REPORT XXXXXXXXXXXX..
07-15 05:59:04.534 D/RILJ    (11177): [4133]> SMS_ACKNOWLEDGE true 1
07-15 05:59:04.534 D/RILJ    (11177): [4133]< SMS_ACKNOWLEDGE 

@xLaMbChOpSx, I hope that what I do here helps somehow. Awaiting further instructions.

from android-imsi-catcher-detector.

@SecUpwN Yes, what you do helps. I haven't even started to look at silent SMS yet, so this is a great reference. Then we can try to compare notes across different devices.

from android-imsi-catcher-detector.

@E3V3A, to me it seems like catlog does a great job of logging just everything we need to solve this Issue. Tell me, is there anything specific that we need to enhance further detection of Silent SMS besides the things I previously posted? Anything else I can do? How about my question to monitor for strings like the more than obvious Received short message type 0, Don't display or store it. Send Ack?

from android-imsi-catcher-detector.

Monitoring strings in logcat is a bad and very desperate idea, as every different RIL out there probably also produce slightly different logcat entries, if any at all. But what do I know, I only have a couple of devices, so if you wanna go ahead and look up and document what happens on a myriad of Androids, no one will stop you. (;

from android-imsi-catcher-detector.

I consider monitoring strings of the radio log to be just an additional measure to detect Silent SMS, certainly not the main and preferred one, especially because I'm sure that advanced IMSI-Catchers could suppress such strings or even insert fake ones. @E3V3A, I've tested receival of a Silent SMS on another phone, an HTC Desire X and discovered that the message Received short message type 0, Don't display or store it. Send Ack is NOT present while receiving a Silent SMS. So monitoring strings really seems a bad idea.

Strangely though, there are numerous IMSI requests like the following in the logfile:

07-15 18:16:06.259 D/RILJ    (1693): [0034]< GET_IMSI 
07-15 18:16:06.259 D/GSM     (1693): [SIMRecords] IMSI: xxxxxxx
07-15 18:16:06.259 D/GSM     (1693): [IccCard] Broadcasting intent ACTION_SIM_STATE_CHANGED IMSI reason null

With keeping in mind that my overall paranoia is not really calmed down with every new revelation on wiretapping, is this phone already tapped? What would be the "ultimate method" to detect a Silent SMS for good? I need instructions on what to look for! What else can I do to help you, @xLaMbChOpSx?

from android-imsi-catcher-detector.

@SecUpwN Thanks for the logs, great to know that there are phones where silent sms leave good traces. I don't think IMSI-Catchers are able to suppress this.
@E3V3A Of course it is not an ideal solution, but in my opinion it's not that bad. Other things we can look at are: In Replicant there is an open source implementation of the Samsung vendor RIL and IPC protocol. Can we learn from them how to monitor the vendor RIL? Or we could even replace the RIL with the opensource implementation (RIL test) if the phone is compatible and give an option to toggle between the proprietary and opensource RIL.

Another thought I had, was to go deeper. It is possible to monitor the data between the kernel and the vendor RIL (RPC/IPC data). The protocol might be proprietary but It should be not hard to identify data which gives evidence about SMS receiving. This has already been done, but for activity monitoring in this project - hooks in the kernel, this is also what SELinux does: AppScope: Slides (page 12), Paper, Video

But I don't think that we are experienced enough to deal with kernel, and even if we find out how to monitor Samsung RIL there will be many unsupported phones. So back to logcat. What I propose is to make a free version of HushSMS only to send Type0 SMS or find one, we can test this app. People should do the same what SecUpwN did, check the logs, and inform us for which strings we have to look for (if there are any), give info about their phone / RIL and we add it to a list. BTW I checked the logs of an old GT-I5800, it displays the complete SMS PDU of the Silent SMS, this is the best what could happen, because we can decode from the PDU the number of the sender. Monitoring the logcat for different type of messages can be done by executing something like: ((logcat -v time -b radio -s AT:D GSM:D | grep -E "message1|message2") > /sdcard/radiolog) &. I think logcat should be relative battery friendly. The app can check the file for new messages and alert the user if there are new records.

Last thing I want to show you is this page. Silent SMS update location data in the VLR database. There are online services which give you the option to do different lookups on the phone and determine in which area a phone is. How it works is also described in this talk, slides here. So my point is that these Silent SMS are not necessarily send for IMSI-Catchers, but to get a recent location for a lookup. In gsmmap.org reports this is covered under "User tracking". There are networks which have good and bad protections against this type of tracking. We could show information from gsmmap.org to inform the user about security of the network he uses.

from android-imsi-catcher-detector.

@andr3jx, your approach to go deeper makes sense. But I'd rather go much, much deeper! 😄

I've captured a full logcat -b radio from the mentioned HTC Desire X and noticed this:

D/GSM     ( 1693): [GsmDCT] overall state is IDLE
D/RILJ    ( 1693): [4791]< SCREEN_STATE error: com.android.internal.telephony.CommandException: GENERIC_FAILURE
D/GSM     ( 1693): [GsmDCT] handleMessage msg={ what=270368 when=-1ms arg1=1 }
D/GSM     ( 1693): [GsmDCT] handleMessage msg={ what=270368 when=0 arg1=1 }
D/RILJ    ( 1693): [4706]< SMS_ACKNOWLEDGE 
D/RILJ    ( 1693): [UNSL]< UNSOL_RESPONSE_NEW_SMS
D/RILJ    ( 1693): [4792]> SMS_ACKNOWLEDGE true 0
D/RILJ    ( 1693): NOTE: mReqWaiting is NOT 0 but1 at TIMEOUT, reset! There still msg waitng for response
D/RILJ    ( 1693): WAKE_LOCK_TIMEOUT  mRequestList=1
D/RILJ    ( 1693): 0: [4792] SMS_NOWLEDGE
D/RILJ    ( 1693): [4793]> SCREEN_STATE: true
D/GSM     ( 1693): [GsmDCT] onReceive: action=android.intent.action.SCREEN_ON
D/GSM     ( 1693): [GsmDCT] stopNetStatPoll
D/GSM     ( 1693): [GsmDCT] overall state is IDLE

Do those logs differ because it's another ROM, or does the ROM even matter in this case?

Also, here are my short answers to your above Proposals:

1. You suggestion with testing Silent SMS makes sense. Maybe @xLaMbChOpSx could add a tab to test AIMSICD for different types of attacks on ones own phone? That way, we don't have to rely on yet another software, but keep it all in one convenient place. When the tab is added, maybe @domi007 can add his code into it? Don't worry, I don't want to push anyone to do something here.
2. Logcat works great and I fully support the idea of monitoring via the mentioned method.
3. Yes, as mentioned in this German article, several agencies like the Federal Criminal Police Office, Federal Customs Service as well as the Federal Office for the Protection of the Constitution obviously are in love with sending these Silent SMS. You can be sure that having sent 440.000 Silent SMS is the "official version" of the story, which doesn't include the ones unofficially sent.

❗ IDEA: Perfect would be if @xLaMbChOpSx could add three buttons to the lower part of the screen named Interception, Impersonation and Tracking. Upon clicking one of those, AIMSICD could display a short note saying something like Fetching protection capabilities of your current mobile network. These stats do not necessarily indicate that you are in danger. Clicking "OK" would then detect the current mobile network of the user, query the database of GSM Security Map and take the user to the respective screen displaying some sort of bar chart. Sounds useful! What do you think?

from android-imsi-catcher-detector.

@SecUpwN It's the Vendor-RIL which decides what will be displayed in the log. Different ROMs can have different versions of Vendor-RIL. Different Vendor-RIL (versions) can provide different info.

If they provide some info, it is handled by the telephony framework. This means that there is only a limited number of strings we have to look for. There are different versions of telephony frameworks in different ROM versions.

We need to monitor for things like SMS_ACKNOWLEDGE.
@E3V3A Is right, we don't necessarily need to monitor the logcat direct. The info is provided in e.g. RIL.java and GsmSMSDispatcher.java. Look in GsmSMSDispatcher for the function dispatchMessage, you will find there the check for type 0 messages.

if (sms.isTypeZero()) {
    // As per 3GPP TS 23.040 9.2.3.9, Type Zero messages should not be
    // Displayed/Stored/Notified. They should only be acknowledged.
    Rlog.d(TAG, "Received short message type 0, Don't display or store it. Send Ack");
    return Intents.RESULT_SMS_HANDLED;
}

If SMS PDU gets provided, the telephony framework can check if it is a Type 0 message, but not every Vendor-RIL will provide the PDU of silent messages, I think.
It should be possible to patch the telephony framework, so that we can monitor for these events better.

from android-imsi-catcher-detector.

@andr3jx You have many great ideas, but looking for strings in logcat is not one of them, and its not a matter of opinion. It is a bad idea. Nearly every phone has a different way of showing the strings there, if any at all, are shown in logcat. (And while I write this, you just posted more above.)
Any binary can put stuff in logcat, AFAIK or choose not to, so for radio, it is partially decided in RIL but probably also in kernel and may even be dependent on the kernel log settings. (I don't know yet.)

We have to find another and better way, which is getting access to modem debug interface or being able to make sure AT command interpreter can issue info regarding received silent SMS, if possible. Instead, why don't you just look in the 3GPP docs under SMS and try to find how unsolicited SMS related messages are received and enabled? That alone would cover a great many more phones.

@SecUpwN I don't understand what these buttons should do, that we're not already supposed to be doing? I think @xLaMbChOpSx should focus on trying to get the detection variable table implemented and you (we) guys should try to help him find some relevant ideas how to do that. Detecting a silent-SMS is just one small point in that table, although important, there is no requirement for sending this for an IMSI-Catcher to catch you..

Of primary focus today, should be to triangulate the fake BTS to within, let's say ~30 meters.
One of the more interesting aspect we should also look into, is that we can monitor SIM card filesystem from AT IF and perhaps be able to detect SMS messages getting passed i/o from there and the many RF settings/variables therein.

Sorry, I don't really wanna police this project, but you all have to try to help it along to stay on track and not loose focus of the primary problem this APP is supposed to solve. Adding various convenient features is never going to get us there. I'm sure xLaMbChOpSx doesn't wanna spend his summer to program additional features for an alpha-app when its not yet doing what it was intended for.

from android-imsi-catcher-detector.

@E3V3A Have you received my mail (some days ago)? Detecting Silent SMS is important, because the feds send many of them. So it is a strong indicator that you're being tracked! Other things that we try to implement will be far less reliable.

from android-imsi-catcher-detector.

@E3V3A, my idea with the buttons was to fetch the data from GSM Security Map to be displayed in our own App, depending on the network provider a user is on. But you are probably right, adding this is not considered to be important at this time. Again, it was just an IDEA.

Sorry, I don't really wanna police this project, but you all have to try to help it along to stay on track and not loose focus of the primary problem this APP is supposed to solve. Adding various convenient features is never going to get us there. I'm sure xLaMbChOpSx doesn't wanna spend his summer to program additional features for an alpha-app when its not yet doing what it was intended for.

Absolutely. While I agree that we really have to focus on the primary problem to detect IMSI-Catchers, I consider detection of Silent SMS just as important. Most of the time the agencies that really do use IMSI-Catchers are FIRST sending out (multiple) Silent SMS to track down the targets approximate location and where he is each day at different times, and THEN they follow the suspect with the IMSI-Catcher to eavesdrop on his data and even listen in on his calls. I guess sending out Silent SMS is much more comfortable for them, too. I fully go with your main point that detection of IMSI-Catchers shall be our primary focus, but we also have to work this Issue alongside to have the topmost Issues solved.

Personally speaking, I feel a little stuck. Where exactly to help? As for this particular Issue I'll be reviewing the 3GPP docs to find out how unsolicited SMS related messages are received and enabled soon. But how exactly to proceed on IMSI-Catcher detection? I need clear instructions, please.

from android-imsi-catcher-detector.

This point (from the detection table) should be easy to implement:

• L1 The LAC of a base station changes (yellow)
• L2 LAC changes more than once (red)

The story behind this is, that the mobile sends the IMSI when a Location Area Update occurs. After that it uses the TIMSI again. While the catcher is in "scanning mode" (looking for the right phone with the right IMSI) it uses this Location Area change to collect all IMSI's.

I guess I should move this to another issue - or should i start a new one?

from android-imsi-catcher-detector.

@andr3jx Yes, I've got your message. Sorry I have not have time to properly respond. I simply have too much on my plate lately.

@SecUpwN I'm not sure your description of the mode of operations by sending silent SMS (S-SMS) are used that way. [edit: it is probably as you say.] My point being that it is not necessary to send S-SMS to track people, and if you use an IMSI-C you probably wanna get a whole bunch of people, and not only one person, unless you're already a prime target for something, in which case you should throw your phone away! Second the IMSI-C is not eavesdropping to data, nor listening to phone calls, that is done by the fake BTS. So now you will say, "well so what the hell is the difference" and the answer is, generally for just tracking an IMSI, nothing, but in order to do any form of eavesdropping, you need a complete BTS that can set up a proper connection with BSC and VLR, AFAIU.

I don't have time to look up the exact RF level handshakes for S-SMS versus, just IMSI-C, but I'm sure it is widely available and easy to find.

Furthermore, the GSMMap is not doing much more than what we are already trying to do, which is providing a ciphering status indication of the current connection. So if we know what the SIM home network ciphering indicator does and what the current home network Ciphering is (and what it has been before) we're pretty much good to go on that part. GSMMap does provide some info regarding the default settings for a few providers, so for that ,perhaps it could be useful. But that could be checked in a small CSV file, since there would be only a handful of entries per country.

@He3556 Thanks for filling out some blanks, perhaps you recall how the handshakes above are made as well?

from android-imsi-catcher-detector.

An interesting way to prevent silent (or any other) SMS, is by deleting the number of the SMS Service Center. Now, I haven't checked if this can be done from API, but it should be, since it is accessible from phone settings. If it is not, I am about 99% sure it can be done over AT interface. Either way, it is a perfect counter measure for these attacks that can be temporarily implemented. Let's say when connected on certain networks, LAC/CID or locations. A setting where, if AIMSICD detect something fishy, just disable SMS, until threat is over or overridden by user.

Please check, and don't forget to write down the original number!

@SecUpwN I edited my last post. I now think your tracking with silent-SMS description is correct. So now we need to look at the details.

from android-imsi-catcher-detector.

Interesting find, @E3V3A. But wouldn't it be much simpler to temporarily turn the phone into airplane mode for a previously defined period of time? Nobody would have to edit and possibly forget anything.

We have to find another and better way, which is getting access to modem debug interface or being able to make sure AT command interpreter can issue info regarding received silent SMS, if possible. Instead, why don't you just look in the 3GPP docs under SMS and try to find how unsolicited SMS related messages are received and enabled? That alone would cover a great many more phones.

I crawled my way to the site index of [Technical realization of the Short Message Service (SMS)](Technical realization of the Short Message Service %28SMS%29) and grabbed version 12.2.0 of 2013‑12‑20 to read about the TP Protocol Identifier. But before I quote the whole stuff here, could you have a look at section 9.2.3.9 TP Protocol Identifier (TP PID) yourself please and tell me if that is Info we need? This section also appears to include a complete description of what a short message type 0 means in detail. Sorry for not being of more help, I am chasing ghosts..

from android-imsi-catcher-detector.

Airplane mode is all BS! It disconnects from network, but RF modem shutdown is HW and SW dependent , so it probably isn't. WiFi is certainly on and maybe also NFC. We don't know, and GPS is certainly also on, so if you're on a qualcomm with GPS in the modem, then modem is not shut down either.

Also I propose to check for Class-2 SMS as well!
From TS 23.038:

Class 2: This message class is Phase 2 specific and carries SIM card data. The SIM card data must be successfully transferred prior to sending acknowledgement to the SC. An error message will be sent to the SC if this transmission is not possible.

Which means that this can be used in the same way as Silent-SMS.

from android-imsi-catcher-detector.

I've just received an E-Mail from Mike (the owner of the famous Kuketz IT-Security Blog) that someone made a low-level logcat on his Samsung Galaxy S3 while receiving a silent SMS.

Furthermore, he told me that the exact same guy will analyze the contents to reveal which functions shall be triggered within his phone. Hoping to receive more data soon (and maybe get in touch with that guy).

from android-imsi-catcher-detector.

Nice work, and he should join us! Also, as you can see from the logs, this comes from the built-in QMI interface ( /system/bin//qmuxd + /dev/qmux ). So we need help on how to use this interface, but that is another issue.

What is the current status of Silent-SMS detection? ( @xLaMbChOpSx ? )

from android-imsi-catcher-detector.

Just a side note on this, during my testing I found out that GSM network will send legitimate type 0 pings to your phone each time your phone was unreachable and someone tried to reach you (call, send sms, mms, whatever). Seems like network is marking the phone as unreachable at that point and pinging it until it's online again. As soon as phone ack such ping gsm network will stop sending pings to phone and deliver notifications about missing calls and queued undelivered messages.

from android-imsi-catcher-detector.

Yes you are right, but this is called Periodic Location Update (PLU). The settings of the timer is send to the cell phone. The phone has to send the PLU to the MSC. If not the phone gets detached and is not available any more. See No.4 in ETSI TS: 123012v100100p.pdf

The PLU is delivered over the BCCH (Broadcast Control Channel) in the sublayer MM (Mobility Management) of the layer 3 GSM Protocol Stack. See No.4 in 3GPP TS: 24008-c60.zip

SMS is delivered by the SMS Control Layer (SMS-CL) and SMS Relay Layer (SMS-RL) - is a part of CM (Call Management). This is another sublayer of Layer 3. MM, RR (Radio Resource Management) and LAPDm (Layer 2) needs to be established before.

I found some good information with a over view of the GSM Protocol Stack.
http://de.slideshare.net/KannanSelvam1/gsm-signaling

from android-imsi-catcher-detector.

@He3556 Then this is not the same thing as PLU, these GSM network pings result in same type0 sms log entry for sure and I was able to reliably simulate this in occasions described above. You can try this on your phone, turn flight mode on, send sms from another phone to your phone, wait few minutes, turn off flight mode and review your log, you should see entry with sms type0 notification.

from android-imsi-catcher-detector.

ok, i see it was my mistake - i just edited the text - it's not about the PLU.
Definition of Type 0 is: a message is received and discarded and a reception acknowledge is send back.
But i didn't know it would log a Type0 in this case. Interesting point for me. We should think about it when we are able to detect the log entry with our App.
If the phone was in flight mode, we should not tell him he just received a silent SMS, when he switches back. (turns off flight mode)

from android-imsi-catcher-detector.

@He3556 "If the phone was in flight mode, we should not tell him he just received a silent SMS, when he switches back. (turns off flight mode)"

We should, because someone else could also send type0 sms during the time phone was off or in flight mode. It's better to have false positive (in case you receive notification sms about missed call or standard sms right after, this type0 sms should be treated as false positive) than no notification at all.

If we could detect the source of type0 sms, this could be great, but as I'm aware this information is never included in log.

from android-imsi-catcher-detector.

about "...false positive"
yes right!
about the source of SMS in general - it is easy to send SMS with a fake cell phone number even over SMS web services, without using your own mobile phone. But in the case of Type0, i think the reception acknowledgement is not important for the sender anyway. So there is no need to include the real sender number. He gets the information (about location of cell phone) from the core network.

But it would be interesting to see some examples of SilentSMS as PDU messages. And those that lets your phone download and install code in the background, like WAP Push with "Service Loading" (SL) for OTA and FOTA.

The PDU should contain:

TP-PID = 0x7F
TP-DCS = Class 2 8-Bit

from android-imsi-catcher-detector.

I think we can use ddi smsdispatcher example to place hooks in SMSDispatcher and get full PDU of the message. I already compiled this successfully one month ago, but thought that it is not helpful because silent SMS don't reach RIL on my phone.

from android-imsi-catcher-detector.

Well VLR will still update the location data even if the SMS is sent from a fake number..

from android-imsi-catcher-detector.

@andr3jx ddi smsdispatcher - yes i remember - always the same annoying problem with the closed baseband. I would like to get a Osmocom BB compatible phone to check out some stuff, but i had no time to get this working anyway.

About SMS: the phone sends the confirmation back to the address of the SMS-Center (SMSC). If delivery failed the SMSC will store the message and try again later. (store and forward) A confirmation to the sender would not work. But maybe it would work when you send the SMS from a ISDN Phone. There you can also fake the caller number but at the same time the network knows your real address (internal). Thats also why suppressing a number to stay anonymous won't work with ISDN. The company will always know who is calling.

from android-imsi-catcher-detector.

@He3556 I'm not sure if confirmation is sent to SMSC. I changed the SMSC to an invalid number on the phone but confirmation still worked. See my comment.

from android-imsi-catcher-detector.

@andr3jx I'm not sure why you say your type-0 SMS "doesn't reach RIL", but from the Java code in this post, it is clear where the logcat message (shown in @SecUpwN post ) is coming from. I missed looking at that ddi sms dispatcher tool, and would love to see some handshakes between QMI and RIL. Can you investigate further why you don't see anything in RIL? (We can discuss the details in the hangout.)

Also, when you post logcat output and so on, please state what phone ,AOS and RIL versions you're using.

from android-imsi-catcher-detector.

It is sent to the senders SMSC not to yours. The first 1-10 octets of the PDU packet is the SMSC address.

It is not easy to stop receiving SMS. Maybe you can send a GSM Code to the provider to stop receiving SMS but I would not trust it. I could only block standard SMS and not silent SMS. Best way would be a PDU filter implemented in the OS of the baseband :) but that is far away for us right now. So I would prefer to use a SIM card without cell phone number - only with data connection and route all data over a VPN gateway at home :) so its possible to log and analyze everything that is send to the mobile :)

(Edited by E:V:A for readability.)

from android-imsi-catcher-detector.

@E3V3A Type 0 SMS don't reach RIL on my phone. My phone doesn't log any messages in comparison to SecUpwN's phone. Conclusion: On my MTK phone Silent SMS get deleted in lower layers so they don't reach RIL. But great that other phones don't do this, so we can try sms dispatcher tool.
@He3556
Ok that explains why SMSC changing didn't work -Thanks ;). Of course using only data for everything is much better, but this is not what this project tries to achieve. I personally made that all my communication work over data connection, but achieving this is not trivial and there are some practical problems.

from android-imsi-catcher-detector.

@andr3jx :)) yes you are right, this is the wrong place to tell people to switch over, to use data connections only. I have digressed from the topic - implementing something in the BB OS was also not meant seriously ;) but maybe we can talk about data connection and mobile VoIP on another channel sometime, if you already have some practice.

from android-imsi-catcher-detector.

You might want to watch this blackhat presentation, this project got name dropped in regards to type 0 SMS: https://www.youtube.com/watch?v=0c_9kloM9DQ

from android-imsi-catcher-detector.

@tobykurien, could you please have a look into the current code? Somehow AIMSICD does not detect silent SMS any longer. You can test if detecting silent SMS was successful with this small guide.

from android-imsi-catcher-detector.

@SecUpwN Type 0 SMS detection never worked - only other types.

from android-imsi-catcher-detector.

@AoiGhost, thanks for reminding me. I remember now that it was Class 0 (Flash-SMS) instead. The question remains, why does it still not work after all the fixes we had for silent SMS? Thanks for suggesting the usage of Android DDI, @andr3jx. Sadly though, @crmulliner seems to be either not interested in particpating in our project (introduced it months ago to him), or he is busy. Maybe both.

from android-imsi-catcher-detector.

Ok, I've done a 180 and say we should:

1. Look for Type-0 and related items in logcat as a first stage detection.
2. Look for side channel detection (I.e. location updates etc)
3. Account for false positives when doing RF OFF/ON.
4. Also look for Class-2 (SIM app install) and WAP-push messages
5. Disable SMSC during detection, to ensure no ACKs are sent.

@andr3jx : one reason you may not see Type-0 in your logs, could be the modem loglevel settings. That is not the same as the logcat levels settings. Another reason is that certain debug messages are only shown when in Factory or Enigneering Modes. Often referred to in Android sources as DBG_ENG. Look in (Sec)Phone:apk : PhoneInterfaceManager.class (Samsung) or equivalent. I've reversed this on my phone and it seem to show that I need to set both:

nfc.trace.mode 1
ro.debuggable   2

Also check the ro.debug_level property. I have on the GT-I9195:

[ro.debug_level]: [0x494d]   <== "IM" = ("MI" in Little Endian), meaning "MID" loglevel.
[ro.debuggable]: [0]

PS. This also seem highly relevant for SIM access, but I'll write about those details in that issue.

Please Test: To test what PDU's and SMS you have received, you can do this:

su
sqlite3 /data/data/com.android.providers.telephony/databases/mmssms.db
sqlite> .tables

addr                 pending_msgs         spam_rate
android_metadata     rate                 spam_sms
attachments          raw                  sr_pending
canonical_addresses  sms                  threads
cmas                 spam_addr            words
drm                  spam_drm             words_content
mychannels           spam_filter          words_segdir
part                 spam_part            words_segments
pdu                  spam_pdu             wpm

sqlite> .schema pdu

CREATE TABLE pdu (_id   INTEGER PRIMARY KEY AUTOINCREMENT,
        thread_id       INTEGER,                        THREAD_ID
        date            INTEGER,                        DATE
        date_sent       INTEGER DEFAULT 0,              DATE_SENT
        msg_box         INTEGER,                        MESSAGE_BOX
        read            INTEGER DEFAULT 0,              READ
        m_id            TEXT,                           MESSAGE_ID
        sub             TEXT,                           SUBJECT
        sub_cs          INTEGER,                        SUBJECT_CHARSET
        ct_t            TEXT,                           CONTENT_TYPE
        ct_l            TEXT,                           CONTENT_LOCATION
        exp             INTEGER,                        EXPIRY 
        m_cls           TEXT,                   *       MESSAGE_CLASS
        m_type          INTEGER,                *       MESSAGE_TYPE
        v               INTEGER,                        MMS_VERSION
        m_size          INTEGER,                        MESSAGE_SIZE
        pri             INTEGER,                *       PRIORITY
        rr              INTEGER,                        READ_REPORT
        rpt_a           INTEGER,                *       REPORT_ALLOWED
        resp_st         INTEGER,                *       RESPONSE_STATUS
        st              INTEGER,                *       STATUS 
        tr_id           TEXT,                           TRANSACTION_ID
        retr_st         INTEGER,                        RETRIEVE_STATUS
        retr_txt        TEXT,                           RETRIEVE_TEXT
        retr_txt_cs     INTEGER,                        RETRIEVE_TEXT_CHARSET
        read_status     INTEGER,                        READ_STATUS
        ct_cls          INTEGER,                *       CONTENT_CLASS
        resp_txt        TEXT,                           RESPONSE_TEXT
        d_tm            INTEGER,                        DELIVERY_TIME
        d_rpt           INTEGER,                        DELIVERY_REPORT
        locked          INTEGER DEFAULT 0,      *       LOCKED 
        seen            INTEGER DEFAULT 0,              SEEN
        deletable       INTEGER DEFAULT 0,      *       
        hidden          INTEGER DEFAULT 0,      *       
        app_id          INTEGER DEFAULT 0,              
        msg_id          INTEGER DEFAULT 0,              
        callback_set    INTEGER DEFAULT 0,              
        reserved        INTEGER DEFAULT 0,      *       
        text_only       INTEGER DEFAULT 0);             

Where I have annotated from ~ HERE. And as you can see, the last ones are not filled in because they are (?) probably Samsung specific. What is that hidden, thing doing?

Anyway, pushing on, I keep receiving CB messages from my provider. One of them look like this:

sqlite> select * from sms where protocol!=0;

               _id = 2122
         thread_id = 317
           address = CBmessages
            person =
              date = 141466180XXXX
         date_sent = 0
          protocol = 5                  <== NOTE!
              read = 1
            status = -1
              type = 1
reply_path_present =
           subject =
              body = XXXXXXXXXXX
    service_center =                    <== NOTE!
            locked = 0
        error_code = 0
              seen = 1
         deletable = 0
            hidden = 0
          group_id =
        group_type =
     delivery_date =
            app_id = 0
            msg_id = 0
   callback_number =
          reserved = 0
               pri = 0
    teleservice_id = 0
          link_url =
           svc_cmd = 0
   svc_cmd_content =
      roam_pending = 0

So I would like you to test and see what you find, if sending Type-0 or Class-2 messages...

from android-imsi-catcher-detector.