所有用第三方應用修改過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.


我們 (黑科技 API 團隊) 發現使用中間人技術將會被 N 社的服務器標記。

目前國內的什麼懶人版美版都是可讀中間人技術~
越獄和root插件的修改GPS坐標以及某模擬器的虛假GPS也屬於可讀中間人技術。
tsProtect插件也屬於中間人技術……
還有國外的 100% 命中技術以及 bot 等都一樣，不會倖免~

以下的 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.

大意是說  

所有站內附件皆會附上安全掃描報告
請會員查看純淨度百分比後判斷使用



相關檔案須知：
取得檔案前，請先詳細閱讀文章內容
避免不必要錯誤與誤會發生。
也可多參考文章討論樓層內容
了解附件檔案相關討論資訊。

【此文章部分內容隱藏中】    解除隱藏說明教學點擊下方 繼續閱讀文章 後
請仔細觀看文章內容 並依照指示進行下一步
最後完成解除隱藏後
系統會回到此文章自動顯示隱藏內容~

繼續閱讀