# A Technical Look at XopProtector: How Deep Does This Open-Source Android Protector Actually Go?

A note on sourcing before diving in: this article is based on what's documented in the xopJack/XopProtector repository's README.md and README.zh-CN.md. I did not have the ability to read the actual .java / .cpp source files line by line, so everything below reflects facts and parameters explicitly stated in the project's documentation — no invented internals. Repo: https://github.com/xopJack/XopProtector, licensed under Apache-2.0.

The one-line version

XopProtector is an open-source Android APK protector made of two parts: a build-time packer (a JVM engine plus an optional Windows desktop UI) and an on-device native shell (libprotector.so). Together they provide DEX encryption, dual-tier VMP, native library (SO) encryption, and RASP-style anti-debug protection.

Encrypted asset layout: this isn't just "zip it and call it a shell"

The protected APK's asset bundle follows a defined format, not a generic encrypted blob:

• code.bin (v4) — the core encrypted payload
• dexes.zip in a custom format called PDX1 — the encrypted DEX package
• config.json — runtime configuration
• Optional sokeys.bin (native library keys), assets.map, and netguard.json

libprotector.so manages several distinct key categories: INSN (instruction-level), DEX, ASSETS, UNKNOWN, and HMAC (integrity verification). Splitting keys by asset type — rather than using one master key for everything — limits the blast radius if a single key is ever compromised.

PVM1 vs PVM2: the docs go out of their way to clear up a naming confusion

This is arguably the most interesting detail in the whole project. The README includes a dedicated "Note on VMP" callout, because the two flags are easy to conflate:

• --vmp-prefix (PVM1): virtualized packing — unpack, then write back to Dalvik bytecode. The docs are explicit: this is not an interpreter.
• --true-vmp-prefix (PVM2): the real deal — a JNI trampoline paired with native-side interpretation, with nothing written back to DEX.

This distinction quietly calls out something common across the commercial app-protection industry: plenty of vendors market simple method-extraction/repacking as "VMP," when true virtual-machine protection means code never lands back in plaintext bytecode and gets interpreted at the native layer instead. XopProtector splits these into two clearly separate names (PVM1/PVM2) instead of lumping both under one marketing umbrella — that kind of naming honesty isn't the norm in this space.

PVM2 is currently at Phase 4, with the following documented capabilities:

• Morph (instruction transformation)
• Multi-ISA support
• Float / double / monitor instruction semantics (v4)
• RASP gating — tied to anti-debug detection, able to refuse interpretation when risk is flagged
• An interpretation cache, to reduce the perf cost of repeated interpretation
• Phase 3 added a parsed-image cache
• The demo exercises invoke / field / array / catch bytecode semantics, plus a full soProbe → protected-SO chain

SO protection: three modes that reflect a real "protection strength vs. APK size" trade-off

--protect-so has been on by default since 0.6.8, RC4-encrypting the .text section of eligible business lib/*.so files. One detail here suggests real production experience rather than theoretical design: the three protection modes are explicitly budget-aware, not just "more encryption = better":

Mode	Behavior
safe (default, since 0.6.12)	Skips industry- and relocation-sensitive SOs, plus a size budget: 12MB extra by default, skipping any file whose unpacked size exceeds 8MB — preventing large engine libraries (game engines, on-device inference libs, etc.) from bloating the APK by tens of megabytes
aggressive	Skips only the shell itself and text-reloc-sensitive SOs; still applies a soft size budget with a WARN
max	Skips only industry-sensitive SOs, no size budget — encrypts every eligible file

There's also a sharper engineering call worth noting: the packer skips any SO whose dynamic relocations patch the .text section — because encrypting .text on such a library would cause the relocator to patch what it thinks is plaintext code, and the app crashes. That's the kind of guardrail you add after hitting a real device crash, not something you'd write from a whiteboard.

Runtime decryption relies on the standard ELF calculation: load_bias = map_start - first_PT_LOAD.p_vaddr, the same technique Android's native loader uses for memory placement.

Cold-start decryption: eager vs. lazy is a startup-time vs. first-call-latency trade-off

--so-decrypt-mode (default: eager):

• eager: at cold start, every encrypted SO is fully materialized and preloaded. Slower startup, but zero latency on subsequent calls.
• lazy: skips full materialization at cold start; only preloads mirrors that are already present in so_plain. Actual decryption is deferred to the first dlopen call (resolved via the DT_NEEDED dependency closure). The remaining keyed SOs are filled in asynchronously in the background, and a so_plain_ready marker is written once done — so the next warm start can skip the cold-start pipeline entirely.

One easy-to-miss detail: early dlopen hooks are installed as part of the SO's constructor — meaning that if code tries to load a library before sokeys.bin has actually loaded, the request is queued rather than failing, and gets decrypted once the keys arrive. That's a non-obvious but important piece of timing logic for stability. The docs also recommend calling System.loadLibrary after Application/shell bootstrap completes, which pairs with this mechanism.

Hollow (code-hollowing) policy: tiered, not blanket

Without an explicit --hollow-prefix, the packer applies a unified automatic policy:

• balanced / perf (default): hollows only the manifest's applicationId package (skipping *Activity and similar component classes), keeping most code AOT-friendly — a sign the project cares about runtime performance, not just maximal extraction.
• aggressive: skips major third-party SDKs/components, hollows remaining business-logic types.
• max: close to legacy full-hollow behavior, but still explicitly skips the Landroid/ and Landroidx/ namespaces — basic engineering sense, since hollowing system classes would almost certainly crash the app.

The docs also state plainly that the policy "never hard-codes a single customer's package name" — a small but pointed line, likely addressing the question of whether this tool was carved out of some client-specific internal project before being open-sourced.

Native-layer obfuscation: CFF/BCF, added in Phase 7

Beyond encryption, the native layer includes control-flow flattening / basic-block obfuscation (CFF/BCF), added in Phase 7. It defaults to a source-level implementation, with an option to switch to an LLVM-based implementation via -Pprotector.llvmObf. Having both paths available suggests a deliberate trade-off between obfuscation quality (LLVM, in theory, stronger) and build-toolchain complexity (LLVM requires more from the build environment).

A library API, not just a CLI

Beyond the command line, the project exposes a Java library entry point that can be embedded directly into a build script or CI pipeline, without shelling out to a subprocess:

ProtectOptions opts = new ProtectOptions();
opts.inputApk = new File("app.apk");
opts.outputApk = new File("out.apk");
opts.shellDir = new File("executable/shell-files");
ProtectResult result = new Protector().protect(opts);

The CLI also supports --json-progress, which streams NDJSON phase/log/done/error events — this is the exact protocol the Windows desktop app uses to drive its progress bar and log panel, which tells you the desktop UI and CLI share one engine rather than maintaining two parallel implementations.

Industry differentiation: payment/finance profiles get automatically escalated

--profile industry targets tool-type and industry applications where security requirements are higher. The default policy leans toward "encryption-first" — full DEX encryption rather than full code-hollowing — and the docs note that payment- and finance-related scenarios can automatically trigger True-VMP (PVM2) without a developer having to hand-specify class prefixes. That implies some heuristic classification of "sensitive code" under the hood; the exact rules live in doc/industry-profile.md and doc/auto-true-vmp-contract.md, neither of which I was able to fetch (if you can paste their contents, I can fold the specifics into a follow-up).

What's honestly missing from this picture

In the interest of accuracy, a few caveats worth stating plainly:

• The README gives you a capability list and parameter reference, not benchmarks — there's no published data on how much cold-start latency the protection adds, and no third-party evaluation of encryption strength.
• PVM2 is described as "true interpretation," but there's no independent penetration-test report validating how well the interpreter actually resists debugging or hooking attempts. The repo's star count (single-to-low-double digits) suggests it hasn't seen large-scale production battle-testing yet.
• App protection is inherently something you can't fully validate by reading docs — someone has to actually try to break it. The project's own disclaimer is upfront about this: protection raises the cost of reverse engineering, it does not guarantee an app can't be cracked.

Bottom line

Compared to a lot of app-protection marketing pages that lean on screenshots and phrases like "military-grade encryption" or "bank-level security," XopProtector's README is unusually information-dense on its own — specific key categories, an exact ELF formula, concrete size-budget numbers, and non-obvious timing/race-condition handling. That level of parameter specificity is usually a signal that whoever wrote the docs actually built the system, rather than paraphrasing a competitor's brochure. That said, documentation-level credibility isn't the same as verified implementation quality — pulling the source or testing it in a staging environment before production use is the sensible next step.

• Repository: https://github.com/xopJack/XopProtector
• License: Apache License 2.0
• Stack: C++ (native shell / PVM2 interpreter) + Java/JVM (packer engine, CLI and library) + .NET WPF (Windows desktop client)