DSi Wifi rev-engineering
Re: DSi Wifi rev-engineering
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)
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)
Re: DSi Wifi rev-engineering
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:But actually, DSi and 3DS have them as so:
And then there are these two commands:
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: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: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).
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
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)
Code: Select all
003Bh WMI_SET_BT_STATUS_CMD ;\Bluetooth Coexistence
003Ch WMI_SET_BT_PARAMS_CMD ;/
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
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 ;/
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).
Re: DSi Wifi rev-engineering
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?)
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?)
Re: DSi Wifi rev-engineering
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)
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)
Re: DSi Wifi rev-engineering
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.
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.
Re: DSi Wifi rev-engineering
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:
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:
Re: DSi Wifi rev-engineering
First of all, thank you very much for replying.
I do have a N3DS, DSi, DSL and DSP so I use both kind of consoles.
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 :/
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.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 do have a N3DS, DSi, DSL and DSP so I use both kind of consoles.
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.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?
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 :/
I propose a WiFi symbol next to a boot as the iconnocash wrote:PS. Yes, an icon would be nice... maybe a Wifi symbol or Download symbol or so.
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.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).
Re: DSi Wifi rev-engineering
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).
Or Nancy Sinatra with a Wifi icon (and the melody playing during transfer).zacchi4k wrote:I propose a WiFi symbol next to a boot as the icon
Re: DSi Wifi rev-engineering
Hello, I've installed Unlaunch 2.0 on my DSi and am trying to send an nds file using the integrated wifiboot 2.7. It connects to my router using WPA2 and correctly gets an ip address, however sending doesn't actually work. I've tried with the latest dslink.exe packaged with devkitPro and also with No$gba Debugger 3.02. The router is an Asus AC87U running Asuswrt-Merlin. Is there anything I can do to help debug this issue?
Re: DSi Wifi rev-engineering
Ok this seems to work from another computer so I'm assumming it's a Windows Firewall problem, sorry about that. However, when sending anything over to the DSi I'm getting white top and bottom screens. I've tried building an example app from devkitPro and uploading that too to make sure it isn't my binary but still the same thing.
I also read that you asked somebody else to try wifiboot 2.6 and 2.5 too, so I did the same but got the same result unfortunately.
I also read that you asked somebody else to try wifiboot 2.6 and 2.5 too, so I did the same but got the same result unfortunately.
Re: DSi Wifi rev-engineering
DHCP is nice to get IP addresses assigned automatically... unless it doesn't work.
I've spent a whole day on trying to figure out why DSi/3DS wifiboot doesn't work with DHCP in my current network. I couldn't find any mistakes in the wifiboot source code, but I've finally "solved" it by moving my fritzbox closer to the router.
The network is quite huge, with some long cables (but those are working fine), and lots of switches (the diagram below is showing the ones that I am aware of, maybe there are 1-2 more switches here or there).
The original wiring with the fritzbox on bottom-left didn't work with most devices (except, it did work with win98 for whatever reason).
The newer wiring with the fritzbox attached to "Switch 2" (on right side of the diagram) did solve that problems.
Is there some obious reason why the original wiring didn't work?
My own theories...
I've spent a whole day on trying to figure out why DSi/3DS wifiboot doesn't work with DHCP in my current network. I couldn't find any mistakes in the wifiboot source code, but I've finally "solved" it by moving my fritzbox closer to the router.
The network is quite huge, with some long cables (but those are working fine), and lots of switches (the diagram below is showing the ones that I am aware of, maybe there are 1-2 more switches here or there).
The original wiring with the fritzbox on bottom-left didn't work with most devices (except, it did work with win98 for whatever reason).
The newer wiring with the fritzbox attached to "Switch 2" (on right side of the diagram) did solve that problems.
Code: Select all
.--------.
| Router |
'---.----'
|
cable, 60m
|
.-----------------------------.
| Switch 1 |
'---.-------------------------'
|
cable, 20m
|
.-----------------------------. .------------------------------.
| Switch 2 |--cable-->| Other Access points (unused) |
'---.----------------------.--' '------------------------------'
| |
cable, 8m cable, 2m
| |
.--------------. .----------.
| Access Point | | Fritzbox |
'---.----------' '---.------'
| |
wifi, weak signal wifi, medium signal
| |
.---------------. +---------> DSi console (working, with DHCP)
| Wifi Repeater | |
'---.-----------' +---------> 3DS console (working, with DHCP)
| |
cable, 2m '---------> Android Tablet (working, with DHCP)
|
.----------.
| Fritzbox |
'---.---.--'
| |
| wifi, perfect signal
| |
| +---------> DSi console (no DHCP reply, works only without DHCP)
| |
| +---------> 3DS console (no DHCP reply, works only without DHCP)
| |
| '---------> Android Tablet (failed to optain IP address, doesn't work at all)
|
cable, 2m
|
'-------------> Windows 98 PC (working, with DHCP)
My own theories...
- DHCP uses broadcast packets (=without ACK reply), so packets might get lost, especially on the Access Point with weak wifi signal, maybe it would help (or cause more problems) to flood the network with hundreds of DHCP retries; currently I am merely sending DHCP retries once every 2-3 seconds (and never get any reply)
- DHCP is somehow counting "hops" (reportedly common is max 4 hops, the many switches might exceed that... but then, why does win98 work?)
- One of the access points/repeaters is bugging about some minor details and refuses to work?
- The various access points might disturb each other (some still sending the request, when others are sending the reply)?
Re: DSi Wifi rev-engineering
heh so one of my DSi got rain... and the RTC got corrupted seems the DSi wifi died, as "advanced" AP search causes black error message, and wifiboot from unlaunch just hangs at connecting... (but dslink and all DSware wifi apps works, i can even search for APs on system settings, altough the "test" causes a black screen at the last stage... that could be due to RTC... as without nocash firmware thers just a 1/20 chance of the launcher launching anything without black error screen)
also when soft reset is issued it goes black screen (maybe unlauncher its trying to reset some hardware that is not responding?)
but so it would be nice to have some DSi Wifi diagnostic tool, that shows the wifi initialization and that would not wait indefinitely for the hardware state or that it would retry till it succeed, so i would have some idea if its possible to recover/use the Dsi Wifi or not
but i can't do code at that level yet... so if theres anything existing that i could try... since you are doing all this rev work you may know better
also when soft reset is issued it goes black screen (maybe unlauncher its trying to reset some hardware that is not responding?)
but so it would be nice to have some DSi Wifi diagnostic tool, that shows the wifi initialization and that would not wait indefinitely for the hardware state or that it would retry till it succeed, so i would have some idea if its possible to recover/use the Dsi Wifi or not
but i can't do code at that level yet... so if theres anything existing that i could try... since you are doing all this rev work you may know better