Your app can identify runtime instrumentation by examining its own process for three kinds of evidence: the traces an instrumentation toolkit leaves behind, functions whose code or dispatch has been rewritten, and libraries that your release never loads. Otukan runs those checks inside your Android and iOS app at launch, at sign-in and before the actions you mark, and hands each finding to your backend with the request it affects. Detection on a device the attacker controls can be studied, so Otukan layers and repeats its checks and keeps the final decision on your server.
Hooking detection is one of the runtime controls described on mobile RASP.
Technique coverage
Instrumentation is not a single technique. An attacker who wants to read a token, skip a check or approve their own transaction will pick whichever method is easiest for that function.
| Evidence | What the attacker did | What Otukan examines | Android | iOS |
|---|---|---|---|---|
| Toolkit traces | Attached a dynamic instrumentation toolkit to your process | Components, threads and channels the toolkit introduces | Checks written for Android processes | Checks written for iOS processes |
| Inline hooks | Overwrote the start of a native function to jump elsewhere | The first instructions of protected functions | Native libraries | Native code and frameworks |
| Managed-code hooks | Replaced a method at the language runtime level | Method dispatch in the runtime | Java and Kotlin methods | Objective-C methods |
| Injected libraries | Loaded foreign code into the process | Loaded libraries against the expected set | Shared libraries in the process | Dynamic libraries in the process |
| Symbol rebinding | Pointed a call to a replacement function | Where system and library calls resolve | Linked function tables | Lazily bound symbols |
Why the platforms differ
Android and iOS load code differently, dispatch methods differently and expose different information to an app. Otukan writes its checks for each platform’s runtime and tests them on that platform’s devices. A check proven on Android says nothing about iOS, and Otukan treats them as separate controls.
Evasion limits
Attackers adapt. A detection that only looks for one file name or one port is defeated the day someone renames it. Otukan is designed around that reality, without publishing the details an attacker would want.
- Several views of the same attack. Traces, code integrity and loaded libraries are checked independently, so hiding one kind of evidence still leaves the others.
- Checks at more than one moment. Instrumentation can attach late, so checks repeat before sensitive actions, not only at launch.
- Protected checks. Obfuscation makes Otukan’s own checks hard to locate, and anti-tampering notices when they are removed from the package.
- A server that expects an answer. When a signal stops arriving, your backend can treat the silence itself as a risk.
We show your engineers how each check behaves in an authorised lab rather than on a public page. That keeps every customer’s protection stronger.
Response integration
A hooking signal is only useful if something acts on it. Otukan connects detection with a response in the app and a decision on your server.
| Moment | What the app does | What your backend can do |
|---|---|---|
| At launch | Holds back sensitive features until checks pass | Record the device’s state for later requests |
| At sign-in | Applies your policy for the login flow | Step up authentication or refuse the session |
| Before a transaction | Re-checks critical functions just before they run | Decline the transaction and flag the account |
| During the session | Repeats checks in the background of marked screens | Correlate signals with velocity and device history |
Signals are most useful when your team can act on them together. Each hooking signal names the layer and the protected function involved, so your security operations can group sessions by technique, spot a new tool spreading across accounts and adjust policy for the affected flow without waiting for the next release.
The app’s response can observe, warn, restrict or terminate, set per flow. A crypto wallet might terminate when a signing function is hooked, while a content app might only record the signal. For wallet flows, see crypto wallet app security. Identity checks face a related risk, which camera injection detection covers.
Before a protected release ships, the named functions are hooked in an authorised lab to confirm each signal. The same journey is repeated on clean devices to confirm silence, then install, update, sign-in and the protected flow are rerun, with versions, devices and the reviewer recorded. For a structured way to evaluate options, see the hooking and instrumentation detection solution guide.