2
edits
Changes
Jump to navigation
Jump to search
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) Line 267:
Line 243: + + + + Line 274:
Line 254: − + − + − |- − | 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:+ + Line 303:
Line 278: − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + − + − | 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.+
no edit summary
| 0xCD6
| 0xCD6
| Reserved
| Reserved
|}
|}
! SIZE
! SIZE
! DESCRIPTION
! DESCRIPTION
|-
| 0x1000
| 0x200
| InitialData
|-
|-
| 0x1200
| 0x1200
| 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"
|-
|-
! 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 ==