Android Analysis: Platform-Specific Techniques

This skill defines Android-specific analysis techniques for MobHunt hunter agents. It is loaded by /hunt-android and /recon commands and used by Android hunter agent instances.

App Structure

After apktool + jadx extraction:

apktool/
  AndroidManifest.xml     ← decoded, human-readable manifest
  res/xml/                ← network_security_config.xml, file_paths.xml, etc.
  assets/                 ← raw assets (configs, databases, certs)
  lib/<abi>/              ← native .so libraries
  smali/                  ← Dalvik bytecode (fallback if jadx fails)

jadx/
  sources/                ← decompiled Java source tree
  resources/              ← resource files

Analysis order: Always start with the manifest (ground truth), then move to decompiled source, then native libraries.

AndroidManifest Security Analysis

Critical Attributes

<application
    android:allowBackup="true"       <!-- backup extraction risk -->
    android:debuggable="false"       <!-- must be false in production -->
    android:usesCleartextTraffic="false"  <!-- HTTP policy -->
    android:networkSecurityConfig="@xml/network_security_config"
>

SDK Version Analysis

<uses-sdk
    android:minSdkVersion="24"       <!-- security baseline -->
    android:targetSdkVersion="34"    <!-- behavior changes -->
/>

minSdkVersion < 24: App supports Android < 7.0, which lacks Network Security Config enforcement. Note this.

Permission Analysis

Dangerous permissions to flag:

• READ_CONTACTS, READ_CALL_LOG, READ_SMS: PII access
• ACCESS_FINE_LOCATION, ACCESS_BACKGROUND_LOCATION: tracking
• CAMERA, RECORD_AUDIO: surveillance
• READ_EXTERNAL_STORAGE / MANAGE_EXTERNAL_STORAGE: broad file access
• SYSTEM_ALERT_WINDOW: overlay attacks (tapjacking)
• BIND_ACCESSIBILITY_SERVICE: full screen content access

Permissions alone are not findings. They are context for other vulnerabilities.

Component Analysis

Export Rules

A component is exported if:

1. android:exported="true" is set explicitly, OR
2. The component has an <intent-filter> AND targetSdkVersion < 31

For targetSdkVersion >= 31, exported must be declared explicitly for components with intent filters.

Exported Activities

# Test: launch exported activity
adb shell am start -n <package>/<activity>

# With extras
adb shell am start -n <package>/<activity> --es key "value"

# With data URI
adb shell am start -n <package>/<activity> -d "content://..."

What to check:

• Does the activity display sensitive data without re-authentication?
• Does it accept intent extras that control behavior (file paths, URLs, user IDs)?
• Is it a WebView activity that loads URLs from intent data?

Exported Services

# Test: start service
adb shell am startservice -n <package>/<service>

# Bind to service
# (requires PoC app for AIDL/Messenger binding)

What to check:

• Does the service perform privileged operations on behalf of any caller?
• Is there caller verification (Binder.getCallingUid())?

Content Providers

# Query provider
adb shell content query --uri content://<authority>/

# With projection
adb shell content query --uri content://<authority>/users --projection "name:password"

# SQL injection test
adb shell content query --uri content://<authority>/users --where "1=1) OR 1=1--"

What to check:

• Is the provider exported without readPermission / writePermission?
• Does query() use raw SQL or parameterized queries?
• Does the provider serve files? Check for path traversal: content://<authority>/../../etc/passwd

Broadcast Receivers

# Send broadcast
adb shell am broadcast -a <action> -n <package>/<receiver>

# With extras
adb shell am broadcast -a <action> --es data "payload"

Intent & Deep Link Analysis

Deep Link Types

Custom scheme without autoVerify: Standalone finding if the scheme carries OAuth tokens, session data, or sensitive parameters.

Intent Redirection

The most impactful Android-specific vulnerability class:

// VULNERABLE: extracts intent from extras and starts it
Intent redirect = getIntent().getParcelableExtra("next_intent");
startActivity(redirect);  // attacker controls destination

Impact: Attacker can access any non-exported component within the app's context, bypassing exported=false.

Detection in source: Search for getParcelableExtra followed by startActivity, startService, or sendBroadcast without component validation.

PendingIntent Hijacking

// VULNERABLE: implicit intent + mutable PendingIntent
Intent intent = new Intent("com.example.ACTION");  // implicit
PendingIntent pi = PendingIntent.getActivity(ctx, 0, intent, 0);  // mutable (pre-API 31)

Impact: Attacker's app can intercept the implicit intent and modify it, performing actions under the victim app's identity.

Detection: Search for PendingIntent.get(Activity|Service|Broadcast) where the base intent is implicit (no setComponent() / setClass()) and flags don't include FLAG_IMMUTABLE.

WebView Security

JavaScript Bridge (addJavascriptInterface)

webView.addJavascriptInterface(new JsBridge(), "AndroidBridge");

public class JsBridge {
    @JavascriptInterface
    public String getToken() { return authToken; }

    @JavascriptInterface
    public void executeCommand(String cmd) { Runtime.exec(cmd); }
}

Assessment: List all @JavascriptInterface methods. If the WebView loads URLs from intent data or untrusted sources, every exposed method is callable by the attacker.

File Access

// DANGEROUS combinations:
webView.getSettings().setAllowFileAccessFromFileURLs(true);
webView.getSettings().setAllowUniversalAccessFromFileURLs(true);
webView.getSettings().setJavaScriptEnabled(true);

With file access + JS enabled, an attacker who controls the loaded URL can read local files:

// Attacker's page loaded via deep link:
var x = new XMLHttpRequest();
x.open("GET", "file:///data/data/com.target/shared_prefs/auth.xml");
x.onload = function() { exfiltrate(x.responseText); };
x.send();

SSL Error Handling

// VULNERABLE: accepts all certificates
webView.setWebViewClient(new WebViewClient() {
    @Override
    public void onReceivedSslError(WebViewHandler handler, SslError error) {
        handler.proceed();  // NEVER do this
    }
});

Network Security Config

Located at res/xml/network_security_config.xml:

<!-- WORST: global cleartext -->
<network-security-config>
    <base-config cleartextTrafficPermitted="true" />
</network-security-config>

<!-- BAD: user CAs trusted in production -->
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />  <!-- allows MITM with user CA -->
        </trust-anchors>
    </base-config>
</network-security-config>

Assessment: Cleartext config alone is informational. User CA trust in production is MEDIUM (enables MITM). Both become findings when chained with evidence of sensitive data transmission.

Data Storage

SharedPreferences

// DANGEROUS: world-readable (deprecated API 17, removed API 28+)
getSharedPreferences("prefs", MODE_WORLD_READABLE);

// COMMON: private, but stores sensitive data unencrypted
getSharedPreferences("auth", MODE_PRIVATE);
editor.putString("access_token", token);

Detection: shared_prefs_analyzer.py scans for getSharedPreferences calls and flags MODE_WORLD_READABLE/MODE_WORLD_WRITEABLE. For MODE_PRIVATE, check what data is stored; tokens, passwords, PII in plaintext are findings when combined with allowBackup=true or other extraction paths.

SQLite / Room Databases

// VULNERABLE: raw query from user input
db.rawQuery("SELECT * FROM users WHERE id = " + userId, null);

// SAFE: parameterized
db.rawQuery("SELECT * FROM users WHERE id = ?", new String[]{userId});

External Storage

// DANGEROUS: world-readable on older Android
File file = new File(Environment.getExternalStorageDirectory(), "data.json");

// DANGEROUS: media store doesn't protect files
context.getExternalFilesDir(null);  // app-specific but readable pre-API 29

Native Library Analysis

JNI Entry Points

Native functions exported via JNI follow the naming convention:

Java_com_example_app_ClassName_methodName

Analysis approach:

1. List JNI exports: nm -gD <lib.so> | grep "Java_"
2. For each export, check the corresponding Java declaration (native keyword)
3. In Ghidra/BN, analyze the native function for:
   • Input validation of JNI parameters
   • Use of GetStringUTFChars without length checks
   • Calls to system(), exec(), dlopen()
   • Hardcoded crypto keys or credentials

Unsafe Functions

Flag these in native code (potential buffer overflows):

• strcpy, strcat, sprintf, gets, scanf
• memcpy without bounds checking

Anti-Tampering / Root Detection

Common libraries:

• SafetyNet / Play Integrity API
• Root detection (RootBeer, custom checks)
• Integrity checks (signature verification)

These are NOT findings. Missing root detection is informational only.

Tool Reference (Android-Specific)

Source Code Review Priorities

When reviewing decompiled Java source, focus on:

1. IPC handlers: onCreate, onNewIntent, onReceive, onBind, query, insert, delete
2. URL/URI processing: Uri.parse, getIntent().getData(), getQueryParameter
3. WebView setup: loadUrl, addJavascriptInterface, WebSettings configuration
4. Crypto operations: Cipher.getInstance, MessageDigest, SecretKeySpec
5. Data storage: getSharedPreferences, openOrCreateDatabase, ContentValues
6. Network calls: OkHttpClient, HttpURLConnection, Retrofit configuration
7. File operations: openFileOutput, getExternalFilesDir, FileProvider

Do NOT attempt to review all source; focus on security-relevant classes identified by dex_class_analyzer.py.