Counter Measure: Disable GTalkService

[E3V3A]

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.

[SecUpwN]

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

[E3V3A]

So how do you install apps on that? If you can use Google Play, then it's probably running...

[SecUpwN]

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.

[andr3jx]

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.

[E3V3A]

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

[andr3jx]

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.

[SecUpwN]

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

[E3V3A]

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

[SecUpwN]

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

[E3V3A]

XPrivacy might be another choice to look into...

[SecUpwN]

XPrivacy might be another choice to look into...

Maybe @M66B can give us a hint on an easy solution?

[E3V3A]

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.

[E3V3A]

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.

[SecUpwN]

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?

[E3V3A]

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.

[SecUpwN]

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.

[menschenfresser]

We should not use google apps at all. After installing pure CM11 without gaaps I feel a free person, at last :-)

[E3V3A]

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

[menschenfresser]

censorship :-( then fuck this project.

[He3556]

we are trying not kick out all Google Services anyway, no need to delete anything.

[SecUpwN]

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!

[SecUpwN]

@E3V3A, I'm pushing this Issue to get a better idea of it. What do you think about my suggestion here?

1. After each boot of the phone, AIMSICD would check if GTalkService is present.
2. If GTalkService is present, AIMSICD could display a warning and offer to disable it.
3. Make disabling/enabling an option in the PREFERENCES which is greyed out if not present.

[E3V3A]

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.

[andr3jx]

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

[E3V3A]

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

[SecUpwN]

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:

1. Use getRunningServices to get all running services
2. Use getServiceInfo to retrieve all services of any app
3. Use the pm command to disable any found services

[E3V3A]

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.

[SecUpwN]

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

[SecUpwN]

Also re-opening this Issue for @smarek to have a last look at it if this can be implemented at all. Thanks!

[vanitasvitae]

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

[SecUpwN]

"Do one thing and do it well". Why don't you implement this feature in another app?

@vanitasvitae, if you would have read the whole Issue, we were trying to find out if there is a way of detecting whether GTalkService can be detected and disabled because of its functionality to remove apps from a device without even asking the user. So if Google or any other third person wanted AIMSICD to vanish from your device to prevent IMSI-Catchers being detected, they'd simply have to press a button. Or, even worse, anyone wanting to compromise your phone could silently push a hidden surveillance app onto your phone. Detecting and disabling GTalkService and related spyware is considered a countermeasure, see DB_id 13 in #230. So now that you know the purpose, please help us solving this.

---

And while I'm at it: I recently found DisableManager by @75py on F-Droid. Maybe he'll be able to join in.

[vanitasvitae]

@SecUpwN: I do have read the whole thread. But I still think AIMSICD should prevent you from getting spied on by IMSI Catchers, not from getting apps installed on/removed from your phone. You could still put that functionality into another app and even promote that app from within AIMSICD.

After all that's just my opinion, but I think AIMSICD should let the task of hardening android up to the user.
Also (I'm not an expert) I think the risk of AIMSICD getting removed remotely by android is pretty low and I don't know if its worth the effort.

[SecUpwN]

You could still put that functionality into another app and even promote that app from within AIMSICD.

Thanks, but we decided this to be a countermeasure to be made available from within our app. So please do not question our decision here, but rather provide some useful thoughts on how to accomplish this.

[vanitasvitae]

Question everything! :)

I currently do not have the time/knowledge to contribute code, but this is open source so I thought I'd contribute by adding to this discussion.

In the end its your choice though.

[SecUpwN]

@jensstein, since you develop my favourite backup manager oandbackup, do you see a way we could detect GTalkService and disable it (possibly only when ROOT is present)? Input is much appreciated.

---

@f3ndot, could you please have a look at the following answer of @jensstein? Which way to go?

i do understand your aim with the issue, i just want to know whether the solution already proposed has been tried out:

Use getRunningServices to get all running services
Use getServiceInfo to retrieve all services of any app
Use the pm command to disable any found services

this sounds like a clear blueprint for doing both the detection and for disabling the service. so i'm just asking which kind of input you are seeking. are you looking for pointers on how to implement this precedure in code? or does the procedure have some issue which need to be resolved? i'll happily give an answer in the issue when i know what you are seeking and if this method has been tried out :)

also, another point would be in which order gtalkservice is started during startup and whether it can be made to stay disabled with pm - say another component of gapps checks whether the service is running or not and starts it if it isn't and that this happens before a user app can run any protective measures. even if this might not be the scenario today it could be with a future revision of gapps.

[rdarioc]

HI all,

first my compliments for your work.

I have been playing with your app for a couple of days. It is my understanding that the feature discussed in this thread it is a nice to have but not yet implemented, I may be wrong since your main website lists this feature among the other things the app actually does but, it wasn't able to detect it on a couple of phones I have been testing it with.

That being said, in case you are still looking for a working way to detect if the GTalkservices are installed and how to disable it, I tested DisableServices, as above recommended. Unfortunately that app was not able neither to find all the occurrences of the mentioned service nor to disable any of them. (I am running a rooted 4.4.2)

Then I tested Autostarts (https://github.com/miracle2k/android-autostarts) with the binaries available on F-Droid and this app actually made the work. Its search function browse across all the services available on your Android, so it was enough to search for GTalk and all about a dozen of services were found. Furthermore I was able to disable for good the service. This configuration was working also through reboots and it was permanent.

I may also point out that the option mentioned above (typing ##8255## ) may or may not find out if the GTalkservices is active or not, as it relates only to one of the several subservices and, as matter of fact, while the Samsing S5 I used for test had this "shortcut" not available, in truth the GTalkservice was up and running, so to speak.

Last but not least, disabling this feature seems not to have affected my ability to install apps from the Google store.

Hope all this helps. Again my compliments for your work.
Dario

[SecUpwN]

Thanks for your wonderful contribution, @rdarioc! Now we only need a pull request to implement the detection of that in our own app here, while at the same time prompting the users that it has been detected and if it shall be disabled. Maybe @miracle2k can help us with that?

[0pLuS0]

Isn't GTalkService in Google Services Framework?

Are we talking about the same app? I thought GTalk is Google Talk/Hangouts?

What happens if you just simply Debloat out all of Google/Gapps and run microG instead, isn't problem solved?

On a Stock Rom I debloat all of these and run microG.

Android Setup
Calendar
Chrome
Drive
Duo
Gboard
Gmail
Google
Google Backup Transport
Google One Time Init
Google Partner Setup
Google Pay
Google Play Movies
Google Play Music
Google Play Services
Google Services Framework
Market Feedback Agent
Maps
Photos
BugReportLite
EngSpecialTest
FactoryMode
Insight Provider

I had assumed now, with all of these gone, it would be safe to just leave the Play Store installed going through microG...

Hmm