Difference between revisions of "Ticket"

From iQueBrew
Jump to navigation Jump to search
m
 
(4 intermediate revisions by 2 users not shown)
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).
+
A '''ticket''' is used to store data about an associated app and per-console information, such as encryption keys and whether or not the app is time-limited.
−
 
 
−
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 ==
−
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.
+
A ticket (BbTicket) consists of two parts: the [[CMD|content metadata]] for the app, and a ticket head (BbTicketHead).
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 16: Line 13:
 
! Information
 
! Information
 
|-
 
|-
−
| 0x0
+
| 0x00
−
| 0x8
+
| 0x29AC
−
| bytes
+
| -
−
| ca_crl_version
+
| [[CMD]]
−
| Unknown (always 0?)
+
| Content metadata for the associated app
 
|-
 
|-
−
| 0x8
+
| 0x29AC
−
| 0x4
+
| 0x04
−
| int32
 
−
| cmd_crl_version
 
−
| Unknown (always 1?)
 
−
|-
 
−
| 0xC
 
−
| 0x4
 
 
| uint32
 
| uint32
−
| content_size
+
| bbId
−
| Content Size
+
| ID of the console this ticket is for
 
|-
 
|-
−
| 0x10
+
| 0x29B0
−
| 0x4
+
| 0x02
−
| int32
+
| uint16
−
| unused_flags
+
| tid
−
| bit 0 on if SA; nothing checks it though
+
| ticket ID; if bit 15 is set, then it is a trial ticket
 
|-
 
|-
−
| 0x14
+
| 0x29B2
−
| 0x10
+
| 0x02
−
| bytes
+
| uint16
−
| titlekey_iv
+
| code
−
| IV used to encrypt titlekey (with common key)               
+
| What type of trial limitation: 0 or 2 = time, 1 = number of launches
 
|-
 
|-
−
| 0x24
+
| 0x29B4
−
| 0x14
+
| 0x02
−
| bytes
+
| uint16
−
| content_hash
+
| limit
−
| sha1 hash of plaintext content
+
| number of minutes, or number of launches, before limit is reached
 
|-
 
|-
−
| 0x38
+
| 0x29B6
−
| 0x10
+
| 0x02
−
| bytes
+
| uint16
−
| content_iv
+
| reserved
−
| IV used to encrypt content
+
| padding               
 
|-
 
|-
−
| 0x48
+
| 0x29B8
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| recrypt_flag
+
| tsCrlVersion
−
| if bit 1 on, content will be re-encrypted on first launch, using console-unique key stored in Virage2 in the SoC   
+
| ticket_crl_version
 
|-
 
|-
−
| 0x4C
+
| 0x29BC
−
| 0x4
+
| 0x10
−
| int32
+
| uint8[16]
−
| allowed_hardware
+
| cmdIv
−
| bitfield, each bit enables access to some MMIO regs new to iQue Player:
+
| titlekey_iv; IV used to re-encrypt title key (with ECDH key)
−
* 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
+
| 0x29CC
−
| 0x4
+
| 0x40
−
| int32
+
| uint8[64]
−
| allowed_secure_kernel_calls
+
| serverKey
−
| one bit per syscall bit 0 allows skc 0, etc.
+
| ECC public key used with console's ECC private key to derive unique title key encryption key via ECDH   
−
|-
 
−
| 0x54
 
−
| 0x4
 
−
| int32
 
−
| console_id
 
−
| can be zero; if not can only run on certain (used for SAs, not games)
 
 
|-
 
|-
−
| 0x58
+
| 0x2A0C
 
| 0x40
 
| 0x40
−
| chars
+
| uint8[64]
−
| signer
+
| issuer
−
| 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
+
| 0x2A4C
−
| 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
 
| 0x100
−
| bytes
+
| uint8[256]
−
| signature
+
| ticketSign
−
| RSA-2048 signature
+
| RSA-2048 signature over all of the above ''and'' the 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]]
 
[[Category:File formats]]

Latest revision as of 13:25, 15 June 2018

A ticket is used to store data about an associated app and per-console information, such as encryption keys and whether or not the app is time-limited.

Format

A ticket (BbTicket) consists of two parts: the content metadata for the app, and a ticket head (BbTicketHead).

Offset Length Type Description Information
0x00 0x29AC - CMD Content metadata for the associated app
0x29AC 0x04 uint32 bbId ID of the console this ticket is for
0x29B0 0x02 uint16 tid ticket ID; if bit 15 is set, then it is a trial ticket
0x29B2 0x02 uint16 code What type of trial limitation: 0 or 2 = time, 1 = number of launches
0x29B4 0x02 uint16 limit number of minutes, or number of launches, before limit is reached
0x29B6 0x02 uint16 reserved padding
0x29B8 0x04 uint32 tsCrlVersion ticket_crl_version
0x29BC 0x10 uint8[16] cmdIv titlekey_iv; IV used to re-encrypt title key (with ECDH key)
0x29CC 0x40 uint8[64] serverKey ECC public key used with console's ECC private key to derive unique title key encryption key via ECDH
0x2A0C 0x40 uint8[64] issuer Certificate used to sign the ticket
0x2A4C 0x100 uint8[256] ticketSign RSA-2048 signature over all of the above and the CMD
Retrieved from "http://www.iquebrew.org/index.php?title=Ticket&oldid=878"