$npx -y skills add meltedinhex/analyst-ai-pack --skill analyzing-android-dex-malwareReverses Android malware: unpacking APKs, decompiling DEX bytecode to readable
| 1 | # Analyzing Android DEX Malware |
| 2 | |
| 3 | ## When to Use |
| 4 | |
| 5 | - You have a suspicious `.apk` (or bare `.dex`) and need to understand its behavior. |
| 6 | - You need to audit the manifest for dangerous permissions, exported components, and the |
| 7 | declared entry points. |
| 8 | - The app loads code dynamically (`DexClassLoader`) or ships a native `.so` you must locate. |
| 9 | |
| 10 | **Do not use** this workflow for iOS apps — DEX/APK tooling does not apply to Mach-O/IPA. |
| 11 | |
| 12 | ## Prerequisites |
| 13 | |
| 14 | - jadx (or apktool + a decompiler) and `unzip`; an Android emulator/sandbox for dynamic runs. |
| 15 | - `aapt`/manifest parsing for permissions and components. |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | ### Step 1: Unpack the APK |
| 20 | |
| 21 | An APK is a ZIP. Extract and inventory the DEX files, native libraries, and assets: |
| 22 | |
| 23 | ```bash |
| 24 | python scripts/analyst.py inspect sample.apk |
| 25 | ``` |
| 26 | |
| 27 | ```text |
| 28 | dex : classes.dex, classes2.dex |
| 29 | native : lib/arm64-v8a/libpayload.so |
| 30 | assets : assets/config.enc (possible encrypted payload) |
| 31 | manifest : AndroidManifest.xml (binary) |
| 32 | ``` |
| 33 | |
| 34 | ### Step 2: Audit the manifest |
| 35 | |
| 36 | Decode `AndroidManifest.xml` and review requested permissions (SMS, accessibility, device |
| 37 | admin, `REQUEST_INSTALL_PACKAGES`), exported components, and the launcher/`BOOT_COMPLETED` |
| 38 | receivers. |
| 39 | |
| 40 | ### Step 3: Decompile DEX |
| 41 | |
| 42 | Run jadx to recover Java. Start at the launcher activity and any `BroadcastReceiver`/`Service` |
| 43 | declared in the manifest. |
| 44 | |
| 45 | ### Step 4: Find dynamic and native code |
| 46 | |
| 47 | Search for `DexClassLoader`/`loadDex`, asset decryption, and `System.loadLibrary`. Dump and |
| 48 | recurse on dynamically loaded DEX; analyze native `.so` separately if needed. |
| 49 | |
| 50 | ### Step 5: Extract behavior and IOCs |
| 51 | |
| 52 | Recover C2 URLs, overlay/accessibility abuse, SMS interception, and config; map to ATT&CK for |
| 53 | mobile in the report. |
| 54 | |
| 55 | ## Validation |
| 56 | |
| 57 | - Every DEX and native library in the APK is accounted for. |
| 58 | - Dangerous permissions are tied to concrete code paths (not just declared). |
| 59 | - Dynamically loaded payloads are dumped and analyzed, not just noted. |
| 60 | |
| 61 | ## Pitfalls |
| 62 | |
| 63 | - Reading only `classes.dex` and missing `classes2.dex`/`classes3.dex`. |
| 64 | - Trusting the manifest alone; behavior may hide behind dynamic loading. |
| 65 | - Ignoring encrypted assets that become the real payload at runtime. |
| 66 | |
| 67 | ## References |
| 68 | |
| 69 | - See [`references/api-reference.md`](references/api-reference.md) for the APK inspector. |
| 70 | - Android DEX format and jadx (linked in frontmatter). |