Changes

5,755 bytes added ,  08:40, 23 July 2023
m
Line 10: Line 10:  
!  Description
 
!  Description
 
|-
 
|-
| 0x00010442
+
| 0x000102C2
 
|  
 
|  
 
| Initialize Deprecated. Appears to be handled about the same way as [[NWMUDS:InitializeWithVersion]], except this uses version=0x100 internally instead of loading it from the command request.
 
| Initialize Deprecated. Appears to be handled about the same way as [[NWMUDS:InitializeWithVersion]], except this uses version=0x100 internally instead of loading it from the command request.
Line 20: Line 20:  
| 0x00030000
 
| 0x00030000
 
|  
 
|  
| [[NWMUDS:Shutdown|Shutdown]]
+
| [[NWMUDS:Finalize|Finalize]]
 
|-
 
|-
 
| 0x00040402
 
| 0x00040402
Line 64: Line 64:  
| 0x000E0006
 
| 0x000E0006
 
|  
 
|  
| ''Identical'' to [[NWMUDS:DecryptBeaconData|DecryptBeaconData]]. Deprecated, only used by old titles.
+
| ''Identical'' to [[NWMUDS:GetNodeInformationList|GetNodeInformationList]]. Deprecated, only used by old titles.
 
|-
 
|-
 
| 0x000F0404
 
| 0x000F0404
 
|  
 
|  
| [[NWMUDS:RecvBeaconBroadcastData|RecvBeaconBroadcastData]]
+
| [[NWMUDS:StartScan|StartScan]]
 
|-
 
|-
 
| 0x00100042
 
| 0x00100042
Line 124: Line 124:  
| 0x001D0044
 
| 0x001D0044
 
| Unknown, >[[2.0.0-2]]
 
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:BeginHostingNetwork|BeginHostingNetwork]] This is a replacement for the original network-creation command.
+
| [[NWMUDS:CreateNetwork2|CreateNetwork2]] This is a replacement for the original network-creation command.
 
|-
 
|-
 
| 0x001E0084
 
| 0x001E0084
 
| Unknown, >[[2.0.0-2]]
 
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:ConnectToNetwork|ConnectToNetwork]] This is a replacement for the original network-connection command.
+
| [[NWMUDS:ConnectNetwork2|ConnectNetwork2]] This is a replacement for the original network-connection command.
 
|-
 
|-
 
| 0x001F0006
 
| 0x001F0006
 
| Unknown, >[[2.0.0-2]]
 
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:DecryptBeaconData|DecryptBeaconData]]
+
| [[NWMUDS:GetNodeInformationList|GetNodeInformationList]]
 
|-
 
|-
 
| 0x00200040
 
| 0x00200040
Line 158: Line 158:  
!  Command Header
 
!  Command Header
 
!  Description
 
!  Description
 +
|-
 +
| 0x00010000
 +
| ?
 +
|-
 +
| 0x00020000
 +
| ?
 +
|-
 +
| 0x00030000
 +
| ?
 +
|-
 +
| 0x00040000
 +
| ?
 +
|-
 +
| 0x00050000
 +
| ?
 
|-
 
|-
 
| 0x000603C4
 
| 0x000603C4
Line 165: Line 180:  
| [[NWMINF:ConnectToEncryptedAP|ConnectToEncryptedAP]]
 
| [[NWMINF:ConnectToEncryptedAP|ConnectToEncryptedAP]]
 
|-
 
|-
| 0x0008....
+
| 0x00080302
 
| [[NWMINF:ConnectToAP|ConnectToAP]]
 
| [[NWMINF:ConnectToAP|ConnectToAP]]
 +
|-
 +
| 0x00090000
 +
| ?
 +
|-
 +
| 0x000A0000
 +
| ?
 +
|-
 +
| 0x000B0000
 +
| ?, return event handle in cmdbuf[3]
 +
|-
 +
| 0x000C0040
 +
| ?
 +
|-
 +
| 0x000D0000
 +
| ?
 +
|-
 +
| 0x000E0002
 +
| ?
 +
|-
 +
| 0x000F0082
 +
| ?
 +
|-
 +
| 0x00100040
 +
| ?
 
|}
 
|}
    
=NWM socket service "nwm::SOC"=
 
=NWM socket service "nwm::SOC"=
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Command Header
 +
!  Description
 +
|-
 +
| 0x00010042
 +
| (u32 size, <static_buffer translate-hdr with static_buf_id=0>, addr) ?
 +
|-
 +
| 0x00020080
 +
| (u32 unk, u32 size) Unknown. Uses size=0x5F8 internally unless the input is <=0x5F8. Uses an ipc static_buffer(static_buf_id=0) for output with the specified size(also used when writing the translate-hdr). Writes an output u32 to cmdreply[2].
 +
|-
 +
| 0x00030042
 +
| (u32 unk, u32 size, <static_buffer translate-hdr with static_buf_id=0>, addr) ?
 +
|-
 +
| 0x00040042
 +
| (u32 size, u32 unk, <static_buffer translate-hdr with static_buf_id=1>, addr) ?
 +
|-
 +
| 0x00050040
 +
| (u32 unk) ?
 +
|-
 +
| 0x00060080
 +
| (u32 unk0, u16 unk1) ?
 +
|-
 +
| 0x00070040
 +
| (u16 unk) This writes an output u32 to cmdreply[2].
 +
|-
 +
| 0x00080040
 +
| [[NWMSOC:GetMACAddress|GetMACAddress]]
 +
|-
 +
| 0x00090000
 +
| This just copies data from state to the cmdreply, this always returns 0. u32 cmdreply[2] = sharedmem_size, cmdreply[4] = [[NWM_Shared_Memory|sharedmem_handle]], cmdreply[5] = eventhandle.
 +
|-
 +
| 0x000A0040
 +
| (u32 unk) ?
 +
|-
 +
| 0x000B0040
 +
| (u32 unk) This writes an output u32 to cmdreply[2].
 +
|-
 +
| 0x000C0040
 +
| (u32 unk) ?
 +
|-
 +
| 0x000D0002
 +
| ([[IPC|kernel_processid_translatehdr]], u32 processid) ?
 +
|}
 +
 +
The only sysmodule which uses this is [[Socket_Services|socket]]-sysmodule. The first command used by socket-module is cmd9.
    
=NWM service "nwm::SAP"=
 
=NWM service "nwm::SAP"=
Line 193: Line 278:  
!  Description
 
!  Description
 
|-
 
|-
| 0x0001....
+
| 0x00010000
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
 
|-
 
|-
| 0x0002....
+
| 0x00020000
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
 
|-
 
|-
| 0x0003....
+
| 0x00030000
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
 
|-
 
|-
| 0x0004....
+
| 0x00040040
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
 
|-
 
|-
| 0x0005....
+
| 0x00050002
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
 
|-
 
|-
| 0x0006....
+
| 0x00060000
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
Line 225: Line 310:  
| [[NWMEXT:ControlWirelessEnabled|ControlWirelessEnabled]]
 
| [[NWMEXT:ControlWirelessEnabled|ControlWirelessEnabled]]
 
|-
 
|-
| 0x0009....
+
| 0x00090000
 
| <=[[2.0.0-2]]
 
| <=[[2.0.0-2]]
 
| ?
 
| ?
Line 293: Line 378:  
| 0x14
 
| 0x14
 
| 0x4
 
| 0x4
| ?
+
| Size of this entire entry, games use this value to traverse the beacons list.
 
|-
 
|-
 
| 0x18
 
| 0x18
Line 357: Line 442:     
The UDS version of [[PRUDP]] is different from the normal UDP version it appears(no afa1/a1af data for example).
 
The UDS version of [[PRUDP]] is different from the normal UDP version it appears(no afa1/a1af data for example).
 +
 +
==Communication protocol==
 +
The process of connecting to a host and exchanging data follows the sequence:
 +
 +
Client->Server: Authentication frame SEQ1
 +
 +
Server->Client: Authentication frame SEQ2
 +
 +
[There does not appear to be an association request frame sent by the client to the server, it is however possible that it was sent and just not captured by the test equipment]
 +
 +
Server->Client: Association Response frame with association id
 +
 +
[From here on, the client is connected to the server]
 +
 +
Client->Server: Encrypted data packet containing an 8-byte 802.2 LLC header with ethertype = EAPoL (0x888E) and an u16 header of 0x201 ([[NWM_Services#EAPoL-Start frame|EAPoL-Start]])
 +
 +
Server->Broadcast: Encrypted data packet containing the updated node information after the client connected (Using ethertype = SecureData).
 +
 +
Server->Client: Encrypted data packet containing an 8-byte 802.2 LLC header with ethertype = EAPoL (0x888E) and an u16 header of 0x0202([[NWM_Services#EAPoL-Logoff frame|EAPoL-Logoff]])
 +
 +
[From here on, data packets sent using SendTo are encapsulated with an LLC header with ethertype = 0x876D ([[NWM_Services#SecureData NWM header|SecureData]])]
 +
 +
[The client also sends periodic SecureData data frames on its own, these are probably ping frames]
    
==Data frames==
 
==Data frames==
Data is transferred over the network using [[NWMUDS:PullPacket]]/[[NWMUDS:SendTo]]. That data is transferred using 802.11 data frames using CCMP encryption. The encrypted data contained in the frame starts with the 0x10-byte LLC header, then the 0xE-byte NWM header, followed by the actual application data from the previously mentioned commands. When [[NWMUDS:SendTo]] was used with dst_NodeID = broadcast, the data frame is sent to the 802.11 broadcast MAC address. Otherwise with a specific NodeID, the data frame is sent to the actual MAC address for that device.
+
Data is transferred over the network using [[NWMUDS:PullPacket]]/[[NWMUDS:SendTo]]. That data is transferred using 802.11 data frames using CCMP encryption. The encrypted data contained in the frame starts with the 0x8-byte [https://en.wikipedia.org/wiki/Subnetwork_Access_Protocol#Use LLC header], then the 0xE-byte NWM header, followed by the actual application data from the previously mentioned commands. When [[NWMUDS:SendTo]] was used with dst_NodeID = broadcast, the data frame is sent to the 802.11 broadcast MAC address. Otherwise with a specific NodeID, the data frame is sent to the actual MAC address for that device.
    
Official application data is normally stored here as big-endian.
 
Official application data is normally stored here as big-endian.
 +
 +
Application data packets are sent to the host using 802.11 unicast, which then acts as a router and forwards the packet to the right destination node id based on the SecureData header using either broadcast or unicast, it is not yet known how it chooses which to use.
 +
 +
==Special data channels==
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Channel
 +
!  Description
 +
|-
 +
| 0x101
 +
| Used when broadcasting the updated node information after a new client connects.
 +
|-
 +
| 0x103
 +
| Used when sending what appears to be "ping" or "null" frames.
 +
|-
 +
| 0x104
 +
| Used to signal the ejection of all spectators in the network.
 +
|}
 +
 +
==SecureData NWM header==
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Offset
 +
!  Size
 +
!  Description
 +
|-
 +
| 0x0
 +
| 0x2
 +
| Size of the entire frame minus the 8 bytes from the LLC header.
 +
|-
 +
| 0x2
 +
| 0x2
 +
| unknown
 +
|-
 +
| 0x4
 +
| 0x2
 +
| Size of the entire frame minus 12 bytes.
 +
|-
 +
| 0x6
 +
| 0x2
 +
| Data channel. Applications can only use the low 8 bits, channels greater than 255 are reserved for management functions.
 +
|-
 +
| 0x8
 +
| 0x2
 +
| Sequence number, incremented after each sent packet.
 +
|-
 +
| 0xA
 +
| 0x2
 +
| Destination network node id
 +
|-
 +
| 0xC
 +
| 0x2
 +
| Source network node id
 +
|}
 +
 +
This data is stored as big-endian.
 +
 +
==EAPoL-Start frame==
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Offset
 +
!  Size
 +
!  Description
 +
|-
 +
| 0x0
 +
| 0x2
 +
| Always 0x201 in big-endian.
 +
|-
 +
| 0x2
 +
| 0x2
 +
| Association id of the sending client in big-endian.
 +
|-
 +
| 0x4
 +
| 0x2
 +
| Unknown. Always 0x1 in big-endian. The parser for this packet errors out if this is > 3.
 +
|-
 +
| 0x6
 +
| 0x2
 +
| Unknown
 +
|-
 +
| 0x8
 +
| 0x28
 +
| NodeInfo structure with all fields in big-endian
 +
|}
 +
 +
This data is stored as big-endian.
 +
 +
==EAPoL-Logoff frame==
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Offset
 +
!  Size
 +
!  Description
 +
|-
 +
| 0x0
 +
| 0x2
 +
| Always 0x202 in big-endian.
 +
|-
 +
| 0x2
 +
| 0x2
 +
| Unknown. Always 0?
 +
|-
 +
| 0x4
 +
| 0x2
 +
| Assigned network node id.
 +
|-
 +
| 0x6
 +
| 0x6
 +
| Mac address of the newly connected client.
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Unknown
 +
|-
 +
| 0x10
 +
| 0x2
 +
| Unknown. Always 0.
 +
|-
 +
| 0x12
 +
| 0x1
 +
| Number of connected nodes, including the new client.
 +
|-
 +
| 0x13
 +
| 0x1
 +
| Max number of nodes.
 +
|-
 +
| 0x14
 +
| 0x2
 +
| Always 0.
 +
|-
 +
| 0x16
 +
| 0x2
 +
| Unknown.
 +
|-
 +
| 0x18
 +
| 0x280
 +
| List of 16 NodeInfo structures with all fields in big-endian
 +
|}
 +
 +
This data is stored as big-endian.
    
==Structure used for generating the CTR for CCMP key generation==
 
==Structure used for generating the CTR for CCMP key generation==
Line 372: Line 620:  
| 0x0
 
| 0x0
 
| 0x4
 
| 0x4
| Local-WLAN communication ID, normally this is: (user_process [[Title_list|uniqueID]] << 8) | val. Where val is 0x10 on retail([[Configuration_Memory|configmem]] UNITINFO bit0 set), 0x90 for devunit. For [[Download Play]], this is always 0x2810 on retail(0x2890 on devunit).
+
| wlancommID
 
|-
 
|-
 
| 0x4
 
| 0x4
 
| 0x4
 
| 0x4
| u32 networkID, randomly-generated when creating the network. The network SSID used when a client connects to the network is sprintf(out, "%08X", networkID).
+
| networkID
 
|-
 
|-
 
| 0x8
 
| 0x8
Line 384: Line 632:  
| 0xE
 
| 0xE
 
| 0x2
 
| 0x2
| ID, for [[Download Play]] this is 0x55.
+
| id8
 
|}
 
|}
   Line 406: Line 654:  
| 0xA
 
| 0xA
 
| 0x1
 
| 0x1
| This ID is also stored at offset 0xE in the CTR-generation structure.
+
| id8
 
|-
 
|-
 
| 0xB
 
| 0xB
Line 414: Line 662:  
| 0xC
 
| 0xC
 
| 0x4
 
| 0x4
| This is the u32 from offset 0x18 in the network-struct.
+
| networkID
 
|}
 
|}
   Line 452: Line 700:  
| 0x10
 
| 0x10
 
| 0x4
 
| 0x4
| wlancommID
+
| wlancommID. Local-WLAN communication ID, normally this is: (user_process [[Title_list|uniqueID]] << 8) | val. Where val is 0x10 on retail([[Configuration_Memory#ENVINFO|ENVINFO]] bit0 set), 0x90 for devunit. Official software includes an input bool flag parameter for setting bit0 in this wlancommID, normally that flag isn't set. For [[Download Play]], this is always 0x2810 on retail(0x2890 on devunit).
 +
 
 +
This wlancommID can have the side affect of region-locking when the title uses the uniqueID for the current title(hard-coded in .text normally), instead of using a fixed input uniqueID for each region of the title.
 
|-
 
|-
 
| 0x14
 
| 0x14
 
| 0x1
 
| 0x1
| This ID is also stored at offset 0xE in the CTR-generation structure.
+
| id8. ID, for [[Download Play]] this is 0x55. 0x55/'U' seems to be used for networks where Wii U can host it(Download Play, Smash Bros, ...) - this value isn't known to be actually checked anywhere however.
 
|-
 
|-
 
| 0x15
 
| 0x15
 
| 0x1
 
| 0x1
| Some sort of counter for how many times this network was connected to?
+
| Number of times the network structure hash was updated.
 
|-
 
|-
 
| 0x16
 
| 0x16
Line 472: Line 722:  
| 0x18
 
| 0x18
 
| 0x4
 
| 0x4
| u32 networkID, see above.
+
| u32 networkID, randomly-generated when creating the network. The network SSID used when a client connects to the network is sprintf(out, "%08X", networkID).
 
|-
 
|-
 
| 0x1C
 
| 0x1C
Line 483: Line 733:  
|-
 
|-
 
| 0x1E
 
| 0x1E
| 0x1
+
| 0xD
 
| ?
 
| ?
 
|-
 
|-
| 0x1F
+
| 0x2B
| 0x1
+
| 0x14
| ?
+
| SHA1 hash of the network structure, starting at the OUI field (offset 0xC) and spanning SizeOfAppData + 0x34. The unused space of the app data buffer is not hashed.
 
|-
 
|-
 
| 0x3F
 
| 0x3F
1,434

edits