Difference between revisions of "Ticket"
m |
|||
| 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, 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. | + | 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 == | == Format == | ||
| Line 93: | Line 93: | ||
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. | 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]] | [[Category:File formats]] | ||
Revision as of 16:54, 24 March 2018
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 | Information |
|---|---|---|---|
| 0x0 | 0x8 | bytes | Unknown (always 0?) |
| 0x8 | 0x4 | int32 | Unknown (always 1?) |
| 0xC | 0x4 | uint32 | Content Size |
| 0x10 | 0x4 | int32 | Unknown (0 for tickets, 1 for SA?) |
| 0x14 | 0x10 | bytes | Unknown (possible title-key) |
| 0x24 | 0x14 | bytes | Content hash (hash of the decrypted content) |
| 0x38 | 0x10 | bytes | Unknown (very possible title-key) |
| 0x48 | 0x4 | int32 | Unknown (2 for game tickets, 0 for SA/iQue Club ticket?) |
| 0x4C | 0x4 | int32 | Unknown (0 for games, 0x13 for iQue Club, 0x1F7/0x1B3 for SA) |
| 0x50 | 0x4 | int32 | Unknown (0x4000 for games, 0x6001 for iQue Club, -1 for normal SAs, 0xE01 for weird SAs?) |
| 0x54 | 0x4 | int32 | Unknown (always 0?) |
| 0x58 | 0x40 | chars | Authority (cert used to sign ticket) |
| 0x98 | 0x4 | uint32 | Content ID (can't be higher than 99999999, if (cid / 100) % 10 == 9, this is a game manual) |
| 0x9C | 0x10 | bytes | Unknown (possible title-key - contents change between devices, but signature remains the same???) |
| 0xAC | 0x100 | bytes | 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)