Android Packers & Obfuscators¶
Packers (protectors, armoring tools) transform APKs to resist reverse engineering, tampering, and automated analysis. Legitimate developers use them to protect IP. Malware authors use them to evade detection and slow down analysts.
Obfuscators are a lighter category: they transform code to make it harder to read but don't encrypt or pack DEX files. Many protection products combine both.
APKiD can identify most commercial packers and obfuscators automatically.
Packers / Protectors¶
| Packer | Vendor | Vendor HQ |
|---|---|---|
| 360 Jiagu | Qihoo 360 | China |
| APKProtect | Nagain | China |
| Arxan (Digital.ai) | Digital.ai | USA |
| Baidu Reinforcement | Baidu | China |
| Bangcle (SecNeo) | Bangcle | China |
| Kiwisec (几维安全) | Kiwisec | China |
| SecShell | Bangcle / SecNeo (梆梆安全) | China |
| DPT Shell | luoyesiqiu (open source) | China |
| Ducex | Unknown (described as Chinese-origin by any.run) | China |
| GoldCrypt | Unknown (underground forums) | Unknown |
| DexGuard | Guardsquare | Belgium |
| DexProtector | Licel | USA / UK |
| Hqwar | Unknown (underground, Russian-speaking author per Kaspersky) | Russia |
| iJiami | iJiami | China |
| NeteaseYiDun | NetEase | China |
| Promon SHIELD | Promon | Norway |
| Tencent Legu | Tencent | China |
| Virbox | Beijing SenseShield Technology | China |
| AppSealing | INKA Entworks (rebranded to DoveRunner, Mar 2025) | South Korea |
| LIAPP | Lockin Company | South Korea |
| Appdome | Appdome Inc | USA / Israel |
| Zimperium zShield | Zimperium | USA |
| Verimatrix XTD | Verimatrix Inc. (XTD lineage from Inside Secure, France); acquired by Guardsquare Feb 2026 | USA / France |
Obfuscators¶
| Obfuscator | Type | Notes |
|---|---|---|
| R8 / ProGuard | Free (Google/open source) | Default Android build tools. Name obfuscation, dead code removal, optimization. R8 replaced ProGuard. |
| Redex | Free (Meta, MIT open source) | Meta's DEX bytecode optimizer. Class merging, inlining, InterDex layout, X.<short> renaming. Not a packer or RASP, but heavily degrades static analysis of Meta apps. |
| Allatori | Commercial | Java/Android obfuscator. String encryption, flow obfuscation, watermarking. |
| DashO | Commercial | PreEmptive Solutions. Obfuscation + tamper detection + analytics. |
| Zelix KlassMaster | Commercial | Aggressive flow obfuscation, string encryption, stack trace obfuscation. |
| OLLVM (Obfuscator-LLVM) | Open source | Control flow flattening, bogus control flow, string encryption for native code. Used by Mandrake. |
Protection Categories at a Glance¶
This is a category-level comparison (packer vs obfuscator vs RASP). For per-product feature-by-feature analysis, see the Packer Comparison Matrix further down.
| Feature | Packers | Obfuscators | RASP |
|---|---|---|---|
| Name obfuscation | Yes | Yes | No |
| String encryption | Yes | Some | No |
| DEX encryption | Yes | No | No |
| Native code wrapping | Yes | No | No |
| Anti-debugging | Yes | No | Yes |
| Anti-tampering | Yes | No | Yes |
| Root detection | Some | No | Yes |
| Emulator detection | Some | No | Yes |
| Runtime self-protection | Some | No | Yes |
RASP (Runtime Application Self-Protection) products like Promon SHIELD (vendor page), Appdome OneShield (vendor page), Arxan (Digital.ai), DexProtector (vendor page), LIAPP, and Verimatrix XTD focus on runtime checks rather than code transformation. They detect hostile environments (root, hooking, debugging, emulator, repackaging) and respond at runtime, often combined with a packer or obfuscator. The term was coined by Gartner; for vendor-neutral background see the OWASP RASP overview.
Malware Families by Packer¶
Commercial packers are increasingly adopted by malware authors. The packer provides anti-analysis protection without the developer needing to build their own.
| Packer | Families | Notes |
|---|---|---|
| Virbox | Gigabud (Zimperium), Klopatra (Cleafy), GoldDigger / GoldPickaxe (Group-IB) | GoldFactory standardized on Virbox; recent Gigabud / GoldDigger samples wrap a libstrategy.so native module per Zimperium. Virbox itself uses randomized native library names rather than a fixed filename. |
| DexGuard | (No primary-sourced banker attribution at present; many higher-tier apps and some unattributed samples use DexGuard but specific malware family use is not substantiated in public research surveyed) | Commercial Guardsquare protection; class-level DEX encryption, native library renaming and encryption (Guardsquare). No single canonical native library filename. |
| Tencent Legu | Various Chinese-market malware | Common in the Chinese market. Identified by version-suffixed libshella-<version>.so (ARM) / libshellx-<version>.so (x86) and asset assets/0OO00l111l1l per Quarkslab. |
| Ducex | Triada | Advanced Chinese packer with RC4 / SM4 function encryption and XOR string encryption; libducex.so plus in-DEX payload section per any.run analysis. Previously misattributed to Tencent Legu on this page. |
| 360 Jiagu | Chinese banking trojans, stalkerware | libjiagu.so / libjiagu_art.so, asset assets/jiagu_data.bin (per APKiD rules). Multi-DEX support. |
| Bangcle | Regional malware, adware | libsecexe.so / libsecmain.so markers (APKiD rules). |
| SecShell | Joker (Zscaler), Chinese malware | libSecShell.so plus assets/secData0.jar (APKiD rules). Bangcle second-gen. Dual RC4/SM4 cipher, self-packed native code. |
| Custom packers | Mandrake, SoumniBot | OLLVM-obfuscated native loaders (Mandrake), manifest parsing exploits (SoumniBot) |
| AppSealing | Korean banking apps, Unity games | Shipping library libcovault-appsec.so (older builds: libsecureapp.so); asset directory assets/AppSealing/. Bypass: AppPealing Xposed module (active against current builds). |
| LIAPP | Korean banking apps (KBPay, NH Bank) | Strong Korean protector with backend integrity-attestation flow (Lockin Company). No public bypass tool. |
| No packer (obfuscation only) | Cerberus lineage, SpyNote | Rely on string encryption, class renaming, and custom obfuscation instead of commercial packers |
Universal Unpacking Toolkit¶
Tools for approaching any packed sample regardless of the specific packer.
DEX Recovery¶
| Tool | Purpose | Packer Coverage |
|---|---|---|
| frida-dexdump | Scans process memory for DEX magic bytes and dumps all loaded DEX files | All packers that decrypt DEX into memory (Chinese packers, DexGuard, DexProtector, AppSealing, LIAPP, Appdome, zShield) |
| FART | ART-level DEX dumper that modifies ART internals (ArtMethod, ClassLinker, interpreter, and dex2oat) and forces invocation of every method to recover function code at runtime |
Effective against packers that use InMemoryDexClassLoader |
| DexDump (smartdone) | Xposed module for dumping DEX at class loading | Older Chinese packers, some DexGuard builds |
| reFrida | Pre-built Frida scripts including DEX interception and string decryption | Broad coverage with configurable hooks |
| AppPealing | Xposed module that disables AppSealing checks and dumps decrypted DEX | AppSealing only |
RASP Bypass¶
| Tool | Purpose | Notes |
|---|---|---|
| Objection | Runtime mobile exploration. Built-in root, SSL, and debug bypasses | Good starting point, handles common detection patterns |
| Shamiko | Zygisk module that hides Magisk root from detection (distributed via the LSPosed release repository) | Preferred for Promon SHIELD, Arxan, and LIAPP |
| ZygiskFrida | Injects Frida gadget via Zygisk at process spawn | Avoids ptrace-based detection. Critical for Arxan, DexProtector, and LIAPP |
| MagiskHide Props Config | Modifies device fingerprint properties to defeat emulator detection | Useful when running on physical rooted device |
Native Analysis¶
| Tool | Purpose | When to Use |
|---|---|---|
| Ghidra + D-810 | Native decompiler with OLLVM deobfuscation plugin | Arxan guard network, Mandrake native loaders, Promon SHIELD library, zShield post-XXTEA |
| IDA Pro + Keypatch | Native disassembler with inline patching | Virbox VM interpreter, DexProtector native bridge, LIAPP native library |
| Frida Stalker | Instruction-level tracing at runtime | Tracing Virbox VM dispatch loop, mapping guard execution in Arxan |
| XXTEA ELF Unpacker (DavidBuchanan314) | Decrypts XXTEA-encrypted ELF bodies from zShield native libraries | zShield only. Removes outermost protection layer, OLLVM flattening remains |
Recommended Lab Setup¶
Physical device (Pixel 7+, rooted with Magisk + Zygisk)
├─ Shamiko (hide root from target app)
├─ ZygiskFrida (stealth Frida injection)
├─ Objection (runtime exploration)
└─ mitmproxy (network interception)
Alternative: Android emulator (API 33-35, Android 13-15)
├─ frida-server on non-default port (rename binary)
├─ Burp Suite / mitmproxy with custom CA
└─ Note: many commercial packers detect emulators
Physical devices are strongly preferred for DexProtector, Promon SHIELD, Arxan, LIAPP, and Appdome analysis. These products aggressively detect emulators and virtual environments. Chinese packers, AppSealing, and DexGuard are generally workable in emulators with basic evasion.
Unpacking Strategy¶
Universal sequence before reaching for the per-packer page:
- Identify the packer (APKiD plus native library and asset inspection)
- Capture DEX via memory dump (hook
DexClassLoader/InMemoryDexClassLoader), process dump (/proc/self/mapsregions with DEX magic), or framework hook - Reconstruct DEX from the dump
- Decompile with JADX or Ghidra
The Analysis Decision Tree below maps observed artifacts to specific packers. For per-packer unpacking specifics, see the individual packer pages. Frida DEX dumping scripts cover the universal hooking approach.
Custom Packers¶
Some malware authors build their own packing solutions rather than using commercial products. These require per-sample analysis but follow predictable patterns.
| Technique | Examples | Analysis Approach |
|---|---|---|
| XOR-encrypted DEX in assets | Budget banking trojans, SMS stealers | Extract asset, brute-force single-byte XOR key (typically visible in native loader) |
| AES-encrypted second stage | Multi-stage droppers | Hook javax.crypto.Cipher to intercept key and IV, or extract from native loader |
| Steganographic DEX in images | Necro | Reverse the pixel-to-byte extraction algorithm from the loader class |
| Manifest manipulation | SoumniBot | Install on device and dump via adb shell dumpsys package, bypassing parser bugs |
| OLLVM-obfuscated native loader | Mandrake | D-810 for OLLVM deobfuscation, Frida Stalker for runtime tracing |
| Encrypted shared preferences payload | Dropper-style malware | Hook SharedPreferences.getString() to capture decrypted payload before loading |
| Split APK abuse | Play Store droppers | Reassemble all splits into a single APK using bundletool, then analyze normally |
Custom packers are typically easier to break than commercial ones because they lack the sustained engineering investment in anti-tampering and anti-hooking. The main challenge is identifying the specific decryption mechanism, which is usually straightforward once the native loader or Java-based decryptor is located. Outliers exist: Mandrake's OLLVM-flattened native loader is harder to deal with than several mainstream commercial protectors.
Packer Comparison Matrix¶
Head-to-head comparison across all documented packers on the features that matter for analysis.
| Feature | Virbox | DexGuard | DexProtector | Arxan | Promon | Chinese | AppSealing | LIAPP | Appdome | zShield | Verimatrix |
|---|---|---|---|---|---|---|---|---|---|---|---|
| DEX encryption | Yes | Yes (class-level) | Yes | Partial | No | Yes (whole DEX) | Yes | Yes (full) | Yes | Yes (.szip) | Yes |
| DEX virtualization | Yes (core) | Optional | No | No | No | No | No | No | No | No | No |
| String encryption | VM-based | Method calls | White-box keys | Yes | No | Basic XOR | Weak | XOR (native) | Native | 32-bit key | Inlined per-site |
| Native protection | Yes | Yes | Yes | Guard network | No (RASP) | No | SO encryption | SO encryption | SO encryption | XXTEA + OLLVM | C/C++ obfuscation |
| Anti-Frida | Yes | Yes | Yes | Yes | Yes | Basic | Basic (port) | Aggressive | Multi-vector | Syscall-based | Yes |
| Anti-root | Yes | Yes | Yes | Yes | Yes | Basic | Moderate | Magisk-aware | Comprehensive | Yes | Yes |
| Anti-emulator | Yes | Yes | Yes | Yes | Yes | Basic | Yes | Aggressive | Yes | Yes | Yes |
| White-box crypto | No | No | vTEE CryptoModule | Yes | No | No | No | No | No | zKeyBox (separate) | EMVCo certified |
| RASP | Partial | Partial | Core feature | Yes | Primary | No | Basic | Core feature | OneShield | Integrity checks | Full suite |
| Code virtualization | DEX + native | Optional | Hide Access | Guard-level | No | No | No | No | No | No | No |
| Server-side attestation | No | No | No | No | No | No | No | Backend integrity flow | No | No | OTA updates |
| Unpacking difficulty | Expert | Medium-Hard | Medium-Hard | Hard | Medium | Easy-Medium | Low-Medium | Hard | Medium-Hard | Medium-Hard | Medium |
| Public bypass tools | None | Limited | Limited | None | Limited | Generic DEX dump | AppPealing | None | None | XXTEA unpacker | None |
Analysis Decision Tree¶
When encountering a protected sample, use this sequence to minimize wasted effort:
Start
|
├─ Run APKiD (current rules: appsealing, jiagu, bangcle, bangcle_secshell,
│ tencent_legu, ijiami, dexprotector, naga; Zimperium / InsideSecure /
│ Appdome / Virbox have no upstream rules yet)
│ ├─ packer : appsealing → AppSealing (use AppPealing or Frida kill/signal/alarm hooks)
│ ├─ packer : tencent_legu → Tencent Legu
│ ├─ packer : jiagu → 360 Jiagu
│ ├─ packer : bangcle / bangcle_secshell → Bangcle / SecShell
│ ├─ packer : dexprotector → DexProtector
│ ├─ Other packer identified → Go to packer-specific page
│ ├─ Obfuscator only → Proceed with jadx, use deobfuscation scripts
│ └─ Unknown protection → Fall through to native library / asset checks below
|
├─ Check native libraries (for protectors APKiD does not yet detect)
│ ├─ libshella-*.so / libshellx-*.so + assets/0OO00l111l1l → Tencent Legu (Quarkslab)
│ ├─ libjiagu*.so + assets/jiagu_data.bin → Qihoo 360
│ ├─ libsecexe.so / libsecmain.so → Bangcle
│ ├─ libSecShell.so + assets/secData0.jar → SecShell
│ ├─ libcovault-appsec.so (or legacy libsecureapp.so) + assets/AppSealing/ → AppSealing
│ ├─ libalice.so / libdexprotector.*.so → DexProtector (older builds; newer use randomized .dat/.mp3 assets)
│ ├─ libstrategy.so wrapped by Virbox runtime → Virbox-protected Gigabud / GoldDigger variant
│ ├─ lib<random12chars>.so (~3MB, packed ELF) → zShield (DavidBuchanan314 writeup)
│ ├─ com.lockincomp.* references → LIAPP (no APKiD signature yet)
│ ├─ Renamed / encrypted .so files plus DEX byte[]->String wrappers → DexGuard (no fixed filename)
│ ├─ Additional outer DEX + opaque native loader (filename varies) → Possible Appdome (verify against vendor patterns)
│ └─ Unknown .so → Check strings, imports for packer signatures
|
├─ Check obfuscation level
│ ├─ a/b/c class names, no string encryption → R8/ProGuard only
│ ├─ Single-char classes + byte[]->String methods → DexGuard string encryption
│ ├─ X.<short> class names (e.g., X.A1c) + InterDex layout → Meta Redex
│ ├─ All strings readable, class names intact → No obfuscation
│ └─ Native JNI stubs replacing Java methods → Virtualization (Virbox or DexGuard advanced)
|
├─ Check assets
│ ├─ assets/AppSealing/ directory → AppSealing
│ ├─ *.szip files (~8MB) + truncated .odex → zShield
│ ├─ Virbox runtime blobs in assets → Virbox
│ └─ Encrypted blobs → Generic packer or custom encryption
|
└─ Choose approach
├─ Obfuscation only → Static analysis with jadx deobfuscation
├─ DEX encryption → frida-dexdump or DexClassLoader hook
├─ Virtualization → Dynamic analysis only (hook VM interpreter)
├─ RASP only → Frida with detection bypass hooks
├─ Server-side attestation (LIAPP) → Token replay from clean device
└─ White-box crypto (Verimatrix CryptoModule, zKeyBox) → Code lifting, not key extraction
Packer Trends in Malware¶
Last reviewed: 2026-05
| Trend | Details |
|---|---|
| Commercial packer adoption | Malware authors increasingly use commercial packers (Virbox, DexGuard) rather than custom solutions. Reduces development cost at the expense of identifiable signatures. |
| Multi-layer / double packing | Modern samples combine two commercial packers or a commercial packer with custom obfuscation. See Double Packing. |
| Packer-as-a-Service | Underground forums offer packing services where customers submit APKs and receive protected versions. No need to license the packer directly. |
| Custom packers declining | Only sophisticated groups like Mandrake developers invest in custom OLLVM-based protection. Most operators use off-the-shelf solutions. |
| RASP integration | Banking trojans increasingly encounter RASP-protected target apps (Promon, Arxan, LIAPP, Appdome), requiring malware to bypass runtime checks to perform overlay injection or accessibility manipulation. |
| Guardsquare consolidation | Guardsquare's acquisition of Verimatrix XTD (closed Feb 2026) means one vendor now controls DexGuard, R8/ProGuard, and Verimatrix XTD. Expect product consolidation and white-box crypto integration into DexGuard. |
| Korean market protectors | LIAPP and AppSealing dominate the Korean banking and gaming markets. LIAPP's server-side token verification introduces a new dimension that purely client-side protectors lack. |
| No-code SaaS protection | Appdome and AppSealing offer cloud-based protection without build pipeline changes. Appeals to organizations without mobile security engineering teams. |
| Manifest-level evasion | SoumniBot demonstrated that packing the code is not the only option. Malforming the APK structure itself can defeat analysis tools without any packer. |
Double Packing¶
Using two distinct packers on the same APK, layering their protections so that an analyst must defeat both to reach the original code. The outer packer's Application class loads first, decrypts and initializes its runtime, then hands off to the inner packer's Application class, which performs its own decryption before finally loading the real app code.
A typical combination pairs a Chinese packer (Virbox, 360 Jiagu) as the outer layer with a second packer or custom protection as the inner layer. The outer packer encrypts the inner packer's stub along with the real payload, so static analysis sees only the outermost stub classes.
How It Works¶
APK
└─ Outer packer Application (e.g., Virbox l637078ca)
├─ Decrypts native library from assets
├─ Loads real Application class from SAPP_NAME metadata
└─ Inner packer Application (e.g., 360 Jiagu GZckWAeyProtected)
├─ Initializes its own protection runtime
└─ Loads the actual app code
The outer packer handles DEX encryption and native library protection. The inner packer adds its own anti-analysis layer (anti-debugging, integrity checks, additional code hiding). Each packer's anti-tampering mechanisms independently verify their own integrity, so bypassing one does not disable the other.
Analysis Impact¶
| Challenge | Why It's Harder |
|---|---|
| Two unpacking stages | Must dump DEX after each packer initializes, not just once |
| Nested native libraries | Two sets of .so files to reverse, each with different protection |
| Combined anti-analysis | Root/emulator/hooking checks from both packers fire independently |
| Ordering dependency | Inner packer only initializes after outer packer completes, so timing hooks is critical |
Unpacking Approach¶
- Identify both packers via APKiD and native library inspection (e.g., Virbox assets +
libjiagu.sopresence) - Dump DEX after the outer packer loads using
frida-dexdumporDexClassLoaderhooks - The dumped DEX will still be protected by the inner packer
- Re-analyze the dumped output, then dump again after the inner packer initializes
- The second dump contains the real app code
Alternatively, wait for both packers to fully initialize before dumping. A late-stage memory dump (after Application.onCreate() completes) often captures the fully unpacked DEX, skipping the intermediate stage.
Detection Evasion Effectiveness¶
How much each protection layer reduces detection rates across multi-engine static scanning, as an ordinal ranking:
| Protection | Evasion against static AV scanning | Why |
|---|---|---|
| No protection | Baseline | All engines can scan the raw DEX |
| RASP only (no packing) | Negligible | Code is still scannable; RASP operates at runtime |
| R8 / ProGuard only | Low | Engines pattern-match on behavior, not names |
| Chinese packer (basic, e.g. Bangcle, 360 Jiagu) | Moderate | Engines scan the stub, not the encrypted payload |
| AppSealing | Moderate | DEX encrypted but historically weaker string protection |
| DexGuard | High | String encryption hides IoCs; class-level encryption hides behavior patterns |
| LIAPP | High | DEX encryption, native string encryption, and server-side attestation |
| Appdome | High | DEX encryption, native library encryption, multi-vector RASP (OneShield) |
| Verimatrix XTD | High | Code encryption, multi-language obfuscation, inlined string decryption |
| Custom packer + obfuscation | High to Very High | Varies by implementation quality (e.g., Mandrake OLLVM) |
| zShield | Very High | XXTEA ELF encryption, .szip DEX, randomized library names |
| Virbox (virtualized) | Very High | Proprietary VM instructions are opaque to static scanners |
These bands are qualitative analyst impressions, not the output of a published study. They reflect typical observed behavior on multi-engine static scanning of packed vs unpacked samples within the same family but no fixed methodology, sample corpus, or date is anchored. Per-family detection deltas vary widely. The actionable takeaways: DEX virtualization (Virbox) provides the highest static analysis resistance, while basic Chinese packers offer adequate protection against automated scanning but fall quickly to manual Frida-based analysis.