Difference between revisions of "CMD"

From iQueBrew
Jump to navigation Jump to search
(Created page with "An iQue '''Content MetaData (CMD)''' 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/S...")
 
(remove speculation that turned out to be incorrect.)
Line 5: Line 5:
 
== Format ==
 
== Format ==
 
The CMD 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.
 
The CMD 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"
 
{| class="wikitable"
Line 118: Line 116:
 
| RSA-2048 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 ==
 
== 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.
+
The signature is made from a SHA1 hash of 0x0 - 0xAC, prior to the titlekey being encrypted with the ECDH-derived titlekek.
−
 
 
−
Comparing CMDs 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 12:21, 6 May 2018

An iQue Content MetaData (CMD) 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 CMD format is similar to a Wii ticket, though it seems the structure was reworked sometime between the iQue and Wii.

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

Signature

The signature is made from a SHA1 hash of 0x0 - 0xAC, prior to the titlekey being encrypted with the ECDH-derived titlekek.

Retrieved from "http://www.iquebrew.org/index.php?title=CMD&oldid=838"