I will explain how to see network traffic from Nintendo WII.There are other methods, but this has worked fine for me.
__________________________________________
Here’s what you’ll need before starting:
Nintendo WII
The USB-LAN adapter for the Nintendo WII.
An online videogame. I use Tatsunoko vs. Capcom
A wireless router at home with internet access.
A laptop with Linux(I use Debian5) configured as such: Kernel compiled with iptables support for network packet redirection, manipulation, etc, udhcpd installed, Wireshark installed, Connected via wirelessly to your home router.
An extra ethernet cord.
__________________________________________
Okay, here we go…
1. Connect USB-LAN to Nintendo WII
2. Connect one side of the cord to the WII, the other into your laptop’s ethernet port.
For my Linux laptop, the ethernet port is “eth0″ and the wireless card is “wlan0′. Now, 2 things need to happen. First - when the WII asks for an IP address on eth0, a DHCP server must be there to answer. Second - when the WII tries to go online(dns requests ‘n such), the laptop will have to do ‘em on the WII’s behalf with wlan0.
To accomplish this, I have a script that does this:
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.all.secure_redirects=0
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0
sysctl -w net.ipv4.conf.wlan0.accept_redirects=0
sysctl -w net.ipv4.conf.wlan0.secure_redirects=0
sysctl -w net.ipv4.conf.wlan0.send_redirects=0
sysctl -w net.ipv4.conf.eth0.accept_redirects=0
sysctl -w net.ipv4.conf.eth0.secure_redirects=0
sysctl -w net.ipv4.conf.eth0.send_redirects=0
set -x
iptables -F
iptables -F -t nat
ifconfig eth0 down
ifconfig eth0 192.168.99.1 netmask 255.255.255.0 up
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to `route -n|grep UG|awk '{print $2}'|tail -1`
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
udhcpd -f /root/wardriving/udhcpd_eth0.conf
(Note that PREROUTING line up there is all one line, not 2.)
And the contents of ‘/root/wardriving/udhcpd_eth0.conf’ is this:
interface eth0
start 192.168.99.2
end 192.168.99.254
option router 192.168.99.1
option subnet 255.255.255.0
option dns 192.168.99.1
option domain 192.168.99.1
option broadcast 192.168.99.255
Be sure that you’re connected wirelessly to your internet with your laptop before running the above commands. Also, make sure your router’s subnet is not the same as the one in the above udhcp config & ifconfig command. My router’s range is 192.168.1.0/24(meaning 1 - 254). See how the above I’m using “99″ where my router is using “1″? That’s important. Those three numbers my router is using “192″,”168″,”1″ cannot be exactly the same as the script’s first 3 numbers “192″,”168″,”99″. If they are, you’ll have overlapping subnets and chances are the WII won’t be able to get online because Linux won’t forward the packets back to the WII. It’ll probably just drop them.
Once all that has been verified, run these commands above as root. It will stay on “udhcpd (v1.17.1) started”.
Now, start up the wii and put it on Wired connection(if it wasn’t before):
Start up wireshark as root and have it monitor “eth0″. Now, make the WII go online with a videogame(or anything actually). I use Tatsunoko-vs-Capcom(TvC).
Now that I’m online, let’s see what was printed to the console from my script:
The “set -x” in my script is what makes the commands print out to the screen after “++” symbols like that. Notice that the WII asked for, and got, and IP because udhcpd was running and waiting for it.
Let’s look at wireshark:
See the DHCP request, Offer and ACK(acknowledgment)? The WII(as 0.0.0.0) sent requests, then a discover. The ARP is udhcp asking if anyone already is using 192.168.99.2. There was no reply. udhcp then did an “Offer” it to the WII. The WII sent out another request, udhcp did an “ACK”. Then WII did a GARP(gratuitous ARP) to let everyone on the network know that the WII has the ip now. See the DNS requests? The reason they’re not failing is because of the command in the script: iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to `route -n|grep UG|awk '{print $2}'|tail -1`
The part: `route -n|grep UG|awk '{print $2}'|tail -1` , is a fancy set of commands that get the IP of the laptop’s nameserver(usually this is the router’s IP). My router’s IP is 192.168.1.1, which is why you see that in the terminal screenshot. That is also why the next thing the WII did was ask where the router was. In this case, because udhcp is running on eth0 and asking as a router, when WII got the ACK - it also got alot of DHCP info, like the server to use for DNS - 192.168.99.1(see the config file for udhcp above). So that’s why the WII asked where 192.168.99.1 was, then it started that whole stream of DNSs to figure out where all the Nintendo servers were.
Now, the truth here is that udhcp doesn’t have the IPs of all servers in the world. That iptables command above, catches all DNS request(port 53) and sends them to IP my laptop is using, which is 192.168.1.1(my router’s IP). And of course, the router I bought at the store doesn’t have all the IPs in the world. It goes off and asks my ISP, Comcast, and Comcast goes off to ask ICANN. Then the whole thing comes back. Now, when a request from the WII at 192.168.99.2 goes to your router, it is changed to the laptop’s IP(192.168.1.10, you don’t see that in these screenshots because I’m watching eth0) and sent out through wlan0. Then when it comes back to the laptop, it is changed back to 192.168.99.1 and sent back to eth0. Sounds complicated? Luckly it’s all happening by itself because of: iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE.
Now here comes the SSL(encrypted) connection for Tatsunoko-vs-Capcom; letting the server(naswii.nintendowifi.net) know that I’m coming online. I assume naswii stands for North American System Wii. This URL is probably inside the system firmware on the gameCD.
When the WII comes online for any reason, it usually checks the weather within 30secs or so for the weather channel on the main screen that comes with all WIIs. Let’s see what wireshark saw for it:
See that “GET” request? It’s downloading a file called “short.bin”. Let’s look closer by right-clicking on it and saying “Follow TCP stream”:
So we see in the Pink at the top, ‘GET /1/049/short.bin HTTP/1.1′. We also see ‘Host: weather.wapp.wii.com’. This means that the file the WII is downloading is at http://weather.wapp.wii.com/1/049/short.bin.
Now, let’s fight a match online!
Punch and Kicking online!!!! The packets for this are just button pushes, boring. They’re UDP packets(which are faster than TCP logic, but not as reliable) and all I see are “FEEE…… FEEE…..” and some other random characters here ‘n there.
Not really interesting.
When I win a match however, interesting things happen!
Those hashes are there to prevent people like me from easily tampering with my online score. If it wasn’t for those hashes, I could type those URLs right into my browser and increase my score without fighting anyone. That would be bad. That’s why CAPCOM designed it this way. Notice the pid value “249190728″. That is unique to my online user “SMT@DDR”. You would have something different if you played this game online. I have not been able to figure out what those hashes mean. When this game first came out, I could knock myself offline immediately by using my laptop’s web-browser to submit that first GET request(the one without the hash). This is no longer true today. I don’t know why that was changed.
At the begining of this post, I showed an encrypted connection being made to naswii.nintendowifi.net. What if I wanted to see what that encrypted content contained?Here comes 3 more things. iptables rule to intercept SSL traffic(which is port 443), dnsspoof to catch all DNS request and return the IP of the laptop itself, so that all website requests go to the local laptop, where the program “webmitm” is waiting on port 80 and 443. webmitm simply forwards on anything “boring”. The excitement happens when traffic on port 443 comes through with something that looks to be the beginnings of an SSL connection. webmitm will use it’s own SSL-cert(that it will walk you through creating) instead of the original server’s cert in an attempt to do a man-in-the-middle attack; hence the “mitm” in webmitm.
I’m going to reboot the WII and reconnect; intercepting the process of the SSL connection:
Oops! Oh no! It didn’t work! Why not? Because the fake SSL key created by webmitm did not fool the WII console.
See the error “Certificate Unknown”? I cannot defeat that. Online bank websites and shopping websites that take your credit-card use SSL as well, and I could not get your info either. That is unless, you ignore the SSL error that your web-browser would give you.
Your browser will tell you there’s a problem and you could choose to ignore the warning. The WII, however, will not ignore the error and will immediate fail to connect.
Well, that’s all I have to say about WII network traffic. This works for XBOX360, Playstation3, and in fact any device that you can plug into your laptop’s ethernet port - even a 2nd spare wireless-router. That way, your laptop will serve like a modem to this 2nd wireless-router and anything that connects to it will ultimately have to come through your laptop’s “eth0″ for internet access. Think iPhone & iPad apps(wink wink).
As you can see, it’s not that hard for hackers to do things like this. Hence why game developers must use hashes to obscure the info going across the internet.
The reason the entire network traffic isn’t encrypted, I think is because Nintendo probably owns the SSL public/private key so any game that requests to go online will be handled by the WII’s firmware. If that key needs to change, it can happen by a firmware update - you cannot update the keys burned on a videogame CD. The reason the the fighting game packets aren’t encrypted, is because it would slow down game play to encrypt/decrypt. In a fighting game, even half-second slow down is usually too much.
The reason the traffic isn’t encrypted for the updating of the scores? I assume Nintendo only wants to deal with the initial connection of the WII to online servers. Leaving the game developers to do whatever they need to for their particular game - and any game developer won’t burn in permanent SSL keys because Nintendo might change the online fighting game server and then the game wouldn’t work. If the server is changed, the old address can still give a 302 redirect to send the WII elsewhere, but a hardcoded SSL key won’t work in that case with a different server URL. So the network-traffic is unencrypted, but hashed with unknown algorithms at the sensitive parts of the game(like updating battle-records & points) so people don’t cheat.
Owari desu! mina-san, sayonara!
Finished! farewell everyone! -^_^-
