Gamecards - Revision history

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

2024-06-01T11:11:43Z

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

← Older revision		Revision as of 15:11, 1 June 2024
Line 219:		Line 219:
	\|}		\|}

	The header command has some initial dummy bytes, and eventually responds with a 0x200 byte ~~header~~. Here's an example for Lego Starwars 3:		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 ................		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.		0000010: b3 cf fb c6 6a b1 cb 20 32 af ce 35 d4 1c 74 c9 ....j.. 2..5..t.

AriA99: Fix formatting because MediaWiki has terrible markup rules

2024-05-26T05:16:39Z

Fix formatting because MediaWiki has terrible markup rules

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

2024-05-26T05:15:06Z

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

Show changes

AriA99: Details on CRC-32

2024-05-26T04:13:24Z

Details on CRC-32

← Older revision		Revision as of 08:13, 26 May 2024
Line 118:		Line 118:

	After the sixth transfer, commands change size from 8 bytes to 16 bytes. Possibly a new encryption is used, such as AES CTR.		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) follows.		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:		Here's a set of sample gamecard commands that a 3DS sends to a 3DS gamecard:

ElementW: Card-detect info

2023-05-26T09:59:09Z

Card-detect info

@@ Line 85: / Line 85: @@
 |}
-VCC is only enabled when the power supply bits of [[CONFIG9_Registers#CFG9_CARDSTATUS|CFG9_CARDSTATUS]] are set to <tt>10</tt>. This is in contrast to the DS and DSi, where the power supply is always available when the console is on.
+{| class="wikitable" border="1"
 ===SPI flash===

ElementW: Make pin table slightly more legible

2023-05-07T11:13:18Z

Make pin table slightly more legible

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

Line 85:		Line 88:

	===SPI flash===		===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 a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at:<br>		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:<br>
	[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] <br>		[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] <br>
	[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)] <br>		[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)] <br>

ElementW: Fix Macronix MX25L1021E datasheet link rot

2023-05-07T08:43:43Z

Fix Macronix MX25L1021E datasheet link rot

← Older revision		Revision as of 12:43, 7 May 2023
Line 86:		Line 86:
	===SPI flash===		===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 a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at:<br>		Savegame SPI flash transfers use CPOL=1 and CPHA=1. So far, only one savegame FLASH chip has been identified. The chip identifies as a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at:<br>
	~~http~~://www.macronix.com/~~QuickPlace~~/hq/~~PageLibrary4825740B00298A3B.nsf~~/~~$defaultview/3F21BAC2E121E17848257639003A3146/$File~~/MX25L1021E~~%2C~~%203V~~%2C~~%201Mb~~%2C~~%20v1.1.~~pdf?OpenElement~~ <br>		[https://www.macronix.com/Lists/Datasheet/Attachments/8796/MX25L1021E,%203V,%201Mb,%20v1.3.pdf Macronix (Rev. 1.3, nov. 11, 2013)] <br>
	http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf ~~(old~~ version mirror) <br>		[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)] <br>
	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.		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.

ElementW: Specify cards only get 3.3V on VCC when CFG9_CARDSTATUS enables it

2023-05-02T20:20:23Z

Specify cards only get 3.3V on VCC when CFG9_CARDSTATUS enables it

← Older revision		Revision as of 00:20, 3 May 2023
Line 81:		Line 81:
	\| Ground		\| Ground
	\|}		\|}

			VCC is only enabled when the power supply bits of [[CONFIG9_Registers#CFG9_CARDSTATUS\|CFG9_CARDSTATUS]] are set to <tt>10</tt>. This is in contrast to the DS and DSi, where the power supply is always available when the console is on.

	===SPI flash===		===SPI flash===

Profi200: /* SPI flash */ Clock polarity and phase.

2021-02-13T00:13:30Z

SPI flash: Clock polarity and phase.

← Older revision		Revision as of 03:13, 13 February 2021
Line 83:		Line 83:

	===SPI flash===		===SPI flash===
	So far, only one savegame FLASH chip has been identified. The chip identifies as a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at:<br>		Savegame SPI flash transfers use CPOL=1 and CPHA=1. So far, only one savegame FLASH chip has been identified. The chip identifies as a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at:<br>
	http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/$defaultview/3F21BAC2E121E17848257639003A3146/$File/MX25L1021E%2C%203V%2C%201Mb%2C%20v1.1.pdf?OpenElement <br>		http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/$defaultview/3F21BAC2E121E17848257639003A3146/$File/MX25L1021E%2C%203V%2C%201Mb%2C%20v1.1.pdf?OpenElement <br>
	http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf (old version mirror) <br>		http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf (old version mirror) <br>

Neobrain: /* Protocol */

2015-12-04T11:54:07Z

Protocol

← Older revision		Revision as of 14:54, 4 December 2015
Line 93:		Line 93:

	===Protocol===		===Protocol===
	The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the DS and DSi gamecard communication 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.		After the sixth transfer, commands change size from 8 bytes to 16 bytes. Possibly a new encryption is used, such as AES CTR.

← Older revision		Revision as of 09:16, 26 May 2024
Line 255:		Line 255:
	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:		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]].		# 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.		# 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.		# 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.		# 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.		# 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.		# 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.		# 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.		All commands and responses are now encrypted using RC4. The gamecard controller and gamecard itself share the RC4 key and advance the state accordingly.
Line 267:		Line 267:
	If the 0x83 command is sent, the cryptography is re-keyed:		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.		# 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.		# 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.		# 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.		# 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 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.		The static values are fixed in the gamecard controller and gamecards themselves, they are not obtained from Process9 or anywhere in NATIVE_FIRM.