more research

9 files changed, 104 insertions, 25 deletions

diff --git a/assets/pictochat-msg-corrupt-lork.png b/assets/pictochat-msg-corrupt-lork.png
new file mode 100644
index 0000000..4d8f9b6
--- /dev/null
+++ b/assets/pictochat-msg-corrupt-lork.png
diff --git a/assets/pictochat-msg-corrupt-lork2.png b/assets/pictochat-msg-corrupt-lork2.png
new file mode 100644
index 0000000..55ef30d
--- /dev/null
+++ b/assets/pictochat-msg-corrupt-lork2.png
diff --git a/assets/pictochat-msg-pattern.png b/assets/pictochat-msg-pattern.png
index db19ad2..f9d8549 100644
--- a/assets/pictochat-msg-pattern.png
+++ b/assets/pictochat-msg-pattern.png
diff --git a/assets/ws-msg-fill-bot.png b/assets/ws-msg-fill-bot.png
new file mode 100644
index 0000000..ab496d2
--- /dev/null
+++ b/assets/ws-msg-fill-bot.png
diff --git a/assets/ws-msg-fill-mid.png b/assets/ws-msg-fill-mid.png
new file mode 100644
index 0000000..c708447
--- /dev/null
+++ b/assets/ws-msg-fill-mid.png
diff --git a/assets/ws-msg-fill-top.png b/assets/ws-msg-fill-top.png
new file mode 100644
index 0000000..476bcf3
--- /dev/null
+++ b/assets/ws-msg-fill-top.png
diff --git a/assets/ws-msg-pattern.png b/assets/ws-msg-pattern.png
index d1f08ef..040d821 100644
--- a/assets/ws-msg-pattern.png
+++ b/assets/ws-msg-pattern.png
diff --git a/docs/notes.md b/docs/notes.md
index 657383e..10c2608 100644
--- a/docs/notes.md
+++ b/docs/notes.md
@@ -90,9 +90,9 @@ source: <https://git.pipeframe.xyz/fork/melonDS>
 
   ![](../assets/ws-no-encrypt.png)
 
-  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 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
@@ -103,11 +103,11 @@ source: <https://git.pipeframe.xyz/fork/melonDS>
 
 - 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 can be on the notebook 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.
 
   ![](../assets/pictochat-msg-height-1-4.png)
   ![](../assets/pictochat-msg-height-5-draw.png)
@@ -121,7 +121,8 @@ source: <https://git.pipeframe.xyz/fork/melonDS>
     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)
+  - 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
@@ -133,6 +134,7 @@ source: <https://git.pipeframe.xyz/fork/melonDS>
     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.
+  - The drawable area (including obstructed top-left corner) is 228x80 pixels
 
 ### Message content
 
@@ -148,6 +150,55 @@ source: <https://git.pipeframe.xyz/fork/melonDS>
   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).
+- 0x004d - 0x00ec appears to be used to send the actual message content:
+
+  ![](../assets/pictochat-msg-crop-lork2.png)
+  ![](../assets/ws-msg-fill-top.png)
+  ![](../assets/ws-msg-fill-mid.png)
+  ![](../assets/ws-msg-fill-bot.png)
+
+  (excerpts from the start, middle and end frames of a completely filled
+  message)
+- The completely filled message also shows an interesting pattern at the end,
+  hinting at a slightly odd image codec
+
+#### Analysis
+
+![](../assets/ws-msg-fill-mid.png)
+
+|offset|type|description|
+|-|-|-|
+|0x0000|`u32`|NIFI: Magic (0x4e494649)|
+|0x0004|`u32`|NIFI: SenderID (melonDS InstanceID)|
+|0x0008|`u32`|NIFI: Type|
+|0x000c|`u32`|NIFI: Length (after NIFI header)|
+|0x0010|`u64`|NIFI: Timestamp|
+|
+|0x0018|`u16`|PictoChat: 0|
+|0x001a|`u16`|PictoChat: (Resend???) (2=New, 0=Resend)|<!-- I assume u16 because the next byte is always 0x00 -->
+|0x0028|`u8[6]`|PictoChat: multiplayer CMD MAC (melonDS Wifi::MPCmdMAC)|
+|0x002e|`u8[6]`|PictoChat: sender MAC|
+|0x0034|`u8[6]`|PictoChat: sender MAC (again)|
+|0x004d|`u8[0xa0]`|PictoChat: Message data (encoding unknown)|
+|0x00ed|`u16`|PictoChat: (random???)|
+|0x00f0|`u8[6]`|PictoChat: (mac/id???)|
+
+### Fiddling
+
+After editing melonDS source code to corrupt the local multiplayer message
+buffer in known content locations before sending the message to the FIFO
+buffer:
+
+![](../assets/pictochat-msg-corrupt-lork.png)
+![](../assets/pictochat-msg-corrupt-lork2.png)
+
+This shows a few important details:
+
+- Messages are not limited to the apparent 228x80 size (there is also message
+  content behind the username label in the above screenshots, but the username
+  label is on a different graphics layer)
+- The ordering of pixels in the messages is not reading order
+- Message content is not checked or validated in any way
 
 ## Unsure/notes
 
diff --git a/experiments/pixel-sequence/draw b/experiments/pixel-sequence/draw
index c26ac27..3561865 100755
--- a/experiments/pixel-sequence/draw
+++ b/experiments/pixel-sequence/draw
@@ -1,15 +1,51 @@
 #!/bin/sh
 
-# pray that the mouse is in the edit field once this timer runs out
-sleep 3
+WINDOW="$(xdotool search --onlyvisible --maxdepth 2 --class melonDS | head -n1)"
+[ -z "$WINDOW" ] && exit 1
+
+eval "$(xdotool getwindowgeometry --shell "$WINDOW")"
+
+sleep 0.5
+
+bottom_screen() {
+	xdotool mousemove $X $Y
+	# skip menu bar
+	xdotool mousemove_relative 0 20
+	# skip top screen
+	xdotool mousemove_relative 0 192
+
+	xdotool mousemove_relative -- $1 $2
+}
+tap() {
+	xdotool mousedown 1
+	sleep 0.02
+	xdotool mouseup 1
+	sleep 0.02
+}
 
 pattern='
-1010
-11001100
-1111000011110000
-11111111000000001111111100000000
+10101010
+1100110011001100
+11110000111100001111000011110000
+1111111100000000111111110000000011111111000000001111111100000000
 '
-pattern="$(echo "$pattern" | tr -d '\n' | sed 's/./\0 /g')"
+pattern="$(echo "$pattern" | tr -d '\n')"
+length="$(echo "$pattern" | wc -c)"
+pattern="$(echo "$pattern" | sed 's/./\0 /g')"
+
+# clear
+bottom_screen 240 170
+tap
+
+# pen
+bottom_screen 8 44
+tap
+# small
+bottom_screen 8 92
+tap
+
+# message top left
+bottom_screen 82 18
 
 for pixel in $pattern ; do
 	# shift mouse 1 pixel right
@@ -18,14 +54,6 @@ for pixel in $pattern ; do
 	# skip 0's in $pattern
 	[ $pixel -ne 1 ] && continue
 
-	# drag mouse 1px down to create pixel
-	xdotool mousedown 1
-	sleep 0.05
-	xdotool mousemove_relative 0 5
-	sleep 0.05
-	xdotool mouseup 1
-	sleep 0.05
-	xdotool mousemove_relative 0 -5
-	sleep 0.05
+	tap
 done