Download Play - Revision history

Yellows8: /* Metadata frame */

2016-04-12T03:33:36Z

Metadata frame

← Older revision		Revision as of 07:33, 12 April 2016
Line 112:		Line 112:
	\| 0x8		\| 0x8
	\| 0x2		\| 0x2
	\| u16, ~~unknown~~.		\| u16, probably the DLP-child title-version.
	\|-		\|-
	\| 0xA		\| 0xA

Yellows8: /* Metadata frame */

2016-04-12T03:31:57Z

Metadata frame

← Older revision		Revision as of 07:31, 12 April 2016
Line 107:		Line 107:
	\|-		\|-
	\| 0x0		\| 0x0
	\| ~~0x4~~		\| 0x8
	\| ~~u32~~, ~~unknown~~.		\| u64 DLP-child titleID. Must be a CTR TID-high, with the TID-high set for DLP-child. The low 4-bits of the TID-low must be clear.
	\|-
	~~\| 0x4~~
	~~\| 0x4~~
	~~\| u32, unknown~~.
	\|-		\|-
	\| 0x8		\| 0x8

Yellows8: /* Metadata frame */

2016-04-10T22:41:02Z

Metadata frame

← Older revision		Revision as of 02:41, 11 April 2016
Line 128:		Line 128:
	\| 0xC		\| 0xC
	\| 0x4		\| 0x4
	\| u32, chunk_size. This is the chunk_size used for transferring the CIA. This is the exact size used for the FS .cia file-reads on the host, and the exact size used for [[Application_Manager_Services\|AM]] CIA file-writes on the client(s). Normally this is 0x0003FFC0.		\| u32, chunk_size. This is the chunk_size used for transferring the CIA. This is the exact size used for the FS .cia file-reads on the host, and the exact size used for [[Application_Manager_Services\|AM]] CIA file-writes on the client(s). Normally this is 0x0003FFC0. This appears to be validated by the client at some point, using a large value for this triggers an "connection interrupted" error when trying to connect.
	\|-		\|-
	\| 0x10		\| 0x10

Yellows8: /* Metadata frame */

2016-04-10T22:25:44Z

Metadata frame

← Older revision		Revision as of 02:25, 11 April 2016
Line 128:		Line 128:
	\| 0xC		\| 0xC
	\| 0x4		\| 0x4
	\| u32, ~~unknown~~.		\| u32, chunk_size. This is the chunk_size used for transferring the CIA. This is the exact size used for the FS .cia file-reads on the host, and the exact size used for [[Application_Manager_Services\|AM]] CIA file-writes on the client(s). Normally this is 0x0003FFC0.
	\|-		\|-
	\| 0x10		\| 0x10

Yellows8: /* Checksum */

2016-04-10T15:42:46Z

Checksum

← Older revision		Revision as of 19:42, 10 April 2016
Line 66:		Line 66:

	The checksum stored in the above data frame header is then calculated using this checksum seed.		The checksum stored in the above data frame header is then calculated using this checksum seed.

			First, the calc_checksum is initialized to 0. Then calc_checksum is added with ''all'' words in the data frame loaded as big-endian, with the data-frame checksum cleared to zero here. If the frame_size isn't word-aligned, the remaining <4-bytes are loaded as big-endian for adding as well.

			Then this is run:
			//During init before the above adding, shift and count are initialized:
			//shift = (((u8*)&checksum_seed)[2] & 0xf) + 0x4;
			//count = (((u8*)&checksum_seed)[3] & 0x7) + 0x2;
			for(pos=0; pos<count; pos++)checksum = (checksum<<shift \| checksum>>shift) ^ checksum_seed;//The u32 checksum_seed is byte-swapped on 3DS for this.

			Lastly the calculated checksum is written to output as big-endian(hence on 3DS it's byte-swapped before writing to output).

	==== Frames ====		==== Frames ====

Yellows8: /* Download Play UDS protocol */

2016-04-10T14:57:05Z

Download Play UDS protocol

← Older revision		Revision as of 18:57, 10 April 2016
Line 59:		Line 59:
	\|}		\|}

	Total_frames is at least 0x4 normally. When a sysupdate is included, total_frames is 0x4+<total frames required for the titlelist(normally 0x1)>.		Total_frames is at least 0x4 normally. When a sysupdate is included, total_frames is 0x4+<total frames required for the titlelist(normally 0x1)>. Total_frames should be <=0x20, but the code doesn't check for this specific value.

	Frames:		==== Checksum ====
			The checksum seed is the 4-byte output from [[PS:EncryptDecryptAes\|encrypting]] zeros with AES-CTR using [[PSPXI:EncryptDecryptAes\|keytype5]]. The CTR is the output from this: "for(i=0; i<0x10; i++)ctr[i] = ctrseed[i] ^ host_macaddress[i % 6];" This ctrseed is a fixed 0x10-byte random-data block stored in DLP-sysmodule .rodata.
			This seed is initialized after connecting to/creating the DLP network.

			The checksum stored in the above data frame header is then calculated using this checksum seed.

			==== Frames ====
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 83:		Line 89:
	The structure of each spectator frame relative to "frame-specific payload" is described below.		The structure of each spectator frame relative to "frame-specific payload" is described below.

	==== Metadata frame ====		===== Metadata frame =====
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 185:		Line 191:
	If the u16 at frameheader+0x6 is less than 0x101, the 8-bytes at outptr are cleared to all-zero, instead of copying the data from offset 0x2E8.		If the u16 at frameheader+0x6 is less than 0x101, the 8-bytes at outptr are cleared to all-zero, instead of copying the data from offset 0x2E8.

	==== Icon gfx frame ====		===== Icon gfx frame =====
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 197:		Line 203:
	\|}		\|}

	==== Sysupdate titlelist frame ====		===== Sysupdate titlelist frame =====
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-

Yellows8: /* Download Play UDS protocol */

2016-04-09T19:42:06Z

Download Play UDS protocol

← Older revision		Revision as of 23:42, 9 April 2016
Line 8:		Line 8:

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

			The spectator data includes the 48x48 icon, this has the same format as [[SMDH]].

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

Yellows8: /* Download Play UDS protocol */

2016-04-09T18:58:44Z

Download Play UDS protocol

← Older revision		Revision as of 22:58, 9 April 2016
Line 30:		Line 30:
	\| 0x6		\| 0x6
	\| 0x2		\| 0x2
	\| ?		\| u16, unknown. For spectator data this is only used for the metadata frame.
	\|-		\|-
	\| 0x8		\| 0x8
Line 68:		Line 68:
	\| 0x0		\| 0x0
	\| 0x300		\| 0x300
	\| ~~Various metadata, two UTF-16 strings displayed by the DLP-client, and the~~ start of the icon gfx.		\| Metadata + start of the icon gfx, see below.
	\|-		\|-
	\| 0x1-0x3		\| 0x1-0x3

Yellows8: /* Metadata frame */

2016-04-09T18:54:52Z

Metadata frame

← Older revision		Revision as of 22:54, 9 April 2016
Line 180:		Line 180:
	\| u8, unknown. Written to outptr+5.		\| u8, unknown. Written to outptr+5.
	\|}		\|}

			If the u16 at frameheader+0x6 is less than 0x101, the 8-bytes at outptr are cleared to all-zero, instead of copying the data from offset 0x2E8.

	==== Icon gfx frame ====		==== Icon gfx frame ====

Yellows8: /* Metadata frame */

2016-04-09T18:46:51Z

Metadata frame

@@ Line 89: / Line 89: @@
 |-
 | 0x0
-| 0x18
+| 0x4
+| u32, unknown.
 |-
 | 0x18
@@ Line 116: / Line 148: @@
 | Array of 0x9C u16s for the start of the icon gfx.
 |-
-| 0x2F8
+| 0x2E8
-| 0x8
+| 0x1
-| ?
+| u8, unknown. Written to outptr+2.
 |}