Android Application-Level Virtualization (App Cloning)

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Application-level virtualization (aka app cloning/container frameworks such as DroidPlugin-class loaders) exécute plusieurs APKs à l’intérieur d’une seule application hôte qui contrôle le cycle de vie, le chargement des classes, le stockage et les permissions. Les guests s’exécutent souvent sous le même host UID, brisant l’isolation par application d’Android et rendant la détection difficile puisque le système voit un seul processus/UID.

Baseline install/launch vs virtualized execution

  • Normal install: Package Manager extrait l’APK → /data/app/<rand>/com.pkg-<rand>/base.apk, assigne un UID unique, et Zygote fork un processus qui charge classes.dex.
  • Dex load primitive: DexFile.openDexFile() délègue à openDexFileNative() en utilisant des chemins absolus ; les couches de virtualisation hookent/redirigent couramment ceci pour charger le dex invité depuis des chemins contrôlés par l’hôte.
  • Virtualized launch: L’hôte démarre un processus sous son UID, charge le base.apk/dex du guest avec un loader personnalisé, et expose des callbacks de cycle de vie via des proxies Java. Les appels API de stockage du guest sont remappés vers des chemins contrôlés par l’hôte.

Abuse patterns

  • Permission escalation via shared UID: Les guests s’exécutent sous l’UID de l’hôte et peuvent hériter de toutes les permissions accordées à l’hôte même si elles ne sont pas déclarées dans le manifest du guest. Les hôtes sur-permissionnés (énormes AndroidManifest.xml) deviennent des « permission umbrellas ».
  • Stealthy code loading: L’hôte hooke openDexFileNative/les class loaders pour injecter, remplacer ou instrumenter le dex du guest à l’exécution, contournant l’analyse statique.
  • Malicious host vs malicious guest:
  • Evil host: agit comme dropper/executor, instrumente/filtre le comportement du guest, et trafique les crashs.
  • Evil guest: abuse de l’UID partagé pour accéder aux données d’autres guests, les ptrace, ou tirer parti des permissions de l’hôte.

Fingerprinting & detection

  • Multiple base.apk in one process: Un container mappe souvent plusieurs APKs dans le même PID.
adb shell "cat /proc/<pid>/maps | grep base.apk"
# Suspicious: host base.apk + unrelated packages mapped together
  • Hooking/instrumentation artifacts: Cherchez des libs connues (ex. Frida) dans les maps et confirmez sur le disque.
adb shell "cat /proc/<pid>/maps | grep frida"
adb shell "file /data/app/..../lib/arm64/libfrida-gadget.so"
  • Crash-tamper probe: Provoquez intentionnellement une exception (ex. NPE) et observez si le processus meurt normalement ; les hôtes qui interceptent les chemins de cycle de vie/crash peuvent avaler ou réécrire les crashs.

Hardening notes

  • Server-side attestation: Enforcez les opérations sensibles derrière des tokens Play Integrity afin que seules les installations genuine (et non les guests chargés dynamiquement) soient acceptées côté serveur.
  • Use stronger isolation: Pour du code hautement sensible, préférez Android Virtualization Framework (AVF)/exécution TEE-backed plutôt que des containers au niveau application partageant un UID.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks