Nand/private/movable.sed - Revision history

Marenthyu: Add information about "impossible" consoles with uninitialized movable.sed files. See github issue for context.

2018-02-26T14:08:20Z

Add information about "impossible" consoles with uninitialized movable.sed files. See github issue for context.

← Older revision		Revision as of 17:08, 26 February 2018
Line 30:		Line 30:

	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 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.

			'''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]

Myria: punctuation

2018-02-19T20:27:50Z

punctuation

← Older revision		Revision as of 23:27, 19 February 2018
Line 29:		Line 29:
	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 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.		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.

Myria: Added note that the snprintf implies byte flipping.

2018-02-19T20:25:37Z

Added note that the snprintf implies byte flipping.

← Older revision		Revision as of 23:25, 19 February 2018
Line 29:		Line 29:
	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 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]).		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.

Wwylele: Reword together with page Nandrw/sys/LocalFriendCodeSeed_B. Correct me if I interpreted it wrong.

2017-04-18T16:33:56Z

Reword together with page Nandrw/sys/LocalFriendCodeSeed_B. Correct me if I interpreted it wrong.

← Older revision		Revision as of 20:33, 18 April 2017
Line 14:		Line 14:
	\| 0x8		\| 0x8
	\| 0x110		\| 0x110
	\| Copied from [[Nandrw/sys/LocalFriendCodeSeed_B]] (or LocalFriendCodeSeed_A if it exists)		\| 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
	\| ~~[[AES]] engine high~~ keyY ~~for 3 keyslots~~		\| The higher 8 bytes of the keyY
	\|-		\|-
	\| 0x120		\| 0x120

TuxSH at 20:00, 5 February 2017

2017-02-05T19:00:27Z

← Older revision		Revision as of 22:00, 5 February 2017
Line 13:		Line 13:
	\|-		\|-
	\| 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)
	\|-		\|-
	\| ~~0x108~~		\| 0x118
	\| 0x8		\| 0x8
	~~\| Usually zero~~		\| [[AES]] engine high keyY for 3 keyslots
	\|-
	~~\| 0x110~~
	~~\| 0x10~~
	\| [[AES]] engine keyY for 3 keyslots ~~(High u64 is unsigned)~~
	\|-		\|-
	\| 0x120		\| 0x120

Plutooo at 22:36, 18 March 2014

2014-03-18T21:36:50Z

← Older revision		Revision as of 00:36, 19 March 2014
Line 10:		Line 10:
	\| 0x4		\| 0x4
	\| 0x4		\| 0x4
	\| ~~u8 [0], [2], and [3] must be zero.~~ When u8 [1] is non-zero, this indicates that the additional 0x20-bytes block at the end of movable.sed exists, ~~thus this enables verifying the AES-MAC~~.		\| 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

Yellows8 at 05:53, 28 January 2014

2014-01-28T04:53:19Z

← Older revision		Revision as of 07:53, 28 January 2014
Line 10:		Line 10:
	\| 0x4		\| 0x4
	\| 0x4		\| 0x4
	\| ~~This~~ u8 must be zero		\| u8 [0], [2], and [3] must be zero. When u8 [1] is non-zero, this indicates that the additional 0x20-bytes block at the end of movable.sed exists, thus this enables verifying the AES-MAC.
	\|-		\|-
	\| 0x8		\| 0x8
Line 26:		Line 26:
	\| 0x120		\| 0x120
	\| 0x20		\| 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~~.		\| 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).
	\|}		\|}

Yellows8 at 06:31, 31 December 2013

2013-12-31T05:31:12Z

← Older revision		Revision as of 08:31, 31 December 2013
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.
	\|}		\|}

Yellows8 at 03:19, 18 December 2013

2013-12-18T02:19:25Z

← Older revision		Revision as of 05:19, 18 December 2013
Line 27:		Line 27:
	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]].		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(written to NAND at the factory), however if this file ~~doesn't exist~~ 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. ~~It's unknown whether~~ movable.sed ~~exists~~ on ~~development units~~.		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]).		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]).

Yellows8 at 16:41, 2 September 2013

2013-09-02T14:41:58Z

← Older revision		Revision as of 18:41, 2 September 2013
Line 27:		Line 27:
	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]].		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, however if this file doesn't exist 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. It's unknown whether movable.sed exists on development units.		Movable.sed always exists on retail(written to NAND at the factory), however if this file doesn't exist 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. It's unknown whether movable.sed exists 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]).		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]).

← Older revision		Revision as of 05:19, 18 December 2013
Line 27:		Line 27:
	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]].		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(written to NAND at the factory), however if this file ~~doesn't exist~~ 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. ~~It's unknown whether~~ movable.sed ~~exists~~ on ~~development units~~.		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]).		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]).

← Older revision		Revision as of 18:41, 2 September 2013
Line 27:		Line 27:
	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]].		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, however if this file doesn't exist 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. It's unknown whether movable.sed exists on development units.		Movable.sed always exists on retail(written to NAND at the factory), however if this file doesn't exist 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. It's unknown whether movable.sed exists 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]).		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]).