Reverse Engineering Pokémon GO: Bypassing Certificate Pinning and Protocol Obfuscation

TLDR: This research details how to bypass certificate pinning and decode proprietary Protocol Buffer traffic in the Pokémon GO mobile application. By using dynamic instrumentation with Frida and static analysis in IDA Pro, the team successfully identified the cryptographic signing process and API request structure. This approach provides a blueprint for researchers to analyze and interact with hardened mobile applications that rely on custom serialization and transport-layer security.

Mobile applications often rely on a false sense of security provided by certificate pinning and custom binary protocols. Developers frequently assume that because a protocol is not documented or uses a binary format like Protocol Buffers, it is effectively immune to inspection. This assumption is a mistake. During a recent deep dive into the Pokémon GO application, researchers demonstrated that these controls are merely speed bumps for anyone with a solid grasp of dynamic instrumentation and static analysis.

Breaking the Transport Layer

The first hurdle in analyzing any mobile application is intercepting the traffic. Pokémon GO employs certificate pinning, which prevents standard man-in-the-middle attacks using tools like Fiddler or Burp Suite. The application uses a custom class, NianticTrustManager, to enforce this check.

Instead of attempting to patch the binary, the most effective approach is to use Frida to hook the checkServerTrusted function. By intercepting this call at runtime, you can force the application to accept your proxy’s certificate, effectively neutralizing the pinning mechanism. This is a standard technique for mobile penetration testers, but it remains the most reliable way to gain visibility into the application's communication flow. Once the pinning is bypassed, you can see the raw traffic, which immediately reveals that the application uses Protocol Buffers for data serialization.

Decoding the Binary Protocol

Protocol Buffers are efficient, but they are not encrypted by default. They are simply a binary representation of structured data. Without the original .proto files, the data looks like a stream of random bytes. However, the structure is predictable. By observing the traffic patterns while performing different actions in the game—such as scanning for nearby Pokémon—you can isolate specific request types.

The application uses a RequestContainer message to wrap all API calls. Within this container, individual requests are identified by an integer ID. For example, request type 106 is used to fetch map objects. By correlating these IDs with game events, you can begin to map out the API.

To decode these messages without the original definitions, use the protoc compiler with the --decode_raw flag. This tool is part of the official Protocol Buffers repository. It will output the field numbers and wire types, allowing you to infer the structure of the message. If you see a field containing a coordinate pair, you can deduce that the message is likely related to location services.

Defeating Cryptographic Signing

The most significant challenge in this research was the cryptographic signing process. The application signs its requests to prevent tampering. The signing function, which the researchers dubbed sigEncryptFunction, takes the request data and produces a signature.

Static analysis in IDA Pro or Ghidra is essential here. By locating the function responsible for generating the signature, you can observe how it manipulates the input data. In this case, the function used a combination of time-based seeds and a standard CBC mode encryption scheme.

The researchers used a technique called "active probing" to identify which fields were required for the signature. By systematically removing fields from the request and observing when the server returned an error, they determined that only a small subset of the data was actually used in the cryptographic calculation. This is a common pattern in A02:2021 – Cryptographic Failures, where developers implement signing but fail to include enough entropy or data to make the signature truly robust against replay or modification.

Real-World Implications for Pentesters

When you are tasked with testing a mobile application, do not stop at the proxy. If you see binary traffic, treat it as a challenge, not a dead end. The tools used here—Frida for instrumentation and protoc for decoding—are essential for any modern mobile security assessment.

If you are testing an application that uses custom binary protocols, focus your efforts on:

1. Identifying the serialization library: Look for strings or function signatures related to Protobuf, FlatBuffers, or Thrift.
2. Hooking the crypto functions: Use Frida to dump the plaintext data before it is encrypted or signed.
3. Replicating the signing logic: Once you understand the algorithm, write a script to sign your own requests. This allows you to fuzz the API endpoints directly, which is far more effective than relying on the mobile client.

Defensive Considerations

For blue teams, the lesson is clear: client-side security controls are not a substitute for server-side validation. While certificate pinning and request signing can deter casual attackers, they will not stop a determined researcher.

Defenders should focus on implementing robust server-side checks. Ensure that every request is validated for logical consistency, not just cryptographic integrity. If a user sends a request for map data, verify that the requested location is physically possible for that user to reach within the game's logic. Relying on the client to "tell the truth" about its state is the primary failure point in these systems.

The cat-and-mouse game between developers and researchers will continue as long as applications rely on obfuscation rather than secure architecture. For those of us on the offensive side, the goal remains the same: keep digging until the binary becomes readable.