CellularPrivacy
Counter Measure: Disable GTalkService
It's been known for a long time that Google has the power to pull or push any app to/from your phone, using the GTalkService: INSTALL_ASSET or REMOVE_ASSET. Thus we would like to disable this dangerous functionality, or at least detect it, when app is in a non-green detection/status mode. In addition, turning off GTalkService will also improve your battery life somewhat. Fortunately (!) this will also block the use of Google Play and updates. We need to:
- [ ] Collect more info on which exact service need to be disabled
- [ ] Find out if the above event can be easily detected and/or blocked, even if all services are running.
References: https://jon.oberheide.org/blog/2010/06/28/a-peek-inside-the-gtalkservice-connection/ http://forum.xda-developers.com/showthread.php?t=2357417&page=119 http://forum.xda-developers.com/xperia-u/issues/app-disable-service-t2455525
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@E3V3A, thanks for adding this. Since I run a CustomROM, I guess I don't have GTalkService since I did not flash a GAPPS-package. How can I verify that no services like GTalkService are running?
So how do you install apps on that? If you can use Google Play, then it's probably running...
I enjoy using Aptoide and F-Droid. The least thing I'd ever install on my phone, is GAPPS. That is a perfect bundle of spyware, folks. I am happy having freed my phone.
Use this to disable services: https://play.google.com/store/apps/details?id=cn.wq.disableservice&hl=en But I don't think if this approach is really so good. If people use Google's services they can't expect that Google will ask them for anything. As far as I know Google used this feature to remove a malware-app on all phones after it was installed.
@andr3jx I don't see how that has anything to do with this issue? (You're suggesting to download an outdated service app from GP to disable gtalkservice?) We can obviously do this much easier from command line.
I don't see how this issue is related to detecting IMSI-Catchers. I'm against implementing it. If someone wants to disable some google services he can use the mentioned app.
@andr3jx and @E3V3A, would you please stop fighting like two little kids here? In my eyes, disabling GTalkService is not on our current priority list, yet I do consider proposed feature important to be added at some point. Why? If Google can obviously boldly ignore Issue 5353 since 2009, then I have to suppose they are working together with agencies that do not want people to be warned about such things like unencrypted communication channels, Silent SMS or other possible attacks. And that leads me to the assumption that our App could get uninstalled through them without the user of our App knowing. Maybe @mar-v-in from the NOGAPPS Project can help us conveniently disabling this service?
Ok, let me clarify how this is related to this AIMSICD. The Google INSTALL_ASSET or REMOVE_ASSET can be used to install or remove anything (by anyone), including our app and replacing it with spyware, if someone wanted to. Now I'm not saying this is trivial to do, which it isn't, but the fact that it can be done, is bad enough, especially when your name is Google. So this is an extremely dangerous function, that we really think the user should be in charge of.
Thus, the proposal is to implement this as a detection mechanism in settings, and let the user decide whether or not this can be disabled. So there is nothing really to argue about here. In addition, this is one of the very few easy to implement detections of when your device is being remotely manipulated. That is the skull icon. "Hit emergency wipe, drop and run!"
@E3V3A, thank you for this clarification. Everyone should now see the additional importance to implement this feature. And thanks for your comment, @andr3jx! I have just contacted the developer of the App and hope he might shed some light on how to fully disable GTalkService.
XPrivacy might be another choice to look into...
Maybe @M66B can give us a hint on an easy solution?
Here are two more articles on the Andoid remote "Kill Switch" law in California and how EFF is trying to prevent this craziness. here and here ~~Note: it's quite possible that kill switch is different from that of Google in OP.~~
Kill switch is made by Google.
Google released Android 5.0 Lollipop Wednesday, and for the first time, it lets users to enable a “kill switch” on their phones. The feature, dubbed “factory reset protection,” requires a Google ID and password before a phone can be reset, and only works when a phone passcode is enabled.
The feature, dubbed “factory reset protection,” requires a Google ID and password before a phone can be reset, and only works when a phone passcode is enabled.
Sounds like custom ROMs are "safe" from this "feature". Or is it hidden in there as well?
Instead of asking new questions to an already complicated topic, try to find some of the answers yourself. Not everyone care about custom ROMs, and they're all different.
Just tossing this into the discussion: *#*#8255#*#* should launch the so-called GTalk Service Monitor (didn't work on my AOKP ROM though). And since @jonoberheide wrote the awesome blog post you mentioned in the OP, I felt like he's the right person to help us on this. I wrote him a message introducing this challenge to him 16 days ago, but sadly did not receive an answer yet. Still hoping for a reply of him.
Did you know that Google exercised the remote application removal feature on the Apps of Jon which he used to demonstrate on SummerCon security conference how easy it would be to bootstrap a Rootkit onto Android phones via the Android Market? I will continue to research for implementable methods.
We should not use google apps at all. After installing pure CM11 without gaaps I feel a free person, at last :-)
@menschenfresser Well, sorry, but we're trying to promote a wider support for our App. Please don't bother posting in the issue threads unless you have something more constructive and relevant to tell us.
I have removed some of your other posts as they were completely irrelevant.
we are trying not kick out all Google Services anyway, no need to delete anything.
censorship :-( then fuck this project
@menschenfresser, first of all: Cool to see you're running pure CM without any GAPPS installed! Have you ever tried out AOKP? It is based upon CM, but yet enables much more tweaking - I just love it! Thing is, I hate Google stuff, too. But since our App shall run on as many devices as possible (which likely most of the time run stock ROMs), our project is not meant to remove all Google crapware, because this would require ROOT and is beyond the scope of developing our App. Here comes the good news: Since I am one of those privacy fanatics having rooted my phone and love phones free of Google (welcome in my club), I have been working on our project with AOSP ROMs and alternatives in mind from the very start.
Maybe you can elaborate a little on why you're so angry about our project? Feel free to get in touch with me via E-Mail, I am sure I can clear things up for you. Help us with pull requests!
@E3V3A, I'm pushing this Issue to get a better idea of it. What do you think about my suggestion here?
- After each boot of the phone, AIMSICD would check if
GTalkServiceis present. - If
GTalkServiceis present, AIMSICD could display a warning and offer to disable it. - Make disabling/enabling an option in the
PREFERENCESwhich is greyed out if not present.
Sound good to me, but I don't know how to do that in practice. I know Titanium Backup and App Quarantine can do this, but not how it's actually done.
Check if service is running - I have -not- found a way to list all components of a package (like DisableService app does).
dumpsys activity services | grep -i "GTalk"
dumpsys| grep -i "gtalkservice"
Disable service:
pm disable com.google.android.gsf/.gtalkservice.service.GTalkService
another thing to disable
pm disable com.google.android.gsf/.gtalkservice.service.GTalkServiceProxy
pm disable com.google.android.gms/.gcm.ProxyGTalkService
others I found:
.gtalkservice.service.ConnectionService
.gtalkservice.service.ConnectionServiceProxy
.gtalkservice.service.PushMessagingRegistrar
.gtalkservice.service.PushMessagingRegistrarProxy
Excellent! Now we need to test this on various stock devices. (I assume ROMs are not using this, unless Google "add-ons" have been added.)
I've just received an answer from @wangqi, the creator of the App Disable Service. He said that his App has a very simple functionality and basically does these things:
- Use getRunningServices to get all running services
- Use getServiceInfo to retrieve all services of any app
- Use the
pmcommand to disable any found services
This is great, but unfortunately this seem to be just the top of the iceberg. A recent review of my Samsung device Android permissions, was really jaw dropping as well. While providing useful insight into why certain other things doesn't work. Which means that for Samsung phones we have a whole new set of these dangerous remote tools.
@E3V3A, I vote for adding detection and protection against this one and on adding the core features of our App as a priority. We can (and should) open separate Issues for the other attack vectors and then see how we can possibly add countermeasures for these relevant to IMSI-Catchers and remote attacks.
Also re-opening this Issue for @smarek to have a last look at it if this can be implemented at all. Thanks!
"Do one thing and do it well". Why don't you implement this feature in another app? I would not expect this functionality from an IMSI-Catcher detector...
