Android App Hacking with Drozer – Usage

This is the article for those of you who have already previously setup Drozer or are returning to test your next Application a few weeks later and do not quite remember the exact syntax to get Drozer purring.

Reconnecting Drozer – Quickstart

Instead of heading back to the last article on setting up Drozer completely here is the quick start to get back online.

  1. Boot Up your Genymotion Device which has the Drozer agent installed, pull it up and turn it on (bottom right hand corner)
  2. Now pull up a console (command line) and change your directory over to your platform-tools folder.
  3. Type adb forward tcp:31415 tcp:31415 to begin using the correct ports required for Drozer
  4. Switch your directory to your drozer folder and then type drozer console connect and you are back in business


Examining Mobile Web Applications w/ Drozer:

drozer list 2

At this point in time I want you to type the command list this is going to demonstrate all of the modules available for you to execute in this session much like the -h or –help command would get you a list of sample syntax that can be used.

drozer app packages

The next command is finding the application package for the APP you are testing.

run app.package.list -f (name of app or company)I have given you a few examples above, this will search for the application package which we will be running additional commands for.  As you can see a search for google pulls up a significant amount of applications, fortunately Drozer puts the (App Name) in brackets so it is very easy for you to identify your application even if you are testing a few at the same time.

For this test I will be using Etar which is an open source calendar application which I have already run these commands on and there are no shown vulnerabilities with this tools  (demonstrating code) as I have already found the application package I will be using.

**Disclosure: Please only be testing applications which you have either written permissions from individuals with authority to test and application, is documented as Open Source (express permissions given – static testing only), or is your own proprietary application in which you are testing for vulnerabilities.

If needed here are the links for SOW (Statement of Work) and ROE (Rules of Engagement) which are highly recommended when working on any penetration testing efforts.

Next, find out some more information on the app you will be looking at first.

run -a (application) use the location found in the screenshot above, in my example it was the ws.xsoh.etar  – see below.

drozer app info

As you can see above, the version number is listed, the path, the .apk file, permissions and typically a broadcast receiver would define the permissions(when its supported by a private company).

You should be Screen shooting this data and save them as artifacts when submitting your testing documentation (and for your own reference so you do not have to run these commands again)

If you need to pull an .apk for any reason please see the article already written in regards to MobSF (Mobile Security Framework) where extracting .apk files is documented.

Attack Surfaces

run app.package.attacksurface (application)

This command will get you into territory which has made Drozer so popular in the mobile web application security world.  Lets take a look.

attack surface

As we can see here, there are 7 activities which have been exported along with 3 broadcast receivers.  Now as security testers it is up to us to make sure that these exported activities and attack surfaces are sensitive and/or vulnerable by design.  If they are vulnerable we can take it a step further and use the other Drozer modules to test and exploit these activities.

Be aware and on the lookout for a line that may be included at the bottom of this attack surface result:


As security testers this is big.  First and foremost this is most likely an item on your Mobile web application security checklist in which case if you do not see this output, most likely this application is not in Dev mode and has been released appropriately and is in Prod state.

So what does it mean if you do see that this application is debuggable?  Good question.

When an application is debuggable it means that the development team did not turn this “feature” off, it also means that as a penetration tester we are able to take our pick of debuggers attach it to the process and walk through every single set of instructions while executing arbitrary code in the application (good times).  InfoSec institute has an excellent article on digging deeper when you application is debuggable and injecting runtime code.

run -a (application)

etar activities

As you can see in this open source application which is the new free software for android calendar it is using basically all code from the packages which is why I chose this application.

When using this next command, look for something that was custom written by the creators.  Something that is unique to the app in particular that is either a standalone activity or an activity behind any type of authentication page in which the application can be taken advantage of.  You would be amazed at some of the things you can discover, Password Lists, Usernames, developer documentation, just remember to Document Everything.

run app.activity.start --component (application) (activity)


Run each activity, witness how it interacts with your application, change parameters, share items, change settings, and see what can be seen and changed within your mobile web application.

Many times the app.service.send can be used to send messages to each individual service, other times it may take writing customer drozer modules as well to truly get the outputs you are looking to get from your Mobile Web Application



Digging Deeper ~

Drozer is capable of building more complex commands on top of just picking activities and running them within the application.  you can also type


in front of your command and see what options are available to you

run app.activity.start --component (application) (activity)

help - Copy

Here we can see that we can continue to use Drozer with a much more ‘explicit intent’ by using optional arguments provided within the help command documentation.

optional args - Copy


While there is not much to see on my sample application using these next few commands it is very important that you continue to analyze the application you are testing with these as I am sure there will not only be content, but possible vulnerabilities and findings as well.


Content Provider Information

run -a (app)

~This will list content provider information – please run this as while you may not have found a vulnerability within the application itself I have seen a number of times where there are significant vulnerabilities or SQL injection flaws within the content providers of the Mobile App.

Drozer Scanner Module

Also Drozer is able to search for SQL Injection with its scanner module but for directory traversal as well.

run scanner.provider.injection -a (app)

run scanner.provider.traversal -a (app)

Run these to find vulnerable content providers that are easily visible to the scanner.

run scanner.provider.finduris -a (app)

This scanner module will allow you to bring together a list of content URI’s that are accessible and then we are able to take a look and try to retrieve and query information from the URI’s or possibly modify data in any correlating databases.

run app.provider.query content://(content provider as seen in previous command output here)

Now we have data, but how to test it?

Here is where you direct knowledge of Android comes into play.

We know that the Android platform is big on using SQLite databases for storing snippets, metadata, and user data.  Since we know these data bases use SQL, we know that SQL injection is right around the corner.  If you don’t know SQL, you can learn enough in a day off of CodeCademy to be dangerous with it.

Here are a few exploit examples testing for SQL vulnerabilities

run app.provider.query content://(content provider) --verticle_id: 1

Looking at certain id’s within the database

run app.provider.query content://(content provider) --projection "'"

Testing the projection field

run app.provider.query content://(content provider) --selection "'"

Testing the Selection field.

run app.provider.query content://(content provider) --projection "* FROM SQLITE_MASTER WHERE type='table';--"

Use any error messages received to craft your requests to tray to list all tables or query specific tables

run app.provider.query content://(content provider) --projection "* FROM Key;--"

Underlying File Systems

These content providers are in place in order to share data, files, and information to other applications outside of the application in which you are using.  This is called sand-boxing.  There are a number of commands you can use within drozer that I will list in a second, but I personally use Root Browser to dig deeper into the filesystem of the application, and if I require a file I can use drozer to download it if I prefer.

to make sure you have the right file, read it

run content://(content provider)/data/data/(filename)

then download it.

run content://(content provider)/data/data/(filename)


Wrap up ~

It is important to remember that you do not have to memorize EVERYTHING!  You just have to know where to find it.  If you ready this whole article awesome.  If you put to use the information delivered in this article, even better!

Personally I hack to learn.

Since I do plan to stop learning, I will definitely not stop Hacking!

I hope you do the same.

Hack On.

Cyber Incision Out.






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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: