Android Dual-App Environment Underlying Analysis and Risk-Control Detection Implementation

Summary: Non-root multi-instance tools like Phantom Split, VirtualApp, Parallel Space, Dual Space Assistant, and BlackBox are essentially user-space lightweight virtual sandboxes. This article breaks down their core implementation principles, organizes the pros and cons of various dual-app detection schemes, clarifies the easily confused basic concepts of package name, PID, and UID, and focuses on the false positive problem that commercial hardening (using iJiMi as an example) brings to detection logic. It provides a practical, compatibility-conscious risk-control implementation plan.

1. First Distinguish App Name, Package Name, PID, and UID

Many dual-app detection pitfalls originate from confusing these basic concepts. Many people see an app name with a numeric suffix or multiple process PIDs and immediately conclude it is dual-app, which is wrong.

Concept	What It Represents	Can It Alone Prove Dual-App?
App name, desktop numbering	A label or shortcut name shown to the user	No, the name can be changed
Package name	Identifier used by the app and its components	No, the container can present the original package name to the app
PID	Process number during a single run	No, a normal app can have multiple processes
UID	System identity used for app sandbox and permission control	Valuable, but the read channel and user space must be confirmed
Signature certificate	Important mark of app publisher and update relation	Can assist in identifying repackaging, but does not equal identifying all containers

Android isolates app resources using Linux UID and other mechanisms. Multiple processes of a normal app usually share the app UID; seeing multiple PIDs does not mean dual-app. Special mechanisms like isolated processes require separate handling.

Two important principles:

1. UID numbers are not a permanent encoding of the package name; the same package may have different UIDs on different devices, users, or installation conditions.
2. Detection should compare the identity relationship within the same run, not hard-code "a fixed UID means dual-app."

Additional note: System-level clones (vendor-provided app cloning, Android work profile) and third-party virtual containers are two completely different implementations. The system multi-user formula is: UID = userId × 100000 + appId. Legitimate data directories can be /data/user/10/xxx. A non-zero user space cannot simply be judged as malicious dual-app.

2. Implementation Principles of Non-Root Dual-App Apps Like Phantom Split

A normal Android system relies on Linux UID/GID isolation plus AMS (ActivityManagerService) for app sandbox isolation. Non-root clone tools, however, have no kernel permissions; they work entirely in user space, using hooks to deceive the framework layer and the target app, achieving parasitic replication.

Overall architecture diagram:

Four core implementation mechanisms:

1. Stub / Proxy Components

The clone host is itself a normally installed APK with a legally assigned package name and UID. It pre-registers a large number of business-less stub components like StubActivity$P0, StubService$P1 in AndroidManifest.xml, assigning different android:process=":p1", :p2. From the system's perspective, all clone instances are sub-processes of the host app, enabling multi-instance concurrent execution.

2. Dynamic Class Loading with DexClassLoader

After the user selects the app to clone, the host reads the locally installed APK file. Inside an independent sub-process, it uses DexClassLoader to load the target app's dex, so libraries, and resources (AssetManager.addAssetPath) into the current process memory. The target app's code is never actually re-installed on the system; it is simply dynamically loaded and executed by the host process.

3. Java-level Hooks to Fake Identity and Deceive the Business App

Using dynamic proxies and reflection to intercept framework-level system API calls:

• Hook AMS: intercept startActivity, wrap the target app's Intent into the host's Stub component Intent to pass system validation; after the Stub starts, replace it with the real Activity logic.
• Hook PMS: when the business app calls getPackageName() or getApplicationInfo(), return the original package name of the cloned app, hiding the host's real identity.

Key point: Most Java-layer API return values can be uniformly tampered with by the container. So a bunch of Java detection interfaces all returning normal values does not prove the environment is secure.

4. Native-layer IO Redirection for Multi-set Data Isolation

Without root, the clone tool cannot create multiple sets of official system private data directories. So it hooks native libc system calls: open, openat, stat, access. When the business app reads/writes /data/data/your_package/shared_prefs, it is transparently redirected at the bottom layer to a virtual path under the host's private directory: /data/data/<host_package>/virtual/data/user/0/<your_package>/shared_prefs/. The Java layer sees the normal path, but the kernel's actual read/write location has changed.

3. How to Detect Whether an App Is Running in a Clone/Dual-App Sandbox

The core idea of countering dual-app: find identity contradictions that the container cannot fully smooth over. The container can hook almost all Java-layer APIs, but it is very difficult to achieve 100% no-breach across the entire chain.

⚠️ Important reminder: Any single client-side detection can be bypassed. A detection hit should be treated as a risk clue, not evidence of guilt.

Method 1: Compare Process UID with Package's Official UID (High Reliability)

In a clone environment, the app runs under the host process's UID, but the system-registered UID obtained from PackageManager for that package name will be inconsistent.

Note: The container can hook Java-layer Process.myUid(). For advanced, call getuid() natively or read /proc/self/status to get the real UID.

public static boolean checkUidMismatch(Context context) {
    try {
        // 1. Get the current process's Linux UID
        int myUid = android.os.Process.myUid();
        // 2. Get the official UID for this package from PackageManager
        PackageManager pm = context.getPackageManager();
        ApplicationInfo appInfo = pm.getApplicationInfo(context.getPackageName(), 0);
        int officialUid = appInfo.uid;
        // Mismatch suggests a clone
        if (myUid != officialUid) {
            return true;
        }
    } catch (Exception e) {
        return false;
    }
    return false;
}

Additional advanced detection (from real engineering review): Create a brand-new PendingIntent probe token and compare getCreatorUid() with the current process UID. In a normal environment, when you create a PendingIntent yourself, the creator UID must equal the process UID. Some clone containers fake all UIDs at the Java layer, but this system token chain is not adapted, causing an identity contradiction.

• Advantages: Pure Java, no NDK required.
• Disadvantages: API >= 24; creation and destruction involve Binder calls, not suitable for high-frequency loops; add memory caching.

private static boolean checkPendingIntentIdentity(Context context) {
    if (context == null) return false;
    PendingIntent pendingIntent = null;
    try {
        String packageName = context.getPackageName();
        Intent intent = new Intent(packageName + ".CLONE_PROBE." + UUID.randomUUID())
                .setPackage(packageName);
        pendingIntent = PendingIntent.getBroadcast(
                context, 0, intent, PendingIntent.FLAG_IMMUTABLE);
        if (pendingIntent == null) return false;
        int creatorUid = pendingIntent.getCreatorUid();
        int processUid = Process.myUid();
        return creatorUid >= 0 && processUid >= 0 && creatorUid != processUid;
    } catch (Exception ignored) {
        return false;
    } finally {
        if (pendingIntent != null) {
            try {
                pendingIntent.cancel();
            } catch (Exception ignored) {}
        }
    }
}

Method 2: /proc/self/maps Memory Mapping Detection (Native Layer)

Clone frameworks must inject hook so libraries into the process space. Read the memory mapping table and match against a feature library of common multi-open frameworks.

Note: Hardening shells also inject so libraries; you need a feature whitelist. Do not flag every non-system so as dual-app.

bool checkVirtualMaps() {
    FILE* fp = fopen("/proc/self/maps", "r");
    if (!fp) return false;
    char line[1024];
    while (fgets(line, sizeof(line), fp)) {
        if (strstr(line, "libsandhook") != NULL ||
            strstr(line, "libva.so") != NULL ||
            strstr(line, "libepic") != NULL ||
            strstr(line, "blackbox") != NULL ||
            strstr(line, "/virtual/data/") != NULL) {
            fclose(fp);
            return true;
        }
    }
    fclose(fp);
    return false;
}

Method 3: Private Directory Physical Path Validation to Counter IO Redirection

The Java-layer getFilesDir() return path can be hooked, but the real physical path after resolving symbolic links may expose the virtual marker.

public static boolean checkFilesPath(Context context) {
    String filesPath = context.getFilesDir().getAbsolutePath();
    String packageName = context.getPackageName();
    // Note: Do not directly exclude /data/user/xx; system multi-user uses non-zero user IDs
    try {
        File dir = new File(filesPath);
        String canonicalPath = dir.getCanonicalPath();
        if (canonicalPath.contains("virtual")) {
            return true;
        }
    } catch (IOException ignored) {}
    return false;
}

Method 4: System Service Dynamic Proxy Detection (High False Positive, Use with Caution)

To intercept AMS/PMS, the clone replaces system Binder interfaces with Java dynamic proxy objects.

⚠️ Risk: Commercial hardening shells also proxy system services to prevent tampering, causing high false positives. Do not use as a strong condition; only as an auxiliary clue.

public static boolean checkSystemServicesHook(Context context) {
    try {
        PackageManager pm = context.getPackageManager();
        if (java.lang.reflect.Proxy.isProxyClass(pm.getClass())) {
            return true;
        }
        Class<?> amClass = Class.forName("android.app.ActivityManager");
        Field gDefaultField;
        try {
            gDefaultField = amClass.getDeclaredField("IActivityManagerSingleton");
        } catch (NoSuchFieldException e) {
            gDefaultField = amClass.getDeclaredField("gDefault");
        }
        gDefaultField.setAccessible(true);
        Object gDefault = gDefaultField.get(null);
        Class<?> singletonClass = Class.forName("android.util.Singleton");
        Field mInstanceField = singletonClass.getDeclaredField("mInstance");
        mInstanceField.setAccessible(true);
        Object amService = mInstanceField.get(gDefault);
        if (java.lang.reflect.Proxy.isProxyClass(amService.getClass())) {
            return true;
        }
    } catch (Throwable ignored) {}
    return false;
}

Method 5: ClassLoader Chain Detection (High False Positive, Not Recommended for Direct Judgment)

Normal apps use the default PathClassLoader; multi-open frameworks insert a custom ClassLoader.

⚠️ Pitfall: Hardening shells replace the ClassLoader to perform dex decryption. This detection is almost unusable in a hardened environment; use only as an observation log, not for risk-control decisions.

4. Impact of Commercial Hardening (iJiMi) on Dual-App Detection

Core conclusion: Hardening interferes with some detection items, but UID and physical path checks are unaffected. Hardening and clone tools use some similar low-level techniques, but their purposes are exactly opposite. Clone: deceive the system, virtualize multiple environments. Hardening: prevent reverse engineering and injection, protect the original app.

Compatibility of Each Detection Method in a Hardened Environment

Detection Method	Hardening Impact	Recommendation
UID consistency comparison / PendingIntent identity check	No impact	Prioritize; use as core judging basis
File path canonical real-path check	No impact	Keep; auxiliary evidence
/proc/self/maps so feature scan	Minor impact	Filter hardening's own so features; match only clone framework keywords
System service dynamic proxy detection	High false positive	Log only; never as an interception condition
ClassLoader chain detection	Very high false positive	Do not use for business judgment; debug logs only

What Low-Level Techniques Does iJiMi Hardening Use?

1. Shell Proxy Application: The Manifest entry is replaced with the hardening shell's Application; the shell executes decryption logic first, then starts the business Application.
2. In-memory DEX decryption without landing: Business dex is encrypted and stored in assets or so, decrypted in memory at runtime, and loaded with a custom ClassLoader. Some versions support VMP instruction virtualization.
3. Native-layer defense: ptrace anti-debugging, TracerPid monitoring, detection of Frida/Xposed injection.
4. Built-in environment awareness: The hardening shell itself has Root, emulator, and multi-open detection capabilities.

Best Anti-Dual-App Practice for Already-Hardened Projects

1. Prefer the hardening vendor's enterprise version built-in anti-multi-open capability (convenient). Enterprise hardening platforms provide an "anti-multi-open/anti-clone" toggle. Detection runs in the shell layer, before the app code is decrypted, making reverse-engineering bypass much harder. The vendor has already handled compatibility with its own shell, suitable for high-security needs.
2. Self-built business-layer detection (for risk reporting, not immediate crash)

• Keep: UID comparison, PendingIntent identity check, real file path check.
• Remove: ClassLoader class name judgment, system service Proxy dynamic proxy strong judgment.
• Detection timing: Wait for the hardening shell to finish initialization; perform detection in the business Application.onCreate or after MainActivity, not in the shell phase.
• Performance: PendingIntent creation involves Binder IPC, add memory caching; do not call in high-frequency loops.

1. Disposal strategy suggestion

❌ Do not directly crash on detection hit. ✅ Recommended: Tag a risk label on the client and report to the backend; the backend combines behavior and device fingerprint for comprehensive risk control. After a hit, restrict sensitive operations like payment or login and show the user a risk warning.

5. Important Engineering Experience Summary

1. Do not confuse system work profile/vendor clone with third-party malicious virtual containers. Business needs to clearly define which environments are allowed and which are forbidden.
2. Many Java-layer detection interfaces go through the same set of hooks; multiple interfaces returning consistent values does not mean the environment is trustworthy. Try to find identity contradictions across different system chains.
3. Client-side detection can always be bypassed. High-value business cannot rely solely on a client boolean result; server-side involvement is required.
4. In hardened environments, prioritize identity-based checks; be cautious with ClassLoader and dynamic proxy logic that easily false-positive.
5. Detection failure (exception, permission restricted) means "unable to judge environment", not "environment is secure". Do not directly return false as a security credential.
6. New detection logic must be gray-released, covering: normal non-hardened, normal hardened, clone non-hardened, clone hardened, vendor system clone, work profile multi-user, various device models, and evaluate the false-positive rate.

Extended thinking: For long-term protection, consider Android Key Attestation key proof, which verifies the app's identity at the hardware level on the server side. However, domestic device compatibility varies; it is suitable as an advanced supplement, not as the only method.