Today’s mobile devices are getting increasingly more resistant to physical imaging, mostly due to the use of full-disk encryption. Full-disk encryption makes useless some low-level acquisition techniques of yesterday, which includes JTAG and chip-off.

iOS was using full-disk encryption since the days of iOS 4 released back in 2011, while Android only started enforcing encryption in devices manufactured with Android 6 and newer on board. Today, pretty much any smartphone you can buy new comes with full-disk encryption out of the box. Does this mean that Android smartphones are just resistant to physical imaging as their Apple counterparts, or is Android still a big security mess? Let’s have a look at some protection mechanisms implemented in modern versions of Android that are to prevent unauthorized access to user data, and how these mechanisms may become completely useless in the right circumstances.

iOS Protection Against Physical Imaging

Let’s first have a look at iOS, Apple’s mobile operating system empowering all iPhone and iPad devices. We’ll finally let go of 32-bit devices and ancient versions of iOS. Granted, the iPhone 5c from the San-Bernardino case has become famous, but it is ancient hardware by today’s standards. Released back in 2013, iPhone 5c reached end-of-life status with the release of iOS 11 which didn’t make it to that device. iPhone 5c was released even before Android 4.4 KitKat was officially announced, and we aren’t talking about KitKat either.

Speaking of legacy devices, iPhone 4 (released in 2010) and earlier had a fatal bootloader-level vulnerability that could not be patched; as a result, full physical acquisition was possible even without a password. Only a small part of data would come out encrypted.

Subsequent generations of 32-bit iPhones including iPhone 4s, 5, and 5c were significantly harder to crack, yet full physical acquisition was still possible with jailbreak. A bootloader-level exploit was developed exclusively for iPhone 5c; that wasn’t easy or cheap, as the FBI paid close to a million dollars to break that one iPhone.

Back in 2014, iOS 8 started encrypted pretty much everything on the device with dynamic, passcode-based encryption keys. Starting with iPhone 5s, Apple’s first 64-bit smartphone, the encryption keys are no longer accessible even if the device is jailbroken. The keys are protected by Secure Enclave, Apple’s take on a hardware-baked security subsystem, which made physical dumping of the data partition impossible even with jailbreak. Physical acquisition was still available if the jailbreak was installed; however, it was limited to just the file system (no keychain decryption possible due to Secure Enclave). A jailbreak had to be installed in order to perform physical acquisition, which in turn required booting and unlocking the device first using the passcode. In other words, the passcode must be known in order to perform the (limited) physical acquisition of all iPhone devices starting with iPhone 5s.

Which brings us to the point. If the passcode is unknown, can we load some code to remove or brute-force it?

Since iOS 8, removing the passcode is pointless even on 32-bit devices. The cryptographic key that’s needed to decrypt the data partition is calculated dynamically based on user input (the passcode) and keys from Secure Enclave. Without the correct passcode, the iPhone will remain encrypted; there’s simply no way around it.

This is why the passcode must be known… or brute-forced.

That’s exactly what FBI demanded from Apple. And that’s exactly what Apple refused to do, even threatened by a potentially devastating legal process. While the FBI managed to unlock that iPhone 5c without Apple’s help, we’ll just put a mental note on what Apple said about their commitment to security, and what they actually did about it under legal threat.

While Apple refused to write (and sign) a boot image that could be used to brute-force passcodes on that iPhone 5c, someone else was able to do it for the FBI, presumable by finding a bootloader vulnerability (which, again, was presumably patched in iOS 10). Since then, similar vulnerabilities were discovered and exploits developed for iPhone 5s and 6; the exact list of devices and versions of iOS is unpublished. The tools are not available, and unlocking is provided as an exclusive service to eligible law enforcement and government agencies.

Finally, there is a hardware-based solution claiming to brute-force passcodes for the iPhone 7 running all versions of iOS 10. The box operates via iPhone’s DFU mode, and has to cope with a very long delay that makes the attack extremely slow (up to 5 minutes per passcode).

Android Security: Physical Imaging

Physical imaging, or physical acquisition, involves making a copy of the user’s data. The term “physical acquisition” is used for both live imaging and offline dumping of the user data partition. In some circumstances, the term also refers to making a dump of the file system (files and folders).

Since early days, Android came with a bunch of security measures designed to protect access to the user’s data. At this time, we won’t touch any authentication or sandboxing mechanisms; instead, we’ll investigate those mechanisms that can prevent physical imaging attempts. In particular, the following security measures exist in Android that can make physical acquisition difficult of impossible.

1. Bootloader lock. A locked bootloader prevents the loading and execution of any code other than that signed by the device manufacturer. In order to flash (or boot into) a custom image such as a custom recovery with the ability to access and image the data partition, one must first unlock the bootloader. This, in turn, would immediately destroy the cryptographic keys used to encrypt the data partition, and wipe the data, making official bootloader unlock a bad strategy for the purpose of physical acquisition.
2. Verified Boot. The Verified Boot mechanism controls the integrity of every part of the boot process, providing protection in the case a bootloader lock is circumvented.
3. Factory Reset Protection (FRP). In some devices, FRP (originally intended as a safeguard against smartphone theft preventing device initialization after an unauthorized factory reset) prevents the loading of unsigned code even on devices with unlocked bootloaders. FRP is activated automatically on all devices with secure lock screen (PIN, pattern or password) and at least one Google Account configured on the device.
4. Full-Disk Encryption (FDE). Encryption is the first and last barrier on the way of low-level and offline physical imaging. Since the data partition is securely encrypted, and the cryptographic keys are stored in the hardware-protected environment (separate from the main storage chip), encryption – at least in theory – would be very hard to overcome unless one knows the user’s password.

With as many as four layers of security, a fairly recent Android smartphone should be quite impenetrable, right? Before we spoil the illusion, let us have a closer look at those security mechanisms.

The Locked Bootloader

In Android, the bootloader is the first piece of code that gets loaded (and executed) from the storage chip. This is important, as the bootloader is not actually the first code that runs once the smartphone is turned on. Instead, this is the first code that is loaded from the storage chip (meaning that, in certain cases, this piece of code can be flashed with a different version with fastboot).

The bootloader is responsible for executing fastboot commands or loading and passing control to the next chunk of code: the boot image (normal boot) or recovery image.

During a normal boot sequence, the bootloader passes control to the boot image that contains the OS kernel and ramdisk (as well as the optional second-stage loader). Since the bootloader is the first code the smartphone runs, it takes full control over the next step of the boot process. In particular, the bootloader may perform signature verification and integrity check of the next link of the boot chain (kernel or recovery). If the boot image is not signed with a trusted signature, the bootloader may or may not continue the boot process.

Most Android devices sold in Europe and in the US come with bootloaders locked out of the box. For most devices, bootloader unlock is not even possible, while for a handful of others the end user may opt for unlocking the bootloader. So what’s the difference between a locked and unlocked bootloader?

Locked bootloader: signature verification of the boot image (kernel or recovery) enforced; signature must be trusted.

Unlocked bootloader: signature verification performed; signature may not be trusted, but signature mismatch may be allowed.

If the bootloader is locked and the device is running Android 6 or newer, you won’t be able to load a custom recovery or upload a forensic boot image to perform physical acquisition.

If you attempt to unlock the bootloader with a method officially supported for a given device (remember, not every device supports bootloader unlock by end users), the bootloader (which actually performs the unlock procedure) will automatically and immediately wipe the cryptographic keys that are used to access the encrypted user data partition. While the data itself will also be wiped on next reboot, the main culprit here is the wiped decryption keys during bootloader unlock. All this is to say that officially unloading the bootloader is not an option for forensic extraction.

Okay, but what if we were to somehow circumvent bootloader lock without actually unlocking the device? If the device is using an older version of Android, you would be able to boot the device. However, with Android 7 and newer this is no longer possible due to the second security measure: the strictly enforced Verified Boot.

Android 7: Trusted Boot Chain with Enforced Verified Boot

The Verified Boot mechanism is used to establish a trusted boot chain from the bootloader and all the way up to the system image. While Verified Boot relies on the bootloader to verify the boot image, it is assumed that the bootloader itself is protected with a different mechanism. For this reason, Verified Boot is disabled once the bootloader is unlocked.

Android Verified Boot implements checks in every part of the boot process; the bootloader checks the integrity of the boot image, while the boot image checks the integrity of the system image before passing control to the Android OS.

Without Verified Boot, malware could make alterations to the boot image or the system image. This would be extremely difficult to detect and almost impossible to defend against. Android Verified Boot protects all elements of the boot and recovery images (kernel, ramdisk, and second-stage loader if present) with a signature.

While Android Verified Boot as a feature originally appeared in Android 4.4 KitKat, its implementation in all versions of Android before Android 7.0 Nougat was mostly limited to displaying a warning message if tampering was detected. However, since Android 7.0, Google became very serious about providing a trusted environment – presumably, to secure transactions through Android Pay.

In Android 7.0 Nougat, Google has started strictly enforcing verified boot on devices. Android Nougat now strictly enforces the boot check, giving far more than just a warning message. As a consequence of this new strict policy, it becomes much harder to root devices running Android 7.0 without unlocking bootloader first (which, as we know, inevitably wipes user data). Even if the locked bootloader is somehow circumvented, the verified boot process will still detect any changes made to the boot image and system image and will prevent the device from booting into the OS.

In other words, simply bypassing bootloader lock in Android 7.x and 8.x devices would not be enough, as Android Verified Boot would effectively block the device from booting into an image that is not signed with a trusted signature.

Notably, Android Verified Boot differs from the Windows Secure Boot implementation in which the bootloader is also protected with hardware-baked keys.

Factory Reset Protection

In the unlikely event you get a smartphone that has an already unlocked bootloader but is otherwise unmodified, can you boot into a custom recovery and dump the data partition? In many cases, this would be no problem. However, some OEMs (notably, Samsung and Motorola) include an additional security measure preventing the boot of untrusted code if Factory Reset Protection is on.

Android 5.1 introduced a long-awaited theft protection measure, the Factory Reset Protection system. The name “Factory Reset Protection” is deceiving: in itself, it does not protect your phone from being erased. It wasn’t designed to protect your data either. What it does though is making the phone useless (or, rather, less valuable and therefore less attractive) to the thief by requiring signing in with the owner’s Google Account credentials if the phone is reset without following the correct procedure (confirming the passcode).

Factory Reset Protection is enabled automatically if:

• The phone is running Android 5.1 or newer
• The phone has Google Play Services installed (so this protection does not apply to most Chinese Android devices without Google Play Services)
• Secure lock screen (PIN, password, or pattern) is enabled
• User added at least one Google Account

While this looks like a lot of requirements, the mere fact is most ordinary folks are already covered without even realizing that they are. If their phone is stolen and the device is wiped (e.g. via a custom recovery), during initial setup the new “owner” would be presented with a window requiring to sign in with the original owner’s credentials.

This is all good, even if FRP can be bypassed quite easily in multiple ways in all but the latest builds of Android, but how is it related to physical imaging?

The relation is far from obvious. While Factory Reset Protection is designed to prevent the ability to use the phone by after a forced data wipe, some manufacturers extended it one step further.

What if the phone had an unlocked bootloader and the thief tries to flash a custom ROM on it with no FRP measures (and possibly no Google services) built in? FRP is enforced on the Google Play Services level by Google Setup Wizard. If the Setup Wizard is not run, the FRP could be bypassed by the thief, and the phone could be restored to a usable state.

This (rather uncommon) scenario is addressed by several OEMs such as Samsung. If Factory Reset Protection is active (regardless of whether or not the phone was wiped), the bootloader, even unlocked bootloader, will not allow booting untrusted code or flashing untrusted images onto the device. Does it interfere with custom ROM usage? No, because the rightful owner can easily disable FRP by simply entering their lock screen password, removing secure lock screen or removing their Google Account before flashing the custom ROM image. Does it help preventing smartphone theft? Yes, it does help. What’s important though, the unexpected side effect is that it also prevents forensic attempts to load a custom recovery or boot into a forensic image even if the bootloader is unlocked.

Working together with bootloader lock and Verified Boot, FRP is yet another roadblock on the way of forensic extraction.

Bootloader Lock: Workarounds

In theory, the set of security measures described above should be well enough to discourage anyone of even thinking about offline imaging. However, Android smartphones are not like iPhones. They are using vastly different hardware, they are build by vastly different vendors, and they are running heavily altered versions of what’s supposed to be Android. While Google has checks in place to validate each vendor’s implementations of Android, some are doing better than others. Before we continue our journey and start talking about full-disk encryption, let’s have a look at how effective all the security measures above for real devices.

In real devices, there are bugs, backdoors and workarounds that allow forensic experts to successfully (and instantly) bypass all of those scary-looking security measures at once.

Let’s start with chipset manufacturers. Many smartphones using a reference implementation of the Qualcomm chipset (and that constitutes the majority of devices, at least in the US) also implement Qualcomm’s USB Upload mode 9008, which provides unrestricted low-level access to the contents of the device storage. Yet another special mode known as Qualcomm Download Mode, HS-USB 9006, Diag 9006 or QDLoader 9006, works on a higher level and allows actually mounting device storage partitions as drive letters. Once one of these modes is engaged, dumping the content of device storage is trivial.

The second-largest mobile chipset manufacturer MediaTek makes data extraction even easier by allowing unrestricted access to device memory via a special protocol utilized by tools such as SP Flash Tools.

Some manufacturers make accessing Android storage even more convenient. For example, LG smartphones are equipped with a low-level firmware update mode LAF. In this mode, two-way communications with device storage are possible, allowing users of certain forensic tools to perform physical imaging of LG smartphones in just a few clicks.

If you think about it, the ability to bypass locked bootloaders, Verified Boot and Factory Reset Protection in one go is severe enough to make us worry. Or is it?

While one can technically image the device, the usefulness of the storage dump will be highly affected by whether or not the data partition was encrypted. And if it was encrypted, the low-level physical dump will be pretty much useless as the encryption keys are stored in a hardware-backed Trusted Execution Environment (TEE).

Encryption

Encryption is not exactly new for Android. You could encrypt your Android 4.4 KitKat smartphone, although this wouldn’t be a very secure encryption. Starting with Android 5.0, Google re-designed full-disk encryption, finally bringing security up to date. It was not until Android 6.0 when Google started pushing manufacturers to enforcing encryption out of the box, but even then the encryption is only enforced on smartphones manufactured with Android 6.0 or newer (as opposed to devices released with an earlier version of Android and receiving Android 6.0 as an OTA update).

If you were given an iPhone (let’s speak of iPhone 4s or newer), you would instantly know that a) it’s encrypted, and b) you have to unlock it at least once (with a passcode) after first boot, or it’ll stay encrypted. The iOS implementation of encryption creates encryption keys on the fly based on information stored in the device (Secure Enclave in 64-bit devices such as iPhone 5s and newer) as well as the passcode entered by the user. The encryption key is always generated by the device. Without the user’s passcode, the encryption key cannot be generated, and the data remains encrypted.

Android used a very different approach. While it is possible for the end-user to make encryption resemble the iOS implementation (by enabling “Secure Boot”, or “Require password to start the device” in the settings), this comes with many drawbacks and is strictly optional.

For most ordinary folks, the default out-of-the box implementation is used. In this implementation, the data partition is encrypted with a key that is calculated as a cryptographic hash of a device-specific key stored in the hardware-backed Trusted Execution Environment (TEE), and a static password string “default_password”.

Once again: the majority of existing Android devices that are encrypted are using the “default_password” sting in lieu of the passcode.

So then, does this make it easy to decrypt the data partition we’ve just extracted via one of the low-level methods? Not really, because the other part of the cryptographic key is based on the unique seed stored in the hardware-backed TEE, and TEE will not let go of that seed unless you are trusted code.

Does that, in turn, mean we cannot do much to decrypt the data? In theory, FDE encryption used in Android 6 and 7 is secure enough to make offline imaging useless. However, some Android manufacturers go really out of their way to prove otherwise.

Samsung: Committed to Security?

“Samsung prides itself on providing end-to-end solutions that are secured at the core”, said Injong Rhee, Executive Vice President and Head of R&D, Software and Services, Mobile Communications Business at Samsung Electronics in a press release. “Samsung KNOX provides enterprise-ready devices with built in defense grade security, right out of the box. Anchored in the device’s hardware, Samsung KNOX protects the device from the moment it boots up all the way through launching an app” is another quote from the same press release.

How do these quotes coincide with reality?

Samsung has all of the following security measures active on their flagship smartphones (at least those running Android 7 at the time of this writing).

1. Bootloader lock out of the box
2. Android Verified Boot
3. Extended Factory Reset Protection making it impossible to load the phone with a third-party boot image
4. Full Disk Encryption out of the box
5. “Samsung KNOX providing enterprise-ready devices with built in defense grade security, right out of the box”, whatever that’d be

In real life, Samsung happens to write software aimed precisely at bypassing all imaginable security measures on its Galaxy S7 smartphones. What’s worse, the company let the software leak into the wild, giving a perfect tool for messing with Samsung devices to the hands of… everyone. If you missed this one, check it out: Physical Imaging of a Samsung Galaxy S7 Smartphone Running Android 7.0.

So what exactly is this all about? Without going too technical, there is this engineering boot image (G891A_7.0_ENG_ROOT.tar) developed and signed by Samsung itself that allows full, unrestricted access to device storage.

What’s much, much worse is the fact that, being signed by Samsung, this boot image is trusted by device TEE, and convinces the TEE to decrypt the encrypted data partition with or WITHOUT the passcode! In fact, the instructions in the guide mentioned above list steps to bypass and remove secure lock screen (PIN, password or pattern), which would be pre-requisite to enabling USB debugging and rooting the phone to prepare it for physical imaging.

Yes, just like that: REMOVE the passcode and DECRYPT the data, all in a few clicks. Using purposely-made Samsung code. Leaked from a Samsung factory. There we go with “defense grade security, right out of the box” for a “solution […] secured at the core”.

What could be worse than that? Letting the thing leak for everybody use.

To recoup, all of the following security measures are bypassed, all in one go:

1. Locked bootloader: bypassed, because the device boots into a genuine image signed by Samsung itself
2. Verified Boot: bypassed, see above; then disabled completely during the rooting process
3. Factory Reset Protection: does not ring the alarm
4. Full Disk Encryption: bypassed because boot image is signed by Samsung, trusted by TEE
5. KNOX: not tripped

Conclusion

We had a look at how different manufacturers handle security issues related to the mobile devices they manufacture. These days, pretty much everybody is shouting “security”. Watch what they do, not what they say.

If you ask us, we’d love to have an Apple-signed engineering bootloader. With Apple private keys, we could develop a tool to extract pretty much everything from the device, no jailbreak required. However, even with Apple private keys, we’d be still facing the passcode, and we’d still have to break it somehow – probably facing the same kind of delays as the iPhone 7 box does.