[Fire TV Original Android Development] Pro-me3us:
At power on Amlogic devices will print a string of SOC information that starts with G12B:BL....

in that string is F2FB39B0:432060. The 2 values report the security efuse status for the device. 32bit values:

CFG9: 0x00432060

CFG10: 0xF2FB39B0

Following 7273/2625 there is a 1 bit change in CFG10

CFG10: 0xF2FB39B0 (pre 7273) = 1111 0010 1111 1011 0011 1001 1011 0000

CFG10: 0xF2F339B0 (post 7273) = 1111 0010 1111 0011 0011 1001 1011 0000

Bits are read from right to left starting with bit 0, so Flag 19 flips from 1 to 0. The security efuse table shows that an efuse was buned to disable 'IS_FEAT_USB_BOOT_ENABLE', barring DFU entry via USB.

There is little documentation on how to burn efuses, more importantly I don't know of any public information on the efuse addresses that correspond to which features. Burning efuses would have to be done through uboot and the Bl31api which is how non-secure world talks to secure world. Amazon may handle it through cmd_efuse.c, since there was an addition to that code made to disable USB boot in 2021. The following can be found in the 2nd gen Cube package from Amazon's open source page

platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/cmd_efuse.c

There are several layers of security, including encryption and signed code. The s922x contains an AES key which is static, and it can be used to decrypt the bootloader. The Cube has boot decrypt enabled, meaning that it is expecting Bl2 to be encrypted, and it will decrypt anything passed to it with the internal AES key. Amazon takes things a step further and encrypts the later bootloader stages with 3 more AES keys. So to fully decrypt the bootloader there are 4 total keys, one of which is static.

But in the case of the Cube, decryption is not an issue since we can dig to get all the keys. The keys just allow the SOC to unscramble the image. There is also signing which involves image hashes. By modifying the image, the hash changes, failing the signature check. The function of the amlogic-usbdl exploit is to bypass the code verification, not encryption.

The Bl2 signing tool is public but Bl2 is not open source. I don't know how functional the Bl2.bin is that is included in the firetv open source repository. There's likely also other security checks I'm overlooking.

If it was from a generic device without any security features implemented in the bootloader maybe? The Cube has a root key burned to it that I assume is specific to the 2nd gen Cube. I believe this is used in verifying bl2.

There would be hardware/board differences that would lead to a host of issues as well. Uboot would be missing the FireOS layer, so I would be surprised if it could hand things off properly. Bl2 would still have to be encrypted using the AES key, since the Cube has boot encrypt enabled, which is doable.

That could be tested with Amlogic's update tool in DFU.

./update write bl2.bin 0xfffa0000 //loads bl2 into memory at the run address
./update run 0xfffa0000 //executes bl2 from memroy
./update bl2_boot bootloader.img //loads and runs the rest of the bootloader into and from memory

The closest thing to Khasdas' VIM3L for the s922x is the Odroid N2/+, in terms of a developer's board with little to no security features implemented. The unsigned Cube bootloader will load fairly far on the N2+, but I don't remember if it got as far as the kernel. I never tried the reverse, loading an N2+ bootloader on the Cube.