What happens when an Android app loads code from writable storage after another app has modified it?

How Writable Storage Turns Into Code Execution

When an app loads code from a location another app can modify, the trust boundary is the storage path itself. The app is no longer executing only what its developer shipped, it is also executing whatever the writable location contains at load time.

That creates a classic code substitution problem. If the code loader accepts files from shared, external, or otherwise writable storage, then integrity depends on whether the app verifies the file before loading it, not just on whether the path looks local.

On Android, the danger is especially sharp when the loaded module runs inside the target app process. The malicious replacement inherits the target app’s permissions and can act with the same access the app already has, which makes the storage write a code execution trigger rather than a simple file tamper.

What the Attacker Gains After the Swap

Once modified code is loaded, the target app may execute attacker-controlled instructions under its own identity. That means the attacker can often reach whatever the app can reach, including app-private data, network endpoints, Bluetooth APIs, and any privileged operations the app is allowed to perform.

The practical consequence is privilege reuse, not a full device takeover by default. The attack is bounded by the app’s granted permissions and runtime capabilities, but those bounds are often broad enough to make the compromise serious, especially if the app is trusted to handle sensitive data or device functions.

Writable-storage loading also weakens update trust. A file that was safe at install time can become unsafe later if another app, a user-accessible process, or a compromised component can replace it before the next load.

Why This Pattern Is Hard to Defend With Path Checks Alone

Defensive logic that only checks the file location, file name, or extension is usually not enough. The meaningful control is integrity, which means the app should know whether the bytes it is about to execute are the same bytes it intended to trust.

Developers should also treat shared storage as hostile by default. If code, plugins, scripts, or native libraries must be loaded dynamically, the safer pattern is to keep them in app-controlled, non-writable storage and to authenticate the content before execution.

Android’s permission model does not neutralize this issue. If the app itself has powerful permissions, attacker-controlled code loaded into that app can make direct use of them without needing to break the platform sandbox first.

Risk and Threat Considerations

This pattern is dangerous because it turns file write access into code execution. The attacker does not need to defeat the app’s permission model if they can replace code that the app later trusts and runs.

Failure mechanism: A writable path lets another app, process, or user action modify executable content before the target app loads it, so the loader becomes the enforcement point for integrity and trust.

Impact: The compromised app may run attacker code with its own permissions, enabling data theft, unauthorized network activity, privilege-abuse actions, or further persistence if the attacker can keep replacing the loaded payload.

Practitioner Guidance

What to verify: Confirm whether the app ever loads dex, native libraries, scripts, or other executable content from storage that is writable by another app or by the user. If it does, verify that the load path is protected by cryptographic integrity checks, not just filesystem permissions.

Common mistake: Treating “internal storage” as automatically safe without checking whether the specific file is replaceable through backup restore, export paths, shared directories, symlinks, or a plugin/update mechanism.

What good looks like: Executable content is stored in app-controlled locations, updated through a trusted pipeline, and validated before every load; anything mutable is treated as untrusted input, not as code.

Practitioner takeaway: If another app can change what gets loaded, then code trust has already shifted from the developer to the storage path, and that is the control boundary you must secure.

Related resources from NHI Mgmt Group

• What happens when a virtual Android device is deleted after secure app testing?
• What happens when Android activities, exported components, or private storage are misconfigured in a mobile app?
• Why can a single SaaS app create such a large blast radius?
• Why do still-valid secrets matter after public disclosure?