Evaluate anti Frida protection by asking three things: which instrumentation mechanisms it detects, at which moment in which flow, and what it does to legitimate code that also touches the runtime. Frida is a widely used dynamic instrumentation toolkit that lets someone inject code into a running app and change what its functions return. Detection earns its place when it names the mechanism, fires before the sensitive step and stays quiet for your own SDKs. This guide covers Android and iOS apps, scoped separately. It sits beside hooking and debugger detection rather than replacing them.
The Otukan control is covered on anti Frida.
Mechanism
Instrumentation reaches an app in more than one way, and each leaves different evidence. Ask any solution to show its handling of each one.
Injected libraries
Code must get into the process first. On a rooted Android device or a jailbroken iOS device, a helper process can attach to your app and load an instrumentation library. On an unmodified device, an attacker can embed the library in a repackaged copy of your app instead. The first path depends on device state; the second depends on app integrity.
Function interception
Once inside, the toolkit rewrites the start of chosen functions so that its own code runs first. It can read arguments, change return values or skip a check altogether. This is the step that turns a login failure into a success or a detection into silence.
Runtime artefacts
Instrumentation runtimes leave traces while they work: extra threads, unexpected memory regions, open communication channels and modified code pages. These traces differ between Android and iOS and between injection modes.
| Mechanism | Android path | iOS path | Related control |
|---|---|---|---|
| Library injection by attaching | Needs root or a debuggable build | Needs a jailbroken device or a development-signed build that allows debugging | Root and jailbreak detection |
| Library embedded in the package | Repackaged and re-signed APK | Re-signed app bundle | Anti-tampering |
| Function interception | Native code and Java or Kotlin methods | C, C++, Objective-C and Swift code | Hooking detection |
| Runtime traces | Process memory and threads | Process memory and loaded images | Instrumentation checks |
- Does the solution detect each row separately on Android and on iOS?
- Does it still detect instrumentation embedded in a repackaged copy on an unmodified device?
- Does it report which mechanism fired?
How Otukan answers. Otukan detects instrumentation libraries in the app’s process, interception on the code paths you mark as sensitive and the traces instrumentation leaves behind. Its integrity checks catch a repackaged copy carrying an embedded library, and each signal names the mechanism it saw.
Execution context
Detection at launch alone leaves a gap: instrumentation can attach later. Decide where it matters.
- List the flows where a changed return value costs you most: login, payment approval, licence or entitlement checks, in-app value.
- For each flow, name the observable event, such as the request the app sends or the screen it unlocks.
- Decide whether the check runs at launch, before the event, or both.
- Decide what the backend should receive with that request.
A useful record looks like this: flow “approve payment”, event “approval request sent”, check “before the request”, backend receives “instrumentation signal and mechanism”.
How Otukan answers. Otukan repeats its checks before the sensitive actions you name, not only at launch. The signal travels with the request it concerns, so your server can refuse an approval that came from an instrumented session.
Policy validation
Test monitoring first, enforcement second, and legitimate code throughout.
Monitoring run
- In an authorised lab, instrument a test build through each injection path and confirm the expected signal.
- Confirm the signal reaches your backend with the right request and mechanism.
- Confirm the app keeps working in observe mode so that nothing is enforced yet.
Clean-runtime baseline
- Run the same flows with your crash reporting, analytics and performance SDKs enabled.
- Run your UI test automation and any accessibility services your users rely on.
- Confirm none of these produce an instrumentation signal, and record any that do.
Enforcement run
- Switch the chosen flows to restrict or terminate and repeat the instrumented tests.
- Confirm the customer sees a clear message and the session ends cleanly.
How Otukan answers. Otukan runs these three passes with your engineers before release, applies the response you choose per flow (observe, warn, restrict or terminate) and records results per platform with devices, versions and the reviewer.
The wider group of runtime checks is covered on mobile RASP. Other injection and interception methods are covered on the hooking and instrumentation detection solution guide.