Numerous vendors advertise many types of solutions for extracting evidence from Android devices. The companies claim to support tens of thousands of models, creating the impression that most (if not all) Android devices can be successfully acquired using one method or another.

On the other side of this coin is encryption. Each Google-certified Android device released with Android 6.0 or later must be fully encrypted by the time the user completes the initial setup. There is no user-accessible option to decrypt the device or to otherwise skip the encryption. While this Google’s policy initially caused concerns among the users and OEM’s, today the strategy paid out with the majority of Android handsets being already encrypted.

So how do the suppliers of forensic software overcome encryption, and can they actually extract anything from an encrypted Android smartphone locked with an unknown passcode? We did our own research. Bear with us to find out!

Many thanks to Oleg Davydov from Oxygen Forensics for his invaluable help and advise.

Android Full-Disk Encryption, Secure Startup and File-Based Encryption

Before we start discussing how manufacturers can bypass encryption, let us first have a look at the types of encryption available in Android.

Starting with version 5.0, Android offers reasonable protection with full-disk encryption (FDE). In modern devices featuring 64-bit processors (basically everything from Qualcomm Snapdragon 410 and all the way up to the recent Snapdragon 845), full-disk encryption is software-accelerated with dedicated ARMv8 commands. The encryption key is protected with Trusted Execution Environment (TEE), a dedicated part of the CPU that will only execute small pieces of signed code (trustlets).

By default, the actual encryption key that is used to encrypt and decrypt the data is based on a combination of a unique hardware key and the phrase “default_password”. While this protection scheme is obviously orders of magnitude less secure than full-disk encryption in iOS devices, it still provides reasonable protection to an average consumer. In other words, bypassing such encryption can be non-trivial.

Users not satisfied with the default protection level can opt to encrypt their phones with a much stronger key based on a combination of a hardware key (again) and user input (passcode, pattern etc.) on device startup. This option is called “Secure startup”, and can be configured during the initial setup while specifying the lock screen password. If the user changes their mind and wants to activate the “Secure startup” option at a later time, he or she will have to first remove the PIN/pattern/password from the device, and then re-enable protection. The phone will then prompt the user whether they want the phone to ask for their PIN/pattern/password on startup.

The principal difference between “secure startup” and “no secure startup” lies in how the device produces the decryption key to access information on the data partition. If secure startup is not enabled, the encryption key will be automatically generated during the boot sequence based on a combination of a certain hardware-dependent key and the passphrase “default_password”; no user input is required. Once Android finishes the boot process, the screen will be still locked and must be unlocked with a PIN/pattern/passcode (but not Smart Lock or any biometric sensor, at least if the manufacturer didn’t screw up this part – which many do). Notably, even before the user unlocks the display, the data partition is mounted and decrypted; the apps are allowed to start and to access their data.

If, however, the secure startup option is enabled, the phone will ask for the passcode early during the boot process. This happens before most Android services, let alone the apps, are allowed to start. The passcode is required to generate the actual encryption key; it will be used instead of the “default_password” for that purpose. Apparently, there is (or there should be) no way to bypass this protection and decrypt the data unless the correct password is provided.

While “secure boot” is inherently a more secure way to protect information, it has not been widely adopted by Android users due to the limitations. If, for example, the phone reboots in their pocked (or during the night), it will be unable to receive calls or play alarms – simply because the required services have not started, and the data is still encrypted.

In Android 7.0, Google offered an alternative to full-disk encryption that combines the protection of Secure Startup with convenience of not having to suffer from its limitations. The new File-Based Encryption (FBE) protects user data by encrypting each file with a unique key. All of these keys are derived from information stored in the TEE as well as the user’s credentials (PIN, pattern or password that are used to unlock the phone). If File-Based Encryption is employed, the phone can boot and access data stored in the special Device Encrypted area that is protected with hardware keys only (so at very least the device will be able to receive a phone call). Most information, however, is stored in the Credentials Encrypted zone, which is protected with keys based on the user’s credentials.

While FBE is inherently more secure compared to FDE, using one or another is not the choice the end user can make (with the only exception of several Google-made Pixel devices). Instead, it is the OEM who makes the decision. If the OEM decides in favour of FDE, there will be no way for the user to switch to the more secure file-based encryption. So far, the more secure File-Based Encryption has been used on a handful of devices, most of which are lesser known or downright exotic (e.g. OnePlus 5, 5T). Most A-brands release their phones configured with the proven-and-working Full-Disk Encryption.

If you are interested in details on Android encryption, we can recommend this excellent report by Ronan Loftus and Marwin Baumann, University of Amsterdam:

Android 7 File Based Encryption and the Attacks Against It

The report describes the basics of Android Full-Disk Encryption and File-Based Encryption, and outlines the differences between the two schemes in a clear and concise way that is easily understandable even for beginners without deep understanding of cryptography.

Breaking Android Encryption

Gone are the days of bare chips with unencrypted data. Today, forensic experts almost expect a phone to have some sort of encryption. This changes the way we access information. Chip off is completely useless for Apple devices. The method is becoming obsolete as more and more Android smartphones are encrypted.

So how can one break into an encrypted Android smartphone and extract information? The sheer diversity of OEMs, devices and software modifications make it impossible to create a universal strategy. Different devices employ different chip sets using different protection methods and even different types of encryption. We’ve seen devices using a built-in encryption key, a single key for all devices of the same model.

Many devices have unpatchable low-level vulnerabilities. These vulnerabilities can be exploited through EDL mode, enabling experts to overwrite certain partitions and inject modified trustlets that will exploit TEE to extract the encryption key or eliminate the GateKeeper delay when brute-forcing the password.

Due to the sheer variety of Android models, modifications and software builds, it is not realistically possible to expect a positive extraction for a given individual device. However, there are techniques applicable to groups of devices that can be usable for physical acquisitions.

Secure Startup

If the user opts to protect their encrypted phone with Secure Startup (the PIN/pattern/passcode will be required to boot the device), most existing extraction methods will fail. The original password must be recovered by running a brute-force attack on the device. The GateKeeper will limit the speed of attacks unless TEE is exploited to disable the feature. To our knowledge, there are currently no ready-made solutions targeting this situation; most existing solutions target regular FDE encryption and passwords without Secure Boot protection.

In other words, if you happen to work on an encrypted Android device that requires a PIN/password/pattern to start, your chances of successful acquisition are not very high unless you are willing to invest a substantial amount of time into that particular case.

Qualcomm EDL Access Mode

Many smartphones equipped with Qualcomm chip sets (except Samsung and LG) are equipped with a so-called Emergency Download Mode. This mode is generally engaged by shorting certain pins while the phone is powered on; special USB cables are available to achieve exactly this (look for “EDL cable” or “deep flash cable”, and you’ll find dozens of different models). By using EDL, one can image the entire storage chip of the device.

EDL extraction for unencrypted devices that are protected with an unknown passcode is available from several vendors including Cellebrite, Magnet and Oxygen. Encrypted devices require additional efforts, and will be covered in the next chapter.

Benefits:

• Relatively easy extraction of supported devices
• More robust and reliable compared to other methods
• Universally applicable to devices equipped with multiple chip sets
• Data from unencrypted devices can be extracted regardless of passcode protection
• Supports all versions of Android (without encryption)

Limitations:

• Does not bypass FDE encryption even if there is no passcode
• Not applicable to encrypted devices
• EDL mode may be difficult to invoke on a particular device

Qualcomm EDL Exploit and Encryption

What about encryption? In EDL mode, one can have a full, unrestricted access to the device storage. Yet, this is not what the exploit is about. While it is possible (and has always been possible) to use EDL mode to image non-encrypted devices with Qualcomm chip sets (similar to LG LAF), low-level access becomes useless once the device is encrypted.

The EDL exploit, on the other hand, enables the attacker to modify the content of the device so that the boot sequence bypasses certain security checks, allowing the attacker to inject modified trustlets into the TEE and extract the encryption keys, unlock bootloader without wiping the device and patch kernel to gain root access. Forensic tools may even perform these operations in the device RAM without modifying the actual storage, making the entire extraction and decryption process forensically sound.

To understand how the EDL exploit works, we recommend reading the following articles:

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals

Exploiting Qualcomm EDL Programmers (2): Storage-based Attacks & Rooting

The EDL exploit applies to a wide range of models including most smartphones equipped with popular inexpensive and mid-range Qualcomm chip sets, and has been additionally confirmed to work with the following models:

• LG: LG G4
• Nokia: Nokia 6, Nokia 5
• Google Nexus: Nexus 6, Nexus 6P
• Motorola: Moto G4 Plus
• OnePlus: OnePlus 5, OnePlus 5T, OnePlus 3T, OnePlus 3, OnePlus 2, OnePlus X, OnePlus One
• ZTE: ZTE Axon 7 (other ZTE-specific exploits are available via ZTE proprietary DFU mode)
• Lenovo: ZUK Z1, ZUK Z2
• Xiaomi: Xiaomi Note 5A, Xiaomi Note 5 Prime, Xiaomi Note 4, Xiaomi Note 3, Xiaomi Note 2, Xiaomi Mix, Xiaomi Mix 2, Xiaomi Mi 6, Xiaomi Mi 5s, Xiaomi Mi 5s Plus, Xiaomi Mi 5x, Xiaomi Mi 5, Xiaomi Mi 3, Xiaomi Mi A1, Xiaomi Mi Max2, Xiaomi Redmi Note 3, Xiaomi Redmi 5A, Xiaomi Redmi 4A

Making use of this exploit is neither fast nor easy. Very few ready-made solutions exist, and there can be no “generic” method for exploiting this vulnerability on different device models – at very least due to the differences in offsets and ABOOT code that is device specific. As of today, the EDL exploit has been successfully developed only for a handful of devices. In order to add support for a random encrypted Android handset with a vulnerable Qualcomm chip set, one must develop custom boot code. While this is technically possible (and easier than unlocking the proverbial iPhone 5c), the process will be still a time- and labour-consuming endeavour.

Benefits:

• One of the very few methods to work with encrypted devices
• Can bypass FDE encryption even with unknown passcode (without Secure Startup)
• Applicable to many devices equipped with vulnerable Qualcomm chip sets
• Can be used to enumerate unknown passcode, bypassing GateKeeper delays

Limitations:

• So far, ready-made solutions exist only for select few devices (most of which are uncommon)
• No ready-made universal solutions (as of today)
• Extremely difficult to implement
• Adding support for a given device may be expensive and time-consuming (still probably less than the million dollars paid for unlocking the infamous iPhone 5c)
• Cannot bypass FBE encryption if unknown passcode is set
• Cannot bypass FDE encryption if both Secure Startup and unknown passcode are enabled

Decrypting Bootloaders

Extracting and decrypting the device through a custom bootloader without allowing the phone to fully boot into the Android OS is probably the most forensically sound method for imaging Android smartphones. Forensic vendors such as Cellerbrite, Oxygen and Magnet develop their own custom versions of bootloaders for the various platforms.

Normally, Android security measures would prevent the device from booting unsigned code. This protection mechanism is explained in detail in Exploit Targets Qualcomm’s EDL Mode, Affects Some Xiaomi, OnePlus, Nokia and other Devices. However, by targeting vulnerabilities in various manufacturers’ handsets (e.g. Qualcomm EDL exploit, Samsung engineering boot image etc.), it is possible to develop a method allowing to bypass passcode checks on devices without Secure Startup, and to run an attack against the passcode if Secure Startup is enabled.

It still takes effort to decrypt the smartphone even if the data is encrypted with “default_password”. Much depends on the encryption implementation of a particular vendor. As an example, some vendors will not re-encrypt the KEK (Key Encryption Key) when the user changes their passcode; this in turn allows decrypting the data regardless of the current passcode by simply using “default_password”. The same situation occurs if, at the time of the initial setup, the vendor opts to start encrypting the phone before the user sets the passcode. According to Oxygen, this is exactly what happens on Motorola smartphones, which can be extracted and decrypted regardless of the lock screen password – but only if Secure Startup is not enabled.

For smartphones without Secure Startup that encrypt the data partition before the user specifies the passcode, the data partition is mounted and decrypted at the end of the boot process and before the user unlocks the device with a passcode or pattern. Methods exist that can convince the TEE to decrypt the content of the device without booting into the system. One of such methods involves disabling dm-verity and booting into a custom boot image via an EDL exploit. In this case, the custom boot image is able to mount and decrypt the encrypted partition and access the data.

Decrypting bootloaders are widely used in Cellerbrite UFED for a range of handsets including select models manufactured by Huawei, Motorola, Xiaomi, Acer, Lenovo, ZTE, Alcatel etc. Oxygen uses bootloader-level extraction for many Motorola and Samsung models, including support for offline passcode recovery for Galaxy S5/S6/Note4 devices.

Samsung Emergency Download Mode

Samsung does not use the Qualcomm EDL mode even in its Qualcomm-equipped handsets (such as those Galaxy Sx models sold in the United States). Instead, Samsung implemented its own proprietary programming protocol called Odin. Odin can be used to read the (encrypted) content of the device. It can be also used to write data on the device.

For many Samsung models, one can use one of the engineering boot images leaked from Samsung or one of its service facilities (an engineering bootloader leaked from Apple anyone?) These engineering boot images are developed and signed by Samsung proper; they allow full, unrestricted access to the device storage.

Being signed by Samsung, such boot images are verified and trusted by the TEE. As a result, for devices that are encrypted with FDE without Secure Boot, one can boot straight into the system while bypassing passcode protection altogether. There are other things one can do with these engineering boot images such as making (and booting) a custom kernel designed specifically for extracting and decrypting data (more information in our blog: iOS vs. Android: Physical Data Extraction and Data Protection Compared).

Other extraction methods are available for select Samsung smartphones that can deal with encryption.

Benefits:

• Ready-made solutions exist (Celebrite UFED)
• Bypasses Full Disk Encryption without Secure Boot (boot image is signed by Samsung, trusted by TEE)
• Possible to attack passcode if Secure Boot is enabled

Limitations:

• Switching to emergency programming mode may require a special cable
• Sometimes, the device must be disassembled and test points shorted to make it switch to emergency programming mode
• Exact location of test points not always known

ZTE Smartphones

ZTE is a large Chinese manufacturer struggling to sell in volumes in the Western market but very popular in the home market. Our experience with ZTE smartphones is limited to ZTE Axon 7, the company’s flagship device of 2016 featuring Snapdragon 820 and released with Android 6 on board. Generally speaking, Chinese manufacturers don’t care about security, up to the point of completely removing the ability to encrypt data on smartphones that are sold in China. Despite making it through Google certification, the Axon 7 allowed positive fingerprint authentication immediately after being powered on.

Many ZTE smartphones, especially the older ones equipped with Qualcomm 8916 (Snapdragon 410) chipsets, have vulnerabilities allowing to image the data through ZTE proprietary DFU mode. This mode, in particular, is used by Cellebrite UFED to image compatible devices.

LG Smartphones

Instead of employing the flawed Qualcomm EDL mode, LG opted to use its own proprietary low-level firmware update protocol LG Download Mode (LAF). The LAF protocol can be used to upload information to the device. However, the very same protocol can be exploited to download information from an LG smartphone regardless of the chip set. Oxygen Forensic Extractor supports LAF acquisition if one selects an LG smartphone during the acquisition. However, this low-level access mode will only return a binary image of the device storage chip. Full-disk encryption effectively prevents acquisition. At this time, there are no known exploits allowing to break the encryption.

To sum it up, LAF mode acquisition has the following benefits and limitations.

Benefits:

• Easy extraction of unencrypted LG devices
• More robust and reliable compared to other methods
• Universally applicable to many LG models regardless of the chip set (Qualcomm or MTK)
• Data from unencrypted devices can be extracted regardless of passcode protection
• Supports all versions of Android (without encryption)

Limitations:

• Does not bypass FDE encryption even if there is no passcode
• Not applicable to encrypted devices

Motorola Smartphones

Oxygen has developed a technique based on bootloader-level CVE exploits allowing experts who use Oxygen Forensic Suite to successfully bypass protection on some Motorola smartphones manufactured between 2015 and 2017. This includes models such as the Moto X, many Moto G variants up to and including the G5, Moto Z and Moto Z Play among many others. The exploit is invoked automatically once the expert connects a compatible Motorola smartphone in “fastboot” mode to the PC, and chooses the “Motorola” option in Oxygen Forensic Extractor (part of the Forensic Suite).

Benefits:

• This method can easily extract data from unencrypted Motorola devices
• Chipset independent (works through fastboot mode)
• Data from encrypted devices can be extracted if no passcode is set or the passcode is known (in which case it must be specified during the extraction)
• Supports Android 7.0

Limitations:

• Limited number of models
• Compatibility not a given even for supported devices (for example, the World variant of Moto G 2^nd may be supported, while the Verizon variant of the same model may be not)
• Does not support all versions of software even if vulnerability is there (due to different offsets)
• Limited to devices with security patch level prior to May, 2017

Alternatives to Physical Acquisition

Drastic times call for drastic measures. Full-disk encryption, File-based encryption, Secure startup and properly implemented secure boot chain can make physical acquisition impossible even if a device is running an ancient version of Android – such as Android 6.0. But what if one could go past the lock screen? The many good security measures in Android are often neglected by the user or countered by the use of some less secure features. Android Smart Lock is one of the features that can have drastic effect on the overall security of the device.

If you are able to go past the lock screen, you can attempt logical acquisition by producing a local backup. Compared to iOS, Android local backups are… complicated. Starting with Android 5.0, backups produced with “adb backup” contain a lot less data than before. So much less that they’ve became practically useless for their intended purpose, namely – backing up and restoring the content of the device. If ADB backup is your last resort, it is still better than nothing; much better than nothing if you take into the account the content of the “sdcard” mount that can be readily accessible via MTP. However, many Android OEM’s offer their very own solutions for backing up and restoring devices.

Take Xiaomi. If the device being acquired is not one of the recent breed of Google-certified smartphones, the local backup performed with MIUI internal tool right on the phone will contain pretty much everything that’s on the phone. This includes sandboxed app data – even for the apps whose developers explicitly disallowed backups. Google-certified devices (such as Xiaomi Mi Mix 2) appear to respect this developer setting, and fail to back up applications that aren’t allowed to back up.

LG, Samsung, ASUS and Sony all have their very own backup solutions. Sometimes these solutions are only available for certain devices or certain versions of Android. Some manufacturers (e.g. Samsung) even have different utilities for backing up the different models. If you are able to use one of such tools, you will gain access to a lot more data compared to ADB backup. (Interestingly, some manufacturers who offer home-grown backup tools will put even stricter limitations on what’s included in ADB backups).

Finally, what if no physical access is possible to the device at all? If this is the case, you can still perform cloud acquisition by obtaining the data directly from the user’s Google Account. The amounts of data Google collects about the user and stores on its servers are truly shocking. In fact, you may be able to obtain significantly more information from the user’s Google Account compared to any other acquisition method even if you could do a file system dump.

Conclusion

While suppliers of forensic software may claim support for tens thousands of models, the actual probability of successfully extracting a random Android smartphones is low because of the encryption. While exploits do exist allowing experts to overcome encryption on certain device models, these methods are far from universal, and will generally only work on smartphones featuring FDE with no Secure Startup. Any other configuration would require attacking the passcode on the device itself, and this may be problematic or impossible even if the device is on the list of supported models.

Are encrypted Android devices secure or not? Compared to a recent iPhone (such as the iPhone 7, 8 and X), an average Android smartphone would be inherently less secure. For many Android smartphones one can develop an exploit based on one or the other unpatchable vulnerability. Granted, the code may not exist, but it can be developed: the direction is clear, and all the right tools are there. On the other hand, imaging an iOS device always requires breaking the passcode first, which can be done by one of the two companies (Cellebrite and GrayShift) and is a subject to multiple “ifs” and “buts”.