So I recently picked up a ZTE Axon 7 (ZTE’s Flagship for 2016), I found myself reading through thread after thread on unlocking / rooting this device, as always the signed firehose image has been leaked.
One of the first steps of rooting/unlocking this device is using QFIL to load a signed image of TWRP, keyword here being ‘Signed.’ It appears by default, if you sign any recovery or boot image, the bootloader (LK), in a locked state will take it as being signed by the OEM, forcing a GREEN State. If you don’t sign the images however, LK will assert (reset) as it’ll return an invalid signature length.
This means SBL1 boots LK, which in turn does not check the signature of boot or recovery, only that one exists, breaking the chain of trust at LK.
With the device in a ‘Locked’ state, let’s see what’s possible:
First sign the boot or recovery image with any key:
java -jar BootSignature.jar /boot ~/Axon7-LineageOS/boot.img ../testkey.pk8 ../testkey.x509.der Axon-7-boot-signed.img
Confirming the device is in a ‘Locked’ state, use the leaked firehose image to flash the new boot.img to the device, the device will boot successfully in a GREEN state.
Let’s do a super quick demo with TWRP:
Okay, why is this bad?
This is bad for a number of reasons, the first and foremost reason is anyone can pickup your device and load an implant at the kernel (flash a compromised boot image) meaning even if you have encrypted your userdata, an attacker could load their boot.img into your device, power it off and send the key to a server when you power on and re-enter the password.
What versions of LK does this affect?
I’ve tested B19 (ZTE’s latest SHA256: bc775d7c77027ed33214b20d11f25f59b6b45e93264ad29f8431cf66070c4077) and the unlock-able version, I would guess anything inbetween.