> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/cloning-and-containers-running-your-app-inside-someone-elses-sandbox-and-how-talsec-detects-it.md).

# Cloning and containers: running your app inside someone else's sandbox, and how Talsec detects it

Your signup bonus is limited to one per device. Your free trial is limited to one per device. Your referral programme assumes a person cannot invite themselves.

All three assume that "one device" means "one instance of your app," which was true for roughly the first decade of Android and is not true now. A user can run five, ten, fifty isolated copies of your app on a single handset, each with its own data directory, its own account, and from your app's point of view, its own apparently clean slate. Some of them do not even need root.

If your promo-abuse numbers look worse than your device-level controls say they should, this is a good place to look.

<figure><img src="https://1548930415-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNjTFXsqCLQ3RU2oA2uHC%2Fuploads%2FDTX7oiyLo3f5ublA1Bb2%2FCloning%20and%20containers%20running%20your%20app%20inside%20someone%20else's%20sandbox%2C%20and%20how%20Talsec%20detects%20it.png?alt=media&amp;token=81c5bdde-9e8f-47d4-ab2d-e38591ccab95" alt=""><figcaption></figcaption></figure>

## What cloning and containers are

Two distinct things get lumped together, and separating them matters for how you respond.

### **OEM dual-app features**

Samsung, Xiaomi, OPPO, vivo and others ship a built-in capability: Dual Messenger, Dual Apps, App Twin, and similar. These lets a user run a second instance of an installed app under a separate Android user or work-profile-like mechanism. This is a vendor feature with an enormous, entirely legitimate user base: two WhatsApp accounts for work and personal, two of anything for two SIMs. It is on hundreds of millions of devices.

### **Third-party virtual containers**

Separately, there is a category of apps that implement avirtualised Android environment *inside themselves*, and run other apps as guests within it. These typically do not require root, because they are not modifying the system. They are hosting your app's process inside their own. That hosting relationship is the security-relevant part.

Both produce the same commercial outcome: many instances, one device.

### Why this breaks your controls

**Device identifiers stop meaning what you think.**\
Each instance may see a different app-scoped identifier, or the host may control what the guest observes entirely. The identifier that anchored your one-per-device rule is now a per-instance value the user can multiply at will.

{% hint style="info" icon="book-blank" %}
You can read more about device identifiers, their usage, and stability [**here**](/appsec-articles/glossary/device-identifiers.md).
{% endhint %}

**Install-count limits do not apply.**\
From the platform's perspective there may be one install, or several under different Android users. Neither maps to what you were trying to count.

**Play Integrity may be satisfied.** The device can be genuine and unmodified. The app can be genuine. Third-party virtualisation in particular often needs no root at all, so the environmental signals that would flag a compromised device may simply be absent.&#x20;

**A guest process does not fully own its own environment.**\
When your app runs inside a hostcontainer, aspects of what it observes - filesystem view, package list, some identifiers - are mediated by the host. That is a weaker isolation posture than a normal install, and it matters beyond multi-accounting: sensitive data handling assumptions get shakier when your process is a guest.

The fraud patterns that follow are predictable:&#x20;

* Signup-bonus farming
* Free-trial recycling
* Referral self-dealing
* Review manipulation
* Gaming multi-accounting
* Voucher abuse&#x20;

These are not exotic attacks. They are a spreadsheet exercise for someone with a phone and an afternoon.

## What Talsec detects

### freeRASP

**freeRASP includes multi-instancing detection**, and it is the direct answer to this problem - [multi-instancing detection](https://docs.talsec.app/appsec-articles/articles/introducing-multi-instancing-detection-for-freerasp). The signal tells you that your app is running as a non-primary instance or inside a hosting environment, which is precisely the fact your device-based control needed and could not otherwise obtain. It sits alongside the rest of the free baseline: `privilegedAccess`, `hooks`, `appIntegrity`, debugger and emulator detection.

{% hint style="success" icon="shield-quartered" %}
freeRASP is free and available for [Android, iOS, Flutter, React Native, Capacitor and more](https://docs.talsec.app/freerasp/integration).&#x20;
{% endhint %}

### RASP+

[**RASP+**](https://docs.talsec.app/premium-products/product/rasp+) is what you want when this is alive fraud channel rather than a curiosity:&#x20;

* Configurable response policy so you can restrict promotional eligibility without blocking the app outright
* Maintained coverage as container implementations change
* Talsec App Security Portal telemetry so you can size the problem across your real user base.&#x20;

{% hint style="success" icon="shield-quartered" %}
See [RASP+](https://docs.talsec.app/premium-products/product/rasp+) and the [tier comparison](https://docs.talsec.app/freerasp/features-and-pricing-plans/the-key-differences-freerasp-vs.-rasp+).&#x20;
{% endhint %}

### AppiCrypt

[**AppiCrypt**](https://docs.talsec.app/premium-products/product/appicrypt) matters here for a reason specific to this threat: the abuse is fundamentally about *identity at the account layer*, and account decisions happen on your backend. An integrity attestation that your server verifies lets you make eligibility decisions with device-integrity context attached, rather than trusting a client-reported identifier that the hosting environment can shape.

## Edge cases and caveats

**This is the most false-positive-prone signal in the batch.**\
OEM dual-app is a shipped, advertised, mainstream feature used by an enormous number of ordinary people for completely ordinary reasons. Treating every multi-instance as fraud will punish real customers at scale.

**Therefore: separate the response from the detection.** \
The right use is usually to make *promotional and trial eligibility* conditional, not to block the app. A user running your app in Dual Messenger should still be able to log in and use it; they just should not get a second signup bonus.

**Distinguish container types where you can.**\
A vendor dual-app instance and a third-party virtualisation host are different risk profiles. Confirm with the Android team what the SDK currently distinguishes before you build policy that assumes a distinction.

**Detection coverage varies.**\
Container implementations differ and evolve; expect this to be a maintained capability rather than a solved one.

**Some legitimate enterprise setups look similar.** \
Work profiles and MDM-managed instances can produce related signals. Know your user base.

## Security todo list

{% stepper %}
{% step %}

### **Check whether your one-per-device controls are actually one-per-device**

Pick your highest-value promotion and ask how it would hold up against fifty instances on one handset. Most teams have not asked.
{% endstep %}

{% step %}

### **Read the** [**device ID article**](https://docs.talsec.app/appsec-articles/articles/fraud-proofing-an-android-app-choosing-the-best-device-id-for-promo-abuse-prevention)

and log it for a few weeks before enforcing anything. You need the baseline rate, and given how common OEM dual-app is, that rate will probably be higher than you expect.
{% endstep %}

{% step %}

### **Turn on multi-instancing detection** via [freeRASP](https://docs.talsec.app/freerasp/integration)

and re-derive which decisions genuinely depend on them. Anything financially consequential should not.
{% endstep %}

{% step %}

### **Scope the response narrowly**

Gate bonuses, trials and referrals. Do not gate login.
{% endstep %}

{% step %}

### Move eligibility decisions server-side with [AppiCrypt](https://docs.talsec.app/premium-products/product/appicrypt)

So the decision is not made by a client running inside someone else's sandbox.
{% endstep %}
{% endstepper %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.talsec.app/appsec-articles/articles/cloning-and-containers-running-your-app-inside-someone-elses-sandbox-and-how-talsec-detects-it.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.