magical

Response hash is calculated as: sha1(salt + base64(data) + salt) Where base64 is the url-safe variant, and salt is still HZEdGCzcGGLvguqUEKQN. magical: 2 Game Freak: 0

So. As mentioned earlier in the thread, we now know how the checksum is obsfuscated, thanks to Jalada and nicholas on IRC. (That is, by xoring it with 0x4a3b2c1d.) By looking for the magic number 0x4a3b2c1d, i was able to find where in the ROM the encryption takes place, and to pinpoint the encryption algorithm. I'm sure you will not be surprised to learn that it uses yet another LCG, which i'm naming the GRNG, for "GTS Random Number Generator". (Terrible, i know. Also it sounds a bit like "grunge".) Ladies and Gentlemen, the GRNG: GRNG[n+1] = (GRNG[n] * 0x45 + 0x1111) & 0x7fffffff The data is encrypted by xoring each byte with the low byte of the high word of the corresponding GRNG value, like so: ciphertext[n] = plaintext[n] ^ ((GRNG[n] >> 16) & 0xff) The checksum is used to seed the GRNG: GRNG[0] = checksum | (checksum << 16) (Oh, and for anyone interested, the routine for seeding the GRNG is at 0x02211E60 in Diamond, and the routine for advancing it is at 0x02211E70. These routines are found in overlay 79.) So there you have it. I guess the floodgates are open. And now that i've figured out both the challenge-response hash and the data encryption, i'm kind of done with this GTS stuff. Honestly though, i'm a little worried about the SSL connection that takes place. Since we don't know much about it, and aren't even close to being able to spoof it, that means that when Nintendo eventually shuts down the official GTS server, all the fan servers will go with it. Enjoy it while it lasts. And, as a parting note, i'm interested in seeing where the Wonder Card spoofing research goes. Peace.

Wow. Great stuff here, LordLandon, Vlad. Poking around in the ROM, i figured out how the hash is generated. hash = sha1("sAdeqWo3voLeC5r16DYv" + token) Breaking the encryption is going to be harder. Some random observations: The data= parameter is base64-encoded The base64-encoded data always begins with "Sj". Does anyone else find that odd? Wait—it's even better than that: the base64-decoded data always begins with "J;". Not sure what that means, though. Perhaps it indicates how the data is encrypted. The data sent to post.asp is 300 bytes long. 8 bytes longer than the Pokémon data. The data sent to exchange.asp is 304 bytes long. 12 bytes longer than the Pokémon data. The data sent to post_finish.asp is 16 bytes long. The data sent to info.asp, result.asp and get.asp is 8 bytes long and, for a given pid, is the same for every request. But it is different for different pids. This means that a change in the pid must correlate with a change in either the encryption OR the data. Personally, i'm betting on the data. It also means that the hash does not factor into the encryption. If you post the same Pokémon twice, the data is completely different each time. The API is not very RESTful.