| 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.