ROM Hack Help editing Wi-Fi behavior

[Toad King]

I'm currently trying to capture SSL connections in plain-text from a Nintendo DS game. (At the moment, I'm just trying it with Metroid Prime Hunters but from what I've seen most online games use a similar library for wi-fi.) The easiest way to do this is to stub out SSL certificate verification, which allows me to place a MITM proxy server in between the DS and the Internet. I've made some progress but I have some questions hopefully somebody can answer.

* Is there any firmware functions used for wi-fi? Outside of connecting to a hotspot I'm unsure what the firmware is used for, if at all.

* Is there any previous research/successes in this?

* Is there any research on the DWC library used in wi-fi enabled DS games?

 

[Foxi4]

Stephen Stair from akkit.org, the author of dswifi, the WiFi library bundled with devkitPro did some extensive research of the protocol used by the system, you can find the documentation here. In addition to that, you can find some more information about various hardware registers at GBATEK, maintained by Martin Korth. I hope this helps in your investigation.

 

[FAST6191]

What Foxi4 said.

Most previous work on anything to do with the DS wifi, once homebrew was made anyway, has been more to do with custom tracks/levels, cheats and the like. As most of that was local (hence Mario Kart track swapping and pokemon cheating) and the wifi stuff was mainly a glorified lobby and multicast server (I think) it meant there was no real need to do anything from the hacker side of things. Sadly the leaked SDK and any subsequent leaks (the DS 3d, also any source code left in games*) did not have anything of note, not the SDK probably would. Naturally some people did try to sniff connections, I am sure you probably read the same post as myself somewhere that mentioned the encrypted packets and though I think at least some of it was plaintext after handshakes nobody even really went for injection; if you can cheat and modify the games then why bother.

*puzzle quest lacks it but I am not sure if any of the other lua using games (El Tigre make my mule and one other that I can not recall right now may be different, it was a Japanese music/rhythm/puzzle game I think). Edit, it was Theta.

On firmware. Not sure entirely. The firmware was updated to support wifi (indeed triggering the need for an update to the custom firmware which had previously used the space) but I am not sure how deeply it draws -- for most games and homebrew it would be the location of the saved settings but homebrew like DSOrganize ( http://www.dragonminded.com/ndsdev/dsorganize/ ) instead had the option to pull settings from saved data via DLDI and the like. Whether this speaks to the firmware being unnecessary or not remains to be seen, generally people were told to run a wifi using game but that might have just been so it could have settings to draw from.
You may find something of interest in http://fwnitro.caitsith2.net/ as it could fiddle with something wifi related (though looking at it now it seems more of a firmware activated cheat or something), not sure if creebome or Loopy's minimalist firmware even support wifi let alone have something of note in them.

Interesting work though, I shall await your results.

 

[Toad King]

Thanks for the responses. It seems most of the online hacks/cheats revolve around making small edits to game code, not necessarily network code.

Right now it seems games just read the wifi hotspot info from the flash memory and do their connections and sending/receiving from their code. While this means it should be possible to manipulate it and stub out cert verification, it all boils down to finding the routine that does that. In Metroid Prime Hunters I narrowed it down to overlay_0004 but there's a lot of code there to shift through, and a debugger like no$gba won't help since it can't do wifi last I checked.

 

[windwakr]

* Is there any research on the DWC library used in wi-fi enabled DS games?

I don't think so. I've looked for information on this before, and have never been able to find anything.

Although, the Wii version of the DWC SDK is floating around out there. I bet they're very similar in how they work, so you could probably gain a lot of information from it.
Can't link to it for obvious reasons, though. But a filename should be OK, right? I mean, ROM filenames are all over this site. It's contained in a file called "SDKs.rar".

 

[Toad King]

I don't think so. I've looked for information on this before, and have never been able to find anything.

Although, the Wii version of the DWC SDK is floating around out there. I bet they're very similar in how they work, so you could probably gain a lot of information from it.
Can't link to it for obvious reasons, though. But a filename should be OK, right? I mean, ROM filenames are all over this site. It's contained in a file called "SDKs.rar".

I'm already able to get SSL plaintext dumps from the Wii, thanks to all communication encrypted and not being handled by IOS on there. A lot of strings in the DS cart seems to suggest they use a very similar if not identical protocol but I'm trying to see if there are any differences.

 

[Toad King]

Well, got a bit farther. Took me forever to build a version of DeSmuME that I could debug but I know that MPH reads the text portion of the SSL cert in the ARM code at 0x020a4d80. Which is weird, since that code isn't in any of the overlays. Which means that the network code might be split up a bit more than I originally thought.

 

[Coto]

.

 

[Toad King]

I think you read this topic wrong; this is for DS SSL encryption, not Wii. There are already ways to bypass SSL on Wii since it's done through IOS, but on DS it is hardcoded into the ROM. This isn't cracking over the air. SSL is designed to be resistant against those kinds of attacks.

 

[Coto]

oh, then don't mind me. I prefer to decypher what the game does with raw data rather than ssl encryption

 

[Toad King]

Just tried a very crude attack: Running DeSmuME until it receives the SSL packets and pausing it, then rummaging through a memory dump.

Guess what I found?

POST /ac HTTP/1.0
Content-type: application/x-www-form-urlencoded
Host: nas.nintendowifi.net
User-Agent: Nitro WiFi SDK/1.0
HTTP_X_GAMECD: AMHE
Connection: close
Content-Length: 320

action=bG9naW4*&gsbrcd=QU1IRTNjcDMya2M*&sdkver=MDAxMDAw&userid=MDQ5NzgxOTg4MzgyMQ**&passwd=NTYz&bssid=MDBmMDFhMmIzYzRk&apinfo=MDA6MDAwMDAwMC0wMA**&gamecd=QU1IRQ**&makercd=MDE*&unitcd=MA**&macadr=MDAwOWJmMTBjMzg3&lang=MDE*&birth=MGMwYw**&devtime=MTQwMzA3MjM0NzIx&devname=RABlAFMAbQB1AE0ARQA*&ingamesn=RABlAFMAbQB1AE0ARQA*

HTTP/1.1 200 OK
NODE: wifiappw1
Content-Type: text/plain
Content-Length: 287
Date: Sat, 08 Mar 2014 04:47:38 GMT
Connection: close
Server: Nintendo Wii (http)

challenge=R0tUMTU5OEk*&locator=Z2FtZXNweS5jb20*&retry=MA**&returncd=MDAx&token=TkRTZVNnaFNEOGowdTB5ZlYwdlhNV0Y1OTRhQzBJWUc0UkVVM1RMWTZQNnJYUlRLbHpqcmw2akxHUVZpWGhXTjFmZlBkeWhEN2JpbHlyU2dZckVodWh1a0ZIRGlpczVleFBHcXRsYm5qUU5FaEZwaXByWVBxQXFPQkJGeVJrNEdqMGQ*&datetime=MjAxNDAzMDgwNDQ3Mzg*

Very naughty Nintendo, not clearing your sent data after sending it (and probably not clearing your receiving data altogether; the unencrypted conntest.nintendowifi.net response is also there at a different offset). Now I know where the SSL Root CA is read, where unencrypted post data is stored, and decrypted response data is stored. Also, the protocol looks nearly identical to the one used on the Wii, which is a relief. Now to get that cert verification out of here.

EDIT: Dang, just noticed the POST query is incomplete. Well the size ends up about the same as the queries on Wii games.

 

[Toad King]

Well, I didn't find exactly what I was looking for, but I found an even simpler fix for SSL logging.

The Nitro WiFi SDK will decide on how to handle a request based on its protocol. That, plus unlike it's Wii counterpart, nas.nintendowifi.net accepts communication over the standard unencrypted HTTP port. (No idea why, maybe earlier WFC games accessed it over plain-text HTTP?) Simply editing all the references to https://nas.nintendowifi.net with http://nas.nintendowifi.net and adding an extra null byte at the end of the string allows you to get plain-text dumps of all the traffic to the authentication server. I almost feel disappointed that it was this easy. (Kudos to Vetle in this thread on the Project Pokemon forums for finding that out years ago: http://projectpokemon.org/forums/sh...bsite-research&p=108778&viewfull=1#post108778)

Here's a patch that implements this for Metroid Prime Hunters (USA): http://save-nintendo-wifi.com/mphunters/MetroidPrimeHunters(USA)-NoSSL.xdelta
I'll be making one for Mario Kart DS as well, but I don't have any DS games with WFC outside of those two. There's also the issue of Nintendo's download server in games like WarioWare D.I.Y., which don't seem to work with plain HTTP. The custom servers in the future might be able to, but we need dumps of current data on them beforehand.

 

[whatupdog]

Some recent work on Monster Hunter Tri SSL research (I know it's for wii and not ds but it may help):
http://www.sufami.org/thread.php?board=8&thema=23&page=1

You might be able to decipher something useful there, or make some contributions.