Homebrew dswifi ASM port, and bugs in dswifi HLL version

[nocash123]

Here's the dswifi librbary ported to ASM code. I've been busy on that project for the past five weeks, and just finished the port yesterday, it's still untested, still lacks some basic subfunctions (like memcopy), and I've probably screwed up a lot of things and the code is probably still totally bugged.

Anyways, during porting, I've naturally had to 'review' every single line of code in the original HLL versions, and came across a bunch of bugs & oddities in the original code. For details, check the ASM file, and search for comments with tags "BUGGED", "BLAH", and "uh":

View attachment 67769 - dswifi ASM port (new ASM code, with comments on HLL bugs)
View attachment 67770 - dswifi HLL code (just for reference: the original HLL code, merged into a single txt file)

EDIT: Hmmm, above links have no permission to view the attachment(?) alternately try thes links (should be working, unless that "temp hash" expires at some point; or unless it should work only with my own IP):
http://gbatemp.net/attachments/dswifi01-txt.67769/?temp_hash=1582d05735d506a4e68e6c28013f9808 - ASM
http://gbatemp.net/attachments/dswifi00-txt.67770/?temp_hash=1582d05735d506a4e68e6c28013f9808 - HLL
(if somebody knows how to use the forums "ATTACH" feature please PM me, just using the attachment number enclosed in ATTACH and /ATTACH doesn't seem to work out)

Tag BUGGED indicates real bugs (unless I've totally misunderstood the code). For example, checksum calculation looks wrong in some cases (carry-out handling, or checksum-zero handling), the checksumming should work in most cases, but it might produce transmission errors at 1:65535 chance (possibly passing okay if retransmissions are done with different headers & different checksums). Some other bugs include cropping the transfer length to the bigger of two values (instead of the smaller value).

Tag BLAH (no offense) indicates useless/unused functions & variables. Some if of it is subjective though (the "extern" definitions are (only) useless when merging the whole source code into a single file; and some of the unused variables might have some purpose for debug/status stuff).

Tag uh indicates stuff that's unclear to me. Some of it might be bugged, or it might be actually working and intended as-is (but would be nice to get some comments/confirmations that explain how/why it's working).

The function names are 99% same as in the original code, so it should be easy to naviagate between the comments in the ASM file and the original code in the HLL files. Main difference is that I've prefixed some functions names by "arm7_" or "arm9_", just remove that prefixes to get the original name.

PS. what I am actually up to is trying to make some wifi uploader that works more reliable than dslink, and preferably also smaller; my current binary is 32Kbytes, and it could be compressed to around 16Kbytes, but it's still too big for DSi cartridge exploits with only have 8Kbytes of save memory, but maybe I can throw away some components: DNS shouldn't be needed for local networks, and Stephen suggested that one could also use non-TCP transmissions, and, not sure if one needs DHCP and IP addresses at all... or could one also use the DS(i)'s MAC address directly from within local networks?

 

[dark_samus3]

for the saves stuff, why not look into compression for the code, that might help (I know it helped a lot for some 3ds related stuff) as for the rest of it, I haven't looked it over yet, but looks like it might be neat

 

[elhobbs]

not sure if this is of any interest to you but I did do some work with wifi for the ds and refactored the dswifi code a bit for a peer to peer version of cquake. this uses fnet instead of the dswifi protocol stack. cquake only used udp but I did do some minimal tests with tcp/ip and it was working. this supports connecting to an AP or acting as a AP for other ds consoles to connect to.
https://storage.googleapis.com/goog.../code.google.com/cquake/cnquake_src_062813.7z

 

[reprep]

Can't wait to use this on my The Biggest Loser dsi cartridge. Hope you can make it fit on 8kbit. Also dslink doesn't work on DWM-W024 boards so my dsi xl cant run it. Hope this works on all versions.

 

[nocash123]

Got it working! Source code in ASM and binaries are here: http://gbatemp.net/attachments/dswifi02-zip.70966/?temp_hash=7042fdc7b23b7be3a7981eeb760df513 - that package includes:

ASM port of the dswifi library from Stephen Stair - same as mentioned in the earlier post, but after adding some glue logic and fixing dozens of mistakes in my ASM code it's now actually tested & working quite well. Sometimes it's disconnecting (displaying "-DIS-") immediately after connecting to an accesspoint (and then requires to reboot and try again). I haven't yet figured out what is causing that issue, but apart from that, everything looks stable.
Oh, and one nice feature is that my channel scanning is ways faster as in the original dswifi version, so it should find your access point almost instantly (if it's on a common channel, ie. 1,6,11).

ASM clone of the dslink tool from wintermute - more or less same as the original dslink tool (allowing to wifi-upload bootcode from .nds/.dsi files to the console). The main difference is that my ASM version will initialize the stacks & hardware similar as how they are initialized by real NDS firmware (the original dslink didn't do so, causing the uploaded code to crash instantly after uploading), that's been the main reason why I've spend 9 weeks on that dswifi asm port (although, when I was almost done with that project, wintermute suddenly started to fix the bugs in the dslink HLL version, so I could have as well wasted my time on something else).
For the PC side, I'll probably add an "upload" function in next no$gba update. For now, people could use my dslink.nds ASM version on console side with wintermute's dslink.exe on PC side.

Dumping tool for several DSi chips - this is allowing to dump ROM, FLASH, Chip IDs, I/O ports from DSi wifi daughterboard, and DSi cameras... stuff that hasn't been done in the past years, apparently the HLL guys didn't knew how to, but with my wifi ASM port nobody is needing HLL programmers any longer ; ) and it should be now possible to figure out which chip(s) from which manufacturer(s) Nintendo has been using in their wifi/camera hardware on DSi (and 3DS). For using it:
- Start "dsdump.dsi" on the console (in DSi mode) (and make source that you've configured wifi access point 1-3 in system settings, working should be open access points, with or without DHCP, and WEP should work too, but it's still untested).
- Start "dsdump.exe" on a windows PC, that tool should then receive five files from the DSi/3DS console and save them as "dump*.bin", the dumping/transfer takes a few seconds for the first four files, the last file will take several minutes (it's intended to dump the wifi ROM, but for most wifi boards it's still unknown where the ROM is located in memory, so it dumping the whole 4Mbyte address space of the wifi chip, which is kinda slow unfortunately).
After dumping all files, the PC tool should exit, and the console should display DUMPDONE. Ah, and if it finds unidentified hardware during dumping, then it should display UNKNOWN HARDWARE in red ink on the console screen. Which, I would be interested in getting the dumps or chip IDs for any such hardware (or even better, hopefully getting the actual hardware some day).

 

[nocash123]

Updated the wifi code and dsi memory dumping tool:

New Wifi code contains a bugfix for WEP encryption, though WEP is still untested to my knowledge... or did anybody test it? And it's having a bugfix for handling wifi disassocation requests (which should be fixed in original dswifi library too, although the original lib doesn't ever seem to encounter disassociation, but if it would do so, then the bugfix would help; the original code did just ignore disassociation requests).

DSi memory dumper does now contain an extra function for dumping the I2C bus wifi calibration EEPROM, including for the overwritten word at index [F0h] and including for the unused bytes at index [300h..3FFh], which seem to be just zerofilled. The main work there has been to write an Xtensa instruction set assembler for being able to run custom code on the Wifi CPU. The EEPROM dumping code is tested/working on AR6002 (old DSi). It's also intended to work on AR6013 (new DSi which uses different GPIO pins for I2C bus). The only thing that won't work is dumping the EEPROM on AR6014 (3DS and New3DS, which, I think, it isn't yet even known if that consoles do contain an I2C bus EEPROM at all, least how to dump it).

To all hackers & crackers: It's all up to you: You can be the first person ever to discover new unknown hardware! Just run that dsdump.dsi tool on your DSi/3DS and dsdump.exe on your PC, and watch out for messages saying "UNKNOWN HARDWARE" in red ink. Hacking's never been simple! Or if it doesn't work for some reason, please let me know!

http://gbatemp.net/attachments/dswifi03-zip.72277/?temp_hash=97d672ff546b4322536bb2b1cdbec149

 

[Coto]

Fun-documented assembly.

Now why dont you submit these bugfixed to DSWIFI then? For example NesDS NIFI uses a modified https://github.com/cotodevel/NesDS/commit/0582d5ba914ca5108978a72448e78aea3fca790b

Not that I could not do that, but if you invested three weeks of your life on it, I guess the world could benefit from it. From the same author who invented those fixes.

If I program something cool I'd use C and distribute that but I have the feeling you hate C (because of HLL programmers, like me sometimes). I can literally rewrite everything in assembly but if a bug appears it becomes very hard to track down (unless a dev unit, which I have never seen in my life). So I resort to -03 + inline stuff and strip debug symbols from GNU ARM (.s) assembly files and objdump the assembled stuff to see if they match the C logic code

Also you use your own disassembler (which I think it's OK and cool to create our own stuff), but then you lose compatibility with GNU ARM syntax (divided syntax and unified syntax). Otherwise perhaps a parser to export to them would be handy to backport disassembled objects from GNU ARM files.

just my 0.02 cents,but nonetheless pretty good work nocash

 

[nocash123]

I've sent the asm file with bug-list to Stephen Stair (the dswifi author), and he has already fixed some of the bugs, there is no official update released yet, but I think there's already some branch or fork or what it is called on github, containing the changes that Stephen has made recently.

For me it's versa, I feel better with ASM and quickly get scared in HLL and I can only guess what it wants say, especially if it's using those retro-kewl =--!^?|++ symbols instead of english keywords ; / but yeah, different people like different things, and some can probably understand HLL languages (or I would hope so).

Apropos... the Red Ink. Some years ago I've read that many people can get scared by certain colors - if that's a problem to somebody then I could change the color of the "UNKNOWN HARDWARE" text message! I would be just glad if somebody would dare test the dumping tool someday. Or if somebody knows somebody who could test it on a DSi console - please tell them about it!

For (dis-)assembler syntax, yup, I am usually brewing up my own syntax/dialect (and the dswifi port is using that syntax, which might prevent most people from using it). Aside from that all of the no$xxx programs contain options for selecting either nocash or native syntax, so everybody could use either one as desired.
Except... I have never heard of that new "Unified" ARM syntax, so that isn't supported... just checked what it's about, and appending the "S suffix to THUMB opcode does really make a lot of sense (in the old syntax MOV and MOVS having kinda opposite meanings in ARM/THUMB was always preventing me from trying write anything in THUMB code).

 

[Normmatt]

Updated the wifi code and dsi memory dumping tool:

New Wifi code contains a bugfix for WEP encryption, though WEP is still untested to my knowledge... or did anybody test it? And it's having a bugfix for handling wifi disassocation requests (which should be fixed in original dswifi library too, although the original lib doesn't ever seem to encounter disassociation, but if it would do so, then the bugfix would help; the original code did just ignore disassociation requests).

DSi memory dumper does now contain an extra function for dumping the I2C bus wifi calibration EEPROM, including for the overwritten word at index [F0h] and including for the unused bytes at index [300h..3FFh], which seem to be just zerofilled. The main work there has been to write an Xtensa instruction set assembler for being able to run custom code on the Wifi CPU. The EEPROM dumping code is tested/working on AR6002 (old DSi). It's also intended to work on AR6013 (new DSi which uses different GPIO pins for I2C bus). The only thing that won't work is dumping the EEPROM on AR6014 (3DS and New3DS, which, I think, it isn't yet even known if that consoles do contain an I2C bus EEPROM at all, least how to dump it).

To all hackers & crackers: It's all up to you: You can be the first person ever to discover new unknown hardware! Just run that dsdump.dsi tool on your DSi/3DS and dsdump.exe on your PC, and watch out for messages saying "UNKNOWN HARDWARE" in red ink. Hacking's never been simple! Or if it doesn't work for some reason, please let me know!

http://gbatemp.net/attachments/dswifi03-zip.72277/?temp_hash=97d672ff546b4322536bb2b1cdbec149

This file doesn't seem to load from sudokuhax for me... just goes to a black screen and isn't connected to my wifi...

 

[Shicky256]

Updated the wifi code and dsi memory dumping tool:

New Wifi code contains a bugfix for WEP encryption, though WEP is still untested to my knowledge... or did anybody test it? And it's having a bugfix for handling wifi disassocation requests (which should be fixed in original dswifi library too, although the original lib doesn't ever seem to encounter disassociation, but if it would do so, then the bugfix would help; the original code did just ignore disassociation requests).

DSi memory dumper does now contain an extra function for dumping the I2C bus wifi calibration EEPROM, including for the overwritten word at index [F0h] and including for the unused bytes at index [300h..3FFh], which seem to be just zerofilled. The main work there has been to write an Xtensa instruction set assembler for being able to run custom code on the Wifi CPU. The EEPROM dumping code is tested/working on AR6002 (old DSi). It's also intended to work on AR6013 (new DSi which uses different GPIO pins for I2C bus). The only thing that won't work is dumping the EEPROM on AR6014 (3DS and New3DS, which, I think, it isn't yet even known if that consoles do contain an I2C bus EEPROM at all, least how to dump it).

To all hackers & crackers: It's all up to you: You can be the first person ever to discover new unknown hardware! Just run that dsdump.dsi tool on your DSi/3DS and dsdump.exe on your PC, and watch out for messages saying "UNKNOWN HARDWARE" in red ink. Hacking's never been simple! Or if it doesn't work for some reason, please let me know!

http://gbatemp.net/attachments/dswifi03-zip.72277/?temp_hash=97d672ff546b4322536bb2b1cdbec149

Does the dsdump tool work in dslink? When I tried it I got a black top screen and white bottom screen (might be the other way around but whatever) and it didn't connect to the wifi. This is a "launch day" dsi (it came with 1.2 when I got it off ebay), so it might be interesting to see the hardware I guess

 

[nocash123]

Yes/no, it's working with wintermute's newest dslink version, but I am afraid that that version isn't officially released yet. And renaming it to boot.nds for directly starting it with sudokuhax... I didn't really try that (didn't have the sd-cart-slot attached to the dsi mainboard)... hmmm, tried now... and it really doesn't work. Attached is a new version that should work with sudokuhax (maybe also with the old dslink version). Ah, and WEP has been tested meanwhile too (and it's working fine).

And, I've started investigating the TeakLite II coprocessor: Disassembled the "aac.a" from the DSi Sound utility, merged it with the included function names from the COFF symbol table, and made some more or less working assembler for programming own Teak code & running actual tests on the hardware. The new dsdump version includes a function for dumping the Teak's memory mapped I/O ports (showing the port address, it's value, and it's values after writing 0000h and FFFFh). Parts of the I/O specs can be also extracted from the disassembled code/symbols, especially the IRQ and CMD/REPLY/SEMAPHORE stuff looks quite straight, the Audio/DMA part looks a bit more difficult.

EDIT: updated the dsdump.dsi tool (small bugfix on teak mapping, and changed arm7 org addr), the changed files are in dswifi05.zip. And for the other/unchanged files, see the old dswifi04.zip package.

 

[I pwned U!]

I just tried running the dsdump app, but it just locks up my 1.4.5 U DSi XL after loading it (with a black top screen, a white touchscreen, and no text). I launched it from Aura Launcher with Sudokuhax, renamed the app to DSDUMP.NDS, and set up a guest network with older, DS-compatible settings.

Do I need it to boot directly with Sudokuhax (as opposed to using a launcher)? Does changing the file extension from .dsi to .nds somehow cause a problem? I hope to get it working just in case I end up finding any useful hardware discoveries.

 

[I pwned U!]

I decided to try launching it directly with Sudokuhax by renaming it to BOOT.NDS, and I used an old 1 GB SD card instead of the 64 GB MicroSD card that I used yesterday, and now it launches. The top screen says:

NOCASH WIFIDUMP
CONNECTING

It does not do anything after this. I tried connecting my Surface Pro 4 to the guest network and running DSDUMP.EXE, but this is what I get:

dsdump by nocash 2016
.00000006
..00000006
..00000006
..00000006
..00000006
..00000006
..00000006
..00000006
..00000006
.255.255.255.255FFFFFFFF

Nothing seems to be dumping. Did I overlook something obvious? I also tried completely disabling the security on the guest network, setting it to 802.11b, deleting all of my other connections in the DSi System Settings, and setting the unprotected guest network as Connection 1, but these actions had no effect.

I am using the DSDUMP.DSI from dswifi05 with the DSDUMP.EXE from dswifi04.

Spoiler: Here are my current Wi-Fi settings:

 

[nocash123]

Yes, renaming dsboot.dsi to boot.nds and starting it via sudokuhax is fine.

The top screen says: NOCASH WIFIDUMP, CONNECTING - It does not do anything after this.

Looks as if it was started okay - but about a second later, it should display your network's SSID, and a bunch of MAC/IP addresses (once when it has found your access point & connected to it).
Do you have that guest network's SSID and WEP password entered in DSi's system settings? And, the system settings has some connection test option - does that pass okay?

I tried connecting my Surface Pro 4 to the guest network and running DSDUMP.EXE, but this is what I get: dsdump by nocash 2016, .00000006, ..00000006 .... .255.255.255.255FFFFFFFF

Yeah, my screen messages are looking like crap ; ) the 0006's are meaning that it's "busy/searching", the 255's mean that it "gave up" - but that's correct in this case (since the connection didn't work on DSi side).

In DSi system settings, you need the SSID and WEP key (or open network) configured as connection 1-3 (not 4-6).
Aside from the connection test, you could also try if the DSi browser is working (even if you have all other five connections disabled in system menu).
If the browser works, you try some homebrew with wifi support (like wintermute's "dslink" or whatever... I've no idea which other "NDS" homebrews are compatible with sudokuhax/DSi mode).

Do you know which wifi daughterboard you have in the DSi XL console? The newer "DWM-W024" board would be most interesting (for dumping purposes) - but I don't know if anybody has ever tested if the current homebrew NDS-based wifi code is working on it (theoretically it should be 99.95% compatible, but it might require some minimal changes, like something that sets a NDS wifi mode flag and disables DSi wifi mode).

 

[I pwned U!]

Do you have that guest network's SSID and WEP password entered in DSi's system settings? And, the system settings has some connection test option - does that pass okay?

All of the information was entered and it passed the connection test.

In DSi system settings, you need the SSID and WEP key (or open network) configured as connection 1-3 (not 4-6).

I deleted all of my other connections and set the open network as Connection 1.

Aside from the connection test, you could also try if the DSi browser is working (even if you have all other five connections disabled in system menu).

The browser is able to connect with the open guest network.

If the browser works, you try some homebrew with wifi support (like wintermute's "dslink" or whatever... I've no idea which other "NDS" homebrews are compatible with sudokuhax/DSi mode).

I downloaded the latest dslink release. The regular version launched, but did not connect, and the installDSiLink version had the following error:

DSi dslink installer.

Press A, B, X, Y to install.

Press start to exit.
writing block 1 of 5
failed writing arm7 code

I also tried launching installDSiLink with the supplied save for The Biggest Loser, but that just resulted in my DSi XL locking up with a red top screen and a green touchscreen.

Do you know which wifi daughterboard you have in the DSi XL console? The newer "DWM-W024" board would be most interesting (for dumping purposes) - but I don't know if anybody has ever tested if the current homebrew NDS-based wifi code is working on it (theoretically it should be 99.95% compatible, but it might require some minimal changes, like something that sets a NDS wifi mode flag and disables DSi wifi mode).

I did not remember off the top of my head, but according to a picture I took over a year ago, apparently it is.

Here is my current setup:

Spoiler

Could this other hardmod somehow be interfering?

I also set up this other mod for enabling game backup and save data backup/restore apps.

 

[ahezard]

This is running using the latest official release of nds-hb-menu https://github.com/devkitPro/nds-hb-menu/releases/tag/v0.6.0 by just renaming the DSDUMP.DSI into DSDUMP.NDS . On 3ds launching nds-hb-menu via the bootstrap.cia included on the release I have on the display :

NOCASH WIFIDUMP
CONNECTING
MAC : (the mac address)
...
SSID : (the SSID of the network)
...
CONNECTED
LOCAL IP : 192.168.43.169
SUBNET : 255.255.255.0
GATEWAY : 192.168.43.1
DNS : 192.168.43.1

But when I run DSDUMP.EXE on a PC connected to the same network nothing is happening. Is this the expected behavior on a 3ds?

I suppose it can also be executed this way on a DSI via sudokuhax using the latest BOOT.NDS 0.6.0

 

[nocash123]

The screen messages are looking fine. Once when starting DSDUMP.EXE on PC side, the console should additionally display "REMOTE IP : 192.168.xx.xx" (with the PC's IP).

What does that hbmenu thing do? If it's booting the ".nds" file in NDS mode (instead of DSi mode), then the dsi dumping stuff won't work (but even then: the "REMOTE IP" text should show up before getting hung).

 

[ahezard]

nds-hbmenu is developed by chism and wintermute, it runs srl from the sdcard. It does run properly files in dsi mode, including loading the arm7i/arm9i binaries. It should be equivalent to dslink.

 

[nocash123]

nds-hbmenu is developed by chism and wintermute, it runs srl from the sdcard. It does run properly files in dsi mode, including loading the arm7i/arm9i binaries. It should be equivalent to dslink.

Sounds nice. I didn't knew that there's a tool for booting dsi code on 3ds (or only heard rumours that certain people would know ways to do so).

Hmmm, I've just spent the whole afternoon on trying to install that "nds-hbmenu" on a japanese new3ds with some ninjahax exploit on some zelda cartridge. Essentially I've rebooted the console 20-40 times (hence the whole afternoon being gone). I've even managed to see the icon for nds-hbmenu twice, and then only got some "<japanese text>OFF<japanese text>" message after clicking that icon (supposedly wanting me to reboot the console another dozen times).
Well, I've already had some similar experiences with the 3DS in the past. Installing homebrew on 3DS just won't work out for me : /

For the DSDUMP.EXE issue, it might be just some problem at the PC/network side. Does the original dslink from wintermute work for you? It should theoretically work (or not work) the same, since it's more or less doing the same as my dsdump/asm code.

 

[Deleted User]

Sounds nice. I didn't knew that there's a tool for booting dsi code on 3ds (or only heard rumours that certain people would know ways to do so).

Hmmm, I've just spent the whole afternoon on trying to install that "nds-hbmenu" on a japanese new3ds with some ninjahax exploit on some zelda cartridge. Essentially I've rebooted the console 20-40 times (hence the whole afternoon being gone). I've even managed to see the icon for nds-hbmenu twice, and then only got some "<japanese text>OFF<japanese text>" message after clicking that icon (supposedly wanting me to reboot the console another dozen times).
Well, I've already had some similar experiences with the 3DS in the past. Installing homebrew on 3DS just won't work out for me : /

For the DSDUMP.EXE issue, it might be just some problem at the PC/network side. Does the original dslink from wintermute work for you? It should theoretically work (or not work) the same, since it's more or less doing the same as my dsdump/asm code.

actually there are dsi titles on eshop for the 3ds, so dsi code is supported even by nintendo. about hacking your 3ds- please go to https://3ds.guide (for a9lh) or http://smealum.github.io/3ds/ for just homebrew... on sys versions 11.2 and below you can get homebrew without any cartridges, just with music app