Mission Improbable: Hardening Android for Security And Privacy

.frame {
text-align: center; margin: 1em 0;
}
.screenshot {
max-height:100%;
max-width:40%;
vertical-align:middle;
horizontal-align:center;
}

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

After a long wait, the Tor project is happy to announce a refresh of our Tor-enabled Android phone prototype.

This prototype is meant to show a possible direction for Tor on mobile. While I use it myself for my personal communications, it has some rough edges, and installation and update will require familiarity with Linux.

The prototype is also meant to show that it is still possible to replace and modify your mobile phone's operating system while retaining verified boot security - though only just barely. The Android ecosystem is moving very fast, and in this rapid development, we are concerned that the freedom of users to use, study, share, and improve the operating system software on their phones is being threatened. If we lose these freedoms on mobile, we may never get them back. This is especially troubling as mobile access to the Internet becomes the primary form of Internet usage worldwide.

Quick Recap

We are trying to demonstrate that it is possible to build a phone that respects user choice and freedom, vastly reduces vulnerability surface, and sets a direction for the ecosystem with respect to how to meet the needs of high-security users. Obviously this is a large task. Just as with our earlier prototype, we are relying on suggestions and support from the wider community.

Help from the Community

When we released our first prototype, the Android community exceeded our wildest expectations with respect to their excitement and contributions. The comments on our initial blog post were filled with helpful suggestions.

Soon after that post went up, Cédric Jeanneret took my Droidwall scripts and adapted them into the very nice OrWall, which is exactly how we think a Tor-enabled phone should work in general. Users should have full control over what information applications can access on their phones, including Internet access, and have control over how that Internet access happens. OrWall provides the networking component of this access control. It allows the user to choose which apps route through Tor, which route through non-Tor, and which can't access the Internet at all. It also has an option to let a specific Voice over IP app, like Signal, bypass Tor for the UDP voice data channel, while still sending call setup information over Tor.

At around the time that our blog post went up, the Copperhead project began producing hardened builds of Android. The hardening features make it more difficult to exploit Android vulnerabilities, and also provides WiFi MAC address randomization, so that it is no longer trivial to track devices using this information.

Copperhead is also the only Android ROM that supports verified boot, which prevents exploits from modifying the boot, system, recovery, and vendor device partitions. Coppherhead has also extended this protection by preventing system applications from being overridden by Google Play Store apps, or from writing bytecode to writable partitions (where it could be modified and infected). This makes Copperhead an excellent choice for our base system.

The Copperhead Tor Phone Prototype

Upon the foundation of Copperhead, Orbot, Orwall, F-Droid, and other community contributions, we have built an installation process that installs a new Copperhead phone with Orbot, OrWall, SuperUser, Google Play, and MyAppList with a list of recommended apps from F-Droid.

We require SuperUser and OrWall instead of using the VPN APIs because the Android VPN APIs are still not as reliable as a firewall in terms of preventing leaks. Without a firewall-based solution, the VPN can leak at boot, or if Orbot is killed or crashes. Additionally, DNS leaks outside of Tor still occur with the VPN APIs on some systems.

We provide Google Play primarily because Signal still requires it, but also because some users probably also want apps from the Play Store. You do not need a Google account to use Signal, but then you need to download the Signal android package and sideload it manually (via adb install).

The need to install these components to the system partition means that we must re-sign the Copperhead image and updates if we want to keep the ability to have system integrity from Verified Boot.

Thankfully, the Nexus Devices supported by Copperhead allow the use of user-generated keys. The installation process simply takes a Copperhead image, installs our additional apps, and signs it with the new keys.

Systemic Threats to Software Freedom

Unfortunately, not only is Copperhead the only Android rebuild that supports Verified Boot, but the Google Nexus/Pixel hardware is the only Android hardware that allows the user to install their own keys to retain both the ability to modify the device, as well as have the filesystem security provided by verified boot.

This, combined with Google's increasing hostility towards Android as a fully Open Source platform, as well as the difficulty for external entities to keep up with Android's surprise release and opaque development processes, means that the ability for end-users to use, study, share, and improve the Android system are all in great jeopardy.

This all means that the Android platform is effectively moving to a "Look but don't touch" Shared Source model that Microsoft tried in the early 2000s. However, instead of being explicit about this, Google appears to be doing it surreptitiously. It is a very deeply disturbing trend.

It is unfortunate that Google seems to see locking down Android as the only solution to the fragmentation and resulting insecurity of the Android platform. We believe that more transparent development and release processes, along with deals for longer device firmware support from SoC vendors, would go a long way to ensuring that it is easier for good OEM players to stay up to date. Simply moving more components to Google Play, even though it will keep those components up to date, does not solve the systemic problem that there are still no OEM incentives to update the base system. Users of old AOSP base systems will always be vulnerable to library, daemon, and operating system issues. Simply giving them slightly more up to date apps is a bandaid that both reduces freedom and does not solve the root security problems. Moreover, as more components and apps are moved to closed source versions, Google is reducing its ability to resist the demand that backdoors be introduced. It is much harder to backdoor an open source component (especially with reproducible builds and binary transparency) than a closed source one.

If Google Play is to be used as a source of leverage to solve this problem, a far better approach would be to use it as a pressure point to mandate that OEMs keep their base system updated. If they fail to do so, their users will begin to lose Google Play functionality, with proper warning that notifies them that their vendor is not honoring their support agreement. In a more extreme version, the Android SDK itself could have compiled code that degrades app functionality or disables apps entirely when the base system becomes outdated.

Another option would be to change the license of AOSP itself to require that any parties that distribute binaries of the base system must provide updates to all devices for some minimum period of time. That would create a legal avenue for class-action lawsuits or other legal action against OEMs that make "fire and forget" devices that leave their users vulnerable, and endanger the Internet itself.

While extreme, both of these options would be preferable to completely giving up on free and open computing for the future of the Internet. Google should be competing on overall Google account integration experience, security, app selection, and media store features. They should use their competitive position to encourage/enforce good OEM behavior, not to create barriers and bandaids that end up enabling yet more fragmentation due to out of date (and insecure) devices.

It is for this reason that we believe that projects like Copperhead are incredibly important to support. Once we lose these freedoms on mobile, we may never get them back. It is especially troubling to imagine a future where mobile access to the Internet is the primary form of Internet usage, and for that usage, all users are forced to choose between having either security or freedom.

Hardware Choice

The hardware for this prototype is the Google Nexus 6P. While we would prefer to support lower end models for low income demographics, only the Nexus and Pixel lines support Verified Boot with user-controlled keys. We are not aware of any other models that allow this, but we would love to hear if there are any that do.

In theory, installation should work for any of the devices supported by Copperhead, but updating the device will require the addition of an updater-script and an adaptation of the releasetools.py for that device, to convert the radio and bootloader images to the OTA update format.

If you are not allergic to buying hardware online, we highly recommend that you order them from the Copperhead store. The devices are shipped with tamper-evident security tape, for what it's worth. Otherwise, if you're lucky, you might still be able to find a 6P at your local electronics retail store. Please consider donating to Copperhead anyway. The project is doing everything right, and could use your support.

Hopefully, we can add support for the newer Pixel devices as soon as AOSP (and Copperhead) supports them, too.

Installation

Before you dive in, remember that this is a prototype, and you will need to be familiar with Linux.

With the proper prerequisites, installation should be as simple as checking out the Mission Improbable git repository, and downloading a Copperhead factory image for your device.

The run_all.sh script should walk you through a series of steps, printing out instructions for unlocking the phone and flashing the system. Please read the instructions in the repository for full installation details.

The very first device boot after installation will take a while, so be patient. During this boot, you should note the fingerprint of your key on the yellow boot splash screen. That fingerprint is what authenticates the use of your key and the rest of the boot process.

Once the system is booted, after you have given Google Play Services the Location and Storage permissions (as per the instructions printed by the script), make sure you set the Date and Time accurately, or Orbot will not be able to connect to the Tor Network.

Then, you can start Orbot, and allow F-Droid, Download Manager, the Copperhead updater, Google Play Services (if you want to use Signal), and any other apps you want to access the network.

NOTE: To keep Orbot up to date, you will have to go into F-Droid Repositories option, and click Guardian Project Official Releases.

Installation: F-Droid apps

Once you have networking and F-Droid working, you can use MyAppList to install apps from F-Droid. Our installation provides a list of useful apps for MyAppList. The MyAppsList app will allow you to select the subset you want, and install those apps in succession by invoking F-Droid. Start this process by clicking on the upward arrow at the bottom right of the screen:

Alternately, you can add links to additional F-Droid packages in the apk url list prior to running the installation, and they will be downloaded and installed during run_all.sh.

NOTE: Do not update OrWall past 1.1.0 via F-Droid until issue 121 is fixed, or networking will break.

Installation: Signal

Signal is one of the most useful communications applications to have on your phone. Unfortunately, despite being open source itself, Signal is not included in F-Droid, for historical reasons. Near as we can tell, most of the issues behind the argument have actually been since resolved. Now that Signal is reproducible, we see no reason why it can't be included in some F-Droid repo, if not the F-Droid repo, so long as it is the same Signal with the same key. It is unfortunate to see so much disagreement over this point, though. Even if Signal won't make the criterion for the official F-Droid repo (or wherever that tirefire of a flamewar is at right now), we wish that at the very least it could meet the criterion for an alternate "Non-Free" repo, much like the Debian project provides. Nothing is preventing the redistribution of the official Signal apk.

For now, if you do not wish to use a Google account with Google Play, it is possible to download the Signal apks from one of the apk mirror sites (such as APK4fun, apkdot.com, or apkplz.com). To ensure that you have the official Signal apk, perform the following:

  1. Download the apk.
  2. Unzip the apk with unzip org.thoughtcrime.securesms.apk
  3. Verify that the signing key is the official key with keytool -printcert -file META-INF/CERT.RSA
  4. You should see a line with SHA256: 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0 EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
  5. Make sure that fingerprint matches (the space was added for formatting).
  6. Verify that the contents of that APK are properly signed by that cert with: jarsigner -verify org.thoughtcrime.securesms.apk. You should see jar verified printed out.

Then, you can install the Signal APK via adb with adb install org.thoughtcrime.securesms.apk. You can verify you're up to date with the version in the app store with ApkTrack.

For voice calls to work, select Signal as the SIP application in OrWall, and allow SIP access.


Updates

Because Verified Boot ensures filesystem integrity at the device block level, and because we modify the root and system filesystems, normal over the air updates will not work. The fact that we use different device keys will prevent the official updates from installing at all, but even if they did, they would remove the installation of Google Play, SuperUser, and the OrWall initial firewall script.

When the phone notifies you of an update, you should instead download the latest Copperhead factory image to the mission-improbable working directory, and use update.sh to convert it into a signed update zip that will get sideloaded and installed by the recovery. You need to have the same keys from the installation in the keys subdirectory.

The update.sh script should walk you through this process.

Updates may also reset the system clock, which must be accurate for Orbot to connect to the Tor network. If this happens, you may need to reset the clock manually under Date and Time Settings

Usage

I use this prototype for all of my personal communications - Email, Signal, XMPP+OTR, Mumble, offline maps and directions in OSMAnd, taking pictures, and reading news and books. I use Intent Intercept to avoid accidentally clicking on links, and to avoid surprising cross-app launching behavior.

For Internet access, I personally use a secondary phone that acts as a router for this phone while it is in airplane mode. That phone has an app store and I use it for less trusted, non-private applications, and for emergency situations should a bug with the device prevent it from functioning properly. However, it is also possible to use a cheap wifi cell router, or simply use the actual cell capabilities on the phone itself. In that case, you may want to look into CSipSimple, and a VoIP provider, but see the Future Work section about potential snags with using SIP and Signal at the same time.

I also often use Google Voice or SIP numbers instead of the number of my actual phone's SIM card just as a general protection measure. I give people this number instead of the phone number of my actual cell device, to prevent remote baseband exploits and other location tracking attacks from being trivial to pull off from a distance. This is a trade-off, though, as you are trusting the VoIP provider with your voice data, and on top of this, many of them do not support encryption for call signaling or voice data, and fewer still support SMS.

For situations where using the cell network at all is either undesirable or impossible (perhaps because it is disabled due to civil unrest), the mesh network messaging app Rumble shows a lot of promise. It supports both public and encrypted groups in a Twitter-like interface run over either a wifi or bluetooth ad-hoc mesh network. It could use some attention.

Future Work

Like the last post on the topic, this prototype obviously has a lot of unfinished pieces and unpolished corners. We've made a lot of progress as a community on many of the future work items from that last post, but many still remain.

Future work: More Device Support

As mentioned above, installation should work on all devices that Copperhead supports out of the box. However, updates require the addition of an updater-script and an adaptation of the releasetools.py for that device, to convert the radio and bootloader images to the OTA update format.

Future Work: MicroG support

Instead of Google Play Services, it might be nice to provide the Open Source MicroG replacements. This requires some hackery to spoof the Google Play Service Signature field, though. Unfortunately, this method creates a permission that any app can request to spoof signatures for any service. We'd be much happier about this if we could find a way for MicroG to be the only app to be able to spoof permissions, and only for the Google services it was replacing. This may be as simple as hardcoding those app ids in an updated version of one of these patches.

Future Work: Netfilter API (or better VPN APIs)

Back in the WhisperCore days, Moxie wrote a Netfilter module using libiptc that enabled apps to edit iptables rules if they had permissions for it. This would eliminate the need for iptables shell callouts for using OrWall, would be more stable and less leaky than the current VPN APIs, and would eliminate the need to have root access on the device (which is additional vulnerability surface). That API needs to be dusted off and updated for the Copperhead compatibility, and then Orwall would need to be updated to use it, if present.

Alternatively, the VPN API could be used, if there were ways to prevent leaks at boot, DNS leaks, and leaks if the app is killed or crashes. We'd also want the ability to control specific app network access, and allow bypass of UDP for VoIP apps.

Future Work: Fewer Binary Blobs

There are unfortunately quite a few binary blobs extracted from the Copperhead build tree in the repository. They are enumerated in the README. This was done for expedience. Building some of those components outside of the android build tree is fairly difficult. We would happily accept patches for this, or for replacement tools.

Future Work: F-Droid auto-updates, crash reporting, and install count analytics

These requests come from Moxie. Having these would make him much happier about F-Droid Signal installs.

It turns out that F-Droid supports full auto-updates with the Priviledged Extension, which Copperhead is working on including.

Future Work: Build Reproducibility

Copperhead itself is not yet built reproducibly. It's our opinion that this is the AOSP's responsibility, though. If it's not the core team at Google, they should at least fund Copperhead or some other entity to work on it for them. Reproducible builds should be an organizational priority for all software companies. Moreover, in combination with free software, they are an excellent deterrent against backdoors.

In this brave new world, even if we can trust that the NSA won't be ordered to attack American companies to insert backdoors, deteriorating relationships with China and other state actors may mean that their incentives to hold back on such attacks will be greatly reduced. Closed source components can also benefit from reproducible builds, since compromising multiple build systems/build teams is inherently harder than compromising just one.

Future Work: Orbot Stability

Unfortunately, the stability of Orbot itself still leaves a lot to be desired. It is fairly fragile to network disconnects. It often becomes stuck in states that require you to go into the Android Settings for Apps, and then Force Stop Orbot in order for it to be able to reconnect properly. The startup UI is also fragile to network connectivity.

Worse: If you tap the start button either too hard or multiple times while the network is disconnected or while the phone's clock is out of sync, Orbot can become confused and say that it is connected when it is not. Luckily, because the Tor network access security is enforce by Orwall (and the Android kernel), instabilities in Orbot do not risk Tor leaks.

Future Work: Backups and Remote Wipe

Unfortunately, backups are an unsolved problem. In theory, adb backup -all should work, but even the latest adb version from the official Android SDK appears to only backup and restore partial data. Apparently this is due to adb obeying manifest restrictions on apps that request not to be backed up. For the purposes of full device backup, it would be nice to have an adb version that really backed up everything.

Instead, I use the export feature of K-9 Mail, Contacts, and the Calendar Import-Export app to export that data to /sdcard, and then adb pull /sdcard. It would be nice to have an end-to-end encrypted remote backup app, though. Flock had promise, but was unfortunately discontinued.

Similarly, if a phone is lost, it would be nice to have a cryptographically secure remote wipe feature.

Future Work: Baseband Analysis (and Isolation)

Until phones with auditable baseband isolation are available (the Neo900 looks like a promising candidate), the baseband remains a problem on all of these phones. It is unknown if vulnerabilities or backdoors in the baseband can turn on the mic, make silent calls, or access device memory. Using a portable hotspot or secondary insecure phone is one option for now, but it is still unknown if the baseband is fully disabled in airplane mode. In the previous post, commenters recommended wiping the baseband, but on most phones, this seems to also disable GPS.

It would be useful to audit whether airplane mode fully disables the baseband using either OpenBTS, OsmocommBB, or a custom hardware monitoring device.

Future Work: Wifi AP Scanning Prevention

Copperhead may randomize the MAC address, but it is quite likely that it still tries to connect to configured APs, even if they are not there (see these two XDA threads). This can reveal information about your home and work networks, and any other networks you have configured.

There is a Wifi Privacy Police App in F-Droid, and Smarter WiFi may be other options, but we have not yet had time to audit/test either. Any reports would be useful here.

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 port is still incomplete, however. The Tor Project is working on obtaining funding to bring it on par with the desktop Tor Browser.

Future Work: Better SIP Support

Right now, it is difficult to use two or more SIP clients in OrWall. You basically have to switch between them in the settings, which is also fragile and error prone. It would be ideal if OrWall allowed multiple SIP apps to be selected.

Additionally, SIP providers and SIP clients have very poor support for TLS and SRTP encryption for call setup and voice data. I could find only two such providers that advertised this support, but I was unable to actually get TLS and SRTP working with CSipSimple or LinPhone for either of them.

Future Work: Installation and full OTA updates without Linux

In order for this to become a real end-user phone, we need to remove the requirement to use Linux in order to install and update it. Unfortunately, this is tricky. Technically, Google Play can't be distributed in a full Android firmware, so we'd have to get special approval for that. Alternatively, we could make the default install use MicroG, as above. In either case, it should just be a matter of taking the official Copperhead builds, modifying them, changing the update URL, and shipping those devices with Google Play/MicroG and the new OTA location. Copperhead or Tor could easily support multiple device install configurations this way without needing to rebuild everything for each one. So legal issues aside, users could easily have their choice of MicroG, Google Play, or neither.

Personally, I think the demand is higher for some level of Google account integration functionality than what MicroG provides, so it would be nice to find some way to make that work. But there are solid reasons for avoiding the use of a Google account (such as Google's mistreatment of Tor users, the unavailability of Google in certain areas of the world due to censorship of Google, and the technical capability of Google Play to send targeted backdoored versions of apps to specific accounts).

Future Work: Better Boot Key Representation/Authentication

The truncated fingerprint is not the best way to present a key to the user. It is both too short for security, and too hard to read. It would be better to use something like the SSH Randomart representation, or some other visual representation that encodes a cryptographically strong version of the key fingerprint, and asks the user to click through it to boot. Though obviously, if this boot process can also be modified, this may be insufficient.

Future Work: Faster GPS Lock

The GPS on these devices is device-only by default, which can mean it is very slow. It would be useful to find out if µg UnifiedNlp can help, and which of its backends are privacy preserving enough to recommend/enable by default.

Future Work: Sensor Management/Removal

As pointed out in great detail in one of the comments below, these devices have a large number of sensors on them that can be used to create side channels, gather information about the environment, and send it back. The original Mission Impossible post went into quite a bit of detail about how to remove the microphone from the device. This time around, I focused on software security. But like the commentor suggested, you can still go down the hardware modding rabbithole if you like. Just search YouTube for teardown nexus 6P, or similar.


Changes Since Initial Posting

Like the last post, this post will likely be updated for a while based on community feedback. Here is the list of those changes so far.

  1. Added information about secondary SIP/VoIP usage in the Usage section and the Future Work sections.
  2. Added a warning not to upgrade OrWall until Issue 121 is fixed.
  3. Describe how we could remove the Linux requirement and have OTA updates, as a Future Work item.
  4. Remind users to check their key fingerprint at installation and boot, and point out in the Future Work section that this UI could be better.
  5. Mention the Neo900 in the Future Work: Baseband Isolation section
  6. Wow, the Signal vs F-Droid issue is a stupid hot mess. Can't we all just get along and share the software? Don't make me sing the RMS song, people... I'll do it...
  7. Added a note that you need the Guardian Project F-Droid repo to update Orbot.
  8. Add a thought to the Systemic Threats to Software Freedom section about using licensing to enforce the update requirement in order to use the AOSP.
  9. Mention ApkTrack for monitoring for Signal updates, and Intent Intercept for avoiding risky clicks.
  10. Mention alternate location providers as Future Work, and that we need to pick a decent backend.
  11. Link to Conversations and some other apps in the usage section. Also add some other links here and there.
  12. Mention that Date and Time must be set correctly for Orbot to connect to the network.
  13. Added a link to Moxie's netfilter code to the Future Work section, should anyone want to try to dust it off and get it working with Orwall.
  14. Use keytool instead of sha256sum to verify the Signal key's fingerprint. The CERT.RSA file is not stable across versions.
  15. The latest Orbot 15.2.0-rc8 still has issues claiming that it is connected when it is not. This is easiest to observe if the system clock is wrong, but it can also happen on network disconnects.
  16. Add a Future Work section for sensor management/removal

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

Anon

November 17, 2016

Permalink

@ Peter P:

Thanks again for setting up some debian mirrors as onion sites! Can you cryptographically sign the list of onion site mirrors for debian.org? (Same for the onion site mirrors for torproject.org.)

Tip to Debian users: using Synaptic, remove "main" from the sections for the ordinary mirrors which now have onion counterparts, then add the new onion sites with only "main" section. If you omit the first step, apt is likely to become confused about where it should look for updates.

As I understand it, setting up an onion version of public websites can not only improve access from censored countries but also help everyone avoid the situation where some government inserts a rogue certificate into the CA system, potentially enabling the intelligence service of some country (Kenya, say) to "spoof" google.com to anyone anywhere. Can Tor Project reach out to ACLU, Amnesty, Human Rights Watch, and other groups to explain this and to help them set up onion site versions of the their public websites?

Anon

November 17, 2016

Permalink

Are there instructions for building without Google apps and without Signal (sorry I haven't RTFM yet)? I currently use Cyanogenmod without Google apps, I don't use Signal, and I don't want them on my phone. I hope the developers accommodate this use case :)

I completely agree with that sentiment but we must remember that this guide is for people just beginning to care about privacy and even though signal does have some shortcomings (GCM and phone numbers) it is the best trade off for security and convenience for the average person that isn't snowden. I know they aren't completely in the LIBRE/FLOSS movement but this a movement that calls for drastic change and frankly even minor change is a massive inconvenience for the average person so hopefully signal will be a gateway for people to care more about their privacy.
TLDR; Signal isn't perfect but it's way better for the common man than using google/standard unencrypted communication.

Anon

November 17, 2016

Permalink

Just a heads up to torproject and guardianproject that someone might want to check out the requests that orfox makes to mozilla's switchboard "experiments" telemetry program (switchboard.services.mozilla.com). Dont know of any documented config pref that can disable it, but these requests are made every time fennec (both mainline firefox and orfox) is opened. It would seem a good idea to prevent this and if there is no known way to disable it along with the other background experiments/telemetry requests specific to the fennec branch of firefox. Would be great if someone could work with mozilla on a pref to disable this to be included in a future build.

Given how much information firefox seems to collect on android by default, it would seem a good idea to take a close look at this.

Would you be willing to submit a bug report? That way it can be reviewed by the right people and tracked properly. You can use the "cipherpunks" username with pass "writecode" if you don't want to create an account. trac.torproject.org.

Anon

November 18, 2016

Permalink

Does Copperhead currently require a Linux machine to install or can it be done from Windows?

You can flash it from Windows with ADB/fastboot for Windows.
Make sure the computer you plug your new, clean ph9ne into is also clean though.
Windows is very dangerous. It's much safer to install from a computer that has IOMMU sandboxing like the user-friendly QubesOS which has a simple GUI and requires no terminal wizardry. This also makes it harder for the phone to infect the computer, if it's not a brand new phone never connected to the internet.

CopperheadOS itself can be installed from Windows. You need x86_64 Linux and 16GiB of memory to build it.

16GiB swap or 16GiB DDR{2,3,4,5}?

Great to see so much emphasis on software freedom here. Unfortunately, Copperhead OS is no longer free software which makes basing this entire project on top of Copperhead moot.

Source: https://twitter.com/CopperheadOS/status/781182820660183040

This entire project still applies, just use Replicant instead of CopperheadOS.

It's freer than Signal.
If you want to make a corporate branded version of CopperheadOS and sell commercial volumes of phones with it preinstalled, there are licensing fees now.

But the owner of Signal threatens to sue anyone who compiles Signal with the backdoor removed, even if you just use it under fair use(e.g. on your own phone, or give away the un-backdoor'd version for free)

Wow, I did not know this, thanks for sharing. All the more reason for motivated people to work on updating Replicant. It's a pity, CopperheadOS looked like they were doing good things.

Signal should be treated with extreme skepticism and caution.

- Signal uses proprietary VoIP servers. No good reason has been given for this, despite widespread curiosity both outside and within the Signal user-base.
- Moxie prefers passive-aggressive communication and non-cooperation with the free software community at large (see both the F-Droid and the LibreSignal incidents), instead preferring Google on everything, completely arbitrarily. Over 3 years ago they had legitimate reasons for not having TextSecure/RedPhone on F-Droid due to some security issues of theirs, but that was mitigated within months. They still refuse to branch outside of the Googlenet. Their recent Signal Desktop makes this seem like a consistent pattern, it's only released as a Chrome extension. Firefox doesn't get shit.
- Signal will also most likely never have Tor support.

Alternative spheres of activity that could topple Signal's dominance:
XMPP: ChatSecure (soon to get OMEMO, the XMPP port of Axolotl/Signal Protocol)
Matrix: Riot. Olm (a fork of Axolotl/Signal Protocol) is planned to be integrated into the Matrix protocol to allow E2E encryption by default. the Matrix project are also very Tor friendly it seems. They're talking about integrating onion routing into core functionality as well.
P2P: Tox, Ricochet (Ricochet uses parts of Tox's code, it can be said that Ricochet is Tox anonymized but without file-sharing features as of right now).

Thank you for articulating my thoughts. I can't believe I'm seeing the Tor Project endorse a product like Signal when we already have plenty of tried and true open standards out there that serve almost exactly the same purpose. I just don't see any reason for the Tor Project to endorse Signal, much less go out of their way to build it into their upcoming OS as the expense of freedom (from Google apps, namely).

Please, if there is any manpower leftover after the more important desktop work, could someone possibly make an official Orfox release for ESR 45.5 on F-Droid?
https://www.mozilla.org/en-US/security/advisories/mfsa2016-90/ drive-by code execution unless images disabled

I feel I'm preaching to the choir here.
Please, somebody tell me another place to warn people about the dangers of http://, EXPORT ciphers and Windows. Another place that will let me post without registering and without javascript. The word needs to get out or no progress towards safe computing can happen.

A good site to which to refer people you know might be:

https://www.theyarewatching.org/

(from ACLU of Washington).

How life has been going on with CloudFlare's captchas?

Cloudflare is a hell on mobile

Any guide on how to safely root or anyway take control of my personal own phone, is there any definity. I would really like to install something with things like vpn orwall and so on that allows me to decide what is mine and what is mine again. I don t wanna allow our life extraction. Big data are good but we need first to create the mentaloty economic and social values understanding to make big data a good thing. Today they want to extract them to target you and crush you or to keep consumersim and other stuff like patriarchalism and so on alive.

Please let me know if I can easily install a new OS on my phone thanks.

On almost any Android device you can be less UNsafe by downloading F-Droid at https://f-droid.org/ (you have to allow 3rd party .apk's sadly, but I think it's worth it).
Then enable the GuardianProject repository built in to F-Droid in the repositories menu.
Don't add any reposifories that aren't built in to it unless you jnow what you're doing.
After it reloads install the latest version of Orbot (if you don't enabke GuardianProject repo you'll get an outdated, unpatched, dangerous version of Orbot).
Goto F-Droid menu->options and set it to download everything through Tor from now on.
Then download Orfox and whatever else, through F-Droid.
Goto your apps list (varies from phone to phone) and disable and/or uninstall everything from Google, and everything that you installed through Google Play Store.
Make sure to get replacements in F-Droid. For example, before removing Google Keyboard search for "keyboard" in F-Droid and get one of the ones there. Everything in F-Droid is free as in speech, open source software without any tracking (or it has a big warning before you install it if there is tracking).
If you aren't rooted get NetGuard, a free no-root firewall.

The above is the same on a rooted device except that if rooted, you can get F-Droid Privileged Extension WHICH MEANS YOU DON'T HAVE TO ENABLE INSTALLATION FROM UNKNOWN SOURCES. This is one way rooting makes it more secure.
You can configure in F-Droid->options to show which apps need root. Orwall and AFWall+ are better than NetGuard but you only get them if you have root.

Exposed is a framework that needs root to install, and once installed it keeps working even if the root was only "temporary". Once you have Xposed framework you can get Xposed Privacy, which lets you have way better control over app permissions than the permission manager in Marshamallow/Nougat. Lollipop and earlier come with no permission manager at all.

How to root varies from device. Search for your device's model ID plus the word "root" or plus the word "xda".

Very few devices were meant to be rooted officially. UNOFFICIAL METHODS CAN SEEM TO WORK PERFECT BUT MIGHT MAKE IT EASY FOR GOVERNMENT OR EVEN RANDOM STREET HACKERS TO ACCESS YOUR DATA.

For installing another operating system, it is similar, but search device ID plus "bootloader" or plus "unlock bootloader" instead. The new OS is called a "rom". Only install CopperheadOS or Replicant roms. If you really insist on a custom rom and those two don't support your device, maybe try OmniRom of ParanoidAndroid, but it's a really bad idea, and CyanogenMod is probably worse.
If there is no official directions from ghe manufacturer of your phone THEN IT IS VERY DANGEROUS TO UNLOCK BOOTLOADER.
At the very least make sure all the adb/fastboot tools and the rom itself is downloaded by links starting with https://
Please look up how to verify signatures. This is very important. Same when downloading operating system for a coomputer e.g. QubesOS.
Consult device manuals and FAQs of large, well-known projects for more info. Be careful and stay safe.

Rooting/rom'ing the safest is if you has the Google Nexus, Google Pixel, or certain kind of Galaxy and certain HTC and certain Samsung. Researching a phone before buying it. Also trying not to buying used unless no other choice, since used phone's may have undetectable and unremovable spyware virus infection.
Never using .exe or .bat downloaded by the plain http://. https:// less dangerous than http://! Also try ask whoever you download from, ask them how verify signature!

Is project BULLRUN limited to mobile devices and desktops or does it apply to self-driving automobiles like the hazardous material transport in Diehard4? Is BULLRUN being applied to the 787 Dreamliner or Airbus C350? Will the NSA make it so we see more airplanes flying into buildings? What about the three mile accident? Was it an accident or did BULLRUN make it easy for terrorists to make their own STUXNET-like nuclear-reactor-targetting malware? Isn't it treason for any US agency to sabotage US national security by going out of their way to make insecure algorithms like the dual-EC one into national (NIST) standards that critical US infrastructure depends on? In short; is NSA allied to ISIS and/or allied to al-queda?

>>It would be useful to audit whether airplane mode fully disables the baseband using either OpenBTS, OsmocommBB, or a custom hardware monitoring device.<<

Note that neither could detect a more sophisticated rogue behavior of the modem, since even an active and listening-for-commands modem is generally not detectable by any of those means. They all would only yell when an unsolicited TX actually happens and then it's basically too late since none could stop that threat. A modem with specially crafted firmware could pretend to be off (airplane mode) even on RF/antenna and still record all audio to modem-internal storage, to sneak it out interleaved with normal traffic on next solicited/expected activity like doing a call or simply just ending airplane mode.

Since all modems nowadays allow OTA firmware update, no software audit of the firmware whatsoever will accomplish anything, the only approach is to get decent HARDware. Even the mandated by FSF/RYF "immutable firmware" is a red herring since firmware gets loaded to modem's RAM before executing it, so that image in RAM still can get modified OTA even if the modem would use ROM instead flash for storage.

/jOERG (Neo900)

Are you saying the only way of detecting viruses is measuring power draw from the baseband?

There can be no real security until some of the underlying binary blob and baseband isolation issues can be solved. There has been work to this end that I'd highly encourage you to check out.

We have the complete set of source code needed to utilize all critical functionality for the Allwinner A20 SOC. This is an older dual-core 2GB ram SOC although still more than adequate for a phone. There is a newer quad-core 1.6ghz processor with 4gb RAM SOC that appears to also be an option. Now this does not include full support for 3D acceleration although I know at least the Allwinner A20 does have usable desktop and video acceleration (it is being used in a laptop/desktop system with adequate desktop performance). The quad-core apparently should be much better and solve the 3D problem.

Now there is a project that has successfully designed, demo'd, and crowd funded a 100% free laptop and desktop and of which its work can be utilized to make a phone cost effective and feasible. The reason is standards. The main objective of the project was to cut the costs of designing and manufacturing devices via the development of a modular computing standard: EOMA68 is essentially a critical building block needed to develop and manufacture devices cost effectively in lower than typically needed quantities. The people and main financier behind EOMA68 have an agenda of enabling development of devices not dependent on any proprietary components. We're talking 100% free here. No modern laptop or desktop is 100% free right now- not even Minifree's Libreboot'd laptops. There are keyboard controller firmwares, hard disk firmwares, LCD controller firmwares, and similar that are all proprietary. EOMA68 is the interface standard and from that 'computer cards' manufactured to this standard will be compatible with any device that complies with the EOMA68 interface standard.

The first 100% free laptop, desktop, and EOMA68 computer card was designed thanks to funding from ThinkPenguin (a true free software friendly GNU/Linux hardware company) and a crowd funding campaign (http://crowdsupply.com/eoma68). The systems will be shipping in March.

Phones, tablets, and other devices are planned. If you are interested in getting behind a realistic cost effective effort to design a phone I'd get in touch with Luke (the lead guy of the standard). Everything is being published for these first devices in addition to the EOMA68 standard itself. A phone may require a slightly different modular computing standard than EOMA68 for the sake of keeping the size of the device small enough to be useful, but a basic smart phone is possible. It does limit the SOCs a bit further too, but ultimately this is the answer to the problems posed here. We do not necessarily need to build off Android and we do not necessarily need to depend on phones designed by those who do not care about privacy and security. We also can bring the costs of a privacy and security friendly phone down via modular standards. It's not the case that such projects have to flop or be insanely expensive (ie like Neo FreeRunner).

Asking here since this seems the most likely place to post something and have NSA read and reply to it (and possibly some operative might have enough freedom to answer honestly if he believes his organization is doing something bad to America); Is project BULLRUN limited to mobile devices and desktops or does it apply to self-driving automobiles like the hazardous material transport in Diehard4? Is BULLRUN being applied to the 787 Dreamliner or Airbus 350? Will the NSA make it so we see more airplanes flying into buildings? What about the three mile accident? Was it an accident or did BULLRUN make it easy for terrorists to make their own STUXNET-like nuclear-reactor-targetting malware? Isn't it treason for any US agency to sabotage US national security by going out of their way to put insecure algorithms like dual-EC into national (NIST) standards that critical US infrastructure depends on? In short; is NSA helping (on purpose or by mistake) ISIS more than it's hurting them? How many actual bombings that were stopped couldn't have been stopped without the PATRIOT Act? How many that were allowed to happen were allowed because of government screwups rather than due to not enough mass surveillence?
Is decreasing everyone's security really making America safer?
More on topic; how many people needed to use their smartphones in life-threatening situations, such as to call 911, and were unable to because of malware that messed up their phones, malware that wouldn't have been able to ir security weren't being deliberately under ined by those paid to protect it?

Hey Mike, the Tor blog could show up revisions history (for example https://blog.torproject.org/node/280/revisions) why is this not available here?

Signal died (https://github.com/LibreSignal/LibreSignal/issues/42), which is good because its owner, moxie0, threatened to sue anyone who dared to remove the backdoor from it. Moxie0 is with facebook, whatsapp, and big data harvesters in general (think NSA/GCHQ/PLA/BND).

Anon

November 23, 2016

In reply to by Anonymous (not verified)

Permalink

> [Signal's] owner, moxie0, threatened to sue anyone who dared to remove the backdoor from it. Moxie0 is with facebook, whatsapp, and big data harvesters in general (think NSA/GCHQ/PLA/BND).

That is a pretty inflammatory claim. Do you have any evidence to offer for any of this?

My understanding is that Moxie is employed by the company which owns Signal. I don't know whether he is also the owner of that company, and I haven't heard about him threatening anyone with anything. My understanding is that his reputation among people fighting the dragnet is generally excellent.

It is true that the Snowden leaks include a number of documents showing that NSA/GCHQ have attempted to introduce various things which could reasonably be described as "backdoors" in various places in critical internet infrastructure (e.g. tapping directly into the unencrypted "private" data cables between Google's many servers, secretly disabling firewalls in commercial telecom switches, munging the PRNG in NIST standards, etc.).

But other published documents from the Snowden trove show that (despite Roger's past temporary affiliation) Tor Project was *not* cooperating with NSA, and that NSA/GCHQ were having much difficulty attacking Tails as of roughly spring 2013. Tha situation may have changed since then, to be sure.

Snowden also gave us the NSA/GCHQ playbook for "disruption" of groups they target, and other documents show that the target list for "effects" campaigns includes the Tor community. The playbook suggests short repetitive posts exploiting pre-existing fears in some community (e.g. Tor users have good reason to fear NSA trickery including backdoors) which never attempt to provide any specific "evidence" (even disinformative "evidence"). So you have a high bar to overcome if you want to convince us that Moxie is a bad'un.

We need technical countermeasures simply in order to express our support for the political opposition, or to stay in touch with nonpartisan civil rights groups like ACLU:

https://www.aclu.org/blog/speak-freely/president-obama-will-soon-turn-o…
President Obama Will Soon Turn Over the Keys to the Surveillance State to President-Elect Trump
Ashley Gorski, Staff Attorney, ACLU National Security Project
Patrick Toomey, Staff Attorney, ACLU National Security Project
21 Nov 2016

> On January 20, President Obama will hand Donald Trump the keys to the surveillance state. Not only will Trump have the NSA’s incredibly powerful technological tools at his disposal, but he’ll also have the benefit of the overbroad and unconstitutional surveillance authorities embraced by the Obama administration — authorities that give tremendous discretion to executive branch officials.
>
> These spying powers have long been cause for concern because they violate our core rights to privacy, freedom of expression, and freedom of association. But when wielded by a man who invited Russia to hack his political opponent, who reportedly eavesdropped on his own hotel guests, and who has called for expanded surveillance of Americans and especially American Muslims, they are all the more frightening. Fortunately, there are several ways to fight back against the surveillance state, including concrete steps you can take to protect yourself and your communications.

CopperheadOS sounds like a nice project, but according to its website, it's non-free: "CopperheadOS source code and builds are made available under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license".

This means it's neither open source nor free software, as it bears restrictions of use (non-commercial), violating Free Software's essential freedom of unrestricted use.

While the project sounds great and is certainly better than a project the source of which is not shared at all, this is still not the full open source OS we need.

Maybe the Tor project, given its enormous recognition value and reputation for helping good causes, could guide the Copperhead team to release their project under a Free and open source license?

They did this to have the option to dual license their changes to commercial companies who might want to repackage and sell Copperhead. I think this is fine (though CC-NC-SA might not be the best choice for software...)

I believe the most important thing, as I said in the introduction, is that the Four Freedoms are honored. Above all else, users should be free to use, share, study, and improve the software they have. Selling that software to others is a different matter, though. For that, I feel that it is entirely reasonable to restrict commercial activity, to ensure that if someone wants to profit from your work by charging others for it, they must pay you too, or at least arrange a license from you that grants them permission to do this.

Obviously, this behavior fails in the Kantian sense. If every free software package did this, we would not have Ubuntu or Red Hat, since selling DVDs would become a nightmare. However, a project like Copperhead that is trying the impossible and has a lot of predators looking profit off their work for free deserves a little more leeway.

In general, I think it is time to revisit out FLOSS licenses. In addition to Android, the Internet of Shit is another nightmare of a cesspool where companies are taking free software, selling it, and not even providing updates, leaving users vulnerable. For cases like this, I believe it is entirely legitimate to forbid the redistribution of binary forms of the software, unless automatic security updates are provided.

"Exterminate All Dogma; Permit No Exceptions."

> Above all else, users should be free to use, share, study, and improve the software they have. Selling that software to others is a different matter, though. For that, I feel that it is entirely reasonable to restrict commercial activity

All commercial activity, or just selling copies of the software? Prohibiting people from hiring programmers to improve the software would effectively disenfranchise those who can't program. Similarly, if people can't pay a computer-shop employee to flash an image for them, many won't be able to use it. (Plus it could make the whole idea of modifying/copying the software seem "shady".)

If we were really going to accept such restrictions, we'd need some solution to the problem of orphaned works too. If the company that wrote the software goes under (or are nominally extant but stuck in some sort of "development hell"), we can't just wait 130 years for the copyright to expire.

I definitely respect your arguments.

Looking at existing cases, lots of device manufacturers avoid the GPL. Maybe making relevant parts of Copperhead GPL (perhaps dual-licensed with a proprietary license) could ultimately have the same effect.

Also, I am not aware of any device manufacturers just using Cyanogenmod, which is arguably superior to AOSP in many regards, without cooperating with established Cyanogenmod bodies. So their fear may be purely hypothetical and ultimately unnecessary.

I really hope they change their minds. That doesn't mean I don't think their efforts are laudable.

Well, that's at least partly the fault of Linus and the Linux Foundation. Had Linux moved on to the GPL v3 and would start to enforce that drivers that are derived from their code and than linked with the kernel had to be under the GPL and would their by be accessible to the user -- it would be much easier to update the devices. (But of course, would Linus be a good Stallmanist and not a deviationist, google hadn't chosen Linux as their kernel of choice)

Does anyone know whether it would be possible to create an MVNO providing anonymous access to the mobile network? Obviously we have the technology to anonymously route calls (cell tower ≅ entry node). We also know how to do anonymous billing (cf. "Untraceable Nym Creation on the Freedom 2.0 Network", "Blind signatures for untraceable payments"). Are the protocols flexible enough that a SIM could generate a new IMSI for every authentication and attach a zero-knowledge proof of payment that the MVNO could accept/reject?

Hooray! A nice write-up just appeared in Ars:

http://arstechnica.com/security/2016/11/tor-phone-prototype-google-host…
Tor phone is antidote to Google “hostility” over Android, says developer
An Android phone hardened for privacy and security that plays Google at its own game.
J.M. Porup (UK) -
22 Nov 2016

> The Tor Project recently announced the release of its prototype for a Tor-enabled smartphone—an Android phone beefed up with privacy and security in mind, and intended as equal parts opsec kung fu and a gauntlet to Google. The new phone, designed by Tor developer Mike Perry, is based on Copperhead OS, the hardened Android distribution profiled first by Ars earlier this year.

This thing needs a name. Cottonmouth? No, NSA already took that for a bit of spyware. Ideas?

How about VeganBreath or IrateOnion? CurvedAcid? FrontSnarf? OnionShooter? korG? UnitedOnion? OnionBazarre? OnionVicar? SlickerVeggies?

Abandoning the poisonous snake theme, how about "Colloquy"?

Great work guys!

There is another currently unmentioned "Future Work" point which is hardware modifications.

CopperheadOS supports only very few devices. This should allow us to work out detailed guides how to identify and physically remove or disable various build-in sensors and interfaces and propose additional modifications. I researched the LG Nexus 5X and was only able to identify some of the components of interest. My idea behind this is to have an encrypted and to some extend secure computer to carry around which still has restricted sensors/interfaces which could be turned against the user.

I think the following components could be of interest here:

  • microphones
    Risk/problem: Acoustical collection, potential passphrase or key leaks thought various side channels, various user monitoring.
    Caveats: This would require a workaround such as always carrying a headset with you if the device should still be used as phone. Hint, there are cables like "3,5mm Klinken Verlängerung 30cm" which can be used to block the mic of the headset if you only want to listen to something.
    Realization: Can be identified on the PCB easily and also as there are holes in the cover for them.
    Impact on the user: High
  • cameras and laser autofocus
    Risk/problem: Visual collection, potential passphrase leaks though various side channels, various user monitoring and reflections in objects like eyeballs and all that good stuff.
    Realization: Easily doable with a tape which is also very convenient if you still want to use the camera sometimes.
    Impact on the user: Medium
  • gyros, accelerometers
    Risk/problem: Potential passphrase leaks thought keyboard side channels, various user monitoring.
    Realization: I was not able to identify the ICs yet which implement this for the Nexus devices. Any help is appreciated.
    Caveats: Screen rotation will not work anymore.
    Impact on the user: Low
  • light sensor
    Risk/problem: Monitoring of device surroundings/environment. Various user monitoring.
    Realization: I was not able to identify the location of this sensor yet in the Nexus devices. Any help is appreciated.
    Caveats: Screen light adaption will not work anymore.
    Impact on the user: Low
  • proximity sensor
    Risk/problem: Monitoring of device surroundings/environment. Various user monitoring.
    Realization: Near the two microphones on the top according to https://www.youtube.com/watch?v=lhAFtP0F2Uk
    Caveats: If the device is still used as regular phone, the display will not look nor turn of if used to make a call.
    Impact on the user: Low
  • barometer
    Risk/problem: Monitoring of device surroundings/environment. Various user monitoring.
    Realization: Do the Nexus devices have one, if yes, where? Any help is appreciated.
  • fingerprint reader
    Risk/problem: If used (on purpose or not), biometric identifiable data of the user might be revealed.
    Realization: Easy to spot and remove. Only basic tools are required (screw driver and case opening).
    Impact on the user: Medium
  • baseband, WWAN RF
    Risk/problem: Baseband exploits, remote control over the phone.
    Realization: Remove antennas, RF amplifiers and all that stuff. Kill switches? Any help is appreciated.
    Impact on the user: Medium
  • WLAN, Bluetooth
    Risk/problem: Nearby RFID reading, potential other malicious uses.
    Realization: Remove antennas. I was not able to identify the ICs yet which implement this for the Nexus devices. Kill switches? Any help is appreciated.
    Impact on the user: High
  • NFC
    Risk/problem: Nearby RFID reading, potential other malicious uses.
    Realization: Remove antennas and NXP PN548 NFC Controller (SMD).
    Impact on the user: Low
  • GPS
    Risk/problem: Location anonymity if phone gets compromised, potential other malicious uses.
    Realization: Remove antennas. I was not able to identify the ICs yet which implement this for the Nexus devices. Kill switches? Any help is appreciated.
    Caveats: No practical navigation anymore.
    Impact on the user: Medium
  • compass
    Risk/problem: Various user monitoring.
    Realization: I was not able to identify the ICs yet which implement this for the Nexus devices. Any help is appreciated.
    Caveats: If not moving, navigation map can not be oriented.
    Impact on the user: Low
  • earpiece speaker, loud speaker
    Risk/problem: Potential acoustical collection, covert channel communication.
    Caveats: Limited user notification except vibration motor and LED light.
    Realization: Easy to spot and remove. Only basic tools are required (screw driver and case opening).
    Impact on the user: High
  • Add battery switch
    Risk/problem: To ensure that the device is really turned of.
    Realization: The battery is "not replaceable" and does not have durable connectors. Any help is appreciated.
    Impact on the user: Low
  • Add device monitoring (power analysis, RF activity, camera/sensor activity)
    Risk/problem: Allow the user to monitor what the device actually does.
    Realization: Anything practical in this regard?
    Impact on the user: High

Every user can make there own judgment what components they want to have and what are unneeded. Also, this is more of a defense in depth as CopperheadOS tries to avoid/mitigate exploitation in the first place. But why take unnecessary risks?

Resources:

Previous work: https://archive.fo/dbolo

Nice work--- I like the way you think! :)

Hopefully Gooligan won't work against "Mike's phone" aka Colloquy, but this story indicates both the challanges we face and the reasons why we need smarter phones:

http://arstechnica.com/security/2016/11/1-million-android-accounts-comp…
1 million Google accounts compromised by Android malware called Gooligan
86 apps available in third-party marketplaces can root 74 percent of Android phones.
Dan Goodin
30 Nov 2016

> Researchers say they've uncovered a family of Android-based malware that has compromised more than 1 million Google accounts, hundreds of them associated with enterprise users. Gooligan, as researchers from security firm Check Point Software Technologies have dubbed the malware, has been found in at least 86 apps available in third-party marketplaces. Once installed, it uses a process known as rooting to gain highly privileged system access to devices running version 4 (Ice Cream Sandwich, Jelly Bean, and KitKat) and version 5 (Lollipop) of Google's Android operating system. Together, the vulnerable versions account for about 74 percent of users.

Really nice work. I honestly think that CopperheadOS should release a phone or tablet similar to the Nexus/pixel series but with hardware switches sometime in the future.

I was looking librem phone (At this point, non-existent phone) discussion but they don't support OpenGapps or Microg. I understand their desire but what a bummer. Maybe Copperhead may try to port their OS to that theoretical phone in the future? Who know what will happen next.

Did you see that the latest Signal version 3.23.0 has gained push-to-talk support? Torifiable mobile voice communication! Over and out.