標題: 所有用第三方應用修改過GPS坐標的的都已經被 N 社標記了 [打印本頁] 作者: iTunes 時間: 2016-8-7 21:57 標題: 所有用第三方應用修改過GPS坐標的的都已經被 N 社標記了 05/08/2016 - 18:43 GMT+1 : Just another quick update, we have discovered that users utilizing MITM techniques may be getting flagged by Niantic servers. Please note read-only MITM is not affected by this flagging. We've confirmed this to the best of our joint abilities, if we discover anything else, we'll be sure to update, however, this should be not a cause for panic at this stage.
以下的 updates 我儘量節儉
The new struct, which we are calling Signature (previously Unknown6), authenticates every request made to the API. The structure of Signature turns out to be made up of a few more structures and values. We've managed to figure out what some of those are, leaving only a few remaining.
The integer unknown_10 is a hash generated by Pokmon Go. It is made by taking the user's current authentication ticket in protobuf format (app specific; different from their PTC or Google login token) and running it through a hashing function called xxHash32.
While our understanding of xxHash32 is not complete, from what we know, this hash function takes three values: the first being some data to hash, the second being a 32-bit integer to use as a "seed value" to start the function with, and the third being how many bytes from the data to use for hashing. In this case, the seed value has been determined to be 0x1B845328. This spits out a new 32-bit integer.
Now we take this integer and use it as the seed value to hash our current latitude, longitude, and altitude. The resulting 32-bit integer is unknown_10.
Similarly, the integer unknown_20 is another hash generated by the game. We take the current latitude, longitude, and altitude, as before, and hash it once again using xxHash32, with 0x1B845238 as the seed value. The resulting 32-bit integer is unknown_20.
We're not 100% sure about how to generate unknown_22, but it acts as a check to prevent users from simply copy-pasting API requests from the app. In other words, it prevents replay attacks. unknown_22 is time based and changes every few minutes.
Finally, unknown_24 (now known as request_hash) is an array of hashes, one for each function call being called via the API. (So, for example, getting the player info and inventory list in the same API call would result in two hashes.)
To generate request_hash, we start by hashing the authentication ticket with a seed value of 0x1B45328, but this time using the hashing function xxHash64. This becomes our new seed value for the remaining hashes.
Now, for each RPC function call included in the request, we take its protobuf data and hash using xxHash64 using the xxHash64 hash of the authentication ticket. The set of all these hashes is our request_hash.