Evaluate memory protection by following one sensitive value through its whole life in your app, whether a session token, a card number, a decryption key or an account balance, and asking where it can be read or changed while the app runs. Check three things: exactly which values and buffers are exposed, how long each stays in plaintext and where plaintext cannot be avoided, and how protection is validated without mistaking storage encryption for it. This applies to Android and iOS apps, each scoped separately. Otukan guards sensitive values at runtime and detects the tools attackers use to read or rewrite memory.
The control itself is covered on mobile app memory protection.
Exposure
Memory attacks are specific. Nobody steals “memory”; they lift one token or change one number. Start with the list.
Values worth protecting
- Which secrets pass through memory: access and refresh tokens, cryptographic keys, one-time codes, card and account numbers?
- Which values cause harm if altered rather than read: balances, transfer limits, entitlement flags, prices?
- Which buffers carry them: network responses, parsed JSON, text fields, camera frames of identity documents?
Routes into the process
- Does the solution notice a debugger attached to the running app?
- Does it detect instrumentation frameworks that read values as they are decrypted?
- Does it recognise emulators, where an attacker can dump process memory at will?
- How does it treat rooted Android and jailbroken iOS devices, where other processes gain wider access?
| Value | Main threat | Example consequence |
|---|---|---|
| Refresh token | Read | Session replayed from another device |
| Encryption key | Read | Stored data decrypted offline |
| Transfer limit | Altered | Checks in the app bypassed before the server sees the request |
| One-time code | Read | Second factor used by someone else |
How Otukan answers. Otukan detects debuggers, instrumentation frameworks and emulators while your app runs, and it reacts when code is injected into the process. Sensitive values you select receive memory protection, so they are harder to locate and harder to change in place.
Lifetime
Every value is readable at some moment. The aim is to make that moment short, known and watched.
Sensitive-value lifecycle
| Stage | Question to answer | Android note | iOS note |
|---|---|---|---|
| Creation | Where does the value first appear in plaintext? | Kotlin and Java strings are immutable and cannot be wiped; prefer byte or char arrays | Swift strings can be copied by the runtime; prefer buffers you control |
| Use | Which components receive a copy? | Libraries, logging and UI bindings may keep their own | Same concern for frameworks and view models |
| Clean-up | Is the buffer overwritten after use? | Arrays can be zeroed; garbage collection timing is outside your control | Buffers you allocate can be zeroed before release |
| Accepted boundary | Where must it stay readable? | Text on screen, the TLS layer | Text on screen, the TLS layer |
Keep keys out of the app
- Is key material held in the Android Keystore, or in the iOS Keychain and Secure Enclave, wherever the operation allows, so the app never holds it in plain form?
- Are decrypted values released the moment the operation completes?
- Are sensitive values excluded from logs, crash reports and analytics?
- Is the accepted plaintext window written down for each value, with an owner?
How Otukan answers. Otukan keeps protected values encrypted in memory between uses, holds them in clearable buffers rather than immutable types where the platform allows, and wipes key material straight after each cryptographic operation. We document the plaintext boundary for each sensitive value together with your engineers. Where a value must be readable, such as text shown on screen, it is recorded as an accepted boundary and covered by runtime detection of the tools that would read it.
Validation
Storage encryption protects data at rest. It says nothing about what can be read from a live process, so test memory protection on its own terms.
Authorised memory test
- Plant a known test value in your own build and search process memory for it, with and without protection, on a device you control.
- Try to change a protected value while the app runs and record whether the app notices and how it responds.
- Repeat on Android and on iOS, and keep the results apart.
Legitimate runtime baseline
- Confirm crash reporting, accessibility services and performance tools keep working with protection switched on.
- Measure start-up time and your most sensitive flows on devices you choose.
- Record which response each detection triggers, and check it matches the flow.
How Otukan answers. Otukan supports an authorised memory test in your own lab with test values, so your engineers see the difference directly. When tampering with a protected value is detected, the app applies the response you chose for that flow, from observing quietly to ending the session, and your backend receives the memory-access signal with the next request.
Related runtime controls are covered on hooking detection and anti-debugging. Inventorying what the app carries and assigning the key lifecycle are covered on the secrets and key protection solution guide.