Difference between revisions of "Nintendo Zone"
| Line 56: | Line 56: | ||
|- | |- | ||
| 0x66 | | 0x66 | ||
| − | | | + | | 1 |
| − | | Unknown, always three in all dumps. | + | | Unknown flags, always three in all dumps. |
|- | |- | ||
| − | | | + | | 0x67 |
| − | | | + | | 5 |
| Padding? | | Padding? | ||
|- | |- | ||
Revision as of 03:22, 2 September 2010
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 was completely shutdown on Aug 27th 2010. 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.
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 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. 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. |
| 0x2c | 24 | Some retailer ID string includes the country, unknown what this is. "McDonalds Japan" |
| 0x44 | 32 | WEP key, if any. |
| 0x64 | 1 | Unknown, region related maybe? |
| 0x65 | 1 | WEP type: 0) Open 1) WEP-64 2) WEP-128 3) WEP-152 |
| 0x66 | 1 | Unknown flags, always three in all dumps. |
| 0x67 | 5 | Padding? |
| 0x6c | 2 | Unknown, was always 0x428 in all dumps. |
| 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. The NetFront version user agent was removed from the NZone bin, so it's unknown what NetFront version NZone uses. Linux/hostapd compatible box and a NIC supported by hostapd is required.
A DS Station/NZone exploit has been 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 also need a HTTPS forwarder/proxy, like httpsforwarder available in SVN. This exploit can only be used with html that is transferred over http. All html on the NZone server was moved to HTTPS. Although the NZone bin has root CAs for VeriSign, Thawte, Nintendo, and others, NZone rejects all certs not signed by Nintendo which includes VeriSign, Thawte, etc. The html for the index main and sub screens is transferred over https. However, the html for the main screen for the pages after the index,(main server for DS Station only) is transferred with http. The sub screen html is transferred with https, with the main server.
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.