Catching Pokemon GO in Your Network
You’ve probably heard about Pokémon GO by now, the app that has become the most successful US mobile game ever, beating Candy Crush Saga. Being in the spotlight, it has also attracted the attention of hackers eager to expose and exploit as many weaknesses in the game as possible.
Using Ixia’s BreakingPoint solution you can generate Pokemon GO traffic, or with the ATI Processor you can identify/classify and get visibility into Pokémon GO traffic on your network. In this article, we will focus on analyzing the communication between Pokémon GO and the Niantic backend servers.
Firing up Fiddler Web Debugger and inspecting the network traffic reveals the communication is performed via HTTPS, but the app doesn’t do certificate pinning, so it’s trivial to man-in-the-middle (MITM) the data if you control the device (in this example we used 0.29.3, but starting with version 0.31.0, certificate pinning was introduced).
From the capture, we can also find some of the app’s dependencies: Unity (the engine on which Pokémon Go is running), Upsight (used for analytics), Crittercism (used for monitoring and crash reporting). The information provided by Fiddler is consistent with our findings from inspecting the application’s APK (Android application package).
Requests and responses are encoded using Google’s Protocol Buffers, and seem to pass through a Remote Procedure Call system. There is an initial handshake performed to
pgorelease.nianticlabs.com/plfe, which seems to assign a number for that session. This handshake includes the authentication JWT (JSON Web Token), location, timestamp, and some other binary data. The handshake response contains a URL in the form of
xxx is a number and all subsequent communications are performed to this URL.
Looking at the content of the response of the first request, we see something like this (this is binary data resulted from the protocol buffers encoding):
Pü[Çl0¡ˆ!ñ×~1ÏÞê²[›j`ã„9„ã8 ò¬ŒÜÕ]Gew‹3_3@”m¿1¯Áß?Dz†ÓÄR”‑#ûU—ÚÏëPŒµÞ¨â*¨§rÑXLÚqd÷ˆ‑Vk¢ ¢…
This is a part of the protocol buffers message. It’s unreadable for the human eye, but to correctly interpret it, we need to know the schema. Luckily, there are some pretty decent schema definitions out there for most of the protocol. In this example, we used https://github.com/AeonLucid/POGOProtos. After installing the protocol buffers library, using the protoc command, it becomes a bit clearer:
I’ve truncated some of the fields, since they were very long, but, as we see, the response provides us with a new endpoint:
pgorelease.nianticlabs.com/plfe/247, which will be used for all subsequent requests.
Now, let’s see how a (decoded) Pokémon encounter looks:
This is the general format for all requests messages. As we can see, a message can contain multiple requests. There are over 50 request types, each one with a different request body. Also, all requests messages contain identification data like the latitude, longitude, and altitude of the player, as well as the authentication token.
Using Ixia’s BreakingPoint system, we can simulate Pokemon GO network traffic, with various actions and parameters.
This is just another example of the research we are doing in the ATI Research Center at Ixia to provide actionable intelligence on the latest happenings within the networking world.
Leverage Subscription Service to Stay Ahead of Attacks
The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.