Cannot install / update Apps anymore about android-imsi-catcher-detector

[xLaMbChOpSx]

Hey mate sorry you are facing problems AIMSICD does implement logging of errors and other items, I went through your log but could not see any log entries from AIMSICD in fact there wasn't anything that really stood out that would indicate an issue.

Did you take the log after an unsuccessful install?

[xLaMbChOpSx]

Once the apk has been removed the only other data left can be found under data/data just look for the package name and remove that directory.

Maybe another log will help track down the root cause. I think I updated all the tags to insert AIMSICD and possibly the class name into any log messages to make filtering easier.

[SecUpwN]

@xLaMbChOpSx, thanks for assisting. I completely re-flashed my ROM from scratch without AIMSICD installed and.. faced the same issue. I figured that AIMSICD cannot be the cause at all and traced down the Issue to be related to Aptoide. Within the logs I discovered that the package installer could not find an identifier - I guess Aptoide removed it or something and thus my phone refused letting me press the install button. All good now, issue solved and world saved. Thank you for reviewing my logcat. ;-)

[E3V3A]

I just tried to install according to the instructions:
https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/releases/tag/v0.1.2-alpha
But when I click on app, and install (either by Google or app installer) it just says: "Application not installed". Any ideas? (I'm on rooted stock 2.3.4)

[xLaMbChOpSx]

The system should install the app once it is pushed to /system/app and permissions set after a reboot it should appear in your app drawer.

[E3V3A]

Well it doesn't. I noticed my system is using odex'ed apks in that directory. And what about this signature business? Do I need to do something with that?

[SecUpwN]

@E3V3A, you are on rooted STOCK 2.3.4 - this doesn't sound like you are on KitKat. The AIMSICD-App shall then not be placed in system/priv-app, but rather in system/app. Also, please make sure you have set the right persmissions to rw-r--r-- (644) and rebooted. Maybe also clear cache & dalvic in recovery?

[E3V3A]

No that is not KItKat, as I said/asked about before. Is this only for KK? I thought he said he'd changed the API?
Ok, how do we do that? (Clear cash/dalvik?)
I set permission to 666, in "/system/app/.."

[xLaMbChOpSx]

Yes the min sdk was reduced to 9, I am thinking the issue is that the apk is signed using the AOSP platform key which does not play well with a stock rom as it differs to say the Samsung or Sony platform key. The biggest issue is that the app must be signed with the platform key to allow sharing of the phone (or system) process as within direct access to the main looper thread as any attempt to invoke the getDefaultPhones() method with cause an exception, I will start a new branch locally and remove all direct access calls and try using reflection only and see what happens.

[SecUpwN]

@E3V3A, the app is not only for KitKat. _If_ you have KitKat, the App has to be moved into system/priv-app, otherwise (and that is your case) into system/app. Did you set permission 666 to the whole system/app-folder? Please don't do that. Just set the app to rw-r--r-- (644) once you moved it into system/app. Regarding clearance of cache/dalvic: What kind of recovery do you have? TWRP?

[xLaMbChOpSx]

I am pretty sure that the system will ignore any apk that is not specifically set to 644 so that could be the problem.

Also I think if the rom you have is odex'ed then the apk may need to be odex'ed or it will not work?? I could be totally wrong on that as I don't have any experience with odex'ed roms.

[SecUpwN]

Could you solve the problem with placing the APK into system/app and setting the correct permissions to rw-r--r-- (644), @E3V3A? Let me know here so that I can close this issue for good. Thank you.

[E3V3A]

a) Then it could be a odex'ed problem. Do you guys have someapp.apk AND someapp.odex on you devices?
b) Also, i still have both RawPhone and the Oblox demo installed, is it possible they might interfere?
c) I'm sorry, but all this is most probably my own fault. I've messed around with this phone too much and disabled a bunch of Samsung crap, I've also had some Google Play issues. I'm sure my installation problems are related to that. Working on a solution...
d) I'm backing up to make a reflash, but I need some time, because my phone still have the BrickBug issue and I have to be very careful. Also waiting for another dev phone.

[SecUpwN]

@E3V3A, how about flashing a fresh ROM above API 10? 😈

[E3V3A]

I got your point the first time. But I want to stay on 10 because of a combination of being a masochist, have no time for making backups, a phone full of tweaks, working on the baseband communication where un-patched modem and other utilities are essential and also because I just don't have a box full of extra phones I can fcuk around with, like many other developers do... Don't worry, I know what you're thinking. I'll get a another/different device to work on soon.

[SecUpwN]

Don't take my humor too serious, @E3V3A. Have a smooth start into the week!

[xLaMbChOpSx]

The ROM I use is deoxed so only the apk fully resides in the app directory, I can try and produce an odex'ed version but without the Samsung firmware I don't think I will have much luck.

In also thinking it may be because of the AOSP platform key being rejected by the stock ROM.

Finding out how to issue AT commands via the serial device may be the only alternative as everything else requires the platform key signing (which possibly means the app is restricted to AOSP based ROMs) and installation as a system application, but the terminal method would rely on root rights at most and could be installed as a user application.

[E3V3A]

Yep, it seems to be a signature issue and possibly also a cscCountry or permissions issue...

E/PackageManager( 2701): Package com.SecUpwN.AIMSICD has no signatures that match those in shared user android.uid.phone; ignoring!
W/PackageManager( 2701): Package couldn't be installed in /data/app/com.SecUpwN.AIMSICD-1.apk

@xLaMbChOpSx, checkout the logcat here: http://pastebin.com/fzMRqLyw

Edit: I noticed I have both odex and de-odexed apk's in that directory. (WTF?)
How can we resolve key issue in the easiest way? (Not neceessarily the correct way, but at least so that I can get this installed. And we can think about permanent solution for Beta release.)

[E3V3A]

@SecUpwN and @xLaMbChOpSx: Any ideas how to resolve the signature issue? Can I copy keys from somewhere else to somewhere? Or how do people deal with this?

It is clear I'm not the only one having this issue, and I simply do not understand why. When I last made a test app, although quite some time ago, I didn't have this problem, so why does it pop-up now? (There's a good reason why I am not a Java developer, and one of them is that I can't be bothered with this kind of crap.) Maybe we have to run the whole thing in Python and SL4A?

[SecUpwN]

@E3V3A, unfortunately I have no idea why this is happening. If you phone is rooted, could you please make a NANDROID and test the App in a fresh ROM environment? Maybe it helps tracing it down.

[xLaMbChOpSx]

@E3V3A It is due to the fact the app is signed with Google's AOSP platform key, stock vendor ROMs reject the key as they only know their own key.

I can remove that issue but doing so will remove the ability to share the com.android.phone process leaving the only option for issuing AT command to working out how to echo them to a serial device.

Happy to go forward with whatever you recommend.

[E3V3A]

@xLaMbChOpSx Ok, I am only briefly starting to understand, but lack overview whats going on under the hood. A few questions:
a) So does the stock ROM's only know ONE signature key or can they accept more? If yes, how could I (we) add this AOSP key to my (our) own stock ROMs?
b) So does (a) imply that people on stock ROMs are not able to use this app? [unacceptable]
c) What exact functionality in com.android.phone are we using?
d) When you say "remove the issue" what exactly do you mean? Remove signature or something else? If it means removing signature, AND a signature is required to run on stock ROM's, then perhaps it would be easier to tell people how to extract key and sign their own unsigned versions of the APK?

e) I played with "am broadcast" and "am start". Does that functionality also require signatures?

[xLaMbChOpSx]

@E3V3A Getting really late here so I will add to this tomorrow but basically say a Samsung stock ROM uses a Samsung propriety key to sign the ROM and apps and knows nothing about the AOSP key. Sort of like trying to send me a pgp signed email using somebody else's public key.

The phone process allows you to invoke the ril methods amongst other things, without sharing this process nothing you do including using reflection will work as the phone process can access the main looper thread which is a requirement when invoking those methods.

To provide compatibility across all ROMs the signing would needed to stop which leaves only the option of using the terminal on the device to attempt to communicate with the modem.

Hope that helps a bit and I will check back in tomorrow morning on my way to work.

[E3V3A]

@xLaMbChOpSx (insert many bad words of your choice)!! Thanks for explanation. Thus we are pretty much left at trying to get this from shell command line. I suggest you to have a quick look at my most recent XDA (am start) post, which seem to indicate that we should be able to execute AT commands via another Samsung jar from rooted command line, and also at the code from the Replicant guys. I guess we should be able to get modem AT by using IPC's wrapping, for XMM modems and from /dev/ttyX on Qualcomm modems.
Check:
https://gitorious.org/replicant/hardware_ril_samsung-ril
https://github.com/morphis/libsamsung-ipc

The bottom line is, if we have to use a special ROM, we don't need all this stuff above, as most allow /dev/ttySomething to access modem via shell.

[E3V3A]

@xLaMbChOpSx and @SecUpwN : So let me understand this right.

1. AIMSICD will not run as intended on any stock ROMs? Only on AOSP originated/signed ROM? Is that correct?
2. If so, which are those ROMs? (How can the user find the compatible ones?)
3. When did Google introduce these requirements? (At what API?)

@xLaMbChOpSx : What exactly do you need to make this work on a stock ROM?

[xLaMbChOpSx]

@E3V3A unfortunately yes using the AOSP platform key will limit the use of the application to AOSP based ROMs which is most custom ROMs such as CyanogenMod, AOKP, Slim, Omni etc. Plus phones like the Nexus should also run it with no problems.

This is a core 'feature' and I believe has always been part of Android and probably other operating systems such as iOS, just like how Windows uses digital signing for executables.

For universal compatibility I can remove the frameworks and telephony class files, remove all references to the core telephony classes and methods, modify the manifest so it does not share the phone process. Then the app would not need to be installed as a system app addressing the easy installation issue as well.

[E3V3A]

@xLaMbChOpSx Aha, ok. That is just too bad, because I think people who would need this app the most, are probably unwitting normal stock users, who have no clue about ROMs or Android development.

So my last question above, was what exact functionality you would need to keep to be able to go stock? I understand this is not an easy question to answer, since you're probably not completely aware about all future functionality, but only for what you have now. However, I certainly have no clue since I can't get this installed, so I don't know what it is doing at the moment. Very frustrating.

Now, if I'm going to spend time flashing a new ROM (just to get this working), perhaps you can recommend me one, so that we can stay on the same page? At the end of the day (or month, figuratively speaking) we really have to figure out how to make this app, ROM independent and Stock OKAY.

Now, in order to help you, I need to know exactly what functional part of the current app, that requires internal (and thus AOSP ROM signature) dependence). We'll then work toward replacing these. Even if it takes different device dependent methods to get this working.

[xLaMbChOpSx]

@E3V3A Totally agree with your last comment and the main target audience of the app, how about I create a new branch that can serve as an archive for the current state of the app and I will modify the master branch so it can be installed on all ROMs as a user app. Then we can focus on getting results using the terminal, basically the functionality that we will lose doing this is the ciphering indicator response provided by the raw ril method. Tracking of cell, location and signal info will still function as well as drawing the basic device info.

For a custom ROM I really like Slimroms and have been using SlimSaber which is SlimKat (kk4.4) compiled with the sabermod linaro toolchain, they are not overloaded with features and provide great stability.

[SecUpwN]

@xLaMbChOpSx, your proposal sounds good, but wouldn't a separate branch confuse the users which App to install and how? As for loosing the core functionality of retrieving the ciphering indicator response: Did I miss an alternate method of retrieving it, will it be re-added in the long run or what else is planned?

@E3V3A, have a look at AOKP. I've been testing this extensively (for years on a broad range of different phones) and must say I've never had a ROM with more features and stability than this one. It's based on the work of CyanogenMod, but massivle extendet and improved ( in their won words: "Android infused with magical unicaorn bytes"). If your phone is supported (search their device list), definitely get it NAO!

[xLaMbChOpSx]

@SecUpwN No if we create another branch we can just publish releases that link to the master branch, if somebody wanted to compile the other branch they could do that themselves. It just sits in the background with the master branch being the default.

[SecUpwN]

Perfect, then so be it! New Icons have been merged, by the way. Hope we can solve all the issues @E3V3A has been experiencing - I just wish he can use AIMSICD. Keep rockin', @xLaMbChOpSx!

[jofrep]

@xLaMbChOpSx "Plus phones like the Nexus should also run it with no problems."
I tested it in a Nexus Galaxy and I got a signature problem error. Could check other Nexus if is worthy.

@E3V3A
I use CyanogenMod as it comes with PivacyGuard, a system app that should be mandatory in all Android devices.

[SecUpwN]

@jofrep, just to mention it here: Xprivacy, which is also on XDA is the best. Undoubtely.

[jofrep]

@SecUpwN I have to agree it looks better as I see you can block Internet access too. I´ll give it a try. Thanks

[E3V3A]

About the ROMs, they both look really nice,and have been considering both of them in the past, but now I think SlimSaber is better for me. The main reason, because main developing is done on that and most importantly he's using the same BP (XMM) as me. It is also tuned down to stay "slim". I don't need all features.

The bad and good thing with CM based ROMS are that they remove or modify many and various (OEM) ServiceMode functionalities (and apps), which often prevent the use of "secret codes" for accessing various debug menus. I am not sure I can live with that, and is also a reason why I choose to stay with outdated stock for so long.

@SecUpwN Yes, that means removing ciphering indicator for now. But what is more surprising is that both your phones are Qualcomm based. And from what I understand, access to AT serial device is much easier to find on those devices. Have you even searched for this? If not, that is ok, but please do have a thorough look around in your /sys and /dev directories. (I will post instruction in XDA what to search for and how.) Try to find (on google) the source or binary called "radiooptions", it has OEM_HOOK option!

@xLaMbChOpSx So to verify, you wanna make the "stock" branch as master? right? And then people who wanna try "CI" can download the archived signed AOSP version? If so then I'm all happy with that.

Finally re-iterating what I said elsewhere. You are both running ROMs, which also means that any attempts by OEMs to hide the modem device from user-space, should have been reimplemented. So I think you need to have another look on what devices are present, and what the RIL daemons are using. Also, can you try to find and run "ipctool/ipcdump"?

[xLaMbChOpSx]

@E3V3A @SecUpwN Pushed the initial commit to restore universal compatibility and also published a new release which should function on all devices and can be instated as a user application.

[SecUpwN]

@xLaMbChOpSx, just for my own peace of mind: What is the preferred way of installing the App? I know we're aiming towards providing support for normal and easy-peasy installation for Stock-ROMs, but as for development purposes are we having two separate Apps now? Or is this already the new way of installment, adding the features back in later? 👍 EDIT: Never mind, #24 explains it beautifully. THANKS!

[xLaMbChOpSx]

@SecUpwN One thing you need to do is first delete the previous version from the system location then reboot, after that you can install the new version like a normal app. You need to do this or else you will get a signature error when installing.

[SecUpwN]

Thank you, just noticed this @xLaMbChOpSx. Awesome work, once again!

[E3V3A]

Yes, I've been playig all night with this. Nice.. Does FC's on Maps and Export.
Not sure how often if it updates the LAC/CID? Are you using a poll mechanism, or just waiting for java signal via API? (How often does that poll?)

[E3V3A]

@SecUpwN @xLaMbChOpSx
Did you already see this?
https://github.com/narseo/ril_analyzer
http://rilanalyzer.smart-e.org/

[SecUpwN]

@E3V3A, nope. Nice find! Will get in touch with the authors today.

Since all issues in this ticket seem to be solved now, I'd like to close it for good. Please continue discussion about RIL analyzation in a fresh (if not already existing) Issue (#23 perhaps) after @xLaMbChOpSx answered your previous question here. Thank you for keeping it structured guys! :)

[xLaMbChOpSx]

@E3V3A just checked out the RilAnalyser you linked and it uses the same type of methods we just removed from the master branch by sharing the phone process and utilizing the methods from the Samsung Service Mode application. It is very nice though with a large range of features implemented I will be looking at this more tonight when I get home.

Currently the LAC/CID should update whenever the activity is started or brought to the foreground, if you have enabled one of the tracking options then that will register a listener that monitors the specific state and if say the CID changes it will log that data.

[illarionov]

@xLaMbChOpSx, Please note the proposal to move out system functionality into separate, optional application, as I suggested in #3. There is a blank for such the service with that forwards some of Samsung Service Mode functions .

[xLaMbChOpSx]

@illarionov Yes I did see that but to ensure we can provide an application that can be used on stock firmware the sections that used the same methods as the service mode app have been removed due to the fact this required signing with the AOSP platform key. I created the aosp_only branch which holds the source that used these methods but at the moment I will be focusing on the master branch and command injection via the terminal. The RilAnalyser source that @E3V3A linked also used this method of splitting the application.

[E3V3A]

@illarionov : Believe me I'd really be happy to just use the fully functional version, based on hacked internals and AOSP signatures. BUT that would deter the aim of this project, which is to provide a useful security app for people outside the development community. First, because developers would stop looking for sensible ways to access AT serial device (or equivalent IPC shared memory modem communication interface) from within phone shell, and second, developer's would just take the plugin and head off in another direction and develop for their own ROMs, and that would be the end of this open project. And even if there were such a plugin, it would be very device dependent anyway, since it relies on the modem firmware. (Next modem FW update it could be dead!)

So the best way you could help, is trying to find ways to:

1. Send and intercept AT commands from command line.
2. Find how to use the modem shared memory devices to
   a) get debug diagnostic info
   b) inject IPC messages

[illarionov]

@E3V3A, I have an I9100G. As far as I know, its service mode is quite well known. It has a function that allows you to get some sort of information about encrypting of connection - OEM_SM_TYPE_SUB_CIPHERING_PROTECTION_ENTER . Both AIMSICD (aosp_only) and my app has an implemetation to receive this info.

Obviously, the normal (stock-firmware) application does not have access rights of the system app and will not be able to get this information. Even if this application will have access to the android command line. If you find a way to get this info without system privileges - you'll find a serious security hole.

One option that you can use, is to monitor output of adb logcat -b raw. To do this, your application must have a permission of android.permission.READ_LOGS. But in Android 4.2 Google has limited access to this permission and now application requires root access to turn this permission on (http://sseblog.ec-spride.de/2013/05/privacy-threatened-by-logging/).

What concrete debug info you need? And why do you need them if it would not be available from application without rights?

[E3V3A]

@illarionov Sorry my bad, that should be diagnostic info, not debug into. If you had read the XDA thread, you would have found in this thread that I already know all about that. And we already mentioned that this app should require root to function properly. I think you need to read a little and some of the PDF documents, if you want more and better answers.

If you just want to read your IMSI and signal strength etc, there are hundreds of Apps in Google Play you can use.

[illarionov]

@E3V3A, thanks for pointing out to XDA thread. Looks like I missed this post.
Now I understand the approach that you are trying to apply (I hope so).
I have an CyanogenMod installed. It does not have ipcdump/ipctool.

shell@android:/ # find . -iname ipcdump
shell@android:/ # 

The com.android.samsungtest package is not installed too and there is no such an application that would be handle the com.android.samsungtest.RilDFTCommand intent.

shell@android:/ # am start -D com.android.samsungtest.RilDFTCommand            
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] pkg=com.android.samsungtest.RilDFTCommand }
Error: Activity not started, unable to resolve Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 pkg=com.android.samsungtest.RilDFTCommand }

Although it is possible to execute the invokeOemRilRequestRaw() using the com.cyanogenmod.SamsungServiceMode.EXECUTE intent, but it is very limited. (SamsungServiceMode.ExecuteReceiver.java). I will try stock firmware later.