Ticket: Difference between revisions

Neobrain (talk | contribs)
Actually, it's encrypted using the normal keys rather than the keyYs, of course...
Luigoalma (talk | contribs)
Content Index doesn't have a fixed size.
 
(5 intermediate revisions by 3 users not shown)
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
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 ==
Line 125: Line 129:
* '''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).