[Miscellaneous Android Development] techyzen101:
Introduction

The System-On-a-Chip the device runs on is enforced with a proprietary secure-boot. Nothing but official images and binaries are accepted to be flashed.​

Background

Booting goes through three stages: bootrom, bootloader and kernel. According to documents about secure boot on these chips is that there is a root certificate existing on the hardware with a chain-of-trust security protocol. Each phase checks the binaries the other contains.

To generate a header, we need a key pair. A key pair consist of a password of exactly eight ASCII characters together with a key of not more than forty-nine characters. In the Spreadtrum document referenced below the key is treated as the product name.

The signing process needs three key pairs found in sig_keys.ini that will be read by RSAKeyGen and generate keys.db. The generated keys.db will always be referenced by the signing tools along with sig_bins.ini which contains the filename inputs and outputs.

Now the first and second key pairs are used to sign fdl1.bin and u-boot-spl-16k.bin with BscGen. Second and third key pairs are used to sign fdl2.bin and u-boot.bin with VLRSign. The last one is used alone to sign boot.img and recovery.img with VLRSign. The RSA + hash of the file is prepended and appended to the first two sets of boot files, and the rest have it only prepended.

In the Spreadtrum document, it stated that only the hash value of the first boot binary, in this case fdl1.bin should match the hash stored in the chip.

Reading through the document some more, it has come to my attention that apparently the hash of the signed boot binary is what the chip holds. It emphasized protection of the key.db because it contains randomly generated RSA for the key pair. I've compared two identical key pair sets and it does what it stated. Losing the key.db means the board is scrapped if it were in manufacturing.

That closes our brute force attack option sad to say.
​

Digging Around The Binaries

Having the u-boot binaries on hand I managed to extract two oem commands:

oem get-psid
oem get-bootinfo

oem get-psid:

(bootloader) SN:Y541XXXXXXXXXXXX-XXXXX

OKAY [ 0.007s]
Finished. Total time: 0.007s

oem get-bootinfo:

(bootloader) INFO:unlocked

OKAY [ 0.015s]
Finished. Total time: 0.015s

As you can see its just information commands and yes, the bootloader is unlocked, which is bogus. There was never an unlock code given by Huawei upon contacting them. They said the device isn't supported in the database, which funny enough is true, because there was no oem unlock command to begin with.

I hope I'm wrong, though a few related documents about security itself is that companies do either allow or deny you of control to unlocking. Unless Huawei gives us the key.db we will be going nowhere with brute force method.​

Engineering Mode

One can open the engineering application to debug and show more information about the device by dialing:

*#*#83781#*#*

The documents stated something about checking if the hash is written on the chip by going to HARDWARETEST tab. My device just says hash value written. Kept our hopes up I know.

Navigating to DEBUG&LOG you will find System Info. Click on that and then click on Version Info.

My device:

Platform Version: MOCORTM_14B_TSHARK28_HUAWEI_W15.34_P5_Debug
Project Version: sc7731g_CP0_modem
BASE Version: TM_BASE_MP_II_HUAWEI_W16.06
HW Version: sc7731g_CP0_modem
Release Date: 02-18-2016 10:02:37

This might come in handy for finding source codes, and also possibly prevent flashing the wrong firmware.
​

Entrypoint

Our only option right now is finding exploits on the bootloader since we do have some of the source codes to base off on. Check the relevant repository link below.​

Final Thoughts

This device is a headache to be honest. I've been scouring everything I could find about it since 2016. Much appreciated if an able body can proceed to help, or just go to Huawei Support and ask them through e-mail.

The instructions for using the signing tool is in the GitHub repository linked below and a related paper for the interested.

In any case this post will continue to be updated.​

Resources

Spreadtrum Secure Boot Tools

Spreadtrum Secure Boot Document (Chinese)

Other Spreadtrum Secure Boot Document (Chinese)

Chipram Repository