more reassembled data dissection + notes

1 files changed, 24 insertions, 12 deletions

diff --git a/docs/notes.md b/docs/notes.md
index e3d1659..c4a72ab 100644
--- a/docs/notes.md
+++ b/docs/notes.md
@@ -96,14 +96,14 @@ source: <https://git.pipeframe.xyz/fork/melonDS>
   which appears to be some kind of 16-bit encoding of the username set on the
   emulator used to capture these packets (this is likely UCS-2 and not UTF-16
   as suggested by [masscat-nifi] which specifies UCS-2).
+- WEP is not used for local multiplayer. This was verified after using
+  Wireshark to dissassemble the IEEE802.11 header present in all captured
+  frames. None of the captured frames had the WEP encrypt flag set.
 - The messages are not sent as single packets. The Ni-Fi protocol appears to set
   up a constant stream, and messages are sent across multiple frames.
-- A full height filled-in message results in 64 packets (with Wireshark filter
-  `nifi.type.enum == 1 && pictochat && frame[0x1a] == 0x02 && frame.len ==
-  246`)
 - PictoChat does not appear to send messages when you are in a chat room by
-  yourself, so local multiplayer / Ni-Fi emulation is required for capturing
-  message content
+  yourself, so local multiplayer emulation is required for capturing message
+  content
 
 ### Message sizing/cropping
 
@@ -306,18 +306,31 @@ messages from the system that joined later)
 - <https://www.problemkaputt.de/gbatek.htm#dswifiieee80211frames>
 - <https://www.problemkaputt.de/gbatek.htm#dswifinintendobeacons>
 
+## Reassembly
+
+The pictochat protocol itself also seems to be made up of several layers, one
+of which splits large messages over multiple frames. After writing more lua
+code to reassemble these chunks, the following observations were made:
+
+- There is a fixed 0x24 (36) byte header before all drawings
+- The size of the reassembled messages for pictochat drawings exactly follows
+  the equation $f(x) = 36 = 2048x$ where $x$ is the number of rows the message
+  shows up as. The row count of the message does not appear to be stored
+  anywhere.
+- The first 8 bytes of reassembled messages (drawings, room join) consists of a
+  constant 0x03, a message type indicator (1 byte) and the address of the
+  author/subject (6 bytes).
+- The remaining 28 bytes of the reassembled message header are constant for
+  drawings. These bytes appear to be some kind of padding as changing them
+  appears to have no effect and does not show up in the drawing.
+
 ## Unsure/notes
 
 - Is the endianness of the DS properly emulated?
-- Is the Ni-Fi 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?
+- Where is a message's destination (pictochat room) defined?
 
 ## TODO:
 
-- message reassembly field? (how does pictochat know which part a message index is)
 - are message-resends required or can the packets be dropped?
 - user identifier / login / announcement procedure?
 - actual message format
@@ -326,5 +339,4 @@ messages from the system that joined later)
     * palette color indices (pixels are 1 nibble)
 - what types of pictochat packets are there? (i.e. how are room join/leave
   events broadcast?)
-- `pictochat.msg_type in {10, 24, 86}` message reassembly in dissector