6,264
edits
Changes
→AES key-init
Some of the Boot9 key-init appears to have a bug(?) when initializing a chunk of keyslots at once: normally it does <code>for(i=0; i<4; i++){... <setup_keyslot_keydata(keyslotbase+i, keydata)> ...}</code>, however in some cases it does that except with <code>(keyslotbase,</code> instead. This results in the keyslot specified by keyslotbase being initialized 4 times in a row, with the remaining 3 keyslots following keyslotbase being left uninitialized.
Some of the Boot9 key-init appears to have a bug(?) when initializing a chunk of keyslots at once: normally it does <code>for(i=0; i<4; i++){... <setup_keyslot_keydata(keyslotbase+i, keydata)> ...}</code>, however in some cases it does that except with <code>(keyslotbase,</code> instead. This results in the keyslot specified by keyslotbase being initialized 4 times in a row, with the remaining 3 keyslots following keyslotbase being left uninitialized.
initialize_aeskeys() works as follows:
* Validates input, calls panic() on failure. conunique_dataptr and bootrom_dataptr are both input parameters for initialize_aeskeys().
* Calls crypto_initialize().
* Then it ''basically'': copies 0x1C-bytes from conunique_dataptr to tmpbuf+0(sp+12), and copies data from bootrom_dataptr with size 0x40-0x1C to tmpbuf+0x1C(conunique_dataptr and bootrom_dataptr are updated afterwards).
* The 0x40-byte tmpbuf is hashed with SHA256.
* Keyslot 0x3F is then initialized using the above hash: keyX = first 0x10-bytes of the hash, keyY = last 0x10-bytes of the hash.
* Then with each console-unique key-init code-block: IV is loaded from bootrom_dataptr(which is updated afterwards), then the 0x40-bytes from bootrom_dataptr is encrypted with AES-CBC. The output is then used as 4 keyXs for initializing keyslots. How bootrom_dataptr is updated if at all varies per code-block. Hashing similar to the code at the start of this function is also run(when the remaining size for conunique_dataptr is non-zero), but the output hash isn't used(this code is also slightly different for one code-block).
* Once finished with that, the non-console-unique keyslots are initialized. This is done with keydata loaded directly from bootrom_dataptr.
* The last initialized keyslot is 0x3F, via normalkey. The keydata for this is copied to 0xFFF00618. This is for restoring the keydata when non-NAND FIRM boot ''fails'', since those use keyslot 0x3F with other keydata.
* Lastly it clears the 0x40-bytes at tmpbuf with the u32 loaded from bootrom_dataptr(the word following the above keyslot 0x3F keydata), then returns.