3
edits
Changes
Jump to navigation
Jump to search
mLine 53:
Line 53: − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + − + − + − + − + − |} − − Structure of the binary-block headers: − {| border="1" cellpadding="3" cellspacing="0" − ! Offset − ! Size − ! Description − + − + − + − + − + − + − + − + − + − + − + + + + + Line 129:
Line 154: − − The 3DS TWL_FIRM verifies all TWL RSA padding with the following. It's unknown whether the DSi Stage1 has the same code as TWL_FIRM for this, the RSA padding data(not the actual hashdata) contained in the DSi bootloader signature and TWL_FIRM bootloader are the same at least. This is different from how the main DSi "BIOS" RSA padding check code does it as well. − * The first byte must be 0x0. − * The second byte must be 0x1 or 0x2. − * Executes a while(<value of byte at current pos in RSA message>). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn't matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned. − * Returns an address for msg_curpos+1. − With the code in 3DS TWL_FIRM, the actual "totalhashdatasize" in the RSA message must be <= <expected hashdata_size>(0x74 for bootloader). The 3DS TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata". Line 143:
Line 161: − + Line 149:
Line 167: − + Line 157:
Line 175: − + Line 166:
Line 184: + +
→Stage2 operations
| 0x0
| 0x0
| 0x20
| 0x20
| Reserved
| Reserved (zerofilled)
|-
|-
| 0x20
| 0x20
| 0x10*2
| 0x4
| Two binary-block headers: first one is for the ARM9 binary, second one for the ARM7 binary.
| ARM9 Bootcode, eMMC Source Offset
|-
| 0x24
| 0x4
| ARM9 Bootcode, Size "Actual binary size"
|-
| 0x28
| 0x4
| ARM9 Bootcode, RAM Destination Address and Entrypoint
|-
| 0x2C
| 0x4
| ARM9 Bootcode, Size rounded up to multiple of 0x200
|-
| 0x30
| 0x4
| ARM7 Bootcode, eMMC Source Offset
|-
| 0x34
| 0x4
| ARM7 Bootcode, Size "Actual binary size"
|-
| 0x38
| 0x4
| ARM7 Bootcode, RAM Destination Address and Entrypoint
|-
| 0x3C
| 0x4
| ARM7 Bootcode, Size rounded up to multiple of 0x200
|-
|-
| 0x40
| 0x40
| 0xBF
| 0xBF
| Reserved
| Reserved (zerofilled)
|-
|-
| 0xFF
| 0xFF
| 0x1
| 0x1
| Unknown, value 0xFF.
| Unknown, value 0xFF? (actually, this is appears to be always 0Ch, not FFh?)
|-
|-
| 0x100
| 0x100
| 0x80
| 0x80
| RSA-1024 signature
| RSA-1024 Data Block
|-
|-
| 0x180
| 0x180
| 0x80
| 0x14
| Unknown
| Global MBK1..MBK5 Slot Settings
|-
|-
| 0x0
| 0x194
| 0x4
| 0xC
| Offset for this binary in NAND.
| Local MBK6..MBK8 Settings for ARM9 Side
|-
|-
| 0x4
| 0x1A0
| 0x4
| 0xC
| Actual binary size.
| Local MBK6..MBK8 Settings for ARM7 Side
|-
|-
| 0x8
| 0x1AC
| 0x4
| 0x4
| Binary load address in memory. This is also the binary entrypoint.
| Global MBK9 Slot Master Setting
|-
|-
| 0xC
| 0x1B0
| 0x4
| 0x50
| Binary size aligned to 0x200-bytes.
| Reserved (zerofilled)
|}
|}
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.
Structure of the 0x74-byte "hash-data" stored in the RSA message:
Structure of the 0x74-byte "hash-data" stored in the RSA message:
| Unknown, not used by 3DS TWL_FIRM.
| Unknown, not used by 3DS TWL_FIRM.
|}
|}
Note that this sector (and two similar ones at 0x400 and 0x600) appear to be the only unencrypted blocks on the NAND flash.
Note that this sector (and two similar ones at 0x400 and 0x600) appear to be the only unencrypted blocks on the NAND flash.
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.
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]] with mode AES-CTR 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];
unsigned int ctr[4];
ctr[0] = binblk->binblocksize;
ctr[0] = binblk->binblocksize;
ctr[1] = (unsigned int)(-binblksize);
ctr[1] = (unsigned int)(-binblk->binblocksize);
ctr[2] = ~binblk->binblocksize;
ctr[2] = ~binblk->binblocksize;
# Sector 0 is read from the NAND. This appears to be an (encrypted) DOS-style MBR.
# Sector 0 is read from the NAND. This appears to be an (encrypted) DOS-style MBR.
# The MBR signature and the type of the first partition are verified.
# The MBR signature and the type of the first partition are verified.
# Filesystem metadata is read from sectors starting around 0x100000. The metadata appears to be in FAT32 format with long filenames.
# Filesystem metadata is read from sectors starting around 0x100000. The metadata is in FAT16 format with long filenames.
# Multiple files are loaded from the filesystem. The exact read addresses will vary depending on your DSi's firmware version and the state of its filesystem when you performed the last firmware update. On a brand new DSi, it appears that the DSi Menu itself is loaded from 0xb20000 after two small metadata files are read from 0xb1c000 and 0x7a0000.
# Multiple files are loaded from the filesystem. The exact read addresses will vary depending on your DSi's firmware version and the state of its filesystem when you performed the last firmware update. On a brand new DSi, it appears that the DSi Menu itself is loaded from 0xb20000 after two small metadata files are read from 0xb1c000 and 0x7a0000.
|-
|-
| "Error: 1-2435-8325" || Invalid signature or partition type in MBR, invalid starting LBA.
| "Error: 1-2435-8325" || Invalid signature or partition type in MBR, invalid starting LBA.
|-
| "Error: 2-2435-8325" || Invalid Firmware
|-
|-
| "Error: 3-2435-8325" || DSi Menu integrity checks failed
| "Error: 3-2435-8325" || DSi Menu integrity checks failed
|-
|-
|}
|}