Mission Impossible: Hardening Android for Security and Privacy

by mikeperry | April 3, 2014

Updates: See the Changes section for a list of changes since initial posting.

This post has been updated further by the November 2016 Refresh of the same idea

Executive Summary

The future is here, and ahead of schedule. Come join us, the weather's nice.

This blog post describes the installation and configuration of a prototype of a secure, full-featured, Android telecommunications device with full Tor support, individual application firewalling, true cell network baseband isolation, and optional ZRTP encrypted voice and video support. ZRTP does run over UDP which is not yet possible to send over Tor, but we are able to send SIP account login and call setup over Tor independently.

The SIP client we recommend also supports dialing normal telephone numbers if you have a SIP gateway that provides trunking service.

Aside from a handful of binary blobs to manage the device firmware and graphics acceleration, the entire system can be assembled (and recompiled) using only FOSS components. However, as an added bonus, we will describe how to handle the Google Play store as well, to mitigate the two infamous Google Play Backdoors.


Introduction

Android is the most popular mobile platform in the world, with a wide variety of applications, including many applications that aid in communications security, censorship circumvention, and activist organization. Moreover, the core of the Android platform is Open Source, auditable, and modifiable by anyone.

Unfortunately though, mobile devices in general and Android devices in particular have not been designed with privacy in mind. In fact, they've seemingly been designed with nearly the opposite goal: to make it easy for third parties, telecommunications companies, sophisticated state-sized adversaries, and even random hackers to extract all manner of personal information from the user. This includes the full content of personal communications with business partners and loved ones. Worse still, by default, the user is given very little in the way of control or even informed consent about what information is being collected and how.

This post aims to address this, but we must first admit we stand on the shoulders of giants. Organizations like Cyanogen, F-Droid, the Guardian Project, and many others have done a great deal of work to try to improve this situation by restoring control of Android devices to the user, and to ensure the integrity of our personal communications. However, all of these projects have shortcomings and often leave gaps in what they provide and protect. Even in cases where proper security and privacy features exist, they typically require extensive configuration to use safely, securely, and correctly.

This blog post enumerates and documents these gaps, describes workarounds for serious shortcomings, and provides suggestions for future work.

It is also meant to serve as a HOWTO to walk interested, technically capable people through the end-to-end installation and configuration of a prototype of a secure and private Android device, where access to the network is restricted to an approved list of applications, and all traffic is routed through the Tor network.

It is our hope that this work can be replicated and eventually fully automated, given a good UI, and rolled into a single ROM or ROM addon package for ease of use. Ultimately, there is no reason why this system could not become a full fledged off the shelf product, given proper hardware support and good UI for the more technical bits.

The remainder of this document is divided into the following sections:

  1. Hardware Selection
  2. Installation and Setup
  3. Google Apps Setup
  4. Recommended Software
  5. Device Backup Procedure
  6. Removing the Built-in Microphone
  7. Removing Baseband Remnants
  8. Future Work
  9. Changes Since Initial Posting


Hardware Selection

If you truly wish to secure your mobile device from remote compromise, it is necessary to carefully select your hardware. First and foremost, it is absolutely essential that the carrier's baseband firmware is completely isolated from the rest of the platform. Because your cell phone baseband does not authenticate the network (in part to allow roaming), any random hacker with their own cell network can exploit these backdoors and use them to install malware on your device.

While there are projects underway to determine which handsets actually provide true hardware baseband isolation, at the time of this writing there is very little public information available on this topic. Hence, the only safe option remains a device with no cell network support at all (though cell network connectivity can still be provided by a separate device). For the purposes of this post, the reference device is the WiFi-only version of the 2013 Google Nexus 7 tablet.

For users who wish to retain full mobile access, we recommend obtaining a cell modem device that provides a WiFi access point for data services only. These devices do not have microphones and in some cases do not even have fine-grained GPS units (because they are not able to make emergency calls). They are also available with prepaid plans, for rates around $20-30 USD per month, for about 2GB/month of 4G data. If coverage and reliability is important to you though, you may want to go with a slightly more expensive carrier. In the US, T-Mobile isn't bad, but Verizon is superb.

To increase battery life of your cell connection, you can connect this access point to an external mobile USB battery pack, which typically will provide 36-48 hours of continuous use with a 6000mAh battery.

The total cost of a Wifi-only tablet with cell modem and battery pack is only roughly USD $50 more than the 4G LTE version of the same device.

In this way, you achieve true baseband isolation, with no risk of audio or network surveillance, baseband exploits, or provider backdoors. Effectively, this cell modem is just another untrusted router in a long, long chain of untrustworthy Internet infrastructure.

However, do note though that even if the cell unit does not contain a fine-grained GPS, you still sacrifice location privacy while using it. Over an extended period of time, it will be possible to make inferences about your physical activity, behavior and personal preferences, and your identity, based on cell tower use alone.


Installation and Setup

We will focus on the installation of Cyanogenmod 11 using Team Win Recovery Project, both to give this HOWTO some shelf life, and because Cyanogenmod 11 features full SELinux support (Dear NSA: What happened to you guys? You used to be cool. Well, some of you. Some of the time. Maybe. Or maybe not).

The use of Google Apps and Google Play services is not recommended due to security issues with Google Play. However, we do provide workarounds for mitigating those issues, if Google Play is required for your use case.

Installation and Setup: ROM and Core App Installation

With the 2013 Google Nexus 7 tablet, installation is fairly straight-forward. In fact, it is actually possible to install and use the device before associating it with a Google Account in any way. This is a desirable property, because by default, the otherwise mandatory initial setup process of the stock Google ROM sends your device MAC address directly to Google and links it to your Google account (all without using Tor, of course).

The official Cyanogenmod installation instructions are available online, but with a fresh out of the box device, here are the key steps for installation without activating the default ROM code at all (using Team Win Recovery Project instead of ClockWorkMod).

First, on your desktop/laptop computer (preferably Linux), perform the following:

  1. Download the latest CyanogenMod 11 release (we used cm-11-20140504-SNAPSHOT-M6)
  2. Download the latest Team Win Recovery Project image (we used 2.7.0.0)
  3. Download the F-Droid package (we used 0.66)
  4. Download the Orbot package from F-Droid (we used 13.0.7)
  5. Download the Droidwall package from F-Droid (we used 1.5.7)
  6. Download the Droidwall Firewall Scripts attached to this blogpost
  7. Download the Google Apps for Cyanogenmod 11 (optional)

Because the download integrity for all of these packages is abysmal, here is a signed set of SHA256 hashes I've observed for those packages.

Once you have all of those packages, boot your tablet into fastboot mode by holding the Power button and the Volume Down button during a cold boot. Then, attach it to your desktop/laptop machine with a USB cable and run the following commands from a Linux/UNIX shell:

apt-get install android-tools-adb android-tools-fastboot
fastboot devices
fastboot oem unlock
fastboot flash recovery openrecovery-twrp-2.7.0.0-flo.img

After the recovery firmware is flashed successfully, use the volume keys to select Recovery and hit the power button to reboot the device (or power it off, and then boot holding Power and Volume Up).

Once Team Win boots, go into Wipe and select Advanced Wipe. Select all checkboxes except for USB-OTG, and slide to wipe. Once the wipe is done, click Format Data. After the format completes, issue these commands from your Linux shell:

adb server start
adb push cm-11-20140504-SNAPSHOT-M6-flo.zip /sdcard/
adb push gapps-kk-20140105-signed.zip /sdcard/ # Optional

After this push process completes, go to the Install menu, and select the Cyanogen zip, and optionally the gapps zip for installation. Then click Reboot, and select System.

After rebooting into your new installation, skip all CyanogenMod and Google setup, disable location reporting, and immediately disable WiFi and turn on Airplane mode.

Then, go into Settings -> About Tablet and scroll to the bottom and click the greyed out Build number 5 times until developer mode is enabled. Then go into Settings -> Developer Options and turn on USB Debugging.

After that, run the following commands from your Linux shell:

adb install FDroid.apk
adb install org.torproject.android_86.apk
adb install com.googlecode.droidwall_157.apk

You will need to approve the ADB connection for the first package, and then they should install normally.

VERY IMPORTANT: Whenever you finish using adb, always remember to disable USB Debugging and restore Root Access to Apps only. While Android 4.2+ ROMs now prompt you to authorize an RSA key fingerprint before allowing a debugging connection (thus mitigating adb exploit tools that bypass screen lock and can install root apps), you still risk additional vulnerability surface by leaving debugging enabled.

Installation and Setup: Initial Configuration

After the base packages are installed, go into the Settings app, and make the following changes:

  1. Wireless & Networks More... =>
  • Temporarily Disable Airplane Mode
  • NFC -> Disable
  • Re-enable Airplane Mode

  • Location Access -> Off
  • Security =>
    • PIN screen Lock
    • Allow Unknown Sources (For F-Droid)

  • Language & Input =>
    • Spell Checker -> Android Spell Checker -> Disable Contact Names
    • Disable Google Voice Typing/Hotword detection
    • Android Keyboard (AOSP) =>
      • Disable AOSP next-word suggestion (do this first!)
      • Auto-correction -> Off

  • Backup & reset =>
    • Enable Back up my data (just temporarily, for the next step)
    • Uncheck Automatic restore
    • Disable Backup my data

  • About Tablet -> Cyanogenmod Statistics -> Disable reporting
  • Developer Options -> Device Hostname -> localhost
  • SuperUser -> Settings (three dots) -> Notifications -> Notification (not toast)
  • Privacy -> Privacy Guard =>

    • Enabled by default
    • Settings (three dots) -> Show Built In Apps
    • Enable Privacy Guard for every app with the following exceptions:
      • Calendar
      • Config Updater
      • Google Account Manager (long press)
        • Modify Settings -> Off
        • Wifi Change -> Off
        • Data Change -> Off
      • Google Play Services (long press)
        • Location -> Off
        • Modify Settings -> Off
        • Draw on top -> Off
        • Record Audio -> Off
        • Wifi Change -> Off
      • Google Play Store (long press)
        • Location -> Off
        • Send SMS -> Off
        • Modify Settings -> Off
        • Data change -> Off
      • Google Services Framework (long press)
        • Modify Settings -> Off
        • Wifi Change -> Off
        • Data Change -> Off
      • Trebuchet

    Now, it is time to encrypt your tablet. It is important to do this step early, as I have noticed additional apps and configuration tweaks can make this process fail later on.

    We will also do this from the shell, in order to set a different password than your screen unlock pin. This is done to mitigate the risk of compromise of this password from shoulder surfers, and to allow the use of a much longer (and non-numeric) password that you would prefer not to type every time you unlock the screen.

    To do this, open the Terminal app, and type the following commands:

    su
    vdc cryptfs enablecrypto inplace NewMoreSecurePassword

    Watch for typos! That command does not ask you to re-type that password for confirmation.

    Installation and Setup: Disabling Invasive Apps and Services

    Before you configure the Firewall or enable the network, you likely want to disable at least a subset of the following built-in apps and services, by using Settings -> Apps -> All, and then clicking on each app and hitting the Disable button:

    • com.android.smspush
    • com.google.android.voicesearch
    • Face Unlock
    • Google Backup Transport
    • Google Calendar Sync
    • Google One Time Init
    • Google Partner Setup
    • Google Contacts Sync
    • Google Search
    • Hangouts
    • Market Feedback Agent
    • News & Weather
    • One Time Init
    • Picasa Updater
    • Sound Search for Google Play
    • TalkBack


    Installation and Setup: Tor and Firewall configuration

    Ok, now let's install the firewall and tor support scripts. Go back into Settings -> Developer Options and enable USB Debugging and change Root Access to Apps and ADB. Then, unzip the android-firewall.zip on your laptop, and run the installation script:

    ./install-firewall.sh

    That firewall installation provides several key scripts that provide functionality that is currently impossible to achieve with any app (including Orbot):

    1. It installs a userinit script to block all network access during boot.
    2. It disables "Google Captive Portal Detection", which involves connection attempts to Google servers upon Wifi assocation (these requests are made by the Android Settings UID, which should normally be blocked from the network, unless you are first registering for Google Play).
    3. It contains a Droidwall script that configures Tor transproxy rules to send all of your traffic through Tor. These rules include a fix for a Linux kernel Tor transproxy packet leak issue.
    4. The main firewall-torify-all.sh Droidwall script also includes an input firewall, to block all inbound connections to the device. It also fixes a Droidwall permissions vulnerability
    5. It installs an optional script to allow the Browser app to bypass Tor for logging into WiFi captive portals.
    6. It installs an optional script to temporarily allow network adb access when you need it (if you are paranoid about USB exploits, which you should be).
    7. It provides an optional script to allow the UDP activity of LinPhone to bypass Tor, to allow ZRTP-encrypted Voice and Video SIP/VoIP calls. SIP account login/registration and call setup/signaling can be done over TCP, and Linphone's TCP activity is still sent through Tor with this script.

    Note that with the exception of the userinit network blocking script, installing these scripts does not activate them. You still need to configure Droidwall to use them.

    We use Droidwall instead of Orbot or AFWall+ for five reasons:

    1. Droidwall's app-based firewall and Orbot's transproxy are known to conflict and reset one another.
    2. Droidwall does not randomly drop transproxy rules when switching networks (Orbot has had several of these types of bugs).
    3. Unlike AFWall+, Droidwall is able to auto-launch at "boot" (though still not before the network and Android Services come online and make connections).
    4. AFWall+'s "fix" for this startup data leak problem does not work on Cyanogenmod (hence our userinit script instead).
    5. Aside from the permissions issue fixed by our firewall-torify-all.sh script, AFWall+ provides no additional security fixes over the stock Droidwall.

    To make use of the firewall scripts, open up Droidwall and hit the config button (the vertical three dots), go to More -> Set Custom Script. Enter the following:

    . /data/local/firewall-torify-all.sh
    #. /data/local/firewall-allow-adb.sh
    #. /data/local/firewall-allow-linphone-udp.sh
    #. /data/local/firewall-allow-nontor-browser.sh

    NOTE: You must not make any typos in the above. If you mistype any of those files, things may break. Because the userinit.sh script blocks all network at boot, if you make a typo in the torify script, you will be unable to use the Internet at all!

    Also notice that these scripts have been installed into a readonly root directory. Because they are run as root, installing them to a world-writable location like /sdcard/ is extremely unwise.

    Later, if you want to enable one of network adb, LinPhone UDP, or captive portal login, go back into this window and remove the leading comment ('#') from the appropriate lines (this is obviously one of the many aspects of this prototype that could benefit from real UI).

    Then, configure the apps you want to allow to access the network. Note that the only Android system apps that must access the network are:

    • CM Updater
    • Downloads, Media Storage, Download Manager
    • F-Droid

    Orbot's network access is handled via the main firewall-torify-all.sh script. You do not need to enable full network access to Orbot in Droidwall.

    The rest of the apps you can enable at your discretion. They will all be routed through Tor automatically.

    Once Droidwall is configured, you can click on the Menu (three dots) and click the "Firewall Disabled" button to enable the firewall. Then, you can enable Orbot. Do not grant Orbot superuser access. It still opens the transproxy ports you need without root, and Droidwall is managing installation of the transproxy rules, not Orbot.

    You are now ready to enable Wifi and network access on your device. For vulnerability surface reduction, you may want to use the Advanced Options -> Static IP to manually enter an IP address for your device to avoid using dhclient. You do not need a DNS server, and can safely set it to 127.0.0.1.


    Google Apps Setup

    If you installed the Google Apps zip, you need to do a few things now to set it up, and to further harden your device. If you opted out of Google Apps, you can skip to the next section.

    Google Apps Setup: Initializing Google Play

    The first time you use Google Play, you will need to enable four apps in Droidwall: "Google Account Manager, Google Play Services...", "Settings, Dev Tools, Fused Location...", "Gmail", and "Google Play" itself.

    If you do not have a Google account, your best bet is to find open wifi to create one, as Google will often block accounts created through Tor, even if you use an Android device.

    After you log in for the first time, you should be able to disable the "Google Account Manager, Google Play Services...", "Gmail", and the "Settings..." apps in Droidwall, but your authentication tokens in Google Play may expire periodically. If this happens, you should only need to temporarily enable the "Google Account Manager, Google Play Services..." app in Droidwall to obtain new ones.

    Google Apps Setup: Mitigating the Google Play Backdoors

    If you do choose to use Google Play, you need to be very careful about how you allow it to access the network. In addition to the risks associated with using a proprietary App Store that can send you targeted malware-infected packages based on your Google Account, it has at least two major user experience flaws:

    1. Anyone who is able to gain access to your Google account can silently install root or full permission apps without any user interaction what-so-ever. Once installed, these apps can retroactively clear what little installation notification and UI-based evidence of their existence there was in the first place.
    2. The Android Update Process does not inform the user of changes in permissions of pending update apps that happen to get installed after an Android upgrade.

    The first issue can be mitigated by ensuring that Google Play does not have access to the network when not in use, by disabling it in Droidwall. If you do not do this, apps can be installed silently behind your back. Welcome to the Google Experience.

    For the second issue, you can install the SecCheck utility, to monitor your apps for changes in permissions during a device upgrade.

    Google Apps Setup: Disabling Google Cloud Messaging

    If you have installed the Google Apps zip, you have also enabled a feature called Google Cloud Messaging.

    The Google Cloud Messaging Service allows apps to register for asynchronous remote push notifications from Google, as well as send outbound messages through Google.

    Notification registration and outbound messages are sent via the app's own UID, so using Droidwall to disable network access by an app is enough to prevent outbound data, and notification registration. However, if you ever allow network access to an app, and it does successfully register for notifications, these notifications can be delivered even when the app is once again blocked from accessing the network by Droidwall.

    These inbound notifications can be blocked by disabling network access to the "Google Account Manager, Google Play Services, Google Services Framework, Google Contacts Sync" in Droidwall. In fact, the only reason you should ever need to enable network access by this service is if you need to log in to Google Play again if your authentication tokens ever expire.

    If you would like to test your ability to control Google Cloud Messaging, there are two apps in the Google Play store than can help with this. GCM Test allows for simple send and receive pings through GCM. Push Notification Tester will allow you to test registration and asynchronous GCM notification.


    Recommended Privacy and Auditing Software

    Ok, so now that we have locked down our Android device, now for the fun bit: secure communications!

    We recommend the following apps from F-Droid:

    1. Xabber
    2. Xabber is a full Java implementation of XMPP, and supports both OTR and Tor. Its UI is a bit more streamlined than Guardian Project's ChatSecure, and it does not make use of any native code components (which are more vulnerable to code execution exploits than pure Java code). Unfortunately, this means it lacks some of ChatSecure's nicer features, such as push-to-talk voice and file transfer.

      Despite better protection against code execution, it does have several insecure default settings. In particular, you want to make the following changes:

    • Notifications -> Message text in Notifications -> Off (notifications can be read by other apps!)
    • Accounts -> Integration into system accounts -> Off
    • Accounts -> Store message history -> Don't Store
    • Security -> Store History -> Off
    • Security -> Check Server Certificate
    • Chat -> Show Typing Notifications -> Off
    • Connection Settings -> Auto-away -> disabled
    • Connection Settings -> Extended away when idle -> Disabled
    • Keep Wifi Awake -> On
    • Prevent sleep Mode -> On

  • Offline Calendar
  • Offline Calendar is a hack to allow you to create a fake local Google account that does not sync to Google. This allows you to use the Calendar App without risk of leaking your activities to Google. Note that you must exempt both this app and Calendar from Privacy Guard for it to function properly.

  • LinPhone
  • LinPhone is a FOSS SIP client that supports TCP TLS signaling and ZRTP. Note that neither TLS nor ZRTP are enabled by default. You must manually enable them in Settings -> Network -> Transport and Settings -> Network -> Media Encryption.

    ostel.co is a free SIP service run by the Guardian Project that supports only TLS and ZRTP, but does not allow outdialing to normal PSTN telephone numbers. While Bitcoin has many privacy issues of its own, the Bitcoin community maintains a couple lists of "trunking" providers that allow you to obtain a PSTN phone number in exchange for Bitcoin payment.

  • Plumble

    Plumble is a Mumble client that will route voice traffic over Tor, which is useful if you would like to communicate with someone over voice without revealing your IP to them, or your activity to a local network observer. However, unlike Linphone, voice traffic is not end-to-end encrypted, so the Mumble server can listen to your conversations.

  • K-9 Mail and APG
    K-9 Mail is a POP/IMAP client that supports TLS and integrates well with APG, which will allow you to send and receive GPG-encrypted mail easily. Before using it, you should be aware of two things: It identifies itself in your mail headers, which opens you up to targeted attacks specifically tailored for K-9 Mail and/or Android, and by default it includes the subject of messages in mail notifications (which is bad, because other apps can read notifications). There is a privacy option to disable subject text in notifications, but there is no option to disable the user agent in the mail headers.
  • OSMAnd~
  • A free offline mapping tool. While the UI is a little clunky, it does support voice navigation and driving directions, and is a handy, private alternative to Google Maps.

  • VLC

    The VLC port in F-Droid is a fully capable media player. It can play mp3s and most video formats in use today. It is a handy, private alternative to Google Music and other closed-source players that often report your activity to third party advertisers. VLC does not need network access to function.

  • Firefox
  • We do not yet have a port of Tor Browser for Android (though one is underway -- see the Future Work section). Unless you want to use Google Play to get Chrome, Firefox is your best bet for a web browser that receives regular updates (the built in Browser app does not). HTTPS-Everywhere and NoScript are available, at least.

  • Bitcoin
  • Bitcoin might not be the most private currency in the world. In fact, you might even say it's the least private currency in the world. But, it is a neat toy.

  • Launch App Ops

    The Launch App Ops app is a simple shortcut into the hidden application permissions editor in Android. A similar interface is available through Settings -> Privacy -> Privacy Guard, but a direct shortcut to edit permissions is handy. It also displays some additional system apps that Privacy Guard omits.

  • Permissions
    The Permissions app gives you a view of all Android permissions, and shows you which apps have requested a given permission. This is particularly useful to disable the record audio permission for apps that you don't want to suddenly decide to listen to you. (Interestingly, the Record Audio permission disable feature was broken in all Android ROMs I tested, aside from Cyanogenmod 11. You can test this yourself by revoking the permission from the Sound Recorder app, and verifying that it cannot record.)
  • CatLog
  • In addition to being supercute, CatLog is an excellent Android monitoring and debugging tool. It allows you to monitor and record the full set of Android log events, which can be helpful in diagnosing issues with apps.

  • OS Monitor
  • OS Monitor is an excellent Android process and connection monitoring app, that can help you watch for CPU usage and connection attempts by your apps.

  • Intent Intercept
  • Intent Intercept allows you to inspect and extract Android Intent content without allowing it to get forwarded to an actual app. This is useful for monitoring how apps attempt to communicate with eachother, though be aware it only covers one of the mechanisms of inter-app communication in Android.


    Backing up Your Device Without Google

    Now that your device is fully configured and installed, you probably want to know how to back it up without sending all of your private information directly to Google. While the Team Win Recovery Project will back up all of your system settings and apps (even if your device is encrypted), it currently does not back up the contents of your virtualized /sdcard. Remembering to do a couple adb pulls of key directories can save you a lot of heartache should you suffer some kind of data loss or hardware failure (or simply drop your tablet on a bridge while in a rush to catch a train).

    The backup.sh script uses adb to pull your Download and Pictures directories from the /sdcard, as well as pulls the entire TWRP backup directory.

    Before you use that script, you probably want to delete old TWRP backup folders so as to only pull one backup, to reduce pull time. These live in /sdcard/TWRP/BACKUPS/, which is also known as /storage/emulated/0/TWRP/BACKUPS in the File Manager app.

    To use this script over the network without a usb cable, enable both USB Debugging and ADB Over Network in your developer settings. The script does not require you to enable root access from adb, and you should not enable root because it takes quite a while to run a backup, especially if you are using network adb.

    Prior to using network adb, you must edit your Droidwall custom scripts to allow it (by removing the '#' in the #. /data/local/firewall-allow-adb.sh line you entered earlier), and then run the following commands from a non-root Linux shell on your desktop/laptop (the ADB Over Network setting will tell you the IP and port):

    killall adb
    adb connect ip:5555

    VERY IMPORTANT: Don't forget to disable USB Debugging, as well as the Droidwall adb exemption when you are done with the backup!


    Removing the Built-in Microphone

    If you would really like to ensure that your device cannot listen to you even if it is exploited, it turns out it is very straight-forward to remove the built-in microphone in the Nexus 7. There is only one mic on the 2013 model, and it is located just below the volume buttons (the tiny hole).

    To remove it, all you need to do is pop off the the back panel (this can be done with your fingernails, or a tiny screwdriver), and then you can shave the microphone right off that circuit board, and reattach the panel. I have done this to one of my devices, and it was subsequently unable to record audio at all, without otherwise affecting functionality.

    You can still use apps that require a microphone by plugging in headphone headset that contains a mic built in (these cost around $20 and you can get them from nearly any consumer electronics store). I have also tested this, and was still able to make a Linphone call from a device with the built in microphone removed, but with an external headset. Note that the 2012 Nexus 7 does not support these combination microphone+headphone jacks (and it has a secondary microphone as well). You must have the 2013 model.

    The 2013 Nexus 7 Teardown video can give you an idea of what this looks like before you try it. Again you do not need to fully disassemble the device - you only need to remove the back cover.

    Pro-Tip: Before you go too crazy and start ripping out the cameras too, remember that you can cover the cameras with a sticker or tape when not in use. I have found that regular old black electrical tape applies seamlessly, is non-obvious to casual onlookers, and is easy to remove without smudging or gunking up the lenses. Better still, it can be removed and reapplied many times without losing its adhesive.


    Removing the Remnants of the Baseband

    There is one more semi-hardware mod you may want to make, though.

    It turns out that the 2013 Wifi Nexus 7 does actually have a partition that contains a cell network baseband firmware on it, located on the filesystem as the block device /dev/block/platform/msm_sdcc.1/by-name/radio. If you run strings on that block device from the shell, you can see that all manner of CDMA and GSM log messages, comments, and symbols are present in that partition.

    According to ADB logs, Cyanogenmod 11 actually does try to bring up a cell network radio at boot on my Wifi-only Nexus 7, but fails due to it being disabled. There is also a strong economic incentive for Asus and Google to make it extremely difficult to activate the baseband even if the hardware is otherwise identical for manufacturing reasons, since they sell the WiFi-only version for $100 less. If it were easy to re-enable the baseband, HOWTOs would exist (which they do not seem to, at least not yet), and they would cut into their LTE device sales.

    Even so, since we lack public schematics for the Nexus 7 to verify that cell components are actually missing or hardware-disabled, it may be wise to wipe this radio firmware as well, as defense in depth.

    To do this, open the Terminal app, and run:

    su
    cd /dev/block/platform/msm_sdcc.1/by-name
    dd if=/dev/zero of=./radio

    I have wiped that partition while the device was running without any issue, or any additional errors from ADB logs.

    Note that an anonymous commenter also suggested it is possible to disable the baseband of a cell-enabled device using a series of Android service disable commands, and by wiping that radio block device. I have not tested this on a device other than the WiFI-only Nexus 7, though, so proceed with caution. If you try those steps on a cell-enabled device, you should archive a copy of your radio firmware first by doing something like the following from that dev directory that contains the radio firmware block device.

    dd if=./radio of=/sdcard/radio.img

    If anything goes wrong, you can restore that image with:

    dd if=/sdcard/radio.img of=./radio


    Future Work

    In addition to streamlining the contents of this post into a single additional Cyanogenmod installation zip or alternative ROM, the following problems remain unsolved.

    Future Work: Better Usability

    While arguably very secure, this system is obviously nowhere near usable. Here are some potential improvements to the user interface, based on a brainstorming session I had with another interested developer.

    First of all, the AFWall+/Droidwall UI should be changed to be a tri-state: It should allow you to send app traffic over Tor, over your normal internet connection, or block it entirely.

    Next, during app installation from either F-Droid or Google Play (this is an Intent another addon app can actually listen for), the user should be given the chance to decide if they would like that app's traffic to be routed over Tor, use the normal Internet connection, or be blocked entirely from accessing the network. Currently, the Droidwall default for new apps is "no network", which is a great default, but it would be nice to ask users what they would like to do during actual app installation.

    Moreover, users should also be given a chance to edit the app's permissions upon installation as well, should they desire to do so.

    The Google Play situation could also be vastly improved, should Google itself still prove unwilling to improve the situation. Google Play could be wrapped in a launcher app that automatically grants it network access prior to launch, and then disables it upon leaving the window.

    A similar UI could be added to LinPhone. Because the actual voice and video transport for LinPhone does not use Tor, it is possible for an adversary to learn your SIP ID or phone number, and then call you just for the purposes of learning your IP. Because we handle call setup over Tor, we can prevent LinPhone from performing any UDP activity, or divulging your IP to the calling party prior to user approval of the call. Ideally, we would also want to inform the user of the fact that incoming calls can be used to obtain information about them, at least prior to accepting their first call from an unknown party.

    Future Work: Find Hardware with Actual Isolated Basebands

    Related to usability, it would be nice if we could have a serious community effort to audit the baseband isolation properties of existing cell phones, so we all don't have to carry around these ridiculous battery packs and sketch-ass wifi bridges. There is no engineering reason why this prototype could not be just as secure if it were a single piece of hardware. We just need to find the right hardware.

    A random commenter claimed that the Galaxy Nexus might actually have exactly the type of baseband isolation we want, but the comment was from memory, and based on software reverse engineering efforts that were not publicly documented. We need to do better than this.

    Future Work: Bug Bounty Program

    If there is sufficient interest in this prototype, and/or if it gets transformed into a usable addon package or ROM, we may consider running a bug bounty program where we accept donations to a dedicated Bitcoin address, and award the contents of that wallet to anyone who discovers a Tor proxy bypass issue or remote code execution vulnerability in any of the network-enabled apps mentioned in this post (except for the Browser app, which does not receive security updates).

    Future Work: Port Tor Browser to Android

    The Guardian Project is undertaking a port of Tor Browser to Android as part of their OrFox project. This will greatly improve the privacy of your web browsing experience on the Android device over both Firefox and Chrome. We look forward to helping them in any way we can with this effort.

    Future Work: WiFi MAC Address Randomization

    It is actually possible to randomize the WiFi MAC address on the Google Nexus 7. The closed-source root app Mac Spoofer is able to modify the device MAC address using Qualcomm-specific methods in such a way that the entire Android OS becomes convinced that this is your actual MAC.

    However, doing this requires installation of a root-enabled, closed-source application from the Google Play Store, which we believe is extremely unwise on a device you need to be able to trust. Moreover, this app cannot be autorun on boot, and your MAC address will also reset every time you disable the WiFi interface (which is easy to do accidentally). It also supports using only a single, manually entered MAC address.

    Hardware-independent techniques (such as a the Terminal command busybox ifconfig wlan0 hw ether <mac>) appear to interfere with the WiFi management system and prevent it from associating. Moreover, they do not cause the Android system to report the new MAC address, either (visible under Settings -> About Tablet -> Status).

    Obviously, an Open Source F-Droid app that properly resets (and automatically randomizes) the MAC every time the WiFi interface is brought up is badly needed.

    Future Work: Disable Probes for Configured Wifi Networks

    The Android OS currently probes for all of your configured WiFi networks while looking for open wifi to connect to. Configured networks should not be probed for explictly unless activity for their BSSID is seen. The xda-developers forum has a limited fix to change scanning behavior, but users report that it does not disable the active probing behavior for any "hidden" networks that you have configured.

    Future Work: Recovery ROM Password Protection

    An unlocked recovery ROM is a huge vulnerability surface for Android. While disk encryption protects your applications and data, it does not protect many key system binaries and boot programs. With physical access, it is possible to modify these binaries through your recovery ROM.

    The ability to set a password for the Team Win recovery ROM in such a way that a simple "fastboot flash recovery" would overwrite would go a long way to improving device security. At least it would become evident to you if your recovery ROM has been replaced, in this case (due to the absence of the password).

    It may also be possible to restore your bootloader lock as an alternative, but then you lose the ability to make backups of your system using Team Win.

    Future Work: Disk Encryption via TPM or Clever Hacks

    Unfortunately, even disk encryption and a secure recovery firmware is not enough to fully defend against an adversary with an extended period of physical access to your device.

    Cold Boot Attacks are still very much a reality against any form of disk encryption, and the best way to eliminate them is through hardware-assisted secure key storage, such as through a TPM chip on the device itself.

    It may also be possible to mitigate these attacks by placing key material in SRAM memory locations that will be overwritten as part of the ARM boot process. If these physical memory locations are stable (and for ARM systems that use the SoC SRAM to boot, they will be), rebooting the device to extract key material will always end up overwriting it. Similar ARM CPU-based encryption defenses have also been explored in the research literature.

    Future Work: Download and Build Process Integrity

    Beyond the download integrity issues mentioned above, better build security is also deeply needed by all of these projects. A Gitian descriptor that is capable of building Cyanogenmod and arbitrary F-Droid packages in a reproducible fashion is one way to go about achieving this property.

    Future Work: Removing Binary Blobs

    If you read the Cyanogenmod build instructions closely, you can see that it requires extracting the binary blobs from some random phone, and shipping them out. This is the case with most ROMs. In fact, only the Replicant Project seems concerned with this practice, but regrettably they do not support any wifi-only devices. This is rather unfortunate, because no matter what they do with the Android OS on existing cell-enabled devices, they will always be stuck with a closed source, backdoored baseband that has direct access to the microphone, if not the RAM and the entire Android OS.

    Kudos to them for finding one of the backdoors though, at least.


    Changes Since Initial Posting

    1. Updated firewall scripts to fix Droidwall permissions vulnerability.
    2. Updated Applications List to recommend VLC as a free media player.
    3. Mention the Guardian Project's planned Tor Browser port (called OrFox) as Future Work.
    4. Mention disabling configured WiFi network auto-probing as Future Work
    5. Updated the firewall install script (and the android-firewall.zip that contains it) to disable "Captive Portal detection" connections to Google upon WiFi association. These connections are made by the Settings service user, which should normally be blocked unless you are Activating Google Play for the first time.
    6. Updated the Executive Summary section to make it clear that our SIP client can actually also make normal phone calls, too.
    7. Document removing the built-in microphone, for the truly paranoid folk out there.
    8. Document removing the remnants of the baseband, or disabling an existing baseband.
    9. Update SHA256SUM of FDroid.apk for 0.63
    10. Remove multiport usage from firewall-torify-all.sh script (and update android-firewall.zip).
    11. Add pro-tip to the microphone removal section: Don't remove your cameras. Black electrical tape works just fine, and can be removed and reapplied many times without smudges.
    12. Update android-firewall.zip installation and documentation to use /data/local instead of /etc. CM updates will wipe /etc, of course. Woops. If this happened to you while updating to CM-11-M5, download that new android-firewall.zip and run install-firewall.sh again as per the instructions above, and update your Droidwall custom script locations to use /data/local.
    13. Update the Future work section to describe some specific UI improvements.
    14. Update the Future work section to mention that we need to find hardware with actual isolated basebands. Duh. This should have been in there much earlier.
    15. Update the versions for everything
    16. Suggest enabling disk crypto directly from the shell, to avoid SSD leaks of the originally PIN-encrypted device key material.
    17. GMail network access seems to be required for App Store initialization now. Mention this in Google Apps section.
    18. Mention K-9 Mail, APG, and Plumble in the Recommended Apps section.
    19. Update the Firewall instructions to clarify that you need to ensure there are no typos in the scripts, and actually click the Droidwall UI button to enable the Droidwall firewall (otherwise networking will not work at all due to userinit.sh).
    20. Disable NFC in Settings config

    Comments

    Please note that the comment area below has been archived.

    April 02, 2014

    Permalink

    Thank you, I have been looking for something like this for a long time now.

    April 02, 2014

    Permalink

    what are the advantages and disadvanatges (secyrity-wise) of adding a secure socket layer on an onion website? I run an hidden service using non-https connections, what are the advantages and disadvangates of switching to https, like DuckDuckGo's https://3g2upl4pq6kufc4m.onion?

    April 04, 2014

    In reply to arma

    Permalink

    I did and for some reason it decided it's a duplicate, and hid it, even though it's not. So that's why I asked it here.
    So please can you answer me here?

    The connections to onion sites are secured using RSA 1024, which isn't really satisfying. You can utilize stronger encryption and authenticity by adding an additional TLS layer. By aware that TLS leaks some additional information, like your system time.

    April 03, 2014

    Permalink

    Thanks for the excellent article. Two points are bit unclear for me:

    1. Why using static IP is more secure? Naturally this doesn't work if the base station is configured to issue dynamic IPs.

    2. Since Google doesn't allow Google accounts created through Tor, how exactly we should create them? Is it better to use the actual device (in this case tablet with Tor disabled) or use a third party device?

    As explained in the post, a static IP reduces the vulnerability surface by not running dhclient. This is most useful for your cell modem, where you know what your IP range will always be, and you'd rather not risk it handing you maliciously crafted DHCP responses.

    For the Google Account issue, see https://blog.torproject.org/blog/mission-impossible-hardening-android-s….

    I am able to use Google Accounts created via WiFi and then used over Tor for the Google Play Store in testing. You likely want to minimize or eliminate your use of Google Play, though.

    April 03, 2014

    Permalink

    Great post, but i have some questions/problems:

    1) For privacy is better don't install F-Droid package (that connect to internet everytime), but browse and download applications directly from https://f-droid.org/repository/browse/ (you connect to internet only when you want)

    2) Droidwall development stops and this is a problem (no update)

    3) A guide for more devices (also cell phones)

    1. To my knowledge F-Droid does not send any unique identifiers, and it is routed over Tor. Using F-Droid is actually more secure than downloading apks, because F-Droid does ensure that apk upgrades use the same official F-Droid key as before (where as adb install does exactly what you tell it: installs a new package). If you download packages yourself, you are also only protected by HTTPS and the CA cartels, which is weaker than a dedicated apk signing key managed by F-Droid.

    2. As mentioned in the post, the newer Droidwall (AFWall+) actually removes several important features from Droidwall. AFWall+ does have a fix for a permissions issue in Droidwall, but that is the only security fix so far. I will update the "install-firewall.sh" script to fix this issue manually shortly:
    https://code.google.com/p/droidwall/issues/detail?id=260
    https://github.com/ukanth/afwall/blob/master/Changelog.md#changelog-afw…

    3. This is a reference prototype, designed to be used to aid in development of a more streamlined ROM or ROM addon package with better UI. We won't be writing another one for other devices unless they have obvious security advantages to the Nexus 7 (such as support by Replicant to remove binary blobs). We certainly won't be writing a guide for cell phones.

    April 04, 2014

    In reply to mikeperry

    Permalink

    Rather, the fdroid client first downloads an index which is signed by the repo maintainer. The client compares downloaded APK checksums with this index. When installing the new APK, the Android OS checks the new signature, just as it does when using ADB.

    April 03, 2014

    Permalink

    For the hardware part:
    I know, it's a little bit offtopic as this one is not an android phone and it's not already available. But perhaps the Neo900 (https://neo900.org/) is even more interesting as the broadband module is completely separated from the rest of the phone. Not to forget the open design itself.

    And thanks a lot for the great work you put in this post!

    April 03, 2014

    Permalink

    A.

    Completely wiping the baseband partition is also an option. The only side effect on my Samsung N7100 has been a slightly higher power consumption, because the radio chips are now unable to power themselves off.

    (On Android:)

    1. <br />
    2. su -c "pm disable com.android.cellbroadcastreceiver"<br />
    3. su -c "pm disable com.android.mms"<br />
    4. su -c "pm disable com.android.phone"<br />
    5. su -c "pm disable com.android.providers.telephony"<br />
    6. su -c "pm disable com.android.smspush"<br />
    7. su -c "pm disable com.cyanogenmod.samsungservicemode"<br />

    (Probably best to do this in recovery:)

    1. <br />
    2. busybox dd if=/dev/zero of=/dev/block/platform/dw_mmc/by-name/RADIO bs=1M<br />

    B.

    To stop the DNS resolve of, and HTTP request to, clients3.google.com on every connection to any Wifi Access Point:

    1. <br />
    2. su -c "settings put global captive_portal_server 127.0.0.1"<br />
    3. su -c "settings put global captive_portal_detection_enabled 0"<br />

    C.

    To stop the resolve/request for 2.android.pool.ntp.org on every boot (even with network time disabled!):

    1. <br />
    2. su -c "settings put global ntp_server 127.0.0.1"<br />

    D.

    To scan for Wifi Access Points passively (by listening for traffic instead of sending out probe requests that leak your MAC address), see
    http://forum.xda-developers.com/showthread.php?t=2683858

    A. It would seem this does not apply to the Nexus 7. The only service running on my Nexus 7 from that list is com.android.phone. Do you think it is worth disabling?

    B. Holy shit. This does still happen on the Nexus 7. I will update the howto with these instructions immediately. These are one time settings, correct? I do not need to place them in the bootup script?

    C. This request does not happen on boot for me. Or at least, it does not leak (I have an upstream router monitoring for Tor leaks for testing).

    D. This hack does not prevent the transmission of already configured (but unavailable) APs over WiFi, which I believe is a more serious problem. I will add this to future work.

    April 04, 2014

    In reply to mikeperry

    Permalink

    A. It's only for devices burdened with a a baseband. I wouldn't bother disabling com.android.phone etc. on a Nexus 7.

    B. Yeah, one time installation only.

    C. I wonder what causes that request for me. Did you test on CM11M4 without Gapps as I did?

    D. Well, the device will only generate probe requests containing APs if those had a cloaked SSID, i.e. you had to enter their name manually. You can always opt never to connect to such APs, or remove them when they're not needed anymore.

    April 04, 2014

    In reply to mikeperry

    Permalink

    (I should have noted that I did not use your scripts or any firewall at all when I observed the NTP request on CM11M4)

    April 08, 2014

    In reply to mikeperry

    Permalink

    are there any instructions how an "upstream router monitoring for Tor leaks" setup should look like? thx in advance.

    Ok, I have included your commands from B in the install-firewall.sh script (which is only run once during device setup). The new zip is already uploaded, and you can see the changed install script at:
    https://people.torproject.org/~mikeperry/android-hardening/android-fire…

    However, while verifying before and after applying these changes, I noticed that these Captive Portal pings were being sent by the Settings service (UID 1000), which should be blocked anyway most of the time. But, since the Settings Service needs to access the network for Google Play setup, I included these changes anyway.

    April 04, 2014

    In reply to mikeperry

    Permalink

    I think disabling the captive portal detection is a still a good idea. Only firewalling it away can cause delays or even connection failures in my experience (depending on Android version and phase of the moon).

    Input- adb shell su -c "settings put global captive_portal_server 127.0.0.1"
    Output- settings: not found
    Not working.... :( pm works but not settings

    I managed to do A on my nexus 5 (hammerhead) by patching the factory images with an empty radio partition, fastboot flashing that and then continuing with installing cyanogen mod as described here. I also disabled all com.qualcom.* services. But the energy consumption is staggering, draining the battery in 12 h (mostly idle) with 77% cell network, and screen in place 2 with 6 %.

    April 03, 2014

    Permalink

    If you find or write a wireless MAC modifier/randomizer that is free software, let us know and we'll add it to F-Droid :)

    -mvdan

    This seems dubious. How does the closed source Mac Spoofer app do this, I wonder?

    I also did not need a kernel patch to change the MAC address reported by busybox ifconfig wlan0 after doing busybox ifconfig wlan0 hw ether 11:22:33:44:55:66, but doing this did not update the Android system's view of the MAC, and it also broke the ability to associate to access points (which I suspect is not a kernel issue, but an Android WiFi management system issue).

    April 03, 2014

    In reply to mikeperry

    Permalink

    in kernel, where your get_mac_addr :

    + #ifdef CONFIG_WIFI_MAC
    + if (randomize_wifi_mac != 0) {
    + srandom32((uint)jiffies);
    + random32();
    +
    + rand_mac = random32();
    + wlan_mac[0] = (unsigned char)(rand_mac >> 2 << 2);
    + wlan_mac[1] = (unsigned char)(rand_mac >> 8);
    + wlan_mac[2] = (unsigned char)(rand_mac >> 16);
    +
    + rand_mac = random32();
    + wlan_mac[3] = (unsigned char)rand_mac;
    + wlan_mac[4] = (unsigned char)(rand_mac >> 8);
    + wlan_mac[5] = (unsigned char)(rand_mac >> 16);
    + }
    + #endif

    of course you have to make randomize_wifi_mac available in /sysfs such that you can echo 1 to it :)

    April 03, 2014

    In reply to mikeperry

    Permalink

    let's elaborate it further, hack the kernel is the best and most reliable way to do, why?

    when you turn on Android' wifi buttion, Android OS will issue a get_mac_addr request (only once per switch) to the kernel, if you have hacked the kernel and have the /sysfs randomize_wifi_mac 'echoed 1', the kernel will 'update' the mac addr of the wifi (using the randomizing code I posted) and eveything is then set :)

    Each time your toggle your Android wifi button, a new mac_addr is generated & enjoy 24/7 free wifi in any coffee shop/mall !

    Do some serious hacking in kernel, different rom has similar but different code...

    April 03, 2014

    Permalink

    Thank you again for this very valuable resource.

    Is there anything that explains what risks each of the changes mitigates?

    For brevity I decided to leave this out. The post was already extremely long. If anyone is interested in turning this material into an addon installation package or integrating it into a ROM, I can either provide them with the rationale, or do a second blog post.

    April 03, 2014

    Permalink

    Just a suggestion for the MAC thing: you could try patching android-framework.jar to report whatever MAC, UUID, IMEI, ... you want to the apps. This isn't going to change the actual values in the hardware, but at least your Android apps (hopefully including the system ones) won't be able to read the original values in any way.

    April 03, 2014

    Permalink

    Looking forward to this staying updated its a great service you are providing.

    Please consider making a guide for the crowd sourced neo900. It is 100% open hardware and source even in baseband. http://neo900.org/

    I look forward to the release of this device. Looks interesting at a glance, however according to the FAQ the baseband will not be open source, but it may be isolated, which is a plus: http://neo900.org/faq

    From the FAQ entry, it still have a USB bridge to the OS, which depending on how that's handled, may still be more vulnerability surface (if the host OS can be tricked into treating that USB interface as something other than what it is supposed to be, and loading alternate, potentially vulnerable USB drivers).

    April 03, 2014

    Permalink

    So there is no point in doing this on smartphone at all? Only on non-cellular mobile devices?

    The baseband on cell phones is full of backdoors. We know from court proceedings that the baseband can activate your microphone at any time, and this appears to be a built-in "feature" of most cellphone basebands. We also now have proof of much deeper backdoors that allow malware to be planted directly on your device.

    It turns out that cell phones do not authenticate the network provider, in part to facilitate roaming. This means nothing prevents any random hacker with a cell network reimplementation from impersonating your cell network provider to exploit these backdoors, and fully compromise your device. (Yes, FOSS implementations of cell networks do exist, and can be deployed with hardware that costs around USD $1000).

    Because of this, the Tor Project cannot in good conscience encourage or endorse use of cell-enabled devices in such a way that that would cause people to believe them to be secure. It is up to the individual user to decide if they care about this type of exploitation, and act accordingly.

    April 04, 2014

    In reply to mikeperry

    Permalink

    Ok then another possibly nobish question - Can I buy a tablet with 3g modem built in which has never been acivated, and I never plan to use it (no data plan, no sim card). The question is can RTOS backdoors and exploits still be activated somehow? I suppose it is impossible but asking just in case..

    April 05, 2014

    In reply to mikeperry

    Permalink

    I know that you can intercept cell phones with imsi catcher https://en.wikipedia.org/wiki/IMSI-catcher
    But can you intercept with openbts and your hardware? if yes, how?
    (i think that openbts can not intercept, because the software can not forward call traffic through to a mobile operator)

    If your goal is to deploy malware through a baseband backdoor, you don't need to forward calls. You just need to get a handset to roam onto your rogue cell network long enough to exploit the backdoor, and then kick them off.

    April 03, 2014

    Permalink

    I had to modify the DNS transproxy section of the firewall-tor.sh to get the rules to load on a CM-11 nightly on tilapia. The error was about a duplicate rule in the droidwall chain. Would appreciate a check by someone knowledgeable... I tried to replicate the intent of the original section... but I am no iptables expert. Edited rules follow:

    # Allow root's DNS proxy and kernel to do their transproxy thang
    # FIXME: On newer kernels, this may require 1-9999999 instead of 0 (because
    # the kernel is flagged as UID 0 instead of blank UID)
    $IPTABLES -A droidwall -d 127.0.0.1/32 -p udp -m owner --uid-owner 0-9999999 -m udp --dport 5400 -j RETURN || exit
    $IPTABLES -A droidwall -d 127.0.0.1/32 -p tcp -m owner --uid-owner 0-9999999 -m tcp --dport 9040 -j RETURN || exit
    #$IPTABLES -A droidwall -s 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp -m multiport --ports 9040 -j RETURN || exit
    #$IPTABLES -A droidwall -d 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp -m multiport --ports 9040 -j RETURN || exit
    #$IPTABLES -A droidwall -s 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m udp -m multiport --ports 5400 -j RETURN || exit
    #$IPTABLES -A droidwall -d 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp -m multiport --ports 5400 -j RETURN || exit

    Those were not duplicate rules you deleted. You deleted the source (-s) lines for 127.0.0.1, which are needed because the transproxy sets the destination to a remote IP (or the device IP) in some cases.

    I am not sure why you got errors for this. I tested in the CM-11-M4 snapshot version I posted and there were no issues, and non-whitelisted apps are still in fact blocked from accessing the network in my version.

    Possibly there is a bug in the newer CM-11 nightly you tried? Might be worth trying to narrow down which nightly the issue appeared in and reporting it to them.

    April 04, 2014

    In reply to mikeperry

    Permalink

    Iptables has such unhelpful error messages... Upon further investigation:

    # CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set

    So that's why the multiport match rules fail on my nightly. In lieu of switching to M3 (there's no M4 for tilapia), I ported these rules to the less concise normal port matching syntax. These rules seem to work as expected (only whitelisted apps work and droidwall loads without issue):

    # Allow root's DNS proxy and kernel to do their transproxy thang
    # FIXME: On newer kernels, this may require 1-9999999 instead of 0 (because
    # the kernel is flagged as UID 0 instead of blank UID)
    $IPTABLES -A droidwall -d 127.0.0.1/32 -p udp -m owner --uid-owner 0 -m udp --dport 5400 -j RETURN || exit

    #$IPTABLES -A droidwall -s 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp -m multiport --ports 9040 -j RETURN || exit
    $IPTABLES -A droidwall -s 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp --sport 9040 -j RETURN || exit
    $IPTABLES -A droidwall -s 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp --dport 9040 -j RETURN || exit

    #$IPTABLES -A droidwall -d 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp -m multiport --ports 9040 -j RETURN || exit
    $IPTABLES -A droidwall -d 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp --sport 9040 -j RETURN || exit
    $IPTABLES -A droidwall -d 127.0.0.1 -p tcp -m owner ! --uid-owner 0-9999999 -m tcp --dport 9040 -j RETURN || exit

    #$IPTABLES -A droidwall -s 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp -m multiport --ports 5400 -j RETURN || exit
    $IPTABLES -A droidwall -s 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp --sport 5400 -j RETURN || exit
    $IPTABLES -A droidwall -s 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp --dport 5400 -j RETURN || exit

    #$IPTABLES -A droidwall -d 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp -m multiport --ports 5400 -j RETURN || exit
    $IPTABLES -A droidwall -d 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp --sport 5400 -j RETURN || exit
    $IPTABLES -A droidwall -d 127.0.0.1 -p udp -m owner ! --uid-owner 0-9999999 -m udp --dport 5400 -j RETURN || exit

    Ok, it took me a while, but I tested these and updated android-firewall.zip with them. Thanks!

    I was also debating ignoring this since it is not needed on the Nexus 7, but what the hell. Since it may be possible to remove the baseband from other devices, might as well eliminate any other easily fixable issues for them, too.

    April 03, 2014

    Permalink

    Hrm... I think the Droidwall section need work. Even after modifying the firewall-tor.sh script to load (see previous comment), applications not on the whitelist can still access the internet (via Tor, but still).

    I think you introduced a leak by tweaking those rules. See my previous comment. There may be a bug in the newer CM11 nightly you used? Everything works out of the box, end-to-end on CM-11-M4-SNAPSHOT.

    April 03, 2014

    Permalink

    After reboot the Droidwall scripts interfere with Orbot. It stalls at 'connecting to control port', I had to flush the rules (via ADB, disabling Droidwall doesn't work). I seems as though userinit.sh (the script that disables network before Orbot starts) is disabling Orbot too.

    Needs more work. Please consider updating the Droidwall section to be more specific, maybe I forgot something... but the two lines above don't seem to work

    Did you remember to add the . /data/local/firewall-tor.sh script to the custom scripts in droidwall? If you do not add that and apply the Droidwall rules, everything will remain blocked.

    April 03, 2014

    Permalink

    "Mission Impossible" (.: ambitious.
    A "new" platform must be refreshing. At first many holes are easier to plug, but a lot of difficult holes remain.

    Could "open hardware" risk less "mystery blob" trouble? But I think no open hardware is really mobile. I think they are more like plug PCs?

    I use mobile only for voice calls, but have concern that the weaker standard of Android privacy is worse than PCs years ago.

    Yes, coming from trying to make the web private, Android appears to be a piece of cake. The core is open source and has a decent architecture for app isolation, which makes me confident we can make it into something that lives up to Tor's privacy standards. This is especially true for users who do not use the Google Apps addon zip (which is where most of the privacy invasive bits in Android come from), and use F-Droid instead. The fact that F-Droid audits and flags even FOSS apps with privacy issues is also a huge boon for privacy-concerned users, too.

    However, even if some of the components or apps you use end up being non-private, you can block those from the network, and they can be prevented from obtaining private details from your privacy-sensitive apps, as well. If your privacy apps themselves are well designed and free from IPC channels, it is quite hard for other apps to steal data from them without an actual exploit against the Android platform (which is something Google takes very seriously).

    Frankly, no systems were designed with the level of privacy Tor strives for in mind. With respect to PCs, see the Chattering Laptops work -- PCs are just as bad, if not worse, and the situation has worsened since that work was published. If you want end-to-end system-level privacy, extensive deep system hacks and config tweaks are required. That's one of the reasons why projects like Tails exist.

    As for the fully open hardware, that would be very, very nice, but at the end of the day I think what it buys us over a semi-open WiFi-only device is better reduction in the vulnerability surface more so than direct privacy (though obviously you can't have privacy without security). It does concern me greatly that the WiFi firmware is not open on the Nexus 7, though. If there were a WiFi-only device supported by Replicant, I would have chosen that instead as the reference platform for this prototype.

    April 04, 2014

    Permalink

    An astounding post, thanks. It shows how difficult it is for people, especially non-technical people like me, to retain control over their devices and privacy.

    As detailed as it is, I doubt I could follow the above instructions with the 2013 Nexus 7 we have at home, despite having messed a lot with my Nexus 4, which has Cyanogenmod on it.

    Can I ask, have you investigated the XPosed framework and XPrivacy module for that framework? That's what I'm using on my phone. I'm more a privacy geek who doesn't want to be tracked, rather than someone who needs it for activism and/or life/death safety issues, so I'm wondering to what degree the time I've spend blocking permissions in XPrivacy has been worthwhile.

    Two reasons:
    1. It is not clear that Xposed+Xprivacy provides substantial improvement over Privacy Guard and the Permissions Manager built in to CM11.
    2. I did not want to recommend anything that wasn't available in the F-Droid repo, especially something that is as invasive on your device as Xposed is.

    April 05, 2014

    In reply to mikeperry

    Permalink

    There are plenty of info on this app, the guy and quite a few oder developers put substantial effort into it.
    In short - more fine grained privacy solution comparing to others mentioned. Definitely worth exploring.

    https://github.com/M66B/XPrivacy#description
    https://github.com/M66B/XPrivacy#similar-solutions

    XDA XPrivacy forum thread:
    http://forum.xda-developers.com/showthread.php?t=2320783

    April 04, 2014

    Permalink

    This is a good post, but it sounds like way too much work for me. Can I pay some organization that I trust, to do this for me and send me the resulting device?

    April 04, 2014

    Permalink

    Are you certain that the Nexus 7 2013 has only one mic? I'm asking because the 2012 had two, which makes sense for echo cancellation.

    A friend and I looked everywhere for a second mic and were unable to find one on the 2013 model. Also, every app I tested was unable to record audio after removal unless I plugged in an external mic.

    April 04, 2014

    Permalink

    The guide should implore users to disable "CyanogenMod statistics" as soon as possible after installation:

    I think you have around 24 hours after the first boot to opt out in Settings -> About Tablet. After that, it will periodically leak some sort of device ID, the OS version, and your device type (e.g. Nexus 7 2013 Wifi = codename "flo") through plain HTTP to a CM server via the Google Analytics framework. It's seriously treacherous stuff.

    Having a firewall to catch this at the last second is good, but better to stop leaks as close to the source as is reasonably possible. Maybe at some point over the years, for whatever reason (user error?) the firewall is off for a few minutes.

    BTW, the CM updater didn't use HTTPS until February 2014, and they still use MD5 everywhere. It looks fragile. https://jira.cyanogenmod.org/browse/CYAN-3502

    April 04, 2014

    In reply to mikeperry

    Permalink

    Shit, sorry.

    I hope they do a good job and post a comprehensive design document. I look forward to taking this apart and writing another blog post about any issues I find.

    April 04, 2014

    In reply to mikeperry

    Permalink

    Thanks for the feedback. I am the Lead Developer of GuardianRom. I will write a design document and cover everything in more detail for you to look at. I have been keeping the technical side down as to not scare off potential non-techie backers. :)

    Thanks,

    x942

    April 04, 2014

    Permalink

    Replicant seems to have determined that on the Galaxy Nexus, the baseband is sufficiently isolated. Wouldn't that be a great device for this purpose?

    Where is the writeup of this analysis? Ideally, they would post schematics and detailed explanation to prove it.

    Even isolated basebands often have a USB bridge (which can be exploited by pretending to be another type of device with a vulnerable USB driver) and direct access to the microphone.

    April 04, 2014

    In reply to mikeperry

    Permalink

    It's been a long time since I've looked, but iirc it's using a high-speed serial link, not USB. The microphone is connected to the audio codec, which is connected to the application processor. Uplink audio is sent from there to the baseband.

    This is a) from unreliable memory and b) from examining the software, not schematics. Caveat viewer.

    I keep hoping that one day Chromium will show up in F-Droid, but so far it has not.

    Are there any F-Droid compatible repos out there with Chromium builds? Or any Chromium APKs at all?

    April 16, 2014

    In reply to mikeperry

    Permalink

    https://code.google.com/p/chromium/wiki/AndroidBuildInstructions

    Also, HTTP Switchboard is the best security and privacy extension for Chromium and Chromium-based web browsers (for example, Google Chrome and Opera).

    It can be found at https://github.com/gorhill/httpswitchboard (scroll down for more information). The creator of it has expressed interest in porting it to Firefox.

    Check https://github.com/gorhill/httpswitchboard/issues/182 for a few things that must be considered.

    April 05, 2014

    Permalink

    > It disables "Google Captive Portal Detection", which involves connection attempts to Google servers upon Wifi assocation.

    What makes these attempts? AOSP itself or the GApps?

    These requests are made by the Settings Service (UID 1000), which is normally blocked as per the recommendations of the rest of the blog post. However, since you do need it to access the network to activate Google Play, I added the commands suggested by another commenter to disable the Captive Portal probes.

    I also updated the text of the post to mention that it is the Settings service that makes these requests.

    April 06, 2014

    In reply to mikeperry

    Permalink

    Thank you.

    April 05, 2014

    Permalink

    After read the comments, i understand that the problem on cell phones is the closed source baseband software.
    Is there an open source baseband software?

    Then, is secure a cell phone with:
    1) open source baseband software
    2) authentication for the network provider
    3) open source operating system without proprietary components (like Replicant)?

    April 07, 2014

    Permalink

    The default dd output block size (512 bytes) is a too small these days, it'll cause unnecessary wear. I'd say the comment that suggested bs=1M has it right.

    April 08, 2014

    Permalink

    I've followed the directions, but once I reboot after installing the CyanogenMod and gapps zip(s) (and after I see the cyanogenmod flash screen), I am asked to type my password to decrypt storage. I enter the correct password, but it is rejected. This is strange, because the password is correct, and the same password works during decryption when Team Win Recovery starts. What do I do at this point? Apology in advance for my lack of technical ability. Thanks!

    Answered my own question - I ended up using WugFresh's Nexus Root Toolkit to flash to stock (selecting the Soft-bricked option in the Toolkit). Once that was done, I started over with the directions above, and all is well.

    April 09, 2014

    Permalink

    " Its UI is a bit more streamlined than Guardian Project's ChatSecure, and it does not make use of any native code components (which are more vulnerable to code execution exploits than pure Java code)."

    Which native code components do you mean exactly? SQLCipher?

    April 09, 2014

    Permalink

    Good news on having to enable "Unknown sources" for F-Droid. Starting at 0.63, devices running 4.0 or later should not need to have that option enabled if they have F-Droid installed as a system app. That means having installed F-Droid in /system/app at some point, even if you have updated that system app to 0.63 by regular means.

    Future releases of the client should implement the installation of packages themselves, so the minimum requirement of 4.0 should be gone in the future.

    -mvdan

    April 09, 2014

    Permalink

    This is a great post. Echoes a lot of the stuff I've done with my SGS2 running CM10.

    However it's going a bit far to say that all basebands are riddled full of backdors that allow the gubberment to haxx0r your phone at any time. There's about three articles that everyone keep referencing over and over, most of which are FUD disguised as psudeo-news, and the rest are from groups with agendas of their own, making a lot of leaps to conclusions and using a lot of 'it's likely that' and 'may be possible' with not much evidence to suggest that's actually safe.

    http://arstechnica.com/security/2014/03/virtually-no-evidence-for-claim…

    It seems a bit tin-foil-hatty to go intentionally denying yourself the single core purpose of these devices (a *phone*) based on such sketchy info.

    Two important points you are downplaying and straw-manning:

    1. It has been known for years that law enforcement has had the ability to remotely enable the microphone of cell phones, even while the device is "powered down". If LE has this ability, it is only a matter of time before others do (and it has already been at least a decade, if not two): http://news.cnet.com/2100-1029-6140191.html

    2. This blog post isn't about denying yourself a phone at all. It is about showing that it is in fact possible to construct a *phone* in such a way that it uses fully FOSS components, properly jails apps and gives the user control and informed consent over the type of information that they can obtain and transmit, provides end-to-end cryptography for communications, and is protected from the untrustworthy, unauthenticated, and archaic cell infrastructure by hardware isolation.

    The most important point of the whole post is that it demonstrates that we can build these types of devices *today*, using off the shelf components, even if the OS vendor and equipment manufactures won't sell us what we want in a single package. Moreover, these devices can make regular PSTN phone calls if we want them to, using LinPhone and a SIP provider that supports outdialing.

    This is a powerful property, and it both opens the door to the crowd-funded design of better versions of this type of device (perhaps even as a single piece of hardware), and illuminates the way forward to building them.

    April 10, 2014

    In reply to mikeperry

    Permalink

    1. Yep, like I said above, that's one of the articles that keep being bandied about repeatedly as 'proof'. You already referenced it earlier, a few times. Thing is, if you actually read the memorandum it's based about, there's actually nothing in it that proves, or even really inferrs, that this surveilance was done by baseband hijack. People looking for conclusions they've already drawn themselves have decided that because the submission stated things like 'can be used anwhere in the US' this means it was a remote activation of the built in microphone. Probably.

    Thing is, as more than a few have pointed out, if you look at it from a more even handed approach, there are plenty of other means that make more sense to provide this outcome.

    2. SIP does indeed have outdialling options, if you're willing to pay for them. But what happens when someone wants (or NEEDS) to call you, and you don't have wifi? The portable wifi hotspots you're talking about, at least where I'm from ,are RUBBISH. Four hours life, tops. Connections drop all the time. They're not a reliable option. You'd spent the rest of your life answering frustrated voicemails....if your SIP provider has voicemail?

    Youre dead right, the GSM network is untrustworthy, unauthenticated, and archaic. But the reality is it's the standard now. Data capabiltiy has added internet to this, but at the end of the day, the ability to give and recieve communication at any time or place is the core reason 99% of people have these things. Even if it's totally secure, a phone that's only a (sortof) phone when you have wifi, and then only if the people you're trying to call have the same sort of phone, is a step backwards.

    I've tried to ask people to switch to non-GSM mesaging in the past and usually got an aswer like "why can't you just use normal text like everyone else?" Trying to convince them to switch with arguments about security is pointless - most people jsut don't give a shit. Even saving money doesn't seem to bother them. They just can't be arsed, and I still have to keep a means of contacting them. So Gibberbot winds up sitting on my phone, unused

    With the setup you're proposing, you are indeed going to probbaly be the most secure phone around at the moment. But it's not much of a phone if it makes talking your mates (and letting them talk to you) a total PITA. And when someone asks you "Hey, what's your number, I'll text you when I can pick you up", any answer you're going to give with this will have to start with "Well, the thing is...." And for 99% of people, that's a dealbreaker.

    1. Right. We don't know exactly what technique is being used in these cases, but we do know that Stingrays and other fake baseband gear exist on the surveillance device market, and they're not cheap, so they must not be useless... The scary bit is that in theory, these devices can also be replicated by a hacker with a GNU radio.

    Your very point here also underscores the problem with basebands: we have *no* verifiability here to really know what they are capable of. They probably can update themselves OTA. In fact, we're pretty sure about that. Beyond that (which is pretty bad, since the network is unauthenticated) all we can do is make guesses. If it were open source, we could verify such behavior was implemented securely. But fat chance of that happening, which is also concerning in and of itself.

    So the only option at the moment remains to isolate it and reduce it to least privilege, which is the traditional computer engineering approach for dealing with such types of systems.

    2. You still seem to be missing the point of this post. It describes a prototype. It is meant to illustrate that it is possible to create a device that has these properties. A mass-market version would not involve some sketch-ass Wifi bridge to the cell network. It would have a simple serial bridge to the cell hardware to route data packets only, and *maybe* a bridge to the microphone that was fully under the control of the OS, for pure voice calls.

    Incidentally, one of the comments above remarked that the Galaxy Nexus may actually have the properties we want already. Now, wouldn't that be nice if we could find out for sure?

    Either way, I wanted to release this version because if it exists and can be made safe for *any* wifi-only device, then we'll have more eyeballs looking at the software side while we search for, wait for, or build a hardware platform that has the isolation properties we want. But even until then, I think there is a sizable niche market even for this hacked up prototype device in terms of hobbyists, privacy enthusiasts, high security users, and/or activist users.

    Moreover as for the performance of the prototype: If your cell provider's service sucks, yes, your experience will suck. I went through 3 el-cheapo carriers before I found one that was reliable. But that is just the nature of cell service. The data networks don't yet have as extensive coverage or reliability as the 2G networks do, but they are getting there. The off-brands are abysmal, and Virgin is also particularly crappy. But, for some providers, the 3G+ data coverage is for all intents and purposes identical to voice (Verizon for sure, and T-Mobile isn't too far off in populated areas).

    April 10, 2014

    In reply to mikeperry

    Permalink

    1. Yep. Agreed. All I'm saying is that folks seem to be very quick to jump from "They might be able to, we don't know" to "They are". Call me pedantic, but I think there's a big gap there that we shouldn't jump without some sort of solid evidence.

    2. Also agreed! Which is why I was really happy when I found this, after years of google trawling that has previously only turned up only little tidbits scattered all over.

    Even if the basebands might (might) be questionable, it'd still be a mahoosive step forward if the the average user did something as simple as switch to CM, put on Droidwall and use FDE and a half decent screenlock. No, it's not totally secure for a determined adversary. But it sure as shit puts a few stumbling blocks in the way fo the mass data-miners, and mile better than a stock ROM.

    I worry that when some else googles "Secure Andriod" for the first time, and they find this great article, they're going to get to chapter one, read "Wifi Only" and go "Nope, no good for me!", and go back to just using bone stock bloatware ROMs because they've dismissed the concept of a secure setup as impractical.

    There's actually a lot more I'd like to discuss with you Mike, outside of a public comment box (which I already jam too much text into). But I can't seem to find a public email for you....

    April 10, 2014

    In reply to mikeperry

    Permalink

    Also, just out of curiosity - is the setup you've described here what you actually use day to day?

    It may well be that I'm over-stating the inconvenience of a wi-fi only phone, or that it's only an issue in my corner of the world. But at least for me, it's proven in the past to be nigh on impossible.

    Yes, I do use this setup regularly. The device is my main mechanism of communicating with friends and family. For them, I prefer Tor+OTR+XMPP rather than voice, to be honest, so I suppose I am a bit of a weirdo (it turns out that the privacy of my communications with friends and family is rather important to me -- is that weird? Who knows these days).

    For other communication, I still do have a dirt-cheap flip phone laying around. However, my goal is to fully replace that piece of junk with VoIP out-dialing.

    Again, this is all a huge experiment. I decided to see if I could build the most secure phone in the world more or less because of an argument with a close friend who said it was impossible and insane to try to do this at all. Naturally, I couldn't resist.

    I actually don't know yet if I have convinced them (they are also rather hard to get a hold of, as you might have guessed)... But even if our argument remains unsettled, I am certain that this prototype is a step in the right direction, at the very least.

    April 11, 2014

    In reply to mikeperry

    Permalink

    Allright, paint me conviced :) I'll give it a crack.

    I don't have a nexus, but I'll see if I can wipe the modem from one of my SGS2s and go from there. Who knows, maybe I can just flash the modem firmware bacdk if I really need GSM for a few minutes, then wipe it again. It's not that hard after all.

    One request - There are those of us who use VPN's instead of Tor for certain things. I know this has security issues of its own, but they are a viable alternative withing their limitiations, just like SIP. Do you think you could add an additional Droidwall script template for VPN users - ie block all outbound wifi traffic except to the VPN servers ( were they'd have to fill in their VPN server IPs) and allow connections on tun0 or whatever the VPN uses?

    The IP thing is not too hard.. Instead of allowing Orbot by UID, change those rule lines into IP address rules instead. However, I am not sure how it will interact with a different virtual interface. It is likely anything I tried to produce for you would not work, so I think my best answer is "Patches welcome! If you get it to work, I will post it in the main doc!"

    It breaks my heart people won't use Tor, of course. But at the end of the day, more people using this type of setup will mean it will get better for everyone, faster. And that's really all I care about.

    April 11, 2014

    In reply to mikeperry

    Permalink

    Cheers. I'll see what I can do.

    It's less that 'I won't use Tor' and more that 'A bunch of sites I go to have blacklisted Tor exit nodes'. And that's even more annoying.

    April 12, 2014

    In reply to mikeperry

    Permalink

    Well, this is not going well at all.

    I'm not used to using iptables, and there was a lot of content in those scripts to do with orbot that I cant make sense of.

    I tried adding in this:

    "/system/bin/iptables -A OUTPUT -d [IP address} -j ACCEPT
    /system/bin/iptables -A INPUT -s [IP address} -j ACCEPT"

    This worked with my previous setup, which was bacially a bunch of these rules on top of a default deny in and out rule. But now the open VPN client is just timing out waiting for the server to reply.

    Are you at all able to elaborate on exactly which of the Orbot UID rules that need tweaking for allowing out to other IPs? I do use Tor a lot, but I need connectivity to this VPN as well, and I would think that there' would be a lot of other people who would benefit from a provision to allow connections to a specific address as required.

    Well, in firewall-tor.sh, I replace the INPUT-firewall ORBOT_UID rule line with:

    $IPTABLES -A INPUT-firewall -m conntrack --ctstate ESTABLISHED -m tcp -p tcp -s $TOR_BRIDGE --sport 443 -j RETURN || exit

    I replace the droidwall output ORBOT_UID rule with the following rules:
    $IPTABLES -A droidwall -m owner --uid-owner $ORBOT_UID -o lo -p udp -m multiport --ports 5400 -j RETURN || exit
    $IPTABLES -A droidwall -m owner --uid-owner $ORBOT_UID -o lo -p tcp -m multiport --ports 9040,9050,9051 -j RETURN || exit
    $IPTABLES -A droidwall -m owner --uid-owner $ORBOT_UID -d $TOR_BRIDGE -p tcp --dport 443 -j RETURN || exit
    $IPTABLES -A droidwall -m owner --uid-owner $ORBOT_UID -j droidwall-reject || exit

    The TOR_BRIDGE env var is just a comma separated list of IPs, ie:
    TOR_BRIDGE=1.1.1.1,2.2.2.2,3.3.3.3

    July 21, 2014

    In reply to mikeperry

    Permalink

    Old comment I know but I'm trying to do this too - would you be able to clarify which Output ORBOT_UID you mean?

    Do we replace

    "$ORBOT_UID -p tcp -j REDIRECT --to-ports 9040 || exit"

    or

    "$IPTABLES -t nat -A OUTPUT -p udp -m owner ! --uid-owner $ORBOT_UID -m udp --dport 53 -j REDIRECT --to-ports 5400 || exit"

    Thanks!

    A VPN can be useful for circumventing blocks or maintaining a level of privacy and security on an untrusted network.

    But as a rule, a VPN should not be considered any more private than an ISP.

    The article is basically saying that there is no way to gain access to private information on the phone because only the (closed source) modem/baseband can gain access to the application processor through this particular backdoor/exploit. This means that only Samsung, your cell carrier, or anyone they provide access to, or anyone who can hack into your modem, would be able to access your private data through this backdoor/exploit.

    I'm the guy who originally posted that article after I read it myself. Which you obviously did not, but rather grossly oversimplified to twist it in line with your own preconcoieved conclusions.

    For anyone else reading, what the article ACTUALLY says, in short, is that the firmware "backdoor" that people keep saying was found in some Samsung devices had NO actual evidence that it can be remotely activated, NO evidence it was put there as an intentional exploit vector, and then even if it could be, it can't actually be used to access anything meaningfull on the device unless you've already done so much jiggery-pokery to the host device that trying to exploit a (non) back door is totally redundant.

    Its FUD, and not all suprising, considering that the claims originated from a someone tied to a group trying to promote their own OS over manufacturer ones.

    April 09, 2014

    Permalink

    I don't have a Nexus so I can't run your scripts but I'm trying to create something that can work for me. Using "Network Log", I find an awful lot of connections to Cyanogen Servers and Mountain View servers (probably Google).

    Cyanogen is called nearly every time I install an app while the Mountain View servers are called by nearly every internet application no matter which server is called.

    Cyanogen servers are called by CyanogenMod Account and CM Updater. While the Mountain View servers are called by the system as well as the kernel!

    Does anyone have any documentation on all the connections Android makes as well as what each connection does?

    April 10, 2014

    Permalink

    How come you dont have PDroid on your list of apps to install? Permissions control has got to be one of the most critical things to securing the system.

    April 10, 2014

    Permalink

    Have you look into using Nook HD or Kindle device? the last year model. they very nice tablets and wifi only with no gps and can be find very low $$ everywhere.

    April 10, 2014

    Permalink

    Doesn't CM11 have TextSecure built into it? And doesn't that have some security concerns of its own (sending your contacts list to remote server)?

    April 12, 2014

    Permalink

    this haz totally fucked my phone! I cant undo any of the scripts and nnow i have NO INTERNET unless I use tor which my email blocks. two thumbs down :(

    April 14, 2014

    Permalink

    This is an awesome post -- very many thank you's in your general direction! I'm thinking of buying a Google Nexus 7, or maybe a Nook HD+ if I can't work out how to manage this installation `howto.' Instead of a `Linux laptop,' should one be able to run the root commands of the install/config process with an iOS or another Android tablet, or would a full Unix-based OS like Ubuntu or Mountain Lion probably be necessary?

    April 15, 2014

    Permalink

    I'm having a issue to make Orweb works on this prototype.
    All other apps works fine by Tor, but Orweb don't.

    DuckDuckGo is not a problem, it works fine. But when i change its settings, to use Tor, the same thing happens. It does not works.

    I tried to modify the firewall script, but unsuccessfully.

    April 17, 2014

    Permalink

    The mac spoofing script:

    ========================
    #!/system/bin/sh

    # Make a backUp of default mac file
    macfile="/efs/wifi/.mac.info"
    macbkp="/efs/wifi/.mac.info.bkp"

    if [ -f "$macfile" ]; then

    if [ ! -f "$macbkp" ]; then
    touch /efs/wifi/.mac.info.bkp
    cat /efs/wifi/.mac.info > /efs/wifi/.mac.info.bkp
    fi

    # Uncomment this line for test only. It does not need to run at boot
    # svc wifi disable

    MAC=`echo $RANDOM | md5sum | sed 's/\(..\)/\1:/g' | cut -b-17`
    echo $MAC > /efs/wifi/.mac.info

    # Uncomment these line for test only. It does not need to run at boot
    # svc wifi enable
    # echo $MAC
    fi
    ==========================

    It has to put at the end of "userinit.sh" file without the first line "#!/system/bin/sh'. So everytime when the device boot, it get a new mac address.

    It can be used to change the mac address before activating the wireless with device turned on. Just uncomment "svc wifi disable / enable" lines.

    CM11-M4 on the Nexus 7 does not seem to have an /efs/wifi directory. There is an /etc/wifi directory, but it does not have a .mac.info file in it..

    Is this perhaps something specific to the build for your device? Is this property documented anywhere? How did you discover it? The only reference to this file that casual searching uncovered is:
    http://code.metager.de/source/xref/CyanogenMod/android/hardware/samsung…

    There are many collisions in the beginning of the md5sum output, so you only get 20708 possible MAC addresses.

    Also, randomizing the first three bytes instead of using a valid OUI makes you stand out as "someone who randomizes his MAC address".

    April 17, 2014

    Permalink

    Two thoughts that I had,

    1. It may be a good idea to put in a warning at the encryption stage that the process is very difficult - and in some cases, impossible - to reverse; and on some devices, will not permit recoveries (including TWRP) to mount the /data folder.
    2. Privacy Guard is very useful, but the fact that it does not allow one to block apps from reading phone (and presumably, tablet) status and identity is a pretty big issue. Any app that has that permission will be able to read the unique device ID and, if transmitted (which we paranoid folk have to assume will happen), does a lot to de-anonymize the user. The obvious solution to this is not to use any app that wants this permission or at the very least, to not let it connect to the Internet. But that does limit functionality to some extent. Have you any thoughts as to how this permission may be made more negotiable?

    I have implemented this setup, to the best of my ability, on my phone, and find it to be a vast improvement over my previous setup, which was mostly about praying that Orbot wouldn't crash every time I took a walk. Thank you for making this and I hope that it gets implemented into a simpler ROM package soon.

    April 20, 2014

    Permalink

    Thanks for this excellent post.

    However I got stuck at the install firewall part. Probably due to my inexperience with android. You write "Then, unzip the android-firewall.zip on your laptop, and run the installation script", I've only got a desktop, not laptop, but I guess that's beside the point, anyway why should I run that script on any other device than the Nexus? I also tried the following: did a adb push of the *.sh files to the android device, but then I couldn't find a way to execute them.

    Any advice would be appreciated...

    April 20, 2014

    Permalink

    I thought i read sometihng on hear about a getting the asus google nexus 7 version 2? or a certain model number and it said toget the wifi only version and it said the two model numbers to confirm... anyone know which models numbers would work.....would it be better to get a dual core vs a quad core for privacy.... i read asus cae out with one with dual core and then switch to quad before release.......

    April 22, 2014

    Permalink

    I am looking to try this out. I got a used google nexus 7 is that ok being used?

    I was factory reset is that bad...

    If i wipe it does it contain the info from previous owner?

    April 22, 2014

    Permalink

    Anonymous on April 20th, run './firewall-install.sh' in a shell on your laptop or desktop, with the mobile device attached via usb cable (debugging enabled, and root w/ adb).

    April 23, 2014

    Permalink

    This works with M5 + Nexus 7 (2012).

    On the 2013 edition I am attempting to set up, using M5, Orbot stays at 50%, and the log reads...

    -----------------------------------------------------

    NOTICE: No circuits are opened. Relaxed timeout for circuit 5 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 6000ms. However, it appears the circuit has timed out anyway. 0 guards are live.

    orConnStatus (various nodes): LAUNCHED
    orConnStatus (various nodes): CONNECTED

    -----------------------------------------------------

    I will try M4 and see if that works.

    April 25, 2014

    Permalink

    Mikeperry, I now tried M4 like you did with the 2013 nexus and it also fails.
    In addition, the stock browser fails to connect to the internet (the one for captive portal stuff). Any ideas?

    April 25, 2014

    Permalink

    It takes awhile now, but even if orbot is connected, I'm not able to access the internet.

    April 25, 2014

    Permalink

    Regarding my non-functioning units, I used orbot 3.0.7 for all.

    So 13.0.7 for grouperM5 release, works.

    13.0.7 does *not* work with floM4.

    April 28, 2014

    Permalink

    How can I access the admin interface of the cell modem?

    I've got TPLink cell modem that I use with my Nexus 7 that I've prepared according to these instructions. Now that modem has a web interface for administration at http://192.168.0.1 , but I can't seem to find a way to access it from my nexus. I've tried to set it as an excluded node in Orbot, but it didn't make a difference.

    Any thoughts?

    Use the firewall-allow-nontor-browser.sh script (formerly firewall-capportal.sh script) to use the Browser app to bypass Tor and admin your router. You must uncomment it in the Droidwall script UI as the post says. Watch for typos, or it won't work!

    April 28, 2014

    Permalink

    In Settings - Personal - Security - Trusted credentials there are quite a list of certificates. Should all of those really be trusted? Including CNNIC?

    April 28, 2014

    Permalink

    "here is a signed set of SHA256 hashes I've observed for those packages."

    What do we do with these?

    May 09, 2014

    Permalink

    Hi,

    I tried this guide and it worked so far. But I decided to remove orbot and now I cant access Net anymore.

    I have disabled the firewall scripts and even disabled the firewall.
    I have set in Wifi settings the dns by hand ... but not connectivity what so ever.
    Now I cant even install orbot back.
    And I could not find any guide/manual on the net how to remove orbot with trans-proxying..

    please give me an advice.

    This is probably because the userinit.sh script is still in /data/local, which Cyanogen will run at boot. That script was installed there to prevent non-tor network access during boot.

    After removing Droidwall and tor, that script will still block everything, and nothing is resetting its rules. To fix this, use the File manager app in root mode to remove it.

    May 10, 2014

    Permalink

    There is a scary thing...
    Android - and also Cyanogenmod - is using the combination of horribly broken RC4 and MD5 as the first default cipher on all SSL connections. This impacts all apps that did not care enough to change the list of enabled ciphers (i.e. almost all existing apps).

    More information here:
    http://op-co.de/blog/posts/android_ssl_downgrade/

    Can anyone write an update package, which enables TLS 1.2 and uses following default ciphers (perfect forward secrecy only)?

    ECDHE-ECDSA-CHACHA20-POLY1305-SHA384
    ECDHE-RSA-CHACHA20-POLY1305-SHA384
    ECDHE-ECDSA-AES256-GCM-SHA384
    ECDHE-RSA-AES256-GCM-SHA384
    DHE-RSA-AES256-GCM-SHA384
    ECDHE-ECDSA-AES256-SHA384
    ECDHE-RSA-AES256-SHA384
    ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
    ECDHE-RSA-CHACHA20-POLY1305-SHA256
    ECDHE-ECDSA-AES256-GCM-SHA256
    ECDHE-RSA-AES256-GCM-SHA256
    DHE-RSA-AES256-GCM-SHA256
    ECDHE-ECDSA-AES128-GCM-SHA256
    ECDHE-RSA-AES128-GCM-SHA256
    DHE-RSA-AES128-GCM-SHA256
    ECDHE-ECDSA-AES256-SHA256
    ECDHE-RSA-AES256-SHA256
    DHE-RSA-AES256-SHA256
    ECDHE-ECDSA-AES128-SHA256
    ECDHE-RSA-AES128-SHA256
    DHE-RSA-AES128-SHA256
    ECDHE-ECDSA-AES256-SHA
    ECDHE-RSA-AES256-SHA
    DHE-RSA-AES256-SHA
    DHE-RSA-CAMELLIA256-SHA
    ECDHE-ECDSA-AES128-SHA
    ECDHE-RSA-AES128-SHA
    DHE-RSA-AES128-SHA
    DHE-RSA-CAMELLIA128-SHA

    May 11, 2014

    Permalink

    "AFWall+'s "fix" for this startup data leak problem does not work on Cyanogenmod (hence our userinit script instead)."

    I've never seen an issue on CM10.1 or CM10.2. AFWall just uses standard init.d scripts.

    There was a recent discussion in the XDA thread[1] on how to enable the "leak fix" script on ROMs that do not have init.d support built into the initrd, by hijacking install-recovery.sh. If that isn't working for you, can you post a bug report in the thread or on the github project?

    "There is also a strong economic incentive for Asus and Google to make it extremely difficult to activate the baseband even if the hardware is otherwise identical for manufacturing reasons, since they sell the WiFi-only version for $100 less. If it were easy to re-enable the baseband, HOWTOs would exist (which they do not seem to, at least not yet), and they would cut into their LTE device sales."

    The wifi versions do not have a SIM card slot.

    IIRC the 2012 wifi models completely lacked a baseband chipset. But obviously the S4 Pro in the 2013 version does have a radio. The ifixit teardown page[2] did not mention a 3G antenna or a 3G transceiver chip like WTR1605L[3], so it is unlikely that this unit would be able to communicate on a mobile network at all.

    "Aside from the permissions issue fixed by our firewall-tor.sh script, AFWall+ provides no additional security fixes over the stock Droidwall."

    AFWall adds per-app control over LAN and VPN interfaces, which can be useful if you want certain apps to only have access to local networks (e.g. file browser, media player) or if you want to force them to always communicate over a private/corporate VPN connection.

    It also adds a hole for DNS requests on Android 4.3+, although dnsproxy2 is a better solution becaues it completely plugs the DNS leak hole. AFWall also lets you enable NTP without allowing other traffic from UID 1000, the Android system catch-all UID that frequently tries to connect back to Google.

    [1] http://forum.xda-developers.com/showthread.php?t=1957231
    [2] http://www.ifixit.com/Teardown/Nexus+7+2nd+Generation+Teardown/16072
    [3] http://www.anandtech.com/show/6541/the-state-of-qualcomms-modems-wtr160…

    May 15, 2014

    Permalink

    Hopefully it's not too late add this to your brilliant post --

    The problem with changing the FDE password later on (given that it's very hard to delete anything from solid storage) is that the old salt etc. generated for the short password will probably still be around for an attacker, so you haven't really gained any security by changing to a longer password.

    The only way to avoid this, as far as I can tell, is to use the following sequence:

    1. Install Android and set your (short) screen unlock password.
    2. Instead of using the the GUI to encrypt your device, run su -c "vdc cryptfs enablecrypto inplace YOUR_LONG_PASSWORD"

    May 17, 2014

    Permalink

    "The problem with changing the FDE password later on (given that it's very hard to delete anything from solid storage) is that the old salt etc. generated for the short password will probably still be around for an attacker"

    Can this actually be read back out through the eMMC block interface, or does it require accessing the raw NAND flash to view overwritten sectors? The latter procedure requires insider knowledge of the specific flash device and is not normally covered by forensic imaging procedures, making the attack more costly and rare.

    May 21, 2014

    Permalink

    Instead of a 4-digit numerical screen password, how about this for a usable and secure password policy:

    - A long, lowercase alphabetic disk encryption password
    - The first couple of letters of the former password as a screen unlock password
    - "Quick unlock" checked in Settings -> Security.

    May 23, 2014

    Permalink

    I have an issue with encrypting the device.

    After typing:

    su
    vdc cryptfs enablecrypto inplace NewMoreSecurePassword

    all I get is:

    vdc: command not found

    Any ideas?

    May 31, 2014

    Permalink

    Great tutorial! Exactly what i was looking for, thanx a lot.
    I got 2 problems with your custom scripts. I want to allow adb over network, but the script won`t work for me.
    - In firewall-allow-adb.sh the predefined UID for ADB is 10004. This UID is taken by FDroid on my phone. How could i get the UID for ADB?
    - SAFE_NETWORK is set on 10.23.69.0/24. Should this be replaced with 192.168.2.0/24?

    And another question is, how could i use another app then Browser to bypass Tor and allow access to local network? I`d like to setup the Sonos app to manage my Sonos Network.
    I tried modifying the firewall-allow-nontor-browser.sh without success.

    Thanx in advance.

    May 31, 2014

    Permalink

    I'm trying to carefully follow the guide with my wifi-only Nexus 7 (2013). I opted out of the Google experience altogether, though. After the first reboot following the full setup, Droidwall blocks all traffic, also from whitelisted apps. It worked as expected before the reboot. If I disable the firewall from Droidwall, any traffic is allowed and gets routed through Tor. I expected everything to be dropped.
    Working with my very limited iptables experience, I figured that the IPv4 section in userinit.sh should start with

    1. <br />
    2. iptables -F<br />
    3. iptables -X<br />
    and Droidwall should run userinit.sh as a custom script if the firewall gets disabled. What do you think of this modification?
    That does not solve the problem of Droidwall blocking everything when the firewall is on. I have triple-checked the custom script input for typos. Do you have any idea what is up?
    By the way, if anyone else needs to get rid of the encryption to start over again, downgrade to CM 10.2 after wiping and formatting in recovery. Something significant changed in cryptfs between Android 4.3 and 4.4. After I wiped CM 10.2 away and formatted once more, TWRP finally stopped asking for the encryption passphrase. This cure allowed my wifi to turn on again after several CM 11 reinstallations over an already encrypted /data failed.

    Droidwall cannot work properly if you purge OUTPUT rules.
    As you can see at: https://code.google.com/p/droidwall/wiki/CustomScripts

    You need redirect all from OUTPUT to a chain like "OUTPUT-firewall". And then u can drop traffic.

    Here is a custom script to run when Droidwall is disabled. It will block everything.
    Put in on /data/local/

    ========================================
    IP6TABLES=/system/bin/ip6tables
    IPTABLES=/system/bin/iptables

    # Fix for https://code.google.com/p/droidwall/issues/detail?id=260
    chmod 755 /data/data/com.googlecode.droidwall/app_bin/droidwall.sh

    # Clear Rules
    $IP6TABLES -t nat -F
    $IP6TABLES -F
    $IPTABLES -t nat -F
    $IPTABLES -F INPUT-firewall
    $IPTABLES -F OUTPUT-firewall

    ## Create Chains ##
    $IPTABLES -N INPUT-firewall
    $IPTABLES -D INPUT -j INPUT-firewall
    $IPTABLES -I INPUT -j INPUT-firewall
    $IPTABLES -N OUTPUT-firewall
    $IPTABLES -D OUTPUT -j OUTPUT-firewall
    $IPTABLES -I OUTPUT -j OUTPUT-firewall

    ## DROP TRAFFIC ##
    $IP6TABLES -A INPUT -j LOG --log-prefix "Denied IPv6 input: "
    $IP6TABLES -A INPUT -j DROP
    $IP6TABLES -A OUTPUT -j LOG --log-prefix "Denied IPv6 output: "
    $IP6TABLES -A OUTPUT -j DROP
    $IPTABLES -A INPUT-firewall -j LOG --log-prefix "Denied IPv4 input: "
    $IPTABLES -A INPUT-firewall -j DROP
    $IPTABLES -A OUTPUT-firewall -j LOG --log-prefix "Denied IPv4 output: "
    $IPTABLES -A OUTPUT-firewall -j DROP
    ========================================

    July 03, 2014

    Permalink

    It's best to unlock the boot chain only temporarily to install a new ROM. Then a physical attacker cannot quite so easily copy your encrypted data, or infect your device with malware. Here's a workflow that keeps user data intact across ROM upgrades:

    Initial relock (assuming CM is already installed):

    1. Download the current factory image[*], unpack it, then unpack the inner zipfile inside
    2. (Re)boot into the bootloader
    3. fastboot flash recovery path/to/extracted/factoryimage/inner/recovery.img
    4. fastboot oem lock
    5. Boot
    6. Install the open source BootUnlocker[**] apk (no need to run it yet)
    7. Enable Settings -> Developer options -> Advanced reboot so you can easily access the bootloader

    ROM upgrade:

    1. Use BootUnlocker to unlock the bootloader
    2. Reboot into bootloader
    3. fastboot boot path/to/clockwork-recovery.img
    4. Install the ROM as usual
    5. Either reboot into bootloader and run fastboot oem lock or use BootUnlocker to re-lock

    ------------------------------------
    [*] https://developers.google.com/android/nexus/images
    [**] https://code.google.com/p/boot-unlocker-gnex/downloads/list

    July 04, 2014

    Permalink

    Hey do you know how to get tethering working through this setup? Can you give me a script for DroidWall?

    Matthew Garett wrote an article on how to use self-signed custom Android ROMs: It's annoying and involves a bunch of manual processes and you'll need to re-sign every update yourself. But it is possible to configure Nexus devices in such a way that you retain the same level of security you had when you were using the Google keys without losing the freedom to run whatever you want.

    July 23, 2014

    Permalink

    Just wanted to say, removing the mic with an X-Acto knife was really just as easy as the guide said it would be. Thank you, Mike!

    July 31, 2014

    Permalink

    No, it pretty much does the exact same thing as far as I can tell as the ADB/terminal method touted earlier in the comments (which I have also used to adequate effect on some devices/ROMs other than the Nexus7 tablet). It seems to use a slightly different method but has a same effect. Did you even read that thread? Or apply the patch? The baseband doesn't disappear from sysinfo when you turn on airplane mode.

    I can't help but wonder if the OP in that thread was actually going for something of the same nature as this article here, but was being more circumspect about it because it was before the recent outrage that made surveillance evasion so much more normal and accepted.

    August 16, 2014

    Permalink

    Thank you for the great post and all those useful comments.

    What about Orwall? Although independent from the Tor project, it seems it does the same job that Droidwall would do. Is it really efficient? It is really user-friendly. Thanks.

    August 16, 2014

    Permalink

    Admirable goal and useful project for some people, but until non-tech people can easily do these things, this is not much help.

    This gives me somewhat private communication provided I am using wifi and only communicating with other tech savvy people.

    For everything else, I have two options:
    1. Refuse to communicate with 95% of regular users.
    2 Communicate in the clear and have everything logged and stored forever.

    Also, these non-techs that I deal with are not stupid. Many are very intelligent types, but do you expect a surgeon working 80 hours a week to set something like this up so they can communicate with me?

    I happen to have a lot of friends in the medical community, and for the most part they are too busy and not skilled enough to even follow a step-by-step guide like this. And I am not going to be their person IT person to do things like this for them. Most would not want anyone handling their device anyway.

    August 19, 2014

    Permalink

    Following my previous comment (August 16th) and after searching again on orwall.org, I noticed that "basically, orWall is a simple UI for scripts provided by Mike Perry in his blog post on torproject" according to its developer. Looks good.

    August 19, 2014

    Permalink

    Thanks for the article, is there any way I can receive an email whenever you publish a new update? eakgeeeaddgegcde

    August 21, 2014

    Permalink

    first of all: great blog post! I am not so familiar with iptables. is there. way to establish a vpn connection first and then tunnel all the tor traffic through the vpn? wouldn't that be a extra security and privacy layer - especially if a exit node is compromised?

    August 22, 2014

    Permalink

    These scripts seem to be quite cobbled together and are full of incompatibilities and holes.

    The allow-nontor-browser script flat-out does not work. Browser still has no acccess.

    If you connect to a portable wifi hotspot from anothe phone, the tor transproxy script causes Tor to hang at 25% of loading network consensus status.

    The instructions for allowing allowing google play to work are also non-functional. Even allowing every app in droidwall, google services just cannot make a connection.

    Nice on paper but useless for any normal person to actually use.