It amazing how many people I talk to, even in the mobile world, who don’t know how easy it is to reverse engineer most Android apps. Only this week, hacking Android apps became even easier with the introduction of an online tool that can reverse engineer an app. Of course, this has been able to be done since Android’s inception except that it needed the use of command line tools that put a lot of people off.
The ability to reverse engineer an app exposes some threats for app owners/developers…
- The possibility of hackers producing copies of apps for profit, to get in app purchases for free or with the possibly with added malware
- The possibility of IP theft in that people can copy your ideas or discover how to use your server APIs
- The possibility of user data theft in that encryption methods/decrypted data can be exposed
So what can app owners/developers do about this? The first line of defence is Proguard that obfuscates code. It mangles identifiers in the code making the code much less readable. Hence obfuscation is less of a solution and more of a deterrent.
It’s very easy to turn Proguard on for release builds (change project.properties in Eclipse). However, it can get tricky on larger, complex projects, especially those that include 3rd party libraries as there are often particular things that must not be obfuscated in order for the app to work properly. Another problem area is crash logs that also become obfuscated making it very difficult to track down end-user problems. Crash log analysis tools need to be kept up to date with the Proguard output obfuscation transformations so that crash log obfuscations can be ‘undone’. Hence, because of these complexities, many time-starved developers end up shipping code that isn’t obfuscated. It’s for this reason I advise those commissioning/designing/specifying apps expect/plan for extra time that will be needed to resolve obfuscation issues.
Another possibility, for security sensitive apps, is to pay for more advanced obfuscation and encryption with a product such as DexGuard. However, as with Proguard, the more you protect the harder it will be to resolve problems caused by the protection itself and end-user triggered problems in the code being protected.