Reverse engineering an Android application. This article shows how to reverse engineer an Android application, first by using d2j-dex2jar to convert the .dex file into .class files within a compressed .jar file and then using a Java decompiler (jd-gui in this case) to decompile the converted code. It also emphasizes, from a security point of view, why we need to do this process and how we look to understand how the application works, if there is any sensitive information hardcoded in the source code and whether or not any code obfuscation was applied to the original code.
When no code obfuscation is applied to an Android application, reverse engineering it can yield decompiled code that is very similar to the original source code. From a security point of view, this can be used to check if any sensitive information has been hardcoded within the code, in trying to understand how the code flows to find any possible vulnerability or in checking whether or not any kind of obfuscation has been applied to the code.
Converting .dex into .class files
Once you have your target apk at hand, you can first use d2j-dex2jar on it; this tool takes the .dex file out of the apk and converts it into Java .class files. If you don’t already have this tool installed, you can get it from here. Once ready, pass the target apk file as parameter to the tool and you’ll get .jar file as result, like shown below:
Decompiling into Java code
The generated .jar file contains the compiled Java code (.class files), now we need to decompile these files in order to get a version close to the original code (.java files). There are several options out there when it comes to decompiling Java code, in this case we will be using the Java Decompiler project through the provided GUI, jd-gui, which can be obtained from official site, here. If you downloaded the decompiler as a jar file, then you can run it as shown below:
Once jd-gui comes up, you can just go ahead and open the .jar file generated by d2j-dex2jar:
After decompiling the generated .jar file, you will see a tree of decompiled packages and classes on the left pane, here you can explore all the code as it was decompiled. For code that was not obfuscated, you’ll get a result very close to the original code, if obfuscated, you’ll get a version of the code that’s hard to read and understand, hard, not impossible.
Hardcoded sensitive information
As in any other system, hardcoding sensitive information on an Android’s application code is mostly a bad idea, if you are able to reverse engineer a target application, you should pay close attention to any misplaced sensitive information, misplaced in the sense that on a Client-Server architecture (which is the case for most of Android applications nowadays), all sensitive information should be handled at server side.
Understanding how the app works
By doing this you can understand the inner workings of the application and how it communicates with other components, like services, providers, receivers, local databases, etc. This can help identifying any sensitive information flowing between application and components as well as any possible weakness on that may affect those communications.
Checking for obfuscation (the goal is to delay/discourage the attacker)
From a security point of view, obfuscation is the means by which we delay or discourage an attacker from understanding how the application’s code was initially written, obfuscation this is achieved by “scrambling” the code enough to make it hard to read and understand, effectively concealing the original code. Class, variable and method names are usually obfuscated and substituted with a series of strings that take meaning away from the objects. Here, we say we only delay/discourage a possible attacker because, with enough time and ability, said attacker will still be able to gain a pretty good understanding of the obfuscated code.
Conclusion
Reverse engineering an Android application can lead to identify possible weaknesses on the application’s code, like hardcoded sensitive data, how the application works or if any obfuscation was applied to the original code. From a security point of view, it is always recommended to obfuscate the application code in order to delay or discourage a possible attacker from understanding the inner workings of the application, however, with enough time a ability, an attacker can still get to know these details. Application sensitivity and risk appetite plays a key role in defining the level of obfuscation we want to implement for a given case.
Reverse Engineering a Xamarin Application.
Recent Comments