Locked and Unlocked Android Boot Loaders

Generally speaking, locked boot loaders prevent the end user from performing modifications to the device’s firmware by implementing restrictions at the boot loader level. Those restrictions can vary, depending on the manufacturer’s decision, but usually there is a cryptographic signature verification that prevents booting and/or flashing unsigned code to the device. Some devices, such as cheap Chinese Android devices, do not include any boot loader restrictions. Knowing the difference about locked and unlocked android boot loaders is important. Especially when you want to tweak the boot or root an android devices.

On Google Nexus devices, the boot loader is locked by default. However, there’s an official mechanism in place that enables owners to unlock it. If the end user decides to run a custom kernel, recovery image, or operating system image, the boot loader needs to be unlocked first. For these devices, unlocking the boot loader is as simple as putting the device into fastboot mode and running the command fastboot oem unlock. This requires the command-line fastboot client utility, which is available in the Android SDK or the AOSP repository.

Some manufacturers also support unlocking the boot loaders on their devices, on a per-device basis. In some cases the process uses the standard Original Equipment Manufacturer (OEM) unlock procedure through fastboot. However, some cases revolve around some proprietary mechanism such as a website or unlock portal. These portals usually require the owner to register his device, and forfeit his warranty, to be able to unlock its boot loader. As of this writing, HTC, Motorola, and Sony support unlocking at least some of their devices.

Unlocking the boot loader carries serious security implications. If the device is lost or stolen, all data on it can be recovered by an attacker simply by uploading a custom Android boot image or flashing a custom recovery image. After doing so, the attacker has full access to the data contained on the device’s partitions. This includes Google accounts, documents, contacts, stored passwords, application data, camera pictures, and more. Because of this, a factory data reset is performed on the phone when unlocking a locked boot loader. This ensures all the end user’s data are erased and the attacker should not be able to access it.

We highly recommended using Android device encryption. Even after all data has been erased, it is possible to forensically recover erased data on some devices.

Stock and Custom Recovery Image

The Android recovery system is Android’s standard mechanism that allows software updates to replace the entirety of the system software preinstalled on the device without wiping user data. It is mainly used to apply updates downloaded manually or Over-the-Air (OTA). Such updates are applied offline after a reboot. In addition to applying OTA updates, the recovery can perform other tasks such as wiping the user data and cache partitions.

The recovery image is stored on the recovery partition, and consists of a minimal Linux image with a simple user interface controlled by hardware buttons. The stock Android recovery is intentionally very limited in functionality. It does the minimal things necessary to comply with the Android Compatibility Definitions at http://source.android.com/compatibility/index.html.

Similar to accessing download mode, you access the recovery by pressing a certain key-press combination when booting the device. In addition to using key-presses, it is possible to instruct a booted Android system to reboot into recovery mode through the command adb reboot recovery. The commandline Android Debug Bridge (ADB) tool is available as part of the Android SDK or AOSP repository at http://developer.android.com/sdk/index.html.

One of the most commonly used features of the recovery is to apply an update package. Such a package consists of a zip file containing a set of files to be copied to the device, some metadata, and an updater script. This updater script tells the Android recovery which operations to perform on the device to apply the update modifications. This could include mounting the system partition, making sure the device and operating system versions match with the one the update package was created for, verifying SHA1 hashes of the system files that are going to be replaced, and so on. Updates are cryptographically signed using an RSA private key. The recovery verifies the signature using the corresponding public key prior to applying the update. This ensures only authenticated updates can be applied. The following snippet shows the contents of a typical Over-the-Air (OTA) update package.

Extracting an OTA Update Package for Nexus 4

Custom Android recovery images exist for most devices. If one is not available, you can easily create it by applying custom modifications to the stock Android recovery source code from the AOSP repository.

The most common modifications included in custom recovery images are

■ Including a full backup and restore functionality (such as NANDroid script)

■ Allow unsigned update packages, or allow signed packages with custom keys

■ Selectively mounting device partitions or SD card

■ Provide USB mass storage access to SD card or data partitions

■ Provide full ADB access, with the ADB daemon running as root

■ Include a fully featured BusyBox binary

Popular custom recovery images with builds for multiple devices are ClockworkMod recovery or TeamWin Recovery Project (TWRP). Image below  shows stock and ClockworkMod recovery screens.

Android recovery and ClockworkMod Recovery

Keeping a custom recovery image with signature restrictions removed, or full ADB access exposed, on your Android device also leaves an open door to obtaining all user data contained on the device’s partitions.