Difference between revisions of "Ticket"

Revision as of 03:44, 6 May 2018

An iQue Ticket is used to store data about a piece of content and per-console information. It is contained inside the ticket file after the CMD data.

Offset	Length	Type	Description	Information
0x00	0x04	bytes	console_id	console id that this ticket is for
0x04	0x02	int16	ticket_id	if bit 15 set then this is a trial ticket
0x06	0x02	uint16	limit_enum	0 or 2 = time, 1 = number of launches
0x08	0x02	int16	limit_value	number of minutes, or number of launches
0x0A	0x02	int16	padding	IV used to encrypt titlekey (with common key)
0x0C	0x04	int32	ticket_crl_version
0x10	0x10	bytes	titlekey_iv	IV used to encrypt titlekey (with ecdh key)
0x20	0x40	int32	ecc_pubkey	used with console's ECC privkey to derive unique titlekey encryption key via ECDH
0x60	0x40	bytes	signer	certificate used to sign the ticket
0xA0	0x100	bytes	signature	RSA-2048, over rest of tik+all of CMD

@@ Line 1: / Line 1: @@
-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).
+An iQue '''Ticket''' is used to store data about a piece of content and per-console information. It is contained inside the ticket file after the CMD data.
-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 [http://wiibrew.org/wiki/Ticket 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.
 {| class="wikitable"
@@ Line 16: / Line 9: @@
 ! Information
 |-
-| 0x0
+| 0x00
-| 0x8
+| 0x04
 | bytes
-| ca_crl_version
+| console_id
-| Unknown (always 0?)
+| console id that this ticket is for
 |-
-| 0x8
+| 0x04
-| 0x4
+| 0x02
-| int32
+| int16
-| cmd_crl_version
+| ticket_id
-| Unknown (always 1?)
+| if bit 15 set then this is a trial ticket
 |-
-| 0xC
+| 0x06
-| 0x4
+| 0x02
-| uint32
+| uint16
-| content_size
+| limit_enum
-| Content Size
+| 0 or 2 = time, 1 = number of launches
 |-
-| 0x10
+| 0x08
-| 0x4
+| 0x02
-| int32
+| int16
-| unused_flags
+| limit_value
-| bit 0 on if SA; nothing checks it though
+| number of minutes, or number of launches
 |-
-| 0x14
+| 0x0A
-| 0x10
+| 0x02
-| bytes
+| int16
-| titlekey_iv
+| padding
 | IV used to encrypt titlekey (with common key)
 |-
-| 0x24
+| 0x0C
-| 0x14
+| 0x04
-| bytes
+| int32
-| content_hash
+| ticket_crl_version
-| sha1 hash of plaintext content
+|
 |-
-| 0x38
+| 0x10
 | 0x10
 | bytes
-| content_iv
+| titlekey_iv
-| IV used to encrypt content
+| IV used to encrypt titlekey (with ecdh key)
 |-
-| 0x48
+| 0x20
-| 0x4
+| 0x40
-| 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
+| ecc_pubkey
-| can be zero; if not can only run on certain (used for SAs, not games)
+| used with console's ECC privkey to derive unique titlekey encryption key via ECDH
 |-
-| 0x58
+| 0x60
 | 0x40
-| chars
+| bytes
 | signer
-| Authority (cert used to sign ticket)
+| certificate used to sign the 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
+| 0xA0
 | 0x100
 | bytes
 | signature
-| RSA-2048 signature
+| RSA-2048, over rest of tik+all of CMD
-|}
-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)
-[[Category:File formats]]

Difference between revisions of "Ticket"

Revision as of 03:44, 6 May 2018

Navigation menu

Search