Android Reversing Part 1: Internals

Hello paranoids

A few weeks ago i have taken on the challenge of learning how to reverse Android APKs. I have developed a bit for Android in the past but i have never delved that much into the Android world. However, as a reverser, i am always curious about the internals of other “binaries”.  As such, i am creating a small series of posts:

  1. Android Reversing Part 1: Internals
  2. Android Reversing Part 2: Tools
  3. Android Reversing Part 3: Tampering with Android Applications

Also, following the normal flow of my blog, i will reverse a real Android apk. At this point i am not sure if i will reverse a malware or just a commercial application protected with anti-reversing frameworks. Will see.

Since i am constantly learning and this is a new topic, i may update the posts overtime to reflect my findings. I am just starting these posts earlier since they provide me with a structured way of learning, by teaching. I will try to keep the posts light and straight to the point.

APK Anatomy

Let us take an example of a malware: 513fef5af719b6bb7d7760007aca2f49 a.k.a Android Autoinst. First of all, an APK is a ZIP file. You can open it with either 7-ZIP or with the Windows ZIP explorer. So, we have:

AutoInst contents

AutoInst contents

Sticking to the standard files/folders:

  • META-INF/: Contains files with SHA-1 digests of some of the the files within the APK, for integrity verification purposes. It also contains the certificate of the application. I have noticed that some files inside res/ (e.g. strings files) have no digest within the files i referred
  • res/: XML layout files and PNGs/JPEGs used by the application
  • AndroidManifest.xml: describes the application: permissions, activities (screen processors, roughly speaking), packages
  • resources.arsc: contains precompiled application resources in binary XML
  • classes.dex: compiled classes (our main target). This can be open using IDA

Other files/folders that may be present:

  • libs/: Native libraries
  • assets/: Similar to res/ but, while the files on the latter are “interpreted” by Android (e.g. taking into account the language or screen orientation/size), these are not. This folder may be used to store text files or other resources that are read by the application code (e.g. text file containing application configurations)

Let us ignore the other files since they seem specific to some compilation/packaging process.

Dalvik, DEX, ByteCode, Smali, Jasmin …

 While saying Android is Java is not correct (VM, GUI programming, classes, multithreading code differ), truth is, a Java developer can read code for Android relatively easy once it understands the workflow of Android applications. In terms of the operating system, Android’s kernel is a Linux kernel. As for the execution of applications, while JVM is used to run Java applications, Android applications are executed by the Dalvik Virtual Machine (DVM). Android applications’ files are first compiled to .class files using the typical Java compiler and then compiled into .dex files using dx tool (comes with Android SDK).

 If you try to open a .dex file you will find it to be unreadable. It is like opening a binary using hexdump. So, is there an assembly equivalent for dex? (remember that assembly is just a “Human Readable” representation of opcodes). Yes!

Some History

A few years ago, Jasmin (, a free open source assembler was developed by Jon Meyer and Troy Downing. The assembler would take an ASCII representation of Java classes, methods and fields and would compile them into .class files which would then be runnable using JVM. The assembler was developed at a time where SUN did not provide an assembler or even a standard language to represent the bytecode. As such, Jasmin has become the first assembler as well as a standard for the representation of bytecode in a readable way. Nowadays, tools such as Jasper (, a Java .class disassembler as well as smali/baksmali (, an assembler/disassembler for the DEX format use Jasmin’s syntax (disassemby of DEX files usingsmali/baksmali is typically called Smali).

Android Basics

Now, this part is a bit more boring and is your best friend. I am no Android developer but i am relatively familiar with the workflow of the applications. It is important to have a slight grasp of how Android projects are structured so you can look at a decompiled version of the APK.


Roughly speaking, Activities are classes that represent the logic behind the screens you see and interact with on an Android app. Activities have standard methods that are called to initialise the current screen interface. Whenever you want to jump to another screen or use an Android functionality (e.g. camera), you typically (unless this changed) need to create an Intent.


Views are building blocks for Android application interfaces. Buttons, textboxes, progress bars are examples of Views. Views that trigger events (e.g. buttons) have handlers that are basically pieces of code that process interactions. Assuming a button, you define a function to handle clicks. The concept of events and handlers is pretty much used on every programming language that provides support for GUIs (e.g. C# and .NET). Views are identified through IDs which are in essence integers stored on files.


Code that executes in the background with no user interface. This is similar to Windows services. Services can be used to run tasks in the background decoupled from Activities. They are not the same thing as threads and the usage of one instead of other is off topic.

Manifest and Permissions

Manifest files are interesting pieces of information for reversing purposes. By analysing them you can infer what is the first activity being created when you execute the application (e.g. search for android.intent.action.MAIN and android.intent.category.LAUNCHER). Manifest file may have permissions which are helpful to tell you what the application requires (e.g. android.permission.SET_WALLPAPER allows the application to change the phone wallpaper).

Final Notes

On this first post i intended to overview the basics of Android applications and APKs. This will be necessary for you to understand the next posts. As i said at the beginning of this post, i am still learning about Android reversing so i may update this article in the future with more information.

Stay safe 😉


One thought on “Android Reversing Part 1: Internals

  1. Pingback: Android Reversing Part 2: Tools | Security Over Simplicity

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s