108
edits
Changes
Jump to navigation
Jump to search
Line 53:
Line 53: − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + − + − + − + − + − |} − − Structure of the binary-block headers: − {| border="1" cellpadding="3" cellspacing="0" − ! Offset − ! Size − ! Description − + − + − + − + − + − + − + − + − + − + − + + + + + Line 150:
Line 175: − +
no edit summary
| 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 MBK8..MBK9 Settings for ARM9 Side
|-
|-
| 0x4
| 0x1A0
| 0x4
| 0xC
| Actual binary size.
| Local MBK8..MBK9 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)
|}
|}
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:
Structure of the 0x74-byte "hash-data" stored in the RSA message:
# 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.