|
| 1 | +# Android Application-Level Virtualization (App Cloning) |
| 2 | + |
| 3 | +{{#include ../../banners/hacktricks-training.md}} |
| 4 | + |
| 5 | +Application-level virtualization (aka app cloning/container frameworks such as DroidPlugin-class loaders) runs multiple APKs inside a single host app that controls lifecycle, class loading, storage, and permissions. Guests often execute inside the host UID, collapsing Android’s normal per-app isolation and making detection difficult because the system sees one process/UID. |
| 6 | + |
| 7 | +## Baseline install/launch vs virtualized execution |
| 8 | + |
| 9 | +- **Normal install**: Package Manager extracts APK → `/data/app/<rand>/com.pkg-<rand>/base.apk`, assigns a **unique UID**, and Zygote forks a process that loads `classes.dex`. |
| 10 | +- **Dex load primitive**: `DexFile.openDexFile()` delegates to `openDexFileNative()` using absolute paths; virtualization layers commonly hook/redirect this to load guest dex from host-controlled paths. |
| 11 | +- **Virtualized launch**: Host starts a process under **its UID**, loads the guest’s `base.apk`/dex with a custom loader, and exposes lifecycle callbacks via Java proxies. Guest storage API calls are remapped to host-controlled paths. |
| 12 | + |
| 13 | +## Abuse patterns |
| 14 | + |
| 15 | +- **Permission escalation via shared UID**: Guests run under the host UID and can inherit **all host-granted permissions** even if not declared in the guest manifest. Over-permissioned hosts (massive `AndroidManifest.xml`) become “permission umbrellas”. |
| 16 | +- **Stealthy code loading**: Host hooks `openDexFileNative`/class loaders to inject, replace, or instrument guest dex at runtime, bypassing static analysis. |
| 17 | +- **Malicious host vs malicious guest**: |
| 18 | + - *Evil host*: acts as dropper/executor, instruments/filters guest behavior, tampers with crashes. |
| 19 | + - *Evil guest*: abuses shared UID to reach other guests’ data, ptrace them, or leverage host permissions. |
| 20 | + |
| 21 | +## Fingerprinting & detection |
| 22 | + |
| 23 | +- **Multiple base.apk in one process**: A container often maps several APKs in the same PID. |
| 24 | + ```bash |
| 25 | + adb shell "cat /proc/<pid>/maps | grep base.apk" |
| 26 | + # Suspicious: host base.apk + unrelated packages mapped together |
| 27 | + ``` |
| 28 | +- **Hooking/instrumentation artifacts**: Search for known libs (e.g., Frida) in maps and confirm on disk. |
| 29 | + ```bash |
| 30 | + adb shell "cat /proc/<pid>/maps | grep frida" |
| 31 | + adb shell "file /data/app/..../lib/arm64/libfrida-gadget.so" |
| 32 | + ``` |
| 33 | +- **Crash-tamper probe**: Intentionally trigger an exception (e.g., NPE) and observe whether the process dies normally; hosts that intercept lifecycle/crash paths may swallow or rewrite crashes. |
| 34 | + |
| 35 | +## Hardening notes |
| 36 | + |
| 37 | +- **Server-side attestation**: Enforce sensitive operations behind [Play Integrity](play-integrity-attestation-bypass.md) tokens so only genuine installs (not dynamically loaded guests) are accepted server-side. |
| 38 | +- **Use stronger isolation**: For highly sensitive code, prefer **Android Virtualization Framework (AVF)**/TEE-backed execution instead of app-level containers that share a UID. |
| 39 | + |
| 40 | +## References |
| 41 | + |
| 42 | +- [Android Application-Level Virtualization (App Cloning) — How It Works, Abuse, and Detection](https://blog.azzahid.com/posts/android-app-virtualization/) |
| 43 | + |
| 44 | +{{#include ../../banners/hacktricks-training.md}} |
0 commit comments