Otukan raises the effort needed to understand your app by answering each analysis technique with its own layer. Against decompilers, it obfuscates managed code and protects strings and framework bundles. Against disassemblers, it hardens native libraries. Against live inspection, runtime checks detect debuggers, hooking and memory reading, then apply the response you set and tell your backend. The aim is cost, not magic: logic that ships to a device can be studied with enough time, so Otukan makes that time long and visible, and helps you keep the true secrets on your server. Android and iOS each get layers designed for their own formats.
Attack paths
Reverse engineering is three different activities, and a protection plan should treat them separately.
| Path | What the analyst does | What they learn | Otukan layer |
|---|---|---|---|
| Decompilation | Turns managed code or framework bundles back into readable source | Class structure, business rules, endpoints, embedded keys | Obfuscation, string protection, bundle protection |
| Disassembly | Reads compiled native code as machine instructions | Encryption routines, licence checks, native security logic | Binary hardening and symbol reduction |
| Runtime inspection | Watches the app run with a debugger, hooks or memory reads | Values after decryption, decisions as they are made | Anti-debugging, hooking detection, memory protection |
Android
Android packages carry managed bytecode that decompiles back to something close to source, plus native libraries. R8 shrinks and renames code at build time; Otukan goes further with control-flow changes, string protection and native hardening.
iOS
iOS apps ship as compiled machine code, so the main static path is disassembly of the executable and its frameworks. Otukan’s iOS layers target symbols, strings and Swift and Objective-C metadata that give an analyst a map.
Cross-platform frameworks
React Native apps carry a JavaScript bundle or Hermes bytecode; Flutter apps carry compiled Dart code. Both hold real business logic, and Otukan protects them on top of the platform layers. .NET MAUI release builds, with their managed assemblies, are covered on .NET MAUI app security.
Layered resistance
No single layer does the job. Each one covers a gap the others leave.
Hardening the package
Asset encryption and binary protection make the unpacked app less useful. Configuration files, scripts and native libraries stop revealing their purpose at a glance, and static patching gets harder.
Obfuscation
Renaming, control-flow changes and string protection strip meaning from decompiled output. Otukan concentrates the strongest settings on the modules you ranked highest and matches the rest of the app to its value. Details are on mobile code obfuscation.
Instrumentation controls
Static layers slow down reading; they do not stop someone watching the app run. Runtime checks detect debuggers, hooking frameworks and injected code, and the app responds per flow. The signal goes to your backend, where an analyst on the device cannot change the outcome. Runtime detail is covered on mobile RASP.
Measuring resistance
Protection is only useful if you can see its effect. Otukan and your engineers analyse an unprotected build and a protected build side by side in an authorised lab, using the same classes of technique an outside analyst would use. For each module you ranked, the record notes what could be read, located or changed in each build, and which runtime signals fired during the attempt. That comparison is repeated when the app changes significantly, so the protection plan follows the code rather than lagging behind it. It also gives your security review a concrete artefact instead of a vendor statement.
Limits of client-side protection
Everything that ships inside an app runs on hardware the attacker may own. Given unlimited time, a determined team can recover client-side logic and any secret embedded with it. Honest protection starts from that fact.
- Move true secrets server-side. Keys that let someone impersonate your app belong on the backend, issued per session.
- Treat the client as evidence, not authority. Your server decides; the app supplies signals.
- Make analysis slow and noisy. Layered protection turns quiet reading into a long effort that trips runtime checks along the way.
- Protect every release. Protection is applied to each build in your pipeline, so new code ships with the same layers as the last release.
Reverse engineering protection is one part of what mobile app security covers. If your app is already in a store, you can request a free App Exposure Check of the public release. For a structured way to evaluate options, see the anti reverse engineering solution guide.