What happens when an app can write to a secondary dex file after installation?

If a writable secondary dex is available, an attacker who can plant a payload may replace or influence executable bytecode that the app later loads. On restart or reload, the modified dex can execute in the app’s process and deliver code execution inside the sandbox. That turns a file write into a practical compromise path, especially when the app dynamically loads extra code.

How writable secondary dex files turn into execution paths

Android expects installed code to be stable after deployment, but a writable secondary dex breaks that assumption. If the app later loads that dex dynamically, the file is no longer just data at rest, it becomes executable input. That creates a classic integrity failure: whoever can modify the file can potentially shape what code runs inside the app’s process.

The dangerous part is not the write itself, it is the combination of write access, a code-loading path, and a later load event. Once the app refreshes, restarts, or reaches the branch that loads the secondary dex, the modified bytecode can execute with the app’s own privileges. In practice, that can turn a storage weakness into a code execution primitive.

Why dynamic loading makes the compromise practical

Secondary dex loading is often used for modularity, feature splitting, or large apps that cannot fit all logic into the primary package. The moment the app trusts a file from disk as executable code, the attack surface shifts from standard input handling to runtime integrity. If the file can be changed after installation, the loader may faithfully import attacker-supplied logic instead of original application code.

That matters because the malicious code runs in the same sandbox as the app. It may not break Android process isolation outright, but it can inherit the app’s access to local data, session state, cached secrets, APIs, and any permissions the app already holds. For defenders, the key question is whether the load path is immutable, verified, and protected from tampering.

Platform and secure-coding guidance generally treat executable artifacts as integrity-sensitive, not as writable content. Controls around file permissions, package integrity, and runtime verification are the practical controls that close this gap. For broader hardening principles, see NIST SP 800-53 Rev 5 Security and Privacy Controls and OWASP API Security Top 10 when the app also loads code or data from exposed interfaces.

What the attacker gains after the dex is modified

Once the modified dex is accepted, the attacker is no longer limited to corrupting a file. They can influence app logic, intercept sensitive flows, alter decisions, or stage additional payloads for persistence. In a mobile app, that may include credential theft, local data access, fraud logic, or silent manipulation of security checks that normally live inside the app.

Because the code runs in-process, post-load detection is harder than with a simple file-injection event. The dangerous window is often when the app next starts or refreshes its dynamic modules, so compromise can remain dormant until the right execution path is reached. If the app also updates its own secondary code from writable storage, the attacker may keep replacing the payload after each restart.

When the question is whether a writable dex matters, the answer is yes whenever that file is part of the execution chain. In those cases, the file should be treated like privileged code, not as an ordinary cache or asset. If the app uses dynamic loading at all, the surrounding trust model should be reviewed with NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework only as broad governance references, not as substitutes for code integrity controls.

What defenders should verify before trusting secondary dex loading

Check whether the secondary dex is stored in a location that is writable by the app, a shared component, or any other lower-trust process. If the answer is yes, verify whether the app validates code integrity before loading and whether the file can be replaced between installation and execution. Also confirm whether the loader accepts only signed, packaged, or otherwise protected artifacts.

What to prioritise: treat any writable executable artifact as a code integrity issue, not a storage issue. If the app depends on dynamically loaded code, require a clear ownership model for who can write the file, who can read it, and what verification occurs before loading.

What to verify: confirm whether the app can load from immutable package storage, protected app-private storage, or a verified update channel. If not, test the exact restart or reload path that would activate the modified dex, because that is the point where compromise becomes real.

Practitioner takeaway: a writable secondary dex is dangerous because it collapses the boundary between file modification and code execution, so the control objective is to make executable artifacts immutable, verified, and non-user-writable before the loader ever touches them.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	CM-5 — Access Restrictions for Change	Writable dexes are code artifacts that need change restriction.
	SI-7 — Software, Firmware, and Information Integrity	The issue is executable integrity, not just file storage.
	AC-6 — Least Privilege	Reducing write rights limits who can alter executable code paths.
Recommendation — Restrict who can modify executable artifacts and verify file ownership before loading. Verify code integrity before loading and reject tampered secondary dex files. Minimize write access to code-loading directories and related update paths.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Dynamic code loading depends on controlled configuration and artifact states.
Recommendation — Keep dynamically loaded code under controlled configuration and change control.
OWASP ASVS	V15 — Secure Coding and Architecture	Runtime loading of writable code is an application architecture hardening issue.
Recommendation — Design dynamic loading so executable artifacts remain protected from tampering.