Otukan’s mobile RASP (runtime application self-protection) puts checks inside your app that watch its own execution while it runs. It detects hooking and instrumentation, attached debuggers, emulators, rooted and jailbroken devices, and changes made to the app since you signed it. When a check fires, the app applies the response you chose for that user flow, from recording the signal to ending the session, and sends the signal to your backend so your server makes the final call. Checks are built separately for Android and iOS, so each platform gets protection designed for its own security model.
Combined static and runtime protection is covered on mobile app shielding.
Runtime boundary
What Otukan monitors
Otukan groups its runtime checks into signal families. Each family is tuned for attack tooling, and each has legitimate cases your policy should account for.
| Signal family | What Otukan looks for | Legitimate cases your policy accounts for |
|---|---|---|
| Instrumentation and hooking | Injected code, modified functions and instrumentation frameworks in the process | Accessibility and assistive tools that attach to apps |
| Debugging and tracing | A debugger or tracer attached to the running release build | Developers and testers on internal builds |
| Modified OS (root and jailbreak) | Traces of tools that remove the platform’s security assumptions | Enthusiast users and some custom system images |
| Emulators and virtual environments | Signs that the device is not physical hardware | QA farms and automated testing |
| App integrity | Code, resources or signing identity different from your release | Store re-signing, which Otukan’s integrity data expects |
Built for each platform
On Android, Otukan’s checks look at the app’s process, the system it runs on and the signing identity the app carries. Your server can combine these signals with a Play Integrity verdict it verifies itself. On iOS, the sandbox limits what any app can learn about the device, so Otukan concentrates on the app’s own process, the libraries loaded into it and the identity of the bundle. Your server can pair those signals with App Attest. Nothing is carried across from one platform to the other.
Raising the cost of attack
Every client-side check runs on a device the attacker may control. Otukan’s answer is depth: checks run at several points in the journey, and every result can reach your backend. An attacker who silences one check on the device still faces the next check and a server that expects to hear from it.
Response choices
What the app does after a detection matters as much as the detection. Otukan gives you four responses and lets you set them per check and per user flow.
| Response | What happens | Legitimate-user impact | Typical use |
|---|---|---|---|
| Observe | The signal is recorded and sent to your backend. Nothing changes for the user. | None | Rolling out a new policy; measuring how often checks fire |
| Warn | The user sees a message about the risk and can continue. | Light friction | Conditions that some legitimate users create, such as developer settings |
| Restrict | Specific sensitive functions are disabled; the rest of the app works. | Partial | Payments, stored data, account changes |
| Terminate | The session ends or the app closes. | High | Clear evidence of tampering on a high-risk flow |
The pattern that works is to start with observe, measure how often each check fires across your real users, then tighten flow by flow. Policy design is covered on threat response.
Lifecycle
Conditions change while the app is running, so Otukan ties checks and responses to moments in the user journey, not only to start-up.
At launch
Integrity and environment checks run before your sensitive code does. The result decides whether the app continues normally, continues with limits, or stops.
At authentication
Runtime signals do the most work when your backend sees them. Otukan sends them with the login request, so your server can step up authentication or refuse the session. The decision stays on the side the attacker cannot touch.
During transactions
A hooking framework can attach after launch. Otukan re-checks before a payment, a transfer or an account change, catching conditions that were not present at start-up. Handling runtime threat signals covers the backend side.
On every release
Otukan fits your existing build and release pipeline, and your signing keys stay with your team. Before a protected release ships, we work with your engineers to prove each check three ways: reproduce the behaviour in an authorised lab and confirm the signal, run the same journey on a legitimate device and confirm it stays quiet, then repeat install, update, sign-in and your most sensitive flow. Results are recorded with OS versions, devices and the reviewer.
For the wider picture, return to mobile app security. If your app is already published, you can request a free App Exposure Check of the public store release.