*This article is subject to a lot of changes due to the unfinished nature of this project.*
PictoChat is a chat application included in the nintendo_ds and Nintendo DSi. It is also evil because it's made by Nintendo and Nintendo loves proprietary software. It uses (obviously) a proprietary protocol to communicate. While some of it (such as the Beacon in GBATEK: https://problemkaputt.de/gbatek-ds-wifi-nintendo-beacons.htm ), a lot is not. And because I want to do things on my own, I haven't looked into other people's attempt to reverse engineer pictochat.
IMPORTANT NOTE: This documentation attempt is incomplete.
This project has multiple goals, mostly learning goals. Such as learning how 802.11 works through a fun little side project, but also learning to emit my own frames and figure out how Nintendo can make use of IEEE 802.11b to write mesh_network applications.
So far, the setup has been done (obviously)
When a DS joins the room alone, it will become a Wi-Fi beacon in the same way as a regular Wi-Fi AP. However, it has its own information. It does not contain any SSID, but it also contains a vendor specific tag to specify information such as the room number and the number of connected users. It will become the "host" in a way that it handles beaconing and telemetry. If the host leaves, it is delegated to another DS present in the room.
The NDS uses a couple multicast addresses on multiplay. They are used in the same way it is documented in GBATEK. Source: https://problemkaputt.de/gbatek-ds-wifi-ieee802-11-frames.htm
03:09:bf:00:00:00 is used for the "host" to communicate to other nodes, we will call it HostToClient
03:09:bf:00:00:03 is used by the clients to acknowledge the frame, will be called ClientAck
03:09:bf:00:00:10 is used to reply to the "host", we will call it ClientReply
Differenciating the host from the client without having to remember the MAC addresses can be done by looking at the destination MAC address of the frame.
The LLC layer in the frame is used in such an odd way that I wonder if it's actually LLC and not Nintendo being Nintendo. The DSAP and SSAP are very different depending on the packet ID (and may be used to help identifying the packet type).
A pattern I however noticed is when the control field has the flag 2 (0x2) set, it means that it's the "original" frame. Afterwards, 3 or 4 more packets with the flag reset will be sent.
The packets have a different ID depending on what is sent. The same ID may also mean a different thing depending if the emitter is the host or the client.
The packet ID is on offset 0x2 of the frame data. The headers differs in size and format depending of the packet type and is still a big WIP considering that a lot of the data is quite cryptic and may require reverse engineering of the ROM to understand properly what is being sent.
For now I don't really know the purpose, it could be to ensure that the destination host is right. But there is a constant that persists across the session that is sent in almost every packet. It is 3 bytes long and my only guess so far is that it's some kind of auth key.
When sending a message, clients will send this packet with ID 0x1. Due to the length of a message, it is usually sent over multiple frames and the data can be pieced together aftwards. Analysis of this data is still to be done.
The headers of this packet type is 12 bytes: 10 bytes at the beginning and 2 bytes at the end.
0x00 - Packet Length
0x01 - Always 0
0x02 - Packet Type (always 0x01)
0x03 - Transmission state
- 0x97 Begin of transmission
- 0x04 Transmission ongoing
0x04-0x05 - Data Length
0x06-0x07 - Data offset
0x08-0x09 - ????
0x0c-0x0f - Host Key
[ DATA - (length) bytes ]
-0x01-0x00 - Frame number
This packet is sent very regularily by the Nintendo DS to probably keep the connection alive, such as being able to provide info such as signal strength in real time. I call it Telemetry due to the fact that it is sent regularily even when nothing is happening.
0x00 - Always 0x34 0x01 - Unknown 0x02 - Packet Type (always 0x05) 0x03 - Unknown 0x04-0x05 - Data length --- Data contents --- 0x06-0x09 - Some kind of checksum (oh no that does not sound good) 0x10-0x13 - Host Key -0x03-0x02 - Frame number -0x01 - Unknown