Changes

| 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

|-

|-

| 0x118

| 0x118

| 0x8

| 0x8

| Last 8-bytes of an [[AES]] engine keyY for 3 keyslots

| The higher 8 bytes of the keyY

| 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. The keyslots this keyY is loaded to is the keyslots used for SD data. This keyY is the console-unique portion of these 3 keyslots. The 16-character sub-directories under the SD card "/Nintendo 3DS" directory have their directory names generated using this file.

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.

 

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.

 

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 have not been formatted, ever

More details [https://github.com/d0k3/GodMode9/issues/318 on this Github Issue]