Doesn't the operating system already block injected code?

On an unmodified device, code signing and the sandbox do most of that work, and they should stay your first line. They stop helping when the device is rooted or jailbroken, or when the app itself has been repackaged with extra code and signed again. Otukan covers those gaps from inside the app, where the loaded code is visible.

What about Flutter, React Native and our own plugins?

Cross-platform frameworks load their own engines and runtimes, and many apps add plugins of their own. Otukan's expected module set includes the framework your release uses and the plugins you declare, so legitimate modules are recognised as yours. Anything outside that set is reported with its name and load path.

Can injected code hide from these checks?

Injected code can try, but hiding takes work and leaves traces of its own. Otukan checks the loaded module set, the load paths and the protected memory regions separately, and repeats them during the session. An attacker has to defeat several independent checks and a backend that expects the signal, which makes injection slower and more expensive.

How do we test this before release?

In an authorised lab, add a test module to a build and load it through each route your threat model names, then confirm the signal and the response. Repeat the journeys on a clean device with every production SDK present to confirm silence. Otukan runs these passes with your engineers and records devices, versions and the reviewer.

Application security feature

Code injection prevention

Otukan knows which code belongs in your Android or iOS app's process, detects foreign modules and patched memory, and responds before sensitive logic runs.

Discuss your app protection requirements Check your app's exposure

Android
iOS
Flutter
React Native

A known module set
Otukan knows which libraries and code regions your release brings with it, including framework runtimes, and treats anything else as a finding.
Your process, your code
Anything running inside your process shares your permissions, tokens and data. Otukan watches that boundary for the whole session.
Evidence for the server
Each injection finding names the module and where it loaded from, and travels to your backend with the affected request.

Injection routes Otukan detects

Pick a route to see how Otukan detects foreign code, what the app does and what your team receives.

Loader tampering on modified devices

Detect
Otukan recognises libraries forced into the process through the system loader on rooted Android devices and jailbroken iPhones.
Respond
Sensitive flows stay closed while unexpected modules are present.
Report
Your backend receives the module name and load path.

Libraries added to a copy

Detect
Otukan compares the modules packaged with the running app against those in your genuine release.
Respond
Per your policy, an altered copy is stopped before sign-in opens.
Report
The finding records the extra module alongside the app version.

Code loaded at runtime

Detect
On Android, Otukan watches for executable code loaded from writable storage that your release did not declare.
Respond
The app follows your policy, from recording to ending the session.
Report
The source location of the loaded code is reported for investigation.

Patched code in memory

Detect
Otukan checks that executable regions holding your protected code still match what was loaded from the release.
Respond
The protected operation is refused before patched code can run.
Report
Your security team sees which protected region changed.

Controls that reinforce injection prevention

Foreign code is rarely the end goal, so these controls protect what it would reach next.

Memory protection
Guards tokens, keys and decrypted values while they sit in memory, the first place injected code goes looking.
Anti-tampering
Checks that packaged code and resources are still the ones you released, closing the route of editing the app itself.
Binary protection
Hardens compiled native code so its functions are harder to locate and patch from injected modules.
Runtime threat signals
Delivers injection findings to your backend and security tooling in a consistent shape alongside other runtime signals.

You choose the response

Set a response for each user flow. Start by observing, then tighten flow by flow as the signals prove themselves.

Observe

Signal sent to your backend

Rolling out a new policy and measuring real-world signals.

Warn

This device looks modified. Continue with care.

Conditions some genuine users create, such as developer settings.

Restrict

Payments are unavailable on this device.

Payments, stored data and account changes.

Terminate

Session closed for your security.

Clear tampering on a high-risk flow.

How it works

Record the module set
The protected release carries a description of the code it is expected to load.
Compare while running
Otukan checks loaded modules and protected memory at launch and throughout the session.
Act before the logic
A finding triggers the response you set before token, key or signing code runs.
Report the module
Module name, load path and platform reach your backend with the affected request.

Code injection prevention should answer one question: does the product know which code belongs in your app’s process, and does it act when something else appears there? Otukan does both. It records the modules your release is expected to load, compares them with what is actually running on Android and iOS, and checks that protected code in memory has not been patched. When foreign code shows up, the app applies your response before tokens, keys or signing logic are touched, and the finding reaches your backend. Injection prevention adds to the operating system’s code signing, covering the gaps opened by modified devices and modified copies.

For the full set of integrity controls, return to application integrity.

Where injected code does damage

Injected code runs with your app’s identity. It can read what your app reads, send what your app sends and change what your app decides. That makes the process boundary the trust boundary that matters.

Affected flows

The harm lands in a handful of flows. Session tokens are copied out of memory and replayed elsewhere. Requests are altered after the user confirms them but before your app signs them. A biometric or PIN result is replaced with a pass. A server-issued limit is ignored on the device. Each of these starts with code your team never wrote running beside code it did.

The trust boundary

The platform treats everything inside your process as your app: it lets that code use your keychain or keystore entries, your network session and your files. Otukan draws a line inside that boundary between code your release brought and code that arrived later.

Entry route	Android	iOS	What Otukan checks
System loader tampering	Needs a rooted device	Needs a jailbroken device	Modules loaded against the expected set
Library added to a copy	Re-signed APK with an extra native library	Re-signed bundle with an extra dynamic library	Packaged modules against the genuine release
Code loaded at runtime	Executable code read from writable storage	Blocked for unsigned code on unmodified devices	Undeclared code sources on Android
Memory patching	Protected native code rewritten in place	Protected code rewritten on a modified device	Protected executable regions

Who does what

Code injection is stopped best when the operating system, the app and the backend each do the part only they can do.

The operating system

Android and iOS enforce code signing and sandboxing. On iOS, unmodified devices refuse to execute unsigned code pages. On Android, the platform verifies the package signature at install and update. These controls weaken once the device is rooted or jailbroken, and they do not object to a copy that someone else signed properly.

The app

Only code inside the process can see the modules loaded beside it. Otukan’s checks run there at launch and during the session, and compare what they find with the module set recorded for your release, including your framework runtime and declared plugins.

The backend

Your server cannot see the device, but it can refuse a request. Otukan attaches injection findings to the requests they affect, so your backend can decline a token refresh or a transfer that came from a process carrying foreign code.

Layer	Responsible for	Cannot see
Operating system	Signing, sandbox, install-time checks	Code added to a properly re-signed copy
App with Otukan	Loaded modules, protected memory, in-flow response	Anything outside its own process
Backend	Final decision on each request	The device itself

How to evaluate code injection prevention

Supported platforms

Ask for each injection route to be scoped separately for Android and iOS, with the OS versions covered. Runtime code loading, for example, is an Android concern with no direct iOS counterpart on unmodified devices. Confirm how Flutter and React Native engines are recognised as legitimate.

Evidence to ask for

Request a reproducible test for each route: a test module loaded through the system loader on a modified device, a module packaged into a re-signed copy, and a patched protected function. For each, confirm the in-app response and the record your backend receives, including module name and load path.

User-impact checks

Accessibility services, device-maker extensions and your own analytics SDKs also interact with your app at runtime. Run your normal journeys on clean devices with every production SDK in place and confirm no injection finding fires. Then repeat install, update, sign-in and the flow you protect most, before and after enforcement.

Related protection for compiled code is covered on binary protection.

Common questions

Doesn't the operating system already block injected code?
On an unmodified device, code signing and the sandbox do most of that work, and they should stay your first line. They stop helping when the device is rooted or jailbroken, or when the app itself has been repackaged with extra code and signed again. Otukan covers those gaps from inside the app, where the loaded code is visible.
What about Flutter, React Native and our own plugins?
Cross-platform frameworks load their own engines and runtimes, and many apps add plugins of their own. Otukan's expected module set includes the framework your release uses and the plugins you declare, so legitimate modules are recognised as yours. Anything outside that set is reported with its name and load path.
Can injected code hide from these checks?
Injected code can try, but hiding takes work and leaves traces of its own. Otukan checks the loaded module set, the load paths and the protected memory regions separately, and repeats them during the session. An attacker has to defeat several independent checks and a backend that expects the signal, which makes injection slower and more expensive.
How do we test this before release?
In an authorised lab, add a test module to a build and load it through each route your threat model names, then confirm the signal and the response. Repeat the journeys on a clean device with every production SDK present to confirm silence. Otukan runs these passes with your engineers and records devices, versions and the reviewer.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

FeatureAnti Frida
FeatureApp repackaging and resigning detection
FeatureOs integrity signals

Keep foreign code out of your app

Tell us the platform, the framework and which part of your app must only ever run its own code, such as token handling or request signing. Keep binaries, signing keys and production credentials to yourself; we never request them.

Discuss your app protection requirements Get a free app exposure check

Or request a technical demo

Code injection prevention

A known module set

Your process, your code

Evidence for the server

Injection routes Otukan detects

Controls that reinforce injection prevention

Memory protection

Anti-tampering

Binary protection

Runtime threat signals