Analyzing Android DEX Malware
When to Use
- You have a suspicious
.apk (or bare .dex) and need to understand its behavior.
- You need to audit the manifest for dangerous permissions, exported components, and the
declared entry points.
- The app loads code dynamically (
DexClassLoader) or ships a native .so you must locate.
Do not use this workflow for iOS apps — DEX/APK tooling does not apply to Mach-O/IPA.
Prerequisites
- jadx (or apktool + a decompiler) and
unzip; an Android emulator/sandbox for dynamic runs.
aapt/manifest parsing for permissions and components.
Workflow
Step 1: Unpack the APK
An APK is a ZIP. Extract and inventory the DEX files, native libraries, and assets:
python scripts/analyst.py inspect sample.apk
dex : classes.dex, classes2.dex
native : lib/arm64-v8a/libpayload.so
assets : assets/config.enc (possible encrypted payload)
manifest : AndroidManifest.xml (binary)
Step 2: Audit the manifest
Decode AndroidManifest.xml and review requested permissions (SMS, accessibility, device
admin, REQUEST_INSTALL_PACKAGES), exported components, and the launcher/BOOT_COMPLETED
receivers.
Step 3: Decompile DEX
Run jadx to recover Java. Start at the launcher activity and any BroadcastReceiver/Service
declared in the manifest.
Step 4: Find dynamic and native code
Search for DexClassLoader/loadDex, asset decryption, and System.loadLibrary. Dump and
recurse on dynamically loaded DEX; analyze native .so separately if needed.
Step 5: Extract behavior and IOCs
Recover C2 URLs, overlay/accessibility abuse, SMS interception, and config; map to ATT&CK for
mobile in the report.
Validation
- Every DEX and native library in the APK is accounted for.
- Dangerous permissions are tied to concrete code paths (not just declared).
- Dynamically loaded payloads are dumped and analyzed, not just noted.
Pitfalls
- Reading only
classes.dex and missing classes2.dex/classes3.dex.
- Trusting the manifest alone; behavior may hide behind dynamic loading.
- Ignoring encrypted assets that become the real payload at runtime.
References