Android-IMSI-Catcher-Detector
Android-IMSI-Catcher-Detector copied to clipboard
CellularPrivacy
Detection of Silent SMS (part 2)
The original thread (#69) was getting far too long, so this is the continuation of that thread.
Please use old thread as reference only!
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@banjaxbanjo Actually my loglevel has been reset to normal. So I'm not high logging, but QMI and Xpose/XPrivacy is really spamming logcat very hard, especially when GPS and Wifi is on. My test phone is 2 core model, and I'm not sure continuously reading from or keeping buffer open is a good idea. Can you show me where in the code this is done?
Please note: If we now close the other thread, it gets marked as solved, which will in turn trigger Bountysource to ask @agilob and me if the bounty (only $15 since noone gets their asses up and actually contributes anything, shame on you, app leechers) may be given to @banjaxbanjo. Continue.
@E3V3A here is the start of function https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/blob/development/app/src/main/java/com/SecUpwN/AIMSICD/smsdetection/SmsDetector.java#L120-#L130
I've let run on my phone for 24 hours with no lag issue but with a bad cpu I suppose it might lag a little.
The main reason I kept logging open was duplicate sms but since we now check the timestamp this will no longer be an issue. Any ideas on what way to go?
So what do these thread sleepers do: here and here ??
I don't think it's the logcat dumper that takes any effort, it must be the checkForSilentSms() thread. Can we write it more efficiently? I see a lot of loops of loops, with lots of info shuffling. I'm sure we can make this more efficiently... But I need to think about and understand the code better.
Besides, you have better things to do... Let's leave this for now.
I'm wondering if there's some kind of indicator when a log buffer is getting full? (I.e. for the kernel to circle.)
@E3V3A I put in the sleep (1000) to slow down the logging abit so its not as laggy if you put this higher its basically like a timer anyway.
A lot of them loop you see are never access they are only accessed if a string is picked up.
ok, a few possible solutions:
- we can increase the size of the logcat buffer by piping to file, so we can make the sleep longer. (Is that blocking?)
- we can check the size before running.
- We might be able to increase performance by searching the logcat in binary format (-B), thus skipping the reformatting and i/o overhead.
# logcat -g -b radio -b main
/dev/log/radio: ring buffer is 512Kb (17Kb consumed), max entry is 5120b, max payload is 4076b
/dev/log/main: ring buffer is 512Kb (139Kb consumed), max entry is 5120b, max payload is 4076b
On my device, while running the app, it takes about 8 seconds to fill up radio buffer, and about 1m20s to fill main buffer, without doing anything!
On more new devices with AOS > 4.3, the main buffer is 1 Mb.
But as I said before, I think its the string checking that takes the most time...
@E3V3A
But as I said before, I think its the string checking that takes the most time..
We need to check all strings I don't think there is a way around this and I have a check in place to only check small lines less than 250 chars and if string is not detected 90% of code is bypassed
if(progress[x].length() < 250){//check only short strings for faster processing
We can experiment with a filter but its going to be a very big filter and I think it will make detection not work as good and we will miss some data. With verbose logging all we have to check if the strings contains
Received short message type 0, Don't display or store it. Send Ack
and it doesn't matter what class this showed up in the logcat from, GsmInboundHandler etc.. < this works for other logcat basebands we dont know but as long as this string shows up it will alert no matter what Class the string came from. <<<Future proof
SmsDetector is not run on the UI thread its run on a background thread wont lag GUI so sleep wont cause issues I don't think.
A side note!
From the sources here:
/**
* The WapPushManager service is implemented to process incoming
* WAP Push messages and to maintain the Receiver Application/Application
* ID mapping. The WapPushManager runs as a system service, and only the
* WapPushManager can update the WAP Push message and Receiver Application
* mapping (Application ID Table). When the device receives an SMS WAP Push
* message, the WapPushManager looks up the Receiver Application name in
* Application ID Table. If an application is found, the application is
* launched using its full component name instead of broadcasting an implicit
* Intent. If a Receiver Application is not found in the Application ID
* Table or the WapPushManager returns a process-further value, the
* telephony stack will process the message using existing message processing
* flow, and broadcast an implicit Intent.
*/
@E3V3A I'll do some testing adding the -b main makes it slightly longer to detect. I've tested wap and mwi recently and seem to be working ok will check again as well as type0.
I found a typo in the pre-loaded DetectionStrings table for Type-0 detection. It has a double ' in there. We can also shorten that string, to only use first sentence...
current: Received short message type 0, Don't display or store it. Send Ack
shortened: Received short message type 0
In addition I'd really like to see some CB message detection.
We can also shorten that string, to only use first sentence...
Not sure if that would lower detection probability of Type-0 SMS.
@SecUpwN no wouldn't make detection work less if anything it would work better. If the logcat line contains them sequence of characters then it will alert. Will add if I get the time and try change the db timestamps to int also.
Will add if I get the time and try change the db timestamps to int also.
Thanks for clarifying @banjaxbanjo. Do yo ink you'll be able to pus your proposed changes within the next 2 hours? Not trying to be pushy or anything, but I'm preparing the release for our itchy users. ;-)
no sec prob be tonight or tomorrow sometime☺
Perfectly fine, @banjaxbanjo. Make sure to use a fresh copy when you do. See ya later, alligator!
What will happen if regular SMS is sent with intentionally wrong checksum? Mobile will receieve and ack but then it will discard message as it was never receieved. Is there any way to detect such activity?
@ga900 That is a great question! Do you know how to write such an SMS we can use to test with?
SMS detection is still broken.. :(
@banjaxbanjo Can you please have a look what happened?
@E3V3A I do not know how to do it, but there are some rumours that such messages is better choice for E-OTD & UL-TOA measurements :( because type0 sms is visible on some multi-sim chinese phones.
I'm not sure if anyone else noticed, but the bounty on this bug (encompassing both #69 & #537) has now increased to $115 as of a couple weeks ago! :open_mouth:
@SecUpwN Is there any way to get the bounty tag replicated from #69 so this issue shows (changes in) the bounty automatically as well?
Is there any way to get the bounty tag replicated from #69 so this issue shows (changes in) the bounty automatically as well?
@TPS, thanks for asking this, I don't know. Maybe @rappo from @Bountysource does?
@SecUpwN @TPS The only way to have the bounty tag show up here automatically is if there's actually a bounty on this issue. If having the tag on this issue is important to you, you can still manually add / update it as needed.
Thanks for responing, @rappo. As you can see, this is part 2 of the original Issue, but developers that continue here should get part of the huge bounty posted on the original Issue. Can I transfer some of it?
@SecUpwN @smarek Guys I think we can get this to work on non rooted phones less than api < 17 I haven't test yet but should work if @smarek wants to test somehow. if 17 or higher user will be asked for root comments added only for guide can be removed.
only needs permission.READ_LOGS if < api 17
try {
Thread.sleep(500);
Process process = null;
String MODE = "logcat -v time -b radio -b main\n";
Runtime r = Runtime.getRuntime();
if(Build.VERSION.SDK_INT < 17){
process = r.exec(MODE);
}else{
process = r.exec("su");
DataOutputStream dos = new DataOutputStream(process.getOutputStream());
dos.writeBytes(MODE);
dos.flush();
dos.close();
}
setSmsDetectionState(true); //<-- moved this here because we don't want to set true if we can't exec command.
mLogcatReader = new BufferedReader(new InputStreamReader(process.getInputStream()));
} catch (InterruptedException | IOException e) {
Log.e(TAG, "Exception while initializing LogCat (time, radio, main) reader", e);
}
@smarek and @banjaxbanjo, I've received an E-Mail from @DimaKoz with a VIDEO of a user testing AIMSICD and its capabilities of detecting silent SMS. Result: This detection needs more improvements.
@SecUpwN this is not a one for all app and is limited until we have more logs for other model phones. I've shown app detecting all sms on my Samsung S5 when debugging set to high in menu *#9900#.
The success of this is based on the amount of logs that we receive with users receiving a silent sms.
so far I've got it to this stage with only my own logs so would be great to get other unique strings to indicate a type 0 etc..
We don't want user data all we need is a string that we know is indicating a silent sms.
