Android Mobile Game Hacking (Part 2)

TL;DR#1: Previously, we covered the fundamentals of Android Sandbox and the basics of memory scanning. We learned how to find and “freeze” values in a game’s memory while it’s running to gain immediate advantages.

TL;DR#2: Now, we’ll take it a step further by exploring the creation of permanent modifications (also called “Mods”). This installment focuses on automating hacks with Frida and reverse-engineering game logic with Ghidra. We also discuss the defensive side: how to identify modified APKs and why you should be cautious of the security risks they pose.

Reliable Cheats: Frida & Binary Patching

Fuzzing and doing the same process repeatedly in the game can be very exhausting and time consuming. That is why it is crucial to write our scripts in order to modify those values for us. Another important issue is that memory is dynamic, so each time that you close and run the game all those addresses will change and will be invalid in the new game run.

This is where tools like Frida come in, which allows us to write scripts that automate the process and eliminate the need for repetitive manual fuzzing.

FRIDA

Using FRIDA to write the script can be as simple as follows:

In this script, we use Frida to extract the library and locate the module’s base address. By adding the specific offset, we can point exactly to our target function. Once the AddCoins address is secured, we begin probing the arguments to identify the coin value. We discovered that the x1 register holds this data. We simply redefine x1 by multiplying it by 100, so each coin you got in the game will be X times 100. Of course, you can play by multiplying this value by any integer.

Java.perform(function() {
console.log('[+] Waiting 3 seconds for libil2cpp.so to load...');
 
setTimeout(function() {
console.log('[+] Hooking AddCoins at offset 0x22440d0');
 
var il2cppModule = Process.findModuleByName('libil2cpp.so');
if (!il2cppModule) {
console.log('[-] IL2CPP module not found');
return;
}
 
var base_addr = il2cppModule.base;
var addcoins_offset = 0x22440d0;
 
console.log('[+] Base address: ' + base_addr);
console.log('[+] AddCoins offset: ' + addcoins_offset);
 
var addcoins_addr = base_addr.add(addcoins_offset);
console.log('[+] AddCoins address: ' + addcoins_addr);
 
if (addcoins_addr.isNull()) {
console.log('[-] Invalid address');
return;
}
 
Interceptor.attach(addcoins_addr, {
onEnter: function(args) {
console.log('[+] AddCoins called at offset 0x22440d0!');
console.log('  x1 original: ' + this.context.x1.toInt32());
 
this.context.x1 = ptr(this.context.x1.toInt32() * 1000);
console.log('  x1 modified: ' + this.context.x1.toInt32());
}
});
}, 3000);
});

Binary Patching: Ghidra

As we identified the offset 0x22400D0, we can use Ghidra to patch the instructions inside that address region using G and by pasting the offset we will see the implementation in arm language. This is application modding, so it won’t be the official app anymore but we can still play and get rewards!

An important trick is to set the variable names of the function’s arguments so it will be easier to detect and change the specific instruction in our value of interest.

After identifying the value, we can just modify it and save the library, re-build the game and play to see the changes. In this case we changed the deltaCoin to 0x64 (100 DEC) but we can use values higher than that, for instance 0x270F (9999 DEC).

Android Modded Games Application Analysis

As we saw in the process of decompiling, modifying and rebuilding the game, we can use those techniques as a reference to identify any modded application. It is important to have in mind at least this:

• APK Signature: does the application have a different signature compared to the original one?
• APK Libraries: does the decompiled application have any different library that the original one does not have?
• At least we can consider comparing the il2cpp.so libraries to identify changes but depending on the game this won’t be the most proficient way to analyze it.

Using apksigner with the following command we can get information about the signatures:

apksigner verify –verbose –print-certs (apk)

As we can see this is the original signature extracted from the application without any kind of modification.

If we use the same command in a our modded application it would look like this:

This is an approach to verifying the authenticity of the application.

We can try another way like comparing the sha-sums of the libil2cpp.so libraries from both apks:

And a very important step to verifying modifications is in fact the libraries and if there are some invocations of those libraries in the Smali application code:

It is possible to create our own libraries and invoke it in the application bootstrap. Due to this behaviour, we should think about the possibility of downloading modded applications that effectively had some changes in the game logic. However, there is a chance to open a modded game which has embedded malware inside.

Automating Mobile Games Analysis With Tungstenic

As we saw before, manually executing this process can be quite trickier or even exhausting, this is where our tool used to analyze Android and iOS applications comes in! Say Hello to Tungstenic, a new evolved mobile application analyzer that helps you to identify vulnerabilities and even libraries and other interesting items that your mobile application has. In our case we need to extract information about:

• Our Application Package Name and general information about it.
• SHA Signatures to make comparisons to determine modded applications over the original.
• Identify some Libraries that can help us to determine the kind of game and its framework and how it was built ( as we said in our recent post about game hacking part I, we are confronting Il2CPP or Mono Game? ).

First we used our tool to scan the application, bringing us all the information we can get manually in a faster and comfortable way.

Looking at the File Information Section, we can extract signatures, size, file name and so on. In this case, we can see the original signature from the .apk.

What if we used it to scan a modded game, well the signatures are going to change showing the incompatibility between them and giving us an approach to know that this application has been modified.

Finally, to determine other aspects of the application composition, we can make a lookup in our Libraries Section, this will help us determine which type of compilation the game has.

As we saw, our tool helped us easier and faster than doing this process manually, after getting this general information we can continue with our analysis in a comfortable way.

General Goals and Conclusion

Why do game hackers actually do this? The reasons vary: some do it just for fun or to gain a competitive advantage, others seek financial retribution, and some even use it to test their abilities. However, there are also those who use game hacking as a vector to distribute malware.

• Entertainment
• Learning
• Monetization
• Competitive Advantage
• Malware Distribution

It is important to bear in mind the following recommendations:

• The client always had to be treated as hostile.
• Applying cryptography to sensitive values in memory would be great to increase the difficulty to retrieve information when the user is scanning the app and searching for values.
• Always do server-side validations instead believing all the information that the client is sending.
• Implement Authoritative Server Architecture in the game and mostly in sensitive functionalities like purchases, money and so on.
• As a gamer, don’t trust blindly in any kind of modded apk from unknown or unreliable sources due to the possibility of installing and running a compromised application with embedded malware.

Stay tuned to the following posts and don’t forget to follow us!!