diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/notes.md | 69 |
1 files changed, 67 insertions, 2 deletions
diff --git a/docs/notes.md b/docs/notes.md index 21eef78..657383e 100644 --- a/docs/notes.md +++ b/docs/notes.md @@ -81,16 +81,81 @@ sufficiently advanced local multiplayer emulation. source: <https://git.pipeframe.xyz/fork/melonDS> -### Findings - - melonDS @ Config > Wifi settings "Local multiplayer features do not use the same network protocols as online play" - comment @ src/Wifi.cpp:46 "multiplayer host TX sequence" - references to `RFTransfer_Type{2,3}` @ <https://www.problemkaputt.de/gbatek.htm#dswifirfchip> - nintendo ds ni-fi protocol @ <https://web.archive.org/web/20090202194241/http://masscat.afraid.org/ninds/proto_info.php> - melonDS emulates actual 802.11b frames - the protocol does not appear to be encrypted: +  + the string `lork` is visible as plain text in the hexdump (offset 0x0056), which appears to be some kind of 16-bit encoding of the username set on the emulator used to capture these packets +- The messages are not sent as single packets. The nifi protocol appears to set + up a constant stream, and messages are sent across multiple frames. +- PictoChat does not appear to send messages when you are in a chat room by + yourself, so local multiplayer / nifi emulation is required for capturing + message content + +### Message sizing/cropping + +- PictoChat automatically crops messages to the smallest height (at the fixed + intervals shown as notebook lines in the edit field on the bottom screen). + Message content can be on the line itself without causing the cropping + algorithm to 'allocate' more space; the allocation only happens if any of the + pixels on the line *below* the colored line are used. The method used to crop + the messages also ensures that the username label in the top left does not + obstruct or remove any content. + +  +  +- Message content is likely only cropped when displaying + +  +  + + The above image was obtained after the following steps: + - Fill in the top row of the message with the black pen, ensuring the entire + notebook line is colored in as well + - Send message (displayed as top message) + - Copy message + - Erase small portion of black area on the right side (displayed as bottom message) + + Notable observations: + - The message content has a 1 pixel border (padding/margin) on all sides + (except the bottom and corners) that can not be filled in. The bottom + border is correctly displayed for received messages, but the edit field has + an additional row of pixels that directly touch the message border on the + bottom. + - When any message is cloned, additional pixels that were masked on the top + screen become visible again in the edit field. This includes the bottom row + of pixels, as well as the two rows of pixels shown in the single line + message picture. + +### Message content + + + + +- All messages with interesting content have NIFI header type 1 (CMD). +- PictoChat messages appear to be sent over frames of length 0xf6 (246) + regardless of actual message size. +- All frames appear to be sent exactly 5 times. 'New' frames have a value of + 0xe004 at offset 0x0026, while resends have a value of 0xf000 instead. +- There are a lot of messages with length 0xaa (170), these appear to include a + random 32-bit value at offset 0x0046. +- The message content (suspected bitmap-like format) appears to be sent + unencrypted (patterns of 0x0 and 0x1 nibbles clearly visible in hexdump). + +## Unsure/notes + +- Is the endianness of the DS properly emulated? +- Is the NIFI magic value also present in physical frames or is this something + MelonDS did? +- The DS implemented WEP(?) encryption for connecting to home network + routers/APs, but is this encryption also used when the WiFi module is used in + local multiplayer mode? Does this even matter inside the emulator? + |