Difference between revisions of "Nand/private/movable.sed"

From 3dbrew
Jump to navigation Jump to search
(Add information about "impossible" consoles with uninitialized movable.sed files. See github issue for context.)
 
(18 intermediate revisions by 5 users not shown)
Line 10: Line 10:
 
| 0x4
 
| 0x4
 
| 0x4
 
| 0x4
−
| This u8 must be zero
+
| When u8[1] is non-zero, this indicates that the additional 0x20-bytes AES-MAC block at the end of movable.sed exists. If u8[1] is zero, then u8 [0], [2], and [3] must be zero as well.
 
|-
 
|-
 
| 0x8
 
| 0x8
−
| 0x100
+
| 0x110
−
| RSA-2048 signature over the 0x10-byte data at 0x108
+
| Copied from [[Nandrw/sys/LocalFriendCodeSeed_B]] (or LocalFriendCodeSeed_A if it exists). The last 8 bytes (LocalFriendCodeSeed) becomes the first 8 bytes of a [[AES]] engine keyY for 3 keyslots
−
|-
 
−
| 0x108
 
−
| 0x10
 
−
| ?
 
 
|-
 
|-
 
| 0x118
 
| 0x118
 
| 0x8
 
| 0x8
−
| Last 8-bytes of an [[AES]] engine keyY for 3 keyslots
+
| The higher 8 bytes of the keyY
 +
|-
 +
| 0x120
 +
| 0x20
 +
| 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. The last 0x10-bytes in this block is an AES-MAC over a SHA256 hash, using the same keyslot used for NAND [[Title_Database|dbs]]. This hash is calculated over the first 0x130-bytes of movable.sed. This AES-MAC is verified is during movable.sed verification(before RSA verification).
 
|}
 
|}
  
−
This file is transferred to the destination 3DS during a [[System Transfer]], the source 3DS then uses a new file retrieved from the shop server. This keyY is the console-unique portion of these 3 keyslots. All of the data under [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]] use these console-unique keyslots. It's unknown where the first 8-bytes of the keyY is loaded from.
+
This keyY is the console-unique portion of the 3 keyslots used for everything stored under [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|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 [[FS:InitializeCtrFileSystem|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 [[Filesystem_services_PXI|file-read]] code-path return value is 0xC8804464) the system will fall-back to using a console-unique keyY already in [[PSPXI:GetLocalFriendCodeSeed|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 [[SVC|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.
  
−
Movable.sed always exists on retail, however if this file doesn't exist the system will fall-back to using a console-unique keyY already in memory. Therefore, movable.sed presumably doesn't exist on development units.
+
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used with the below snprintf for ID0 in [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. ID0 is generated by: snprintf(outdirname, maxlen, "%08x%08x%08x%08x", hashword[0], hashword[1], hashword[2], hashword[3]). Thus, ID0 is the first half of the SHA-256 of movable.sed bytes 0x110-0x11F inclusive, with the four u32s of the half-SHA-256 byte-flipped.
  
−
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used for ID0 in [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]].
+
'''Note:''' It has been observed at least 2 times that the 0x120+ part has been left uninitialized, yet the 3DS is still working without any form of modfication, behaving just as if it was initialized and working just fine with Custom Firmware installed.
 +
It is currently unknown why this is the case, but the following information holds true for both systems:
 +
* They are Old 3DS Retail Consoles from Europe
 +
* They were shipped with Firmware version 1.0.0-0E
 +
* Their Serial Number starts with CEM10, differ from there on
 +
* SoC manufacturing date of 2010
 +
* They have not been formatted, ever
 +
More details [https://github.com/d0k3/GodMode9/issues/318 on this Github Issue]

Latest revision as of 16:08, 26 February 2018

Offset Size Description
0x0 0x4 Magic "SEED"
0x4 0x4 When u8[1] is non-zero, this indicates that the additional 0x20-bytes AES-MAC block at the end of movable.sed exists. If u8[1] is zero, then u8 [0], [2], and [3] must be zero as well.
0x8 0x110 Copied from Nandrw/sys/LocalFriendCodeSeed_B (or LocalFriendCodeSeed_A if it exists). The last 8 bytes (LocalFriendCodeSeed) becomes the first 8 bytes of a AES engine keyY for 3 keyslots
0x118 0x8 The higher 8 bytes of the keyY
0x120 0x20 This data is written to the file when doing a System Format. The original movable.sed from the factory is only 0x120-bytes. The last 0x10-bytes in this block is an AES-MAC over a SHA256 hash, using the same keyslot used for NAND dbs. This hash is calculated over the first 0x130-bytes of movable.sed. This AES-MAC is verified is during movable.sed verification(before RSA verification).

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]). Thus, ID0 is the first half of the SHA-256 of movable.sed bytes 0x110-0x11F inclusive, with the four u32s of the half-SHA-256 byte-flipped.

Note: It has been observed at least 2 times that the 0x120+ part has been left uninitialized, yet the 3DS is still working without any form of modfication, behaving just as if it was initialized and working just fine with Custom Firmware installed. It is currently unknown why this is the case, but the following information holds true for both systems:

  • They are Old 3DS Retail Consoles from Europe
  • They were shipped with Firmware version 1.0.0-0E
  • Their Serial Number starts with CEM10, differ from there on
  • SoC manufacturing date of 2010
  • They have not been formatted, ever

More details on this Github Issue

Retrieved from "https://www.3dbrew.org/w/index.php?title=Nand/private/movable.sed&oldid=20619"