OTP Registers

2023-04-19T00:21:25Z

Liam:

This region (0x10012000-0x10012100) is used as persistent storage on SoC and for passing the TWL console ID around (0x10012100-0x10012108).

== Overview ==

Console-unique keys are derived from here. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

This is the console-unique data store, including [[CTCert]] etc, that ends up in ITCM at 0x01FFB800. After decryption, the first 0x90-bytes of plaintext are copied to 0x01FFB800 if hash verification passes. Refer to [[Memory_layout#ARM9_ITCM]] for what is contained in the decrypted OTP.

On [[FIRM]] versions prior to [[3.0.0-6|3.0.0-X]], this region was left unprotected. On versions since [[3.0.0-6|3.0.0-X]], this has been fixed, and the region disable is now done by Kernel9 after doing console-unique TWL keyinit, by setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for New 3DS key generation.

On development units ([[CONFIG|UNITINFO]] != 0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]].

Normally [[Bootloader|Boot9]] will pass plaintext_otp+0x90 to the AES keyinit function, but when hash verification fails it will pass 0x10012000(otp+0) instead.

== Sections ==

{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| Console-unique data encrypted with AES-CBC. The normalkey and IV are stored in Boot9(retail/devunit have seperate normalkey+IV for this). The last 0x20-bytes of plaintext are a SHA256 hash over the first 0xE0-bytes of plaintext.
|-
| 0x100
| 0x8
| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.
|}

== Plaintext OTP ==
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| This is always 0xDEADB00F.
|-
| 0x4
| 0x4
| This is the u32 DeviceId.
|-
| 0x8
| 0x10
| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the first two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
|-
| 0x18
| 0x1
| OTP version
|-
| 0x19
| 0x1
| This determines if the OTP is for a dev system; it indicates the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
|-
| 0x1A
| 0x6
| Manufacturing date (of the SoC?). Usually month(s) before the dates in the logs stored in [[Flash_Filesystem|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte. This order matches up with the layout of a <code>struct tm</code>.
|-
| 0x20
| 0x4
| This is the CTCert expiry time as UNIX timestamp, this is specified in big endian if the OTP version is <5.
|-
| 0x24
| 0x20
| This is the CTCert ECDSA privk.
|-
| 0x44
| 0x3C
| This is the CTCert ECDSA signature (sect233r1?/SHA-256).
|-
| 0x80
| 0x10
| This is all-zero.
|-
| 0x90
| 0x70
| Used by Boot9 for generating the console-unique AES [[AES_Registers|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.

Note that the size passed to the Boot9 keyinit code for console-unique-buffer-size is 0x70, hence this includes the below OTP hash.
|-
| 0xE0
| 0x20
| SHA256 hash over the previous 0xE0-bytes.
|}

NCSD

2022-09-12T10:53:38Z

Liam:

[[Category:File formats]]
This page documents the format of NCSD.

== Overview ==
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.

'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].

NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.

For CCI images, the partitions are reserved as follows:

{| class="wikitable" border="1"
|-
! [[NCCH]] Index
! Reserved Use
|-
| 0
| Executable Content ([[NCCH#CXI|CXI]])
|-
| 1
| E-Manual ([[NCCH#CFA|CFA]])
|-
| 2
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])
|-
| 6
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])
|-
| 7
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])
|}

The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).

== NCSD header ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000
| 0x100
| RSA-2048 SHA-256 signature of the NCSD header
|-
| 0x100
| 4
| Magic Number 'NCSD'
|-
| 0x104
| 4
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)
|-
| 0x108
| 8
| Media ID
|-
| 0x110
| 8
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)
|-
| 0x118
| 8
| Partitions crypt type (each byte corresponds to a partition in the partition table)
|-
| 0x120
| 0x40=(4+4)*8
| Offset & Length partition table, in media units
|-
| 0x160
| 0xA0
| ...
|}

For carts,
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x160
| 0x20
| Exheader SHA-256 hash
|-
| 0x180
| 0x4
| Additional header size
|-
| 0x184
| 0x4
| Sector zero offset
|-
| 0x188
| 8
| Partition Flags (See Below)
|-
| 0x190
| 0x40=8*8
| Partition ID table
|-
| 0x1D0
| 0x20
| Reserved
|-
| 0x1F0
| 0xE
| Reserved?
|-
| 0x1FE
| 0x1
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.
|-
| 0x1FF
| 0x1
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.
|}

For NAND,

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x160
| 0x5E
| Unknown
|-
| 0x1BE
| 0x42
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).
|}

=== NCSD Signature ===
The RSA public key used for gamecard NCSD is stored in [[Memory_layout|ITCM]]. The separate public key used for NAND NCSD is stored in Process9 .(ro)data instead of ITCM, and in [[Bootloader|boot ROM]].

For the boot ROM check, sighax may be used to fake-sign NAND headers. Process9's check will fail, however, unless patched.

=== Partition Flags ===
{| class="wikitable" border="1"
|-
! Byte Index
! Description
|-
| 0
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].
|-
| 3
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)
|-
| 4
| Media Platform Index (1 = CTR)
|-
| 5
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)
|-
| 6
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];
|-
| 7
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)
|}

=== Partition Flags (In Terms of Save Crypto Determination) ===
{| class="wikitable" border="1"
|-
! Byte Index
! Description
|-
| 1
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].
|-
| 3
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.
|-th
| 7
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.
|}

Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.

== Card Info Header ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x200
| 4
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.
|-
| 0x204
| 4
| Card Info Bitmask
|-
| 0x208
| 0xF8
| Reserved
|-
| 0x300
| 4
| Filled size of cartridge
|-
| 0x304
| 0xC
| Reserved
|-
| 0x310
| 2
| Title version
|-
| 0x312
| 2
| Card revision
|-
| 0x314
| 0xC
| Reserved
|-
| 0x320
| 8
| Title ID of [[CVer]] in included update partition
|-
| 0x328
| 2
| Version number of [[CVer]] in included update partition
|-
| 0x32A
| 0xCD6
| Reserved
|}

== Development Card Info Header Extension ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x1000
| 0x200
| InitialData
|-
| 0x1200
| 0x200
| CardDeviceReserved1
|-
| 0x1400
| 0x10
| TitleKeyData
|-
| 0x1410
| 0x1BF0
| CardDeviceReserved2
|-
| 0x3000
| 0x1000
| 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.

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"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x10
| 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.
|-
| 0x8
| 0x1F8
| 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).
|-
| 0x400
| 0x200
| Filled with 00 (0b00000000) bytes.
|-
| 0x600
| 0x200
| Filled with FF (0b11111111) bytes.
|-
| 0x800
| 0x200
| Filled with 0F (0b00001111) bytes.
|-
| 0xA00
| 0x200
| Filled with F0 (0b11110000) bytes.
|-
| 0xC00
| 0x200
| Filled with 55 (0b01010101) bytes.
|-
| 0xE00
| 0x1FF
| Filled with AA (0b10101010) bytes.
|-
| 0xFFF
| 0x1
| 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 ==

[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files

[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files

3dbrew - User contributions [en]

OTP Registers

NCSD