aboutsummaryrefslogtreecommitdiff
path: root/docs/notes.md
blob: 657383e5c8f0ba358dd38b94d23f1e388196b92d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
# research

## DS / DSi emulators

wanted features:

- **DS and DSi version emulation (DSi for later)**
  
  DS version of pictochat can still receive images with rainbow drawings, but
  doesn't support sending
- **firmware booting**
  
  the phat DS and DS lite's firmware had pictochat built-in instead of as a
  standalone app like on the DSi. to launch pictochat, firmware booting must be
  possible.
- **local multiplayer network emulation**
  
  required for testing sending and receiving
- **local multiplayer packet capture**
  
  required for reverse engineering the packet format
- **local multiplayer packet injection**
  
  required for testing forged packets
- **open source**
  
  DIY packet injection anyone?
- **linux-compatible**
  
  just a preference
- **debugging (ideally using GDB or similar interface)**
  
  if all else fails, reading and/or injecting packets into memory using a
  debugger might be the only option for testing forged packets. a debugger
  could also help with reverse engineering the decoding process of a pictochat
  packet/message

### [DeSmuME][desmume]

- phat ds only
- no firmware booting
- no local multiplayer emulation
+ open source
+ cross-platform
- no debugger

DeSmuME is focused on high quality/performance emulation for single player
titles, and actively rejects requests for WiFi emulation.

### [melonDS][melonds]

+ ds and (experimental) dsi support
+ firmware booting support
+ local multiplayer emulation
+ allows patched-in or real network packet capture using loopback network
  adapter and wireshark
+ loopback network adapter also (probably) allows injecting forged packets
+ open source
+ cross-platform
- no debugger

melonDS is a very new emulator that is still actively being developed. melonDS
is focused on accurate emulation and is the only one on this list with
sufficiently advanced local multiplayer emulation.

### [no$gba][nogba]

+ supports DS and DSi games
+ firmware booting support
- no local multiplayer emulation
- closed source
- windows only
+ very advanced debugger

[toolchaingenericds]: https://bitbucket.org/Coto88/toolchaingenericds/src/master/
[nogba]: https://problemkaputt.de/gba.htm
[melonds]: https://melonds.kuribo64.net/
[desmume]: https://desmume.org/

## MelonDS hacking

source: <https://git.pipeframe.xyz/fork/melonDS>

- 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:

  ![](../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 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.

  ![](../assets/pictochat-msg-height-1-4.png)
  ![](../assets/pictochat-msg-height-5-draw.png)
- Message content is likely only cropped when displaying

  ![](../assets/pictochat-msg-crop.png)
  ![](../assets/pictochat-msg-crop-lork2.png)

  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

![](../assets/pictochat-msg-pattern.png)
![](../assets/ws-msg-pattern.png)

- 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?