Download Play

The 3DS dlplay title has two dlplay modes: 3DS and DS. DS dlplay is just regular dsmode dlplay, same interface and protocol as before. Like DS gamecards, holding down start+select while starting the dsmode dlplay client will disable stretching the screens.

Download Play protocol

The Download Play protocol for 3DS is completely different from the DS Wireless Multiboot (WMB) protocol. While the DS WMB protocol used to send program code in plaintext over wireless, the Download Play protocol is now uses WPA2 CCMP(which uses 128-bit AES CTR) to broadcast the application. Download Play uses UDS, which is implemented by NWM module. CCMP is handled by NWM module. Local-WLAN communications are handled UDS, the actual dlplay-specific data is the data sent in the encrypted CCMP frames and the data sent in the encrypted tag data stored in the beacons.

The plaintext broad-casted beacons have static Nintendo tag data, broad-casted at a rate of 0.102400/s. These beacons contain a Nintendo vendor tag which contains encrypted data, see here regarding UDS beacons. Data frames encrypted with CCMP are broad-casted as well, the size of these varies. After a client authenticates to the host, the host sends an association response, with a random ASCII hex SSID, like: "EB6FAB77". After that the systems communicate and transfer the binary with CCMP encrypted data frames.

This is a dump of the Nintendo tag of the beacon from Monkey ball 3D, with vendor 001f32. The data contained in this vendor tag is encrypted:

000: 18 05 9f ae 17 c8 a5 1d 0b 81 28 be 74 0f d4 af
010: 97 30 04 60 fd 2d f3 d9 8d bc 22 80 51 60 3c 75
020: d9 89 6d 16 c4 f3 aa 89 26 d4 14 25 67 75 8e 4b
030: 3c 97 85 c9 83 15 d4 96 06 b1 29 b6 f5 51 57 71 
040: cc b6 1f 4a c8 bd 4f c0 57 43 cb ab fa 37 74 b0
050: 64 6b 87 69 a1 de a4 05 7c 7c 49 5d f5 21 25 83
060: 4c f2 d0 70 38 14 7b 0f f4 97 f7 ff f3 ff 36 cd
070: c2 e2 c0 78 98 d1 d5 4d 3d d4 9b 57 84 6c e2 4f
080: 25 f2 56 c4 19 88 64 13 78 68 e2

CCMP Key

The CCMP key is generated by the NWM module.

The CCMP key used for UDS communications with the booted Download Play executable is a separate key, generated by the NWM module where the input passphrase is a random hex string.

Broadcasted application data

The Download Play protocol broadcasts 3DS application data in the CIA format, which contains a certificate chain, a ticket, a TMD, and the actual application itself, in CXI format. The broadcasted archive data is temporarily stored as a file on the internal NAND Flash storage, and is kept there until new archive data from a different game is received through the Download Play protocol.

The CXI application content is again encrypted, this time using 128-bit AES CBC. The encryption uses the decrypted titlekey of the ticket, and the titleid padded with zeros as the IV. To get the decrypted titlekey, the titlekey stored in the ticket must be decrypted using 128-bit AES-CBC with the 3DS common key, and the same IV as mentioned previously.

So in actuality, the 3DS application code, as it is being transmitted wirelessly has been encrypted 3 times:

• The first time is using 128-bit AES CTR encryption for the ExeFS of the CXI format,
• the second time is using 128-bit AES CBC encryption in the archive data,
• and the third time is using 128-bit AES CTR for the CCMP encryption.

Remote Distribution of System-Updates

As part of the child distribution process, a 3DS acting as the server in a local Download Play session, can send firmware updates to another 3DS unit acting as the client, through first sending the system update package then instructing the client to install reboot and reinstantiate a connection (which it caches information about temporarily) remotely, if it finds system updates are necessary before distributing the child-application. ( eg. multiplayer game or a demo. ) Like "update" partitions on CTR Cards, this is not an "automatic feature" and not implemented for all Download Play titles.