Stage2: Difference between revisions

Line 122:

Note that the above format resembles the [[DSi Cartridge Header]] (entries 0x20-0x3F are roughly similar, and entries 0x180-0x1AF appear to be same as in cart header).

The RSA pubks(the one for 3DS and the other one for DSi) for the below signature can be obtained from 3DS TWL_FIRM Process9(this is required for getting the binaries' keyY). It's unknown(?) if the DSi bootrom(s) copy this modulo to anywhere outside of bootrom.

~~Below is some interesting info on~~ the ~~RSA Data Block, but it's unclear if or how that data block has been decrypted,~~ and ~~if it has been done on~~ DSi or 3DS (~~or both).~~

~~In practice, bootcode decryption isn~~'~~t possible because the RSA key is unknown,~~ keyY ~~is also unknown (when not knowing the RSA key~~)~~, and keyX is also unknown (it~~'s ~~said to be same as for Tad; which is~~ unknown~~, it isn't included in the "srl extract" utility~~)~~, and~~ the ~~"binblksize" value for CTR is also unclear~~ (~~it might be same as "'''binblk->'''binbl'''oc'''ksize" though~~).

Structure of the 0x74-byte "hash-data" stored in the RSA message:

Line 164:

Line 161:

Whereas the filesystem data in NAND is encrypted using a unique key for every DSi, the stage2 bootloader is identical on every DSi tested so far. The stage2 bootloader binaries are not encrypted with any console-unique keys.

Stage1 uses the [[AES_Engine]] to decrypt each ARM9/ARM7 binary, where keyY is from the above signature. The [[AES_Engine]] keyslot used here is the same one used for the shared areas for [[Tad]], therefore the keyX is the same as the one used for that. The following is used for the CTR, where "binblk->binblocksize" is the ~~actual~~ binary size:

Stage1 uses the [[AES_Engine]] to decrypt each ARM9/ARM7 binary, where keyY is from the above signature. The [[AES_Engine]] keyslot used here is the same one used for the shared areas for [[Tad]], therefore the keyX is the same as the one used for that. The following is used for the CTR, where "binblk->binblocksize" is the above binary size aligned to 0x200-bytes:

unsigned int ctr[4];

@@ Line 122: / Line 122: @@
 Note that the above format resembles the [[DSi Cartridge Header]] (entries 0x20-0x3F are roughly similar, and entries 0x180-0x1AF appear to be same as in cart header).
+The RSA pubks(the one for 3DS and the other one for DSi) for the below signature can be obtained from 3DS TWL_FIRM Process9(this is required for getting the binaries' keyY). It's unknown(?) if the DSi bootrom(s) copy this modulo to anywhere outside of bootrom.
-Below is some interesting info on the RSA Data Block, but it's unclear if or how that data block has been decrypted, and if it has been done on DSi or 3DS (or both).
-In practice, bootcode decryption isn't possible because the RSA key is unknown, keyY is also unknown (when not knowing the RSA key), and keyX is also unknown (it's said to be same as for Tad; which is unknown, it isn't included in the "srl extract" utility), and the "binblksize" value for CTR is also unclear (it might be same as "'''binblk->'''binbl'''oc'''ksize" though).
 Structure of the 0x74-byte "hash-data" stored in the RSA message:
@@ Line 164: / Line 161: @@
 Whereas the filesystem data in NAND is encrypted using a unique key for every DSi, the stage2 bootloader is identical on every DSi tested so far. The stage2 bootloader binaries are not encrypted with any console-unique keys.
-Stage1 uses the [[AES_Engine]] to decrypt each ARM9/ARM7 binary, where keyY is from the above signature. The [[AES_Engine]] keyslot used here is the same one used for the shared areas for [[Tad]], therefore the keyX is the same as the one used for that. The following is used for the CTR, where "binblk->binblocksize" is the actual binary size:
+Stage1 uses the [[AES_Engine]] to decrypt each ARM9/ARM7 binary, where keyY is from the above signature. The [[AES_Engine]] keyslot used here is the same one used for the shared areas for [[Tad]], therefore the keyX is the same as the one used for that. The following is used for the CTR, where "binblk->binblocksize" is the above binary size aligned to 0x200-bytes:
    unsigned int ctr[4];