242
edits
Changes
Jump to navigation
Jump to search
Line 10:
Line 10: − + Line 449:
Line 449: + + − + − + − + − + − + + − + + + + + + + + + + + + + + + + + + + Line 488:
Line 509: − + − + − |- − | 0x7 − | 0x1 − | Data channel − + Line 506:
Line 523: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 609:
Line 710: − + Line 632:
Line 733: − + − + − + − +
→NWM local-WLAN service "nwm::UDS": Correct command ID. Verified against UDS disassembly
! 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.
Server->Client: Authentication frame SEQ2
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
Server->Client: Association Response frame with association id
[From here on, the client is paired with the server]
[From here on, the client is connected to the server]
Client->Server: Encrypted data packet with node information, using an LLC header with ethertype = 0x888E (EAPoL) and an apparently dummy EAPoL header, followed by the node information (friendcodeseed, username, and some unknown fields).
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 broadcasting the connection of the new client to the other clients?
Server->Broadcast: Encrypted data packet containing the updated node information after the client connected (Using ethertype = SecureData).
Server->Client: Encrypted data packet containing some sort of ack?
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 exchanged between the client and the server contain the information passed to SendTo, encapsulated with an LLC header with ethertype = 0x876D (SecureData)]
[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 0x8-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==
==SecureData NWM header==
|-
|-
| 0x6
| 0x6
| 0x1
| 0x2
| unknown. Normally 0 during SendTo data transfer. Set to 1 in the automatic periodic frames NWM sends (Ping frames?) and for broadcasting the updated node information when a new client connects. Probably a "is_management" bit.
| Data channel. Applications can only use the low 8 bits, channels greater than 255 are reserved for management functions.
|-
|-
| 0x8
| 0x8
| 0x2
| 0x2
| unknown
| Sequence number, incremented after each sent packet.
|-
|-
| 0xA
| 0xA
| 0x2
| 0x2
| Source network node id
| 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
|}
|}
| 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
|-
|-
| 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