DIVA Android App — Walkthrough

Figure 1.0

Hi,

In this article we are going to crack DIVA Android Application. If don’t setup your android pentesting environment, Click Here.

To download DIVA app Click Here.

Installation:

I have setup Platform Tools in environment variables. If you do not setup you have to place platform tools and apk file in same location or provide full path of their location.

In order to install the Diva application run the Android Virtual machine.

Figure1.1

Either you can Drag and Drop the APK file of DIVA on Android VM or you can install it with Android Debug Bridge (adb). Installation with ADB wil be discussed here.

Open Command Prompt and Navigate to the location of DIVA APK file.

Figure 1.2

Now run following command:

adb devices

This command will show us status of any android device running on our system or not as shown in figure below 1.3:

Figure 1.3

As VM which we started earlier is running, now it’s time to install DIVA application. Run command given below and shown in figure 1.4:

adb install diva-beta.apk

You will get success status printed on command line as shown in figure 1.4:

Figure 1.4

Icon of DIVA app will also apprear on your VM as shown in figure 1.5 below:

Figure 1.5

Tap (Click) on the DIVA app Icon to launch the application.

Figure 1.6

INSECURE LOGGING:

Before solving this challenge please visit this LINK and read it. It is highly recommended.

Tap on Insecure Logging Button. A new activity will appear as shown in figure 1.7 below:

Figure 1.7

Now before typing on this screen go to your command line and execute command written and shown in figure 1.8 below:

adb shell

Figure 1.8

Shell will open there type the command:

logcat

Once you enter command logs will start appearing in front of you.

Figure 1.9

Now go to the Android VM and there enter credit card number

Figure 1.10

Now go back the the command line where logs are appearing you will find there Credit Card Number in plain text as shown in figure 1.11 below:

Figure 1.11

Here Insecure Logging challenge is completed.

HARDCODING ISSUES - PART 1:

Before solving this challenge please visit this LINK and read it. It is highly recommended.

Tap on Hardcoding Issues - Part 1 Button. A new activity will appear as shown in figure 1.12 below:

Figure 1.12

As this is hardcoding challenge this mean the Vendor Key is hardcoded in the application. In order to get the hardcoded key we need to do Reverse Engineering of this application.

First convert the APK file into RAR file by only changing the extension.

Then Extract the RAR file. You will get DEX file along with other files and folders as shown in figure 1.13 below:

Figure 1.13

Now convert this classes.dex file into jar file with Dex2Jar tool. Go to Command Prompt and enter following command:

d2j-dex2jar classes.dex

A converted jar file with same name as dex file will appear in your folder as shown in figure 1.14 below:

Figure 1.14

Now access this JAR file with JD-GUI which is Java Decompiler.

Figure 1.15

Now we got the vendor’s secret key. Enter the Secret key to get access in app as shown in figure 1.16 below:

Figure 1.16

Here Hardcoding Issue - Part 1 challenge is completed.

INSECURE DATA STORAGE - PART 1:

In order to complete this challenge we have to move around in Directories with the help of shell. But first review the source code of this activity. We can see that credentials are stored in Shared Preferences as shown in figure 1.17 below:

Figure 1.17

After accessing shell with adb go to /data/data/. This is the location where packages of all installed applications are stored. Find the package of diva application and then access it as shown in figure 1.18 below:

Figure 1.18

First enter username and password and save them before try to find them in these directories.

Figure 1.19

Now from shell find them. App is saving these credentials in shared preferences as shown in figure 1.20 below:

In order to view contents of XML file to get username and password type following command:

cat jakhar.aseem.diva_preferences.xml

Figure 1.20

Here Insecure Data Storage - Part 1 challenge is completed.

INSECURE DATA STORAGE - PART 2:

This is similar challenge to previous one but credentials are stored in different location.

Before going to solve this challenge save credentials from in application.

Figure 1.21

This time credentials were stored in database ids2 and in its myuser table as shown in figure 1.22 below:

Figure 1.22

In order to access database files from command line we have a tool in platform tools folder named “sqlite3”.

Type following command in linux (android) shell:

sqlite3 <database_name>

sqlite3 ids2

sqlite>.tables

This .tables command will show all of the tables available in that particular database.

to exit from this tool .exit command is used.

sqlite>.exit

This will return you to your previous shell on which you were working.

Figure 1.23

Here Insecure Data Storage - Part 2 challenge is completed.

INSECURE DATA STORAGE - PART 3:

Enter the credentials from application.

Figure 1.24

The credentials were stored in temporary file as shown in figure 1.25 below:

Figure 1.25

Let’s access those temporary file from shell.

Figure 1.26

Here Insecure Data Storage - Part 3 challenge is completed.

INSECURE DATA STORAGE - PART 4:

Enter the credentials from application.

Figure 1.27

The app is storing credentials in external storage.

Figure 1.28

We got the location, now access them from shell as shown in figure below 1.29:

Figure 1.29

Here Insecure Data Storage - Part 4 challenge is completed.

INPUT VALIDATION ISSUES - PART 1:

This challenge is about SQL Injection.

First try to enter single quote (‘) as input and check result.

Try to enter single quote twice (‘’) and then check result.

You will see the difference in the output of the toast.

Once you realize that your inputs are working then play with text field.

Figure 1.30

Here Input Validation Issues - Part 1 challenge is completed.

INPUT VALIDATION ISSUES - PART 2:

In this challenge we have to access local files using URL.

first let’s try to access Google as shown in figure 1.31 below:

Figure 1.31

Let’s try to change the URL and try to access a file from device.

file:////etc/hosts

You can see it worked in figure 1.32 below:

Figure 1.32

Now let’s try to access a file from shared preferences where credentials are stored. It is the file we saw in earlier challenges.

file:///data/data/jakhar.aseem.diva/shared_prefs/jakhar.aseem.diva_preferences.xml

Figure 1.33

Here Input Validation Issues - Part 2 challenge is completed.

ACCESS CONTROL ISSUES - Part 1:

Figure 1.34

Accessing credentials from “View API Credentials” Button is completely legal. There is no issue in it. We need to check that can we directly access credentials without going through this activity or this checkpoint. In order to do that first we have to get the name of activity which will appear after it, for that we take the help of logcat which is discussed earlier.

Run logcat command from android shell then click on “View API Credentials” Button a log will generated related to this which gives us name of next activity as shown in figure 1.35 below:

Figure 1.35

Figure 1.36

As we got the activity name. Now let’s try to access it from adb activity manager directly.

adb shell am start -n jakhar.aseem.diva/.APICredsActivity

Figure 1.37

As you can see we got access of API Credentials without any restriction or authentication. This also means that other apps can also access these credentials.

Figure 1.38

Here Access Control Issues - Part 1 challenge is completed.

ACCESS CONTROL ISSUES - PART 2:

First we have to de compile the application. We use APKTOOL for it.

On Command Line type the following command:

apktool_2.4.1.jar d diva-beta.apk

Figure 1.39

A folder of application name will be created in same directory of apk. From there open AndroidManifest.XML file:

Figure 1.40

Let’s open the Java code file and inspect there about any new thing.

Figure 1.41

Search this highlighted parameter in R.class.

Figure 1.42

In order to get the value of this chk_pin we have to inspect the strings.XML file which is located in application decompiled folder /res/values/string.xml

Figure 1.43

Let’s try to access the credentials with these details we have found and disabling check pin.

adb shell am start -n jakhar.aseem.diva/.APICreds2Activity -a jakhar.aseem.diva.action.View_CREDS2 --ez check_pin false

Figure 1.44

Now you will see in your VM Credentials appeared.

Figure 1.45

Here Access Control Issues - Part 2 challenge is completed.

ACCESS CONTROL ISSUES - PART 3:

Apparently we cannot access notes without pin. Let’s try to access activity using content provider.

adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes/

Figure 1.46

Here Access Control Issues - Part 3 challenge is completed.

HARDCODING ISSUES - PART 2:

Pull libdivajni.so file from VM using adb.

adb pull /data/data/jakhar.aseem.diva/lib/libdivajni.so

Use strings tool to get strings from libdivajni.so file.

strings libdivajni.so

After trying different strings finally highlighted string worked.

Figure 1.47

Figure 1.48

Here Hardcoding Issues - Part 2 challenge is completed.

INPUT VALIDATION ISSUES - PART 3:

In this challenge goal is to crash the application.

Figure 1.49

Enter any random but long string, that string will lead to crash the application.

Figure 1.50

Figure 1.51

We have successfully crashed this application.

Here Input Validation Issues - Part 3 challenge is completed.

We have successfully cracked the full DIVA application and completed all challenges.

Thanks for staying till here.

If you like this article, please support on Patreon.