Saturday, May 26, 2012

Cheating the Android

Yarr everybody,

Long time since my last post, and today I’m returning to an old subject that I like very much. Cheating in games. And this time Android games.
I include in this post a small tutorial about patching an Android application, followed with introducing a big problem I’m facing in my attempts to cheat in various games. If you are already familiar with the technique of patching Android apps you can skip straight to the last paragraph where I talk about the problematic aspects of it. I would love to hear any comments the readers might have about my methods or any tips and tricks that might make the process easier to endure.

The Tutorial part:
I would walk you through the following steps:

  1. Getting the binary
  2. Unpacking, Disassembly and Decompiling it
  3. Finding a good place to patch
  4. Patching
  5. Repacking, ReSigning and ReInstalling the app
  6. Having fun

Setting up:
For these tasks you are going to need a rooted Android device (In some cases the emulator could do), and the standard ADK tools installed.
First enable the USB debugging from the Settings->Applications->Development menu, and connect to the computer with a USB cable. Now check the connection using the “adb devices” command. If the ADB can’t find the device, recheck the cable, the drivers and the adb.
Tip for those of you who use a Samsung Android device: the fastest way to get the right drivers is by installing the SamsungKies.

Step 1 Getting the binary
To get the binary of the application in target, you can simply search the right APK under  /data/app where usually APKs are stored. Or you can:
Run the application

  • Connect to the device with adb
  • Run “adb shell”
  • Run “su” (If needed)
  • Run “ps” to find the process id.
  • Run “ls -la /proc/PROCESS_ID/fd” and search in the long list of file descriptors for the apk file.
  • Pull the file from the device using the “adb pull” command.

Step 2 Unpacking, Disassembly and Decompiling it
For this step we will get to know not one but three tools to work with APKs
1. apktool
2. dex2jar
3. jd
The apktool would be used to unpack the apk file into its inner components. Using the command “apktool d APK_FILE OUTPUT_DIR”,  you can produce a directory with all of the components that makes the APK including a dir called smali that contains disassembly of the Dalvik bytecode. The smali files are text files that can be edited to make a patch. The directory can be repacked into an APK simply with the command “apktool b CONTENT_DIR OUTPUT_APK”.
Another tip: If you are facing any trouble during the repacking, you can try to unpack with “-r” flag “apktool d -r APK_FILE OUTPUT_DIR”, to leave the resources untouched, sometimes, the source to many problems is the resources. If you are not trying to deface the application don’t bother solving these problems.
The 2nd and 3rd tools are used to produce a decompiled, more readable code, and they are not a must for patching. The principle, is to open the APK file with a standard unzip tool, find the classes.dex file in it, use the dex2jar tool to convert the dex to a jar file, and decompile the jar with the Java decompiler.

Step 3 Finding a good place to patch
Now you’ve got lots of decompiled Dalvik code, use your reverse engineering talent to find a good cozy spot for your patch, or any other kind of cheats you would like. Note that some applications use a native arm code combined with the Dalvik code, which is usually found under the lib subfolder and could be disassembled with IDA pro as a ELF ARM (LE) binary.

Step 4 Patching
Patching, either by changing a smali file or by patching a lib file. Note, that the smali code is not the most familiar assembly, but I find it very intuitive and easy to understand.

Step 5 Repacking, ReSigning and ReInstalling the app
Repack using the apktool: “apktool b CONTENT_FOLDER OUTPUT_APK”. Now if you try to install the APK you just made, you would most probably get an error code that says “INSTALL_PARSE_FAILED_NO_CERTIFICATES”. In that case what you need to do is to use the signapk tool found at to sign the apk, you can use the sample certificate and key that are shipped with the tool.

Step 6 Having fun
Have fun.

The big problem:
Now if one would follow the exact steps trying to patch a game such as DrawSomething he would soon find out that most of the code is not in the Java nor in the native ARM binary. Instant the interesting part is found in another binary file called DrawSomethingFree.s3e, which is a binary file of the Marmalade SDK. Marmalade is a platform for developers to create games for both iOS and Android at the same time.
If one would try to decompile the Templerun game he would soon find a very similar story written in Mono for android. Mono is a C# like SDK for developing applications for both iOS and Android. Now this makes no sense, C# is a language made by Microsoft mostly optimized for Windows x86 platforms, why adapt it to Android, which handles Java like code naturally, is there really a benefit in C# coding style over Java? And if so is it worth the effort and the overhead of making a new VM to execute CLI code on Android?
Researching even further, I found out that there are awfully lots of such cross platform SDKs running everything from C to Lua including Python and Javascript. Each of them required understanding a new unknown homemade file type with new kind of bytecode encoding of some kind of imitation of a standard language.
I’m looking for any help from people on researching and understanding these files and how to disassemble and patch them for the better good.
So if anyone knows anything about the internals of any of the following:

  • Widgetpad
  • Whoop
  • RhoMobile
  • Shiva3d
  • SIO2
  • Unity
  • Corona
  • PhoneGap
  • Titanium Mobile
  • cocos2d-x
  • Edgelib
  • Moai
  • Mono
  • MoSync
  • Mominis
  • Marmalade
  • Simple DriectMedia Layer

I would be more than happy to learn more about it. And if anyone knows of any other cross platform environment, please let me know, as I’m trying to make some knowledge base about them.