The open nature of Android may lead to a potential problem for some developers — that is, without proper precautions, the original source code can be retrieved and modified. While this isn’t a concern for every developer, for some it could be a nightmare.

Reverse engineering Android apps

The nature of Java (the predominant programming language for Android apps, with the exception of native code) is that the code is not compiled down to machine code; it is compiled to an intermediate format that is ready to be run on a variety of hardware platforms. While this allows great portability, it also leaves the code for Android apps, as present in the APK (Application PacKage file), available for extraction.

While I won’t cover it here, the tools to decompile the DEX file (the code archive) from an APK back into a JAR archive are widely available and easy to use. I suggest you poke into your own APK to see what can be extracted. It is a bit startling what can be discovered. The image resources are plainly visible in the APK archive, and with just a few seconds of work, the original code can also be seen, with variable and method names intact.

Not all developers will care about this; some enthusiasts will want to modify apps in a constructive way. However, when commercial interests are involved, there can be a number of instances where it is desirable to protect your app.

Possible reasons for attacks on your code

One possible attack is for the purpose of allowing gamers to cheat. This can affect the gameplay of others, which eventually affects the bottom line of the vendor. While large online multi-player franchises like World of Warcraft have invested in a sophisticated anti-cheat mechanism, I am not aware of significant effort in this area by Android developers.

I have heard some developers voice a concern about piracy. The official Android documents on their LVL (Licensing Verification Library) indicates that you should obfuscate your code to prevent someone from modifying your app to simply cut the license check out.

Every developer must decide how much effort to spend to cut off the non-paying “customers,” but this can be a greater concern if resources are consumed by each new user of the app. Paying to support a few hundred thousand freeloaders can put a strain on any app with significant infrastructure.

The same concern with licensing applies to in-app purchasing — a modified version of the app could be made to bypass the purchase mechanism and provide free access.

Another big concern is the security of important data. A more sophisticated attacker might be able to gain access to information that is dangerous outside of the world of apps — financial information, for example.  Users tend to expect that developers will safeguard the information that they have been entrusted with.

There could be many reasons beyond these, but some of the basic methods of protection are the same.

Protections and workarounds

Without a doubt, the simplest method to protect an app is to enable the obfuscation in ProGuard. This freely available tool is already built into the Android toolkit. 

ProGuard can not only remove unused code, it can make it much harder to read the decompiled code.  For example, “DescriptiveClassName.descriptiveMethodName()” becomes “A.b()”. This immediately makes it more difficult to decipher the original code.

ProGuard is not enabled by default because it can take a little work to configure it properly. Some libraries and SDKs require a few modifications to the ProGuard configuration to prevent vital classes from getting pulled out or renamed. Since ProGuard is only run when producing the release version of the app, be sure to test the release version early in the test cycle to iron out any quirks related to libraries you use and update your configuration.

To enable ProGuard, simply uncomment the “proguard.config=” line in your project’s “project.properties” file. Ta-da! The default configuration has been enabled.

Note that the ProGuard documentation on the Android site refers to “proguard.cfg,” which is the configuration file used in an older version of the Android tools. You want the new version that uses “proguard-project.txt,” because a lot of common configuration has been done for you.

Beyond the basics

Beyond ProGuard, there are other obfuscation technologies that can be used to protect your Android apps. For example, the same author of ProGuard has created an Android-specific version called DexGuard that has more advanced features such as string encryption.

No single technique is enough to thwart a determined attacker. Security is a process, not a one-click solution. However, the amount of protection gained by simply enabling ProGuard is worth consideration by all Android developers. Developers with more sophisticated needs will have to spend more effort finding and configuring the right solution.