Android APK Protection Benchmark Report: XopProtector vs. 360, Tencent Legu, and Bangcle — Which Solution Deserves Your Attention?
Test Topic: Android Application Protection, Reverse Engineering Resistance, Runtime Performance, and Device Compatibility
Products Evaluated: XopProtector, 360 Jiagu, Tencent Legu, and Bangcle Security
Test Categories: Static Analysis, Dynamic Attack Resistance, Performance, Compatibility, and Engineering Integration
Key Evaluation Criteria: Protection Strength, Runtime Stability, Cost, and Technical Transparency
Project: https://github.com/xopJack/XopProtector
1. Background: How Should Android Application Protection Platforms Be Evaluated?
As Android reverse engineering tools continue to evolve, traditional code obfuscation is no longer sufficient to protect critical application logic.
Tools such as JADX, JEB, IDA, and Ghidra have become increasingly sophisticated. Dynamic analysis frameworks such as Frida and Xposed also allow attackers to inspect applications during execution.
With the emergence of AI-powered reverse engineering tools, analyzing application code is becoming increasingly automated.
For Android developers, application protection is more important than ever.
Some of the most recognized Android protection platforms include:
- 360 Jiagu
- Tencent Legu
- Bangcle Security
- XopProtector
The first three are established commercial security solutions, while XopProtector is an open-source Android application protection project licensed under Apache License 2.0.
This report explores an important question:
Can a free, open-source Android protection solution compete technically with established commercial protection platforms?
Rather than comparing brand recognition or marketing claims, we establish a unified testing framework covering protection capabilities, performance, compatibility, and development costs.
2. Products Under Evaluation
2.1 XopProtector
Project repository:
https://github.com/xopJack/XopProtector
XopProtector is a multi-layer Android APK protection framework built around a build-time Packer and a Native Shell runtime architecture.
Its core technologies include:
- PDX1 DEX encryption.
- Native Shell runtime restoration.
- PVM1 method virtualization.
- PVM2 True VMP with native interpretation.
- SO native code protection.
- RASP runtime application self-protection.
- Frida / Hook detection.
- SO integrity protection.
- Windows GUI desktop application.
- JVM CLI automation.
The project is licensed under Apache License 2.0, allowing source-code auditing, modification, and further development under the license terms.
2.2 360 Jiagu
Official product page:
https://360.net/product-center/360-mobile-security/android
360 Jiagu provides Android application protection capabilities, including DEX encryption, DEX VMP, SO protection, anti-tampering, anti-debugging, anti-Hook, and Frida detection.
Its product offerings include different protection tiers. Specific capabilities should be verified against the actual version and subscription plan being tested.
2.3 Tencent Legu
Official product portal:
https://cloud.tencent.com/product/ms
Tencent Legu provides mobile application security services designed to protect Android applications against reverse engineering, debugging, piracy, and unauthorized repackaging.
Available protection features and service conditions depend on the current product version and plan.
2.4 Bangcle Security
Official developer portal:
Bangcle Security provides standard and customized mobile application protection solutions.
Its security capabilities cover anti-reverse-engineering, anti-tampering, anti-debugging, and code protection.
Its official developer documentation also describes protection technologies based on virtual machine instruction sets.
3. Laboratory Testing Environment
To ensure a meaningful comparison, all four products should be tested using identical APK samples, devices, and testing procedures.
3.1 Test Applications
We recommend three APK samples.
| Sample | Application Type | Primary Testing Objective |
|---|---|---|
| APK-A | Standard Android application | DEX protection and basic compatibility |
| APK-B | Application containing critical business algorithms | VMP and method protection |
| APK-C | Application containing multiple native SO libraries | SO protection and dynamic loading |
All samples should be developed by the testing team, with complete source code and appropriate testing authorization.
The following conditions should remain consistent:
- Android Gradle Plugin version.
- JDK version.
- minSdkVersion.
- targetSdkVersion.
- APK signing configuration.
- Business logic and resource files.
Every protection platform should receive the same original APK.
3.2 Device Testing Matrix
The following Android versions are recommended:
| Environment | Android Version | Testing Objective |
|---|---|---|
| Android 5 | API 21 | Legacy compatibility |
| Android 7 | API 24 | ART runtime compatibility |
| Android 9 | API 28 | Intermediate-version compatibility |
| Android 10 | API 29 | Storage behavior changes |
| Android 12 | API 31 | Modern Android compatibility |
| Android 13 | API 33 | Permission and system changes |
| Android 14 | API 34 | Updated ART environment |
| Android 15 | API 35 | Newer Android compatibility |
| Android 16 | API 36 | Latest system compatibility |
| Android 17 | Corresponding stable API | Future-version compatibility |
Note: Android 17 testing should use an officially available SDK and actual supported devices. Emulator results should not automatically be treated as equivalent to physical-device results.
The testing matrix should also cover:
- ARM64.
- ARM32, where supported.
- Different manufacturers' customized Android ROMs.
- Emulators and physical devices.
3.3 Testing Tools
| Tool | Purpose |
|---|---|
| JADX | DEX decompilation |
| JEB | DEX structural analysis |
| apktool | APK structure inspection |
| IDA Pro | Native code analysis |
| Ghidra | SO reverse engineering |
| Frida | Dynamic Hook testing |
| ADB | Installation, launching, and log collection |
| Android Profiler | CPU, memory, and performance analysis |
| Perfetto | Startup and system performance analysis |
| readelf | ELF structure inspection |
| dumpsys | Application runtime inspection |
4. Core Testing Categories and Methodology
The laboratory evaluation is divided into eight categories covering 20 core test cases.
Category 1: DEX Static Protection
Objective: Determine whether original business code can be easily recovered after protection.
| ID | Test | Method | Evaluation Criteria |
|---|---|---|---|
| T01 | APK static analysis | Extract APK using apktool | Exposure of internal file structure |
| T02 | DEX inspection | Examine classes*.dex | Exposure of original DEX files |
| T03 | JADX decompilation | Import protected APK into JADX | Readability of business code |
| T04 | String analysis | Search for business-related strings | Exposure of sensitive strings |
Key questions:
- Are original business DEX files directly accessible?
- Can critical business classes be decompiled?
- Can important methods be reconstructed?
- Are sensitive strings exposed?
XopProtector Technical Analysis
XopProtector uses the PDX1 encrypted format to package DEX content and employs a Native Shell for runtime restoration.
Its design aims to reduce the exposure window of plaintext DEX and increase the difficulty of static analysis.
However, DEX encryption does not mean that executable code can never be analyzed at runtime. Memory and runtime testing are still necessary to evaluate the actual protection effectiveness.
Category 2: VMP Protection
Objective: Determine whether the protection platform meaningfully increases the difficulty of reverse engineering critical business methods.
This is one of the most important testing categories.
| ID | Test | Method | Evaluation Criteria |
|---|---|---|---|
| T05 | VMP method identification | Inspect protected methods | Protection coverage |
| T06 | Instruction reconstruction | Analyze with static tools | Instruction recoverability |
| T07 | Native interpretation | Analyze runtime execution paths | Presence of native interpretation |
| T08 | Method execution performance | Execute identical methods repeatedly | Execution overhead |
Three different protection approaches must be distinguished:
- Conventional method encryption.
- Method packaging and runtime restoration.
- Genuine virtual machine instruction transformation and interpretation.
XopProtector's Key Differentiator: Dual VMP Architecture
PVM1:
Uses method packaging and protection mechanisms to increase the difficulty of method recovery and static analysis.
PVM2:
Implements True VMP through instruction Morph, a multi-ISA instruction system, JNI trampolines, and a Native Interpreter.
These two mechanisms should not be confused.
PVM1 is not an interpreter. PVM2 is the component responsible for native virtualized execution.
This means XopProtector goes beyond DEX encryption by providing virtualization-based protection for selected critical methods.
Category 3: Native SO Protection
Objective: Determine whether native code receives effective protection.
| ID | Test | Method | Evaluation Criteria |
|---|---|---|---|
| T09 | SO structure inspection | Examine ELF using readelf | Exposure of ELF structure |
| T10 |
.text protection |
Compare protected and original code sections | Code-section protection |
| T11 | Native analysis | Analyze with IDA / Ghidra | Readability of original code |
| T12 | SO loading | Test dynamic loading and dependencies | Loading success rate |
Key considerations:
- Is the SO library encrypted or otherwise protected?
- Is the
.textsection protected? - Do dynamic relocations affect protection?
- Does runtime decryption and loading work correctly?
- Are different ABIs supported?
XopProtector Technical Characteristics
XopProtector supports .text encryption for business SO libraries.
It provides Safe, Aggressive, and Max protection modes.
It also supports Eager and Lazy SO decryption modes to accommodate different startup performance and compatibility requirements.
For large SO libraries, protection strategies consider dynamic relocations, protection budgets, and file-size constraints to avoid unnecessary compatibility problems.
Category 4: Dynamic Attack Protection
Objective: Determine whether the application can detect and respond to common runtime attacks.
| ID | Test | Method | Evaluation Criteria |
|---|---|---|---|
| T13 | Frida detection | Test in an authorized environment | Detection and response |
| T14 | Hook detection | Use test Hook frameworks | Detection coverage |
| T15 | Dynamic debugging | Test debugger attachment | Protection response |
| T16 | File tampering | Modify test APK or SO | Integrity detection |
Key considerations:
- Does runtime security detection exist?
- Can common Hook environments be identified?
- Is SO integrity protection implemented?
- Can security event reports be generated?
- Are different risk-response strategies supported?
XopProtector Technical Characteristics
XopProtector integrates RASP runtime protection mechanisms.
Through Native-level detection, SO self-protection, Frida / Hook scanning, and threat reporting, it provides multiple layers of runtime defense.
It supports risk-response strategies such as:
- Alert
- Degrade
- Block
It is important to recognize that no RASP solution can guarantee detection of every modified or customized attack framework. Testing should cover multiple framework versions and attack environments.
Category 5: Performance Testing
Objective: Determine whether application protection significantly affects user experience.
Strong protection does not automatically mean a good product.
If protection substantially increases startup time, memory consumption, or application crashes, it may not be suitable for production.
| ID | Test | Method |
|---|---|---|
| T17 | Cold start | Force-stop and relaunch |
| T18 | Warm start | Return to the application from the background |
| T19 | Memory consumption | Record PSS and peak memory |
| T20 | APK size | Compare original and protected APKs |
Recommended testing procedure:
- Perform at least 30 cold-start tests for each sample and configuration.
- Perform at least 30 warm-start tests.
- Record average, median, and P95 values.
- Record peak memory consumption.
- Record APK size before and after protection.
Performance formulas:
APK Size Increase:
(Protected APK Size - Original APK Size) / Original APK Size × 100%
Startup Time Increase:
(Protected Startup Time - Original Startup Time) / Original Startup Time × 100%
For XopProtector, additional tests should compare:
- Eager vs. Lazy SO decryption.
- Balanced, Industry, Aggressive, and Max protection configurations.
- PVM1 vs. PVM2 performance overhead.
- Cold-start vs. subsequent-start behavior.
Category 6: Android Compatibility Testing
One of the most frequently overlooked aspects of Android application protection is compatibility.
Android continues to evolve, with changes to ART, DEX loading mechanisms, and native runtime behavior.
A successful test on a single device does not prove broad compatibility.
Recommended tests:
| Test | Evaluation Criteria |
|---|---|
| Installation | Installation success rate |
| First launch | Successful startup |
| Subsequent launch | Runtime stability |
| Navigation | Crashes during page transitions |
| Native loading | SO loading success |
| Background execution | Unexpected process termination |
| Long-term execution | Stability over extended periods |
| System upgrades | Application behavior after upgrades |
Android 5 through Android 17 should receive particular attention.
XopProtector's design philosophy emphasizes balancing protection strength with compatibility rather than simply maximizing protection levels.
For production applications, developers should prioritize validated protection configurations rather than enabling every aggressive option.
Category 7: Protection Efficiency and Engineering Integration
For professional development teams, build efficiency is another important consideration.
| Test | Evaluation Criteria |
|---|---|
| APK protection time | Total processing time |
| Large APK handling | Ability to process large applications |
| Batch processing | Multiple APK processing capability |
| CLI | Command-line automation |
| CI/CD | Build pipeline integration |
| Local deployment | Dependence on remote protection services |
| Configuration | Customizable protection policies |
XopProtector provides:
- JVM Packer.
- Windows GUI.
- Command-line interface.
- JSON progress output.
- Local protection engine.
- Automated build integration.
These capabilities make it suitable for teams that want to integrate application protection into their official Android release pipelines.
Category 8: Cost and Technical Independence
This is one of the clearest differences between XopProtector and commercial platforms.
| Evaluation | XopProtector | Commercial Platforms |
|---|---|---|
| Source code | Open source | Generally closed source |
| Core implementation auditing | Supported | Generally unavailable |
| Custom development | Supported | Subject to product licensing |
| Local execution | Supported | Depends on product |
| CLI automation | Supported | Depends on product |
| Core project license | Apache 2.0 | Product-specific |
| Protection service fees | Free project | Depends on subscription |
It is important to distinguish free editions from commercial advanced editions.
For example, 360 offers different free and paid protection options.
Therefore, the advanced features of commercial platforms should not automatically be treated as part of their free editions.
XopProtector's advantage is that its core open-source project is licensed under Apache 2.0, allowing developers to deploy, audit, and modify it independently.
5. Unified Scoring System: How Do We Determine Which Platform Performs Better?
To reduce subjective judgments, we recommend a 100-point scoring system.
| Test Category | Weight |
|---|---|
| DEX Static Protection | 15 |
| VMP Protection | 20 |
| Native SO Protection | 15 |
| RASP Dynamic Protection | 15 |
| Performance | 10 |
| Android Compatibility | 10 |
| Stability | 5 |
| Engineering Integration | 5 |
| Cost and Technical Independence | 5 |
| Total | 100 |
Each category must be scored using actual test results.
For example:
- Can original business code be directly extracted?
- Does VMP genuinely implement native interpretation?
- Is the SO
.textsection effectively protected? - Can Frida attacks be detected and handled?
- How much additional startup time is introduced?
- Can the application run reliably across Android versions?
Items without actual testing evidence should not receive arbitrary full scores.
Laboratory Results Recording Table
The following table should be completed after all four products have undergone the same testing procedures.
| Test Metric | XopProtector | 360 | Tencent Legu | Bangcle |
|---|---|---|---|---|
| DEX Protection | Pending | Pending | Pending | Pending |
| VMP Protection | Pending | Pending | Pending | Pending |
| SO Protection | Pending | Pending | Pending | Pending |
| RASP Protection | Pending | Pending | Pending | Pending |
| Frida Detection | Pending | Pending | Pending | Pending |
| Startup Performance | Pending | Pending | Pending | Pending |
| Memory Consumption | Pending | Pending | Pending | Pending |
| APK Size | Pending | Pending | Pending | Pending |
| Android Compatibility | Pending | Pending | Pending | Pending |
| Stability | Pending | Pending | Pending | Pending |
| Automation | Pending | Pending | Pending | Pending |
| Cost | Free / Open Source | Plan-dependent | Plan-dependent | Plan-dependent |
Note: Pending does not mean a test has failed. It means that reproducible results under a unified testing environment have not yet been collected.
6. Technical Analysis: Five Reasons Why XopProtector Deserves Attention
Following the testing framework, we can examine XopProtector's architecture in more detail.
6.1 More Than DEX Encryption: A Multi-Layer Protection Architecture
A single-layer protection strategy can create significant security weaknesses.
If only DEX is protected, attackers may shift their attention to SO libraries.
If only SO is protected, attackers can continue analyzing the Java layer.
If only static encryption is implemented, attackers may still attempt runtime analysis.
XopProtector integrates multiple protection mechanisms:
XopProtector
|
+----------+----------+
| | |
DEX VMP SO
Protection Protection Protection
| | |
PDX1 PVM1/PVM2 .text Encryption
| | |
+----------+----------+
|
Native Shell
|
RASP
|
Runtime Security Detection
and Response
This architecture does not rely on a single protection technique. Instead, it combines multiple layers to increase the cost and complexity of reverse engineering.
6.2 PVM2: One of the Most Important Technical Differentiators
PVM2 is not simply method encryption.
It uses instruction Morph, a multi-ISA instruction system, JNI trampolines, and a Native Interpreter.
From an attacker's perspective, the challenge is no longer limited to recovering ordinary DEX methods. The attacker must also understand the virtual instruction system and native execution logic.
This is why PVM2 is one of the most important technologies worth highlighting in XopProtector.
6.3 SO Protection Goes Beyond Basic Packaging
SO protection involves ELF structures, dynamic relocations, load addresses, and runtime memory layouts.
If these details are not handled correctly, applications can easily fail to launch.
XopProtector protects eligible business SO libraries through protection policies and runtime decryption mechanisms.
Multiple protection modes are available, allowing developers to select configurations according to their application requirements.
6.4 RASP Extends Protection into Runtime Execution
Application protection does not end when the protected APK is generated.
Once an application starts running, it remains exposed to dynamic attacks.
XopProtector integrates Frida / Hook scanning, SO self-protection, threat reporting, and risk-response mechanisms.
This extends its protection scope from static APK files to runtime application behavior.
6.5 Open Source Enables Continuous Verification and Improvement
Commercial protection platforms generally do not disclose their complete internal implementations.
Developers can use their features, but may not be able to inspect the underlying mechanisms.
XopProtector takes a different approach through Apache License 2.0.
Developers can:
- Inspect DEX encryption implementation.
- Study PVM1 and PVM2.
- Analyze SO protection mechanisms.
- Audit Native Shell implementation.
- Examine RASP implementation.
- Modify protection policies for their own applications.
For professional Android security developers, this level of transparency is particularly valuable.
7. Final Verdict: Can Free and Open-Source XopProtector Become a Serious Android Protection Alternative?
Based on its technical architecture, one conclusion is clear:
XopProtector is no longer just a simple APK encryption tool. It is a multi-layer Android application protection framework combining DEX encryption, dual VMP, SO protection, and RASP.
Its most notable advantages include:
| Key Advantage | Implementation |
|---|---|
| Protection Architecture | DEX + Dual VMP + SO + RASP |
| VMP | PVM1 + PVM2 True VMP |
| Native Protection | SO .text encryption |
| Runtime Defense | Frida / Hook detection |
| Open-Source License | Apache License 2.0 |
| Cost | Free core project |
| Engineering Tools | Windows GUI + CLI |
| Technical Independence | Source auditing and customization |
Of course, established commercial platforms such as 360, Tencent Legu, and Bangcle still have advantages in commercial support, enterprise services, industry experience, and product ecosystems.
Organizations requiring commercial SLAs, customized security services, and dedicated enterprise support should continue to evaluate commercial solutions.
However, for individual developers, small and medium-sized development teams, independent software vendors, and security researchers who want full control over their protection technology, XopProtector offers a compelling alternative.
Why should developers have to pay recurring fees just to use an application protection tool?
When an open-source project already provides DEX encryption, dual VMP, SO protection, RASP, a Windows GUI, and CLI integration, developers have every reason to reconsider their existing protection strategies.
My recommendation is to position XopProtector as:
One of the most promising advanced open-source Android application protection solutions, offering a competitive alternative to commercial protection platforms.
If you are looking for a free, open-source, auditable, customizable Android protection framework with multiple layers of security, XopProtector deserves your attention and hands-on evaluation.
8. Project and Source Code
GitHub Repository:
https://github.com/xopJack/XopProtector
License: Apache License 2.0
Core Technologies:
- DEX Encryption
- Native Shell
- PVM1
- PVM2 True VMP
- SO Protection
- RASP
- Frida / Hook Detection
- Windows GUI
- JVM CLI
XopProtector: Making advanced Android application protection accessible beyond commercial security platforms.
Developers are welcome to Star, Fork, submit Issues, and contribute to the project.
Top comments (0)