If that's all so, could the PoGo devs simply enforce some type of device authentication to 'shut down' these APIs, or otherwise take different steps to make unofficial APIs less compatible/more difficult/effectively impossible?
That's impossible. If you try this you'll either have a bunch of false positives or even more likely a patched api around 12 hours later. Never underestimate the dedication of botters. There are multiple headless WoW Apis around for 10 years now and Blizzard isn't able to close them out.
I sincerely hope that they don't do that, or at least not 'shut it down' completely. The reason is that there are some use cases for this API which don't involve cheating, for example the many different Pokemon Go server status pages including one that I built myself [1].
In those blocks could be anything, detailed gps co-ords, device details, there's a fair chance they can ban all these API users at the push of a button based on whatever's in those blocks.
Everything else is unencrypted - sent back and forth using the protobuf format, the formatting of the protobuf's were dropped on pastebin a few weeks ago.
It seems that the devs are firefighting scalability issues atm, and it would make sense that unsanctioned 3rd party APIs will be targeted Soon™ but probably heuristically.
They're also in violation of the ToS I believe, but bans in their previous title came in waves, and I've not heard of any pogo banwaves yet.
Only if they signed up to it ;o)
If you're reverse engineering an app and someone else is using the device with the app installed there's no need for you to have submitted to a contract of obligations to the app provider. Depending how you orchestrate things the signee might be guilty of giving their credentials away. It would probably come in as unauthorised access of a computer system with respect to USA/England&Wales legislation.
See: https://www.fknsrs.biz/blog/reverse-engineering-pokemon-go.h...
All that can be spoofed tho, and whether they have the resources to apply that level of analysis to XXX million users is questionable.
* Just a working 3 step tracker
* Gym high scores
* Display nicknames of gym pokemonThat's rife for abuse. It would require a "reporting" function; a moderation team; resolution practices; human intervention; a "scoring" system to judge repeat offenders... on and on and on.
Please don't ask for that. I don't need to see that the gym located at a church being championed by the Pokeman nicknamed "Gaylord."
The notorious Westboro Baptist Church was being held by an apparently LGBT friendly account called LOVEISLOVE recently, which I thought was quite sweet tbh.
For number 3, it would depend if that data is sent by the server. I'm guessing that it isn't
The Fort/Gym data from the map request returns only the top cp pokemon in the gym. But the actual gym data returns the actual list of member pokemon, which might also include the nickname (POGOProtos definitions include it, but would need to make an actual request to confirm).
So maybe!
The speculation is that this was done deliberately to ease server load.
Also, does this API depend on running on Android?
Most of the important stuff is certainly done server-side, like determining whether a Pokemon appears at coordinates x,y or not (though my guess is the client is tasked with this, and then says "Hey server, I'm showing there should be a Pidgey at x,y, I'm gonna try to catch it." The server confirms by running the exact same deterministic check on x,y, then says "Yep, I see it too," or "No, you're a filthy liar, Joey.")
But for the actual "I caught it" or "I missed it," unless the exact user input is sent to the server, and then the server simulates the projected path of the throw, the client seems like it gets to say that. So perhaps the client could actually say "I hit it perfectly," and the server just says "Well if you say so."
Checking if a throw resulted in a capture server-side would be weird, I don't see why it couldn't be done on the client. It could be querying for the players inventory, to see if they have enough pokeballs? It'd still be better to just sync that once before the fight...
My best guess is, the conditions for a Pokemon running away involve something only the server knows. A weak example: maybe it considers other players in the area - pokemon might be more likely to run away if the area is too crowded? So every once in a while the client asks the server how many players are there nearby, or something.
I don't know about the second question.
It's terribly buggy and clearly totally insecure. They can't keep up with the server load and nobody had a conversation before the game shipped about protecting against abuse from people reverse engineering their APIs. This is a joke.
There should be some minimum level of quality regardless of the fact that if you shove crap through the door people will buy it.
that's true on so many levels. even the gameplay is bonkers, both because it is way removed from the actual pokemon lore and themes but also more importantly because level caps and no mid quest but just gyms block every casual player from the only player interaction available
I'm blind and would be interested in there being an accessible version, but it's just not ever going to get made. Seems like pokestops or whatever they're called could be represented as a plain native list, with Maps integration for voice guidance to the point if you don't already know where to go.
And it looks like the in-game action is fairly simple. Could probably render it with positional audio, which has been done in accessible games for at least a decade [1]. I wear a bone conduction headset, so I could listen to the audio cues overlaying my actual environment. It may be hard to model the catch mechanics, but I assume they aren't too much more complex than "center one thing on another and throw," which again audio games have pretty much figured out.
Seems like a fun project. Might give it a shot if I can stomach the risk of getting randomly shut down one day.
Edit: Speeling
1. http://audiogames.net Kind of an annoyingly bad site in some respects, but useful info all the same.
On the other hand, this does sound like a fun project.
The two major categories of cheatifying in Ingress are falsifying one's location and multi-accounting. There's precious little that can be done about the latter, so Niantic focus on banning players that appear to be "spoofing" their location.
Given the wealth of different devices and playing scenarios, immediate detection of GPS spoofing is infeasible. Things like WiFi router locationing idiocy (or even just dodgy GPS antennae) play havoc with the utopian dream of perfect positioning every time. If a player performs actions seconds apart that are separated by thousands of miles then the game temporarily ignores them, but after some time in the naughty corner they can resume play.
Hardy spoofing detection instead depends on longer-term profiling. Ingress has a similar API to Pokémon Go – JSON chunks (rather than protobuf) over HTTPS, most fields out in the open – but each request from the app includes a monolithic "clientBlob" containing device characterisation. The format of this has been (presumably) reverse-engineered by a few hardy souls but it is certainly closely-protected Niantic knowledge. We could safely assume that it's a proprietary blend of signal strengths, gyroscope readings, touch events and timings, secret herbs and spices etc.
The clientBlobs lend themselves to offline processing. There are conceivably servers continuously trawling through a backlog looking for tell-tale patterns of bad behaviour, but it also provides an audit trail if a particular player is suspected of spoofing. Occasionally Niantic indulges in mass purges, which presumably follow from a new cheat detection heuristic being run on all the collected data for some period. These "ban waves" have a reputation for penalising unusual device configurations (the most recent major wave appeared to target, amongst other things, players with modified Android variants that might mask GPS falsifying code, including cheaper Chinese knock-offs, and Jolla phones running Sailboat).
Occasionally during major Ingress gaming events – so called "XM anomalies" – there is some level of human supervision to quickly identify and remedy clearly-fraudulent player behaviour, but for day-to-day operations it seems that account termination, so-called "hard bans" and shorter-lived "soft bans" are entirely automated, and based on offline player data analysis.
Getting back to the New Cruelty: the clientBlob was not part of Ingress's initial implementation; for a while after it was introduced was ignored, and then it became mandatory. A similar opaque chunk of data is included in the Pokémon Go requests, so we should look forward to its imminent deployment when Niantic scrape together enough Pokécoins to buy a few new servers for batch processing. At that time these convenient APIs won't have long to live.
I'm curious how the financial side works with the gameplay side - the people doing spoofing might also be those that are motivated enough to spend money on the game; you don't want to ban your whales [best spenders] just because they tried to cheat. Would be really interested to see how much of that weighs in to business decisions on crack-downs on unauthorised "play".
I don't think though that Niantic have much of a moral hazard to consider here. Looking at what's purchasable in the Pokémon store, there's nothing that would be attractive to anyone who was able to virtually wander the world at all hours from the comfort of their couch, especially since anything that can be bought with cash money could be obtained using coins earned in-game. If a player's motivation in spoofing was to "catch 'em all" by whatever means necessary, it seems unlikely that they'd draw the line at restocking from Pokéstops along the way.
Comparing with the dark side of Ingress, there is a ludicrously well-organised black market economy offering purchases for every in-game commodity – all, of course, completely against the T&Cs, all completely abhorred by legitimate players, but all offered with consummate professionalism (think of the slick ransomware scammers offering a support number). Niantic don't see any of that cash. It is likely to have had a major impact on their design decisions for the PoGo store, and the game in general. If, for instance, there is no way to trade items between players, then it severely limits the options for a parallel economy.
I could be reading too much in your comment but I get the feeling you're upset at the overwhelming amount of pokemon-related threads. Don't be.
Reverse engineering is a very interesting field of programming. Video game reverse engineering is one of the most amazing things, actually. It's where many teenagers discover how the games they play work. Where they first start understanding technology, write their first scripts, start being in control of their computer.
I haven't touched Pokemon Go yet, and am not overly interested (mostly because it's not available where I live). But the reverse engineering effort behind it is spectacular and passionating. Why dismiss it like this?
It's utterly boring.
Overall it's sad that most game mechanics of the original games didn't make it into Pokemon Go. Does anyone know how much time they had to implement it?
I vaguely remember stories about game companies legally going after companies making bots.
Would uploading an API like this open someone up to a lawsuit? What about someone uploading a bot or a botting framework?
If they are profiting off their work to the extent that it actually makes business sense for the game company to sue them for damages, then that is the action they can expect to get.
If you want to learn more this subreddit is great for news.
The Python version has been out for weeks now and I thought this was the Golang version.
The best PokemonGo bot by far!