Nintendo WiFi Protocol Analysis

[AngelSL]

My setup is a Linksys WMP54G PCI Wireless Adapter, using modified drivers, acting as a soft access point. Packet logging done by Wireshark.

So far, I have analyzed these stuff:

• The client (DS) and server do a SSL Handshake while connecting.
  
• Most data (except data about IPs/ports) is encrypted in an unknown encryption as of yet.
  
• Data about IP/Ports is transmitted via UDP, not TCP
  
• The protocol is the same even if you're using Plat or D/P (That's what it seems, please correct me if I'm wrong)
  

That's all I managed to recall (I forgot to save)

[Sabresite]

If it uses SSL for the handshake, it is possible that it uses SSL for the encryption as well. If they are not stupid, they probably used an algorithm that has a public and private key where the DS has the public key, and the server has the private key. This would make it very difficult to decipher the data coming/going from the server.

[AngelSL]

You're exactly right. Most data is SSL'd actually.

[coolbho3000]

Won't SSL make it pretty much impossible to reverse engineer?

I didn't think Nintendo would implement something like SSL, especially after you consider their laughably weak protection on wonder cards.

[codemonkey85]

I'm sorry if this is a bit off topic and/or in the wrong place, but with this kind of research, is it possible (if it ever were reverse engineered) to use a typical PC with proper hardware to access the DS' wireless communications directly? Perhaps even tricking a Pokémon DS game into thinking it was connecting to a Wii?

There would be uses for that.

[Sabresite]

Codemonkey you are entirely correct.

Angel: I had an idea while sitting on my thumbs crying about SSL. Lets start by acquiring the information that is available to us, which is in the ROM.

We can get the private key to the WFC information, and the public key to the client. At the very least this will allow us to emulate the client.

Once we have the private key to the incoming WFC information and the public key to the outgoing WFC information, we can use “expected" packet data to brute force the other part of the pair. How you ask?

We sniff the packets for a trade where we know the information being sent from both sides to the WFC server, and what to expect upon incoming on both sides.

You may say, well that’s impossible since we don't know the packet structure. It isn't. We already know what 236 bytes of the packets should be when decrypted, for both sides. We can use brute force (yes it will take a while, and quite a few people), with the same block information, until we "find" all 236 bytes.

Next we take the assumption that the keys are dynamic and based on some type of session id or other. Once we have the keys, we will need to tie it into the private-key/public-key algorithm used by the Nintendo DS and the session id that is transferred (or Mac Address, or Wifi Code, or Friend Code, or Trainer Information.... whatever is used).

And of course, if this ends up taking too long from a practical stand point, we can always emulate the DS only.

[codemonkey85]

This isn't my strong point by any means, but if there is any way I can help with this, count me in! It means possibly adding a feature to PKMDS (or Pokémod if you're into it) to directly access a DS save file through normal DS wireless functions.

I have a dream where, someday, someone could take their retail cart of DPPt, connect to their PC using DS wireless communications through the game's menu, and use PKMDS to organize their Pokémon. Afterward, everything could be saved right back to the cart.

Also, maybe the NO$GBA developer(s) could use this information to add wireless communications support to their emulator. I dunno.

[AngelSL]

Any progress?

I can't do anything but sniff and look at the SSL encrypted data fly by right now, so...

EDIT:

I just had a lightbulb!

Since the server does the key exchange via network, perhaps we could grab the key from that packet.

Sabre, you're the only one I sent the pcap to. Look into it.

[Sabresite]

Angel, it uses SSL the same way a web browser would. It receives a certificate and other crap, generates the numbers, receives a number, and then generates the encryption key pair.

If we can mimic that, we can figure this garbage out.

[codemonkey85]

I thought of another neat use of this protocol, if it does get figured out. See this post, but to sum it up, I thought it would be rather neat if the DS could be connected to a PC, and the PC application could mimic that DS (or any DS) and log onto the Global Terminal, resulting in some extra control over your DS' communications with Nintendo's servers.

Can you say "user maintained battle servers for retail DS games"? Or user maintained trade stations? Just throwing ideas out there.

Edited April 29, 2009 by codemonkey85

[derrick]

good ideas code monkey that would be awsome but if this ever gets figuerd out i wonder what kind of hardware some one would need to use that kind of program i mean besides wifi

[codemonkey85]

I don't know, but I know people have hosted DS game demos from their PCs using certain Wi-Fi adapters and/or drivers. So it has to be doable.

[derrick]

yeah so someone might be able to host pokemon events two from there computer

that would be sweet i could never figuer out how to get my deoxys game stop event cart to work so this would help a lot

[coolbho3000]

I don't know, but I know people have hosted DS game demos from their PCs using certain Wi-Fi adapters and/or drivers. So it has to be doable.

I've done it in Linux before with my Nintendo WiFi USB connector, actually, to send signed demos to my DS (unsigned stuff only works on a flashed DS). I don't remember which programs were needed for it, but the USB device's Windows driver could not be utilized for Wireless Multiboot.

DS Download Play protocol, from what I understand, is relatively simple. The communications Pokemon uses would be more difficult to reverse engineer.

[codemonkey85]

The communications Pokemon uses would be more difficult to reverse engineer.

Which is why I'm relying on the people who know how to reverse engineer such things!

In all seriousness though, if there is anything I can do to help figure this stuff out, I would be happy to help. It would be a wonderful addition to my software (which I have recently begun a major overhaul of).

I know Sabresite had some security concerns about wireless data transfer, but how awesome would it be to wirelessly interface with your retail Pokémon game between a PC and a DS for save file editing?

[derrick]

yeah that would be the best part for me the wireless save editing

[evandixon]

This would greatly help those who do not have AR, or a flashcart.

But, I don't think this is even practical. I mean, trying to de-crypt SSL.

[Jiggy-Ninja]

This would greatly help those who do not have AR, or a flashcart.

But, I don't think this is even practical. I mean, trying to de-crypt SSL.

We don't need to crack SSL the hard way. All we need for meaningful communication is the DS's private key and the Nintedo server's public key.

We have access to the DS, and the ROMs used for games, so it should be possible to extract that information somehow.

Though I doubt that any full fledged save editor could be made using just Wifi without a flash cart or AR. The best you might be able to do is spoof trades or battles.

[codemonkey85]

Though I doubt that any full fledged save editor could be made using just Wifi without a flash cart or AR. The best you might be able to do is spoof trades or battles.

Well, theoretically, if you have the ability to imitate the Wii's protocol for connecting to a DS, you could at least access and modify the entirety of your PC storage system, since that's what Pokémon Ranch does.

[AlbinoDrow]

If you can spoof trades and make the DS think its trading with another DS when its really on your computer, then I'm sure you can make it trade pokemon stored on your computer made by pokesav or the like.

Or even pokesav genorated pokemon getting put on a Pokemon Ranch emulator of sorts and make the DS think its getting pokemon off ranch when its just your PC. That would be great for anyone without an AR (or sick of only being able to use the AR to get a few genorated pokemon at a time), or even people without a flashcart.

I have a router in which I know how to log into it, I have a DSi with Diamond and Platinum, though I dont know if I have anything to grab packets and such nor a Wii to see if I can get Ranch Packets. Though if I can help in grabbing them I'd be more then willing! Heck, with this I could have entire boxes of pokesav genorated pokemon, or even legit pokemon I want to store all on my PC and ready for possible editing, uploading, etc!

The only thing is how do we get the Ranch emu to beleive the pokemon game is able to receive such pokemon. There has to be like a name thing, and if we can edit that too we can use one grand PC Ranch for all our pokemon games. Fast transfers from Diamond to Plat in full boxes would be available if we can do it though, not to mention the ability for more people to upload pokemon to their pc, get the .pkm file and upload it to the site in cases of events.

[codemonkey85]

The only thing is how do we get the Ranch emu to beleive the pokemon game is able to receive such pokemon.

Well, if we write a program that tricks the DS into thinking the program is Ranch, we are in control of all of those checks, since it is Ranch that performs them. Therefore, we can just choose not to code it like that.

That is assuming it really is possible to even do this.

[AlbinoDrow]

That would be awesome and make life easier for retail cart owners to mod pokemon without an AR, or even load pokemon. (like me)

How would I be able to help with this? I have a modem, router, DSi, Platinum, and Diamond (which is my hack game), though I dont know how I would get the packets of the data being sent and recieved.

[Andy]

Hi guys,

A few musing on this subject. If we're to assume that the connection is using SSL/TLS, which it seems that it is, then we have to ask a few questions about the configuration of public / private keys.

1) Which end has the private key?

Is the private key stored on the DS itself or on Nintendo's server. Both have pros and cons as far as Nintendo is concerned. If the private key is on the DS, then the Nintendo server can be sure that the information it's receiving is from the DS and nothing else. And if the private key is on the Nintendo server, then the DS can be sure that it's conversing with the Nintendo server.

2) Is there just one public / private keyset?

Highly highly unlikely. Each DS would have a unique key with the corresponding key located on the Nintendo server. This would allow Nintendo to differentiate between DS consoles based on the keyset.

3) Assuming the above, when is the keyset generated?

Easy question. The keyset must surely be generated the first time you connect to the Nintendo WiFi system and then the DS's key stored on the cartridge (or possibly internal memory). Start up Pokemon, go into "Nintendo WFC Settings", then "Options", then "System Information". Here we have the MAC address of the DS (which could be used as the key password) and the "Nintendo Wi-Fi Connection ID", which I would say is linked to the key on that system.

If you erase the connection settings, the next time you try to connect to the Nintendo server, it will regenerate this with a new number (and also erase your PalPad friends).

4) How do we intercept keys?

We need to try intercepting traffic at the stage when you first connect to the Nintendo server and see what flies across. This would provide some information as to how it works.

There is also an option called "Transfer Nintendo WFC Configuration" which is used to transfer the configuration from one DS to another. We could also try intercepting this traffic to see what we can see.

However, it's worth noting that it is possible that the keys themselves are not transmitted in plain text, but instead encrypted using previously established master key. In which case... bugger!

Andy

[Andy]

I has a quick look into this today, using a slightly different method. I was still using Wireshark for the packet-logging, but I was using a APR spoofer to intercept communications between the DS and router.

With this in place I went into the Global Trade Station in Jubilife City, connected to the GTS, deposited a Pokemon for trade and then searched for a couple of other Pokemon.

This fired off a load of connections to various servers owned by Akamai Technologies (a company that, amongst other things, provides network services for MMO games and such).

I haven't done any analysis on this yet as I'm having trouble getting Wireshark to give me any reasonable data beyond the packet headers?!

But, I didn't notice any UDP data flying around, which is different to AngelSI's findings. AngelSI: did we follow roughly the same procedure or were you trying to trade using the normal wireless communications (i.e. a non-GTS trade)?

If not, are you treating lower-level protocols such as ARP and DHCP as UDP. Anything relating to ARP, DHCP or ICMP can be disregarded - it's all standard connection and address negotiation stuff.

Andy

[Sabresite]

The WFC is completely different then the GTS. Using the GTS is like searching through a website, its kind of weird.

With the WFC, its fairly straight foward:

The DS cartridge has a certificate for SSLv3, and it uses some type of information to salt a big number which is sent to the WFC server. A number is sent back to the DS as well. With these numbers, a private key and public key are generated on both ends. The public key the DS has is to encrypt the information that it sends. The private key is to decrypt the information that it receives.

Getting that certificate and salting algorithm is already in the ROM, somewhere.