Cyber Security Mobile App Testing

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.






Cyber Security Mobile App Testing

How to use MobSF to analyze a Mobile Web Application

There are a number of excellent tools that exist when it comes to testing mobile web applications.  Unfortunately many of them cost a significant amount of mulah.  There are a few though that currently are free to use and we are going to take a deep dive into getting you your first Mobile Security Framework report from the Mobile Web App that you are testing today.

Before testing Mobile Web Applications please be sure that your organization has the required documentation and written consent from the organization in order for you to do so.  Typically this will be included in a SOW (Statement of Work) and ROE (Rules of Engagement)



MobSF Install and Use:

Now that we have the .APK and have it in our Kali box, lets get our Mobile Security Framework up and running.

I would be doing you a disservice if I tried to go step by step on the setup and did not tell you that MobSF and ajinabraham don’t already have excellent tutorials in getting up and running with the MobSF tool, because they do.

Feel free to visit their page or continue on and follow the next few steps.

**For Windows or Mac please see MobSF documentation at this link **

The reason I use Kali in a Virtual Environment is so I can suspend it, have a dedicated MobSF VM, and it saves my MobSF reports in the ‘recent MobSF reports’ so I can actively switch back and forth to it and analyze source code.

For Kali Linux follow along here and run this syntax:

Pull up your terminal/command line in Kali Linux and run:

git clone
cd Mobile-Security-Framework-MobSF

clone the file, then switch your directory as shown above.

sudo apt install build-essential libssl-dev libffi-dev python-dev
pip install -r requirements.txt --user

Then install these libraries which are essential to getting up and running, along with installing the requirements and dependencies.


Now in every pentest I have been apart of, there is always a pentester who claims to have done the work but has NO report to back it up…..Don’t be that GUY/GAL!

Run this command apt-get install wkhtmltopdf

This will give you the option at the end of uploading your .APK file to download the pdf and have a report to show that the analysis has at least been run, an artifact exists, and that it can be referenced back to.


After this, we are ready to start the MobSF Server.

In your terminal run

python runserver

MobSF server running.PNG

Now you have your server running, but wait there is nowhere to insert my APK file!?

Thats because MobSF is AWESOME!

Pull up your browser and go to http://localhost:8000/

You will now see the Web Interface that is click and drag ready for that .APK file that you have already downloaded from your Google Drive/Dropbox Account

MobSF Analyzing.PNG

Throw it in, and you will see the server in the background have fun analyzing this .APK while you sit back and relax.

MobSF report.PNG

Be sure you are aware of the OWASP Mobile Security Checklist this is essential to making sure you cover your bases as a pentester.  You are not required to know everything, but you are required to have to know how and where to find EVERYTHING.

So hop to it, get analyzing you have your report, at the bottom left side you can see download report as a pdf, but please use the web interface, it allows you to download the Java code for the application and really get your hands dirty along with be more user friendly than the PDF report (which you should still keep as an artifact).


Here is the certificate for the Application which you are able to make sure it is up to industry standards.



Also make sure the permissions for your application Make Sense!  Go through these while testing the functionality of the application and make sure that the user is asked for the appropriate permissions and they are not assumed (many a lawsuit has happened by the creator of mobile applications assuming that data can be taken and/or shared).

Manifest Analysis.PNG

As you can see in the Manifest Analysis MobSF rates many items as high severity.  There is a fine line between Customer Experience and Security which is why you see what you see, read the description and use your God given critical thinking skills to analyze them, do not just throw this report at your Project Manager or client and say fix these things!  If you find something out of the ordinary, or seriously think you have a few items that may lead to vulnerabilities, do some research, or crazier yet ASK someone!

MobSF allows you to download the Android manifest, the java code, and the smali code.  Unfortunately this tool does generate false positives.  Verify the issues described by Mobile Security Framework by downloading the code and analyzing it. Do your due diligence.  Prove vulnerabilities exist.

Have fun, learn lots.

~Cyber Incision out