{ "id": "f0af718f-ee0b-459d-8ff6-c609844a416a", "created_at": "2026-04-06T00:06:38.049066Z", "updated_at": "2026-04-10T13:12:32.434486Z", "deleted_at": null, "sha1_hash": "113001f599e25222a41bf2417b4d2f1e9f0653a7", "title": "Remote Kill and Install on Google Android", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 190791, "plain_text": "Remote Kill and Install on Google Android\r\nBy Jon Oberheide\r\nArchived: 2026-04-05 19:44:19 UTC\r\nIn this post, I\\’ll talk about the REMOVE_ASSET and INSTALL_ASSET mechanisms that can be invoked by\r\nGoogle via Android\\’s GTalkService to not only remotely remove applications from an Android device but also\r\nremotely install new applications.\r\nRootStrap Background\r\nSo if you didn\\’t check out my slides from SummerCon last week in NYC, I talked a bit about a program called\r\nRootStrap in the second half of my talk. RootStrap is intended as an example of an application that could be used\r\nto bootstrap a rootkit (hence the name). Summed up as briefly as possible, RootStrap phones home periodically to\r\nfetch remote native ARM code and executes it outside the Dalvik VM. An attacker could use such an approach to\r\ngain a large install base for a seemingly innocent application and then push down a local privilege escalation\r\nexploit as soon as a new vulnerability is discovered in the Linux kernel and root the device. Since carriers are\r\nfairly conservative in pushing out OTA patches for their devices, an attacker could easily push out their malicious\r\npayload before the devices were patched.\r\n \r\nIn addition to the sample RootStrap application, I also posted an innocent looking app called \\“Twilight Eclipse\r\nPreview\\” that claimed to be a preview of the upcoming Twilight Eclipse movie to the Android Market. The\r\nTwilight app was actually just RootStrap in disguise, displaying a Twilight image while phoning home to check\r\nfor new payloads to pull down and execute. Obviously, none of these payloads were actually malicious in nature.\r\nhttps://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/\r\nPage 1 of 4\n\nThe Twilight app got \\~200 downloads in the first 24 hours but started slowing down as it received bad\r\nreviews...apparently I don\\’t have a future in marketing mobile apps to Twilight teens.\r\nAndroid Remote Kill\r\nIn response to Andy\\’s coverage on Forbes of my SummerCon presentation, Google asked me to withdraw my\r\napplications from the market, which I had no problem doing. Later that day, I noticed a couple of notifications on\r\nmy phone:\r\nSweet, Google had just invoked their remote kill functionality! Apparently not many people have dug into the\r\nvending APK, but I\\’ve known about the REMOVE_ASSET functionality for a while so it was neat to see it being\r\ninvoked on my phone. I verified my assumptions of the REMOVE_ASSET intent by bringing up the\r\nGTalkService monitor:\r\nTalking with Rich later, this was apparently the first time the Android team invoked the remote kill functionality. I\r\nhad assumed it had been used frequently in the past, but apparently attackers have been slacking off. Rich covered\r\ntheir use of the remote kill functionality on the Android Developers blog today.\r\nNow, the Android platform not only allows for the removal of applications remotely via the REMOVE_ASSET\r\nintent, but also allows for the installation of new applications via the INSTALL_ASSET intent. If some people are\r\nupset that Google retains the ability to kill applications remotely (I personally prefer the potential security gains of\r\nthe functionality), I fear what they\\’d think of the INSTALL_ASSET feature. ;-)\r\nThe GTalkService Connection\r\nhttps://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/\r\nPage 2 of 4\n\nSo just how does the remote install and remote kill functionality work on the Android platform? I actually talked\r\nabout this functionality in my SummerCon slides as well when discussing the operation of the Android Market\r\nand its protocol.\r\nYour Android device maintains a persistent TCP/SSL/XMPP connection to Google\\’s GTalk servers at all times\r\nover your device\\’s data connection (either your mobile data service or WiFi). This connection is managed by a\r\nservice aptly named GTalkService. Your device will automatically re-establish this persistent connection whenever\r\nyou move between networks and periodically sends heartbeat messages to Google\\’s servers.\r\nThe GTalkService connection allows Google to push down messages to your device. For example, Google\\’s\r\nrecently announced C2DM (cloud to device messaging) platform uses this connection to provide push\r\nfunctionality to third-party apps.\r\nAs seen in slide #11 and #12 of my presentation, the GTalkService is actually used during the normal Android\r\nMarket install process. Instead of downloading the APK from the Market, clicking \\‘Install\\’ will trigger Google\\’s\r\nservers to push a INSTALL_ASSET message down the GTalkService pipe. Upon receiving this message, your\r\nphone will download and install the APK.\r\nAs expected, the REMOVE_ASSET intent functions similarly. Google can push a REMOVE_ASSET message\r\ndown to all the Android phones in order to remote kill a particular application deemed malicious.\r\nBoth the INSTALL_ASSET and REMOVE_ASSET functionality are implemented in the vending APK:\r\nSecurity Concerns\r\nWhile remotely removing apps might ruffle the feathers of people who like the feeling of having full control over\r\ntheir device, the remote install functionality is of more concern from a security perspective.\r\nAs I mention on slide #14, if an attacker is able to MITM this SSL GTalkService connection for a particular\r\ndevice, it may be possible to spoof these INSTALL_ASSET messages to deliver a malicious application payload.\r\nIf Google\\’s GTalkService servers were compromised, the malicious impact would obviously be a bit more\r\nwidespread.\r\nYou better believe that myself and others are taking a careful look at these code paths. :-)\r\nhttps://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/\r\nPage 3 of 4\n\nSource: https://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/\r\nhttps://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/" ], "report_names": [ "remote-kill-and-install-on-google-android" ], "threat_actors": [], "ts_created_at": 1775433998, "ts_updated_at": 1775826752, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/113001f599e25222a41bf2417b4d2f1e9f0653a7.pdf", "text": "https://archive.orkl.eu/113001f599e25222a41bf2417b4d2f1e9f0653a7.txt", "img": "https://archive.orkl.eu/113001f599e25222a41bf2417b4d2f1e9f0653a7.jpg" } }