Wii U network sniffing & strange speed alteration experience

[radioheadrule83]

I decided to use Fiddler2 to see if any information could be intercepted in Wii U communications. No nefarious intent. I was testing my phone to make sure third party apps weren't totally blitzing my data plan and killing my battery -- I figured the same technique would work on consoles.

To do this yourself, set up Fiddler (http://www.fiddler2.com) on a device on your network (ie. PC or laptop), then set up your desired devices (ie. Android/IOS device, or console) with proxy settings that match your computer's local IP address (on Port 8888 by default).

As all the Wii U's communication is SSL encrypted after initial handshakes, not a lot can be ascertained without successfully spoofing a cert for the servers... Fiddler does have SSL stripping capability, but you need to know what you're doing, I don't, and I suspect it doesn't work without knowing a little about what Nintendo's servers expect.



Connection tests
Performing a connection test just loads the page - http://conntest.nintendowifi.net - which as you can see is a basic html test page

System Update check:
When you perform a System Update check, the system sends nus.wup.shop.nintendo.net a SOAP request presumably compliant with an API-call named - nus.wsapi.broadon.com/GetSystemTitleHash
They're obviously checking the hash of the Wii U firmware against a hash on the server or something.

According to wsippel at GAF:

BroadOn is a strange company, founded by a former member of the board at ATI, the founder and former CEO of ArtX (designers of the Flipper GPU), and he was also responsible for developing the N64 GPU at sgi. He was also one of the inventors of GL, the sgi graphics API that evolved into OpenGL later. BroadOn develops different kinds of technologies, for example DRM (used for Wii), but also networking in general (very power-efficient "always-on" networking technology using an embedded MIPS CPU, maybe used for Wii), graphics and input technologies (motion based, probably Wiimote-related). Nintendo is their only customer as far as I know...

As Wii U Menu loads:
Connections are made to:

Code: [Select]

tagaya.wup.shop.nintendo.net
account.nintendo.net
nppl.app.nintendo.net
idbe-wup.cdn.nintendo.net
tagaya-wup.cdn.nintendo.net
ecs.wup.shop.nintendo.net

The headers sent to account.nintendo.net include these elements among others (I've removed stuff unique to my system, there's what looks to be a user unique ID on subsequent requests too):

Code: [Select]

X-Nintendo-API-Version: 0100
X-Nintendo-Application-Version:0023
X-Nintendo-Client-ID: xxxxxxxxxxxxxxxx
X-Nintendo-Client-Secret: xxxxxxxxxxxxxxx
X-Nintendo-Country: UK
X-Nintendo-Device-Cert: xxxxxxxxxxxxx
X-Nintendo-Device-ID: xxxxxxxxxxxxxxx
X-Nintendo-Device-Type: 2
The connections to ecs.wup.shop.nintendo.net involve the call ecs.wsapi.broadon.com/GetAccountStatus -- presumably to see if you're banned, and what state you're in - (are you playing a game etc)

discovery.olv.nintendo.net, api-eu.olv.nintendo.net and other connections send the headers:

Code: [Select]

X-Nintendo-ParamPack:
X-Nintendo-ServiceToken:
Idling on the home screen / Wara Wara stuff
there are repeated connections to idbe-wup.cdn.nintendo.net, olveu.cdn.nintendo.net, and api-eu.nintendo.net

When a Download starts
Downloads hit up ccs.cdn.wup.shop.nintendo.net with a GET request in the format /ccs/download/***/***
User-Agent: WiiU/PBOS-1.1

Miiverse traffic
Nothing was visible via the proxy at all

Getting Friend List
checks idbe-wup.cdn.nintendo.net

Nintendo eShop
Uses the account, nus and ecs sites. I was surprised that streaming a video yielded nothing during the proxy sniffs.



SOME OBSERVATIONS

Nintendo's servers do not tolerate strange requests from your home's WAN IP -- I've successfully been able to temporarily stop downloads on the Wii U by pinging ccs.cdn.wup.shop.nintendo.net and other nintendo.net addresses from another device on the network while the proxy routing is taking place.

AKAMAI cdn
Like PSN, Wii U uses the Akamai CDN service for cloud hosted downloads. What I found troubling and interesting is that I actually have a download of Batman: Armoured Edition going at the moment... connected direct to my router with no proxy, the Wii U was reporting a waiting time of 19 hours! Connected via proxy (my laptop) this came down to 2 hours after 10% complete. This does not make sense... I would have expected the time to increase if anything.

I would have suspected the estimate simply being wrong, but it was observably quicker. Strange. It might be something to do with the way I have my laptop manually configured with a DNS list. I've set it up for locality, speed and redundancy. I've got it configured that way because VirginMedia's DNS servers are heavily cache optimised (sometimes out of date), they flake out of service occasionally, and they intercept bad DNS calls - which I also don't like.... but why would that work? Maybe the DNS servers you use have an effect on geolocation discovery. Why they wouldn't just accept the system's CountryID instead, I don't know. Perhaps because people could take their consoles abroad or lie... If there ARE problems there, it could explain people experiencing slow downloads.

edit: now currently using VirginMedia 194.168.4.100 and Level 3 Communications 4.2.2.5 as DNS, getting the 2hr waiting time rather than the ~20hr, with no proxy involved. Bizarre.


A Test
If any of you are interested in helping me see if DNS is a factor in which akamai server you get directed to, you don't need to mess about with this Fiddle business...

Just open Command Prompt (start > run > CMD.exe) and type "ping ccs.cdn.wup.shop.nintendo.net" -- you should initially be resolved to an akamai server. For example, I am resolving to a1702.g.akamai.net in the UK -- curious to know if people elsewhere in Europe, NA and Japan get anything different?

[benjipwns]

Code: [Select]

Pinging a1702.g.akamai.net [204.245.6.170] with 32 bytes of data:
Reply from 204.245.6.170: bytes=32 time=464ms TTL=52
Reply from 204.245.6.170: bytes=32 time=371ms TTL=52
Reply from 204.245.6.170: bytes=32 time=312ms TTL=52
Reply from 204.245.6.170: bytes=32 time=517ms TTL=52US, Michigan.

[Don Flamenco]

good shit, gonna read

[Positive Touch]

sorry, i dont keep up with the bores book club

[archnemesis]

For example, I am resolving to a1702.g.akamai.net in the UK -- curious to know if people elsewhere in Europe, NA and Japan get anything different?

I get the same from Sweden.

[naff]

Resolves to same URL, different IP though.

[radioheadrule83]

Yep URL identity seems to stay the same. The IP I currently get is 90.84.54.50 in Liverpool, UK.

This is an Akamai server in the Netherlands by the look of it: http://en.utrace.de/ip-address/90.84.54.50

Code: [Select]

Pinging a1702.g.akamai.net [204.245.6.170] with 32 bytes of data:
Reply from 204.245.6.170: bytes=32 time=464ms TTL=52
Reply from 204.245.6.170: bytes=32 time=371ms TTL=52
Reply from 204.245.6.170: bytes=32 time=312ms TTL=52
Reply from 204.245.6.170: bytes=32 time=517ms TTL=52US, Michigan.

Looks to be based in Kansas - http://en.utrace.de/ip-address/204.245.6.170

For example, I am resolving to a1702.g.akamai.net in the UK -- curious to know if people elsewhere in Europe, NA and Japan get anything different?

I get the same from Sweden.

What IP do you get?