Frida is a widely used dynamic instrumentation toolkit: it places an agent inside a running app and rewrites functions from a script. Evaluate anti Frida protection by what happens when an instrumented session tries to change an outcome. Otukan detects the agent whichever way it arrived, attached to a live process, present from launch or packaged into a modified copy, and acts before the sensitive step completes. Your backend receives the signal with the request it concerns. Checks are built and tested separately for Android and iOS. Instrumentation becomes slower, costlier and visible, and your server keeps the final decision.
For the wider integrity picture, return to application integrity.
How Otukan recognises instrumentation
Instrumentation leaves three kinds of evidence, and Otukan treats each as its own signal, so your team knows what was found rather than receiving a single yes or no.
Injected agent libraries
Before a script can do anything, its agent has to be inside your process. Otukan inspects what is loaded there while the app runs. On Android and on iOS the agent reaches the process by different routes, and the checks follow each platform’s route.
Intercepted functions
The agent’s purpose is interception: redirecting a function so the script runs first and decides what the caller sees. Otukan confirms that the functions you mark as sensitive still begin with the code you shipped, so a login check, a licence test or a price calculation cannot be quietly rewritten.
Runtime leftovers
A working agent needs threads, memory and a channel to receive its instructions. Those leftovers remain visible even when the agent tries to hide its library, and Otukan looks for them as independent evidence.
| Signal | What Otukan examines | Android route | iOS route |
|---|---|---|---|
| Agent in the process | Code loaded into the app at runtime | Attached on a rooted device, or packaged into a re-signed APK | Attached on a jailbroken device, or packaged into a re-signed bundle |
| Rewritten function | Entry instructions of marked functions | Native and managed code paths | Native, Swift and Objective-C paths |
| Control channel | Threads and endpoints the agent opens | Checked within the app’s own process | Checked within the app’s sandbox |
Where the check fires
Detection at launch alone leaves a gap, because an agent can attach at any moment. Otukan ties its checks to the steps where a rewritten answer does damage.
| Flow | Observable event | When Otukan checks | What your backend receives |
|---|---|---|---|
| Sign-in | Credentials submitted | Before the request leaves the app | Instrumentation signal with the login request |
| Payment approval | Approval confirmed by the user | Immediately before approval is sent | Signal and route with the approval |
| Entitlement or licence | Premium feature unlocked | Before the feature opens | Signal with the entitlement request |
| Key use | Stored key read for signing | Before the key operation runs | Signal with the signed request |
Pick the events that matter
Start with the flows where a single changed return value turns a refusal into an approval. Name the event your server sees for each one. That event is where Otukan’s check should sit and where its signal should travel.
Let the server decide
A decision taken only on the device can be scripted away. Because the instrumentation signal accompanies the request, your server can refuse an approval that came from an instrumented session even if the app itself was silenced.
Proving the policy
A good anti Frida rollout proves two things: instrumentation is caught, and legitimate code is left alone. Otukan runs this validation with your engineers before a protected release ships.
Observe first
Release with the observe response on your chosen flows. In an authorised lab, instrument a test build through each route and confirm the expected signal reaches your backend with the right request. Nothing changes for users while you measure.
Your SDKs stay quiet
Crash reporters, analytics, performance monitors and UI automation also touch the runtime. Run the same journeys with them switched on and confirm that none of them trigger an instrumentation signal. Record any that do and tune before enforcing.
Enforce flow by flow
Move one flow at a time to restrict or terminate, repeat the instrumented tests and confirm the user sees a clear message. Then repeat install, update, sign-in and the sensitive flow on a legitimate device to confirm nothing regressed.
Evidence you keep
Each run is recorded with devices, OS versions, expected results and the reviewer, so the policy you enforce is one you have seen working.
Evaluation questions for buyers are covered on the anti Frida solution guide. Modified toolkit builds are covered on detecting modified Frida builds.