OTP Registers - Revision history

PabloMK7: Wrong size fixed

2024-11-21T12:18:48Z

Wrong size fixed

← Older revision		Revision as of 15:18, 21 November 2024
Line 76:		Line 76:
	\|-		\|-
	\| 0x90		\| 0x90
	\| ~~0x70~~		\| 0x50
	\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.		\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.

Liam at 02:21, 19 April 2023

2023-04-19T00:21:25Z

← Older revision		Revision as of 04:21, 19 April 2023
Line 34:		Line 34:
	! Size		! Size
	! Description		! Description
	\|-
	~~\| 0x0~~
	~~\| 0x90~~
	~~\| Copied into ITCM. The encrypted version of this is what New3DS-arm9loader hashes for key-generation.~~
	\|-		\|-
	\| 0x0		\| 0x0
Line 49:		Line 45:
	\| 0x8		\| 0x8
	\| 0x10		\| 0x10
	\| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the ~~last~~ two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.		\| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the first two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
	\|-		\|-
	\| 0x18		\| 0x18

SciresM at 19:28, 6 April 2019

2019-04-06T17:28:45Z

← Older revision		Revision as of 21:28, 6 April 2019
Line 53:		Line 53:
	\| 0x18		\| 0x18
	\| 0x1		\| 0x1
	\| ?		\| OTP version
	\|-		\|-
	\| 0x19		\| 0x19
	\| 0x1		\| 0x1
	\| This is the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".		\| This determines if the OTP is for a dev system; it indicates the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
	\|-		\|-
	\| 0x1A		\| 0x1A
	\| 0x6		\| 0x6
	\| Manufacturing date (of the SoC?). Usually month(s) before the dates in the logs stored in [[Flash_Filesystem\|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte.		\| Manufacturing date (of the SoC?). Usually month(s) before the dates in the logs stored in [[Flash_Filesystem\|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte. This order matches up with the layout of a <code>struct tm</code>.
	\|-		\|-
	\| 0x20		\| 0x20
	\| 0x4		\| 0x4
	\| This is the CTCert ~~ECDSA exponent~~, this is ~~byte-swapped when plaintext_otp+0x18~~ is >=5.		\| This is the CTCert expiry time as UNIX timestamp, this is specified in big endian if the OTP version is <5.
	\|-		\|-
	\| 0x24		\| 0x24
	\| ~~0x2~~		\| 0x20
	~~\| ?~~
	\|-
	~~\| 0x26~~
	~~\| 0x1E~~
	\| This is the CTCert ECDSA privk.		\| This is the CTCert ECDSA privk.
	\|-		\|-
	\| 0x44		\| 0x44
	\| 0x3C		\| 0x3C
	\| This is the CTCert ECDSA signature.		\| This is the CTCert ECDSA signature (sect233r1?/SHA-256).
	\|-		\|-
	\| 0x80		\| 0x80

Myria: /* Plaintext OTP */ Manufacturing date in OTP is probably of the SoC because it's older than system flash

2017-01-23T18:03:22Z

Plaintext OTP: Manufacturing date in OTP is probably of the SoC because it's older than system flash

← Older revision		Revision as of 21:03, 23 January 2017
Line 61:		Line 61:
	\| 0x1A		\| 0x1A
	\| 0x6		\| 0x6
	\| Manufacturing date. Usually month(s) before the dates in the logs stored in [[Flash_Filesystem\|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte.		\| Manufacturing date (of the SoC?). Usually month(s) before the dates in the logs stored in [[Flash_Filesystem\|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte.
	\|-		\|-
	\| 0x20		\| 0x20

Yellows8: /* Plaintext OTP */

2017-01-23T14:28:12Z

Plaintext OTP

← Older revision		Revision as of 17:28, 23 January 2017
Line 61:		Line 61:
	\| 0x1A		\| 0x1A
	\| 0x6		\| 0x6
	\| Manufacturing date. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte.		\| Manufacturing date. Usually month(s) before the dates in the logs stored in [[Flash_Filesystem\|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte.
	\|-		\|-
	\| 0x20		\| 0x20

Myria: /* Plaintext OTP */ Mirrored meaning of offset 0x1A from memory layout.

2017-01-23T06:07:55Z

Plaintext OTP: Mirrored meaning of offset 0x1A from memory layout.

← Older revision		Revision as of 09:07, 23 January 2017
Line 61:		Line 61:
	\| 0x1A		\| 0x1A
	\| 0x6		\| 0x6
	\| ?		\| Manufacturing date. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte.
	\|-		\|-
	\| 0x20		\| 0x20

Yellows8: /* Plaintext OTP */

2017-01-11T02:22:00Z

Plaintext OTP

← Older revision		Revision as of 05:22, 11 January 2017
Line 85:		Line 85:
	\| 0x90		\| 0x90
	\| 0x70		\| 0x70
	\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.		\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.

			Note that the size passed to the Boot9 keyinit code for console-unique-buffer-size is 0x70, hence this includes the below OTP hash.
			\|-
			\| 0xE0
			\| 0x20
			\| SHA256 hash over the previous 0xE0-bytes.
	\|}		\|}

Yellows8: /* Plaintext OTP */

2017-01-11T02:16:24Z

Plaintext OTP

← Older revision		Revision as of 05:16, 11 January 2017
Line 85:		Line 85:
	\| 0x90		\| 0x90
	\| 0x70		\| 0x70
	\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation.		\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.
	\|}		\|}

Yellows8: /* Plaintext OTP */

2017-01-11T02:07:18Z

Plaintext OTP

← Older revision		Revision as of 05:07, 11 January 2017
Line 85:		Line 85:
	\| 0x90		\| 0x90
	\| 0x70		\| 0x70
	\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]].		\| Used by Boot9 for generating the console-unique AES [[AES_Registers\|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation.
	\|}		\|}

Yellows8: /* Sections */

2017-01-06T21:34:41Z

Sections

← Older revision		Revision as of 00:34, 7 January 2017
Line 22:		Line 22:
	\| 0x0		\| 0x0
	\| 0x100		\| 0x100
	\| Console-unique data encrypted with AES-CBC. The normalkey and IV are stored in Boot9(retail/devunit have seperate normalkey+IV for this) The last 0x20-bytes of plaintext are a SHA256 hash over the first 0xE0-bytes of plaintext.		\| Console-unique data encrypted with AES-CBC. The normalkey and IV are stored in Boot9(retail/devunit have seperate normalkey+IV for this). The last 0x20-bytes of plaintext are a SHA256 hash over the first 0xE0-bytes of plaintext.
	\|-		\|-
	\| 0x100		\| 0x100