Difference between revisions of "Nand/private/movable.sed"
| Line 23: | Line 23: | ||
| 0x10 | | 0x10 | ||
| [[AES]] engine keyY for 3 keyslots (High u64 is unsigned) | | [[AES]] engine keyY for 3 keyslots (High u64 is unsigned) | ||
| + | |- | ||
| + | | 0x120 | ||
| + | | 0x20 | ||
| + | | Unknown, this data is written to the file when doing a [[System Settings|System Format]]. The original movable.sed from the factory is only 0x120-bytes, only the first 0x120-bytes of movable.sed are read when loading the keyY/etc. | ||
|} | |} | ||
Revision as of 07:31, 31 December 2013
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x4 | Magic "SEED" |
| 0x4 | 0x4 | This u8 must be zero |
| 0x8 | 0x100 | RSA-2048 signature over the 0x10-byte data at 0x108 |
| 0x108 | 0x8 | Usually zero |
| 0x110 | 0x10 | AES engine keyY for 3 keyslots (High u64 is unsigned) |
| 0x120 | 0x20 | Unknown, this data is written to the file when doing a System Format. The original movable.sed from the factory is only 0x120-bytes, only the first 0x120-bytes of movable.sed are read when loading the keyY/etc. |
This keyY is the console-unique portion of the 3 keyslots used for everything stored under sdmc/Nintendo 3DS/<ID0>/<ID1> and nand/data/<ID0>. For SD this is used for encryption and AES MACs, however for NAND this is only used for AES MACs. This file is transferred to the destination 3DS during a System Transfer. The movable.sed keyY high u64 is updated on the source 3DS during a System Transfer, and when doing a system format with System Settings.
Movable.sed always exists on retail and development units(written to NAND at the factory), however if reading this file fails(svcBreak would be executed if the file-read code-path return value is 0xC8804464) the system will fall-back to using a console-unique keyY already in memory, with the last 8-bytes being loaded from the 8-bytes following that u64. On development units the code-path handling movable.sed would execute svcBreak if file-reading(regardless of error-code) or verifying the RSA signature fails(this would brick the 3DS), RSA verification failure on a retail unit here would also cause a brick.
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used with the below snprintf for ID0 in sdmc/Nintendo 3DS/<ID0>/<ID1> and nand/data/<ID0>. ID0 is generated by: snprintf(outdirname, maxlen, "%08x%08x%08x%08x", hashword[0], hashword[1], hashword[2], hashword[3]).