Android Security Part 1 - Reverse Engineering Android Apps

Google introduced automatic support for ProGuard, a code obfuscation tool, in ADT as early as December 2010 in version 8.0.0. It is integrated into the build system to make code obfuscation a pretty “straightforward” process. Since then, Google has encouraged—albeit not proactively—developers to enable ProGuard to prevent hackers from reverse engineering and hacking applications. Despite enabling ProGuard, however, a very persistent hacker may still be able to reverse engineer a ProGuard-ed application but the task becomes exponentially harder. There are other good practices developers should abide by to ensure a secure app, but code obfuscation should always be the first line of defense (more information on code obfuscation on Android here and here). Out of curiosity, I went ahead and did some reverse engineering on some popular apps (all have more than 1 million downloads on Google Play) that may contain user sensitive information and un/surprisingly, 10 out of 12 weren’t doing some sort of code obfuscation. I’m sharing in this post what and how I did that to point out 2 things: (1) how easy it is to reverse engineer an app, and (2) to increase awareness of the importance of security specifically code obfuscation.


Methodology


My methodology was simple, in fact, a quick Google Search on ”Android Hacking” should give anyone the tools to do this. Below are the steps:

  1. Obtain the .apk files of the applications of interest by using Astro File Manager. Simply navigate to “tools” in the options menu, “Application Backup”, and then select all the apps you’re interested in. Once backup is perform, an image is obtained of the apps and the corresponding .apk files will be stored under your SD card’s backups/ directory.
  2. Unpack .apk file using unzip.
  3. Disassemble compiled classes.dex file using baksmali. This will generate tons of .smali files.
  4. Perform static analysis on .smali files.

For step 4, if an application does not have code obfuscation, then all static constant declarations can be read in plain text (red flag!). You can still take things a step further, for instance, by writing smali code and retracing your steps to create your own custom hacked-out app.

Results

Understanding smali code is pretty straightforward event without prior knowledge of the language especially when it comes to finding static member fields. Declared String values are human-readable. Here are a few screen-shots of what I’ve found:
Fig. 1 Fig. 2 Fig. 3 Fig. 4

Conclusion

ProGuard creates drastic improvements in security. Here’s an example of how smali code would look like with ProGuard on vs. with ProGuard off. Say your Activity has a static member field HACK_THIS:
Fig. 5

When we disassemble the resulting .dex file without ProGuard enabled, we get this:

Fig. 6

Whereas code obfuscation using ProGuard results in:



From this comparison, you can observe the following: enabling ProGuard in this situation removes the human-readable static member field whereas disabling it leaves it in plain-text in smali assembly code. Although the content of the String gets copied wherever it is used in code as seen on line 39 in Figure 7, the context of what that String represents is virtually unknown. Again, a persistent hacker may deduce what that means through brute-force, but ProGuard increases the complexity of the task. ##### Any tips on how to create a secure Android app? Leave a comment below!

Comments