Ticket
An iQue Ticket is used to store data about a piece of content, such as the size, hash and ID. It's used as part of the SKSA (for info about the SA1/SA2) and also used as part of the Title Data structure (for info about the game title).
Each ticket is signed via RSA-2048 using a CP (content protection?) certificate, the method for signing/verifying has been found for SA1/SA2, but game tickets don't seem to work. It's likely that some part of the structure is changed in memory just before the iQue validates it.
Format
The ticket format is similar to a Wii ticket, though it seems the structure was reworked sometime between the iQue and Wii.
It's assumed that the title key needed to decrypt an SA / .app is part of the structure, though likely encrypted with a common-key that's yet to be dumped from the console.
Offset | Length | Type | Description | Information |
---|---|---|---|---|
0x0 | 0x8 | bytes | ca_crl_version | Unknown (always 0?) |
0x8 | 0x4 | int32 | cmd_crl_version | Unknown (always 1?) |
0xC | 0x4 | uint32 | content_size | Content Size |
0x10 | 0x4 | int32 | unused_flags | bit 0 on if SA; nothing checks it though |
0x14 | 0x10 | bytes | titlekey_iv | IV used to encrypt titlekey (with common key) |
0x24 | 0x14 | bytes | content_hash | sha1 hash of plaintext content |
0x38 | 0x10 | bytes | content_iv | IV used to encrypt content |
0x48 | 0x4 | int32 | recrypt_flag | if bit 1 on, content will be re-encrypted on first launch, using console-unique key stored in Virage2 in the SoC |
0x4C | 0x4 | int32 | allowed_hardware | bitfield, each bit enables access to some MMIO regs new to iQue Player:
(0 for games, 0x13 for iQue Club, 0x1F7/0x1B3 for SA) |
0x50 | 0x4 | int32 | allowed_secure_kernel_calls | one bit per syscall bit 0 allows skc 0, etc. |
0x54 | 0x4 | int32 | console_id | can be zero; if not can only run on certain (used for SAs, not games) |
0x58 | 0x40 | chars | signer | Authority (cert used to sign ticket) |
0x98 | 0x4 | uint32 | content_id | Content ID (can't be higher than 99999999, if (cid / 100) % 10 == 9, this is a game manual) |
0x9C | 0x10 | bytes | titlekey | crypted with common key, and if this is not an SA, then crypted again with key derived using ECDH of console's privkey and pubkey in ticket |
0xAC | 0x100 | bytes | signature | RSA-2048 signature |
In different SAs which seem to have matching bytes in the encrypted data, the field at 0x38 seems to be the only constant between them, likely our best suspect for the title-key.
Signature
The signature is made from a SHA1 hash of 0x0 - 0xAC. In SA1/SA2 this hash seems to be valid for the given signature, but for some reason game tickets don't seem to validate.
Comparing tickets for the same game from two different devices, the area at 0x9C-0xAC seems to completely change, while the actual signature remains the same. It's likely that this area is probably decrypted using a per-device key just before verification.
Fake Signing
As the iQue is so similar to Wii it was guessed that fake-signing may be possible. Sadly tests done with SA1 tickets have all been unsuccessful, though it could be possible that the way SK validates signatures is completely different to how SA1/SA2 validates them (it may be that SK uses an Assembly version for validation, while SA1/SA2 use the C version shared with the Wii, though this is all just speculation at this point)