Android applications are bundled and installed as android application package(apk) on an Android device. More often then not the stakeholders of an application require confidence that the application that is being developed is secure and does not pose an unacceptable level of risk. Drozer is just the tool for that.

Warning: This is going to be a comprehensive, long and fairly technical post. Once again, nothing is left to reader’s/user’s imagination.

Drozer is a security audit and attack framework for Android which works by allowing you to interact with the Dalvik VM, other apps’ IPC endpoints and the underlying OS. Drozer provides tools to help you use and share public exploits for Android. For remote exploits, it can generate shellcode to help you to deploy the drozer Agent as a remote administrator tool, with maximum leverage on the device.

Now let us go ahead and configure drozer. We will be using a Mac OSX based System, however the instructions are more or less aligned for a Windows based system too. Some prerequisites for configuring dozer are:

  1. Java Development Kit (JDK) 1.6 – (very important! See configuration of Java 6 below for reason)
  2. Python 2.7.
  3. Android SDK
  4. You should ensure that each of these tools are on your path: adb, java

Let us move from easiest to the most difficult prerequisite configuration:

Configuring adb:

On Mac this can be done via homebrew by executing the following at the terminal:

Configuring Java 6:

It is very important that Java 1.6 is installed and used. This is because Android bytecode is only compliant to version 1.6 and not higher versions. Making use of any version of javac other than 1.6 will result in errors during compilation that look similar to the following:

bad class file magic (cafebabe) or version (0033.0000)

You can download legacy Java6 for OSX from here:

Once you have downloaded and installed it. It is necessary to make sure that javac -version returns 1.6.*  on the terminal. See this link for information on how java_home is setup on Mac OSX. If Java 6 was correctly installed at /Library/Java/, then it can be made primary by using the following command at the terminal:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/

All the important configurations are done. Python is installed by default on Mac OSX and is accessible via the terminal.

Installing Drozer:

Once the configurations are done, we can now clone drozer directly form git itself. All commands will be run on the terminal.

  1. At appropriate location(a separate folder preferably), clone the drozer repo:

 git clone

  1. We will setup drozer from the repo directly. Once the repo is cloned, go to the root of the repo by: cd drozer
  2.  Setup the PYTHONPATH to include/find the drozer:

    export PYTHONPATH=/path/to/drozer/src/:$PYTHONPATH

  3. Now you can run:

    python build

  4. After finishes, if you type drozer in the terminal then the command should be executed successfully.

Hacking with Drozer:

Before you start hacking, we will need an Android device(although the steps are valid for emulator too). Also, we will need to install drozer agent and sieve apk(s) on the device. The purpose of these: sieve is a vulnerable application that we would be testing. Agent app is the app which is our gateway into the dalvik vm of the android device we are connected to.The Agent opens a ServerSocket, on port 31415 by default, and awaits incoming connections and commands via those connections.

Both the apps are available here:

To connect to drozer agent app:

  1. Connect the android device to the computer via usb.
  2. Launch the agent app on the android device.
  3. Push the “on” button on the app screen. This will make it listen for incoming tcp connections on port 31415
  4. On the terminal type: adb forward tcp:31415 tcp:31415
  5. And after that:

    drozer console connect

    This should launch drozer console:


 As soon as this happens, we can say safely that we are connected to the android device. The screen of the drozer app should look like the one below and the connectivity indicator fir embedded server should have turned green:


The drozer Console is a command line environment, which should be familiar to anybody who has used a bash shell or Windows terminal. Now we can go ahead and assess sieve.

The first step in assessing Sieve is to find it on the Android device. Apps installed on an Android device are uniquely identified by their ‘package name’. We can use the `app.package.list` command to find the identifier for Sieve:

dz> run app.package.list -f sieve


We can ask drozer to provide some basic information about the package using the `` command:

dz> run -a com.mwr.example.sieve

Package: com.mwr.example.sieve

Process Name: com.mwr.example.sieve

Version: 1.0

Data Directory: /data/data/com.mwr.example.sieve

APK Path: /data/app/com.mwr.example.sieve-2.apk

UID: 10056

GID: [1028, 1015, 3003]

Shared Libraries: null

Shared User ID: null

Uses Permissions:

– android.permission.READ_EXTERNAL_STORAGE

– android.permission.WRITE_EXTERNAL_STORAGE

– android.permission.INTERNET

Defines Permissions:

– com.mwr.example.sieve.READ_KEYS

– com.mwr.example.sieve.WRITE_KEYS

This shows us a number of details about the app, including the version, where the app keeps its data on the device, where it is installed and a number of details about the permissions allowed to the app.

We can ask drozer to report on Sieve’s attack surface:

dz> run app.package.attacksurface com.mwr.example.sieve

Attack Surface:

  3 activities exported

  0 broadcast receivers exported

  2 content providers exported

  2 services exported

    is debuggable

We can drill deeper into this attack surface by using some more specific commands. For instance, we can ask which activities are exported by Sieve:

dz> run -a com.mwr.example.sieve

Package: com.mwr.example.sieve




The PWList activity is exported and does not require any permission, we can ask drozer to launch it:

dz> run app.activity.start –component

com.mwr.example.sieve com.mwr.example.sieve.PWList

This formulates an appropriate Intent in the background, and delivers it to the system through the `startActivity` call. Sure enough, we have successfully bypassed the authorization and are presented with a list of the user’s credentials:


Next we can gather some more information about the content providers exported by the app. Once again we have a simple command available to request additional information:

dz> run -a com.mwr.example.sieve

Package: com.mwr.example.sieve

  Authority: com.mwr.example.sieve.DBContentProvider

    Read Permission: null

    Write Permission: null

    Content Provider: com.mwr.example.sieve.DBContentProvider

    Multiprocess Allowed: True

    Grant Uri Permissions: False

    Path Permissions:

     Path: /Keys


       Read Permission: com.mwr.example.sieve.READ_KEYS

       Write Permission: com.mwr.example.sieve.WRITE_KEYS

  Authority: com.mwr.example.sieve.FileBackupProvider

    Read Permission: null

   Write Permission: null

   Content Provider: com.mwr.example.sieve.FileBackupProvider

   Multiprocess Allowed: True

   Grant Uri Permissions: False


This shows the two exported content providers that the attack surface alluded to in Section 3.3. It confirms that these content providers do not require any particular permission to interact with them, except for the /Keys path in the DBContentProvider.

Also, We identified that Sieve exported two services. As with activities and content providers, we can ask for a little more detail:

dz> run -a com.mwr.example.sieve

Package: com.mwr.example.sieve


    Permission: null


    Permission: null

Once again, these services are exported to all other apps, with no permission required to access them.

And that is it. We did configure, install and scratched the surface of an app using dozer. There is much more to dozer which we would be covering in subsequent posts. I hope this was useful and informative