101 lines
3.2 KiB
Markdown
101 lines
3.2 KiB
Markdown
---
|
|
name: analyzing-android-dex-malware
|
|
description: 'Reverses Android malware: unpacking APKs, decompiling DEX bytecode to readable
|
|
Java, auditing the manifest for abused permissions and components, and locating dynamically
|
|
loaded or native payloads. Activates for requests to analyze an APK, decompile DEX, or
|
|
investigate a suspicious Android app.'
|
|
domain: cybersecurity
|
|
subdomain: reverse-engineering
|
|
tags:
|
|
- reverse-engineering
|
|
- android
|
|
- dex
|
|
- apk
|
|
- mobile
|
|
- decompilation
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1059
|
|
- T1406
|
|
- T1577
|
|
d3fend:
|
|
- D3-FCR
|
|
- D3-DA
|
|
references:
|
|
- 'Android DEX bytecode format — https://source.android.com/docs/core/runtime/dex-format'
|
|
- 'jadx DEX-to-Java decompiler — https://github.com/skylot/jadx'
|
|
---
|
|
|
|
# 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:
|
|
|
|
```bash
|
|
python scripts/analyst.py inspect sample.apk
|
|
```
|
|
|
|
```text
|
|
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
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the APK inspector.
|
|
- Android DEX format and jadx (linked in frontmatter).
|