2
edits
Changes
Jump to navigation
Jump to search
no edit summary
Line 235:
Line 235:
|-
−| 0x1000
−| 0x10
−| Card seed keyY (first u64 is Media ID (same as first NCCH partitionId))
−|-
−| 0x1010
−| 0x10
−| Encrypted card seed (AES-CCM, keyslot 0x3B for retail cards, see [[CTRCARD_Registers|CTRCARD_SECSEED]])
−|-
−| 0x1020
−| 0x10
−| Card seed AES-MAC
−|-
−| 0x1030
−| 0xC
−| Card seed nonce
−|-
−| 0x103C
−| 0xC4
−| Reserved3
−|-
−| 0x1100
−| 0x100
−| Copy of first NCCH header (excluding RSA signature)
|-
−| 0x1500
−| 0x1B00
−| CardDeviceReserved3
"TitleKey" is the decrypted version of the title key at 0x1000-0x103B ("Encrypted card seed"). This field appears to be what development--and maybe retail?--cards read to know what card encryption seed to use in the CTR protocol.+
−Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique Id obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).
The test pattern is the same one encountered in development DS/DSi cartridges. Its layout is as follows:+
+| 0x3200
Retail cards always return FF when attempting to read 0x1200-0x3FFF. They probably actually have the same data as development cards, but there's no way to read it.+
| 0xCD6
| 0xCD6
| Reserved
| Reserved
−|}
|}
Line 267:
Line 243:
! SIZE
! SIZE
! DESCRIPTION
! DESCRIPTION
+|-
+| 0x1000
+| 0x200
+| InitialData
|-
|-
| 0x1200
| 0x1200
Line 274:
Line 254:
| 0x1400
| 0x1400
| 0x10
| 0x10
−| TitleKey
+| TitleKeyData
|-
|-
| 0x1410
| 0x1410
−| 0xF0
+| 0x1BF0
| CardDeviceReserved2
| CardDeviceReserved2
−|-
|-
| 0x3000
| 0x3000
| 0x1000
| 0x1000
−| Test pattern
+| TestData
|}
|}
−TitleKeyData contains the decrypted version of the title key found in the InitialData. This field appears to be what development--and maybe production?--cards read to know what card encryption seed to use in the CTR protocol.
−The CardDeviceReserved areas have random-looking data whose purpose is unknown, other than perhaps to hide the TitleKey.
The CardDeviceReserved areas have random-looking data whose purpose is unknown, other than perhaps to hide the TitleKey.
−Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique ID obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).
+=== InitialData ===
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
Line 303:
Line 278:
! DESCRIPTION
! DESCRIPTION
|-
|-
−| 0x3000
+| 0x0
−| 8
+| 0x10
−| The bytes FF,00,FF,00,AA,55,AA,55.
+| Seed (keyY used to decrypt the title key - keyX is keyslot 0x3B for production cards, or a key of all zeroes for development cards)
+|-
+| 0x10
+| 0x10
+| TitleKey (AES-CCM encrypted)
+|-
+| 0x20
+| 0x10
+| Mac
+|-
+| 0x30
+| 0xC
+| Nonce
+|-
+| 0x3C
+| 0xC4
+| Reserved
+|-
+| 0x100
+| 0x100
+| NcchHeader (copy of the first NCCH header, excluding the RSA signature)
+|}
+=== TestData ===
+The test data is the same one encountered in development DS/DSi cartridges. Its layout is as follows:
+{| class="wikitable" border="1"
+|-
+! OFFSET
+! SIZE
+! DESCRIPTION
+|-
+| 0x0
+| 0x8
+| The bytes FF 00 FF 00 AA 55 AA 55.
|-
|-
−| 0x3008
+| 0x8
| 0x1F8
| 0x1F8
−| An ascending byte sequence equal to the offset mod 256 (08,09,0A, ..., FE,FF,00,01, ..., FF).
+| An ascending byte sequence equal to the offset mod 256 (08 09 0A ... FE FF 00 01 ... FF).
|-
|-
−| 0x200
| 0x200
−| A descending byte sequence equal to 255 minus the offset mod 256 (FF,FE,FD, ..., 00,FF,DE, ..., 00).
+| 0x200
+| A descending byte sequence equal to 255 minus the offset mod 256 (FF FE FD ... 00 FF DE ... 00).
|-
|-
−| 0x3400
+| 0x400
| 0x200
| 0x200
−| Filled with 00 bytes.
+| Filled with 00 (0b00000000) bytes.
|-
|-
−| 0x3600
+| 0x600
| 0x200
| 0x200
−| Filled with FF bytes.
+| Filled with FF (0b11111111) bytes.
|-
|-
−| 0x3800
+| 0x800
| 0x200
| 0x200
−| Filled with 0F bytes.
+| Filled with 0F (0b00001111) bytes.
|-
|-
−| 0x3A00
+| 0xA00
| 0x200
| 0x200
−| Filled with F0 bytes.
+| Filled with F0 (0b11110000) bytes.
|-
|-
−| 0x3C00
+| 0xC00
| 0x200
| 0x200
−| Filled with 55 bytes.
+| Filled with 55 (0b01010101) bytes.
|-
|-
−| 0x3E00
+| 0xE00
| 0x1FF
| 0x1FF
−| Filled with AA bytes.
+| Filled with AA (0b10101010) bytes.
|-
|-
−| 0x3FFF
+| 0xFFF
−| 1
+| 0x1
−| The final byte is a 00.
+| The final byte is 00 (0b00000000).
|}
|}
−Production cards always return FF when attempting to read 0x1200-0x3FFF. They probably actually have the same data as development cards, but there's no way to read it.
== Tools ==
== Tools ==