Imaging Locked Motorola Devices Via Bootloader Exploit

Last-generation Android devices are gradually getting more secure, even approaching iOS-grade security in some usage scenarios. Equipped with fingerprint readers and compulsory encryption of the data partition, Android smartphones became a much tougher acquisition target compared to just a couple of years ago. In this world of increasing security, security firms go out of their way to discover usable techniques for imaging such devices. In this article, we will discuss the latest technique allowing experts to perform bootloader-level imaging and decryption of 2015, 2016 and 2017 Motorola models running Android 5.0 through 7.0.

Bootloader Lock

Before we go on to the new acquisition method, let us first have a look at Android data protection mechanisms. In this article, we’ll concentrate on three things: bootloader lock, encryption, and passcode. Let’s start with bootloader.
In literal terms, bootloader is executable code that loads before the OS. It is this code that chooses a boot partition and hands control to either the regular boot image or the boot image in the recovery partition. Bootloader is also responsible for establishing fastboot connection and executing any fastboot commands.

In normal OS operation, the bootloader packages instructions to boot the operating system kernel. As the bootloader is the first thing that gets loaded once the device is powered on, it takes full control of what it will or will not do, permit or restrict what the user can do.

As the bootloader starts up before anything else on the device, it can perform whatever security checks of the next bootable item in the boot chain, the kernel. If, for any reason, the bootloader’s integrity check of the kernel fails, the device will not continue the boot process, and the user will receive a security check failed warning.

These and other checks occur if the bootloader is locked. With a locked bootloader on Android devices, users are not allowed to modify any system partitions or boot unsigned images (such as a custom recovery) via “fastboot boot” command, or bypass any security-related checks enabled by the OEM.


Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.


On the other hand, if you had an unlocked bootloader, you could run all types of fastboot commands, load a custom boot image (e.g. a custom recovery) and use that to image the device by capturing the content of the data partition. If you are a “normal” user or developer, your first step would be unlocking the bootloader.

On some (but not all) devices the bootloader can be officially unlocked. While some manufacturers (most notably Google with its Nexus and Pixel range, Nextbit Robin and a bunch of other developer-friendly devices) allow for unconditional bootloader unlock, others may introduce additional verification steps before allowing the user to unlock. For one, Motorola requires users to apply for unlock code. Users have to register their device serial number with Motorola in order to obtain the code, and must use the code to perform the unlock.

Unlocking the bootloader in recent Motorola devices destroys cryptographic keys that are used to decrypt the data partition, and require a full factory reset before the device is usable. Because of this, officially unlocking the bootloader is not a valid option for data extraction.

FRP, or Factory Reset Protection

Regardless of bootloader lock status, there is an additional hurdle to overcome with imaging some of the newer devices, including most Samsung and Motorola models. Starting with Android 5.1, Google began offering an additional layer of protection, this time in an attempt to mitigate smartphone theft. Factory Reset Protection, or FTP, is a security feature of Android devices running Android 5.1 and higher that prevents the use of device that have been factory reset. Factory Reset Protection activates immediately and automatically once the user adds a Google account and configures secure screen lock (PIN, passcode, pattern, fingerprint etc.) If someone resets the device to factory settings by booting into recovery, the Setup Wizard will effectively prevent the use of the device until the user logs in using the same Google Account as previously set up on the device.

While Factory Reset Protection does sound like a neat idea, why do we even mention it here? The very name of the feature suggests that Factory Reset Protection kicks in after the phone is restored to factory settings, meaning a full data wipe has been completed.

There is more to FRP than meets the eye. One possible way thieves could use to bypass Factory Reset Protection, particularly on devices with unlocked bootloaders, was flashing or booting into a custom recovery and manipulating the phone’s ROM to bypass checks for Factory Reset Protection. Alternatively, a custom ROM sans Google Apps could be loaded, allowing the device to boot without any theft protection checks.

To address this specific case, some manufacturers including Motorola implemented an additional check. If Factory Reset Protection is active, the phone will not boot unsigned code regardless of bootloader lock status.

Even if the bootloader is oem unlocked (and most definitely if it isn’t), the phone will not boot into a custom recovery if:

a) the phone has a Google Account on it, and
b) the phone has secure lock screen (fingerprint unlock, PIN, passcode, pattern and so on)

In conjunction with a locked bootloader, FRP is a highly effective roadblock not only preventing theft but also blocking device imaging.

Imaging Devices with Locked Bootloaders

As we demonstrated, going the official route to unlock device bootloader is not a valid acquisition option as it does not preserve the data. Even if bootloader unlock could be performed without losing data, Factory Reset Protection (FRP) would still kick in, effectively blocking unsigned code to boot. However, other methods exist allowing forensic specialists to image devices regardless of their bootloader lock and screen lock status.

Such techniques vary across models, device and chipset manufacturers. For example, LG equips virtually all of its Android smartphones with a low-level service programming protocol that enables LG service centers to access firmware in LG smartphones regardless of their lock status. While initial purpose of this protocol (LGUP) was to enable “unbricking” of unbootable devices and repair corrupted software by uploading a known good firmware, the protocol allowed for two-way communication, thus enabling developers to download information from LG smartphones instead of uploading firmware. This method has been available for LG smartphones in Oxygen Forensic Suite since a few years ago.

Other manufacturers may provide their own low-level access protocols. As another example, many Android devices based on Qualcomm chipsets ship with open access to a so-called Qualcomm Download Mode, otherwise known as HS-USB 9006, Diag 9006 or QDLoader 9006. Once this mode is engaged and the Android device is connected to a computer, the computer picks up the content of the device storage and maps partitions as drive letters. Imaging the data partition is then a simple matter of using the correct flash imaging tool.

Yet another service mode by Qualcomm is mode 9008, an even lower-level version of hsusb 9006. While mode 9008 requires an additional programming file (normally available to official service centers) to load the device, by using that file one can boot the device and perform low-level imaging.

There is but one problem while using these low-level techniques. If the device was running Android 6.0 or 7.0 out of the box, the user data partition is automatically and compulsory encrypted, and the user is given no option to disable said encryption. The actual encryption key is stored in the device, and is also encrypted.

Encryption

Android devices could be encrypted for ages. Before Android 5.0 5.1 6.0 full-disk encryption (FDE) was optional on Android handsets. While users could still use FDE, they would have to manually trigger encryption in the Settings. Google’s own data suggests that less than 15% of users actually activated the feature. In a quest to increase Android security, Google made full-disk encryption mandatory on all Android devices that shipped with Android 6.0. Notably, devices that shipped with earlier versions of Android and received Android 6.0 (or even 7.x) as an OTA update were exempt, and were able to do without encryption.


Shipped with Android 5.1.1 or earlier: no forced encryption regardless of current Android version.

Shipped with Android 6.0 or 7.0: mandatory encryption; FDE fully enforced straight out of the box; deactivating is not an option.


Unlike iOS that uses encryption keys unique per each block of data, Android FDE employs a much simpler yet still efficient scheme. Unless the user activates the option to require a PIN code to start the device, the data partition is encrypted with a key that is calculated as a one-way function (cryptographic hash) of the password string “default_password” and a device-specific key that is stored in hardwre-backed Trusted Execution Environment (TEE).

The use of “default_password” as opposed to a PIN code that has to be entered by the user every time the device boots up allows Android OS to fully boot and decrypt the data partition (secure lock screen would still prevent unauthorized access to user data). If, however, the device is cold imaged by, for example, booting into a custom recovery, the data partition will remain encrypted because the TEE module is not supposed to expose its part of the data required to calculate the decryption key.

If, on the other hand, the user enables Secure start-up by selecting the “Require password to start the device” option in Android Settings, the decryption key will be calculated as a cryptographic hash of device-specific data in TEE as well as user input (PIN, password or pattern – but not fingerprint data or any other type of biometric input). The data partition will not be decrypted and the phone will not boot until the user enters the correct password.

The Full Disk Encryption scheme offers a very effective protection against low-level attacks such as those performed via firmware download, engineering access or service modes.

Oxygen’s Motorola Extraction Technique

If you read so far, you can imagine the obstacles Oxygen had to overcome when developing a method of breaking into locked Motorola devices. Locked bootloader, Factory Reset Protection (FRP) and Full-Disk Encryption (FDE) are seemingly designed almost exclusively for preventing the imaging.

Oxygen has developed a low-level acquisition method based on bootloader exploit that was discovered earlier for the Nexus 6. Oxygen’s technique makes the bootloader to boot the device into a special RAM image. This RAM image in turn executes code to dump the content of the data partition with on-the-fly decryption of that data, effectively imaging the device regardless of bootloader lock, FRP status and full-disk encryption.

What about Android Verified Boot and its strict enforcement in Android Nougat? The new extraction method does not break the boot chain; in fact, it does not even start the normal boot process. It does not attempt to alter the boot image or the system image, and it does not boot the device into the Android OS. As a result, the enforced Verified Boot protection is successfully bypassed – even in Motorola smartphones running Android 7.

Finally and most notably, Oxygen’s method can be used to image smartphones released with Android 6.0 and 7.0 out of the box with enforced full-disk encryption. However, for models with hardware-backed TEE this method can only decrypt FDE-encrypted partitions if secure lock screen is not configured for the device.

Compatible Devices and Android Versions

This acquisition method is compatible with fourth and fifth generation Motorola devices released in 2015-2017. This includes Moto C and Moto C Plus, Moto E2 through E4, all variants of Moto G2 through G5 models, Moto X Pure and Moto X Style, Moto X Play. Support for additional models such as the Moto Z and Moto Z Play is planned.

This exploit has been patched by Motorola in ROMs with May 2017 patch level; however, there are numerous devices still running unpatched ROMs, and there are numerous Motorola devices that will never see the patch due to carrier update policies or plain end of support.

If the device is running a patched version of Android (with May 2017 security patch level of or newer), you may still be able to use the extraction method if you downgrade by flashing an older version of the bootloader. A bootloader image extracted from older software versions of exactly the same device model and version may be used.

Downgrading the bootloader is only possible on devices that have been already bootloader-unlocked. Downgrading the bootloader does not modify user data since the only thing that needs to be flashed is the bootloader image.

Step By Step Guide

In order to image a compatible Motorola device, we’ll use the latest version Oxygen Forensic Detective.

  1. Start Oxygen Forensic Detective
  2. Click “Connect device” on the main toolbar
  3. Oxygen Forensic Extractor will launch

4. In Oxygen Forensic Extractor, select “Motorola Android dump” under “Physical data acquisition”

5. Follow the instructions on connecting the device. Power down the Motorola smartphone and make sure it is not connected with a USB cable. After the device powers down, hold both Power and Volume Down buttons until the device switches on. Release the buttons and wait until the bootloader menu appears on the phone.

6. In Oxygen Forensic Extractor, click Connect

7. The wizard will automatically locate and identify the device

8. A special boot image will be uploaded into device RAM without modifying the original boot image.

The device will look as follows:

9. The device will be automatically rebooted into special extraction mode. The wizard will continue upon device reboot.

10. If the device is protected with a lock screen password or PIN, enter it in the window below. Otherwise leave the form empty. The password will be used to mount and decrypt user data partition. Oxygen Forensic Extractor will verify the password by attempting to mount the partition before proceeding to the next step. If you’ve entered an incorrect password, you will be able to try again. The number of attempts is unlimited, yet the phone’s TEE may enforce a long and increasing delay after you exceed a certain number of attempts, making brute-force, even manual, extremely slow and unfeasible. If you don’t know the correct password, technically, the phone can still be imaged, yet the dm-0 dump will contain encrypted user data.

11. You will then be presented with the extraction parameters window. Configure device alias, assign case number and fill out all other relevant parameters, then click Next.

12. The device will be imaged. The process may take some time depending on the size of the device storage.

13. The dump will be processed. At this point, you may disconnect the device.

14. Once the processing is finished, a confirmation appears. Click Finish to close the wizard.

15. You may now return to Oxygen Forensic Detective and begin analyzing the data.

Conclusion

Android smartphones with locked bootloaders were always tricky. The release of Android 6.0 introduced encrypted experience on devices that shipped with the new OS, while update to Android 7.0 has brought even more challenges to mobile forensic specialists. The recent generation of Motorola smartphones running Android 7.0 is likely to feature encryption straight out of the box. The effects of locked bootloaders and active Factory Reset Protection make acquisition attempts via custom recovery fruitless.

Oxygen has discovered a smart workaround and implemented a solution allowing mobile forensic specialists to extract data on the physical level from many Motorola smartphones – even those running Android 7.0 and featuring encrypted data partitions.

Locked bootloaders aside, the most challenging part of the acquisition process is full-disk encryption implemented in all recent versions of Android and strictly enforced in phones shipped with Android 6.0 and newer on board.

Encryption renders chip-off and ISP extraction attempts useless as the data would come out encrypted. While overcoming full-disk Android encryption is still a challenge, Oxygen invented a solution allowing its mobile forensic toolkit to pull decryption keys from devices that are not protected with a passcode. Oxygen continues researching possibilities of brute-forcing passcode-based encryption keys.

The new approach supports many recent Motorola devices ranging from Moto E to Moto Z and running all versions of Android including Android 7.0 prior to May 2017 security patch. By keeping its activities strictly in the device’s volatile memory, the new technique is as forensically sound as at all possible as it makes no modifications to any of the device’s storage partitions. In a case of successful acquisition, the outcome is significantly greater compared to logical acquisition.

Oxygen’s new physical acquisition for Motorola devices is exclusively available in Oxygen Forensic Detective 9.5 and newer.

Leave a Comment