Nintendo Zone

Nintendo Zone is the successor of DS Download Station, the latest revision in the Nintendo Spot series. The predecessor of Nintendo Zone in this series is DS Station, and the first revision in this series is Nintendo Spot. Although Nintendo Zone is the latest revision in the series, most game stores still use DS Station. This series downloads DS demos from an Internet server, rather than from a local DS host. Technical info on NSpot/DS Station is available here. Nintendo Zone locations have additional company-specific content. Companies can use this for information about the store/location, coupons with JP McDonalds won by quizzes, prizes, mini-games, etc. Nintendo Zone is available in Japan. Nintendo World Store in New York City used to have NZone, but they don't have NZone or even DS Download Station anymore. A few McDonalds test locations in Germany used to have NZone. That test service ended, the EUR NZone server seemed to be completely shutdown on Aug 27th 2010. However on July 5th the server is online again. Several USA Best Buy locations started a NZone test service in June 2009, see this. That test service ended, NZone is non-existent in USA since no test services exist in USA. NZone pictures here. EUR NZone screenshots here and here. Old USA NYC screenshots here. Japan screenshots: here and here.

Sysmenu displays this when NZone is detected for the first time.

NZone icon flashing in sysmenu when sysmenu detects NZone again after the initial detection.

NZone loading content from the server.

Hidden settings app menu for updating NZone.

Client usage

Unlike DS Station, the Nintendo Zone client is rigged to only connect to a certain AP when there's a special beacon with the payload encrypted in range. When the AP has the correct SSID and WEP key(WEP isn't always used), the client attempts to connect to the AP. The AP SSID and WEP key if any is contained in the special beacon in the encrypted payload. When the DSi is in range of the special beacon with the encrypted payload for the first time, sysmenu will display a message that you're in range of a Nintendo Zone. When you press the "Start" button, sysmenu boots NZone. The hidden DSi Nintendo Zone client will then appear in the menu, see the images to the right as well. After the initial NZone detection, the client icon always stays in the menu, it is never removed. When NZone is detected the second time in sysmenu, the icon and the icon on the strip which you can touch with stylus to select app icons starts flashing, and a sound constantly plays while in range of NZone. If sysmenu doesn't detect another NZone beacon for 10 seconds, the flashing and sound stops. NZone is not region-locked, the server region is determined by the special beacon.

The client is basically a NetFront browser rigged to only work with certain APs, and with the capability of booting RSA-1024 signed(same as WMB sign system) NDS software downloaded with https. DS Station seems to only support Nintendo's custom NTFA file format for graphics. Nintendo Spot supports other formats, one of the formats is GIF. Nintendo Zone supports NTFA, GIF, and PNG. The DSi NZone with the memo menu, can take pictures with the DSi cameras and save to the camera album. You can also draw stuff then save to camera album, and take screenshots of either screen at anytime(except when loading pages, sometimes memo menu is disabled by third-party sites) and save to NZone savedata. Screenshots can be viewed later via the memo menu, regardless if NZone beacons are in range or not. The NZone WFC usage notes state: "Photos, drawings or any other kind of images that you post via the Nintendo Zone can be viewed and downloaded by other users, and may be made public via Nintendo Zone or the internet. These photos, drawings or other kinds of image may then be copied, edited and/or posted by others." The rest is just "your images may be seen by a large number of people, don't post offensive material or copyrighted etc."

Beacon payload format

The NZone beacon payload is encrypted, the cipher and key is unknown. The cipher doesn't seem to be AES: the ciphertexts are very random, however when XOR is used on the ciphertext and cleartext that isn't very random. The cipher probably isn't a chain-block-cipher, as the XOR pad between two beacons match exactly for the bytes in the cleartext that match. The IV or key is based on the host MAC address: changing the sender MAC and BSSID caused DSi to not detect NZone. Normally beacon_type 0 is used, but when beacon_type 1 is used a different key seems to be used? This table is the format of the cleartext data, this was dumped by hooking the Arm9 IPX NZone beacon verification function. The crypto is done Arm7-side. That IPX arm7 function only verifies the NZone beacon, it's unknown what IPX function does the actual decryption. The NZone beacon code is contained in TWL SDK. DSi opera web browser automatically connects to NZone APs, all official DSi software automatically connects to NZone APs. NZone has a option to install a wifi config entry for the NZone AP, for old NTR SDK games run from cards. TWL SDK probably scans for beacons, checks if beacon_type is 0 or 1, and checks if the payload length is 0x70. If those succeed, it then decrypts the whole payload and verifies the checksum. When the checksum is valid, NZone is detected.

OFFSET	SIZE	DESCRIPTION
0x00	32	AP SSID.
0x20	10	Authentication parameter, required for connecting to the server. Server uses this to determine which third-party content to link to on the index page. First ASCII number char in this param is region, this is also used to determine which server to connect to. Regions: 0) JP 1) USA 2/3) EUR 4) KOR 5) China
0x2a	2	This u16 was always one in all dumps, unknown what this is. This isn't used by the client.
0x2c	24	Some retailer ID string includes the country, unknown what this is but it's not used by the client. "McDonalds Japan"
0x44	32	WEP key, if any.
0x64	1	Unknown, not used by the client.
0x65	1	WEP type: 0) Open 1) WEP-64 2) WEP-128 3) WEP-152
0x66	1	Unknown flags, always three in all dumps. Bits 0 and 1 don't seem to be used by the client. The client does use bit 2, testing setting bit 2 didn't help reveal what bit 2 is for.
0x67	5	Padding.
0x6c	2	Unknown, was always 0x428 in all dumps. Not used by the client.
0x6e	2	CRC16 over whole payload.

Versions

Version 3.0 of the DSi Nintendo Zone client was released with the February 9, 2010 update. Version 3.0 of the Japanese client was released on January 8, 2010. It is unknown what has changed since the initial version, v2.0. The server can check the version param the client sends, and if the version is old, the server replies with an error. The user-agent used by NZone v3.0 is "NintendoZoneViewer/1.1". Since the server can refuse to let the client continue since the client is old, the client may display a message "This viewer must be updated in order to use the Nintendo Zone service. Update now?". When you press the "No" button in the update dialog, NZone returns to sysmenu, and pressing the "Yes" button boots the settings app to a hidden menu to only update NZone. When updating NZone via this menu, the AP that NZone uses is used for updating. Like DSi Shop, Nintendo can force you to run a system update when the client was updated. The JP server forces you to update NZone. The JP server has a html sysmenu_update tag that forces you to update your DSi to 1.4.

Exploits

DS Station's web browser uses NetFront 3.3. Nintendo Zone v3.0 has the URL buffer overflow bug from NetFront 3.3 and DS Station, but htmlhaxx is impossible to use with NZone due to SSL. The NetFront version user agent was removed from the NZone bin, so it's unknown what NetFront version NZone uses.

A DS Station exploit was written by Yellows8. The exploit is only available on Google Code wmb-asm SVN. SVN web interface is available here, SVN URL available here. To use the exploit at home with DS Station, you need a Linux/hostapd compatible box and a NIC supported by hostapd. You also need a HTTPS forwarder/proxy, like httpsforwarder available in SVN. This exploit can only be used with html that is transferred over http. This DS Station exploit works perfectly on DSi with WMB ds-mode. The default embedded .nds in the exploit loads hbmenu from flash card, loading from flash card works perfectly on DSi in WMB ds-mode from DS Station nzonehtmlhaxx. You need the DS Station bin to use this exploit, but the bin will not be publicly redistributed due to copyright etc.

Test NZone haxx, crashed NZone. The EUR server bug exploited here was fixed a couple hours after beginning html injection attacks.

Server exploits

The EUR NZone server used to have the SSL renegotiation authentication gap bug. Initially, exploiting this with the redirection script on the server were being attempted. Then on the next day, attacks via HTTP TRACE requests to inject html into the server response to the DSi NZone client were done. Tests of crashing DSi NZone with nzonehtmlhaxx was done twice: first test was injecting htmlhaxx when the client tried sending a request to the redirection script for third-party content, the second test was injecting htmlhaxx immediately when the client first connected to the server. Both tests crashed DSi NZone perfectly. HTTP TRACE is never used by NZone or any web browser. Counting from the initial attack, Nintendo fixed this in less than 26 hours. Counting from when attacks with HTTP TRACE were started, Nintendo fixed this in less than 4 hours. The picture to the right is a shot of crashed DSi NZone, Nintendo fixed the bug before any payload was executed.

That EUR SSL reneg exploit was the only NZone servers hole in existence, there are no more SSL holes, there are zero http links on all NZone sites Nintendo and third-party, and there are zero NZone beacon data code buffer overflows. NZone haxx is completely dead.

Security

NZone is very secure due to SSL. NZone will abort when the server cert isn't signed by Nintendo. None of the NZone servers have http links, nor do they even listen on port 80 for http. HTTP downgrade attacks are impossible even when you can inject html.(nzonehtmlhaxx can be used when it's possible to inject html into the server reply, but that's impossible now.) All NZone sites use only relative URLs. When URLs that include https are used, they must use Nintendo's server otherwise NZone will refuse to load the linked page. NZone refuses to load linked pages that use http, or use https but don't link to Nintendo's site. With images, the path must be relative otherwise NZone will refuse to render the page. The NZone servers use a redirect.cgi script to redirect the client to the third-party server via a HTTP 302. The "url" parameter to this script can be arbitrary, the server allows any protocol https or http, and any domain. However NZone will refuse to load a http page from a redirection. For NZone redirection it only allows https to any site with cert signed by Nintendo.