Breakin 'Em All – Overcoming Pokemon Go's Anti Cheat Mechanism

Breakin 'Em All – Overcoming Pokemon Go's Anti-Cheat Mechanism

Speakers: Tal Skverer

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=2En96Cg9BFw

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Tal%20Skverer%20%E2%80%93%20Breakin%20%27Em%20All%20Overcoming%20Pokemon%20Go%27s%20Anti-Cheat%20Mechanism.pdf

Overview

Pokémon Go launched in July 2016 and immediately became a global phenomenon, blending augmented reality with a location-based game mechanic that required players to physically move through the world. Within weeks, a parallel community of developers began probing the game's network protocol to build scanners, maps, and bots — tools that Niantic, the game's developer, worked aggressively to suppress. The resulting arms race between Niantic's anti-cheat systems and the hacking community spans nearly a decade and serves as a rich case study in mobile security, reverse engineering, and the limits of client-side integrity enforcement.

At DEF CON 33, security researcher Tal Skverer presented a retrospective and technical deep dive into the methods used to discover, understand, and ultimately bypass the layers of anti-cheat protection Niantic deployed in Pokémon Go. Starting from an HTTP proxy intercept in 2016 and progressing through Protocol Buffers, SSL certificate pinning, root detection, code obfuscation, and server-side behavioral analysis, the talk walks through what amounts to a complete mobile application security audit conducted over years — with a real-time scoring system of "gym badges" to track progress through Niantic's defenses.

Background

▶ Watch: Discovery: Pokémon Go uses Protocol Buffers (protobuf) over HTTPS (0:59)

Pokémon Go operates on a deceptively simple premise: a mobile client communicates with Niantic servers over HTTPS to determine which Pokémon are near the player's GPS coordinates, then renders them in augmented reality. However, the client receives exact Pokémon locations — not just proximity hints — because computing distance on-device is more efficient than server-side calculation. This architecture created an immediate incentive for third-party scanner tools: forge a location request to the server, collect the full map of nearby Pokémon without physically going there, and display it on a web interface.

The first generation of scanners (circa 2016) exploited the complete lack of request authentication. As the community grew, Niantic introduced progressively more sophisticated defenses, creating what became a sustained reverse engineering effort. Skverer's research, conducted independently beginning in 2016, systematically dismantled each defense layer and documented how the protocol and anti-cheat evolved over time. By DEF CON 33, he structured the findings as six "gym battles" — each one representing a distinct defensive mechanism that had to be defeated.

Context for this research: Skverer had previously presented at DEF CON 31, where he disclosed a zero-day vulnerability in Google Cloud Platform (GCP). The Pokémon Go research is explicitly framed as historical — most techniques shown no longer work against the current live app — but the methodology and intermediate techniques remain highly instructive for mobile security practitioners.

Key Findings

▶ Watch: Reverse engineering: S2 cell coordinate system for location spoofing (7:00)

1. The Pokémon Go protocol is Protocol Buffers (protobuf) over HTTPS, not a custom binary format or JSON. This was not publicly documented; it was discovered via HTTP proxy inspection of traffic, with the protobuf signature (first byte 0x08, mixed readable/binary content) recognizable to an experienced researcher.

1. No .proto schema was publicly available, requiring schema reconstruction from traffic observation alone — a process called "blind deserialization" that reveals field numbers and types but not field names.

1. SSL certificate pinning was implemented to prevent standard MITM proxy interception. Bypassing this required Frida-based dynamic instrumentation to hook the SSL verification functions at runtime and return success regardless of certificate validity.

1. Root and emulator detection was added to prevent running the modified app on rooted Android devices or emulators. Bypassing this required patching the detection logic in the APK's compiled code (smali patching) or using Xposed/LSPosed framework modules to hook detection calls.

1. Integrity tokens and request signing were introduced over successive versions, adding HMAC-like signatures to requests to prevent replay attacks and forged location submissions. Defeating these required full reverse engineering of the signing algorithm embedded in the client.

1. Server-side behavioral analysis proved to be Niantic's most durable defense: banning accounts that moved too fast, generated unrealistic scan patterns, or made requests at inhuman rates — defenses that cannot be bypassed through client-side manipulation alone.

Technical Deep Dive

▶ Watch: Bypass: SSL certificate pinning via Frida dynamic instrumentation (9:02)

Badge 1 — Sniffing: HTTP Proxy Intercept

The initial protocol discovery used Fiddler Classic as an HTTP(S) proxy. On Android, configuring a proxy is as simple as setting the Wi-Fi proxy to point at a machine running Fiddler. With this in place, all HTTP(S) traffic from the Pokémon Go app was captured. The content type header on requests claimed application/x-www-form-urlencoded — a text-based format — but the body was clearly binary. The first byte of request bodies was consistently 0x08, and the payload contained interspersed readable ASCII strings mixed with binary data. These two characteristics are signature indicators of Protocol Buffers serialization.

Understanding Protocol Buffers

Protobuf is Google's binary serialization framework. A .proto schema file defines message structures with typed fields and integer field IDs. At the wire level, each field is encoded as a varint field number plus a wire type, followed by the value. Field numbers are preserved in the binary, but field names are not — a reconstructed schema from binary alone will have correct field numbers and types but unknown names. Skverer reconstructed the Pokémon Go request and response schemas by observing traffic patterns: correlation of game actions (walking to a location, encountering a Pokémon) with changes in specific field values allowed semantic reconstruction of the schema without access to Niantic's source code.

Badge 2 — Decoding: Schema Reconstruction

With a reconstructed .proto schema, Skverer could decode all traffic, modify field values (specifically the GPS latitude/longitude fields in the location update message), re-encode, and replay requests to the server. This formed the core of the first functional scanner: send fabricated location requests in a grid, collect the returned Pokémon spawn data, plot on a map.

Badge 3 — Certificate Pinning Bypass

Niantic added SSL certificate pinning to prevent proxy-based MITM. The app embedded a list of expected certificate hashes and verified them during the TLS handshake. Standard Fiddler proxying, which presents its own certificate, was rejected.

The bypass used Frida, a dynamic instrumentation toolkit. Frida injects a JavaScript engine into the running process and allows hooking of arbitrary functions. The approach was to hook the certificate verification function (typically in the Android SSL/TLS library or within Niantic's own implementation) and patch its return value to always indicate success. A common Frida script targets javax.net.ssl.X509TrustManager.checkServerTrusted() and the equivalent native layer calls. This allowed Fiddler to continue proxying traffic even with pinning enabled.

Badge 4 — Root Detection and Emulator Detection Bypass

As the scanner community grew, Niantic added detection for rooted devices and Android emulators, refusing to authenticate requests from flagged environments.

Root detection typically checks for:

• The presence of su binary in common paths (/system/xbin/su, /sbin/su)
• The ro.build.tags system property being set to test-keys
• Detection of known root management apps (Magisk, SuperSU)
• Writeable /system partition
• Presence of Xposed framework

Emulator detection checks:

• ro.hardware containing goldfish or ranchu (AOSP emulator markers)
• ro.product.model indicating an emulator
• Missing sensor data (gyroscope, accelerometer)

Bypass methods included Magisk's "MagiskHide" (now "Shamiko") module, which conceals root indicators from specific apps, and smali-level patching of the APK to remove or nop-out detection logic before re-signing.

Badge 5 — Request Signing and Integrity Tokens

This was technically the most demanding phase. Niantic introduced a request signing mechanism where each API request was accompanied by a cryptographic signature derived from the request content, timestamps, and a session-specific secret. Requests without valid signatures, or with replayed signatures, were rejected.

Fully defeating this required static analysis (apktool + jadx to decompile the APK to smali and Java) combined with dynamic analysis (Frida to trace calls through the signing code at runtime) to reconstruct the algorithm. The signing logic was obfuscated — strings were encrypted, control flow was flattened, and anti-debugging techniques were present. Community efforts (notably the POGOProtos project on GitHub, which maintained the reconstructed .proto schema) collaborated on documenting the signing algorithm as it changed across app versions.

Badge 6 — Server-Side Behavioral Analysis

The final and most resilient defense layer was entirely server-side. Niantic tracked:

• Travel speed between scan locations (teleporting is physically impossible)
• Scan frequency (humans cannot issue 50 location requests per second)
• Account age and normal vs. anomalous gameplay patterns
• Geographic consistency

No amount of client-side manipulation could defeat these heuristics directly. The community response was to rate-limit scanners to mimic human walking speed, randomize request timing, use multiple accounts across different geographic regions, and gradually shift to distributed scanning networks where many compromised or sacrificial accounts each perform a small number of requests.

Demo / Proof of Concept

▶ Watch: Live demo: modifying protobuf fields to fake player location (11:00)

The talk included screenshots and captured traffic demonstrating each bypass stage in sequence. Fiddler captures showed raw protobuf traffic before and after schema reconstruction. Frida scripts were shown bypassing certificate pinning with just a few lines of JavaScript. Reconstructed protobuf messages showed the latitude/longitude substitution that enabled location spoofing. A working scanner output displayed a map with Pokémon locations derived from forged location requests — the original motivation for the entire research effort.

Skverer noted that all techniques demonstrated are for historical versions of the app and no longer function against current live Pokémon Go installations. The talk was accompanied by a two-part blog post on his personal blog covering additional technical details not included in the presentation due to time constraints.

Defensive Implications

▶ Watch: Emulator detection: bypassing device sensor checks (16:56)

The Pokémon Go case study has direct implications for mobile application developers deploying anti-cheat or anti-fraud mechanisms:

Certificate pinning is necessary but not sufficient. Once an attacker has physical access to the device (or control of a rooted device), Frida-based hooking can defeat most SSL pinning implementations that live in user-space code. More resilient alternatives include TEE (Trusted Execution Environment)-backed key verification or hardware attestation (Android SafetyNet/Play Integrity API, iOS DeviceCheck), which are considerably harder to fake at the kernel and hardware level.

Root/emulator detection is a speed bump, not a wall. Magisk, LSPosed, and smali patching can defeat most user-space detection schemes. Play Integrity API (formerly SafetyNet Attestation) provides a Google-signed attestation of device integrity that is much harder to spoof without a bootloader unlock or bootloader exploit.

Client-side obfuscation adds friction but not security. ProGuard, R8, and dedicated obfuscation tools slow reverse engineering but do not prevent it. Researchers with Frida and jadx will eventually reconstruct algorithms regardless of obfuscation depth.

Server-side behavioral analysis is the only durable control. Rate limiting, velocity checks, geographic consistency, and ML-based anomaly detection targeting superhuman patterns are the defenses that cannot be bypassed through client modification. Niantic's enforcement in this domain forced the scanner community to distribute load, slow down, and ultimately accept that mass scanning at scale was no longer viable.

The play integrity signal chain (device attestation → server validation) should be the foundational layer for any mobile application with meaningful anti-cheat requirements, supplemented by server-side behavioral baselines.

Key Takeaways

• The Pokémon Go protocol was discovered through basic HTTP proxy inspection and protobuf signature recognition, then fully reconstructed through schema inference from traffic observation alone.
• Certificate pinning, root detection, and emulator detection are all bypassable through dynamic instrumentation (Frida) and static APK patching (apktool/smali) on rooted Android devices.
• Request signing and integrity tokens raised the bar significantly, requiring full static + dynamic reverse engineering to defeat — but community collaboration eventually succeeded here too.
• Server-side behavioral analysis (velocity, frequency, geographic consistency) proved to be the only truly durable anti-cheat layer, as it cannot be circumvented through client-side manipulation.
• Mobile security researchers should treat hardware attestation (Play Integrity API, iOS DeviceCheck) as the minimum baseline for high-value anti-cheat enforcement, rather than relying on client-side checks.

About the Speaker(s)

▶ Watch: Request signing: field 24 hash analysis and bypass (18:51)

Tal Skverer is a security researcher who leads the research team at ASIC Security, a cybersecurity startup focused on identity security. He conducts independent security research in his off hours, participating in CTFs and exploratory projects documented on his personal blog. His DEF CON history includes a 2023 presentation at DEF CON 31 where he disclosed a zero-day vulnerability in Google Cloud Platform (GCP). The Pokémon Go research was conducted independently beginning in 2016, born out of personal motivation to build a Pokémon scanner for a rural area underserved by the game's spawn mechanics. He can be reached via social media and maintains a blog where the two-part writeup accompanying this talk was published simultaneously with the DEF CON 33 presentation.