A week ago my professor's Pixel 4 XL was stolen from his desk when he left it there for charging. The phone has been shut down. It had few minutes of battery left when it was plugged in charging. Though I believe that the attacker has powered it off immediately and also turned off mobile data or turned on airplane mode which are unfortunately allowed in Pixel devices without unlocking the screen. I must say that this is a weak physical security design and helps the attacker more than environment safety*. Although location cannot be turned off at locked screen but it will be useless unless the device automatically reconnects to the nearby open wifi in campus to which the device was connected earlier.

I assured him that the data cannot be compromised because it is protected by file based encryption (FBE) which is bound to the user's lock screen password and lock screen password is verified by Titan M chip (TEE) to unlock the device. The attacker can still reset the device which is then prompted by factory reset protection when setting up the device. This is yet another weak physical security design because unauthorised factory reset can be prevented by adopting biometric authentication for bootloader and recovery mode by TEE which wakes up before the android bootloader is awaken.

In Pixel, bootloader can be unlocked by enabling OEM unlocking from developer tools and then executing fastboot flashing unlock in bootloader mode. As the attacker cannot reach developer settings without unlocking the screen, my professor asked if by using a hardware tool like UFS flash storage reader & writer, can the attacker directly tamper with OEM unlocking byte and bootloader state (locked & unlocked) bytes which are stored somewhere for persistence across reboots and flashing custom ROMs?

*Environment safety: Some security trade-offs were made by android security team by allowing to shut down, to turn on airplane mode and to turn off mobile data from locked screen so that devices in case of emergency like overheating of the device while in plane and radio interference, these features can be remain functional from locked screen.


Pixel refuses fastboot flashing unlock (and unlock_critical) command unless OEM unlocking is enabled. OEM unlocking byte is stored by TEE as implemented in android source.

libese provides a minimal transport wrapper for communicating with embedded secure elements. Embedded secure elements typically adhere to smart card standards.

TEE is tamper-resistant by design. So it's not possible to physically modify OEM unlocking byte in Pixel. VerifiedBootState is also stored in TEE. This ensures that stolen Pixel device cannot be reused by unlocking the bootloader and reflashing the images.

When bootloader unlock command is executed, bootloader queries TEE to get unlock ability set by OEM unlocking. When VerifiedBootState is set to unlocked, TEE flushes file based encryption (FBE) keys and bootloader resets the device. Verified boot state and unlock ability remains persistent in TEE across reboots, flashing custom ROMs and factory reset. This is why the user still has to relock the bootloader even if all partitions are reflashed with stock images.

Verified boot state in TEE is now also used in SafetyNet's hardware-backed attestation. Tamper-protection by TEE makes it impossible to fake verified boot state. As a result, it leaves no way to pass SafetyNet's device-integrity test even if you have root access.

In other devices, OEM unlocking byte is stored in FRP partition which is a bad security design because OEM unlocking byte can be physically modified if it's stored outside of TEE. In such devices, OEMs sends unlock.bin signature file to the user which is used as an additional argument with unlock command so there is some sort of verification in place to verify the device owner. In Mi devices, OEM unlocking requires registration with Mi account which ensures that only the account owner can unlock bootloader from Mi unlock tool even if OEM unlocking is enabled.

Earlier Mi devices are found to be storing bootloader state in /devinfo partition which is totally insecure because by simply modifying the byte, the attacker could unlock the bootloader. As more and more devices will be mandated to enforce SafetyNet's hardware-backed attestation, VerifiedBootState will be stored in TEE.

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .