[BlackBerry Priv] doitright:
They're going to lock it down as tight as they can.... but you *CAN'T* put an absolute lock on the system partition, since that would make system updates impossible. I'm sure that the main device you are referring to when you reference HTC was the "Vision", but you will recall that the system partition was only locked out in a *normal* boot. A recovery boot exposed a writable system partition, there just wasn't any way to use it because of recovery limitations.

BUT, this doesn't mean that it is possible to take over control of your phone! Here is the big problem; bootloader chain of trust!

On a NEXUS, we have a boot process that looks like this; hardware boot from EEPROM --> PBL (signature validation) --> SBL1..n+TZ (signature validation) --> ABOOT (signature validation) --> Linux kernel boot/recovery

The handoff from ABOOT to the Linux kernel is an interesting one.

In the Nexus case, the Linux kernel boot/recovery partitions are not signature validated. At least not always.

So what happens in the bootup is that each bootloader is signature validated by the previous bootloader PRIOR to executing it. If any stage fails validation, the device will go into HSUSB-BULK mode. In fact, the ONLY way to get into HSUSB-BULK mode is for a bootloader to fail validation.

So what this means, is that there is NO WAY to replace ANY of the bootloaders up to and including ABOOT/LK. Even on a Nexus. Why? Because it breaks the chain of trust.

Now, something added into Android 6.0; dm-verity. Well, technically, it was added back in 4.4, but not actually used back then. So why now? Hmmm, may be related to Blackberry. Yes, they are using 5.1, but that doesn't mean that the feature now used in Nexus devices can't be enabled in 5.1.

dm-verity is the part that complains about the system being in various compromised or compromisable stated during boot. dm-verity is able to completely block boot.

But you say that dm-verity is a component of the linux kernel, enabled in the boot partition of the device that is being protected by it... yes, but that is only helpful because there is no signature check on the boot partition. Now imagine for a moment that ABOOT/LK is configured to require boot and recovery partition signature checking before handing over control.... what that will mean, is that you can't modify the boot partition to disable it like you can on an unlocked Nexus 6. If you modify the boot partition, then ABOOT will go into whatever recovery mode is deemed proper. It'll probably fall back to recovery when the boot partition can't be verified, or fastboot (which can actually be unlocked safely on such a device, since you would have to load something that will pass signature checks, or it won't boot).

Now what does dm-verity actually do? It verifies that each block being read is unchanged from original. Most people don't understand this -- that it is an on-the-fly validation.

I.e., if it was just a boot-time validation, you could fake it by modifying the data and not the filesystem database. That could, in theory, allow a modified partition to boot, but then what happens later is that when the modified data gets read, it generates an I/O error.

So where does this leave us in terms of hacking such a protected device? Not a very good position at all, since there is no interface to interfere with the process during the boot. In other words, you would have to find and exploit a flaw in dm-verity itself. You can't change the bootloaders because of the eeprom that starts off the entire chain. You can't change the boot partition because of the bootloaders. You can't change the dm-verity keys because they are part of the boot partition. You can't change the system partition because of dm-verity.

So attack vectors;

1) hardware attack; if you can replace/rewrite the eeprom that sets off the boot process, then you can shove in your own bootloader stack. I'm not sure if this is even possible, those snapdragons have some interesting hardware level protections. It might refuse to boot a PBL that isn't signed by qualcomm.

2) exploit flaw in dm-verity; figure out some way feed it a new key and hash table on the fly.

3) exploit other software flaw and cause a second installation of Android to boot from some non-verified location.

#2 and #3 are incredibly difficult, especially when you have a solid selinux policy preventing you from doing anything fun.