Mission Possible: Securing and liberating Android 4.4

{X} This is an incomplete and propably also out-of-date article written in Mid-2015


As already stated, I think the "Mission Impossible"-Article is still great and probably the most-complete tutorial, so I won't rephrase the article but instead list the things which are either outdated or missing from my point of view. There are some things I disagree with, so I'll try to explain why I chose another route. Actually these are the things which I'd like to read before 1-2 weeks, so I hope it will be useful.

Choosing the right ROM

TL;DR = Unless you have a device which is supported by Replicant, choose OmniROM. If there isn't already a OmniROM build for your device, try to make one - it might still be easier than securing CyanogenMod. If all fails, use CyanogenMod (or look for other ROMs).

In 2014, Cyanogenmod was probably still the best choice, although it became already clear that this won't last long. In 2015, when using Cyanogenmod while targeting for a fully OpenSource ROM, you have to actually work heavily against it (like removing Google Analytics and other proprietary stuff). It doesn't seem that this will change in future, given that the CM Devs founded a company (Cyanogen Inc.), started to commercialize the project and are currently having a partnership with Microsoft. So in 2015, CM doesn't seem to be a good base any longer, and I would generally recommend OmniROM instead of CM (if it is already available for your device). OmniROM is AOSP-based, community-driven and aims to be a fully OpenSource ROM - it's basically a reaction to the commercialization of CM. OmniROM has also a much more advanced built-in tool for handling permissions for Apps and comes with some developer tools which might be handy.

((The developer of the free-cyangn project, which removes Google Analytics from CM (and also substitutes some other proprietary bindings) switched to OmniROM, too, but he is still maintaining the free-cyangn code.

((The Replicant project is currently based on CM, but is also thinking about using OmniROM as a base in future. I think it would actually make much sense to see those projects merged together, given that they both aim to be fully OpenSource.

Google Apps

TL;DR = Don't use Google Apps.

I would strike the "Google Apps" part completely, even if it is marked as optional. I think it would better to write a part about why you should not install Google Apps. It should state that:

Of course, it's possible to disable access to nearly everything like the author of the MI-Article did - which is a lot of hassle - but if you succeed, you're actually not getting a secure device, but only a secure snapshot. There will be updates for Google Apps, and you will have to adjust. So, when installing Google Apps you are actually leaving the "Mission Possible" route and are back at "Mission Impossible".


Preparing the Installation

gpg --recv-keys DD5DCE7A
gpg --verify org.fdroid.fdroid_910.apk.asc org.fdroid.fdroid_910.apk

/!\ Superuser: OmniROM doesn't come with a bundled Superuser-App, so you will have to provide your own. Unfortunately I didn't try if it's possible to just simply install the one from F-Droid after first boot, I downloaded and flashed it manually


After flashing TWRP, reboot into it. Use ADB to push your ROM (and ROM Checksum) and flash it with TWRP. Don't reboot now, but if you ever reboot manually from TWRP, you might be asked if you want to install SuperSU - do not confirm. You want to use "Superuser" instead, which is OpenSource.

Remove Components

I recommend to remove any shipped APKs which you don't need or want, are proprietary, unsafe to use or hurt your privacy. They are located in either /system/app or /system/priv-app/. While still in recovery mode, you can easily use "adb pull /path/to/apk" to make a backup, and "adb shell rm /path/to/apk" to remove them. Packages I removed on both, CM+OmniROM:

Sample Code (only works for APKs located in /system/app/):

for app in Email Browser Apollo SoundRecorder ; do
        echo "removing $app"
        adb pull /system/app/${app}.apk "${app}.apk" && adb shell "rm -f /system/app/${app}.apk"


Packages I removed on CyanogenMod (or: why you shouldn't use CM):

There are probably much more packages which I would have removed, but after I realised that the CM developers had also integrated Google Analytics, it became clear that CM is a "Mission Impossible" of it's own. If you have to use CM, it's probably best to start with the free-cyangn tool which subtitutes the built-in Google Analytics with NoAnalytics. I did not, I switched to OmniROM. Note that the developer of free-cyangn also switched to OmniRom, so he is not developing it further, but he is still maintaining it.


Packages I removed on OmniRom:

Add Components

Now it's time to add some stuff - at least the F-Droid package, which should be placed in /system/priv-app/ so it is a "privileged system app" and therefore you won't need to tick "Allow installation from untrusted source". Other packages should be fine in /system/app/. I found it handy to also push other data, like some configuration files from a prior Android installation, or a textfile with the password for my WiFi-Hotspot, so it's possible to copy&paste it while being in Android OS.

So, basically it goes like this:

adb shell mount /system        # should be already mounted
adb push org.fdroid.fdroid_910.apk /system/priv-app/
adb push dev.ukanth.ufirewall_171.apk /system/app/
adb shell mount /sdcard         # should be already mounted, too
adb push wifi.txt /sdcard/      # password for WiFi
adb push settings.k9s /sdcard/  # K9-Mail configuration file from prior installation
adb push black.png /sdcard/     # I didn't want to install an app for setting a solid black wallpaper -> localhost

Every time you're connecting to a WiFi-Hotspot, will be polled (see Line 64 + Line 376 @ ). Quick'n Dirty Workaround:

adb shell "echo '          ' >> /system/etc/hosts" -> localhost

It doesn't matter if you're disabling NTP in the System Settings or not - will be queried (see Line 1045 @ ). Quick'n Dirty Workaround:

adb shell "echo '          ' >> /system/etc/hosts"

First Boot

I guess it's possible to configure following steps via CLI even before the first boot, but for now, I'm just documenting these:


K9-Mail + OpenKeyChain

K9-Mail shouldn't need a further explanation. I recommend OpenKeyChain instead of AGP, because the development of AGP is stalled, the last AGP updates only pulled code from OpenKeyChain.


App for managing tasks. If you want to sync your tasks via CalDAV with DAVDroid, you have to install this first.


Use DAVDroid to sync Contacts, Calendar and Tasks (see above) with your own server via CalDAV.


Nice RSS feed reader with offline support. It's possible to configure a Proxy, too. So if you are using "Automated Refresh", think about using TOR as a proxy, since speed won't matter in this case.

Fennec (Firefox Mobile)

To be honest, I can't recommend Firefox any longer. I'm listing it here because it's better to have a browser which is getting security updates regularly (in contrast to the AOSP Browser), but in regard to Privacy, Firefox/Fennec should have an own "Mission Impossible"-article. Fennec seems to regularly send pings to Google, for whatever reason. Following steps could not stop Fennec to try sending data packets to Google:

Note: data packets has been tried to sent to Google even without doing anything, right after the first start of Fennec without typing anything in the URL bar, and without tapping anything. Changing the default search engine from Google to Wikipedia also didn't make a difference. Worse: these "pings" are still trying to be sent when Fennec is in background while using another app, so it is needed to explicitly close Fennec to stop these. At some point, I allowed internet access for Fennec, so it could get updates (or whatever it wants from Google) and had the hope that after that it would stop sending packets to Google. It didn't helped, I firewalled Fennec again, and at the next day there were hundreds of data packets in the firewall log which couldn't be sent from Fennec to Google.

TODO: why are packets being send to port 4882 at the local gateway / router?


I disagree with the "Backups"-part in the MI-Article, mainly for two reasons:

Of course, when backing up via recovery mode, you'll have to use a cable - but on the other hand you don't have to configure your firewall and ADB for wireless usage (and disabling it after that), therefore wireless backups IMHO aren't convenient anyway.

FIXME this needs to be verified



Things I like to see in 2016:

Supporters/Guest-lasse_lindner (last edited 2020-11-29 13:15:57 by doczkal)