Unsigned Dynamic Code Loading
How Unsigned Dynamic Code Loading works
Loading code at runtime (DEX/JAR/WebView JS) from external storage or the network without signature verification allows attackers to inject arbitrary code into the app process.
Unsigned Dynamic Code Loading in practice
Find Dynamic Class Loading
rg -n "DexClassLoader|PathClassLoader|System.loadLibrary|loadUrl\(" src outIf code pulls modules from writable paths or URLs, it is exploitable.
Attempt External Load (Android)
If the app uses DexClassLoader with external paths, dropping a crafted DEX into that location can grant code execution under app context.
How to fix and prevent Unsigned Dynamic Code Loading
- Avoid dynamic loading
- Ship all code in signed bundles; disable runtime loading in release builds.
- Verify source and integrity
- Enforce signature checks and strong integrity (hash+signature) before loading modules.
- Restrict paths
- Never load from external/world‑writable locations; prefer internal storage with strict permissions.
Last updated
