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
There are some really good tools out there, but I’m going show you my favorite ones.
It’s is used for reverse engineering 3rd party, closed, binary Android apps. You can edit the decompiled .smali code and re-buid the app with you modifications. Even though, it’s not really required to follow along, you should totally check it out!
We are going to work with .dex files and it’s the best tool to convert those file to a single JAR, which can be decompiled later on.
My personal favorite java command-line decompiler is jd-cmd. It’s easy to use and has some very handy command line options.
If you like GUI (Graphical User Interface), then you should download JD-GUI.
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.
┌─[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.
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.
I assume you can easily spot the hardcoded vendor secret key check. This is a very bad coding practice to hardcode secrets 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 😉
If you found this article helpful, please share to help others with similar interest find it! + Feedback and donations are always welcome!