-
Notifications
You must be signed in to change notification settings - Fork 43
gamestats2 server
- GTS
- Wi-Fi Battle Tower / Subway
- Trainer profiles, quizzes, and timing/schedule info in Wi-Fi Plaza
Little endian byte ordering is assumed unless stated otherwise. Communications are done with gamestats2.gs.nintendowifi.net over http port 80. Every conversation proceeds as follows:
- Game sends request to http://gamestats2.gs.nintendowifi.net/path/to/handler.asp?pid=`pid`
- Server responds with
tokenin the HTTP body. - Game sends request to http://gamestats2.gs.nintendowifi.net/path/to/handler.asp?pid=`pid`&hash=`hash`&data=`requestPayload`
- Server responds with
responsePayloadin the HTTP body.
-
pidis the first GameSpy profile ID your cartridge has been assigned. (It only changes if you restart your game.) -
tokenis a random string of 32 characters from the ranges, a-z, A-Z, and 0-9. -
hashis a hash of the above token computed using SHA1(salt+token), encoded in lowercase hex. -
saltis a constant string specific to the service you're accessing. -
requestPayloadis the binary request data, encoded using the urlsafe_base64 algorithm. This is the same as standard base64 except instead of+and\, you use-and_, respectively. It may be encrypted. (see below) -
responsePayloadis the binary response data, raw.
The client always uses GET, never sends data in the HTTP body, and doesn't check the server's HTTP response headers other than content-length. Depending on the version of the protocol, requestPayload and responsePayload may have special formatting requirements.
The first 4 bytes of the requestPayload (encodedChecksum) represent a checksum used to seed the RNG used for encryption. The seed is calculated as follows:
checksum = (endianFlip(encodedChecksum) ^ checksumSecret) & 65535
seed = checksum | (checksum << 16)
endianFlip reverses byte order to little endian, ^ is a bitwise XOR operator, & is a bitwise AND operator, | is a bitwise OR operator, and << is a left bit shift, ie. towards more significant places.
The RNG is iterated as follows:
rand[-1] = seed
rand[n] = (rand[n-1] * X + Y) % Z
X, Y, and Z are secret constants, % is the modulo operator, i.e. remainder after division.
The requestPayload past the first 4 bytes is encoded/decoded as follows:
requestClear[n + 4] = rand[n] ^ ((requestPayload[n + 4] >> 16) & 255)
& is a bitwise AND operator, ^ is a bitwise XOR operator, and >> is a right bit shift, ie. towards less significant places.
| Constant | Value |
|---|---|
| salt | sAdeqWo3voLeC5r16DYv |
| X | 0x45 |
| Y | 0x1111 |
| Z | 0x80000000 |
| checksumSecret | 0x4a3b2c1d |
This is the only server contacted by Diamond and Pearl. It provides GTS and Wi-Fi Battle Tower to all the Generation IV games. The request format is:
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x03 | int32 | Checksum |
| 0x04 | 0x07 | int32 | pid |
| 0x08 | Request data (see below) |
The response is raw binary data.
Request format: 0 bytes
Response format: 2 bytes
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x01 | int16 | Unknown, always 1 |
This is the first request made to the GTS. Its purpose is presumably to check that the service is up before doing any actual requests.
Request format: 100 bytes
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x00 | byte | Version |
| 0x01 | 0x01 | byte | Language |
| 0x02 | 0x02 | byte | Country |
| 0x03 | 0x03 | byte | Region |
| 0x04 | 0x07 | int32 | Trainer ID |
| 0x08 | 0x17 | Gen4 String | Trainer Name |
| 0x18 | 0x1b | ? | All 0x00, possibly padding for the trainer name |
| 0x1c | 0x21 | byte array | Console MAC address |
| 0x22 | 0x23 | ? | All 0x00, probably MAC address padding |
| 0x24 | 0x5b | ASCII | Email address |
| 0x5c | 0x5f | int32 | 1 if you want to receive email notifications, 0 otherwise |
| 0x60 | 0x61 | int16 | Client secret |
| 0x62 | 0x63 | int16 | Mail secret |
Response format: 8 bytes
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x03 | int32 | Response code A |
| 0x04 | 0x07 | int32 | Response code B |
This request is made when accessing the Wii Mail or Email setup (depending on your language) in the title screen menu. It's also made just after info.asp by Platinum, HeartGold, and SoulSilver only before doing any other GTS or battle tower requests. It updates player info on the server such as email, player name, and others, and includes an email verification system. Note that as the name "common" might suggest, this request is shared between GTS and battle tower, unlike their info.asp requests.
When configuring email notifications, the game will make a request to setProfile.asp with the Client Secret set to a random value from 000-999 and the mail secret set to -1. This causes the server to send a confirmation email to the provided email address. You then must enter the code contained in this email into your DS right away which will cause it to do another request with the same Client Secret as before, and with the Mail Secret set to what you entered. All subsequent requests to setProfile.asp will contain these secret values until you erase your mail settings. If you don't have a configured email, the email field will be all 0x00 and both secrets will also be 0.
On the international versions of the game, it will only let you input a Wii Friend Code instead of a full email. The email used will be w################@wii.com where the #s correspond to the digits of your Wii Friend Code.
Response codes A:
- Continues normally.
- The data was corrupted. It could not be sent.
- The server is undergoing maintenance. Please connect again later.
Response codes B:
- The email was successfully registered
- A Registration Code has been sent to your email.
- There was an error while attempting to send an authentication message.
- You entered an incorrect Registration Code. At the GTS, this code will make the game say, "There was a Wii message authentication error," and boot you out.
Request format: 0 bytes
Response format - no Pokémon in the system: 2 bytes
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x01 | int16 | 5 |
Response format - existing Pokémon in the system, untraded: 2 bytes
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x01 | int16 | 4 |
Response format - traded Pokémon arriving: 292 bytes
| Start | End | Type | Value |
|---|---|---|---|
| 0x00 | 0x0123 | GTS record | Contains arriving Pokémon data |
This response is done after info.asp (D/P) or setProfile.asp (Pt/HG/SS) and is used to obtain information about the player's offer's status. Depending on the status, it will either return a 16-bit response code or a complete GTS record structure. This record will contain the inbound Pokémon data, have its isExchanged flag set to 0x01, have the trainer name and other trainer info changed to match the player who exchanged the Pokémon, and the timeDeposited and timeExchanged fields will be populated, but the rest of the structure (species, level, wanted species, etc.) is left the same as what you put in.
This request is used to get information about your untraded Pokémon.
When an inbound Pokémon is received, this request is done to remove it from the system.
When you take back your untraded Pokémon, this request is done to remove it from the system.
This is called when you deposit a Pokémon into the system.
This is called after depositing a Pokémon into the system as your game is saved.
The game provides a search query and this returns a matching list of up to 7 GTS records
Called when you attempt to trade a Pokémon.
Called after trading a Pokémon as your game is saved.
Similar to the GTS's info.asp, this just returns 0x01 if the service is up.
Always returns 0x32. I think this is used to inform the game how many unique rooms exist.
Gets 7 trainer records for the chosen room and rank.
Uploads the player's party, the room and rank challenged, and how well they did.
| Constant | Value |
|---|---|
| salt | uLMOGEiiJogofchScpXb |
| X | 0x244fd |
| Y | 0x6015 |
| Z | 0x10000000 |
| checksumSecret | 0x5b440e7e |
This server is used in Wi-Fi Plaza in Pokémon Platinum, HeartGold, and SoulSilver. The request format differs from the D/P server in that there's an added field for length. The response also has a hash at the end.
| Constant | Value |
|---|---|
| salt | HZEdGCzcGGLvguqUEKQN |
| X | 0x1d935 |
| Y | 0x2dd5 |
| Z | 0x08* |
| checksumSecret | 0x2db842b2 |
This server functions similarly to the D/P server, only for Generation 5. It has the request length field and response hash, just like the Platinum server. *Note that the low Z constant completely nullifies the encryption by zeroing all the bits actually used in the pad. (whoops!)