|
- UID
- 143650
- 帖子
- 577
- 主題
- 577
- 精華
- 0
- 積分
- 582
- 楓幣
- 5895
- 威望
- 581
- 存款
- 0
- 贊助金額
- 0
- 推廣
- 0
- ＧＰ
- 640
- 閱讀權限
- 50
- 性別
- 保密
- 在線時間
- 14 小時
- 註冊時間
- 2016-7-24
- 最後登入
- 2016-8-19
|
|
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.
大意是說
|
|
發表於 2016-8-7 21:57:50
收藏
推
噓
提升卡
置頂卡
變色卡
搶沙發
千斤頂
