Protector4J 6 · VM-integrated protection

Protection that lives insidethe Java virtual machine.

Protector4J 6 protects Java bytecode through a VM-owned chain: authenticated .p4jx archives, staged class loading, encrypted bytecode in Metaspace, on-demand interpreter decoding, and a guarded JIT path.

.p4jx
Authenticated archive
HotSpot
VM-owned loading path
7 layers
Defense in depth
Protected class lifecycle
01 / INPUT
JAR / WAR / Library
Application code and resources
02 / SEAL
P4JX archive
AES-256-GCM and per-app keys
04 / EXECUTE
Interpreter / JIT
Controlled, on-demand decode paths
03 / LOAD
VLX HotSpot
Staged parsing and protected linkage
Metaspace bytecode state
ENCRYPTED
VM-owned protection chain

Protection across the full bytecode lifecycle

P4JX keeps archive access, class parsing, protected linking, interpretation, JIT compilation, and runtime integrity inside a customized HotSpot security boundary.

Explore the protection architecture
Current P4JX architecture
The P4JX architecture

The protected archive and runtime form one security boundary

Protection remains active from authenticated archive access through parsing, linking, interpretation, JIT compilation, and runtime integrity checks.

01
Closed archive access inside the VM
02
Per-method staging and immediate remasking
03
Interpreter and JIT decode chains
Traditional approach
Traditional class encryption

Decrypt first, then hand plaintext to the JVM

A custom ClassLoader can hide files on disk, but the ordinary class definition boundary and runtime inspection mechanisms remain available.

The loader becomes a concentrated interception point.
Plain class structures re-enter the standard JVM pipeline.
Defense in depth

Seven layers. One continuous trust chain.

Seven layers of defense continuously protect core code, significantly raising the cost of decompilation, debugging, and reverse engineering.

P4JX / VM SECURITY BOUNDARY
L1—L7 / ACTIVE
  1. L1
    01 / 07

    Authenticated archive

    .p4jx archives carry protected application content and establish a consistent delivery boundary.

  2. L2
    02 / 07

    Staged class loading

    VLX HotSpot owns protected class loading, carrying the protection state into the runtime environment.

  3. L3
    03 / 07

    Protected linkage

    Verification and linking remain inside the VM security boundary, with critical transitions covered by the same protection chain.

  4. L4
    04 / 07

    Protected interpretation

    Interpretation remains inside the VM protection boundary and continues under a unified runtime policy.

  5. L5
    05 / 07

    Compiled execution protection

    Compiled execution stays coordinated with the wider runtime protection model, keeping performance and protection states aligned.

  6. L6
    06 / 07

    Runtime integrity

    The runtime continuously checks critical environment and code state to preserve the integrity of the protected environment.

  7. L7
    07 / 07

    Anti-injection boundary

    Agent, profiler, and debugger export paths are restricted, narrowing how external tools can reach protected data.

01PROTECTED DELIVERY
02VM SECURITY BOUNDARY
03RUNTIME POLICY / ACTIVE
From input to protected runtime
ENCRYPTED
P4JX / START

Protect your application with P4JX

Follow the guided setup, complete the compatibility check, and generate a protected package matched to your target platform.

Protected class lifecycle
04 / 04
01JAR / WAR / Library
02P4JX archive
03VLX HotSpot
04Interpreter / JIT
Metaspace bytecode stateENCRYPTED
CONTACT

Contact Us

You can leave message here, or directly send mail to [email protected], we will get back to you ASAP

[email protected]