testing-mobile-ipc

Testing Mobile IPC and Deep Links

Every exported component and registered URL scheme is a remote entry point that does not need the network. A malicious app on the same device — or a web page the user visits — can invoke them directly, and they are frequently written as if only the app itself would ever call them.

When to Use

• Reviewing AndroidManifest.xml for exported components
• Testing deep links, App Links, custom URL schemes, or Universal Links
• Assessing content provider and broadcast receiver exposure
• Checking PendingIntent, intent redirection, and App Group sharing
• Answering "what can another app on this device do to this one?"

When NOT to Use

• Network API testing — use testing-apis
• Binary-level reversing — use analyzing-ios-binaries or the relevant reversing-* skill
• TLS or detection problems blocking you — use bypassing-mobile-pinning or bypassing-root-jailbreak-detection first
• The wider assessment — use testing-mobile-applications

Android: Enumerate the Surface

apktool d target.apk -o out
# Every component with exported=true, or with an intent-filter and no explicit
# exported attribute on older targetSdk (which defaults to exported)
rg -n 'android:exported="true"|<intent-filter>' -B3 out/AndroidManifest.xml

# Live enumeration
adb shell dumpsys package com.target.app | rg -A3 'Activity Resolver|Receiver Resolver|Service Resolver|Provider'
drozer console connect
#   run app.package.attacksurface com.target.app
#   run app.activity.info -a com.target.app
#   run app.provider.info -a com.target.app

android:exported defaults changed — apps targeting API 31+ must declare it explicitly, but a component with an intent-filter on an older target is exported implicitly. Check targetSdkVersion before concluding a component is private.

Also check permission protection levels. A component "protected" by a custom permission declared with protectionLevel="normal" is protected by nothing: any app can request and receive it without user interaction.