Android Game Hacking Series - Level 1

Introduction to Android Game Hacking and its techniques.

Hello everyone! Starting with game hacking is hard, and trying to start in mobile game hacking is harder. This is due to the fact that there is almost no information related this topic. As there is no offensive information there is neither defensive or preventive information.

So most small companies or single developers do not have tools to make their games tamper-proof or harder to hack. So they usually face many problems when their games grow in importance as mobile hackers tend to tackle the most important or famous games. The consequence of this is the loose of money (if a user has a way to acquire free gear or game stuff they won’t pay for it) or reputation of the game as cheaters make the user experience of authentic users.

So in this series I’ll try to give some light on common techniques mobile hackers use, using open source games.

In this first blogpost I’ll be using the rogue-like game: Hyperrogue

The objective for this hack is to modify the “Ice Diamonds” value for any other value we want, and make the hack repeatable.

Setup

We will work with the following setup:

We will use “Genymotion” as the emulator, and in order to find the memory region of the ice diamond variable we will use “Game Guardian”. In order to make the final hack we will use “frida” because of the ease on the hack.

Step 1: Finding the first address

The first step to generating a bug for an specific value in memory is finding the memory address where the variable is allocated. Depending on how the information is stored in memory, if the game has any memory protection the first search can be really easy or pretty hard.

In this case the game is simple, so a basic memory scan will be enough.

In order to do it select the option “New Search” with the value 0 (when we start the game the Ice Diamonds will start with that value) and data type “dword”. That will search in all the memory of the process for memory address which content is 0.

Then we move the character and find one ice diamond, and then we filter the results with the value 1 and then with 2.

We execute this process till we get to a few values (ideally one). Once we do that, we have to find the right one. I usually do it by changing the content of the found variables and checking if it is reflected on the game. In the following image I show the one I found by changing the content:

So at this point we can say we have a cheat created. Kudos!

Step 2: Make it repeatable

Note that the memory address found in the example was: 0x6e7b46495c.

But the next step on our hack is to make it repeatable. So we execute the same process again and we’ll probably find that the memory address of the variable has changed, but not that much:

Why does the memory address changes every time the application is launched? It is because of one protection called ASLR, which is nowadays in all applications installed in any modern OS. So it is something that we will face most of the times if we want to learn how to hack a game.

As the memory address changes every time, we need to find a way to find dinamycally how to predict the memory address of the variable. This will depend hardly on how the game was coded and how the memory is allocated (whether it is static or dinamyc).

In order to find that, I went to read the memory map file of the game process. The memory map file can be found in /proc/pid/maps.

The pid (process id) of the game can be found in many ways. Particularly in Game Guardian it is shown in the title of the process being scanned.

So we need to find the memory region where the memory address is by reading the file. As it is long I recommend to try first the following command and check if in the filtered list we get the range of memory we want:

cat /proc/<pid>/maps | grep <first_4_or_5_hex_of_memory>

In my case I got the following:

...
6e7a88f000-6e7b299000 r-xp 00000000 fe:12 570135                         /data/app/~~vLTxx9PAP97dVJ3ZaxJRZg==/com.roguetemple.hyperroid-bH7VfpFL5b4kJ-a6h9hVOg==/lib/arm64/libhyper.so
6e7b299000-6e7b29a000 ---p 00000000 00:00 0 
6e7b29a000-6e7b2c2000 r--p 00a0a000 fe:12 570135                         /data/app/~~vLTxx9PAP97dVJ3ZaxJRZg==/com.roguetemple.hyperroid-bH7VfpFL5b4kJ-a6h9hVOg==/lib/arm64/libhyper.so
6e7b2c2000-6e7b336000 rw-p 00a32000 fe:12 570135                         /data/app/~~vLTxx9PAP97dVJ3ZaxJRZg==/com.roguetemple.hyperroid-bH7VfpFL5b4kJ-a6h9hVOg==/lib/arm64/libhyper.so
6e7b336000-6e7b56b000 rw-p 00000000 00:00 0                              [anon:.bss]
6e7b5c0000-6e7b5c1000 ---p 00000000 00:00 0 
6e7b5c1000-6e7b612000 rw-p 00000000 00:00 0                              [anon:scudo:secondary]
...

As the memory address is 0x6e7b46495c, the memory region is the following one:

6e7b336000-6e7b56b000 rw-p 00000000 00:00 0                              [anon:.bss]

At the end of the line we find that the memory is allocated in the [anon:.bss] region of the libhyper.so library.

Now we can execute the following equation (in hex):

<variable_memory_address> - <init_of_memory_region>

In this case it is:

0x6e7b46495c - 0x6e7b336000 = 0x12e95c

In order to check if this is reliable we need to excute the same process of step1 again (at least two or three times). If in each time the equation returns the same value, it means that the variable is allocated in a static memory region, so we can execute memory calculations in order to find the right address to modify.

If the memory region changed, we might be facing a dinamyc allocated object, and the technique used in that case is pretty different. But as of today, we are good.

Step 3: Make the hack

After finding the formula, we need to make the hack to avoid the manual operation. At the time of writing this blogpost I couldn’t find a way to do it in Game Guardian (even using the Lua scripting functionality). So I decided to do it with Frida:

var m = Process.getModuleByName('libhyper.so')
m.enumerateRanges('rw-')[0].base

I faced another limitation with Frida, and that is that we do not have the memory regions separated as we do in the memory map. But I found that the second command shown will point to the line before the [anon:.bss] region of the library:

6e7b2c2000-6e7b336000 rw-p 00a32000 fe:12 570135                         /data/app/~~vLTxx9PAP97dVJ3ZaxJRZg==/com.roguetemple.hyperroid-bH7VfpFL5b4kJ-a6h9hVOg==/lib/arm64/libhyper.so
6e7b336000-6e7b56b000 rw-p 00000000 00:00 0                              [anon:.bss] 

So instead of generating the formula using the beginning of the .bss region we can use the previous one. At this point, in order to verify that it worked that way I executed several tests to check if it was reliable.

After doing that and confirming it was still viable to execute the formula, I changed it to point to the previous memory region:

0x6e7b46495c - 0x6e7b2c2000 = 0x1a295c

And then execute the script:

var initObject = parseInt(m.enumerateRanges('rw-')[0].base) + 0x1a295c;
var address = ptr(initObject);
address.writeInt(15);

After we execute this script, we can find that the variable is changed in memory:

The last step of the hack would be to patch the application to add the Frida script, and run it when the application starts.

If you want to know how to do it, please read the following link: https://rossmarks.uk/blog/permanent-frida-hacks/.

If you want us to create a video reach out on our social networks and we will create the content for you :)

Another level of sophistication in hacks is a mod menu. In future blogposts we will show how to create a mod menu for our game.

If you are a mobile game developer and you want to have a scan on your mobile game, reach us, and we can help you to make your game hacker-proof!