Difference between revisions of "Download Play"

From 3dbrew
Jump to navigation Jump to search
Line 2: Line 2:
  
 
== Download Play protocol ==
 
== 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 3DS Download Play protocol uses [[NWM_Services|UDS]] which uses CCMP encryption etc. See also [[DLP_Services|here]].
  
−
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_Services|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.
+
=== Download Play UDS protocol ===
 +
This section describes the data transferred using the [[NWM_Services|UDS]] service. All data is stored as big-endian.
  
−
The plaintext broad-casted beacons have static Nintendo tag data, broad-casted at a rate of 0.102400/s. These beacons contains Nintendo vendor tags, the third tag contains encrypted data. See [[NWM_Services|here]] regarding UDS beacons. Data frames encrypted with CCMP are broad-casted as well.
+
UDS [[NWMUDS:Bind|data_channel]] 0x1 is used for spectator data, while all non-spectator data uses data_channel 0x2. The spectator data is received by connecting to the network as a spectator then receiving data-frames, this is handled when scanning for DLP networks. This spectator-data contains the DLP icon and the sysupdate titlelist.
−
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 [[CIA]] with CCMP encrypted data frames.
 
  
−
Before beginning data transfer, the host broad-casts data-frames encrypted with CCMP. These data-frame broadcasts contain Download Play metadata for the application, including icon data, nickname of host + nicknames of clients, total clients, metadata for the system update, etc.
+
This is the data starting at offset 0x0 for UDS PullPacket/SendTo:
−
 
+
{| class="wikitable" border="1"
−
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
+
!  Offset
−
010: 97 30 04 60 fd 2d f3 d9 8d bc 22 80 51 60 3c 75
+
!  Size
−
020: d9 89 6d 16 c4 f3 aa 89 26 d4 14 25 67 75 8e 4b
+
!  Description
−
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
+
| 0x0
−
050: 64 6b 87 69 a1 de a4 05 7c 7c 49 5d f5 21 25 83
+
| 0x1
−
060: 4c f2 d0 70 38 14 7b 0f f4 97 f7 ff f3 ff 36 cd
+
| Must be 0x1 for spectator data.
−
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
+
| 0x3
−
 
+
| 0x3
−
== CCMP Key ==
+
| ?
−
The CCMP key is generated by the [[NWM_Services|NWM]] module.
+
|-
−
 
+
| 0x4
−
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.
+
| 0x2
 +
| Size of the entire frame.
 +
|-
 +
| 0x6
 +
| 0x2
 +
| ?
 +
|-
 +
| 0x8
 +
| 0x4
 +
| Checksum
 +
|-
 +
| 0xC
 +
| 0x1
 +
| Spectator data: frameid, must be less than total_frames. Normal data: unknown.
 +
|-
 +
| 0xD
 +
| 0x1
 +
| Spectator data: total_frames. Normal data: unknown.
 +
|-
 +
| 0xE
 +
| 0x1
 +
| Unknown. This must match a state value. When this frame value is non-zero, 0x1 is used for the frame value when doing the compare instead.
 +
|-
 +
| 0xF
 +
| 0x1
 +
| ?
 +
|-
 +
| 0x10
 +
|
 +
| The frame-specific payload starts here.
 +
|}
  
 
== Broadcasted application data ==
 
== 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|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 Download Play protocol broadcasts 3DS application data in the [[CIA]] format. The title is installed to NAND, and is kept there until new CIA 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 ==
 
== 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 system 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. This system update data is from the application's system update [[NCCH#CFA|CFA]], prior to beginning the data transfer the host broadcasts data-frames which contain the [[CVer|cup_list]] from this system update CFA.
+
As part of the child distribution process, a 3DS acting as the server in a local Download Play session, can send system 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. This system update data is from the application's system update [[NCCH#CFA|CFA]], prior to beginning the data transfer the host broadcasts data-frames which contain a title-list from the system update CFA.

Revision as of 17:08, 9 April 2016

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 3DS Download Play protocol uses UDS which uses CCMP encryption etc. See also here.

Download Play UDS protocol

This section describes the data transferred using the UDS service. All data is stored as big-endian.

UDS data_channel 0x1 is used for spectator data, while all non-spectator data uses data_channel 0x2. The spectator data is received by connecting to the network as a spectator then receiving data-frames, this is handled when scanning for DLP networks. This spectator-data contains the DLP icon and the sysupdate titlelist.

This is the data starting at offset 0x0 for UDS PullPacket/SendTo:

Offset Size Description
0x0 0x1 Must be 0x1 for spectator data.
0x3 0x3 ?
0x4 0x2 Size of the entire frame.
0x6 0x2 ?
0x8 0x4 Checksum
0xC 0x1 Spectator data: frameid, must be less than total_frames. Normal data: unknown.
0xD 0x1 Spectator data: total_frames. Normal data: unknown.
0xE 0x1 Unknown. This must match a state value. When this frame value is non-zero, 0x1 is used for the frame value when doing the compare instead.
0xF 0x1 ?
0x10 The frame-specific payload starts here.

Broadcasted application data

The Download Play protocol broadcasts 3DS application data in the CIA format. The title is installed to NAND, and is kept there until new CIA data from a different game is received through the Download Play protocol.

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 system 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. This system update data is from the application's system update CFA, prior to beginning the data transfer the host broadcasts data-frames which contain a title-list from the system update CFA.

Retrieved from "https://www.3dbrew.org/w/index.php?title=Download_Play&oldid=16623"