Detailed info for those who are interested:
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 Pokémon 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.
