Majic

The first smart phone I got was back in October of 2011, a venerable Samsung Nexus S. Since then I had a chance to go through a couple of other phones, picking them based on whether they can run now defunct CyanogenMod ROM. I have stuck to Nexus phones for quite a long time due to this.

(as a side-note, I can only hope that LineageOS will pick up after death of CyanogenMod).

In my last incarnation, I started using a Motorola Moto G 2014.

The decision to pick this device can be summarised with the following requirements:

• It should be cheap. I'm tired of buying expensive phones that do not get proper security updates, and that are supported for just two years. I want to be able to "throw away" the phone without weeping for the money I spent on it.
• It should be possible to easily unlock it in order to run custom ROMs. I have come to enojoy the UI of CyanogenMod. Very often it had those little tweaks that mean a lot to me compared to stock firmware. Plus I run apps from F-Droid only anyway, so no need for Google play or what-not. This also provides a way to keep old devices running for longer time due to extended support provided by community, once vendor has decided to stop patching the firmware.

Once I got the phone (or more precisely, once I finally got around to setting it up), I decided to improve the process I used so far and treat it as part of my infrastructure. Although using Ansible for setting it up is not an option, I can at least have all the necessary procedures documented.

The idea was to cover the following:

• Installing from scratch.
• Enabling encryption.
• Updating firmware.
• Backing-up the phone data and settings
• Restoring the phone data and settings.

Installation from scratch was relatively easy process. I had to get an unlock code from Motorola, which also voided my warranty (therefore another reason to buy a cheap phone). After this I was able to flash TWRP, and subsequently CyanogenMod.

One of the issues I had was that TWRP at first (when I got the phone) could not decrypt the phone at all. This was luckily fixed at some point, so I could easily access encrypted data through it. This is important when you decided to encrypt the SD card, and still want to be able to update the firmware on the phone (you can read the updated from encrypted partition).

After the installation was done, it was time for encryption. This was a fairly straightforward process, but... There is a lot to be desired in terms of features. It is year 2017, and security of Android phones has not improved much. Here is a nice overview of issues I have with it:

• Bootloader is protected as long as you do not unlock the phone. This protection, of course, depends on how good the vendor has implemented it, and whether they provide patches. As is known to most people, jailbreaking has become a common way to "unlock" Android phones. So much for that part.
• Once the bootloader has been unlocked, there is no way to protect it yourself. Although TWRP could implement password protection, it would be useless since once the phone is unlocked you can easily just replace the bootloader with anything you want. At this point, even though Android has started storing encryption keys in hardware (i.e. it is not just a file on the device), it is not worth much since someone would be able to boot a custom system to steal your password for purposes of unlocking the device (and, well, access everything you have using their own image).
• Enabling encryption in Android (CyanogenMod to be more specific) will only make sure the data partitions are encrypted. The system partition is not encrypted, and can easily be flashed with another system. Theoretically, someone could steal your phone, replace the system with their own, and then return the phone to you. You'd be none the wiser if this is done within short time. The core issue still lies within (lack of) bootloader protection, though.
• Android has unfortunately killed most of the userspace evolution in GNU/Linux. This means a lot of custom tools and layout, including... Handling of encryption. Good luck trying to decrypt data using standard tools, not to mention that even if you manage to get some kind of shell on device, there are no native CLI tools for trying to mount the data. Proivided all works fine, you will never needs this. But if you need to debug why decryption fails (like I tried to with TWRP), you will have to do some custom coding and building.
• It is not possible to separate the encryption password from PIN entry (for unlocking the phone) using built-in GUI. Luckily, at least it can be done using adb...
• Due to Android leaving it up to vendors to decide on how to handle key material, very strange exploits are possible, including ability to extract the damn encryption key from "hardware". I.e. like in case of Qualcomm SOCs. Awesome.

With that out of the picture, let's have a look at backup and restore. To put it short, backup and restore on Android sucks. Big time. Here's list of issues I had:

• Unless you are running vendor-provided firmware, there is no built-in user friendly functionality (through menu) for device backup and restore. Yes, it is 2017 already, and stock Android has no proper system for backing-up the entire phone and restoring it. If you are using Google services, that is the only thing you can backup for sure. Which kind of makes sense, I guess. Google does want you to store all your data with them, and use their services for everything anyway. Eventually you could opt using some of the proprietary apps available out there. For me this is a no go since I do not want to use proprietary apps.
• If you enable debug mode (sic), and install Android platform tools, you should be able to run backup/restore from CLI. I write should, since I had only partial success with this. The process was super slow, and I could not restore everything (good luck figuring out the correct arguments to use).
• Luckily, with TWRP finally being able to decrypt the phone, you can perform backup/restore from within it. Except... It will not backup your data and the SD card. The SD card which you have set-up to be used as internal storage so you can pack more apps and applications on your device... In other words, you get at best backup of most settings and that's all. So you still need to backup the data through other means.
• Ok, but at least you can use TWRP through adb (the Android platform tools) to log-in into the system and create an archive of anything that TWRP itself does not include in backups. Luckily, TWRP does come with the tar util. Except... You can't use traditional GNU/Linux piping with Android adb shell command. So you need to put the archive on device itself (or use a workaround involving netcat... shudder). And then, after going through all the hoops, while testing the restore procedure you find out that... tar included in TWRP can't handle files bigger than 2GB. Yes, you heard that well. The one included in Android system itself, can. So a couple of mounts (on the phone) later and some tweaking of LD_LIBRARY_PATH, and you can finally restore the phone data.

This is not the least of my annoyances, though. Here and there you may need to switch phones. I have not tested whether a backup from one phone (at least data/settings) and restore on another works. I do remain skeptical given the previous listings from this post. Because of this I decided to go down the route of exploring how to backup and restore individual applications instead. Here's the list again:

• Some applications can backup and restore settings, some can't. Depends on the app.
• Some applciations can backup and restore data, some can't. Again, depends on the specific app you are using.
• Some applications may store data in obscure locations, making it harder to get to them.
• Some applications may be able to backup, but not restore data or settings.
• Some applications may support backup of data or settings, but it is annoying as hell. For example, I had this note-taking application that could backup the notes, but... One by one. Yeah, that application got replaced.
• When backing-up and restoring, each application has its own procedure, storage location etc. And it can be rather counter-intuitive.
• Some apps have very ugly bugs related to backup/restore. Since each app implements this on their own from scratch.

So there you have it. Smart phones in 2017.

Mind you, this whole post is concentrating on Android, and specifically on CyanogenMod. I do think the same thing would apply to stock Android system too (not to be confused with vendor derivates).

Finally, to add salt to the wound, Apple has actually managed to provide their users with out-of-the-box backup and restore functionality (encryption too), and this has been done long time ago. You are entrusting your data to the devil in that case, but at least they realised they need to make this process as user-friendly as possible