diff options
| -rw-r--r-- | assets/pictochat-fiddle-fill-glitch.png | bin | 0 -> 2902 bytes | |||
| -rw-r--r-- | assets/pictochat-fiddle-fill-lork.png | bin | 0 -> 4015 bytes | |||
| -rw-r--r-- | assets/pictochat-fiddle-fill-lork2.png | bin | 0 -> 4427 bytes | |||
| -rw-r--r-- | docs/notes.md | 37 |
4 files changed, 30 insertions, 7 deletions
diff --git a/assets/pictochat-fiddle-fill-glitch.png b/assets/pictochat-fiddle-fill-glitch.png Binary files differnew file mode 100644 index 0000000..ff8a32f --- /dev/null +++ b/assets/pictochat-fiddle-fill-glitch.png diff --git a/assets/pictochat-fiddle-fill-lork.png b/assets/pictochat-fiddle-fill-lork.png Binary files differnew file mode 100644 index 0000000..fe4d059 --- /dev/null +++ b/assets/pictochat-fiddle-fill-lork.png diff --git a/assets/pictochat-fiddle-fill-lork2.png b/assets/pictochat-fiddle-fill-lork2.png Binary files differnew file mode 100644 index 0000000..fb369cf --- /dev/null +++ b/assets/pictochat-fiddle-fill-lork2.png diff --git a/docs/notes.md b/docs/notes.md index 9965544..acc9067 100644 --- a/docs/notes.md +++ b/docs/notes.md @@ -176,10 +176,12 @@ Notable: - All messages with interesting content have Ni-Fi 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. +- All frames appear to be sent exactly 5 times. 'New' frames are indicated with + a 0/2 boolean (0=resend, 2=new) at various points in the packet data. This + resend field may not apply to non-pictochat packets, and [GBATEK][gbatek] + describes this field completely differently. PictoChat resend packets can + safely be dropped without impacting communication (while cutting the packet + dump file size down by ~80%). - The message content appears to be sent unencrypted (patterns of 0x0 and 0x1 nibbles clearly visible in hexdump). - Offset 0x004d - 0x00ec appears to be used to send the actual message content: @@ -248,6 +250,8 @@ TODO: 0x4e(PictoChat msg data offset) - 0x18(Ni-Fi header length) == 0x36 ### Fiddling +#### Corrupt + After editing melonDS source code to corrupt the local multiplayer message buffer in known content locations before sending the message to the FIFO buffer: @@ -257,12 +261,30 @@ buffer: 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) +- Messages are not limited to the apparent 228x80 size, and lines are visible + outside the message border (there is also message content behind the username + label in the above screenshots, but the username label is displayed above the + message) - The ordering of pixels in the messages is not reading order - Message content is not checked or validated in any way +#### Fill + + + + +After dissecting the messages, the bounds of the actual message content, as +well as how to consistently differentiate between pictochat messages and other +messages were used to create a fiddle filter that fills an entire message with +palette index 3 (hot pink). This clearly shows the actual bounds of the +pictochat message. + +Cloning a filled message results in an interesting visual glitch. The message +content appears to be duplicated, as it does not actually contain enough pixel +data to fill almost the entire bottom screen. + + + ## Room host The system that initially joins an empty room appears to become the room host. @@ -303,6 +325,7 @@ messages from the system that joined later) ## More interesting sources / link dump +[gbatek]: https://www.problemkaputt.de/gbatek.htm - <https://www.problemkaputt.de/gbatek.htm#dswifiieee80211frames> - <https://www.problemkaputt.de/gbatek.htm#dswifinintendobeacons> |
