Ticket: Difference between revisions
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|| | | 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 == | ||