Ticket - Revision history

Luigoalma: Content Index doesn't have a fixed size.

2019-10-13T22:42:49Z

Content Index doesn't have a fixed size.

← Older revision		Revision as of 02:42, 14 October 2019
Line 85:		Line 85:
	\| 0x124\|\|0x40\|\|Limits		\| 0x124\|\|0x40\|\|Limits
	\|-		\|-
	\| 0x164\|\|~~0xAC~~\|\|Content Index		\| 0x164\|\|X\|\|Content Index
	\|}		\|}

Line 97:		Line 97:

	* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.		* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.

			* The Content Index of a ticket has its own size defined within itself, with seemingly a minimal of 20 bytes, the second u32 in big endian defines the full value of X.

	== Certificate Chain ==		== Certificate Chain ==

Dazzozo at 00:28, 10 July 2016

2016-07-09T22:28:06Z

← Older revision		Revision as of 02:28, 10 July 2016
Line 94:		Line 94:
	* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)		* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)

	* The titlekey is used to decrypt content downloaded from the CDN using 128-bit AES-CBC with the content index (padded with trailing zeroes) as the IV.		* The titlekey is used to decrypt content downloaded from the CDN using 128-bit AES-CBC with the content index (as big endian u16, padded with trailing zeroes) as the IV.

	* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.		* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.

Dazzozo: index not ID

2016-07-09T22:26:15Z

index not ID

← Older revision		Revision as of 02:26, 10 July 2016
Line 94:		Line 94:
	* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)		* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)

	* The titlekey is used to decrypt content downloaded from the CDN using AES-CBC with the content ID as the IV.		* The titlekey is used to decrypt content downloaded from the CDN using 128-bit AES-CBC with the content index (padded with trailing zeroes) as the IV.

	* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.		* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.

Neobrain: \o/

2016-07-09T22:04:46Z

\o/

← Older revision		Revision as of 02:04, 10 July 2016
Line 93:		Line 93:

	* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)		* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)

			* The titlekey is used to decrypt content downloaded from the CDN using AES-CBC with the content ID as the IV.

	* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.		* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.

Neobrain: Merged with (misplaced) content from the Titles page. Also reword to sound less awkward to read.

2016-03-20T15:42:39Z

Merged with (misplaced) content from the Titles page. Also reword to sound less awkward to read.

← Older revision		Revision as of 18:42, 20 March 2016
Line 125:		Line 125:
	* '''CommonETicket''' (for short, '''cetk''') is the name given to tickets for titles which are not available on the [[EShop\|eShop]], like [[Title list#CTR System Titles\|system titles]]. As the name suggests, they are not unique tickets, the same ticket is common to each 3ds which has installed that title. This is in contrast to tickets for eShop content, which are generated prior to initial download, and are unique to 3ds it was generated for.		* '''CommonETicket''' (for short, '''cetk''') is the name given to tickets for titles which are not available on the [[EShop\|eShop]], like [[Title list#CTR System Titles\|system titles]]. As the name suggests, they are not unique tickets, the same ticket is common to each 3ds which has installed that title. This is in contrast to tickets for eShop content, which are generated prior to initial download, and are unique to 3ds it was generated for.

	* '''CETK''' can be fetched through HTTP using the link to default update server, using the title's [[TMD]] URL where "cetk" is used instead of "tmd" for the URL. The 3DS NIM module retrieves system tickets via SOAP request ''~~GetCommonETicket~~''.		* '''CETK''' can be fetched through HTTP using the link to default update server, using the title's [[TMD]] URL where "cetk" is used instead of "tmd" for the URL. The 3DS NIM module retrieves system tickets via SOAP request ''GetSystemCommonETicket'' instead of directly downloading the cetks with HTTPS. The cetks are also accessible via HTTP (even though the 3DS never accesses them like that).

Yellows8: /* Ticket Data */

2015-11-10T02:07:13Z

Ticket Data

← Older revision		Revision as of 05:07, 10 November 2015
Line 53:		Line 53:
	\| 0x7E\|\|0x1\|\|SignerCrlVersion		\| 0x7E\|\|0x1\|\|SignerCrlVersion
	\|-		\|-
	\| 0x7F\|\|0x10\|\|TitleKey (encrypted using one of the common ~~normal-keys~~; see below)		\| 0x7F\|\|0x10\|\|TitleKey (normal-key encrypted using one of the common keyYs; see below)
	\|-		\|-
	\| 0x8F\|\|0x1\|\|Reserved		\| 0x8F\|\|0x1\|\|Reserved

Neobrain: Actually, it's encrypted using the normal keys rather than the keyYs, of course...

2015-11-09T23:47:57Z

Actually, it's encrypted using the normal keys rather than the keyYs, of course...

← Older revision		Revision as of 02:47, 10 November 2015
Line 53:		Line 53:
	\| 0x7E\|\|0x1\|\|SignerCrlVersion		\| 0x7E\|\|0x1\|\|SignerCrlVersion
	\|-		\|-
	\| 0x7F\|\|0x10\|\|TitleKey (encrypted using one of the common ~~keyYs~~; see below)		\| 0x7F\|\|0x10\|\|TitleKey (encrypted using one of the common normal-keys; see below)
	\|-		\|-
	\| 0x8F\|\|0x1\|\|Reserved		\| 0x8F\|\|0x1\|\|Reserved

Neobrain: /* Ticket Data */

2015-11-09T23:39:48Z

Ticket Data

← Older revision		Revision as of 02:39, 10 November 2015
Line 53:		Line 53:
	\| 0x7E\|\|0x1\|\|SignerCrlVersion		\| 0x7E\|\|0x1\|\|SignerCrlVersion
	\|-		\|-
	\| 0x7F\|\|0x10\|\|~~Encrypted~~ TitleKey		\| 0x7F\|\|0x10\|\|TitleKey (encrypted using one of the common keyYs; see below)
	\|-		\|-
	\| 0x8F\|\|0x1\|\|Reserved		\| 0x8F\|\|0x1\|\|Reserved

Neobrain: Explicitly mention that these are referred to as common keyYs ...

2015-11-08T12:26:16Z

Explicitly mention that these are referred to as common keyYs ...

← Older revision		Revision as of 15:26, 8 November 2015
Line 92:		Line 92:
	* The Ticket Title Version is generally the same as the title version stored in the [[TMD\|Title Metadata]]. Although it doesn't have to match the TMD version to be valid.		* The Ticket Title Version is generally the same as the title version stored in the [[TMD\|Title Metadata]]. Although it doesn't have to match the TMD version to be valid.

	* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)		* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys ("common keyYs") stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)

	* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.		* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.

Neobrain: /* Ticket Data */

2015-11-08T12:23:29Z

Ticket Data

← Older revision		Revision as of 15:23, 8 November 2015
Line 71:		Line 71:
	\| 0xB0\|\|0x1\|\|License Type		\| 0xB0\|\|0x1\|\|License Type
	\|-		\|-
	\| 0xB1\|\|0x1\|\|~~Ticket~~ common [[AES\|keyY]] ~~index~~, usually 0x1 for retail system titles.		\| 0xB1\|\|0x1\|\|Index to the common [[AES\|keyY]] used for this ticket, usually 0x1 for retail system titles; see below.
	\|-		\|-
	\| 0xB2\|\|0x2A\|\|Reserved		\| 0xB2\|\|0x2A\|\|Reserved
Line 92:		Line 92:
	* The Ticket Title Version is generally the same as the title version stored in the [[TMD\|Title Metadata]]. Although it doesn't have to match the TMD version to be valid.		* The Ticket Title Version is generally the same as the title version stored in the [[TMD\|Title Metadata]]. Although it doesn't have to match the TMD version to be valid.

	* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot ~~where the~~ keyY is ~~one~~ of 6 ~~keyYs loaded via the keyY index~~ stored in the ~~ticket~~. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key.(On retail for these keyYs, the hardware key-scrambler is used)		* The titlekey is decrypted by using the [[AES]] engine with the ticket common-key keyslot. The keyY is selected through an index (ticket offset 0xB1) into a plaintext array of 6 keys stored in the data section of Process9. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key. (On retail for these keyYs, the hardware key-scrambler is used)

	* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.		* In demos, the first u32 in the "Limits" section is 0x4, then the second u32 is the max-playcount.