The future of mobile app security, or what Pokémon can teach us

    Since the advent of Pokemon Go, I have been following with great curiosity everything related to this toy. Oddly enough, it gives an insane amount of interesting information - primarily regarding the development of mobile applications. It would seem that you are developing banking applications - what could be the connection here? But no, you also have something to learn from Pokemon.

    Today I would like to dwell only on one of the interesting observations - namely, on the security of the mobile application. Not that Niantic was an icon for all world developers, but let's assume that their level of development is quite high, and their mistakes and shortcomings will be true for most other mobile applications. I will try to state in such a way that it is interesting and understandable to all developers, and not just those who played or read something about the toy.

    Act one. Bots for everyone and no one will leave offended

    The first versions of the application were very poorly protected from reverse engineering, and with great speed appeared geek developers who disassembled the mechanics of the game or added additional features or hacks there. When it became interesting to me how many developers were involved in this fun, I opened the github and got a little bit sick:

    Yes, your eyes have not deceived you. 1644 repositories. Probably worth clarifying that there:

    • Bots - where without them;
    • Clean API implementation options in any languages ​​and platforms;
    • Data collections and mechanics pulled from the application;
    • Applications for finding Pokemon around;
    • Automation apps like the mass evolution of Pokémon;
    • Applications for viewing the hidden properties of Pokemon (IV);
    • Applications for calculating the optimal battles;
    • Just a version of the game with reduced system requirements.

    It should be noted that many applications owe their appearance to the fact that many points are very poorly implemented or explained in the game - it is quite natural that resourceful developers decided to whip together several crutches.

    Act two. Timid defense attempt

    At some point, the application abruptly stopped showing the remoteness of Pokemon (previously, three degrees of remoteness were shown). What do you think this is connected with? Think a couple of minutes. Your worst-case assumption will turn out to be true - remoteness was calculated in a client application to which the coordinates of nearby Pokémon were transmitted - which significantly increased the detection radius for frolicking bots. It’s not entirely clear why Niantic decided to completely remove this feature instead of transferring the calculation to the server side ... Well, okay, we’ll hardly ever know. Perhaps they decided not to add extra load to the server, already cracking from the strain. This article does not include the question of how a Google subsidiary was so screwed up with scaling a game with such low data connectivity, but still ...

    Act Three. Funny attempt to protect

    A little later, the time for detecting Pokemon after the player appeared in the location doubled - as far as I remember, from 5 to 10 seconds. It looks like some kind of panic protection measures, which, of course, could not bring intelligible results - bots in the same way doubled the timeout.

    Act Four. Protection!

    Finally, the day came when bots and scanners stopped working at once. Honest players breathed a sigh of relief - to compete with bots, many of which scored the level 30+ inaccessible to the player, was very tiring, and just sad. But well ... The relief lasted only three days. Enthusiasts from reddit during this time disassembled the native C ++ library, which is part of the application, picked up the necessary data and encryption, and again rolled out a working version of the API, which was picked up by bots and scanners during the day.

    The fifth act. Attack!

    In fairness, it is worth noting that the fifth and fourth acts went in parallel, but I wanted to logically separate them.

    In this act, Google began to ban indiscriminately any application on Google Play that had at least something to do with Pokemon. Banhammer worked indiscriminately. As an example of unjustly affected applications, we can cite

    • An application for calculating the hidden characteristics of Pokemon. Banned for "violating the device and network abuse". What is an outright lie, since the principle of the application is to recognize images from the game and analyze indicators. The application does not even have the right to send data to the Internet ...

    • A simple calculator to calculate the optimal Pokemon to fight with the selected. Banned because “violates the impersonation policy”. Which is generally a favorite phrase from Google, because it is impossible to understand and fix the error (believe me, I tried to do this with another application).

    Act six and last. A shame.

    It is difficult to call this act otherwise. After the popular applications were removed from google play, the developers unifiedly posted them in open source on github. In general, the infrastructure of mobile applications on the github is quite interesting - 2016 allows you to do automatic updates from the github, send error messages anywhere, and in general it’s pretty good to live without Google Play. Moreover, the credibility of the application is not less, but more than if it had been posted on Google Play ...

    And what happened? Pretty expected, but no less sad thing. Niantic went to complain about the repository. As a result, most authors deleted their code (I must say, not completely, but simply wiped it with the last commit) with something like this:

    I've received a notice to cease and desist from Niantic Labs, and I've decided to comply with their requests. I'd like to clarify that the main reason I chose to shut it down was because I've lost interest rather than legal concerns. Niantic's actions towards 3rd party developers have been very off-putting and it has killed my personal motivation to work on this project. This was a fun weekend project for a game I enjoyed, and now I've lost interest in both. I won't resume development, but there are active forks of this project you could use.

    Not that the authors were afraid of Niantic's calls, but their policies simply upset the developers to the core. Application code remains on the github, forks multiply, and malicious use continues to flourish. Niantic could neither provide their own adequate tools for working with the game, nor protect the game from outside interference. And just went to scribble complaints. Well ... Not so if it were unexpected in the light of the similar fate of the much less popular Ingress, but it is a pity that a company that claims to revolutionize the gaming industry does not learn from its mistakes and does not even recognize them. Although I’m glad that there are guys like Blizzard who understand how useful it is to give players the opportunity to influence the overall game world and refine it.
    UPDATE. The comments say that I'm not quite right, or even completely wrong. But Blizzard still makes it possible to influence at least the user interface. The motive for closing alternative servers and clients is quite understandable - this is a direct loss of profit.


    What can we learn from this sad story?

    1. Mobile application code cannot be protected. In the best case, you will simply not be needed by anyone - then you have nothing to worry about. Otherwise, when laying out the application, it is better to assume that you posted its sources in open source - from this position it is much easier to assess the consequences and possible measures to counter hacking.
    2. Mobile applications without Google Play may exist, and, apparently, there will be more in the future.
    3. You can get a huge number of helpers if you post your application in open source. You are scared? Well then, continue to entertain yourself with the illusion of protection. And your potential helpers will be on the other side of the barricades.


    Details from the reddit on parsing the new API


    The Update . At first, I slowed down and did not do a survey with options for what else to talk about, so the corresponding items appeared in the comments. Now you can just vote.

    Update 2. Added translation of the hack history.

    Only registered users can participate in the survey. Please come in.

    I can tell you a few more stories if you indicate in the comments that they are interesting to you:

    • 48.8% Full history of hacking a new version of the Pokemon API by the reddit community. She is fascinating and instructive! 218
    • 41.7% Why Apache HttpComponents became deprecated, where Google developers lie, and why you should continue to use HttpComponents (and how to do it). 186
    • 60.9% The current implementation of SSL in browsers is confusing to the user, giving the illusion of security. 272
    • 47.3% Why you should not run right now to develop your application with augmented reality, monuments and Peter the Great. 211

    Also popular now: