Drozer

Drozer is an open-source Android security assessment framework that tests an app’s attack surface by simulating what a malicious application could do through Android’s inter-process communication (IPC) mechanisms. Originally developed by MWR Labs (acquired by F-Secure, later WithSecure), Drozer is now maintained by Reversec with 4,400+ GitHub stars.

The main difference between Drozer and automated scanners like MobSF is the testing approach. MobSF finds common vulnerabilities through pattern matching. Drozer works differently: it installs a lightweight agent on the target device and lets you interact with apps the way a malicious application would — testing exported components, content providers, and IPC endpoints hands-on.

GitHub: ReversecLabs/drozer | Stars: 4.4k+ | Latest Release: v3.1.0 (August 2024) | License: BSD 3-Clause

Drozer specializes in finding vulnerabilities that static analysis misses: exported components without proper permission checks, content providers vulnerable to SQL injection, broadcast receivers that accept untrusted data, and privilege escalation paths through intent chains. Importantly, Drozer does not require root access — it tests what a zero-permission malicious app could achieve, which is the most realistic Android threat model.

For mobile security pentesters, Drozer sits between automated scanning and manual reverse engineering. It answers a specific question: “what can a malicious app actually do to this target?”

Overview

Drozer uses a client-agent architecture. The Drozer Agent is an Android app installed on the test device (physical or emulator). The Drozer Console runs on your workstation and connects to the agent, either via USB port forwarding with ADB or over a network connection.

Once connected, you interact with the target device through a command-line console. Drozer assumes the identity of the agent app — an unprivileged Android application — and uses standard Android APIs to probe other apps. This design is intentional: it tests what a zero-permission malicious app could achieve, which is the most realistic threat model for most Android security assessments.

The framework is modular. Core modules handle package enumeration, component discovery, and basic interaction. Community-contributed modules add capabilities for specific testing scenarios, and you can write your own in Python when the built-in ones fall short.

Version 3.0 rewrote the codebase for Python 3 compatibility, fixing longstanding issues with modern Python environments. The agent and console communicate via Protocol Buffers. You can connect via ADB port forwarding over USB or directly over Wi-Fi.

Key Features

Attack Surface Enumeration

The first step in any Android security assessment is understanding what the target app exposes. Drozer’s app.package.attacksurface module provides an immediate overview:

dz> run app.package.attacksurface com.target.app
Attack Surface:
  3 activities exported
  1 broadcast receivers exported
  2 content providers exported
  1 services exported

This tells you how many components are accessible to other apps on the device. Each exported component is a potential entry point that could be abused by a malicious application. Drozer then provides specific modules to drill into each component type.

For a broader view, app.package.info reveals the target’s permissions, shared user IDs, and process information. The app.package.manifest module dumps the full AndroidManifest.xml as parsed by the Android runtime — which can differ from the static manifest that tools like Apktool extract, due to runtime manifest merging.

Content Provider Exploitation

Content providers are among the most commonly vulnerable Android components, and Drozer provides the most thorough testing toolkit for them. Providers expose structured data through URI-based interfaces, and poorly secured providers can leak sensitive data or accept SQL injection.

Drozer’s content provider modules cover discovery and exploitation:

• app.provider.info — Lists all content providers and their read/write permissions
• app.provider.finduri — Discovers accessible content URIs through the app’s code
• app.provider.query — Queries content providers to extract data
• app.provider.injection — Tests for SQL injection in content provider queries
• app.provider.traversal — Checks for path traversal vulnerabilities in file-based providers

Providers without proper READ/WRITE permissions are especially dangerous. A zero-permission malicious app could query them to extract user data, authentication tokens, or internal app state.

Activity and Service Testing

Exported activities can be launched by any app on the device. Drozer lets you start activities with crafted intents, potentially bypassing authentication screens, accessing admin interfaces, or triggering unintended behavior.

The app.activity.info module lists exported activities and their required permissions. The app.activity.start module launches them with custom extras, data URIs, and action strings.

For services, app.service.info reveals exported services and their permission requirements. Drozer can bind to exposed services, send messages, and observe responses — testing for unauthorized access to background operations like data synchronization, file processing, or network communication.

Broadcast Receiver Analysis

Broadcast receivers that accept intents from any sender can be abused to trigger unintended actions. Drozer’s broadcast modules enumerate receivers and send crafted broadcasts to test how they handle untrusted input.

This matters most for receivers that handle sensitive operations: SMS processing, push notification handling, app update mechanisms. A receiver that skips sender validation can be tricked into performing privileged operations on behalf of a malicious app.

Custom Module Development

When built-in modules don’t cover what you need, Drozer supports custom modules in Python. These modules have access to the Android runtime through the agent, can invoke Java methods via reflection, and interact with any system service or content provider.

The drozer-modules repository on GitHub provides community-contributed modules that extend Drozer’s capabilities for specialized testing scenarios like WebView exploitation, clipboard monitoring, and keystore analysis.

Use Cases

Penetration Testing

I use Drozer as the primary tool for the interactive testing phase of Android penetration tests. After automated scanning with MobSF identifies the obvious issues, Drozer lets me explore and confirm vulnerabilities that require actual device interaction.

The typical workflow: enumerate the attack surface, query exposed content providers for data leakage, try SQL injection on each provider endpoint, launch exported activities to bypass navigation flows, send crafted broadcasts to test receiver input validation. This hands-on testing regularly turns up issues that automated tools miss.

Security Auditing

Development teams use Drozer to verify that their apps properly protect exported components. Before each release, running Drozer’s attack surface enumeration confirms that only intended components are exported and that each has appropriate permission guards.

This matters a lot for apps that use content providers for internal data sharing. Developers sometimes export providers for inter-component communication without realizing those providers become accessible to every app on the device.

Training and Education

Drozer shows up in Android security training courses and certifications. Its interactive console works well for teaching because students can see the immediate impact of exported components, understand IPC security through hands-on exploitation, and work through the OWASP Mobile Top 10 with practical exercises.

Pricing

Drozer is completely free and open source under the BSD 3-Clause License. There are no paid tiers or commercial editions.

Strengths & Limitations

Strengths:

• Only mainstream open-source tool dedicated to interactive Android IPC attack surface testing
• No root required — tests realistic malicious app scenarios
• Finds vulnerabilities that static analysis and automated scanners miss
• Modular architecture allows community extensions and custom modules
• Thorough content provider testing (injection, traversal, data leakage)
• Python 3 support with v3.0 rewrite
• Works on both real devices and emulators
• Widely referenced in Android security certifications and training materials
• BSD license allows unrestricted use in commercial pentesting

Limitations:

• Android-only — no iOS support (use Objection for cross-platform mobile testing)
• Learning curve for understanding Android IPC concepts before effective use
• Agent app must be installed on the target device (requires ADB access or physical device)
• Some newer Android security features (scoped storage, restricted implicit intents) limit what Drozer can test
• No built-in reporting — you need to capture console output and format reports manually
• Community module repository is not as actively maintained as the core framework

Getting Started

Companion Tools

Drozer handles interactive IPC testing. These tools cover the rest of the Android security workflow:

Android Security Toolkit

MobSF

Jadx

Apktool

Frida

radare2

Ghidra

For a full Android security testing toolkit, pair Drozer with MobSF for automated static and dynamic analysis, Jadx for Java code decompilation, Apktool for APK resource decoding, Frida for runtime instrumentation, and radare2 or Ghidra for native library reverse engineering.

Frequently Asked Questions