Unlocking Engineering of Pokemon Go

In computing system, one can unlock how things function and reuse the data to accomplish something by following reverse engineering method. This is applicable even for Android apps.

We are looking for the perfect app to do the reverse engineering and nothing far better than a Pokemon-go app, it took over the world in days and makes an impact on millions of people. This blog will mainly focus on how we extracted information from the Android app, in order to understand their technical methodologies.

Here are quick things we found:

• The code is not obfuscated, which makes attempts at reverse engineering much easier.
• We are able to rebuild a functional project and understood most of project flow.
• No hint to future VR or Cardboard versions
• Dependencies could be better managed
• We can get access to quite a few things: code for location/network/sensors and communication with Pokémon Go Plus
• It may be possible to downgrade the minimum requirements

For details understanding please read more information below,

Reverse Engineering of an app:

The first thing we need to do in order to reverse engineering is to have the APK file. It doesn’t seem difficult to find the Pokemon GO app apk from the internet.

In our case, we have tested the APK of version 0.29.3, dated from July 20.

Inside the APK

Now let’s have a deep dive inside the APK. Actually, an APK is just a zip archive with below files and folders inside:

The Manifest is just an Android Manifest of the application. It acts like an identity element and provides the name, icon, versions, permissions, device restriction and different components of the app. Whenever there is a need to update or install, it’s the entry point which system refer.

Classes.dex is compiled with java source. You can actually have more than one (called as multidex), but it doesn’t really matter for our purposes.

Lib is the folder containing the native libraries.

Res and assets are direct matches for the resource and assets of the project.

Resources.arsc is an android special file that makes the link among resources and code. A compiled version of R.java files of the project.

META-INF is a folder containing a metadata and is of no interest to us.

Extracting Code

The dex extension stands for Dalvik Executable. This is an Android specific file format and is not very accessible. We can deal with the dex files in following two ways: The first one is a smali which converts contents to the readable bytecode and the other one is the conversion to traditional java file.

We will choose the second way and use dex2jar to convert the dex (Dalvik executable) into a Java archive, as the name indicates (a Java archive is just a zip file comprising Java bytecode in .class files). Now, we have a jar and many other tools are now available to us. The next interesting tool is a decompiler which will convert the .class bytecode files into Java source code. There are numerous decompilers available having their own strengths and weaknesses that should be minor in our case. We used Jadx, but feel free to use another.

We should now have easily readable most of the code for any developer “Most of the code” only as it rolls out decompilers have their limitations and are not always able to decompile every piece of code.

By going through the source code, the initial conclusion was that there does not seem to be any obfuscation. All packages are easily readable, so we can identify which libraries are being used in an app. The list of libraries is given below:

• Android support libraries: support-v4, appcompat, and support-annotations
• Jackson (JSON parser): core, annotations, and data bind
• Otto (event bus)
• Gson (JSON parser)
• Dagger (dependency injection)
• Apache Commons IO (utilities for I/O)
• RxJava / RxAndroid (reactive programming)
• Upsight (analytics)
• AdMob, now declared as firebase-ads (ads, analytics)
• Unity classes.jar (interaction between the Android framework and Unity)
• Crittercism, now known as Apteligent (monitoring and crash reporting)
• Voxelbusters’s Cross Platform Native Plugins (mainly used for sharing from Unity)
• Lunar Mobile Console (Unity logger for Android)
• Google VR SDK
• Various parts of the Play Services

After wiping everything, we concluded with the below list of direct dependencies utilize by the project:

• Gson
• Crittercism
• Upsight
• Admob/firebase-ads
• Google VR SDK, Unity and associated

Pokémon Go is running on the Unity app engine, which is the main dependency of it. So, when you launch the app, you will have a splash screen with the Niantic logo in order to give some time for the Unity engine to start. Then another progress bar loading display enables the engine to load all the required assets for processing further.

Pokemon Go uses Protocol Buffers for communication, not XML, JSON, etc. This is trendy now a day for communication.

Resources and Assets

Fortunately, getting to the resources and assets is going to be much easier than the source code. Despite, assets are unused during the developing phase and packaged as-is in the app. Although every asset in Pokémon Go is designed for Unity, so we will not discuss with these for the time being.

But dissimilar assets, resources are influenced by the developing phase (particularly, by apt, the Android Asset Packaging Tool, which, despite its name, operates on resources and not assets). Remarkably, XML designs (and the Manifest for that matter) are switched to a binary XML format where a person is unable to edit or read. Also, 9-patches are converted and lose the columns and rows indicating their properties of scaling.

The Another tool (aptly named APKtool) facilitates you to revert these transformations which sound good for developers. An option of decode (APKtool d) uses an APK and gives you an almost working Android project (with Manifest and resources in an easily readable format). APKtool transforms the classes.dex into small files, when Java classes is required due to this reason we did not use it earlier.

Now we can include the decompiled Manifest, decompiled resources, and the assets in our project, and, since we cleaned up our Java code earlier, we have now caught everything we need for a fully functional Android project.

Analyzing the code

As we saw earlier, most of the app runs inside Unity. The upside for the developers is that Unity is platform-independent. So whatever they write for Unity will run on both iOS and Android. This means the code that is left over are the parts specific to Android which they could not integrate to Unity. Namely, you can view code for:

• Sign-in / Registration (inside the package com.nianticlabs.nia.account)
• In-App purchases (inside com.nianticlabs.nia.iap)
• Communication via Bluetooth with the Pokémon Go Plus (inside com.nianticproject.holoholo.sfida)
• Interaction with Location, Network and Sensors (inside com.nianticlabs.nia.location/ network/sensors)

In the end, despite its length, this is a fairly basic analysis, only using off-the-shelf, accessible tools. Yet few game-breaking secrets are not revealed, published cheats or hacks, or given any unfair advantage over their competition to readers. But, if you are an app developer, you have to realize that this would be possible for dedicated attackers if you do not take steps to actively restrict such attacks.

We should also take a minute to discuss what we won’t be able to see when reverse engineering occurs. We are restricted only to what is inside the app, so there are parts of the project, that developer can see are inaccessible to us. Here is a nonexhaustive list:

• Everything builds related: We only have the conclusion of the build, not the process
• Everything about continuous integration or testing
• Other variants (mainly debug versions): While developing, you tend to have special features that are not visible in production, and as we are working from a release version, theses features should not be included in the app (and are probably not)
• The source of the back-end: This should be obvious, but this is especially important here where a lot of people would be interested in learning about the algorithms that decide, for example, what Pokémons spawn where. But servers made this is a decision made. We can only learn how to communicate with these servers, not how they behave internally.

Source – Applidium