Design and Evaluation of Java Backend Code Protection Solutions

Background

In B2B Java applications deployed on client machines, protecting intellectual property requires encrypting or obfuscating core code (e.g., License, Billing, Pay) and preventing third‑party dependency inspection.

Industry Solutions

Four typical tools are reviewed:

ProGuard : free open‑source obfuscator with negligible performance impact, but it only obfuscates part of the code, is time‑consuming during packaging, interferes with Arthas, has complex configuration, and cannot encrypt all third‑party dependencies.

jar‑protect : a Spring Boot jar encryption tool that works with a javaagent and rewrites classes via Javassist, hiding method bodies; however it uses DES (heavy for many jars), stores encrypted classes in META-INF/.encode/ leading to class conflicts, and cannot encrypt all third‑party information.

GraalVM : compiles Java applications to native binaries, offering 100× faster startup, lower memory/CPU usage, and resistance to decompilation, but it does not support our business framework.

core‑lib/xjar : a Golang‑based encryption tool with a Maven plugin; it can encrypt all class files, but doubles jar size, requires a Golang runtime, and has not been updated for three years.

Our Requirements

Encrypt our own project classes so that tools like jadx cannot easily decompile them.

Encrypt third‑party dependency jars to hide their details.

Proposed Solution

During Maven packaging, repackage a fat jar and encrypt the lib directory inside, making it unreadable to jadx.

For core business classes, use Javassist to rewrite class files, clearing method bodies and resetting field values.

At runtime, a custom javaagent decrypts the encrypted jars into a temporary directory and adds them to the Spring Boot classloader.

The agent also intercepts class loading, decrypts encrypted classes on‑the‑fly, and returns the original bytecode.

Notes

Javassist rewriting requires all dependent libraries added to the class pool.

Encrypted classes should be placed in a separate directory to avoid class conflicts.

The agent must be lightweight to keep performance impact below 5%.

Re‑packaged jars may change class order, potentially causing conflicts (e.g., log4j); thorough testing is required.

Conclusion

The implemented Maven encryption and agent decryption plugin provides a lightweight solution that fully encrypts third‑party packages and business classes, preventing reverse engineering while keeping performance overhead under five percent.

References

ProGuard: https://github.com/Guardsquare/proguard

jar‑protect: https://gitee.com/chejiangyi/jar-protect

GraalVM: https://javakk.com/tag/graalvm

core‑lib/xjar: https://github.com/core-lib/xjar