This week, we will be looking at another Hardcoded issue and how to trace along the App. As we saw last week developers tend to hard code while developing certain functionalities during development phase and sometimes, they are plainly hidden which is difficult to uncover. Let us walk through DIVA – Hardcoded functionality exercise 12. We are not walking through sequentially on this DIVA challenge, rather based on issue to understand and focus.

Above Figures 1 to 3 show the App exercise 12 and error message “Access denied! See you in hell :D” displayed for the invalid vendor key. Let us check the source code decompiled using Jadx.

Click on “HardcodeActivity2” class under “jakhar.aseem.diva” package.

We can see there is a private object djni declared of type DivaJni which can possibly be a class. Followed by a method called “access”. Access method validates the input entered by user against some value and displays if user is granted access or not. But unlike in the previous exercise, it is not comparing straight against another hardcode value in source code.

 

Hardcoded Issues 1

 

Hardcoded Issues 2

 

As in Figure 4 and Figure 5, we will compare the previous exercise and current one to investigate further. Hardcoded Issues 1 compares the user input with value “vendorsecretkey”. Where as Hardcoded Issues2 is comparing user input against this.djni.access (which is possibly a method in djni object. We have seen earlier djni is an object of type DivaJni. DivaJni is a class which can be seen in Jadx source code view.

 

In DivaJni class, a static string variable is declared and assigned value “divajni”. Followed by System.loadLibrary(soName), which implies there is a library divajni in the App. Linux based library modules are compiled with .so extension. We can assume it will be “divajni.so”. On searching through the decompiled sourced, “libdivajni.so” library file can be found under “/diva/diva-beta/lib/x86_64/”. When apk file is decompiled, there will be multiple copies of “libdivajni.so”, but they are for different architecture like x86, x86_64, mips, mips64 etc.

 

Let us run the strings command on library file and analyse the contents.

 

Analysing through the output, it looks mostly related to either:

Description	Output values
Library name	libdl.so, libc.so, libm.so etc
Method or property or some sort of keyword related	.dynsym, .dynstr, .hash etc
Some hardcoded value not related to any of above two points	·  <$!H · olsdfgad;lh ·  ;*3$”

Let us try one by one on the following values as vendor key:

• <$!H
• olsdfgad;lh
• ;*3$”

While trying “olsdfgad;lh”,  the app provides access with the  following message “Access granted!, See you on the other side :)”. This implies the value is hardcoded in library. If source code is provided for static analysis, we can find the value under divajni.c under the location:

https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c

There are other ways to analyse the same hardcoded values. Tools like Radare2 and cutter are very helpful. In one of next few weeks’ post, I will provide how to use Radare2 and cutter to analyse this exercise and other challenges.

Remediation: It is recommended to not use any hardcoded values in the code as this provides a way to read the code after decompiling. A possible alternate is to use encryption and KeyStore to mitigate the issue. Make sure the app is using the Android KeyStore and Cipher mechanisms to securely store encrypted information on the device.

We will look into another type of vulnerability in the next post.