How to make apk Secure. Protecting from Decompile

Basically, there are 5 methods to protect your APK being cracking/ reversing/ repackaging:

1. Isolate Java Program

The easiest way is to make users unable to access to the Java Class program. This is the most fundamental way, and it has a variety of specific ways to achieve this. For example, developers can place the key Java Class on the server, clients acquire services by access relevant interfaces of the server rather than access to the Class file directly. So there is no way for hackers to decompile Class files. Currently, there are more and more standards and protocols services provided through interfaces, such as HTTP, Web Service, RPC, etc. But there are lots of applications are not suitable for this protection. For example, Java programs in stand-alone programs are unable to isolate.

2. Encrypt Class Files

To prevent Class files from being decompiled directly, many developers will encrypt some key Class files, such as registration number, serial number management and other related classes. Before using these encrypted classes, the program needs to decrypt these classes first, then loading these classes into JVM. These classes can be decrypted by hardware, or software.

Developers often loading cryptographic classes through a customed ClassLoader class (Applet does not support customed ClassLoader because of security). Customed ClassLoader will find cryptographic classes first, then decrypt them. And finally loading the decrypted classes to JVM. Customed ClassLoader is a very important class in this protect method. Because it itself is not encrypted, it may be the first target of a hacker. If the relevant decryption key and algorithm have been overcome, then the encrypted classes can easily be decrypted.

3. Convert to Native Codes

Convert program to native codes is also an effective way to prevent decompilation. Because native codes are often difficult to be decompiled. Developers can convert the entire application to native codes, or they can also convert only key modules. If just convert key part of the modules, it will need JNI technology to call when Java programs are using these modules. It abandoned Java's cross-platform feature when using this mothod to protect Java programs. For different platforms, we need to maintain different versions of the native codes, which will increase software support and maintenance workload. But for some key modules, sometimes this solution is often necessary. In order to guarantee these native codes will not be modified or replaced, developers often need to digitally sign these codes. Before using these native codes, developers often need to authenticate these local codes to ensure that these codes have not changed by hackers. If the signature check is passed, then developers can call relevant JNI methods.

4. Code Obfuscation

Code obfuscation is to re-organize and process Class file, making the treated codes accomplish the same function (semantics) with the untreated codes. But the obfuscated codes are difficult to be decompiled, i.e., the decompiled codes are very difficult to understand, therefore decompile staffs are hard to understand the really semantics. Theoretically, if hackers have enough time, obfuscated codes may still be cracked. Even some people are developing de-obfuscate tool. But from the actual situation, since the diversified development of obfuscation, the mature of obfuscation theory, obfuscated Java codes can well prevent decompilation.

5. Online Encryption

APK Protect was an online encryption website for APK, but activity has apparently been discontinued since 2013 or so. It provided Java codes and C++ codes protection to achieve anti-debugging and decompile effects.

I originally suggested you use this last method for it could save you more time. Based on my experience, it was very simple to operate and it wouldn't take long time.


With Jellybean this has now become a possibility.

$ openssl enc -aes-128-cbc -K 000102030405060708090A0B0C0D0E0F 
-iv 000102030405060708090A0B0C0D0E0F -in my-app.apk -out my-app-enc.apk

$ adb install --algo 'AES/CBC/PKCS5Padding' --key 000102030405060708090A0B0C0D0E0F 
--iv 000102030405060708090A0B0C0D0E0F my-app-enc.apk
        pkg: /data/local/tmp/my-app-enc.apk
Success

Please read the following blog post for further details


If this is secret information that must not fall into the hands of your users, you cannot secure it. It is fundamentally impossible to put information on a device (code or data), and have your application access it, but not allow someone with the device to have access to that information.

Encrypting the information is pointless from a security point of view, because your application has to contain whatever is needed to decrypt it in order to use it, and a sufficiently motivated attacker can always extract that and decrypt it on their own.

All you can do is make it more annoying and time consuming to get access to that information, which only helps if there's not really that much of a need to keep it secret. This is what using proguard to obfuscate your .apk file can do.


Have you considered sqlite encryption? See this thread - sqlite encryption for android

As for protecting your .apk, try obfuscating your code using proguard. See http://developer.android.com/guide/developing/tools/proguard.html


You can try 'Anti Decompiler(Android)Trial'

https://play.google.com/store/apps/details?id=com.tth.AntilDecompilerTrial

It makes something Proguard doesn't:

  • Hide all const values (string, character), you will never see clear text like "my key", "my val"... in your apk file
  • Obfuscate file name, which is referenced in AndroidManifest.xml
  • Add fake code to your source code. Event the powerful decompilers likes: dex2jar, jd-gui,... can't reverse exactly your apk file. Most of functions will show with comment 'Error'.

=====

  • After transforming, if you give someone your source project, it will be nearly impossible to read and understand.
  • This solution doesn't exclude Proguard, You can combine them together. (function, field Obfuscation of Proguard is better than Obfuscation features of this solution)