Get inside the APK files

Disclaimer: Never attempt to reverse engineer applications that you have not developed. I am not responsible for any harm I may cause to external developers who use this tutorial. I insist that you must use this knowledge only to audit your own applications!

So, was your Android application pirated? Do you have purchases in the Google app, but someone posted a free full paid version on pirated websites? How is it possible?

Let's try to understand and decompile the APK file. Here is the guide. Not for hackers or hackers, but for developers, so you know better the weak aspects of the security of your application.

In this tutorial, I'll use Mac OS X, but the tools I'm using are cross-platform, and you can also install them on Linux and even Windows.

To begin with, you obviously need the APK file of the application that you want to reverse engineer. As it is your own project, you can obtain it from the app \ build \ Output \ apk folder of your project, or you can obtain it using ApkPure on your PC or from your device (you can make a backup copy of any of your installed applications without root) . example, with ES File Explorer).

Installing the necessary tools

Next, let's start with the installation of the necessary tools. Will need:

apktool to unzip the APK file in a smali project and repackage it.

apk-signer to sign your final APK file

IntelliJ IDEA and Smali Support Plugin (I have not tried installing it in Android Studio, but I think it should work)

Let's start with apktool. Go to this web page and follow the instructions. After that, you should be able to execute the apktool command from your Terminal:

Next, download apk-signer. Go to this page, click on the "Download" button near APK-Signer. It's just a simple .jar file with GUI, so you can open it like any usual application with a double click to run it on Mac OS X. You should see the following window:

For Mac OS X users, you do not have to specify the JDK path.

And the last part of our tool installation journey is the smalidea plugin. Download it from here, just look for smalidea - *. *. Zip on the page and choose the latest version. To install it, open IntelliJ IDEA, go to Preferences-> Add-ons-> Install add-on from disk ... After that, you will have to restart IntelliJ IDEA.

Now we are ready to begin.

Uncompile APK file

To decompile the APK file, open the Terminal and run the following command:

apktool d path / to / your / app.apk

By default, after executing that command, you should see a folder with the decompiled application in your Startup folder.

If you open the decompiled application folder, you should see the structure similar to this one:

I suggest you open IntelliJ IDEA, click File-> Open ... and choose the decompiled application folder in the next window. Now it is easier to edit files there.

Let's make changes

To begin with, we will try to understand the structure of the files. You can see the AndroidManifest.xml file in the root folder and you can also edit it as is, since it is the default Android manifest file.

In the res folder you can find the resources of the application: strings, values, draws.

The most interesting folder for us is smali. In cases of multidex applications, you can see the smali_classes2 folder - this is the location of the classes in the second .dex file.

We are going to open the smali folder. Here you can see the basic structure of all the packages included in the application. For example:

Of course, if you lower the tree, you will eventually see files with class names. But they are not .java or .kt, they are all .mali. And it is a way to interpret the code within the .dex files in a readable and editable format.

The syntax is freely based on the Jasmin / dedexer syntax and supports the full functionality of the dex format (annotations, debug information, line information, etc.)

Sometimes you will see a file with the name of the source file and many files with almost similar names:

These are internal classes. For example, each lambda has its own .smali file, as well as each internal class.

Then, finally, let's try to open any of these .smali files!

The structure of the folder should be similar to the structure of the source code (of course, if the application you have decompiled is not obfuscated), so you can easily find the classes you are looking for. Also, you can search IntelliJ IDEA, using double shift.

You may notice that the .smali files that are inside are really different from the usual source files. For example, here is a class declaration:

But do not worry,

In addition, you can see the declared static fields and, of course, edit them:

As mentioned above, the long and double primitives (J and D, respectively) are 64-bit values ​​and require 2 registers.

Basically, J means that it is a 64-bit value, and we can edit it, but keep in mind that this is a 16-bit literal.

And here is one of the method / function statements:

In this case, the name of the method is isUserSubscribed, it has a parameter with the name p2 with the Java list type, and it is a shopping list, which, by the way, is annotated as nullable.

Imagine that the method has a serious and reliable logic, many conditions and iterations, method calls to verify if the end user actually bought the premium subscription, but finally ends with this return code:

As you can see, in a branch if (cond_0), using the constant line / 4 p1, 0x1 we set the value "true" in p1, and in another branch if (cond_1), using the line const / 4 p1, 0x0 we put "false" to p1 and in both cases return p1. Basically, by changing 0x0 on the last line (and you can change it using IntelliJ IDEA or any other text editor), hackers can make this method return "true" and break all the premium subscription logic.

Of course, this is the most obvious case: try to hack the application, disable some purchase checks, the most primitive and simple. But by using the same tools, detractors can do much worse with your application, so be careful.

Build APK from smali

So, we have changed some codes here, try to build and run our modified APK. It's simple - simply execute:

apktool b path / to / your / decompiled / folder

After a few seconds, there will be a new APK file inside the dist folder that is inside the decompiled application folder.

But if you try to install it on your device, you will receive an error that says "Application not installed." It's because your APK file is not signed at all. Of course, a hacker could not sign it using the original keystore, of course, if he keeps his keys and passwords store in a safe place. Then, to execute it, we will have to sign it with a new keystore, or we can use an existing one. To create one, open apk-signer.jar, go to the "Key Generator" tab, fill in all the required information and click on "Generate key file". Now you can use this keystore to sign APK files.

In the Apk Signer tool, go to the "Signatory" tab.

Select the keystore that you generated in the previous step, complete the passwords and alias names, choose the APK file you want to sign and click the "Log in" button.

You will find the final installable APK file in the same place where you found an unsigned one, in the dist folder. Try to execute it and if you have done everything correctly, you should see the changes in the application.

What happens if I use React Native? I am safe?

Not really. If your application is written in React Native, with the same apk tool you can find the index.android.bundle file inside the assets folder of the decompiled APK folder.

To open it using IntelliJ IDEA, right-click on the file, Associate with file type ... and choose JavaScript. And the .js file is usually minified. Of course, you can edit it and rebuild the application, but it can be difficult to do so:

Just use js-beautify - to install it use:

pip install jsbeautifier

and execute it using:

js-beautify -o out.js in.js

Now you can find everything you want within this embossed .js file. With the embossed .js file it is much easier to read the JavaScript code. But do not replace the index.android.bundle file with an embellished one, because we have it only to understand the source code; that is why, after finding the required lines in the beautified file, replace what you want within the index.android.bundle file of the minimum font, and rebuild APK.

How to be safe

If you are suffering from piracy and you do not know how the intruders modified your APK, you can try to think how they do it and reproduce these steps with your APK, and then use that knowledge.

How to be safe? One of the possible solutions is to perform all the checks in the back-end, but in some cases it is not possible. But for really sensitive operations, linked in some way with your money or that of your users, you should do back-end checks anyway. Because the front-end is almost always reversible. Use the front-end only to validate the data, obtained from the back-end.

Also, remember to use ProGuard and do not forget to activate it for the release versions, it can help in some cases.