Reverse Engineering The DIVA Apk


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:

Required tools

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.

- - - - - - - - - -
Note: I’m using Linux, but the tools should work on every platform!
- - - - - - - - - -

Decompressing APK files

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:

└──╼ $ mv diva-beta.apk
└──╼ $ unzip -d diva-beta
  inflating: AndroidManifest.xml     
  inflating: res/anim/abc_fade_in.xml  
  inflating: res/anim/abc_fade_out.xml

--- snip ---

└──╼ $ cd 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

└──╼ $ 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...
└──╼ $ cd 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 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.

└──╼ $ classes.dex
dex2jar classes.dex -> ./classes-dex2jar.jar
└──╼ $ ls | grep *.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:

└──╼ $ 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.
└──╼ $ ls             'NotesProvider$'                 'R$'        'R$'                  'R$'                   'R$'                        'R$'                            'R$'                  'R$'                   'R$'           'R$'       'R$'       'R$'       'R$'       'R$'                        'R$'              

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

package jakhar.aseem.diva;

import android.os.Bundle;
import android.view.View;
import android.widget.EditText;
import android.widget.Toast;

public class HardcodeActivity
extends AppCompatActivity
public void access(View paramView)
if (((EditText)findViewById(2131492987)).getText().toString().equals("vendorsecretkey"))
Toast.makeText(this, "Access granted! See you on the other side :)", 0).show();
Toast.makeText(this, "Access denied! See you in hell :D", 0).show();

protected void onCreate(Bundle paramBundle)

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 😉

Before you go

If you found this article helpful, please share to help others with similar interest find it! + Feedback and donations are always welcome!