Difference between revisions of "Ticket"

From 3dbrew
Jump to navigation Jump to search
(Merged with (misplaced) content from the Titles page. Also reword to sound less awkward to read.)
(Content Index doesn't have a fixed size.)
 
(3 intermediate revisions by 2 users not shown)
Line 85: Line 85:
 
| 0x124||0x40||Limits
 
| 0x124||0x40||Limits
 
|-
 
|-
| 0x164||0xAC||Content Index
+
| 0x164||X||Content Index
 
|}
 
|}
  
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 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.
 +
 +
* 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 ==

Latest revision as of 01:42, 14 October 2019

Tickets are a format used to store an encrypted titlekey (using 128-Bit AES-CBC). With 3DS, the Ticket format was updated (now v1) from Wii/DSi format (v0).

Structure[edit]

All of the data in the file is represented in Big Endian.

Offset Size Description
0x000 Y Signature Data
Y 0x210 Ticket Data

Y denotes the total size of the "Signature Data" section and depends on the signature type.

Signature Data[edit]

The signature is of the ticket header.

Offset Size Description
0x0 0x4 Signature Type
0x4 X Signature
0x4 + X Padding to align the signature data to 0x40 bytes

Signature Type[edit]

Value Signature Method Signature Size Padding Size
0x010000 RSA_4096 SHA1 (Unused for 3DS) 0x200 0x3C
0x010001 RSA_2048 SHA1 (Unused for 3DS) 0x100 0x3C
0x010002 Elliptic Curve with SHA1 (Unused for 3DS) 0x3C 0x40
0x010003 RSA_4096 SHA256 0x200 0x3C
0x010004 RSA_2048 SHA256 0x100 0x3C
0x010005 ECDSA with SHA256 0x3C 0x40

The hash for the signature is calculated over the Ticket Data.

Ticket Data[edit]

Offset Size Description
0x0 0x40 Issuer
0x40 0x3C ECC PublicKey
0x7C 0x1 Version (For 3DS this is always 1)
0x7D 0x1 CaCrlVersion
0x7E 0x1 SignerCrlVersion
0x7F 0x10 TitleKey (normal-key encrypted using one of the common keyYs; see below)
0x8F 0x1 Reserved
0x90 0x8 TicketID
0x98 0x4 ConsoleID
0x9C 0x8 TitleID
0xA4 0x2 Reserved
0xA6 0x2 Ticket title version
0xA8 0x8 Reserved
0xB0 0x1 License Type
0xB1 0x1 Index to the common keyY used for this ticket, usually 0x1 for retail system titles; see below.
0xB2 0x2A Reserved
0xDC 0x4 eShop Account ID?
0xE0 0x1 Reserved
0xE1 0x1 Audit
0xE2 0x42 Reserved
0x124 0x40 Limits
0x164 X Content Index
  • For v0 of the format, see here
  • The Ticket Title Version is generally the same as the title version stored in the 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 ("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 (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.
  • 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[edit]

Tickets retrieved from CDN/SOAP have a certificate chain appended at the end of the file. There are two certificates in this chain:

CERTIFICATE SIGNATURE TYPE RETAIL CERT NAME DEBUG CERT NAME DESCRIPTION
Ticket RSA-2048 XS0000000c XS00000009 Used to verify the Ticket signature
CA RSA-4096 CA00000003 CA00000004 Used to verify the Ticket Certificate

The CA certificate is issued by 'Root', the public key for which is stored in NATIVE_FIRM.

Some facts[edit]

  • CommonETicket (for short, cetk) is the name given to tickets for titles which are not available on the eShop, like 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 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).