Changes

== Client usage ==

== 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. The payload uses a checksum, modifying any of the payload causes sysmenu/NZone to not detect the beacons/NZone. 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.

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 [http://www.mcdonalds.co.jp/ds/how_to_play/ 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. The region is somehow determined by the special beacon, NZone is not region-locked. The client uses the correct URLs for the region somehow specified by the special beacon. Initially the client normally seems to use hard-coded URLs, but when it somehow detects "invalid" URLs or a perhaps a failed request the client seems to use URLs from the encrypted beacon 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 [http://www.mcdonalds.co.jp/ds/how_to_play/ 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 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.

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 [http://code.google.com/p/wmb-asm/wiki/NTFA NTFA] file format for graphics. Nintendo Spot supports other formats, one of the formats is GIF. Nintendo Zone supports NTFA, GIF, and PNG.

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 [http://code.google.com/p/wmb-asm/wiki/NTFA NTFA] file format for graphics. Nintendo Spot supports other formats, one of the formats is GIF. Nintendo Zone supports NTFA, GIF, and PNG.

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 function. The crypto is done Arm7-side.

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 function. The crypto is done Arm7-side.

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.

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.