Introduction - Reverse Engineering Android Applications

Reversing APK Files

The first step in the reverse engineering process is to retrieve the APK file. If the application is on the device and it has adb access you can run the command below to list all of the packages on the device. If you know the name of the application you can use grep to look for the specific application, in this case insecurebank.

To pull the application from the device you need to get the full path name of the APK file for the package.

Once you know the path you can run 'adb pull to retrieve the APK from the device.

Now that you have the APK file you can rename the file extension as a zip file and use the unzip command to decompress.

Building Android Applications

Developers create Android applications in the Java programming language. These files are then compiled into .class files. The class files are then given to the dx tool in order to generate .dex files.

These .dex files are then packaged as an APK with other files.

The classes compiled in dex format are understood by the Dalvik Virtual Machine and allows the application to be executed during runtime. Each application running on an Android device has its own Dalvik Virtual Machine

Decompiling Dex Files

In order to decompile the application we need to locate the classes.dex file, we want to convert this back into a Java JAR file. In Appie you can use the 'd2j-dex2jar classes.dex' command to convert.

The JAR file can now be decompiled into Java source code using JD-GUI.

Analyzing The Code

You can now go through the various classes to analyze the application logic, identify sensitive information etc. In the example below we can see the DoLogin class has a hardcoded developer backdoor.

If you login with the username - devadmin without a password it will give you access to the application.

We can confirm that the username 'devadmin' has allowed us to access the application.

The page below is the landing page post-authentication.

References: http://resources.infosecinstitute.com/android-hacking-and-security-part-18-introduction-to-reverse-engineering/

Android Unintended Data Leakage

Unintended data leakage occurs when a developer places sensitive information or data in a location that is easily accessible by other apps on the device.

Android Logs

Logging functionality is used for debugging purposes during development. Android has a class called Log that can be used from within the application to place debug information in a central log. Up until Android 4.1 Jelly Bean applications with the READ_LOGS permission could access log entries from other applications. Therefore any application running on a device that has a version below 4.1 or is rooted is still vulnerable.

This tutorial will demonstrate how sensitive information can be leaked via Android logs. For this demo I will use Insecure Bank, this application contains a number of Android vulnerabilities, if you want to find out how to install click on the link here

Once you have the app setup you should see a login page similar to below. The login credentials to access the app are:

• dinesh/Dinesh@123$
• jack/Jack@123$

Prior to logging in we want try and capture any sensitive information. There are a number of ways of doing this, you can use the logcat option in the Eclipse IDE or adb logcat. A very useful script that comes packaged in Appie is PID Cat, this script filters the logs by application package making it easier to identify information coming from that particular application.

In Appie simply type pidcat com.android.insecurebankv2 (package name). Then log in with the credentials above, you should now see the same credentials displayed in the log.

Another example using the insecure bank application is on the transfer amounts page. You can click on the 'Get Accounts' button and then enter an amount to transfer.

Once you hit the transfer button, the accounts and logs will show up on PID Cat. Again this could be read by other applications.

Logging is an essential feature during development but can inadvertently expose sensitive information. Although it seems trivial, it can lead to serious risk depending on the data that is leaked.

Clipboard Leakage

Another area were sensitive data leakage can occur is from the clipboard. Users tend to copy/paste quite a lot on mobile devices as its easier than typing. If the application allows for the copy/paste of sensitive information from one app to another then it is possible that a malicious application could read it also.

If you take the example below from Insecure Bank, the user can copy out transfer statement information.

We can then use the post-exploitation module in drozer to read the clipboard. To install this module type 'module install clipboard'. Then run the command below

References: https://www.owasp.org/index.php/Mobile_Top_10_2014-M4
                    https://github.com/dineshshetty/Android-InsecureBankv2
                    https://manifestsecurity.com/appie/