Android Application-Level Virtualization (App Cloning)

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Application-level virtualization (aka app cloning/container frameworks such as DroidPlugin-class loaders) esegue più APK all’interno di una singola app host che controlla lifecycle, class loading, storage e permissions. I guest spesso vengono eseguiti all’interno dello host UID, comprimendo l’isolamento per-app standard di Android e rendendo difficile la rilevazione perché il sistema vede un unico processo/UID.

Baseline install/launch vs virtualized execution

  • Normal install: Package Manager estrae l’APK → /data/app/<rand>/com.pkg-<rand>/base.apk, assegna un unique UID, e Zygote effettua un fork di un processo che carica classes.dex.
  • Dex load primitive: DexFile.openDexFile() delega a openDexFileNative() usando percorsi assoluti; i layer di virtualizzazione comunemente hook/redirect questo per caricare il guest dex da percorsi controllati dall’host.
  • Virtualized launch: L’host avvia un processo sotto il suo UID, carica il base.apk/dex del guest con un custom loader, ed espone callback di lifecycle via Java proxies. Le chiamate alle API di storage del guest vengono rimappate su percorsi controllati dall’host.

Abuse patterns

  • Permission escalation via shared UID: I guest girano sotto lo host UID e possono ereditare tutte le host-granted permissions anche se non dichiarate nel manifest del guest. Host con permessi eccessivi (massive AndroidManifest.xml) diventano “permission umbrellas”.
  • Stealthy code loading: L’host hooka openDexFileNative/class loaders per inject, replace, o instrument il guest dex a runtime, bypassando la static analysis.
  • Malicious host vs malicious guest:
  • Evil host: agisce come dropper/executor, instrumenta/filtra il comportamento del guest, e manipola i crash.
  • Evil guest: abusa dello shared UID per raggiungere i dati di altri guest, usare ptrace su di essi, o sfruttare i permessi concessi all’host.

Fingerprinting & detection

  • Multiple base.apk in one process: Un container spesso mappa diversi APK nello stesso PID.
adb shell "cat /proc/<pid>/maps | grep base.apk"
# Suspicious: host base.apk + unrelated packages mapped together
  • Hooking/instrumentation artifacts: Cerca librerie note (es. Frida) nelle maps e conferma su disco.
adb shell "cat /proc/<pid>/maps | grep frida"
adb shell "file /data/app/..../lib/arm64/libfrida-gadget.so"
  • Crash-tamper probe: Provoca intenzionalmente un’eccezione (es. NPE) e osserva se il processo termina normalmente; host che intercettano i percorsi di lifecycle/crash possono assorbire o riscrivere i crash.

Hardening notes

  • Server-side attestation: Applica le operazioni sensibili dietro token Play Integrity in modo che solo installazioni genuine (non guest caricati dinamicamente) siano accettate lato server.
  • Use stronger isolation: Per codice altamente sensibile, preferire Android Virtualization Framework (AVF)/TEE-backed execution invece dei container a livello di app che condividono un UID.

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks