Locked-down GPTs? Newer Qualcomm devices might hard-brick when repartitioned

[Lanchon]

there has been a completely unexplained hard-brick of a recent Qualcomm device (released on June 2015) while being repartitioned.

to give some context, this happened during porting of REPIT to a new device. REPIT is a safe (until now, that is) on-device data-sparing Android repartitioning tool that is executed simply by flashing a zip package in recovery.

back on track: the device in question is Huawei Y560-L01, and it was bricked during a very cautious and conservative test: the cache partition was shrunk by 1 MiB and the start of the next partition, recovery, was moved closer to the beginning of the disk by a similar amount. this was done to test whether the bootloader gets its partition info from the standard GPT, or whether it relys on some other hypothetical proprietary data structure. after this change, bootling recovery might suceed or fail, according to this key piece of information.

no other partitions were touched. the device's ability to boot android should have not been affected. much less its ability to boot to fastboot. however, after the change was made without incident, the device faild to even boot to fastboot and started being recognized as "Qualcomm HS-USB Diagnostics 900E" by Windows.

if you rule out freak incidents like the device having a hardware malfunction during repartitioning (which of course i do), then IMHO the only explanation that remains is this: Qualcomm, in its infinite wisdom, started locking down the GPT with digital signatures.

this idea is not completely crazy and has some traction: the bootloader has to read the GPT and parse it before reading any partitions. this means that the GPT parser is part of the attack surface of the bootloader: craft a malformed GPT that can confuse and exploit the bootloader and chain-load a kernel, and then your device will be "hacked" every time you power it on and transparently load an unsigned kernel.

now, instead of writing a trustworthy GPT parser (a task that is not that complex btw), Qualcomm could have sidestepped the issue by verifying the signature of the GPT before parsing it. this reduces the attack surface of the bootloader given that the signature verifier is necessarily already part of the attack surface.

on the other hand, this has a nasty unintended consequence: bootloaders cannot really be fully unlocked anymore. you see, the data structure embodying the lock/unlock status of the eMMC is -to save money- persisted on the eMMC itself. but said data typically resides in a partition and thus cannot be accessed before parsing the GPT, which means that the lock/unlock status is only known after the GPT signature passed; with the unavoidable side-effect that GPT signature checking cannot be disabled.

it is worth noting at this point that the bricked Huawei device was in fact fastboot-unlocked.

selling devices under the pretext that their bootloader is unlockable when in fact that is only a half-truth can make OEMs liable to false advertising charges. not to mention that after withholding this vital information from customers, and thus causing bricks, manufactures should at least offer downloadable stock flashing tools or free repairs.

assuming that the hypothesis of locked-down GPTs in otherwise unlocked devices is true, i would like to know what Huawei will do to remedy this situation for the unfortunate customer of theirs who exercised his alleged freedom on his Huawei device and ended up with a brick.

it might be true that this is all Qualcomm's doing, and that Huawei was not even "consciously aware" of this issue, and that this issue might affect Qualcomm-based products by other OEMs. but still, this happened on a Huawei device; and their response, if any, will surely influence my buying decisions in the future.

[Lanchon]

i pulled yet another binge browsing all-nighter and ended up reading excellent trustzone and bootloader exploit write-ups by security researcher @laginimaineb.

i had tried googling info about GPT locking to no avail, but yesterday i just stumbled upon confirmation when i read his write-up about unlocking the moto bootloader via exploits. relevant to this discussion is a closing comment towards the end of the article that says:

In this blog post we went over the flow controlled by a single QFuse. But, as you can probably guess, there are many different interesting QFuses out there, waiting to be discovered.

[...]

One such example is the "engineering" fuse; this fuse is mentioned throughout the aboot image, and can be used to enable an amazing range of capabilities such as skipping secure boot, loading unsigned peripheral images, having an unsigned GPT, and much more.

so there... he mentions signed GPTs in the most matter-of-fact way :)

i'd like to invite @laginimaineb to join this issue and let us know where or how he found out about GPT signing, and more importantly, to maybe shed some light on which bootloaders, which SoCs, which OEMs, we can expect to have locked-down GPTs. this can help us avoid a repeat of the nasty Huawei bricking.

---

as a bonus, his article also shows that some bootloaders (eg, moto's) use a fuse to store the bootloader unlock state, instead of using the eMMC. of course this means that the locked/unlocked flag can only be toggled once on these devices.

this invalidates the following comment of mine, albeit only for these devices:

the data structure embodying the lock/unlock status of the eMMC is -to save money- persisted on the eMMC itself. but said data typically resides in a partition and thus cannot be accessed before parsing the GPT, which means that the lock/unlock status is only known after the GPT signature passed; with the unavoidable side-effect that GPT signature checking cannot be disabled.

so yes, the QFuse embedded in the SoC can be read before ever touching the eMMC, meaning that the bootloader on these devices could easily disable signature checking of the GPT. whether they do or not, i have no idea.

the devices i had previously looked into (Nexus 4, Nexus 5, OnePlus One, and one of the Nexus 7 tablets) all store the bootloader unlock state on the eMMC and the toggle is fully reversible. i do not know about newer devices, but i sure hope tinkerer-friendly OEMs such as Google and OnePlus keep allowing unlock reversal. i can't think of a valid reason to disallow this, and i would seriously consider not buying a device in which unlocking is non-reversible.

[laginimaineb]

Hi Lanchon,

Thanks for the kind words! I'm happy to hear you enjoyed my blog posts.

Unfortunately I don't have much to contribute to this discussion; I've only ever looked into bootloader unlocking when dealing with my own Moto X... Regardless, as for the GPT validation, I simply saw a string referencing this feature ("engineer hw, skip gpt validation") in the Moto's aboot image, following a check for the engineering fuse I mentioned.

Cheers, Gal.

[Lanchon]

thanks, that's great info!!

strings /dev/block/.../aboot | grep -i gpt and you might have just saved us a few bricks! :)

thanks again, and yes your articles are fantastic.

[laginimaineb]

My pleasure! The aboot image for the Moto X seems to refer to the signature checking function as "validate_gpt_image". It also seems to have a backup GPT image which is validated if the original validation check fails, in case that's useful to you.

[Lanchon]

i just ran strings on falcon's (Moto G 2013) motoboot.img and found Need a valid, signed GPT. there is also a lot of stuff about GPT validation, but validation is more extensive than signing and does not really imply it.

btw, the bootloader most probably does not have a backup GPT. there are strings naming primary/backup/alternate GPTs:

Failed to read primary GPT
primary gpt validation result: %s
Failed to read alternate GPT
invalid backup GPT header
alternate gpt validation result: %s
Alternate GPT is identical to Primary GPT.
Invalid protective mbr, check alternate gpt
Flashing primary GPT image...
Found partition %s in alternate GPT
Failed to write primary GPT.
Flashing backup GPT image...
Failed to write EFI backup GPT header.
Failed to write EFI backup GPT entries.
primary_gpt
backup_gpt
Invalid primary GPT, validating backup GPT...
failed to load backup GPT
Invali backup GPT
Failed to restore primary GPT
Failed to update backup GPT

but they probably refer to GPT's standard backup that is stored towards the end of the disk: https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg

EDIT: and the flashable gpt.bin is, in fact, signed.

EDIT: these findings are valid for both KK 4.4.4 and LP 5.1 versions of the GPE firmware.

[Lanchon]

there has been a new development regarding detection of GPT signatures via strings in the bootloader. it is now known that this method can result in false positives.

please see the details here.

[akiratoriyama]

Is there any way to recovery a device from this? Device in case is a Xiaomi Redmi Note 4X "mido" on which I was trying the same partitioning voodoo. It just shows up as 900E on my PC, and no Qualcomm tools including QPST can toggle it to 9008 DL mode.

[Lanchon]

i guess it's JTAG or service, i'm afraid.

[vladimiroltean]

Hi @Lanchon, I appreciated reading through this discussion, but I'm not clear on what the final word on these so-called "GPT signatures" is. I'm sure you are aware that Qualcomm bootloader source code is available at https://source.codeaurora.org/quic/la/kernel/lk/. Inside the lk source code, the only references to GPT signatures are in the platform/msm_shared/include/partition_parser.h file:

/* GPT Signature should be 0x5452415020494645 */
#define GPT_SIGNATURE_1 0x54524150
#define GPT_SIGNATURE_2 0x20494645

These "signatures" are clearly not Qualcomm's invention :)

[Lanchon]

hmmm, interesting... no i haven't looked at the code, didn't know it was there. as i remember, there were strings in bootloader binaries hinting GPT signature checks. preprocessor symbols would not normally end up as strings. i might look into this again some day. thanks for the report and sorry for the late reply!