Alina Colceriu
Ixia Senior Application Protocol Engineer
Blog

Catching Pokemon GO in Your Network

August 8, 2016 by Alina Colceriu

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).

Pokemon1

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 pgorelease.nianticlabs.com/plfe/xxx, where 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):

5‚€€€€ÉßÛS#pgorelease.nianticlabs.com/plfe/247:k

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:

status_code: 53

request_id: 6032429073588813826

api_url: "pgorelease.nianticlabs.com/plfe/247"

auth_ticket {

  start: "\374[\307l0\241\210!\361\026\327~\0271\030\317\027\217\336\352\017\262[\233j`\343\..."

  expire_timestamp_ms: 1469449908021

  end: "\250\247r\321\255XL\332\025qd\367\210\036Vk"

}

returns: ""

returns: ""

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:

status_code: 2

request_id: 1595665085873782876

requests {

  request_type: ENCOUNTER

  request_message {

    encounter_id: 6709781666168763549

    spawn_point_id: "40b1ff439b3"

    player_latitude: 44.436206817626953

    player_longitude: 26.092941284179688

  }

}

requests {

  request_type: GET_HATCHED_EGGS

}

requests {

  request_type: GET_INVENTORY

  request_message: "\010\326\374\365\217\342*"

}

requests {

  request_type: CHECK_AWARDED_BADGES

}

latitude: 44.436195373535156

longitude: 26.092935562133789

altitude: 4

auth_ticket {

  start: "\355\354\020ys|\022\034\022\022\202j\363\023\304\305J\334\347\255\263\..."

  expire_timestamp_ms: 1469449908996

  end: "6N\356\235\375H<\352\003}\270\207\316\177\367G"

}

unknown12: 803

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.

Pokemon2

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.