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: bits 0-7: new PI stuff bit 0: PI buffer used for aes/NAND read output and PI DMA (1KB at PI_BASE+0x10000) bit 1: NAND flash regs in PI bit 2: memory mapper for old PI dma bit 3: hardware AES-engine in PI bit 4: new PI dma engine, DMAs from/to PI buffer bit 5: new GPIO; power + LED bit 6: external IO bus stuff (debug?) bit 7: new PI error stuff bit 8: enables access to USB regs bit 9: enables access to internal ram used for SK stack (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)