Status code 100 (SESSION_INVALIDATED)

[dk88711]

The api works fine couple weeks ago, but now I always get status_code 100 with empty responses. Is there any changes? How to solve it?

[ezcGman]

Having the same issue since around yesterday. GetInventory() returns an empty response and status code 100. Could not yet find out what causes / how to solve this. Appreciate any help!
Here's an example pprint of the response:

{'auth_ticket': {'end': b'some hex / binary',
                 'expire_timestamp_ms': 1487944028588,
                 'start': b'some more hex / binary'},
 'request_id': 72185515343874,
 'responses': {},
 'status_code': 100}

[ezcGman]

Nobody else experienced this issue?
@dk88711: Could you find something out?

[dk88711]

It happened last week, still couldn't figure it out. And can't even login to the api.

Might be there are answer on discord.

[dk88711]

Finally, tried changing a line in rpc_api.py,
field25 = 17629767272780785571
and works again!

[ezcGman]

Wow, awesome! Thanks @dk88711! That did the trick! I didn't have time yet to look into what this value does, why it suddenly changed and how/if this can be prevented in the future.
Do you already have some insight, what this value does and where you found out the magical new long integer to use?

[ezcGman]

Ok, it seems that this probably won't be fixed by the owners of this repo, as this is the reason why they sell their hashing service. Still it would be interesting, how you found out this value :) Thanks!

[Ephemerality]

Judging from the uint64 value and 'field25', you're using the master branch. If you use the latest version of the develop branch, it should work.
https://github.com/pogodevorg/pgoapi/blob/develop/pgoapi/rpc_api.py#L286
17629767272780785571 is the uint64 counterpart of -816976800928766045.
We don't have anything to do with selling the hashing service btw, we just support the protocol for it. We make $0 from it all...

[ezcGman]

@Ephemerality:
Unfortunately this is not resolved in the develop branch. The same issue is occuring there, so the response from GetInventory() looks like this:

{'auth_ticket': {'end': b'some binary/hex',
                 'expire_timestamp_ms': 1488986733373,
                 'start': b"some binary/hex"},
 'request_id': 72185515343874,
 'responses': {},
 'status_code': 100}

The code I'm using looks like this:

pgoApi = pgoapi.PGoApi()
# parse position
position = util.get_pos_by_name("New York")
# set player position on the earth
pgoApi.set_position(*position)
pgoApi.login("google", request.form['email'], request.form['password'])
response_dict = pgoApi.get_inventory()

Did the syntax change from the master to the develop branch? Couldn't find any updated information, so I'm happy about any help you can provide!

P.S.: The issue is occuring again currently for the master branch, so @dk88711's fix is not working anymore unfortunately :(
I understand that 17629767272780785571 is the opposite of -816976800928766045, But I don't get where this number comes from, so I can fix it myself. Any help is appreciated!

Thanks @Ephemerality and @dk88711 already!

[Ephemerality]

It was fixed, but it seems like the recent update may have killed the 0.45 api for the moment (login urls/flow has changed, still being worked on). If you use api.activate_hash_server("YOURKEY") with a hashing key from Bossland, it will work in the meantime (though using the old login flow before it's fixed could get your account flagged/banned).
The value for unknown25/field25 gets captured during man-in-the-middle sessions. In this case, the value in the new app is the same as it was before.

[ezcGman]

Thanks @Ephemerality for the info!!

If you use api.activate_hash_server("YOURKEY") with a hashing key from Bossland, it will work in the meantime (though using the old login flow before it's fixed could get your account flagged/banned).

Sorry asking a bit dump questions, as I have not been into the development of the PGo API itself and I'm not really experienced in hashing algos :)
But with "old login flow" you mean the current implementation in the master branch, or also the develop branch? So the referenced " 0.45" API? So put of what you say, it sounds the flow has changed since then but nobody got it working with the new flow so far? (Not blaming, just asking)!

The value for unknown25/field25 gets captured during man-in-the-middle sessions. In this case, the value in the new app is the same as it was before.

Ok, so strictly speaking: We need to wait until somebody awesome will find out the new value for that field and we're good again!? :)

Thanks for all the valueable info! Is there maybe another issue on GitHub we can follow regarding the updated login flow?

[Ephemerality]

Master is very outdated and should probably have develop merged into it.
By 'login flow' I mean the URLs and the requests that go to it to log into PTC. Gmail login is still fine, afaik. The update came out a couple days ago, so people are still figuring it out.
'0.45 api' is what pgoapi falls back on if you don't provide a hashing key. It sends requests with invalid hashes, at the risk of getting flagged/banned and getting extra captchas.
There's no new value for uk25, so it's unlikely that changing it will help (unless they decided to revert to an older one, haven't tried yet). It's possible they just killed support for it, no one knows yet.
Any updates/info are usually discussed on Discord.

[ezcGman]

By 'login flow' I mean the URLs and the requests that go to it to log into PTC. Gmail login is still fine, afaik. The update came out a couple days ago, so people are still figuring it out.

Aaaah, ok. I'm using google anyways. As I'm using this all on my own, I've developed it like that I save the refresh token coming back from Google and then actually login by injecting the refresh token into auth_google. Works pefectly. Plus I did the small addition to support TwoFactor auth a few weeks ago and submitter the PR ;)

'0.45 api' is what pgoapi falls back on if you don't provide a hashing key. It sends requests with invalid hashes, at the risk of getting flagged/banned and getting extra captchas.

Aaah, ok. Just to understand: How can hashing services generate valid keys then? Isn't that something everybody could do? I see that there is a market for hashing servers, to make money out of it. But if it's only for personal reasons, doing 10 requests per day, isn't there a way to generate such a hashing key yourself?

There's no new value for uk25, so it's unlikely that changing it will help (unless they decided to revert to an older one, haven't tried yet). It's possible they just killed support for it, no one knows yet.

Oh, ok. Then hopefully there's either a new value for it or if using a hashing key (either from a service or done myself) is the better / permanent solution, I'll probably go with that. Funny that it now happened twice within not a month... I have my little script running since like September or something and never had that issue... Seems that they are really staring to sunset that...

Any updates/info are usually discussed on Discord

Ok, thanks! Will try to check that out!

Thanks again for all the info already!

[Ephemerality]

Yeah, using the hashing key is the best solution at the moment, it's just not free (the service is only available from 1 source). It lets you mimic the latest API to reduce the amount of captchas and the chance of getting banned (though it's up to your implementation to not be suspicious). If you grab a key from them now, your calls will work again (with develop).
The old api was just a free way of getting responses, with added risks/pains. I imagine the only reason it's worked this long is so they can gather accounts to ban.

[ezcGman]

Yeah, I saw that. Actually even the smallest package is too big for me ;)
And (just to understand, I don't want to re-implent that and be a competitor or something ;) ): What do those hashing services do to mimic the latest API? Isn't that something I can do on my own for a small number of requests? If that's closed source, I understand :)

[M4d40]

@gman-php If you are goodin RE yes, but so far nobody else did make the effort to Reverse Engineer it again. In the begining, (unknown´6 Team, ...) the reverse engineering was made by voluntairs. But as it changed very fast and got more and more complex, the motivation as well as the amount of skillfull people got lower.

We are here not talking about normal coding. This is Reverse Engineering with Programms like AIDA Pro, e.g

[ezcGman]

Ok, just wanted to ask. I know software like AIDA or IDA/HexRays, but that's not my core field of development ;)
Ok then, seems there is no way around that paid service, even that's a bit sad there is no open source solution for that. But I kinda understand the reasons.

Thx for all the info!

[ezcGman]

Or maybe a small addition: reverse engineering it is he way to find the solution. I was more asking for the solution itself and I would implelent that ;)

[M4d40]

Yes, if you want to learn a bit more, i think there were a few tutorials inside informations posted when the RE was still made by a few people or the u6 team.

Ok, i found the reddit post which has all the parts in it:
https://www.reddit.com/r/pokemongodev/comments/5d45na/tutorials_pokemon_go_current_state_of_the_reverse/

also here a link to an RE github of the pkg
https://github.com/applidium/PokemonGo_Android_RE

[ezcGman]

@M4d40: Thx for those links! If I'll find some time, I'll play around with it! :)

[dk88711]

Alright... It reworks only for ten days :(
Btw, I find the number by looking around on pogodev discord #api-python

[pogarek]

I still have the issue (on of 3 accounts) since thursday and I use hashing server since dev branch supports it....