Android Reverse Engineering 101 – Part 3

In the first two articles of the series, I wrote about the APK format and the aapt tool.

In this post I will focus on dex2jar, a tool to work with Android  .dex and Java .class files: there are few mirrors, but you can point here for the official website.

The core feature of this tool is, as you would expect, converting the classes.dex file of an APK to classes.jar (or any name of your choice of course) or vice versa. So it’s possible, using any Java decompiler tool, to view the source code of an Android application.

What you get are .class files, don’t expect to get Java source code that was written by the application developer: however, as you’ll see later, it’s completely readable.


To get the latest available version, please go to one of the official repositories.

The installation process is quite straightforward: you just have to unzip the package in a folder of your choice and then add that location to your path. That’s it, you’re ready to start using dex2jar!

Note: it might be possible that you need to give execution rights to the script files contained in the folder.

At the time of writing, the latest stable release is 2.0, so this is the version used in the rest of the article.

version: reader-2.0, translator-2.0, ir-2.0

Before digging in the core features of the tool, if you take a look at the content of the dex2jar folder, you can notice that several scripts are available (both Unix/Mac and Windows versions): that’s because each major feature supported by dex2jar is provided in a separate script: I think it’s a good solution so you don’t have to pass too many arguments to one executable.

dex2jar folder content
dex2jar folder content

Let’s now move to the core feature of the tool: converting DEX classes to JAR.

If you have read the first part of this series, you know that executable code inside an APK file is in DEX format, which can be defined as an Android bytecode format. Of course, it would be better to have an easier to read format in order to analyze the code of one application and this is exactly where dex2jar can help you.

Before issuing the very first command, we need to pick an application from Google Play Store and also install a decompiler to view the source (on other hand what we get are .class files, not .java):

  • RGB Tool: it’s an open-source application, so it’s not a problem to reverse engineering it. You can directly get the APK here.
  • JD-GUI: yet another fast Java decompiler with a UI.

The first command we’re going to test, lets you extract the executable code of the application in JAR format: -f -o classes.jar FILENAME.apk

With the -o option, you specify the name of the output file of the command, while -f simply tells dex2jar to overwrite this file if it’s already existing.


If you open the output file with JD-GUI, you can see the source code of the application: again, what you get is not exactly what was written in the Java classes, but it’s enough clear to read. Underlined items are clickable, so it’s also very easy to navigate through the code.

JD-GUI classes.jar
JD-GUI classes.jar

Just for your reference, here you can find the original source code of the file displayed in the screenshot.

Where are the resources?

If you carefully look the screenshot, you have certainly noticed that instead of resource names, like, … there are numbers: these are the IDs stored in the class file as explained by the official documentation. This file is automatically generated at build time (don’t modify it manually!) and it can be found in the .../build/generated/source/r/... folder of your project. It’s essentially a final class which defines static final classes for each resource type, such as strings, layouts, arrays, colors, dimens, … and for each of them it defines static final int fields, you resource IDs. In this way, while implementing your application, you don’t have to deal with numbers directly.

IDs are stored in hexadecimal, so the 0x7f080000R.array.pick_color_array  in the original application source code) is the 2131230720 (decimal) used by getStringArray in the file extracted by dex2jar (you can see it in the screenshot above of SelectPictureDialogFragment.class).

Obfuscated code

I picked this specific application because I know its code has been shrunk and obfuscated with ProGuard: you can clearly see that because several packages and classes are named  a,  b,  c, …

In the screenshot here below, it’s evident the work done by ProGuard to change method and variables names and to scramble the flow of the code. However, the code is still quite readable and it’s not particularly difficult to find and understand specific algorithm or business logic.

Of course, not all the classes have been obfuscated, but this depends on the specific rules declared in the ProGuard configuration file: for the application used in this example, it can be found here on GitHub.

Obfuscated code
Obfuscated code
Out Of Memory Error

The current documentation is not updated about this topic, anyway it’s possible, while converting DEX to JAR or viceversa, to get an OutOfMemoryError issue: very likely you’re trying to translate a large size DEX file.

You need to increase the size of the memory of the JVM and in order to do that, you have to open the d2j_invoke script and look for this line:

java -Xms512m -Xmx1024m -classpath "${_classpath}" "$@"

Change the values accordingly to your system and needs: personally, in my experience, I just had to change the size of the memory allocation pool like this: -Xmx2048m .

Back to DEX

dex2jar supports also the conversion from .class to .dex: this is particularly interesting because it gives the possibility to put back executable code into the APK file.

The specific command is: -f -o classes.dex classes.jar

With the -o option, you specify the name of the output file of the command, while -f simply tells dex2jar to overwrite this file if it’s already existing.


The APK file is essentially a ZIP file, so the new DEX file can be inserted back quite easily:

zip -r FILENAME.apk classes.dex

Remember this operation alters the original APK file, so you can’t simply install it on your device, but you have to sign it again with jarsigner in order to regenerate the MANIFEST.MF file. This is a security safeguard against altering an application: if you do it, you have to resign the package and since you do not have the keystore and private key used for the original application, you can’t release your altered APK as an update of the original one.

When the system is installing an update to an application, it compares the certificate in the new version with those in the existing version. The system allows the update if the certificates match.


From the official page:

smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android’s Java VM implementation. The syntax is loosely based on Jasmin’s/dedexer’s syntax, and supports the full functionality of the dex format (annotations, debug info, line info, etc.).

Diving into details is beyond the scope of this article, but I wanted to introduce you anyway to smali and baksmali, just to let you know that is possible to get .smali files directly from the classes.dex file.

That means you can change the source code of an application directly working with this format.

The command is quite simple: FILENAME.apk


The tool creates a new folder, naming it appending the suffix -out to the APK file name: inside the files are organized by package name.

smali output folder
smali output folder

Just to give an idea, this is what a smali file looks like: it’s not so hard to read and once you get used to its syntax it becomes quite understandable.

Please notice this is the a.class file for which I have posted a screenshot here above, while talking about obfuscated code.

smali file
smali file


apktool is also able to manipulate smali files: I will show you in the next part of the series.

That’s all for this update and dex2jar: as you have seen, with a relatively simple to use tool, you can already extract (and possibly put back) a lot of information from and to an APK file. But the tool lacks the support for XML resources and they are an important part of any Android application.

In the next part I will introduce you to apktool and that’s where things get really interesting.

4 thoughts on “Android Reverse Engineering 101 – Part 3”

  1. Orrrr you can just use and have it do all this for you. You can checkout the smali, jar, resources, etc. You can even use different decompilers based on the code.

    PS: I’m not the developer of the bytecode viewer, just a user of this wonderful tool that merges all the goodies into one place!

    1. Absolutely, it’s a great tool. But I also think, if you are new to this topic and you would like to understand what’s going on behind the scenes, it’s better to start using each tool separately. Thanks again for stopping by!

  2. Great tutorial. I enjoyed every bit of it.

    please correct this line: FILENAME.apk

    should be:
    d2j-dex2smali.bat FILENAME.apk

    that is the way it workeed when l tried it.

    1. Thanks for stopping by and reading the tutorial. Actually it depends on which environment you are: Linux/Mac would be .sh, Windows .bat 😉

Leave a Reply

Your email address will not be published. Required fields are marked *