Reverse Engineering Android Applications to Discover Hard Coded Credentials (APK’s)

Mobile Applications have quickly become a part of our daily lives. To date, there are over 2.6 million applications on the Google Play store alone. In this article we will be looking at reverse engineering Android applications to find hard coded credentials. These credentials, in a real life scenario, would likely be hard coded API keys.

What is an APK File?

Android applications use a master XML file known as the android manifest, we will also be looking at how to investigate this file to understand how an application works.

Android Package Files (APK) are a collection of resources and files, such as code and images required to run an android application in an archive format. APK Files are installed on an android device in a similar way that a .exe or .dmg file would be installed on a PC or Mac.

Typically, an APK is downloaded from the Google Play store. To increase security each APK is signed by the developer to prove its authenticity. There are many applications that have been developed for various purposes that are not released on the Google Play store, and therefore have to be downloaded from third-party sources.

APK files for new Android builds are often leaked early. A user may download these to get the new features before a standard user that waits for the update. Another example is that a user may want to download an earlier version of an application that is no longer available on the google play store.

It is not advised to download any third-party applications as they may contain malware.

What is inside an APK File?

Typically, the following files are included in an APK as a minimum:

Android Manifest file

The Android Manifest file is located in the root of a project and contains information about how the application works, the activities, and some security settings. The manifest file dictates the minimum SDK versions allowed to run the application, if the application can be backed up, and much more. This is the first thing to look at during a Mobile Application Penetration test, as it gives a good overview of the application and how it works.

Classes.dex file

This file will be targeted later in this article. At the moment, the file is almost unreadable to human eyes. Dex files are named “Dalvik Executables” and can be created by compiling Java applications.

/Assets folder

This folder is used to store html, fonts, mp3, image, and text files that are necessary for the application to function correctly.

/lib folder

This will typically contain linux shared object files (.so). If an attacker can find a way to modify and get execute them, it may result in code execution, however, this is rare possible.

/META-INF folder (consisting of)

• Manifest.mf – This contains resource files and their SHA1 hash. Viewing this file shows a list of hashes in base64 format.
• CERT.RSA – Developers signing certificate to prove the authenticity of the application.
• CERT.SF – Signature File.

Viewing the AndroidManifest.xml file

To view the androidManifest.xml file we need to use apktool to de-package the apk binaries. This will leave the AndroidManifest.xml file readable by text editors.

Current Directory:

Running apktool to de-package the .apk file.

Java – jar apktool_2.4.0.jar  d Test-app.apk

The above screenshot shows the “Test-app” directory created by running the apktool. We are now able to browse the “Test-app” directory and the AndroidManifest.xml file is in readable format.

./d2j-dex2jar.sh classes.dex

This creates the file “classses-dex2jar.jar”

Now we can use JD-GUI to open the new Java file with the command below, but firstly, let’s have a look at the AndroidManifest.xml file.

Java -jar jdgui.x.x.x classes-dex2jar.jar

Reading the AndroidManifest.xml File

<uses-permission> shows us that the application requires internet access, meaning that it is likely talking to an endpoint and may require some form of authentication.

Android:allowbackup=“true” – This tells us that the application can be backed up by third-parties.

android:debuggable=“true” – This tells us that the application can be used in debugging mode.

The final highlighted area shows that there are two activities, main and launcher.

Digging Deeper

Viewing the AndroidManifest.xml file can give us a lot of information about the application, how it works, and how it’s supported. Now, we can look deeper into the android application and view the Java source code (or at least a very close version of it).

Open the Jar file with JDGUI.

Let’s have a look inside the main activity “access” that we discovered earlier in the AndroidManifest.xml file. There was also another activity called “files” that we found.

Here we can see that this code is getting data sent via a Unique resource ID (2131492973). We can check what this ID is referring to in the R.class file.

The access.class also refers to another unique resource ID in onCreate which means that this will be executed, let’s have a deeper look.

Confirm that this is the unique resource for the activity_access class;.

Now that we have found the unique ID for the activity_access, let’s have a look in the layouts file to see how it is used. This is located in /res/layout.xml and can be opened in any text editor.  Here we can see all of the elements that build the first activity on load.

At the bottom of the above file, we can see that access class is called upon clicking the applications submit button.

(onClick) –

The Access Class is executed when the button is pressed. It gets the value of what is entered from the unique resource id, creates the intent to files.class, enters the code that is sent, and starts a new activity.

Now that we understand how the main activity access.class is being called, let’s have a look at the files.class

In the files.class we can see that username and password are being stored in a unique resource ID. Let’s have a look at the R.class file to confirm that these values relate to user and password.

Now that we have discovered that the username and password are stored in a unique value, we can check the strings.xml file. This file is used to store hardcoded strings. Strings.xml is located at Res > Value > strings.xml

The screenshot above of the strings.xml file shows the “Pwd” and “user” values.

To Conclude

Hopefully, you should now have an understanding of the tools required to reverse engineer android applications, the data structure of an APK file, and understand the significance of the AndroidManifest.xml file.

Enjoying our content? View our last blog post here.

Click here if you would like to find out more about our Web Application Testing Service.

‍