Reverse Engineering: DIVA application

Mr. Robot
InfoSec Adventures
Published in
4 min readOct 1, 2018

DIVA stands for Damn Insecure and Vulnerable Application.

This Android application is intentionally vulnerable and created just for testing purposes. You can download the application from here: http://www.payatu.com/wp-content/uploads/2016/01/diva-beta.tar.gz

Some tools

There are some really good tools out there. These are my favorite:

Apktool

It’s is used for reverse engineering 3rd party, closed, binary Android apps. You should totally check it out:
https://ibotpeaches.github.io/Apktool/install/

Dex2jar

I’m going to work with .dex files, so here is a good tool for that:
https://github.com/pxb1988/dex2jar

JD-CMD

My personal favorite java command-line decompiler is jd-cmd: https://github.com/kwart/jd-cmd

JD-GUI

If you like GUI, then you should download JD-GUI:
http://jd.benow.ca/

I’m going to use linux, but the tools should work on every platform.

Let’s get started

APK stands for Android Package Kit. APK files are saved in a compressed .zip format and can be opened by any zip decompression tool. You can try it by renaming the .apk extension to .zip and decompressing the file. The content will be something like this:

┌─[t0thkr1s@btksoftware]─[~/Downloads]
└──╼ $ mv diva-beta.apk diva-beta.zip
┌─[t0thkr1s@btksoftware]─[~/Downloads]
└──╼ $ unzip diva-beta.zip -d diva-beta
Archive: diva-beta.zip
inflating: AndroidManifest.xml
inflating: res/anim/abc_fade_in.xml
inflating: res/anim/abc_fade_out.xml
--- snip ---┌─[t0thkr1s@btksoftware]─[~/Downloads]
└──╼ $ cd diva-beta/
┌─[t0thkr1s@btksoftware]─[~/Downloads/diva-beta]
└──╼ $ ls
AndroidManifest.xml classes.dex lib META-INF res resources.arsc

The downside of this technique is that the .xml files are barely readable. You can find some activity names and permissions, but the file is mostly gibberish.

Apktool to the rescue

┌─[t0thkr1s@btksoftware]─[~/Downloads]
└──╼ $ apktool d diva-beta.apk -o diva-beta
I: Using Apktool 2.3.1-dirty on diva-beta.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /home/t0thkr1s/.local/share/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
┌─[t0thkr1s@btksoftware]─[~/Downloads]
└──╼ $ cd diva-beta
┌─[t0thkr1s@btksoftware]─[~/Downloads/diva-beta]
└──╼ $ ls
AndroidManifest.xml apktool.yml lib original res smali

Apktool produces different files. This time, if you try to read the AndroidManifest.xml file, for example, you’ll get a fully readable and formatted .xml file. But, where are the source files? Apktool generates .smali files, which you can edit and then recompile the application.

Source files

Let’s not concentrate on the XML files, we want the source code. Now, in order to read the classes.dex file, we can use an excellent tool called dex2jar. Head over to https://github.com/pxb1988/dex2jar/releases and download the latest stable release. I added the contents of the zipped file to my PATH recursively, this way the usage in different directories is much easier.

┌─[t0thkr1s@btksoftware]─[~/Downloads/diva-beta]
└──╼ $ d2j-dex2jar.sh classes.dex
dex2jar classes.dex -> ./classes-dex2jar.jar
┌─[t0thkr1s@btksoftware]─[~/Downloads/diva-beta]
└──╼ $ ls | grep *.jar
classes-dex2jar.jar

At this point, you have 2 options. If you like working in the command-line, then use jd-cmd, if you prefer GUI then you have JD-GUI. In this example, I’m going to use jd-cmd and show you its usage. In case you chose JD-GUI, all you have to do is open the .jar file and you’ll be presented with the decompiled .java source files. As for jd-cmd, here is how you do it:

┌─[t0thkr1s@btksoftware]─[~/Downloads/diva-beta]
└──╼ $ sudo java -jar ~/Downloads/jd-cli.jar classes-dex2jar.jar -od src
[sudo] password for t0thkr1s:
12:35:42.417 INFO jd.cli.Main - Decompiling classes-dex2jar.jar
12:35:42.420 INFO jd.core.output.DirOutput - Directory output will be initialized for path src
-- snip --12:35:46.245 INFO jd.core.output.DirOutput - Finished with 1788 class file(s) and 0 resource file(s) written.
┌─[t0thkr1s@btksoftware]─[~/Downloads/diva-beta/src/jakhar/aseem/diva]
└──╼ $ ls
AccessControl1Activity.java 'NotesProvider$DBHelper.java'
AccessControl2Activity.java NotesProvider.java
AccessControl3Activity.java 'R$anim.java'
AccessControl3NotesActivity.java 'R$attr.java'
APICreds2Activity.java 'R$bool.java'
APICredsActivity.java 'R$color.java'
BuildConfig.java 'R$dimen.java'
DivaJni.java 'R$drawable.java'
Hardcode2Activity.java 'R$id.java'
HardcodeActivity.java 'R$integer.java'
InputValidation2URISchemeActivity.java R.java
InputValidation3Activity.java 'R$layout.java'
InsecureDataStorage1Activity.java 'R$menu.java'
InsecureDataStorage2Activity.java 'R$mipmap.java'
InsecureDataStorage3Activity.java 'R$string.java'
InsecureDataStorage4Activity.java 'R$styleable.java'
LogActivity.java 'R$style.java'
MainActivity.java SQLInjectionActivity.java

jd-cli.jar provides multiple command-line options. Here, I used -od to specify the output directory as src.

HardcodeActivity.java source file.

I assume you can easily spot the hardcoded vendor secret key check. This is a very bad coding practice to hardcode secret in source files. DIVA was created to present numerous vulnerabilities and bad practices. Check out the other activities to see them!

I wrote a small shell script to automate these steps and properly reverse engineer Android applications. I may reveal it in my next post 😉

Before you go

Thank you for taking the time to read my article. If you found it helpful, please hit the 👏 button 👏 (up to 50x) and share it to help others with similar interest find it! + Feedback is always welcome! 🙏

--

--

Mr. Robot
InfoSec Adventures

Self-taught developer with an interest in Offensive Security. I regularly play on Vulnhub and Hack The Box.