apk-interceptor

Android deeplink, Intent, and WebView bridge assessment helper

apk-interceptor is a portable Android testing APK for authorized application security assessments. It helps security engineers verify how an Android app handles external entry points such as custom URI schemes, deeplinks, exported Activities, and WebView JavaScript bridges.

The tool is intentionally constrained:

• It does not declare android.permission.INTERNET
• It does not send data to external servers
• It does not execute shell commands
• It does not require root, Magisk, Frida, or runtime instrumentation
• It serves only one local content:// payload file
• It registers one custom URI scheme fixed at build time

Motivation

During Android application security assessments, many findings from static analysis still need a small on-device proof of concept before they can be confirmed: registering a custom URI scheme, sending an explicit Intent, serving a local content:// payload, or checking whether JavaScript can reach a WebView bridge.

Building a new throwaway test app for each case is repetitive and error-prone. Small differences in manifest entries, authorities, URI grants, package names, or Intent construction can slow down verification and make results harder to reproduce.

apk-interceptor was created to make that confirmation step repeatable. Instead of writing a new PoC APK for every assessment, you build this tool with the authorized scheme or application ID you need, run the test on-device, and keep the workflow constrained by design: no INTERNET permission, no external data transmission, no shell execution, and no root dependency.

What You Can Test

apk-interceptor is useful for these assessment tasks:

Scenario	Module	What It Helps Verify
Custom URI scheme hijacking	Interceptor	Whether another app can register the same custom scheme and receive links
Deeplink parameter handling	Sender	Whether the assessed app accepts unsafe query/path parameters
Exported Activity exposure	Sender	Whether an exported Activity can be launched directly by another app
WebView bridge exposure via content://	Payload + Sender	Whether a local HTML payload can reach a WebView JavaScript bridge
Local payload syntax check	Payload	Whether your HTML/JS payload runs in the self-test WebView

Detailed vulnerability walkthroughs:

• Custom URI Scheme Hijacking
• Deeplink Open Redirect
• Exported Activity With Untrusted Intent Data
• WebView JavaScript Bridge Exposure Via content://

The app keeps an in-memory assessment log for sent Intents, received deeplinks, bridge callbacks, JavaScript results, and errors. Logs disappear when the app process is killed. Because logs are not persisted, capture evidence with screenshots or screen recording as you work.

How It Compares

apk-interceptor is a confirmation tool, not a discovery or exploitation framework. It assumes you already know what to test (scheme, Activity class, bridge name) from static analysis, and gives you a safe, on-device way to verify reachability and capture evidence. It is built to be installed on an assessment device and even shared with a client, so it ships no INTERNET permission, no shell execution, no data exfiltration, and no root requirement.

Where it sits next to the usual Android tooling:

Tool	Role	How apk-interceptor differs
jadx / MobSF / QARK / Semgrep	Find vulnerable entry points (static)	apk-interceptor does not scan or decompile; it confirms a finding you already have
deep-C / NSdeepLink / adb am start	Enumerate and send deeplinks	apk-interceptor can also send, but its differentiator is receiving a hijacked scheme and showing the exact URI and parameters
drozer	General on-device attack framework (agent + often root)	apk-interceptor is a single lightweight APK with deliberate safety guardrails, narrower scope, and easier client-safe distribution
Metasploit / Frida	Weaponize or hook (e.g. addJavascriptInterface RCE)	apk-interceptor only checks bridge reachability with a harmless payload; it never exfiltrates or executes shell commands

The two areas where apk-interceptor has the clearest edge over the alternatives:

• Scheme-hijack evidence: acting as the second app that actually registers the scheme and logging every received parameter, which adb/static analysis cannot show.
• content:// → WebView bridge verification: a non-exported, single-file provider whose payload is delivered only through a temporary Intent read grant, plus a local self-test WebView to validate payload syntax first.

Sending Versus Intercepting

apk-interceptor treats sending and intercepting differently, and this is the most important thing to understand before using it:

Action	Module	Custom scheme needed at build time?
Send an Intent or deeplink to another app	Sender	No, type any URI, package, or Activity at runtime
Intercept (receive) a deeplink for a custom scheme	Interceptor	Yes, the scheme is fixed into the APK at build time

To send a crafted deeplink to the assessed app, you do not need to rebuild: use the Sender tab's Implicit Deeplink mode and type any URI.

To intercept a deeplink, that is, to make Android route a custom scheme to apk-interceptor so you can observe a possible scheme-hijack, you must build the APK with that scheme via --scheme. The scheme is fixed at build time on purpose (a design guardrail); apk-interceptor never registers arbitrary schemes at runtime. If you change the scheme you are assessing, rebuild and reinstall.

Requirements

• Android Studio with Android SDK 35
• Android 12+ device or emulator
• JDK 17+
• adb for device installation and optional command-line testing

Build And Install

Build the APK with the custom URI scheme you are authorized to assess:

./build-interceptor.sh --scheme <authorized_custom_scheme>
adb install ./out/apk-interceptor-<authorized_custom_scheme>-debug.apk

Optional build flags:

./build-interceptor.sh \
  --scheme <authorized_custom_scheme> \
  --app-id <custom.application.id> \
  --output ./out

--app-id sets the installed application ID (the package identity on the device and the content://<applicationId>.payload authority) at build time. The default is com.sterrasec.apkinterceptor. Override it with --app-id when you need multiple separately installable builds for different assessments. The Windows equivalent is build-interceptor.bat.

The default scheme intercept-poc-example is a harmless placeholder. The build script refuses to produce an assessment APK with that default scheme.

First Launch

On first launch for each app version, apk-interceptor shows an authorized-use dialog. After you tap I understand, the same version does not show the dialog again. The Sender tab still shows a persistent warning because it can send Intents to other apps.

Screenshots