Network Security (EE I7000)

Mobile Platform Hacking (Group-06)

Project Contributor:

MD ABDUL KADIR & FLAMUR SHATRI

Submitted To:

Professor Tarek Saadawi, PhD

EE I7000 Course Instructor

Associate Director of Cybersecurity MS Program,

Director, Center of Information Networking and Telecommunications (CINT)

Grove School of Engineering

The City College of New York

Academic Session- Spring 2023

Introduction

The purpose of this project is to demonstrate how mobile hacking is done and to identify vulnerabilities in mobile devices and applications that can be exploited by malicious actors and provide recommendations on how to address these vulnerabilities to enhance the security of the mobile device or application.

Reverse engineering is a complex process where a particular system is analyzed in detail to understand how it works and how it was designed, often with the goal of creating a copy or improving upon it. It involves taking apart a device, software or any other complex system, analyzing its components and its behavior to uncover its underlying functionality, design, or source code.  

In this project we will use the process of reverse engineering to analyze software binaries for the purpose of demonstrating how the software cracking is done; how values or software behavior can be changed.

For the cracking process, we will show the process and the series of steps that a hacker/cracker follows to find out how a particular software works and to change the software behavior and make it work as they desire. To come up with a clearly demonstrated view of this, we are going to use an android game to show how someone can change the values of the game currency (coins in our case), to cheat the game, by changing the hardcoded values inside the game core software.

I. Background

Mobile platform hacking using reverse engineering is a process that is used to understand how a software was made and how it works. There are two ways to do realize this process:

1. Static analysis: where the engineers study the binary without running it. They use specific tools that try to turn the machine code into a more readable code.

2. Dynamic analysis: where the engineers run the binary with an attached debugger. By using the debugger, they can understand which part of the code is being called at a specific triggered event. Most of the time it is done in combination with static analysis.

There are various reasons why software engineers use the reverse engineering process. The main uses are as listed below:

1. To recreate a  competitor software (create another version of the software by using the same or similar algorithm). This has been a major reason for a long time for reverse engineering in general, not only for software. But in software we can see several examples. One is the OpenOffice Linux apps, where developers studied the Microsoft Office software and recreated most of their functionality as an open-source software. Another example is the Wine software, where the engineers reverse engineered the Windows API to make it possible to run Windows apps in a Linux OS.

2. To study important software to find exploitable bugs by security researchers and hackers/agencies. This is also a very common reason where the security researchers try to find bugs and report them to the software vendors so they can patch the software, while hackers will try to find and exploit these bugs for malicious purposes. If anyone looks in the CVE database of MITRE, you can see a lot of bugs patched every day. Some of these bugs might have been reported by security researchers, while some others might have been found being exploited by hackers.

3. To analyze malware behavior. This is also one of security researchers’ main objectives if they are studying how to counteract malwares to help the public and antivirus software fight them. One famous example is in the case of the WannaCry ransomware, where a security researcher studied the ransomware’s behavior and found out that before encrypting the files, WannaCry would first check if a specific domain existed, which it didn’t. The researcher registered the domain and stopped the spread and the further encryptions of the ransomware.

4. Change software’s behavior. This is done most of the time in apps that are downloaded from pirate websites. The crackers crack paid software to make them free without a license, or they may change a game for example to reward the player from the beginning of the game with a big amount of game currency. But what you may not know is if the cracker went even further ahead and injected malware code inside the cracked app, turning it into a Trojan Horse, which happens very often.

As mentioned in the Summary, in this project we will focus on the 2nd and 4th reason.

How can we protect against this?

For the first and fourth point, there isn’t any way to protect against it if the users have the software in their machine. You can try to discourage the person who is trying to reverse engineer and copy/change your software by obfuscating the code and adding useless code which is not related to the app functionality, but this would only give a harder time to the competition. Sooner or later, they will have an understanding of how things work.

For the second point, since the biggest problems are memory corruptions which lead to critical vulnerabilities, it is advised that if it is possible, developers should use programming languages where the developer is not responsible for the memory management. But this is not always possible, like in system software, apps that require very fast computation, will always need to be written in a programming language that is closer to the Machine Language, like C, C++, etc.

For the third point, we wouldn’t want the hackers to know how to avoid us from analyzing their malwares, but they do. Some implement code that makes the malware stop running if it detects that it is being run in a virtual machine, to avoid dynamic analysis. As mentioned before, this will only make the job of the researcher harder, but they still can use static analysis to understand the code.

By following these steps, you can help protect your mobile device from cracking and other security threats.

1. Keep your mobile operating system and apps up-to-date: Regularly updating your mobile operating system and apps can help protect your device from known security vulnerabilities and exploits.
2. Download apps only from trusted sources: Only download apps from official app stores, such as Google Play Store or Apple App Store. Be cautious of downloading apps from third-party app stores or websites, as they may contain malware or malicious code that can compromise your device's security.
3. Use antivirus software: Install and use a reputable antivirus software on your device to detect and remove any malicious software or viruses that may be installed on your device.
4. Be cautious of phishing scams: Do not click on suspicious links or download attachments from unknown sources, as they may contain malware or phishing scams that can trick you into revealing sensitive information or installing malicious software on your device.
5. Avoid rooting or jailbreaking your device: Rooting or jailbreaking your device can make it more vulnerable to security threats, as it removes some of the device's security measures and can allow unauthorized access to your device's system files.
6. Use strong passwords: Use strong passwords for your device and app accounts to prevent unauthorized access. Avoid using easily guessable passwords, such as your birthdate or pet's name, and use a combination of uppercase and lowercase letters, numbers, and symbols.

II. Tools and System Specifications

For the cracking part, if the analysis is a static analysis, like in our case, it does not matter where it is done as long as the reverse engineering tool is supported by our operating system. In this case we crack an Android game, and we do this with three tools: Apktool, Jadx and apksigner, which are all cross platform because they are written in Java, but here the attack is performed using the Windows operating system. It would be helpful to have an Android device or a simulator to test the changes from time to time, to make sure the changes are correct. To edit the bytecode, I used Notepad++, but you can use any editor.

III. Experimentation

 Cracking an android game.

Next, we will try to crack a game, by changing the value of the coins we get in the beginning of the game from 0, to a higher value.

It should be noted that this only works, because it is an offline game where everything is saved locally, and no verification is done with the game servers. While there are other ways to change the behavior of online games, the same thing to get extremely high values like in offline things cannot be done.

Now we start by first disassembling the apk( Android package) file, so we can get the bytecode of the app, which will allow us to do direct modifications into it. This step can also be done after the decompilation and study of the code. The command is as shown in the figure below. After the java -jar part, the first argument is the apktool location, next is d which stands for decompile, then -f to force delete the destination directory (not necessary if the directory does not exist) and -o to give the name/path of the directory where the decompiled files will be written ( if omitted, they will be written in the current directory), followed with the path of the destination directory, and the last argument is the path of the apk that we are disassembling.

Fig. 3.5 Running the apktool to disassemble the app that we want (name redacted)

After that as a next step we want to study the code, but not the bytecode, since it is a Machine code and very hard to read and understand from humans. So, we use jadx to try to decompile the code and make it appear more human readable. What we are doing is static analysis, but we can also do dynamic analysis by using a debugger for example IdeaSmali.

The process of static analysis is a hard process that takes a long time and a lot of patience, but I will go faster in the explanations here.

We first try to locate the files that we are interested in, by searching for strings related to the values we want to change, since strings are hardcoded most of the time.

As seen in Fig. 3.6, we were able to find that the “coins” string is used as a key to get the value from the SharedPreferences (an object to store data) of the app. So now we will try to see where this set is and try to find where the initial value of the variable is set. Since the values in SharedPreferences are set with the putInt function we search with the keyword: putInt(“coins”

Fig. 3.6 coins string used to get value from SharedPreferences

As we can see in Fig. 3.7, the function where the value of coins is changed is g0, so we search for the usage of that function

Fig. 3.7 Third use of the String “coins”, and the one we are interested to find g0 function usage

After searching for the usage of g0, we find that the best possible result would be the one where variable Q4 is used as a parameter, since Q4 is initialized with 0 in the beginning as seen in Fig. 3.8, same value 0 as our coins. So, we will try and modify that variable in the bytecode file.

Fig. 3.8 the value of the base coins is Q4

Fig. 3.9 Q4 is initially 0

After we open the bytecode files, we search for the Q4 variable. As we can see from Fig. 3.10 we locate the code where the variable is set. The variable gets the value from register v9, but we can’t just change that value of v9, without knowing it’s previous value and previous type, since we will change it to a 32 bit variable, while it could be another type and cause the game to crash in case we do the wrong modification.

Fig. 3.10 Q4 declaration in the Dalvik bytecode.

As we can see in Fig. 3.11, indeed the register v9 is declared as a 4 bit variable and has the value 0, so we will copy this line of code and paste it below the code that we want to change.

Fig. 3.11 v9 register initialization to 0

So, in figure Fig. 3.12, we can see that we pasted the previous v9 initialization instruction, after initializing the Q4 variable, and before that we add the const v9, 0x111111, which changes the type of the constant from 4 bit to 32 bit (which is the default if you omit size). The number 0x111111 is the hexadecimal value for the number 1118481.

Fig. 3.12 Changing v9 register to a high hexadecimal value before the instructions that sets it to Q4 gets executed

Now we can recompile and try if the changes we did are correct and won’t cause the game to crash.

Fig. 3.13 Recompiling and resigning the apk with apktool and apksigner

After running the game we can see that the value was changed from 0 in Fig. 3.14 from the original game, to 1118481 to the modified game. So our modification was a success.

Fig. 3.14 The value of coins in the original apk

Fig. 3.15 The value of coins in the modified apk.

IV. Conclusion

After studying the code of an android game in detail, we were able to modify it and also we were able to change the software behavior, so we can “benefit” from it. After recompiling and signing it, we left no traces behind, so the changes we made will not be noticed  and now we can start the game with an amount of coins that we desire.

By demonstrating this reverse engineering technique, we hope we can spread awareness to developers to be more careful with the code they write, so in the future they can minimize errors of this nature and try to hide their sensitive information more. So, we have to make sure that for critical variables that we would not want to be modified,  we should either save them on a server or try to obfuscate them and make it as hard as possible to be found.

At the very end, cracking games can have negative consequences for both the players and the game industry. Cracked games may contain malware or viruses that can harm the players' devices or compromise their personal information. They can also undermine the game's community and economy by encouraging piracy and cheating, which can discourage honest players from participating and ultimately reduce the game's popularity and profitability.

V. References

[1] Dalvik bytecode https://source.android.com/devices/tech/dalvik/dalvik-bytecode

[2] Jadx https://github.com/skylot/jadx

[3]  Apktool: https://ibotpeaches.github.io/Apktool/

[4] Mobile Hacking:  https://www.mygreatlearning.com/academy/learn-for-free/courses/ethical-hacking-mobile-platforms-and-network-architecture