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...")
 
m (Actually link to IA8)
 
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
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).
+
A '''content metadata''' or '''CMD''' is a file or structure used to store data about an iQue app, such as encryption keys, its access to secure kernel calls, and its access to various hardware. It is used on its own in [[SKSA]] (where SA1 and SA2 both have their own attached CMD) and also contained as part of every [[ticket]].  
−
 
 
−
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 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.
+
A CMD consists of two parts: '''contentDesc''', an optional 0x2800-byte long structure containing information about a game such as its save type, title, and thumbnail image; and '''BbContentMetaDataHead'''. The former is not used in the content metadata for SAs.
  
−
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.
+
=== contentDesc ===
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Length
 +
! Type
 +
! Information
 +
|-
 +
| 0x00
 +
| 0x04
 +
| uint32
 +
| EEPROM RDRAM location (typically 0x807C0000, 0 if unused)
 +
|-
 +
| 0x04
 +
| 0x04
 +
| uint32
 +
| EEPROM size (either 0x200 or 0x800)
 +
|-
 +
| 0x08
 +
| 0x04
 +
| uint32
 +
| Flash RDRAM location (typically 0x807C0000, 0 if unused)
 +
|-
 +
| 0x0C
 +
| 0x04
 +
| uint32
 +
| Flash size (0x20000 if used)
 +
|-
 +
| 0x10
 +
| 0x04
 +
| uint32
 +
| SRAM RDRAM location (typically 0x807C0000, 0 if unused)
 +
|-
 +
| 0x14
 +
| 0x04
 +
| uint32
 +
| SRAM size (0x8000 if used)
 +
|-
 +
| 0x18
 +
| 0x04
 +
| uint32
 +
| Controller Pak 0 RDRAM location (could be 0x807C0000 or 0x807C0000, 0 if unused)
 +
|-
 +
| 0x1C
 +
| 0x04
 +
| uint32
 +
| Controller Pak 1 RDRAM location (0 if unused)
 +
|-
 +
| 0x20
 +
| 0x04
 +
| uint32
 +
| Controller Pak 2 RDRAM location (0 if unused)
 +
|-
 +
| 0x24
 +
| 0x04
 +
| uint32
 +
| Controller Pak 3 RDRAM location (0 if unused)
 +
|-
 +
| 0x28
 +
| 0x04
 +
| uint32
 +
| Controller Pak size (0x8000 when used)
 +
|-
 +
| 0x2C
 +
| 0x04
 +
| uint32
 +
| Probably osRomBase (always 0xB0000000?)
 +
|-
 +
| 0x30
 +
| 0x04
 +
| uint32
 +
| Probably osTvType (always 1? which is for NTSC)
 +
|-
 +
| 0x34
 +
| 0x04
 +
| uint32
 +
| Probably osMemSize (always 0x400000? for no expansion pak)
 +
|-
 +
| 0x38
 +
| 0x04
 +
| uint32
 +
| Unknown, possibly another libultra boot param
 +
|-
 +
| 0x3C
 +
| 0x04
 +
| uint32
 +
| Unknown, possibly another libultra boot param
 +
|-
 +
| 0x40
 +
| 0x03
 +
| chars
 +
| "CAM", unknown purpose
 +
|-
 +
| 0x43
 +
| 0x01
 +
| byte
 +
| Number of ".u0x" files for this game?
 +
|-
 +
| 0x44
 +
| 0x02
 +
| uint16
 +
| Thumb image length (can't be more than 0x4000, decompressed size must be exactly 0x1880)
 +
|-
 +
| 0x46
 +
| 0x02
 +
| uint16
 +
| Title image length (can't be more than 0x10000, how exactly would that even fit?)
 +
|-
 +
| 0x48
 +
| ''Thumb image length''
 +
| bytes
 +
| DEFLATE-compressed thumb image, stored as RGBA5551 (56w * 56h)
 +
|-
 +
| 0x48 + ''Thumb image length''
 +
| ''Title image length''
 +
| bytes
 +
| DEFLATE-compressed title image, stored as [http://wiki.tockdom.com/wiki/Image_Formats#IA8 IA8] (184w * 24h)
 +
|-
 +
| 0x48 + ''Thumb image length'' + ''Title image length''
 +
| 0x27B8 - image lengths
 +
| chars
 +
| Title name + ISBN
 +
|}
  
 +
=== BbContentMetaDataHead ===
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 16: Line 137:
 
! Information
 
! Information
 
|-
 
|-
−
| 0x0
+
| 0x2800
−
| 0x8
+
| 0x04
−
| bytes
+
| uint32
−
| ca_crl_version
+
| unusedPadding
−
| Unknown (always 0?)
+
| padding
 +
|-
 +
| 0x2804
 +
| 0x04
 +
| uint32
 +
| caCrlVersion
 +
| Certificate Authority(?) CRL version
 
|-
 
|-
−
| 0x8
+
| 0x2808
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| cmd_crl_version
+
| cpCrlVersion
−
| Unknown (always 1?)
+
| Content Protection(?) CRL version
 
|-
 
|-
−
| 0xC
+
| 0x280C
−
| 0x4
+
| 0x04
 
| uint32
 
| uint32
−
| content_size
+
| size
−
| Content Size
+
| Size (in bytes) of the associated app
 
|-
 
|-
−
| 0x10
+
| 0x2810
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| unused_flags
+
| descFlags
−
| bit 0 on if SA; nothing checks it though
+
| Seemingly unused/unchecked; bit 0 set if the associated app is SA
 
|-
 
|-
−
| 0x14
+
| 0x2814
 
| 0x10
 
| 0x10
−
| bytes
+
| uint8[16]
−
| titlekey_iv
+
| commonCmdIv
−
| IV used to encrypt titlekey (with common key)                
+
| titlekey_iv; IV used to encrypt title key (with common key)              
 
|-
 
|-
−
| 0x24
+
| 0x2824
 
| 0x14
 
| 0x14
−
| bytes
+
| uint8[20]
−
| content_hash
+
| hash
−
| sha1 hash of plaintext content
+
| SHA-1 hash of the plaintext of the associated app
 
|-
 
|-
−
| 0x38
+
| 0x2838
 
| 0x10
 
| 0x10
−
| bytes
+
| uint8[16]
−
| content_iv
+
| iv
−
| IV used to encrypt content
+
| content_iv; IV used to encrypt content
 
|-
 
|-
−
| 0x48
+
| 0x2848
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| recrypt_flag
+
| execFlags
−
| if bit 1 on, content will be re-encrypted on first launch, using console-unique key stored in Virage2 in the SoC   
+
| Despite the name, only one use/flag is known: if bit 1 is set (the "recrypt flag"), the associated app will be re-encrypted on first launch
 
|-
 
|-
−
| 0x4C
+
| 0x284C
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| allowed_hardware
+
| hwAccessRights
 
| bitfield, each bit enables access to some MMIO regs new to iQue Player:
 
| bitfield, each bit enables access to some MMIO regs new to iQue Player:
 
* bits 0-7: new PI stuff               
 
* bits 0-7: new PI stuff               
Line 80: Line 207:
 
* bit 8: enables access to USB regs
 
* bit 8: enables access to USB regs
 
* bit 9: enables access to internal ram used for SK stack   
 
* bit 9: enables access to internal ram used for SK stack   
−
(0 for games, 0x13 for iQue Club, 0x1F7/0x1B3 for SA)
+
(0x0000 for games except for Animal Forest which is 0x0033, 0x0013 for iQue Club, 0x01F7/0x01B3 for SA)
 
|-
 
|-
−
| 0x50
+
| 0x2850
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| allowed_secure_kernel_calls
+
| secureKernelRights
−
| one bit per syscall bit 0 allows skc 0, etc.
+
| Which [[SKC|secure kernel calls]] the associated app can use, one bit per syscall: bit 0 allows SKC 0, etc.
 
|-
 
|-
−
| 0x54
+
| 0x2854
−
| 0x4
+
| 0x04
−
| int32
+
| uint32
−
| console_id
+
| bbid
−
| can be zero; if not can only run on certain (used for SAs, not games)  
+
| If not zero, can only be run on the specified console (used for SAs, not games)  
 
|-
 
|-
−
| 0x58
+
| 0x2858
 
| 0x40
 
| 0x40
−
| chars
+
| uint8[64]
−
| signer
+
| issuer
−
| Authority (cert used to sign ticket)
+
| Certificate used to sign the cmd
 
|-
 
|-
−
| 0x98
+
| 0x2898
−
| 0x4
+
| 0x04
 
| uint32
 
| uint32
−
| content_id
+
| id
−
| Content ID (can't be higher than 99999999, if (cid / 100) % 10 == 9, this is a game manual)
+
| Content ID of the associated app
 
|-
 
|-
−
| 0x9C
+
| 0x289C
 
| 0x10
 
| 0x10
−
| bytes
+
| uint8[16]
−
| titlekey
+
| key
−
| 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  
+
| The associated app's title key. It is encrypted once with the common key. If the associated app is not an SA, then it is encrypted ''again'' with a key derived using the result of ECDH with the console's private key in the Virage2 and the public key in the app's ticket.
 
|-
 
|-
−
| 0xAC
+
| 0x28AC
 
| 0x100
 
| 0x100
−
| bytes
+
| uint8[256]
−
| signature
+
| contentMetaDataSign
−
| RSA-2048 signature
+
| RSA-2048 signature over all of the above, but before the title key is encrypted a second time.
 
|}
 
|}
−
 
−
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 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]]

Latest revision as of 02:32, 4 February 2019

A content metadata or CMD is a file or structure used to store data about an iQue app, such as encryption keys, its access to secure kernel calls, and its access to various hardware. It is used on its own in SKSA (where SA1 and SA2 both have their own attached CMD) and also contained as part of every ticket.

Format

A CMD consists of two parts: contentDesc, an optional 0x2800-byte long structure containing information about a game such as its save type, title, and thumbnail image; and BbContentMetaDataHead. The former is not used in the content metadata for SAs.

contentDesc

Offset Length Type Information
0x00 0x04 uint32 EEPROM RDRAM location (typically 0x807C0000, 0 if unused)
0x04 0x04 uint32 EEPROM size (either 0x200 or 0x800)
0x08 0x04 uint32 Flash RDRAM location (typically 0x807C0000, 0 if unused)
0x0C 0x04 uint32 Flash size (0x20000 if used)
0x10 0x04 uint32 SRAM RDRAM location (typically 0x807C0000, 0 if unused)
0x14 0x04 uint32 SRAM size (0x8000 if used)
0x18 0x04 uint32 Controller Pak 0 RDRAM location (could be 0x807C0000 or 0x807C0000, 0 if unused)
0x1C 0x04 uint32 Controller Pak 1 RDRAM location (0 if unused)
0x20 0x04 uint32 Controller Pak 2 RDRAM location (0 if unused)
0x24 0x04 uint32 Controller Pak 3 RDRAM location (0 if unused)
0x28 0x04 uint32 Controller Pak size (0x8000 when used)
0x2C 0x04 uint32 Probably osRomBase (always 0xB0000000?)
0x30 0x04 uint32 Probably osTvType (always 1? which is for NTSC)
0x34 0x04 uint32 Probably osMemSize (always 0x400000? for no expansion pak)
0x38 0x04 uint32 Unknown, possibly another libultra boot param
0x3C 0x04 uint32 Unknown, possibly another libultra boot param
0x40 0x03 chars "CAM", unknown purpose
0x43 0x01 byte Number of ".u0x" files for this game?
0x44 0x02 uint16 Thumb image length (can't be more than 0x4000, decompressed size must be exactly 0x1880)
0x46 0x02 uint16 Title image length (can't be more than 0x10000, how exactly would that even fit?)
0x48 Thumb image length bytes DEFLATE-compressed thumb image, stored as RGBA5551 (56w * 56h)
0x48 + Thumb image length Title image length bytes DEFLATE-compressed title image, stored as IA8 (184w * 24h)
0x48 + Thumb image length + Title image length 0x27B8 - image lengths chars Title name + ISBN

BbContentMetaDataHead

Offset Length Type Description Information
0x2800 0x04 uint32 unusedPadding padding
0x2804 0x04 uint32 caCrlVersion Certificate Authority(?) CRL version
0x2808 0x04 uint32 cpCrlVersion Content Protection(?) CRL version
0x280C 0x04 uint32 size Size (in bytes) of the associated app
0x2810 0x04 uint32 descFlags Seemingly unused/unchecked; bit 0 set if the associated app is SA
0x2814 0x10 uint8[16] commonCmdIv titlekey_iv; IV used to encrypt title key (with common key)
0x2824 0x14 uint8[20] hash SHA-1 hash of the plaintext of the associated app
0x2838 0x10 uint8[16] iv content_iv; IV used to encrypt content
0x2848 0x04 uint32 execFlags Despite the name, only one use/flag is known: if bit 1 is set (the "recrypt flag"), the associated app will be re-encrypted on first launch
0x284C 0x04 uint32 hwAccessRights 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

(0x0000 for games except for Animal Forest which is 0x0033, 0x0013 for iQue Club, 0x01F7/0x01B3 for SA)

0x2850 0x04 uint32 secureKernelRights Which secure kernel calls the associated app can use, one bit per syscall: bit 0 allows SKC 0, etc.
0x2854 0x04 uint32 bbid If not zero, can only be run on the specified console (used for SAs, not games)
0x2858 0x40 uint8[64] issuer Certificate used to sign the cmd
0x2898 0x04 uint32 id Content ID of the associated app
0x289C 0x10 uint8[16] key The associated app's title key. It is encrypted once with the common key. If the associated app is not an SA, then it is encrypted again with a key derived using the result of ECDH with the console's private key in the Virage2 and the public key in the app's ticket.
0x28AC 0x100 uint8[256] contentMetaDataSign RSA-2048 signature over all of the above, but before the title key is encrypted a second time.
Retrieved from "http://www.iquebrew.org/index.php?title=CMD&oldid=964"