Difference between revisions of "单卡联机"
(translate 20%) |
|||
Line 20: | Line 20: | ||
080: 25 f2 56 c4 19 88 64 13 78 68 e2 | 080: 25 f2 56 c4 19 88 64 13 78 68 e2 | ||
− | == WPA2 | + | == WPA2 加密 == |
− | + | Download Play 协议和所以的本地无线通讯使用相同的WPA2加密机制。输入数据使用 [[Process_Services|EncryptDecryptAes]] 和 [[PSPXI:EncryptDecryptAes|keytype1]] 是一个 0x10-byte 哈希值. Download Play输入的口令是固定的,区别在于每一个本地无线协议。 CTR是一个0x10-byte 经过哈希的16-byte结构,包含了主机MAC地址, 正常应用的titleID中的uniqueID。(然而用于Download Play的uniqueID是固定的)。输出的十六进制加密数据是最终WPA2密码。这个有可能是MD5的0x10-byte哈希值是未知的。 | |
− | + | 引导Download Play可执行文件的wpa2通讯使用上述方法生成的随机十六进制字符串作为密码。 | |
− | |||
== Broadcasted application data == | == Broadcasted application data == |
Revision as of 14:26, 26 March 2013
3DS dlplay有两个dlplay模式:3DS和DS。DS dlplay是只是普通的dsmode dlplay,使用了和从前同的接口和协议。 与DS游戏卡相同,进入dsmode dlplay应用时按住start +select,3DS会禁用拉伸屏幕。
Download Play 协议
3DS的Download Play 协议与 DS Wireless Multiboot (WMB) 协议完全不同。DS WMB协议用于无线以纯文本形式发送程序代码,而3DS的 download play协议使用WPA2加密的128位AES CTR广播应用程序。
广播的信标(beacons)有 以0.102400 / s的速度广播的静态的任天堂标签数据 和 WPA2广播的数据帧,他们的大小不尽相同。 客户端向主机请求身份验证,主机发送连接响应,响应包含了一个随机的ASCII十六进制SSID (如“EB6FAB77”)。 之后使用WPA2加密的数据帧进行系统的通讯和传输的二进制文件。
这是从猴子球3D(vendor 001f32)导出的一个任天堂标签。数据中包含的vendor tag数据是加密的:
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
WPA2 加密
Download Play 协议和所以的本地无线通讯使用相同的WPA2加密机制。输入数据使用 EncryptDecryptAes 和 keytype1 是一个 0x10-byte 哈希值. Download Play输入的口令是固定的,区别在于每一个本地无线协议。 CTR是一个0x10-byte 经过哈希的16-byte结构,包含了主机MAC地址, 正常应用的titleID中的uniqueID。(然而用于Download Play的uniqueID是固定的)。输出的十六进制加密数据是最终WPA2密码。这个有可能是MD5的0x10-byte哈希值是未知的。 引导Download Play可执行文件的wpa2通讯使用上述方法生成的随机十六进制字符串作为密码。
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 WPA2 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.