Otukan detects modified and repackaged copies of your app by comparing what is running with what you shipped: its code and resources, the certificate it is signed with, and its code in memory. Checks inside the app make those comparisons at launch and again before sensitive steps, and platform attestation lets your server confirm the result independently. Just as important, Otukan knows your legitimate builds, so store signing, updates and approved variants pass cleanly. A failed check becomes a signal to your backend, where your policy decides whether to observe, restrict or stop the session.
For combined static and runtime protection, see mobile app shielding.
Integrity scope
A copy of your app can be changed at three levels. Otukan checks each one, because a check on one level says nothing about the others.
| Level | What changes | Typical attacker goal | How Otukan detects it |
|---|---|---|---|
| Package | Code, resources or configuration inside the app | Remove a licence or security check, change an endpoint, insert adware | File contents are compared with the release build |
| Signature | The certificate or team identifier the app is signed with | Distribute the modified copy outside your channels | Signing identity is compared with your channels’ identities |
| Runtime | Code or data in memory after launch | Change a function’s result during a session without touching the package | Checks repeat in memory during the session, with hooking detection |
Package and signature changes usually come together: once the files change, the original signature is invalid, so the copy must be re-signed. Runtime modification needs no new package, which is why Otukan pairs integrity checks with mobile RASP and hooking detection. Obfuscation keeps the checks themselves hard to find and remove.
Authorised change
Integrity checks that flag your own releases are worse than none. Otukan starts from a list of every legitimate way your app can differ, and each one is expected by design.
| Scenario | Android | iOS | Otukan result |
|---|---|---|---|
| Store signing | With Play App Signing, users receive Google’s app signing certificate, not your upload certificate | App Store builds are re-signed by Apple for distribution | Pass |
| Store delivery format | Google Play generates split APKs from your App Bundle for each device | App Store thinning delivers device-specific variants | Pass |
| Update from previous release | New code and resources, same signing identity | New build, same team identifier and bundle identifier | Pass |
| Beta and internal channels | Play testing tracks use the same app signing key; non-store channels may use other keys | TestFlight, ad hoc and development signing | Pass, when listed for that build |
| Enterprise or managed distribution | Managed Google Play or private channels | Custom apps or enterprise distribution | Pass, when listed |
| Modified and re-signed copy | Different signing certificate | Different team identifier | Signal |
| Resource edited, re-signed | Resource contents differ | Bundle contents differ | Signal |
Otukan records which signing identities are legitimate for each build and channel. When you rotate a key or open a new channel, the expectation is updated before the release, so your users are not caught out. For key handling, see app signing security.
Enforcement on your terms
A failed integrity check shows that something differs; it does not prove fraud. Security researchers, users who sideload an older release and devices with unusual configurations can all produce an unexpected install. Otukan is built to act on that difference with judgement.
Detection
Checks run at launch and repeat before sensitive steps, because runtime modification can start after launch. Where the platform offers attestation, your server verifies it rather than trusting a result the app reports about itself. Obfuscation protects the checks, so they are hard to locate and strip out.
Response
The signal travels to your backend with the request it concerns, and your policy decides: allow and record, step up authentication, restrict payments or account changes, or refuse the session. Keeping the decision on the server means a modified copy cannot patch it out. Policy design is covered on threat response.
Testing
Otukan tests each scenario in the table above together with your team. In an authorised lab, a modified copy is built, re-signed and installed to confirm the expected signal. Builds from each legitimate channel are then installed to confirm nothing fires. Install, update, sign-in and your most sensitive flow are repeated, with versions, devices, results and the reviewer recorded.
For the wider protection model, return to mobile app security. If your app is already published, start with a free App Exposure Check of the public store release. For a structured way to evaluate options, see the anti tampering solution guide.