DSi Wifi rev-engineering

Discussion of development of software for any "obsolete" computer or video game system.
nocash
Posts: 1060
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi Wifi rev-engineering

Post by nocash » Wed Jul 10, 2019 4:48 pm

Released wifiboot v2.6 and no$gba v2.9e
http://problemkaputt.de/wifiboot.htm
http://problemkaputt.de/gba.htm
The main news is allowing to upload 3DS .firm files from no$gba utility menu to 3DS consoles.

That is my first 3DS program : )
And it's even a useful one... at least for people whom are coding .firm files.
Which is probably meaning useful to 3-5 people, but anyways.

10 Jul 2019 - wifiboot v2.6
- 3ds-wifi: added support for uploading 3DS.firm files via 3ds sdio
- source code cleaned up (REGBASE symbols, moved new SDIO code to wificore)
- extended transfer protocol (new bootinfo block, icon/title, rtc/time, etc)
- co-releases: 3ds.firm upload in no$gba/utility, wifiboot protocol in gbatek

10 Jul 2019 - version 2.9e
- wifiboot uploader: supports uploading 3ds .firm files from no$gba to 3ds
- wifiboot uploader: new bootinfo block (icon/title and rtc/time)
- wifiboot/help: added DS Wifi Dslink/Wifiboot Protocol chapter
- 3ds/help: added notes on SD/MMC Signals and 3DS Hardmodding
- 3ds/help: 3ds NWM wifi driver info (pool addresses and type1/4/5 variants)
- 3ds/help: specs for CID/OTP/NCSD/FIRM sectors for 3ds-#.mmc and new3ds-#.mmc
- setup: added 3ds/new3ds as nds mode variants (for debug view, not emulation)
- 3ds/aes: supports keyinit as by bootrom per otp (for filesys viewer)
- 3ds/emmc: loaded from 3DS-1.mmc or New3DS-1.mmc (for filesys viewer only yet)
- 3ds/bios: loaded from BIOS3DS.ROM (ARM9+ARM11) or BIOS3DS9.ROM+BIOS3DS11.ROM
- 3ds/help: added file/filesys info and arm11 mpcore/irq register specs
- wifi/help: added several new details (mostly from newly dumped AR6014 rom)
- a22i: supports abbrev ALU Rd,Rm,RotateShift (using Rd for both Rd and Rn)
- wifi/help: added wifi-board pinouts from fccid, and 4kbyte-wifi-flash-specs
- 3ds/crypt: supports sha256, sha224, aes-cbc, new keyscrambler (keyx/y)
- filesys viewer: show/decrypt 3ds stuff (partitions and firm/sav blocks)
- filesys viewer: faster directory loading (abort on first unused 00h entry)

nocash
Posts: 1060
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi Wifi rev-engineering

Post by nocash » Wed Jul 10, 2019 6:21 pm

And some behind the scenes findings... I've spend the last 1-2 weeks on gazing at the 3DS AR6014 wifi firmware's rom/ram code (and also peeked at the DSi AR6002/AR6013 versions here and there).

Going by most or all official atheros source code, the last three WMI commands at 0047h and up should be:

Code: Select all

  0047h  WMI_SET_FRAMERATES_CMD    ;aka WMI_FRAME_RATES_CMD
  0048h  WMI_SET_AP_PS_CMD         ;aka WMI_AP_PS_CMD
  0049h  WMI_SET_QOS_SUPP_CMD
But actually, DSi and 3DS have them as so:

Code: Select all

  0047h  WMI_START_WHATEVER_TIMER_CMD                        ;-whatever on DSi!
  0048h  WMI_SET_FRAMERATES_CMD    ;aka WMI_FRAME_RATES_CMD  ;-cmd 0048h on DSi (instead of 0047h)!
  0049h  WMI_HOST_EXIT_NOTIFY_CMD  ;special DSi/3DS command (called host exit notify in ar6013/6014 ascii strings)
And then there are these two commands:

Code: Select all

  003Bh  WMI_SET_BT_STATUS_CMD    ;\Bluetooth Coexistence
  003Ch  WMI_SET_BT_PARAMS_CMD    ;/
They are implemented in AR6002, but AR6013/6014 are simply ignoring that two commands (the firmware does have code for handling the commands, but the function vectors are instead pointing to dummy handlers... so it looks as if somebody has intentionally or accidentally made them nonfunctional).

The Type4/Type5 firmware variants for 3DS have these extra commands:

Code: Select all

Special 3DS commands (for Type4 firmware, with AP mode):
  004Ah  WMI_AP_HIDDEN_SSID_CMD                         ;01h bytes (1)
  004Bh  WMI_AP_SET_NUM_STA_CMD aka WMI_AP_NUM_STA_CMD  ;01h bytes (1)
  004Ch  WMI_AP_ACL_POLICY_CMD                          ;01h bytes (1)
  004Dh  WMI_AP_ACL_MAC_LIST_CMD aka WMI_AP_ACL_MAC_CMD ;09h bytes (1+1+6+1)
  004Eh  WMI_AP_CONFIG_COMMIT_CMD                       ;34h bytes (..)
  004Fh  WMI_AP_SET_MLME_CMD                            ;09h bytes (6+2+1)
  0050h  WMI_AP_SET_PVB_CMD     ;ignored on 3DS         ;06h bytes (ignored)
  0051h  WMI_AP_CONN_INACT_CMD                          ;04h bytes (4)
  0052h  WMI_AP_PROT_SCAN_TIME_CMD                      ;08h bytes (4+4)
  0053h  WMI_?                                      ;01h bytes (1)
  0054h  N/A
  0055h  WMI_?                                      ;04h bytes (2+2)
  0056h  WMI_ignored_?                              ;01h bytes (ignored)
  0057h  WMI_?  ;with EVENT_1022h                   ;00h bytes
  0058h  WMI_?     <-- with optional params?        ;var       (2+2+1+1+N)
  0059h  WMI_?       ;only lower 8bit used          ;04h bytes (4; only 1 used)
  005Ah  WMI_?                                      ;01h bytes (1)
  005Bh  WMI_?                                      ;04h bytes (2+1+1)
  005Ch  WMI_?                                      ;04h bytes (1+3)
  005Dh  WMI_?                                      ;0Ah bytes (1+1+2+1+1+2+2)
  005Eh  WMI_?                                      ;01h bytes (1)
  005Fh  WMI_?                                      ;04h bytes (4)
Special 3DS commands (for Type5 firmware, with MacFilter and GameID):
  0060h  WMI_?                             ;3Ah bytes
  0061h  WMI_?                             ;28h bytes
  0062h  WMI_?                             ;12h bytes
  0063h  WMI_?                             ;02h bytes
  0064h  WMI_?                             ;03h bytes
  0065h  WMI_?                             ;07h bytes
  0066h  WMI_?                             ;07h bytes
  0067h  WMI_?                             ;03h bytes
  0068h  WMI_?  ;can be with EVENT_1023h   ;01h bytes
  0069h  WMI_?                             ;00h bytes
  006Ah  WMI_?                             ;00h bytes
  006Bh  WMI_?                             ;01h bytes
  006Ch  WMI_?                             ;06h bytes
  006Dh  WMI_?  ;with EVENT_1026h          ;00h bytes
  006Eh  WMI_?                             ;01h bytes
  006Fh  WMI_?                             ;06h bytes
  0070h  WMI_?                             ;01h bytes
  0071h  WMI_?                             ;08h bytes
  0072h  WMI_?                             ;02h bytes
  0073h  WMI_?  ;with EVENT_1027h          ;01h bytes
The AP mode commands appear to be same as what is command number F00Ah..F013h in official atheros code. I guess the 3DS is using that AP stuff to host multiplayer games.
So, I think both Type4 (AP Mode) and Type5 (MacFilter) are somehow "local network" related. Maybe one is for Streetpass, and one for Single-gamepak DownloadPlay (and maybe also one of them for Multi-gamepak local multiplayer).

Oh, and I have taken another approach on comparing the 3DS NWM wifi firmware versions. Searching for known Xtensa code didn't work (for unknown revisions). So, I am now searching for known ARM literal pool structures (to obtain size & offset of the Xtensa code blocks). I've compared four NWM files yet, and found them to contain three different Xtensa code revisions:

Code: Select all

  Stub.data   038h bytes                   ;\Database and EEPROM reading stub
  Stub.code   316h bytes                   ; (always same size/content)
  Database    1E8h bytes                   ;/
  Main.type1  0FD3h, 10F7h, or 1B1Bh bytes ;\Main firmware (compressed)
  Main.type4  A053h, A482h, or A5EBh bytes ; (size/content varies per version)
  Main.type5  78F6h, 7A2Eh, or 7A2Eh bytes ;/
Or, well Type5 has only two different sizes (I haven't checked yet if the 7A2Eh-byte versions are identical).

For normal use the oldest/smallest Type1 versions seems to be fine. I've tried to disassemble that code, it's only 1600 lines, but to really understand what it is doing one would also need to disassemble 70,000 lines of ROM code (which, I have only disassembled parts of it).
Anyways, in general, the RAM code containx the usual "main init" function (required because the atheros ROMs are lacking that code). And the remaining RAM code seems to be mostly containing a newer revision of the atheros/mitsumi mode switching code, and lots code for testing GPIO bit14 (which might be also mode switching related).

nocash
Posts: 1060
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi Wifi rev-engineering

Post by nocash » Mon Aug 26, 2019 5:58 pm

Released wifiboot v2.7 - http://problemkaputt.de/wifiboot.htm

wifiboot v2.7 - 26 Aug 2019
- fast reconnect: re-uses old channel number and dhcp settings on warmboot
- 3ds: forces sys mode, for compatibility with luma3ds (thanks psi)
- 3ds: faster power button and power off handling, and home button reset
- 3ds: init arm11 irq targets (in case they were destroyed by fastboot.3ds)
- 3ds: issues disconnect_cmd after upload (doing same on dsi/ar6013 crashes?)

zacchi4k
Posts: 2
Joined: Sun Sep 08, 2019 11:02 am

Re: DSi Wifi rev-engineering

Post by zacchi4k » Sun Sep 08, 2019 11:24 am

Hello,
I've been having an issue with Wifiboot, namely it doesn't recognize hidden WiFi networks.
I have configured my router to have a guest, non-password protected WiFi hotspot with MAC filtering just for the DS consoles.
If I enable SSID broadcasting, everything works fine, however, when I turn it off, while the consoles can still connect to the hotspot (via games or via the Internet config screen), Wifiboot suddenly can't connect anymore.

Another "issue" is the application doesn't have any icon (really doesn't matter, but I figured I could point it out)

nocash
Posts: 1060
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi Wifi rev-engineering

Post by nocash » Tue Sep 10, 2019 12:13 pm

Yes, sorry, hidden networks aren't supported in wifiboot (nor dslink). The channel scanning relies on receiving Beacons with SSID strings from the access point. I didn't even knew that Nintendo supports that hidden access point feature - and don't know if/how I could implement it. First of, two questions:

Why are you doing that, is that your security fix fow using WEP, or some energy saving scheme?
And are you really using a DS console, or a DSi?

Implementing that feature should be probably done by sending a Probe Request to the access point, and then receiving a Probe Response (which is equivalent to normal Beacons).
I had considered doing that even for normal access points because it might save 100ms of time spend on waiting for Beacons to arrive.
On the other hand, it would require sending Probe Request to all 3 or 6 access points - and if they do actually all respond with Probe Responses then packets would be more likely to collide and things might get slower and/or more unreliable.

With NDS-Wifi it should be possible to send Probe Requests, but I have no idea if (or how) DSi-Wifi does support it. The other approach that might work would be blindly trying to connect to the access points without any Beacons or Probing, but that might also slow down things when trying to connect to all 3 or 6 access points on all channels.

Altogether it would be easiest to use non-hidden access points. Unless....

Are those hidden access points a must-have feature used by many people?
Or do you know some good connection flowchart that would avoid most of the above possible problems?

PS. Yes, an icon would be nice... maybe a Wifi symbol or Download symbol or so.

tepples
Posts: 21707
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: DSi Wifi rev-engineering

Post by tepples » Tue Sep 10, 2019 1:33 pm

Google Search keyword: hidden ssid

Some people have recommended disabling beacons (or "hiding the SSID") based on the same logic as not having to outrun the proverbial lion: it makes you less visible as a target than nearby networks run by others. But disabling beacons doesn't add security. In fact, some operating systems are known to broadcast probe requests for all saved networks with hidden SSIDs continuously in case one is nearby, which leaks the SSIDs to others listening to your device's probe requests using Wireshark (doo doo doo-doo doo-doo).

Sources:

zacchi4k
Posts: 2
Joined: Sun Sep 08, 2019 11:02 am

Re: DSi Wifi rev-engineering

Post by zacchi4k » Sat Sep 14, 2019 10:14 am

First of all, thank you very much for replying.
nocash wrote:Why are you doing that, is that your security fix fow using WEP, or some energy saving scheme?
And are you really using a DS console, or a DSi?
I really disabled SSID broadcast just for the convenience of not having an open but filtered showing up on every WiFi device in my house. I really don't care if people can still sniff the WiFi traffic, because I only use it for the DS consoles. And even if MAC filtering is still not impenetrable, I could just turn the WiFi network on when needed and then turn it off.
I do have a N3DS, DSi, DSL and DSP so I use both kind of consoles.
nocash wrote:Altogether it would be easiest to use non-hidden access points. Unless....

Are those hidden access points a must-have feature used by many people?
Or do you know some good connection flowchart that would avoid most of the above possible problems?
I don't know, but if I had to guess it's just me and a few dozen people using a setup like this, most people probably use their phone with an open hotspot when they need to connect with the DS. Now I could be wrong, but if it turns out to be actually the case, I certainly don't pretend you implement a feature for just a few people to use.
Sorry, but I'm a complete noob when it comes to anything ever remotely related to low-level networking, so I can't be of much help with the second question :/
nocash wrote:PS. Yes, an icon would be nice... maybe a Wifi symbol or Download symbol or so.
I propose a WiFi symbol next to a boot as the icon :P
tepples wrote:In fact, some operating systems are known to broadcast probe requests for all saved networks with hidden SSIDs continuously in case one is nearby, which leaks the SSIDs to others listening to your device's probe requests using Wireshark (doo doo doo-doo doo-doo).
I don't think I'm extremely "vulnerable" to this exploit since the network is used exclusively by the DS consoles, and those only look for WiFi when it's strictly necessary.

nocash
Posts: 1060
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi Wifi rev-engineering

Post by nocash » Sun Sep 15, 2019 6:48 am

Okay, I'll probably leave hidden SSID's unimplemented. But, you have the hidden WEP guest mode compined with non-hidden WPA/WPA2? Then you could at least use the WPA/WPA2 access point for DSi (and 3DS).
zacchi4k wrote:I propose a WiFi symbol next to a boot as the icon
Or Nancy Sinatra with a Wifi icon (and the melody playing during transfer).

Post Reply