In a previous blog post, we covered how to use the ASM library to instrument Java code. In conjunction with instrumentation, ASM can also be used to modify classes and change how they behave entirely, often in dramatic ways.

Having gone over the Java classes of the application, you now wish to instrument them by adding logging information to let you track their activity. Since manually going through every file will take an exorbitant amount of time however, we will instead create a script to automatically edit the bytecode for us with the help of a useful library called ASM.

At some point, you will come upon Java classes that resist attempts at decompilation. Whether a method or an entire file, all seem to be impervious to the decompilation software that you use. More often than not, this means that you are on the right track, and that the key to reverse engineering the application lies right ahead.

Often times, you will be faced with compiled Java code that you must analyze. With .class files in particular representing a significant amount of most applications’ programming, being able to decompile them can grant you unique knowledge of the inner workings of the system.

All Android apps come in one basic format: the APK, or Android Package Kit. Similar to an EXE file on windows, when you press install on the Google Store, the APK is downloaded onto your phone, and installed. It follows that, by downloading it instead onto your computer, you could theoretically open it, and be able to look around and see all the files that the creator made.

Having extensively modified your Android application’s APK file, you now wish to install it on your phone and give it a run. Unfortunately, adb install refuses to cooperate, and instead returns INSTALL_PARSE_FAILED_NO_CERTIFICATES. To get around this, we will need to imitate an official publisher from the Google Play Store, and sign our new APK file with a useful little command called jarsigner.

At some point or another, you will need to obtain a snapshot of your Android application’s RAM. Simple and easy to pull off, doing so will almost certainly be helpful to your reverse-engineering efforts, regardless of the type of application you have. For that, we will use the wonderful program going by the name of GDB.

Many popular Android applications are made with the Unity 3D engine. Written in C#, the game’s code, physics, and programming are packed into an assortment of assemblies (DLL files), often either encrypted or obfuscated.

Sometimes, in order to throw off your efforts, Android apps will create a whole boatload of threads at a very high rate. Faced with random context switches and a generally unstable debugging environment as a result, it is always helpful to create a list of where all threads are initialized, and statically analyse them one at a time rather than attempt to do so all in one go. The most simple way to do so, is by latching onto a peculiar little system function called pthread_create.

Hello there! At some point in your life, you must have downloaded a game and had gone “Wow! There is so much content it has to offer, I can’t even put it in words how fun it would be to play if I only had enough time (and/or money) to grind through the steep difficulty curve.”