Attacking Android through custom updates

…or Why it’s a bad idea to root your phone

I’ve been messing around with this technique recently to allow me to gain access to data on Android when I don’t have access to the OS.

It’s a very useful technique which can allow the reading of data, the installation of packages or just the removal of passwords.

First some restrictions and caveats:

1. This technique will only work with a custom recovery partition, as the stock Android recovery partition requires that the updates are signed with a valid update.
2. There is a fair bit of munging for specific hardware and versions of the recovery partition in place. I set mine up for a Nexus 4, because it was what I had hanging around. Other platforms will need tuning.

For this, number 1 is the most restrictive; this means that you can only use this technique on a device that has been OEM unlocked (so you can upload a custom recovery partition to it) or already has a custom recovery partition (such as TWRP) which implies that it has already been rooted.

This situation is uncommon, but not rare.

Before we start: Different boot levels

I’m going to be bouncing around the different boot levels on standard Android, so here are some quick words to explain this in a bit more depth. An Android device can run with multiple different flavours of controlling program, all of which have various mechanisms to access. For stock Android on a Nexus device we have:

1. The powered off power charging animation. This is a very primitive version of Android that just displays the animation. On some other hardware, such as Rockchip, this may allow adb access.
2. Fastboot. This is the basic bootloader level and is similar to the BIOS on your PC. It allows the updating of the device’s storage at a very low level. Other hardware will have its own versions (e.g. Odin on Samsung) some of these, such as the MediaTek and Rockchip bootloaders even allow reading of stored data.
3. Recovery. This is a relatively small management partition that is designed to allow access to storage at a moderately high level. This is used by Android to update itself with OTA (over the air) updates.
4. Android. The full Android operating system.

Most of the stuff I’m talking about in this article is referring to the recovery partition. Often a replacement recovery partition is flashed up when rooting or changing) the Android operating system (e.g. installing Clockwork Mod).

Attacking through the recovery partition

The recovery shell has multiple purposes, but its main use is to provide a basic partition to allow Android to perform updates on file systems that are normally read only (such as /system) or run from a RAM disk (such as /).

These processes are normally managed by the operating systems, which copies the raw files to the cache partition and then invokes a reboot to the recovery partition which does the actual upgrade. But, and it’s a big “but”, there’s a facility called “side-loading” where a custom package can be run by the recovery shell. This is normally how a phone is rooted.

This isn’t normally an issue with a standard recovery partition as the recovery shell requires that the package is signed by a trusted authority (such as Google, or the hardware manufacturer), but if the phone has been rooted then this restriction needs to be bypassed and the quickest mechanism to bypass is to install an alternative recover shell which doesn’t required signed packages, such as TWRP.

So, if we’ve found a physical device with TWRP installed, but a lock screen in place, can we unlock it? Well yeah, otherwise this would be a short article.

Building a custom update package

So, what happens when an update package is passed? Not much really, the update is passed in a zip file, which is extract and then, as we can see from the source code the binary META-INF/com/google/android/update-binary is run:

So, in theory all we need to do is to make our own binary, compile it and do whatever we want. This can be quite complex as the recovery shell is quite empty so we’d have to do a lot ourselves.

There’s a solution here, to use what the Android OTA process uses: a basic interpreter called edify, which is a simple scripting language, whose syntax can be found on the Android developer site.

As we just want to remove the lock screen, the script is very simple:

This basically mounts the standard Android file systems and then just removes the password hash file (see my earlier article) for more details on this.

We saved our script as installer-script and now we can make our package by putting together a pre-built version of edify with our script and zip it all up:

The other files are standard files that are required but have just been copied from another update package. These files can be created by signapk if needed.

Installing It

We have our updater file, and a Nexus 4 which is locked and running TWRP, so how do we gain access to it. We first need to boot into recovery mode, which is quite easy to do:

1. Hard power down the device by holding down the power button for 10 seconds
2. Press and hold down the volume down button
3. Whilst holding volume down press the power button and hold it until you get the bootloader screen (it has the Android with its front open and the big word “start”)
4. Press volume down twice until it says “Recovery mode” and then press the power button
5. At this point it should boot into TWRP

From here, unlocked the screen, tap “Advanced” and then select “ADB Sideload” and swipe to activate it. It should be noted that you can also put the zip file on an SD-Card, if your phone supports SD-Cards.

ADB sideload is a cut down version of ADB that only allows sideloading. Connect your device to your computer and run:

And it should apply it with no errors. The final step is to tap “Reboot System” to reboot the phone into Android.

Once it has rebooted it now no longer has a passcode and we can do what we want to it! As they say in computer games: pwned!

Conclusion

This isn’t really describing a vulnerability – it’s more a technique that is sort of required to do stuff like rooting your phone, but as a side effect it will allow somebody to gain access to your phone.

It does require that the phone is either OEM unlocked or that it has already had a new recovery partition flashed, so won’t have an effect on 90% of phones around.

In closing I’ll just repeat my usual advice: do not root your personal phone.