Bypass bootloader signiture check

We found that there is a "logical bug" inside ZTE axon7's bootloader. that is we can generate a keystore.img,then flash it to phone's keystore partition. and we sign the boot and recovery images with our customized private key. so if the bootloader verifyed the boot image with oem key store in bootloader it will falied,but with the keystore in keystore partition it will success.
in Google's implementation, the bootloader will show a yellow page,to tell you the boot is not official.but in ZTE's implementation.the bootloader shows nothing,it just loads the boot image and boot into the system.
that is how i do the rooting with bootloader locked.
easy? ha.

this is the conceptions we used.

Keystore

Why use a keystore?

To go from ORANGE screen to YELLOW screen. This will help ensure that even with a custom ROM, your system hasn't been compromised. On boot, you'll get the YELLOW screen, giving you the fingerprint of the keystore. To ensure safety, check the fingerprint is always the same. DO NOT stop at the first letters. Better know random letters than first letters.

How to generate keystore keys?

/path/to/make_key keystore '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com'

Obviously the second string is meant to be replaced.

How to generate keystore image?

openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8 /path/to/keystore_signer keystore.pk8 keystore.x509.pem keystore.img keystore.pub.pk8

#How to sign the boot and recovery image

java -jar /path/to/BootSignature.jar /boot new-boot.img keystore.pk8 keystore.x509.pem new-boot.img.signed

How to flash the signed boot to phone

we use qualcomm's firehose protocal to flash boot.img to phone partition.that's what axon7root.exe do.

Conceptions

Boot state

The boot state of the device describes the level of protection provided to the end user if the device boots. Boot states are GREEN, YELLOW, ORANGE, and RED.

Device state

The device state indicates how freely software can be flashed to the device. Device states are LOCKED and UNLOCKED.

In addition to device state—which already exists in devices and controls whether the bootloader allows new software to be flashed—verified boot introduces the concept of boot state that indicates the state of device integrity.

Classes

Two implementation classes exist for verified boot. Depending on how fully the device implements this specification, they are defined as follows:

Class A implements verified boot with full chain of trust up to verified partitions. In other words, the implementation supports the LOCKED device state, and GREEN and RED boot states.

Class B implements Class A, and additionally supports the UNLOCKED device state and the ORANGE boot state.

Verification keys

Bootloader integrity is always verified using a hardware root of trust. For verifying boot and recovery partitions, the bootloader has a fixed OEM key available to it. It always attempts to verify the boot partition using the OEM key first and try other possible keys only if this verification fails.

In Class B implementations, it is possible for the user to flash software signed with other keys when the device is UNLOCKED. If the device is then LOCKED and verification using the OEM key fails, the bootloader tries verification using the certificate embedded in the partition signature. However, using a partition signed with anything other than the OEM key results in a notification or a warning, as described below.

Boot state

A verified device will ultimately boot into one of the four states during each boot attempt:

GREEN, indicating a full chain of trust extending from the bootloader to verified partitions, including the bootloader, boot partition, and all verified partitions.
YELLOW, indicating the boot partition has been verified using the embedded certificate, and the signature is valid. The bootloader displays a warning and the fingerprint of the public key before allowing the boot process to continue.
ORANGE, indicating a device may be freely modified. Device integrity is left to the user to verify out-of-band. The bootloader displays a warning to the user before allowing the boot process to continue.
RED, indicating the device has failed verification. The bootloader displays a warning and stops the boot process.
The recovery partition is verified in the exact same way, as well.

Device state

The possible device states and their relationship with the four verified boot states are:

LOCKED, indicating the device cannot be flashed. A LOCKED device boots into the GREEN, YELLOW, or RED states during any attempted boot.
UNLOCKED, indicating the device may be flashed freely and is not intended to be verified. An UNLOCKED device always boots to the ORANGE boot state.

how the bootloader works

Credit

@phhusson for super-bootimg .this the tool i used to generate keystore and sign the image file.
@Google for documentation.
@ZTE for firehose programmer.