3dbrew - User contributions [en]

Gamecards

2024-06-01T11:11:43Z

AriA99: Link to where the 0x200 InitialData comes from, I noticed the pattern looking at the Lotus3 page at Switchbrew

[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]]
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]]

===Physical interface===
The 3DS gamecards have the same physical interface as regular DS and DSi gamecards. There is only a minor cosmetic difference in the plastic case, which has a small extruding notch on the top-right side. As such, it prevents insertion of the gamecard into old Nintendo DS or DSi systems.

When modifying the case so that the 3DS gamecard fits in a DS or DSi system, those systems will refuse to detect the gamecard and show no banner icon.

{| class="wikitable" border="1"
|-
! Pin
! Name
!colspan="2"| Description
|-
| 1
| GND
|colspan="2"| Ground
|-
| 2
| CLK
|colspan="2"| Clock. Frequencies 6.7MHz and 4.2MHz for DS/DSi gamecards, up to 16.6MHz for 3DS gamecards (for both SPI and ROM transfers).
|-
| 3
| NC
|colspan="2"| Not connected. Possibly used to program cards.
|-
| 4
| RCS
|colspan="2"| ROM select, active low. Pulled low to start a ROM transfer.
|-
| 5
| RST
|colspan="2"| Reset, active low.
|-
| 6
| ECS
|colspan="2"| Savegame chip select, active low. Pulled low to start a savegame SPI transfer.
|-
| 7
| IRQ
|colspan="2"| Removal detection.
|-
| 8
| VCC
|colspan="2"| Powersupply 3.3V.
|-
!
!
! ROM bus (selected by RCS)
! Savegame bus (selected by ECS)
|-
| 9
| DAT0
|rowspan="8"| Bidirectional data bus.
|rowspan="4"| NC
|-
| 10
| DAT1
|-
| 11
| DAT2
|-
| 12
| DAT3
|-
| 13
| DAT4
| NC/SIO3
|-
| 14
| DAT5
| WP#/SIO2
|-
| 15
| DAT6
| SO/SIO1
|-
| 16
| DAT7
| SI/SIO0
|-
| 17
| GND
|colspan="2"| Ground
|}

{| class="wikitable" border="1"
|-
!
! 3DS
! DS and DSi
|-
| VCC
| Only enabled when the power supply bits of [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] are set to <tt>10</tt>
| Always available when card is detected
|-
| Card-detect
| Physical insertion switch, readable through [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] bit 0
| IRQ pin
|-
| Time to first clock pulse
| ~280ms
| ~166ms
|}

===SPI flash===
Savegame SPI flash transfers use CPOL=1 and CPHA=1. So far, only one savegame FLASH chip has been identified. The chip identifies as <tt>0xC22211</tt>. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at: 
[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] 
[https://web.archive.org/web/20160307235354/http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf Old version mirror (Rev. 0.01, apr. 07, 2010)] 
However, the MX25L1021E doesn't support the 4 bit wide transmission that the 3DS uses to talk to the SPI flash. It is thus likely that this is a custom flash chip.

===Format===
Cartridges can come in several sizes and include system updates in a region reserved for this. In ROMs less than 1GB the update region can be found with:
CART_SIZE_MAX-( 0x280000*(CART_SIZE_MAX/CART_SIZE_128MB) )-0x2000000. The region is then 0x2000000 bytes.

===Protocol===
The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the [http://problemkaputt.de/gbatek.htm#dscartridgeprotocol DS and DSi gamecard communication protocol].

The protocol begins in a DS-compatible 8-byte command mode (unencrypted). It switches to a 3DS-only 16-byte mode (encrypted) after the 0x3e command. When 16-byte commands are used, the data bus maintains the value 0x00 until the card signals it is ready by clocking a single byte 0x01, followed by the actual data. After each 0x200-byte block of actual data, a 4-byte standard CRC32 of the block data (before encryption, polynomial 0x82608edb and the final output is xored with 0xffffffff) follows.

Here's a set of sample gamecard commands for the title LEGO Star Wars III The Clone Wars (EUR), title ID 0004000000038c00, that a 3DS sends to a 3DS gamecard:

{| class="wikitable" border="1"
|-
! Size
! Command
! Decrypted command
! Description
|-
|<tt>2000</tt>
|<tt>9F00000000000000</tt>
|<tt>9F00000000000000</tt>
|Reset
|-
|<tt>0000</tt>
|<tt>71C93FE9BB0A3B18</tt>
|<tt>71C93FE9BB0A3B18</tt>
|Signal that the gamecard should act as a 3DS gamecard
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|<tt>9000000000000000</tt>
|Get gamecard ID1, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|<tt>9000000000000000</tt>
|Get gamecard ID1, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>A000000000000000</tt>
|<tt>A000000000000000</tt>
|Get gamecard ID2, response=00000000
|-
|<tt>0000</tt>
|<tt>3E00000000000000</tt>
|<tt>3E00000000000000</tt>
|Enter 16-byte command mode
|-
|<tt>0200</tt>
|<tt>82000000000000000000000000000000</tt>
|<tt>82000000000000000000000000000000</tt>
|Get gamecard header and enable encryption
|-
|<tt>0000</tt>
|<tt>F32C92D85C9D44DED3E0E41DBE7C90D9</tt>
|<tt>8300000000000000708DF1A731717D0B</tt>
|Seed (rekey cryptography)
|-
|<tt>0004</tt>
|<tt>696B9D8582FB55D31B68CAFE70C74A95</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>BAA4812CA0AC9C5D19399530E3ACCCAB</tt>
|<tt>A300000000000000708DF1A731717D0B</tt>
|Get gamecard ID2 (using cryptography)
|-
|<tt>0000</tt>
|<tt>178E427C22D87ADB86387249A97D321A</tt>
|<tt>C500000000000000708DF1A731717D0B</tt>
|Refresh cart NAND
|-
|<tt>0004</tt>
|<tt>E06019B1BD5C9130ED6A4D9F4A9E7193</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4E0D224862523BBFE2E6255F80E15F37</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4CDF93D319FB62D0DB632A45E3E8D84C</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9AA5D80551002F955546D296A57F0FEF</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>C12BA81AEF30DDDBD93FAD5D544C6334</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0200</tt>
|<tt>62EC5FB7F420AE1DC6253AE18AFA5BB3</tt>
|<tt>BF000000000000000000000000000000</tt>
|Read gamecard at address 0
|-
|<tt>0200</tt>
|<tt>E3FA23AA016BE0C93430D1F42FF41324</tt>
|<tt>BF000000000040000000000000000000</tt>
|Read gamecard at address 0x4000
|}

The header command has some initial dummy bytes, and eventually responds with the 0x200 byte [[NCSD#InitialData|InitialData]]. Here's an example for Lego Starwars 3:
0000000: 00 8c 03 00 00 00 04 00 00 00 00 00 00 00 00 00 ................
0000010: b3 cf fb c6 6a b1 cb 20 32 af ce 35 d4 1c 74 c9 ....j.. 2..5..t.
0000020: 8e 6b 27 2f 08 01 28 3b d4 30 de 44 37 f5 b0 46 .k'/..(;.0.D7..F
0000030: 91 59 d7 38 33 48 df 83 fd 71 84 2c 00 00 00 00 .Y.83H...q.,....
0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000100: 4e 43 43 48 7a 7f 0e 00 00 8c 03 00 00 00 04 00 NCCHz...........
0000110: 36 34 02 00 00 00 00 00 00 8c 03 00 00 00 04 00 64..............
0000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000150: 43 54 52 2d 50 2d 41 4c 47 50 00 00 00 00 00 00 CTR-P-ALGP......
0000160: 0c 27 e3 c1 de 7b 2a e2 d3 11 4f 32 a4 ee bf 46 .'...{*...O2...F
0000170: 9a fd 0c f3 52 c1 1d 49 84 c2 a9 f1 d2 14 4c 63 ....R..I......Lc
0000180: 00 04 00 00 00 00 00 00 00 00 00 00 01 03 00 00 ................
0000190: 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00001a0: 06 00 00 00 1c 0a 00 00 01 00 00 00 00 00 00 00 ................
00001b0: 22 0a 00 00 58 75 0e 00 01 00 00 00 00 00 00 00 "...Xu..........
00001c0: 13 0c 04 26 15 f6 47 c4 c6 32 25 ea 9e 67 f8 a2 ...&..G..2%..g..
00001d0: 7b 15 24 6b 88 fb c7 a9 27 25 7b 84 97 7b 78 7b {.$k....'%{..{x{
00001e0: a6 5b ee 10 60 bb 6a 68 21 bb ce c6 00 03 5b 7e .[..`.jh!.....[~
00001f0: 64 fb 6e ac a7 f0 96 0c fb 1f 5a 37 08 77 28 f7 d.n.......Z7.w(.

After the 0x82 command, cryptography is initialized, which can be reproduced following this algorithm; unless noted otherwise, all operations are in big endian byte order:

# Set the [[AES_Registers|AES keyslot 0x3b keyY]] to the values at 0x000:0x010. The corresponding keyX is set in [[Bootloader|Boot9]].
# Decrypt the 16 bytes at 0x010:0x020 using AES-128-CCM in keyslot 0x3b using the 12-byte nonce at 0x030:0x03c to obtain the primary seed; if the response to the 0xa0 command AND 0x00000003 equals 3, instead use slot 0x11 and set the normalkey to 0x00000000000000000000000000000000. Verify that the 16-byte tag at 0x020:0x030 is valid.
# Split the primary seed into two halves: left and right.
# Initialize a context for the SNOW 2.0 stream cipher. The 128-bit key is the primary seed. The 128-bit IV is a 128-bit static value depending on the gamecard ID2.
# Call the SNOW 2.0 stream cipher 32 times to obtain 1024 bits (32 words) of output. Discard them.
# Initialize a context for the RC4 stream cipher. The 256-bit key consists of a 128-bit static value depending on the gamecard ID2 followed by four outputs of the SNOW 2.0 stream.
# Call the RC4 stream cipher 256 times to obtain 2048 bits (256 bytes) of output. Discard them.

All commands and responses are now encrypted using RC4. The gamecard controller and gamecard itself share the RC4 key and advance the state accordingly.

If the 0x83 command is sent, the cryptography is re-keyed:

# Initialize a new context for the SNOW 2.0 stream cipher. The 128-bit key consists of the left half of the primary seed followed by the lower 64 bytes of the decrypted 0x83 command. The 128-bit IV is the same 128-bit static value depending on the gamecard ID2 as before.
# Call the SNOW 2.0 stream cipher 32 times to obtain 1024 bits (32 words) of output. Discard them.
# Initialize a new context for the RC4 stream cipher. The 256-bit key consists of the same 128-bit static value depending on the gamecard ID2 as before followed by four outputs of the new SNOW 2.0 stream.
# Call the RC4 stream cipher 256 times to obtain 2048 bits (256 bytes) of output. Discard them.

The above example commands can be decrypted in this manner.

The static values are fixed in the gamecard controller and gamecards themselves, they are not obtained from Process9 or anywhere in NATIVE_FIRM.

NCSD

2024-06-01T11:07:53Z

AriA99: InitialData at +0x1000 is not part of the development cart extension

[[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
|-
| 0x1000
| 0x200
| InitialData
|}

=== InitialData ===

This data is returned by [[Gamecards|16-byte cartridge command]] 0x82.

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x08
| Title ID (little-endian)
|-
| 0x08
| 0x08
| Reserved (normally all-zero)
|-
| 0x10
| 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)
|-
| 0x20
| 0x10
| TitleKey (AES-CCM encrypted)
|-
| 0x30
| 0x10
| AES-CCM MAC
|-
| 0x40
| 0xC
| AES-CCM nonce
|-
| 0x3C
| 0xC4
| Reserved (normally all-zero)
|-
| 0x100
| 0x100
| NcchHeader (copy of the first NCCH header, excluding the RSA signature)
|}

== Development Card Info Header Extension ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 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, namely Gateway, puts what many refer to as "private headers" at CardDeviceReserved1 in place of actual development card information. This header consists of:

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x40
| Unique cartridge ID; only the first 0x10 bytes are meaningful, the rest are 0xff; obtainable using encrypted [[Gamecards|16-byte cartridge command]] 0xc6; the first 0x10 bytes can also be obtained in userland via [[Process_Services_PXI|pxi:ps9::GetRomId]]
|-
| 0x40
| 0x4
| Cartridge ID1; obtainable using 8-byte cartridge command 0x90 or 16-byte cartridge command 0xa2
|-
| 0x44
| 0x4
| Cartridge ID2; obtainable using 8-byte cartridge command 0xa0 or 16-byte cartridge command 0xa4
|-
| 0x48
| 0x8
| Padding (all-0xff)
|}

The legitimacy of the unique cartridge ID can be validated by online services.

Some dumping tools, notably GodMode9 as of 2024-05-26, erroneously always write 0x00000000 into the position of the Cartridge ID2. This is presumably because the cartridge ID2 is always zero for retail carts.

=== 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

PSPXI:GenerateRandomBytes

2024-05-26T06:01:15Z

AriA99: Add a short description how this thing works, the whole thing is too ugly to restate

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000D0042]
|-
| 1
| Output buffer size
|-
| 2
| (Size<<8) <nowiki>|</nowiki> 0x4
|-
| 3
| Output buffer pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=

Generates random bytes using the FIPS 186-2 (change notice 1) appendix 3 generator using SHA-1.

NCSD

2024-05-26T05:35:15Z

AriA99: /* Development Card Info Header Extension */ ID1 is unobtainable from userland

[[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, namely Gateway, puts what many refer to as "private headers" at CardDeviceReserved1 in place of actual development card information. This header consists of:

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x40
| Unique cartridge ID; only the first 0x10 bytes are meaningful, the rest are 0xff; obtainable using encrypted [[Gamecards|16-byte cartridge command]] 0xc6; the first 0x10 bytes can also be obtained in userland via [[Process_Services_PXI|pxi:ps9::GetRomId]]
|-
| 0x40
| 0x4
| Cartridge ID1; obtainable using 8-byte cartridge command 0x90 or 16-byte cartridge command 0xa2
|-
| 0x44
| 0x4
| Cartridge ID2; obtainable using 8-byte cartridge command 0xa0 or 16-byte cartridge command 0xa4
|-
| 0x48
| 0x8
| Padding (all-0xff)
|}

The legitimacy of the unique cartridge ID can be validated by online services.

Some dumping tools, notably GodMode9 as of 2024-05-26, erroneously always write 0x00000000 into the position of the Cartridge ID2. This is presumably because the cartridge ID2 is always zero for retail carts.

=== 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

NCSD

2024-05-26T05:34:04Z

AriA99: Properly specify private header

[[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, namely Gateway, puts what many refer to as "private headers" at CardDeviceReserved1 in place of actual development card information. This header consists of:

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x40
| Unique cartridge ID; only the first 0x10 bytes are meaningful, the rest are 0xff; obtainable using encrypted [[Gamecards|16-byte cartridge command]] 0xc6; the first 0x10 bytes can also be obtained in userland via [[Process_Services_PXI|pxi:ps9::GetRomId]]
|-
| 0x40
| 0x4
| Cartridge ID1; obtainable using 8-byte cartridge command 0x90 or 16-byte cartridge command 0xa2 or in userland via
|-
| 0x44
| 0x4
| Cartridge ID2; obtainable using 8-byte cartridge command 0xa0 or 16-byte cartridge command 0xa4
|-
| 0x48
| 0x8
| Padding (all-0xff)
|}

The legitimacy of the unique cartridge ID can be validated by online services.

Some dumping tools, notably GodMode9 as of 2024-05-26, erroneously always write 0x00000000 into the position of the Cartridge ID2. This is presumably because the cartridge ID2 is always zero for retail carts.

=== 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

Gamecards

2024-05-26T05:16:39Z

AriA99: Fix formatting because MediaWiki has terrible markup rules

[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]]
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]]

===Physical interface===
The 3DS gamecards have the same physical interface as regular DS and DSi gamecards. There is only a minor cosmetic difference in the plastic case, which has a small extruding notch on the top-right side. As such, it prevents insertion of the gamecard into old Nintendo DS or DSi systems.

When modifying the case so that the 3DS gamecard fits in a DS or DSi system, those systems will refuse to detect the gamecard and show no banner icon.

{| class="wikitable" border="1"
|-
! Pin
! Name
!colspan="2"| Description
|-
| 1
| GND
|colspan="2"| Ground
|-
| 2
| CLK
|colspan="2"| Clock. Frequencies 6.7MHz and 4.2MHz for DS/DSi gamecards, up to 16.6MHz for 3DS gamecards (for both SPI and ROM transfers).
|-
| 3
| NC
|colspan="2"| Not connected. Possibly used to program cards.
|-
| 4
| RCS
|colspan="2"| ROM select, active low. Pulled low to start a ROM transfer.
|-
| 5
| RST
|colspan="2"| Reset, active low.
|-
| 6
| ECS
|colspan="2"| Savegame chip select, active low. Pulled low to start a savegame SPI transfer.
|-
| 7
| IRQ
|colspan="2"| Removal detection.
|-
| 8
| VCC
|colspan="2"| Powersupply 3.3V.
|-
!
!
! ROM bus (selected by RCS)
! Savegame bus (selected by ECS)
|-
| 9
| DAT0
|rowspan="8"| Bidirectional data bus.
|rowspan="4"| NC
|-
| 10
| DAT1
|-
| 11
| DAT2
|-
| 12
| DAT3
|-
| 13
| DAT4
| NC/SIO3
|-
| 14
| DAT5
| WP#/SIO2
|-
| 15
| DAT6
| SO/SIO1
|-
| 16
| DAT7
| SI/SIO0
|-
| 17
| GND
|colspan="2"| Ground
|}

{| class="wikitable" border="1"
|-
!
! 3DS
! DS and DSi
|-
| VCC
| Only enabled when the power supply bits of [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] are set to <tt>10</tt>
| Always available when card is detected
|-
| Card-detect
| Physical insertion switch, readable through [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] bit 0
| IRQ pin
|-
| Time to first clock pulse
| ~280ms
| ~166ms
|}

===SPI flash===
Savegame SPI flash transfers use CPOL=1 and CPHA=1. So far, only one savegame FLASH chip has been identified. The chip identifies as <tt>0xC22211</tt>. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at: 
[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] 
[https://web.archive.org/web/20160307235354/http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf Old version mirror (Rev. 0.01, apr. 07, 2010)] 
However, the MX25L1021E doesn't support the 4 bit wide transmission that the 3DS uses to talk to the SPI flash. It is thus likely that this is a custom flash chip.

===Format===
Cartridges can come in several sizes and include system updates in a region reserved for this. In ROMs less than 1GB the update region can be found with:
CART_SIZE_MAX-( 0x280000*(CART_SIZE_MAX/CART_SIZE_128MB) )-0x2000000. The region is then 0x2000000 bytes.

===Protocol===
The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the [http://problemkaputt.de/gbatek.htm#dscartridgeprotocol DS and DSi gamecard communication protocol].

The protocol begins in a DS-compatible 8-byte command mode (unencrypted). It switches to a 3DS-only 16-byte mode (encrypted) after the 0x3e command. When 16-byte commands are used, the data bus maintains the value 0x00 until the card signals it is ready by clocking a single byte 0x01, followed by the actual data. After each 0x200-byte block of actual data, a 4-byte standard CRC32 of the block data (before encryption, polynomial 0x82608edb and the final output is xored with 0xffffffff) follows.

Here's a set of sample gamecard commands for the title LEGO Star Wars III The Clone Wars (EUR), title ID 0004000000038c00, that a 3DS sends to a 3DS gamecard:

{| class="wikitable" border="1"
|-
! Size
! Command
! Decrypted command
! Description
|-
|<tt>2000</tt>
|<tt>9F00000000000000</tt>
|<tt>9F00000000000000</tt>
|Reset
|-
|<tt>0000</tt>
|<tt>71C93FE9BB0A3B18</tt>
|<tt>71C93FE9BB0A3B18</tt>
|Signal that the gamecard should act as a 3DS gamecard
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|<tt>9000000000000000</tt>
|Get gamecard ID1, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|<tt>9000000000000000</tt>
|Get gamecard ID1, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>A000000000000000</tt>
|<tt>A000000000000000</tt>
|Get gamecard ID2, response=00000000
|-
|<tt>0000</tt>
|<tt>3E00000000000000</tt>
|<tt>3E00000000000000</tt>
|Enter 16-byte command mode
|-
|<tt>0200</tt>
|<tt>82000000000000000000000000000000</tt>
|<tt>82000000000000000000000000000000</tt>
|Get gamecard header and enable encryption
|-
|<tt>0000</tt>
|<tt>F32C92D85C9D44DED3E0E41DBE7C90D9</tt>
|<tt>8300000000000000708DF1A731717D0B</tt>
|Seed (rekey cryptography)
|-
|<tt>0004</tt>
|<tt>696B9D8582FB55D31B68CAFE70C74A95</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>BAA4812CA0AC9C5D19399530E3ACCCAB</tt>
|<tt>A300000000000000708DF1A731717D0B</tt>
|Get gamecard ID2 (using cryptography)
|-
|<tt>0000</tt>
|<tt>178E427C22D87ADB86387249A97D321A</tt>
|<tt>C500000000000000708DF1A731717D0B</tt>
|Refresh cart NAND
|-
|<tt>0004</tt>
|<tt>E06019B1BD5C9130ED6A4D9F4A9E7193</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4E0D224862523BBFE2E6255F80E15F37</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4CDF93D319FB62D0DB632A45E3E8D84C</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9AA5D80551002F955546D296A57F0FEF</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>C12BA81AEF30DDDBD93FAD5D544C6334</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0200</tt>
|<tt>62EC5FB7F420AE1DC6253AE18AFA5BB3</tt>
|<tt>BF000000000000000000000000000000</tt>
|Read gamecard at address 0
|-
|<tt>0200</tt>
|<tt>E3FA23AA016BE0C93430D1F42FF41324</tt>
|<tt>BF000000000040000000000000000000</tt>
|Read gamecard at address 0x4000
|}

The header command has some initial dummy bytes, and eventually responds with a 0x200 byte header. Here's an example for Lego Starwars 3:
0000000: 00 8c 03 00 00 00 04 00 00 00 00 00 00 00 00 00 ................
0000010: b3 cf fb c6 6a b1 cb 20 32 af ce 35 d4 1c 74 c9 ....j.. 2..5..t.
0000020: 8e 6b 27 2f 08 01 28 3b d4 30 de 44 37 f5 b0 46 .k'/..(;.0.D7..F
0000030: 91 59 d7 38 33 48 df 83 fd 71 84 2c 00 00 00 00 .Y.83H...q.,....
0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000100: 4e 43 43 48 7a 7f 0e 00 00 8c 03 00 00 00 04 00 NCCHz...........
0000110: 36 34 02 00 00 00 00 00 00 8c 03 00 00 00 04 00 64..............
0000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000150: 43 54 52 2d 50 2d 41 4c 47 50 00 00 00 00 00 00 CTR-P-ALGP......
0000160: 0c 27 e3 c1 de 7b 2a e2 d3 11 4f 32 a4 ee bf 46 .'...{*...O2...F
0000170: 9a fd 0c f3 52 c1 1d 49 84 c2 a9 f1 d2 14 4c 63 ....R..I......Lc
0000180: 00 04 00 00 00 00 00 00 00 00 00 00 01 03 00 00 ................
0000190: 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00001a0: 06 00 00 00 1c 0a 00 00 01 00 00 00 00 00 00 00 ................
00001b0: 22 0a 00 00 58 75 0e 00 01 00 00 00 00 00 00 00 "...Xu..........
00001c0: 13 0c 04 26 15 f6 47 c4 c6 32 25 ea 9e 67 f8 a2 ...&..G..2%..g..
00001d0: 7b 15 24 6b 88 fb c7 a9 27 25 7b 84 97 7b 78 7b {.$k....'%{..{x{
00001e0: a6 5b ee 10 60 bb 6a 68 21 bb ce c6 00 03 5b 7e .[..`.jh!.....[~
00001f0: 64 fb 6e ac a7 f0 96 0c fb 1f 5a 37 08 77 28 f7 d.n.......Z7.w(.

After the 0x82 command, cryptography is initialized, which can be reproduced following this algorithm; unless noted otherwise, all operations are in big endian byte order:

# Set the [[AES_Registers|AES keyslot 0x3b keyY]] to the values at 0x000:0x010. The corresponding keyX is set in [[Bootloader|Boot9]].
# Decrypt the 16 bytes at 0x010:0x020 using AES-128-CCM in keyslot 0x3b using the 12-byte nonce at 0x030:0x03c to obtain the primary seed; if the response to the 0xa0 command AND 0x00000003 equals 3, instead use slot 0x11 and set the normalkey to 0x00000000000000000000000000000000. Verify that the 16-byte tag at 0x020:0x030 is valid.
# Split the primary seed into two halves: left and right.
# Initialize a context for the SNOW 2.0 stream cipher. The 128-bit key is the primary seed. The 128-bit IV is a 128-bit static value depending on the gamecard ID2.
# Call the SNOW 2.0 stream cipher 32 times to obtain 1024 bits (32 words) of output. Discard them.
# Initialize a context for the RC4 stream cipher. The 256-bit key consists of a 128-bit static value depending on the gamecard ID2 followed by four outputs of the SNOW 2.0 stream.
# Call the RC4 stream cipher 256 times to obtain 2048 bits (256 bytes) of output. Discard them.

All commands and responses are now encrypted using RC4. The gamecard controller and gamecard itself share the RC4 key and advance the state accordingly.

If the 0x83 command is sent, the cryptography is re-keyed:

# Initialize a new context for the SNOW 2.0 stream cipher. The 128-bit key consists of the left half of the primary seed followed by the lower 64 bytes of the decrypted 0x83 command. The 128-bit IV is the same 128-bit static value depending on the gamecard ID2 as before.
# Call the SNOW 2.0 stream cipher 32 times to obtain 1024 bits (32 words) of output. Discard them.
# Initialize a new context for the RC4 stream cipher. The 256-bit key consists of the same 128-bit static value depending on the gamecard ID2 as before followed by four outputs of the new SNOW 2.0 stream.
# Call the RC4 stream cipher 256 times to obtain 2048 bits (256 bytes) of output. Discard them.

The above example commands can be decrypted in this manner.

The static values are fixed in the gamecard controller and gamecards themselves, they are not obtained from Process9 or anywhere in NATIVE_FIRM.

Gamecards

2024-05-26T05:15:06Z

AriA99: Describe cart cryptography protocol now that it is confirmed the Switch uses a different protocol

[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]]
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]]

===Physical interface===
The 3DS gamecards have the same physical interface as regular DS and DSi gamecards. There is only a minor cosmetic difference in the plastic case, which has a small extruding notch on the top-right side. As such, it prevents insertion of the gamecard into old Nintendo DS or DSi systems.

When modifying the case so that the 3DS gamecard fits in a DS or DSi system, those systems will refuse to detect the gamecard and show no banner icon.

{| class="wikitable" border="1"
|-
! Pin
! Name
!colspan="2"| Description
|-
| 1
| GND
|colspan="2"| Ground
|-
| 2
| CLK
|colspan="2"| Clock. Frequencies 6.7MHz and 4.2MHz for DS/DSi gamecards, up to 16.6MHz for 3DS gamecards (for both SPI and ROM transfers).
|-
| 3
| NC
|colspan="2"| Not connected. Possibly used to program cards.
|-
| 4
| RCS
|colspan="2"| ROM select, active low. Pulled low to start a ROM transfer.
|-
| 5
| RST
|colspan="2"| Reset, active low.
|-
| 6
| ECS
|colspan="2"| Savegame chip select, active low. Pulled low to start a savegame SPI transfer.
|-
| 7
| IRQ
|colspan="2"| Removal detection.
|-
| 8
| VCC
|colspan="2"| Powersupply 3.3V.
|-
!
!
! ROM bus (selected by RCS)
! Savegame bus (selected by ECS)
|-
| 9
| DAT0
|rowspan="8"| Bidirectional data bus.
|rowspan="4"| NC
|-
| 10
| DAT1
|-
| 11
| DAT2
|-
| 12
| DAT3
|-
| 13
| DAT4
| NC/SIO3
|-
| 14
| DAT5
| WP#/SIO2
|-
| 15
| DAT6
| SO/SIO1
|-
| 16
| DAT7
| SI/SIO0
|-
| 17
| GND
|colspan="2"| Ground
|}

{| class="wikitable" border="1"
|-
!
! 3DS
! DS and DSi
|-
| VCC
| Only enabled when the power supply bits of [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] are set to <tt>10</tt>
| Always available when card is detected
|-
| Card-detect
| Physical insertion switch, readable through [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] bit 0
| IRQ pin
|-
| Time to first clock pulse
| ~280ms
| ~166ms
|}

===SPI flash===
Savegame SPI flash transfers use CPOL=1 and CPHA=1. So far, only one savegame FLASH chip has been identified. The chip identifies as <tt>0xC22211</tt>. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at: 
[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] 
[https://web.archive.org/web/20160307235354/http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf Old version mirror (Rev. 0.01, apr. 07, 2010)] 
However, the MX25L1021E doesn't support the 4 bit wide transmission that the 3DS uses to talk to the SPI flash. It is thus likely that this is a custom flash chip.

===Format===
Cartridges can come in several sizes and include system updates in a region reserved for this. In ROMs less than 1GB the update region can be found with:
CART_SIZE_MAX-( 0x280000*(CART_SIZE_MAX/CART_SIZE_128MB) )-0x2000000. The region is then 0x2000000 bytes.

===Protocol===
The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the [http://problemkaputt.de/gbatek.htm#dscartridgeprotocol DS and DSi gamecard communication protocol].

The protocol begins in a DS-compatible 8-byte command mode (unencrypted). It switches to a 3DS-only 16-byte mode (encrypted) after the 0x3e command. When 16-byte commands are used, the data bus maintains the value 0x00 until the card signals it is ready by clocking a single byte 0x01, followed by the actual data. After each 0x200-byte block of actual data, a 4-byte standard CRC32 of the block data (before encryption, polynomial 0x82608edb and the final output is xored with 0xffffffff) follows.

Here's a set of sample gamecard commands for the title LEGO Star Wars III The Clone Wars (EUR), title ID 0004000000038c00, that a 3DS sends to a 3DS gamecard:

{| class="wikitable" border="1"
|-
! Size
! Command
! Decrypted command
! Description
|-
|<tt>2000</tt>
|<tt>9F00000000000000</tt>
|<tt>9F00000000000000</tt>
|Reset
|-
|<tt>0000</tt>
|<tt>71C93FE9BB0A3B18</tt>
|<tt>71C93FE9BB0A3B18</tt>
|Signal that the gamecard should act as a 3DS gamecard
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|<tt>9000000000000000</tt>
|Get gamecard ID1, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|<tt>9000000000000000</tt>
|Get gamecard ID1, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>A000000000000000</tt>
|<tt>A000000000000000</tt>
|Get gamecard ID2, response=00000000
|-
|<tt>0000</tt>
|<tt>3E00000000000000</tt>
|<tt>3E00000000000000</tt>
|Enter 16-byte command mode
|-
|<tt>0200</tt>
|<tt>82000000000000000000000000000000</tt>
|<tt>82000000000000000000000000000000</tt>
|Get gamecard header and enable encryption
|-
|<tt>0000</tt>
|<tt>F32C92D85C9D44DED3E0E41DBE7C90D9</tt>
|<tt>8300000000000000708DF1A731717D0B</tt>
|Seed (rekey cryptography)
|-
|<tt>0004</tt>
|<tt>696B9D8582FB55D31B68CAFE70C74A95</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>BAA4812CA0AC9C5D19399530E3ACCCAB</tt>
|<tt>A300000000000000708DF1A731717D0B</tt>
|Get gamecard ID2 (using cryptography)
|-
|<tt>0000</tt>
|<tt>178E427C22D87ADB86387249A97D321A</tt>
|<tt>C500000000000000708DF1A731717D0B</tt>
|Refresh cart NAND
|-
|<tt>0004</tt>
|<tt>E06019B1BD5C9130ED6A4D9F4A9E7193</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4E0D224862523BBFE2E6255F80E15F37</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4CDF93D319FB62D0DB632A45E3E8D84C</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9AA5D80551002F955546D296A57F0FEF</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0004</tt>
|<tt>C12BA81AEF30DDDBD93FAD5D544C6334</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
|Get gamecard ID1 (using cryptography), response=9000FEC2
|-
|<tt>0200</tt>
|<tt>62EC5FB7F420AE1DC6253AE18AFA5BB3</tt>
|<tt>BF000000000000000000000000000000</tt>
|Read gamecard at address 0
|-
|<tt>0200</tt>
|<tt>E3FA23AA016BE0C93430D1F42FF41324</tt>
|<tt>BF000000000040000000000000000000</tt>
|Read gamecard at address 0x4000
|}

The header command has some initial dummy bytes, and eventually responds with a 0x200 byte header. Here's an example for Lego Starwars 3:
0000000: 00 8c 03 00 00 00 04 00 00 00 00 00 00 00 00 00 ................
0000010: b3 cf fb c6 6a b1 cb 20 32 af ce 35 d4 1c 74 c9 ....j.. 2..5..t.
0000020: 8e 6b 27 2f 08 01 28 3b d4 30 de 44 37 f5 b0 46 .k'/..(;.0.D7..F
0000030: 91 59 d7 38 33 48 df 83 fd 71 84 2c 00 00 00 00 .Y.83H...q.,....
0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000100: 4e 43 43 48 7a 7f 0e 00 00 8c 03 00 00 00 04 00 NCCHz...........
0000110: 36 34 02 00 00 00 00 00 00 8c 03 00 00 00 04 00 64..............
0000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000150: 43 54 52 2d 50 2d 41 4c 47 50 00 00 00 00 00 00 CTR-P-ALGP......
0000160: 0c 27 e3 c1 de 7b 2a e2 d3 11 4f 32 a4 ee bf 46 .'...{*...O2...F
0000170: 9a fd 0c f3 52 c1 1d 49 84 c2 a9 f1 d2 14 4c 63 ....R..I......Lc
0000180: 00 04 00 00 00 00 00 00 00 00 00 00 01 03 00 00 ................
0000190: 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00001a0: 06 00 00 00 1c 0a 00 00 01 00 00 00 00 00 00 00 ................
00001b0: 22 0a 00 00 58 75 0e 00 01 00 00 00 00 00 00 00 "...Xu..........
00001c0: 13 0c 04 26 15 f6 47 c4 c6 32 25 ea 9e 67 f8 a2 ...&..G..2%..g..
00001d0: 7b 15 24 6b 88 fb c7 a9 27 25 7b 84 97 7b 78 7b {.$k....'%{..{x{
00001e0: a6 5b ee 10 60 bb 6a 68 21 bb ce c6 00 03 5b 7e .[..`.jh!.....[~
00001f0: 64 fb 6e ac a7 f0 96 0c fb 1f 5a 37 08 77 28 f7 d.n.......Z7.w(.

After the 0x82 command, cryptography is initialized, which can be reproduced following this algorithm; unless noted otherwise, all operations are in big endian byte order:

1. Set the [[AES_Registers|AES keyslot 0x3b keyY]] to the values at 0x000:0x010. The corresponding keyX is set in [[Bootloader|Boot9]].
2. Decrypt the 16 bytes at 0x010:0x020 using AES-128-CCM in keyslot 0x3b using the 12-byte nonce at 0x030:0x03c to obtain the primary seed; if the response to the 0xa0 command AND 0x00000003 equals 3, instead use slot 0x11 and set the normalkey to 0x00000000000000000000000000000000. Verify that the 16-byte tag at 0x020:0x030 is valid.
3. Split the primary seed into two halves: left and right.
4. Initialize a context for the SNOW 2.0 stream cipher. The 128-bit key is the primary seed. The 128-bit IV is a 128-bit static value depending on the gamecard ID2.
5. Call the SNOW 2.0 stream cipher 32 times to obtain 1024 bits (32 words) of output. Discard them.
6. Initialize a context for the RC4 stream cipher. The 256-bit key consists of a 128-bit static value depending on the gamecard ID2 followed by four outputs of the SNOW 2.0 stream.
7. Call the RC4 stream cipher 256 times to obtain 2048 bits (256 bytes) of output. Discard them.

All commands and responses are now encrypted using RC4. The gamecard controller and gamecard itself share the RC4 key and advance the state accordingly.

If the 0x83 command is sent, the cryptography is re-keyed:

1. Initialize a new context for the SNOW 2.0 stream cipher. The 128-bit key consists of the left half of the primary seed followed by the lower 64 bytes of the decrypted 0x83 command. The 128-bit IV is the same 128-bit static value depending on the gamecard ID2 as before.
2. Call the SNOW 2.0 stream cipher 32 times to obtain 1024 bits (32 words) of output. Discard them.
3. Initialize a new context for the RC4 stream cipher. The 256-bit key consists of the same 128-bit static value depending on the gamecard ID2 as before followed by four outputs of the new SNOW 2.0 stream.
4. Call the RC4 stream cipher 256 times to obtain 2048 bits (256 bytes) of output. Discard them.

The above example commands can be decrypted in this manner.

The static values are fixed in the gamecard controller and gamecards themselves, they are not obtained from Process9 or anywhere in NATIVE_FIRM.

Gamecards

2024-05-26T04:13:24Z

AriA99: Details on CRC-32

[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]]
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]]

===Physical interface===
The 3DS gamecards have the same physical interface as regular DS and DSi gamecards. There is only a minor cosmetic difference in the plastic case, which has a small extruding notch on the top-right side. As such, it prevents insertion of the gamecard into old Nintendo DS or DSi systems.

When modifying the case so that the 3DS gamecard fits in a DS or DSi system, those systems will refuse to detect the gamecard and show no banner icon.

{| class="wikitable" border="1"
|-
! Pin
! Name
!colspan="2"| Description
|-
| 1
| GND
|colspan="2"| Ground
|-
| 2
| CLK
|colspan="2"| Clock. Frequencies 6.7MHz and 4.2MHz for DS/DSi gamecards, up to 16.6MHz for 3DS gamecards (for both SPI and ROM transfers).
|-
| 3
| NC
|colspan="2"| Not connected. Possibly used to program cards.
|-
| 4
| RCS
|colspan="2"| ROM select, active low. Pulled low to start a ROM transfer.
|-
| 5
| RST
|colspan="2"| Reset, active low.
|-
| 6
| ECS
|colspan="2"| Savegame chip select, active low. Pulled low to start a savegame SPI transfer.
|-
| 7
| IRQ
|colspan="2"| Removal detection.
|-
| 8
| VCC
|colspan="2"| Powersupply 3.3V.
|-
!
!
! ROM bus (selected by RCS)
! Savegame bus (selected by ECS)
|-
| 9
| DAT0
|rowspan="8"| Bidirectional data bus.
|rowspan="4"| NC
|-
| 10
| DAT1
|-
| 11
| DAT2
|-
| 12
| DAT3
|-
| 13
| DAT4
| NC/SIO3
|-
| 14
| DAT5
| WP#/SIO2
|-
| 15
| DAT6
| SO/SIO1
|-
| 16
| DAT7
| SI/SIO0
|-
| 17
| GND
|colspan="2"| Ground
|}

{| class="wikitable" border="1"
|-
!
! 3DS
! DS and DSi
|-
| VCC
| Only enabled when the power supply bits of [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] are set to <tt>10</tt>
| Always available when card is detected
|-
| Card-detect
| Physical insertion switch, readable through [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] bit 0
| IRQ pin
|-
| Time to first clock pulse
| ~280ms
| ~166ms
|}

===SPI flash===
Savegame SPI flash transfers use CPOL=1 and CPHA=1. So far, only one savegame FLASH chip has been identified. The chip identifies as <tt>0xC22211</tt>. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at: 
[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] 
[https://web.archive.org/web/20160307235354/http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf Old version mirror (Rev. 0.01, apr. 07, 2010)] 
However, the MX25L1021E doesn't support the 4 bit wide transmission that the 3DS uses to talk to the SPI flash. It is thus likely that this is a custom flash chip.

===Format===
Cartridges can come in several sizes and include system updates in a region reserved for this. In ROMs less than 1GB the update region can be found with:
CART_SIZE_MAX-( 0x280000*(CART_SIZE_MAX/CART_SIZE_128MB) )-0x2000000. The region is then 0x2000000 bytes.

===Protocol===
The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the [http://problemkaputt.de/gbatek.htm#dscartridgeprotocol DS and DSi gamecard communication protocol].

After the sixth transfer, commands change size from 8 bytes to 16 bytes. Possibly a new encryption is used, such as AES CTR.
When 16-byte commands are used, the data bus maintains the value 0x00 until the card signals it is ready by clocking a single byte 0x01, followed by the actual data. After each 0x200-byte block of actual data, a 4-byte standard CRC32 of the block data (before encryption, polynomial 0x82608edb and the final output is xored with 0xffffffff) follows.

Here's a set of sample gamecard commands that a 3DS sends to a 3DS gamecard:

{| class="wikitable" border="1"
|-
! Size
! Command
! Decrypted command
! Description
|-
|<tt>2000</tt>
|<tt>9F00000000000000</tt>
|?
|Reset
|-
|<tt>0000</tt>
|<tt>71C93FE9BB0A3B18</tt>
|?
|Unknown
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|?
|Get gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9000000000000000</tt>
|?
| Get gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>A000000000000000</tt>
|?
| Unknown, response=00000000
|-
|<tt>0000</tt>
|<tt>3E00000000000000</tt>
|?
| Enter 16-byte command mode.
|-
|<tt>0200</tt>
|<tt>82000000000000000000000000000000</tt>
|?
| Get header
|-
|<tt>0000</tt>
|<tt>F32C92D85C9D44DED3E0E41DBE7C90D9</tt>
|<tt>8300000000000000708DF1A731717D0B</tt>
| Seed
|-
|<tt>0004</tt>
|<tt>696B9D8582FB55D31B68CAFE70C74A95</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
| Get secured gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>BAA4812CA0AC9C5D19399530E3ACCCAB</tt>
|<tt>A300000000000000708DF1A731717D0B</tt>
| Unknown
|-
|<tt>0000</tt>
|<tt>178E427C22D87ADB86387249A97D321A</tt>
|<tt>C500000000000000708DF1A731717D0B</tt>
| Unknown
|-
|<tt>0004</tt>
|<tt>E06019B1BD5C9130ED6A4D9F4A9E7193</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
| Get secured gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4E0D224862523BBFE2E6255F80E15F37</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
| Get secured gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>4CDF93D319FB62D0DB632A45E3E8D84C</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
| Get secured gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>9AA5D80551002F955546D296A57F0FEF</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
| Get secured gamecard ID, response=9000FEC2
|-
|<tt>0004</tt>
|<tt>C12BA81AEF30DDDBD93FAD5D544C6334</tt>
|<tt>A200000000000000708DF1A731717D0B</tt>
| Get secured gamecard ID, response=9000FEC2
|-
|<tt>0200</tt>
|<tt>62EC5FB7F420AE1DC6253AE18AFA5BB3</tt>
|<tt>BF000000000000000000000000000000</tt>
| Read address 0
|-
|<tt>0200</tt>
|<tt>E3FA23AA016BE0C93430D1F42FF41324</tt>
|<tt>BF000000000040000000000000000000</tt>
| Read address 0x4000
|}

The header command has some initial dummy bytes, and eventually responds with a 0x200 byte header. Here's an example for Lego Starwars 3:
0000000: 00 8c 03 00 00 00 04 00 00 00 00 00 00 00 00 00 ................
0000010: b3 cf fb c6 6a b1 cb 20 32 af ce 35 d4 1c 74 c9 ....j.. 2..5..t.
0000020: 8e 6b 27 2f 08 01 28 3b d4 30 de 44 37 f5 b0 46 .k'/..(;.0.D7..F
0000030: 91 59 d7 38 33 48 df 83 fd 71 84 2c 00 00 00 00 .Y.83H...q.,....
0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000100: 4e 43 43 48 7a 7f 0e 00 00 8c 03 00 00 00 04 00 NCCHz...........
0000110: 36 34 02 00 00 00 00 00 00 8c 03 00 00 00 04 00 64..............
0000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000150: 43 54 52 2d 50 2d 41 4c 47 50 00 00 00 00 00 00 CTR-P-ALGP......
0000160: 0c 27 e3 c1 de 7b 2a e2 d3 11 4f 32 a4 ee bf 46 .'...{*...O2...F
0000170: 9a fd 0c f3 52 c1 1d 49 84 c2 a9 f1 d2 14 4c 63 ....R..I......Lc
0000180: 00 04 00 00 00 00 00 00 00 00 00 00 01 03 00 00 ................
0000190: 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00001a0: 06 00 00 00 1c 0a 00 00 01 00 00 00 00 00 00 00 ................
00001b0: 22 0a 00 00 58 75 0e 00 01 00 00 00 00 00 00 00 "...Xu..........
00001c0: 13 0c 04 26 15 f6 47 c4 c6 32 25 ea 9e 67 f8 a2 ...&..G..2%..g..
00001d0: 7b 15 24 6b 88 fb c7 a9 27 25 7b 84 97 7b 78 7b {.$k....'%{..{x{
00001e0: a6 5b ee 10 60 bb 6a 68 21 bb ce c6 00 03 5b 7e .[..`.jh!.....[~
00001f0: 64 fb 6e ac a7 f0 96 0c fb 1f 5a 37 08 77 28 f7 d.n.......Z7.w(.

NIM Services

2017-01-27T18:48:14Z

AriA99: /* NIM server service "nim:s" */ Fix cmd header for AccountDeleteTitleETicketsSOAP. This ''should'' be accurate but I am not sure. NIM sucks.

[[Category:Services]]
= NIM user service "nim:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| Related to starting a sysupdate?
|-
| 0x00020000
| [[NIMU:GetUpdateDownloadProgress|GetUpdateDownloadProgress]]
|-
| 0x0003....
| ?
|-
| 0x00040000
| [[NIMU:FinishTitlesInstall|FinishTitlesInstall]]
|-
| 0x00050000
| This obtains an event handle. Home Menu will check whether a system update is available when this event is triggered.
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x00090000
| [[NIMU:CheckSysupdateAvailable|CheckSysupdateAvailable]]
|-
| 0x000A0000
| GetState
|-
| 0x000B0000
| [[NIMU:GetSystemTitleHash|GetSystemTitleHash]]
|-
| 0x000C0082
| ?
|-
| 0x000E0080
| ?
|-
| 0x000F0042
| ?
|-
| 0x00110000
| ?
|-
| 0x00130000
| ?
|-
| 0x00140000
| ?
|-
| 0x00150000
| ?
|-
| 0x00170042
| ?
|-
| 0x00180080
| ?
|-
| 0x00250000
| ?
|-
| 0x00260200
| ?
|-
| 0x00270000
| ?
|-
| 0x00280000
| ?
|-
| 0x00290246
| ?
|-
| 0x002A0000
| ?
|-
| 0x002B0000
| ?
|-
| 0x002C0000
| ?
|-
| 0x002D00C0
| ?
|-
| 0x00480002
| ?
|}

= NIM server service "nim:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010200
| [[NIMS:StartDownloadSimple|StartDownloadSimple]]
|-
| 0x00020000
| [[NIMS:CancelDownload|CancelDownload]]
|-
| 0x00030000
| [[NIMS:GetProgress|GetProgress]]
|-
| 0x00050082
| [[NIMS:UnregisterTask|UnregisterTask]]
|-
| 0x00060080
| [[NIMS:IsTaskRegistered|IsTaskRegistered]]
|-
| 0x000A0000
| [[NIMS:CheckSysupdateAvailableSOAP|CheckSysupdateAvailableSOAP]]
|-
| 0x000B0084
| [[NIMS:SetAttribute|SetAttribute]]
|-
| 0x0016020A
| [[NIMS:ListTitles|ListTitles]]
|-
| 0x00220080
| AccountDeleteTitleETicketsSOAP. The SOAP request is sent only after the ticket for the specified titleID has been successfully deleted.
|-
| 0x00290000
| [[NIMS:AccountCheckBalanceSOAP|AccountCheckBalanceSOAP]]
|-
| 0x002D0042
| [[NIMS:DownloadTickets|DownloadTickets]]
|-
| 0x003C0002
| [[NIMS:RegisterSelf|RegisterSelf]]
|-
| 0x003F0000
| GetInitializeResult. Checks whether nim is properly initialized or not. If it is not, the result code returned is non-zero.
|-
| 0x00420240
| [[NIMS:StartDownload|StartDownload]]
|-
| 0x00550246
| [[NIMS:RegisterTask|RegisterTask]]
|-
| 0x00570082
| [[NIMS:ConnectNoTicketDownload|ConnectNoTicketDownload]]
|}

= NIM server service "nim:aoc" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00030042
| SetApplicationId
|-
| 0x00040042
| SetTin
|-
| 0x000902D0
| ListContentSetsEx
|-
| 0x00180000
| GetBalance
|-
| 0x001D0000
| GetCustomerSupportCode
|-
| 0x00210000
| Initialize
|-
| 0x00240282
| CalculateContentsRequiredSize
|-
| 0x00250000
| RefreshServerTime
|}

= NIM service "nim:ndm" =

= kagiya server =
The nim system module communicates with a server called kagiya (kagiya-ctr.cdn.nintendo.net or kagiya-dev-ctr.cdn.nintendo.net for development units). It provides the 9.6 crypto seed in binary form for any given title ID under (HTTPS) kagiya-ctr.cdn.nintendo.net/title/0x%16llx/ext_key?country=%s, where %16llx is the title ID and %s is a country code as used in the [[EShop|eShop]].

=New3DS=
NIM module only uses [[PTMSYSM:CheckNew3DS|CheckNew3DS]] for determining what heap sizes to use, in two functions. One is for the size of the 0x08000000 vmem heap, the other is probably for some buffer allocated on that heap. The New3DS version of these sizes are 0x1C000-bytes larger than the Old3DS sizes here.

=HTTPS requests=

==Trusted RootCAs==
During startup NIM-module creates two RootCertChains with [[HTTP_Services|HTTPC]]. Both of these only contain the same [[HTTPC:RootCertChainAddDefaultCert|default]] cert with ID 0x3. The first RootCertChain is used with NetUpdateSOAP. Requests such as the "notifications.json" page don't use these RootCertChains(in this case just [[HTTPC:AddDefaultCert|default]] certID 0xB is used).

==SOAP==

===NetUpdateSOAP===
There are exactly 3 types of network SOAP requests used with [https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP NetUpdateSOAP] by NIM module, described below. This URL contained in NIM module itself is only used with GetSystemTitleHash. The other requests use an identical URL loaded from an ECommerceSOAP response instead.

See also [https://github.com/yellows8/ninupdates here].

====GetSystemUpdate====
Returns the current sysupdate title-listing. This also contains the SystemTitleHash returned by GetSystemTitleHash.

====GetSystemTitleHash====
Returns the current SystemTitleHash for the current sysupdate title-listing.

====GetSystemCommonETicket====
Returns the Base64-encoded cetk for each specified TitleId entry.

This is only used when installing new titles. This means with CDN system-updates, tickets are never installed except when a title is being installed for the first time. For example, a system on the latest system-version that was only ever updated via CDN has the same NATIVE_FIRM ticket installed from the factory.

=Sysupdate checking process=
This section describes the process used when checking whether a sysupdate is required.

First the GetSystemTitleHash SOAP request is done. Then the SystemTitleHash in savedata hash.dat is compared with the received one. If they match and the SystemTitleHash flag is set to value 0x03, it will immediately return that no sysupdate is required. Otherwise it will start the GetSystemUpdate SOAP request handling.

The GetSystemUpdate SOAP request contains a titlelist of all NAND system-titles. For GetSystemUpdate response parsing, it compares each SOAP title_entry with the NAND system titlelist. If a SOAP titleID isn't found in the NAND titlelist, this means NAND is missing a new title and hence a sysupdate is required for installing that title. If a NAND title_entry-version is less than the SOAP title_entry-version, this means the title needs updated and hence a sysupdate is required.

At least one <TitleVersion> entry with valid data in the GetSystemUpdate response is required.

The titleIDs sent in the GetSystemUpdate SOAP request are decimal, while the titleIDs in the response are hex.

=NIM [[System_SaveData]]=
==hash.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x60
| 0x1
| u8 flag used with the SystemTitleHash. 0x01 = latest sysupdate isn't installed as of last SOAP requests, 0x03 = latest sysupdate is installed as of last SOAP requests.
|-
| 0x61
| 0x21
| ASCII hex SystemTitleHash, including NUL-terminator. This is the latest SystemTitleHash which NIM module received from SOAP.
|}

=Types=
==InstallationMode==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Initial installation
|-
| 1
| Unknown
|-
| 2
| Unknown
|-
| 3
| Reinstallation
|}
==DownloadState==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not initialized
|-
| 1
| Download initialized
|-
| 2
| Downloading, verifying and installing TMD
|-
| 3
| Initializing save data
|-
| 4
| Downloading and installing contents
|-
| 5
| Waiting before calling [[AM:CommitImportPrograms]]
|-
| 6
| Running [[AM:CommitImportPrograms]]
|-
| 7
| Title installation finished
|-
| 8
| Unknown error regarding title version
|-
| 9
| Creating the .ctx file (or error doing so)?
|-
| 10
| Irrecoverable error encountered
|}
==TitleConfig==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x4
| Title version
|-
| 0xC
| 0x4
| Unknown (always 0)
|-
| 0x10
| 0x1
| Age rating for the HOME Menu parental controls
|-
| 0x11
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Unknown (always 0?)
|}
==TitleProgress==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| [[#DownloadState|Download State]]
|-
| 0x4
| 0x4
| Last result code in NIM related to the installation
|-
| 0x8
| 0x8
| Amount of bytes that have been downloaded
|-
| 0x10
| 0x8
| Total bytes that need to be downloaded
|}

NIMS:ConnectNoTicketDownload

2017-01-27T18:40:11Z

AriA99: /* Description */ Add note why it's called the way it's called

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00570082]
|-
| 1
| Pointer to a buffer
|-
| 2
| Length of the buffer
|-
| 3
| {{Tooltip|Descriptor|0x0000000c {{!}} (size <nowiki><<</nowiki> 4)}} for mapping a [[IPC#Buffer_Mapping_Translation|write-only buffer]] in the target process
|-
| 4
| Pointer to a buffer (same as input word 1)
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Connects [[NIM_Services|NIM]] to the network for further use. This is ''required'' before any actual actions, such as [[NIMS:RegisterTask]] or [[NIMS:StartDownload]] can be taken.

The buffer is a scratch buffer for nim. [[EShop|eShop]] provides a buffer of 0x20000 bytes.

This command does not appear to affect tickets.

NIMS:ConnectNoTicketDownload

2017-01-27T18:39:16Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00570082] |- | 1 | Pointer to a buffer |- | 2 | Length of the buffer |- | 3 |..."

NIMS:RegisterSelf

2017-01-27T18:34:58Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x003C0002] |- | 1 | {{Tooltip|Descriptor|0x20}} for IPC#Handle_Translation|p..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x003C0002]
|-
| 1
| {{Tooltip|Descriptor|0x20}} for [[IPC#Handle_Translation|process ID]]
|-
| 2
| 0x10
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Registers the current process with [[NIM_Services|NIM]]. This is ''required'' before any networking actions can be taken.

NIMS:SetAttribute

2017-01-27T18:31:01Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x000B0084] |- | 1 | Length of the attribute to set (''including'' trailing NUL..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000B0084]
|-
| 1
| Length of the attribute to set (''including'' trailing NUL)
|-
| 2
| Length of the value to set (''including'' trailing NUL if string)
|-
| 3
| {{Tooltip|Descriptor|0x00000002 {{!}} (size <nowiki><<</nowiki> 14) {{!}} (static_buffer_id <nowiki><<</nowiki> 10)}} for [[IPC#Static_Buffer_Translation|static buffer]] (id 0)
|-
| 4
| Pointer to the name of the attribute in ASCII to set
|-
| 5
| {{Tooltip|Descriptor|0x00000002 {{!}} (size <nowiki><<</nowiki> 14) {{!}} (static_buffer_id <nowiki><<</nowiki> 10)}} for [[IPC#Static_Buffer_Translation|static buffer]] (id 1)
|-
| 6
| Pointer to the value of the attribute to set
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Sets an attribute. The name of the attribute appears to be an ASCII string. The types of the attributes ''may'' vary (research required, only ASCII strings observed).

{| class="wikitable" border="1"
|-
! Attribute
! Value
|-
| TIN
| TIN (?). [[EShop|eShop]] sets this to (string!) "56789".
|}

NIMS:IsTaskRegistered

2017-01-27T18:25:50Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00060080] |- | 1-2 | Title ID to query for |} =Response= {| class="wikitable..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00060080]
|-
| 1-2
| Title ID to query for
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| (u8) non-zero if there is a task for the given title ID
|}

=Description=
Checks whether there is a task registered with [[NIMS:RegisterTask]] for the given title ID.

NIMS:UnregisterTask

2017-01-27T18:24:21Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00050082] |- | 1-2 | Title ID of the title whose task to remove |- | 3 | {{To..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00050082]
|-
| 1-2
| Title ID of the title whose task to remove
|-
| 3
| {{Tooltip|Descriptor|0x20}} for [[IPC#Handle_Translation|process ID]]
|-
| 4
| Placeholder for process ID
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Removes a task registered with [[NIMS:RegisterTask]].

NIMS:RegisterTask

2017-01-27T18:21:22Z

AriA99: Remove duplicate "Descriptor"

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00550246]
|-
| 1-6
| [[NIM_Services#TitleProgress|Title Progress]]
|-
| 7-8
| Unknown, not written by the system [[eShop]] application service command code *at* *all*.
|-
| 9
| Unknown, eShop always writes 0
|-
| 10
| {{Tooltip|Descriptor|0x20}} for [[IPC#Handle_Translation|process ID]]
|-
| 11
| Placeholder for process ID
|-
| 12
| {{Tooltip|Descriptor|0x00000002 {{!}} (size <nowiki><<</nowiki> 14) {{!}} (static_buffer_id <nowiki><<</nowiki> 10)}} for [[IPC#Static_Buffer_Translation|static buffer]] (id 1)
|-
| 13
| Pointer to the name of the title in UTF-16LE
|-
| 14
| {{Tooltip|Descriptor|0x00000002 {{!}} (size <nowiki><<</nowiki> 14) {{!}} (static_buffer_id <nowiki><<</nowiki> 10)}} for [[IPC#Static_Buffer_Translation|static buffer]] (id 5)
|-
| 15
| Pointer to the name of the developer of the title in UTF-16LE
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Registers a task for sleep mode downloading. A glowing, wrapped package with the information from input words 13 and 15 will be shown on the [[Home_Menu|Home Menu]].

NIMS:RegisterTask

2017-01-27T18:20:39Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00550246] |- | 1-6 | Title Progress |- | 7-8 |..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00550246]
|-
| 1-6
| [[NIM_Services#TitleProgress|Title Progress]]
|-
| 7-8
| Unknown, not written by the system [[eShop]] application service command code *at* *all*.
|-
| 9
| Unknown, eShop always writes 0
|-
| 10
| Descriptor for {{Tooltip|Descriptor|0x20}} for [[IPC#Handle_Translation|process ID]]
|-
| 11
| Placeholder for process ID
|-
| 12
| {{Tooltip|Descriptor|0x00000002 {{!}} (size <nowiki><<</nowiki> 14) {{!}} (static_buffer_id <nowiki><<</nowiki> 10)}} for [[IPC#Static_Buffer_Translation|static buffer]] (id 1)
|-
| 13
| Pointer to the name of the title in UTF-16LE
|-
| 14
| {{Tooltip|Descriptor|0x00000002 {{!}} (size <nowiki><<</nowiki> 14) {{!}} (static_buffer_id <nowiki><<</nowiki> 10)}} for [[IPC#Static_Buffer_Translation|static buffer]] (id 5)
|-
| 15
| Pointer to the name of the developer of the title in UTF-16LE
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Registers a task for sleep mode downloading. A glowing, wrapped package with the information from input words 13 and 15 will be shown on the [[Home_Menu|Home Menu]].

NIMS:GetProgress

2017-01-27T18:09:36Z

AriA99: /* Description */ Fix description that was wrongly copied and pasted.

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00030000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2-7
| [[NIM_Services#TitleProgress|Title Progress]] struct
|}

=Description=
Gets information about the current [[NIM_Services|NIM]] download, which was started with [[NIMS:StartDownload]] or [[NIMS:StartDownloadSimple]].

NIMS:GetProgress

2017-01-27T18:09:05Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00030000] |} =Response= {| class="wikitable" border="1" |- ! Index Word !..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00030000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2-7
| [[NIM_Services#TitleProgress|Title Progress]] struct
|}

=Description=
This cancels downloading the current [[NIM_Services|NIM]] download, which was started with [[NIMS:StartDownload]] or [[NIMS:StartDownloadSimple]].

NIMS:CancelDownload

2017-01-27T18:07:32Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00020000] |} =Response= {| class="wikitable" border="1" |- ! Index Word !..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00020000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This cancels downloading the current [[NIM_Services|NIM]] download, which was started with [[NIMS:StartDownload]] or [[NIMS:StartDownloadSimple]].

NIMS:StartDownloadSimple

2017-01-27T18:06:19Z

AriA99: Fix header code.

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00010200]
|-
| 1-6
| [[NIM_Services#TitleConfig|Title Config]]
|-
| 7-8
| Unknown, not written by the system [[eShop]] application service command code *at* *all*.
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This starts downloading the specified eShop title. The installation mode for [[NIMS:StartDownload]] appears to be automatically determined. See that page for further details.

NIMS:StartDownloadSimple

2017-01-27T18:05:41Z

AriA99: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00420240] |- | 1-6 | Title Config |- | 7-8 | Unk..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00420240]
|-
| 1-6
| [[NIM_Services#TitleConfig|Title Config]]
|-
| 7-8
| Unknown, not written by the system [[eShop]] application service command code *at* *all*.
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This starts downloading the specified eShop title. The installation mode for [[NIMS:StartDownload]] appears to be automatically determined. See that page for further details.

NIMS:StartDownload

2017-01-27T18:02:38Z

AriA99: Update with references to struct on NIM_Services and fill in missing u8.

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00420240]
|-
| 1-6
| [[NIM_Services#TitleConfig|Title Config]]
|-
| 7-8
| Unknown, not written by the system [[eShop]] application service command code *at* *all*.
|-
| 9
| [[NIM_Services#InstallationMode|Installation Mode]]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This starts downloading the specified eShop title in the given mode.

[[NIMS:GetProgress]] may be used to monitor the progress of installation. To abort the current download, see [[NIMS:CancelDownload]].

NIM Services

2017-01-27T17:56:15Z

AriA99: /* NIM server service "nim:s" */ Add stubs for filling in individual commands.

[[Category:Services]]
= NIM user service "nim:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| Related to starting a sysupdate?
|-
| 0x00020000
| [[NIMU:GetUpdateDownloadProgress|GetUpdateDownloadProgress]]
|-
| 0x0003....
| ?
|-
| 0x00040000
| [[NIMU:FinishTitlesInstall|FinishTitlesInstall]]
|-
| 0x00050000
| This obtains an event handle. Home Menu will check whether a system update is available when this event is triggered.
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x00090000
| [[NIMU:CheckSysupdateAvailable|CheckSysupdateAvailable]]
|-
| 0x000A0000
| GetState
|-
| 0x000B0000
| [[NIMU:GetSystemTitleHash|GetSystemTitleHash]]
|-
| 0x000C0082
| ?
|-
| 0x000E0080
| ?
|-
| 0x000F0042
| ?
|-
| 0x00110000
| ?
|-
| 0x00130000
| ?
|-
| 0x00140000
| ?
|-
| 0x00150000
| ?
|-
| 0x00170042
| ?
|-
| 0x00180080
| ?
|-
| 0x00250000
| ?
|-
| 0x00260200
| ?
|-
| 0x00270000
| ?
|-
| 0x00280000
| ?
|-
| 0x00290246
| ?
|-
| 0x002A0000
| ?
|-
| 0x002B0000
| ?
|-
| 0x002C0000
| ?
|-
| 0x002D00C0
| ?
|-
| 0x00480002
| ?
|}

= NIM server service "nim:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010200
| [[NIMS:StartDownloadSimple|StartDownloadSimple]]
|-
| 0x00020000
| [[NIMS:CancelDownload|CancelDownload]]
|-
| 0x00030000
| [[NIMS:GetProgress|GetProgress]]
|-
| 0x00050082
| [[NIMS:UnregisterTask|UnregisterTask]]
|-
| 0x00060080
| [[NIMS:IsTaskRegistered|IsTaskRegistered]]
|-
| 0x000A0000
| [[NIMS:CheckSysupdateAvailableSOAP|CheckSysupdateAvailableSOAP]]
|-
| 0x000B0084
| [[NIMS:SetAttribute|SetAttribute]]
|-
| 0x0016020A
| [[NIMS:ListTitles|ListTitles]]
|-
| 0x0022....
| AccountDeleteTitleETicketsSOAP. The SOAP request is sent only after the ticket for the specified titleID has been successfully deleted.
|-
| 0x00290000
| [[NIMS:AccountCheckBalanceSOAP|AccountCheckBalanceSOAP]]
|-
| 0x002D0042
| [[NIMS:DownloadTickets|DownloadTickets]]
|-
| 0x003C0002
| [[NIMS:RegisterSelf|RegisterSelf]]
|-
| 0x003F0000
| GetInitializeResult. Checks whether nim is properly initialized or not. If it is not, the result code returned is non-zero.
|-
| 0x00420240
| [[NIMS:StartDownload|StartDownload]]
|-
| 0x00550246
| [[NIMS:RegisterTask|RegisterTask]]
|-
| 0x00570082
| [[NIMS:ConnectNoTicketDownload|ConnectNoTicketDownload]]
|}

= NIM server service "nim:aoc" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00030042
| SetApplicationId
|-
| 0x00040042
| SetTin
|-
| 0x000902D0
| ListContentSetsEx
|-
| 0x00180000
| GetBalance
|-
| 0x001D0000
| GetCustomerSupportCode
|-
| 0x00210000
| Initialize
|-
| 0x00240282
| CalculateContentsRequiredSize
|-
| 0x00250000
| RefreshServerTime
|}

= NIM service "nim:ndm" =

= kagiya server =
The nim system module communicates with a server called kagiya (kagiya-ctr.cdn.nintendo.net or kagiya-dev-ctr.cdn.nintendo.net for development units). It provides the 9.6 crypto seed in binary form for any given title ID under (HTTPS) kagiya-ctr.cdn.nintendo.net/title/0x%16llx/ext_key?country=%s, where %16llx is the title ID and %s is a country code as used in the [[EShop|eShop]].

=New3DS=
NIM module only uses [[PTMSYSM:CheckNew3DS|CheckNew3DS]] for determining what heap sizes to use, in two functions. One is for the size of the 0x08000000 vmem heap, the other is probably for some buffer allocated on that heap. The New3DS version of these sizes are 0x1C000-bytes larger than the Old3DS sizes here.

=HTTPS requests=

==Trusted RootCAs==
During startup NIM-module creates two RootCertChains with [[HTTP_Services|HTTPC]]. Both of these only contain the same [[HTTPC:RootCertChainAddDefaultCert|default]] cert with ID 0x3. The first RootCertChain is used with NetUpdateSOAP. Requests such as the "notifications.json" page don't use these RootCertChains(in this case just [[HTTPC:AddDefaultCert|default]] certID 0xB is used).

==SOAP==

===NetUpdateSOAP===
There are exactly 3 types of network SOAP requests used with [https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP NetUpdateSOAP] by NIM module, described below. This URL contained in NIM module itself is only used with GetSystemTitleHash. The other requests use an identical URL loaded from an ECommerceSOAP response instead.

See also [https://github.com/yellows8/ninupdates here].

====GetSystemUpdate====
Returns the current sysupdate title-listing. This also contains the SystemTitleHash returned by GetSystemTitleHash.

====GetSystemTitleHash====
Returns the current SystemTitleHash for the current sysupdate title-listing.

====GetSystemCommonETicket====
Returns the Base64-encoded cetk for each specified TitleId entry.

This is only used when installing new titles. This means with CDN system-updates, tickets are never installed except when a title is being installed for the first time. For example, a system on the latest system-version that was only ever updated via CDN has the same NATIVE_FIRM ticket installed from the factory.

=Sysupdate checking process=
This section describes the process used when checking whether a sysupdate is required.

First the GetSystemTitleHash SOAP request is done. Then the SystemTitleHash in savedata hash.dat is compared with the received one. If they match and the SystemTitleHash flag is set to value 0x03, it will immediately return that no sysupdate is required. Otherwise it will start the GetSystemUpdate SOAP request handling.

The GetSystemUpdate SOAP request contains a titlelist of all NAND system-titles. For GetSystemUpdate response parsing, it compares each SOAP title_entry with the NAND system titlelist. If a SOAP titleID isn't found in the NAND titlelist, this means NAND is missing a new title and hence a sysupdate is required for installing that title. If a NAND title_entry-version is less than the SOAP title_entry-version, this means the title needs updated and hence a sysupdate is required.

At least one <TitleVersion> entry with valid data in the GetSystemUpdate response is required.

The titleIDs sent in the GetSystemUpdate SOAP request are decimal, while the titleIDs in the response are hex.

=NIM [[System_SaveData]]=
==hash.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x60
| 0x1
| u8 flag used with the SystemTitleHash. 0x01 = latest sysupdate isn't installed as of last SOAP requests, 0x03 = latest sysupdate is installed as of last SOAP requests.
|-
| 0x61
| 0x21
| ASCII hex SystemTitleHash, including NUL-terminator. This is the latest SystemTitleHash which NIM module received from SOAP.
|}

=Types=
==InstallationMode==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Initial installation
|-
| 1
| Unknown
|-
| 2
| Unknown
|-
| 3
| Reinstallation
|}
==DownloadState==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not initialized
|-
| 1
| Download initialized
|-
| 2
| Downloading, verifying and installing TMD
|-
| 3
| Initializing save data
|-
| 4
| Downloading and installing contents
|-
| 5
| Waiting before calling [[AM:CommitImportPrograms]]
|-
| 6
| Running [[AM:CommitImportPrograms]]
|-
| 7
| Title installation finished
|-
| 8
| Unknown error regarding title version
|-
| 9
| Creating the .ctx file (or error doing so)?
|-
| 10
| Irrecoverable error encountered
|}
==TitleConfig==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x4
| Title version
|-
| 0xC
| 0x4
| Unknown (always 0)
|-
| 0x10
| 0x1
| Age rating for the HOME Menu parental controls
|-
| 0x11
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Unknown (always 0?)
|}
==TitleProgress==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| [[#DownloadState|Download State]]
|-
| 0x4
| 0x4
| Last result code in NIM related to the installation
|-
| 0x8
| 0x8
| Amount of bytes that have been downloaded
|-
| 0x10
| 0x8
| Total bytes that need to be downloaded
|}

NIM Services

2017-01-27T17:44:54Z

AriA99: Update the page with structs.

[[Category:Services]]
= NIM user service "nim:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| Related to starting a sysupdate?
|-
| 0x00020000
| [[NIMU:GetUpdateDownloadProgress|GetUpdateDownloadProgress]]
|-
| 0x0003....
| ?
|-
| 0x00040000
| [[NIMU:FinishTitlesInstall|FinishTitlesInstall]]
|-
| 0x00050000
| This obtains an event handle. Home Menu will check whether a system update is available when this event is triggered.
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x00090000
| [[NIMU:CheckSysupdateAvailable|CheckSysupdateAvailable]]
|-
| 0x000A0000
| GetState
|-
| 0x000B0000
| [[NIMU:GetSystemTitleHash|GetSystemTitleHash]]
|-
| 0x000C0082
| ?
|-
| 0x000E0080
| ?
|-
| 0x000F0042
| ?
|-
| 0x00110000
| ?
|-
| 0x00130000
| ?
|-
| 0x00140000
| ?
|-
| 0x00150000
| ?
|-
| 0x00170042
| ?
|-
| 0x00180080
| ?
|-
| 0x00250000
| ?
|-
| 0x00260200
| ?
|-
| 0x00270000
| ?
|-
| 0x00280000
| ?
|-
| 0x00290246
| ?
|-
| 0x002A0000
| ?
|-
| 0x002B0000
| ?
|-
| 0x002C0000
| ?
|-
| 0x002D00C0
| ?
|-
| 0x00480002
| ?
|}

= NIM server service "nim:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00060080
| The input at cmdreq[1-2] is an u64 titleID. This writes an u8 to cmdreply[2]. It's unknown what exactly the [[eShop]] application uses this for, it only uses this command for apps which are installed(checked via [[Application_Manager_Services|AM]] probably). In those cases, it seems the outval for this command(with result-code=0) is normally 0?
|-
| 0x000A0000
| [[NIMS:CheckSysupdateAvailableSOAP|CheckSysupdateAvailableSOAP]]
|-
| 0x0016020A
| [[NIMS:ListTitles|ListTitles]]
|-
| 0x0022....
| AccountDeleteTitleETicketsSOAP. The SOAP request is sent only after the ticket for the specified titleID has been successfully deleted.
|-
| 0x00290000
| [[NIMS:AccountCheckBalanceSOAP|AccountCheckBalanceSOAP]]
|-
| 0x002D0042
| [[NIMS:DownloadTickets|DownloadTickets]]
|-
| 0x00420240
| [[NIMS:StartDownload|StartDownload]]
|}

= NIM server service "nim:aoc" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00030042
| SetApplicationId
|-
| 0x00040042
| SetTin
|-
| 0x000902D0
| ListContentSetsEx
|-
| 0x00180000
| GetBalance
|-
| 0x001D0000
| GetCustomerSupportCode
|-
| 0x00210000
| Initialize
|-
| 0x00240282
| CalculateContentsRequiredSize
|-
| 0x00250000
| RefreshServerTime
|}

= NIM service "nim:ndm" =

= kagiya server =
The nim system module communicates with a server called kagiya (kagiya-ctr.cdn.nintendo.net or kagiya-dev-ctr.cdn.nintendo.net for development units). It provides the 9.6 crypto seed in binary form for any given title ID under (HTTPS) kagiya-ctr.cdn.nintendo.net/title/0x%16llx/ext_key?country=%s, where %16llx is the title ID and %s is a country code as used in the [[EShop|eShop]].

=New3DS=
NIM module only uses [[PTMSYSM:CheckNew3DS|CheckNew3DS]] for determining what heap sizes to use, in two functions. One is for the size of the 0x08000000 vmem heap, the other is probably for some buffer allocated on that heap. The New3DS version of these sizes are 0x1C000-bytes larger than the Old3DS sizes here.

=HTTPS requests=

==Trusted RootCAs==
During startup NIM-module creates two RootCertChains with [[HTTP_Services|HTTPC]]. Both of these only contain the same [[HTTPC:RootCertChainAddDefaultCert|default]] cert with ID 0x3. The first RootCertChain is used with NetUpdateSOAP. Requests such as the "notifications.json" page don't use these RootCertChains(in this case just [[HTTPC:AddDefaultCert|default]] certID 0xB is used).

==SOAP==

===NetUpdateSOAP===
There are exactly 3 types of network SOAP requests used with [https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP NetUpdateSOAP] by NIM module, described below. This URL contained in NIM module itself is only used with GetSystemTitleHash. The other requests use an identical URL loaded from an ECommerceSOAP response instead.

See also [https://github.com/yellows8/ninupdates here].

====GetSystemUpdate====
Returns the current sysupdate title-listing. This also contains the SystemTitleHash returned by GetSystemTitleHash.

====GetSystemTitleHash====
Returns the current SystemTitleHash for the current sysupdate title-listing.

====GetSystemCommonETicket====
Returns the Base64-encoded cetk for each specified TitleId entry.

This is only used when installing new titles. This means with CDN system-updates, tickets are never installed except when a title is being installed for the first time. For example, a system on the latest system-version that was only ever updated via CDN has the same NATIVE_FIRM ticket installed from the factory.

=Sysupdate checking process=
This section describes the process used when checking whether a sysupdate is required.

First the GetSystemTitleHash SOAP request is done. Then the SystemTitleHash in savedata hash.dat is compared with the received one. If they match and the SystemTitleHash flag is set to value 0x03, it will immediately return that no sysupdate is required. Otherwise it will start the GetSystemUpdate SOAP request handling.

The GetSystemUpdate SOAP request contains a titlelist of all NAND system-titles. For GetSystemUpdate response parsing, it compares each SOAP title_entry with the NAND system titlelist. If a SOAP titleID isn't found in the NAND titlelist, this means NAND is missing a new title and hence a sysupdate is required for installing that title. If a NAND title_entry-version is less than the SOAP title_entry-version, this means the title needs updated and hence a sysupdate is required.

At least one <TitleVersion> entry with valid data in the GetSystemUpdate response is required.

The titleIDs sent in the GetSystemUpdate SOAP request are decimal, while the titleIDs in the response are hex.

=NIM [[System_SaveData]]=
==hash.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x60
| 0x1
| u8 flag used with the SystemTitleHash. 0x01 = latest sysupdate isn't installed as of last SOAP requests, 0x03 = latest sysupdate is installed as of last SOAP requests.
|-
| 0x61
| 0x21
| ASCII hex SystemTitleHash, including NUL-terminator. This is the latest SystemTitleHash which NIM module received from SOAP.
|}

=Types=
==InstallationMode==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Initial installation
|-
| 1
| Unknown
|-
| 2
| Unknown
|-
| 3
| Reinstallation
|}
==DownloadState==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not initialized
|-
| 1
| Download initialized
|-
| 2
| Downloading, verifying and installing TMD
|-
| 3
| Initializing save data
|-
| 4
| Downloading and installing contents
|-
| 5
| Waiting before calling [[AM:CommitImportPrograms]]
|-
| 6
| Running [[AM:CommitImportPrograms]]
|-
| 7
| Title installation finished
|-
| 8
| Unknown error regarding title version
|-
| 9
| Creating the .ctx file (or error doing so)?
|-
| 10
| Irrecoverable error encountered
|}
==TitleConfig==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x4
| Title version
|-
| 0xC
| 0x4
| Unknown (always 0)
|-
| 0x10
| 0x1
| Age rating for the HOME Menu parental controls
|-
| 0x11
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Unknown (always 0?)
|}
==TitleProgress==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| [[#DownloadState|Download State]]
|-
| 0x4
| 0x4
| Last result code in NIM related to the installation
|-
| 0x8
| 0x8
| Amount of bytes that have been downloaded
|-
| 0x10
| 0x8
| Total bytes that need to be downloaded
|}