You reduce abuse from cloned or repackaged clients by making every sensitive request prove that it comes from your genuine, unmodified app, and by letting your backend refuse the ones that cannot. Otukan builds that proof into your Android and iOS release: integrity checks catch modified and re-signed copies on the device, and platform attestation gives your server evidence it verifies itself. A counterfeit copy or a script imitating your traffic then loses access to accounts, rewards and content. Otukan does not take fake apps off stores or search the internet for lookalikes; it makes them worthless against your API.
Threat boundary
“Fake app” covers two different problems. Only one of them runs your code or calls your API, and that is the one app protection can stop.
| Threat | What it is | Runs your code? | Calls your API? | Who handles it |
|---|---|---|---|---|
| Repackaged copy | Your app, unpacked, changed and re-signed | Yes | Yes | Otukan integrity checks and your backend |
| Modded build | A repackaged copy with unlocked or cheat features | Yes | Yes | Otukan, plus your game or content backend |
| Scripted client | Code that imitates your app’s network traffic | No | Yes | Your backend, using Otukan evidence |
| Lookalike app | A separate app copying your name and design | No | Usually not | Brand, legal and store reporting |
| Phishing site | A web page imitating your brand | No | Sometimes, with stolen credentials | Brand teams and account takeover prevention |
The first three all end at your API. That is where Otukan puts the gate.
Trust enforcement
The strongest defence against a fake client is a server that asks for evidence a fake cannot produce.
A clone-to-API scenario
An attacker downloads your app, removes the checks that block a promotion, re-signs it and shares it. On the device, Otukan’s integrity checks see a different signing identity and altered code, and the copy can refuse its sensitive paths. Suppose the attacker strips those checks too. The copy’s requests still arrive at your API without valid genuine-app evidence, and your backend declines the reward. Once the attacker gives up on the app and writes a script against your API, that script has no evidence either.
What the server checks
| Signal | Where it comes from | What your backend decides |
|---|---|---|
| Genuine-app evidence | Otukan in your protected release | Serve, limit or refuse the request |
| Platform attestation | Play Integrity on Android, App Attest on iOS, verified by your server | Whether the app and device meet your bar |
| Integrity and environment signals | Otukan runtime checks | Step up, restrict or flag the account |
Why the evidence is hard to forge
The evidence is produced inside your protected release, tied to that release’s integrity checks and hidden by obfuscation. A copy that has been altered no longer produces it correctly, and a script that never ran your app has nothing to present. Pairing it with platform attestation means your server also has evidence it checks with the platform itself, rather than relying on the client alone.
Your API gateway or backend enforces the result per endpoint. Sign-in, rewards and purchases can be strict while public content stays open. Android and iOS evidence is produced and verified separately, as each platform’s services differ.
Limitations
Otukan protects everything that runs your code or calls your API. Beyond that, the lines are clear.
- No store takedown. Removing a lookalike listing is a store and legal process. Otukan’s contribution is that the listing’s app cannot use your service.
- No universal clone search. Otukan finds modified copies when they run and fake clients when they call your API. It does not crawl stores or the web.
- Older releases need a plan. Users on releases shipped before protection send no evidence. Enforcement is therefore set per endpoint and tightened as users update.
- Evidence complements account security. A genuine app can still be used by a fraudster with stolen credentials, so the signal feeds your wider risk decision.
Before enforcement, the clone-to-API scenario is reproduced with your team in an authorised lab: a modified copy and a script are run against a test backend to confirm refusal, then the genuine release is exercised across install, update, sign-in and the protected flow to confirm it passes. Game studios will find the sector view on mobile game security, and the wider model on mobile app security. Messages that lure customers to counterfeit copies are covered on phishing and smishing detection.