Hello, today i was trying to port openwrt to a new router that is based on ipq4019
I compiled a testing dts with nand partition and i tried to flash it using FW_RECOVERY function
With my joy... The flash failed as the firmware is not signed...
Done!
Bytes transferred = 6029445 (5c0085 hex)
Board SecureBoot is enabled
MAGIC NUMBER = 0xd00dfeed
FW is not SIGNED
Upgrade Kernel image authentication failed
Image did not pass SecureBoot authentication,it is forbidden to be written to flash!!
Does anyone came across this? Anyway to solve this ?
Seems this U-Boot does use signed fit images...
The feature for required signed configs or images in fit images is from original U-Boot.
But the messages printed on serial are for sure not from original U-Boot... This must be custom from the soc or device vendor.
Do you have access to the U-Boot console?
If yes, can you post your U-Boot environment?
If no, i think the only solution is to flash another bootloader.
Or you can try to figure out how this can be disabled or something else by using the gpl source...
If it works by blowing eFuses than for sure this checks are c code and no environment setting.
Sadly i think you have to look for a hole in there "Secure Boot" implementation...
I think you have also no serial console availabe for flashing your custom u-boot?
The only solution will be finding a security hole or flashing new fw (u-boot) with a hw programmer...
nono wait I have uboot access by serial and also a command to update uboot... so i can compile and flash my uboot but... you know... flash uboot is always risky ...
Interesting
i know that this is very risky, but a restricted device is not a good device for somebody like us
Probably you can boot your compiled u-boot from ram before flashing...
I´m interested in the secure boot impl and the other restrictions to make the device "secure".
Can you post the available commands, the environment and which devices you have?
This might not be fully related, but it could be the case the chain of trust does not start at the U-Boot.
AVM has implemented signature validation for the bootloader from the SBL via (from what it seems) the TrustZone/QSEE in their newer IPQ4019 models (7520 / 3000 / 1200). They utilize it to have two bootloaders (not U-Boot but EVA in AVMs case). This way, they can update the bootloader with minimum risk for power-cuts / bad blocks.
You can find some clues on how this works in their GPL code (osp.avm.de). However, they do not (yet) enforce signature validation in EVA.
