Design and Implementation of a Lightweight Maven Encryption and Agent Decryption Solution for Java Backend Applications

Background – In B2B Java applications deployed on client machines, protecting core code (e.g., License, Billing, Pay) from reverse engineering tools like jadx is essential, as is preventing inspection of third‑party dependencies.

Industry Solutions

ProGuard : a free open‑source obfuscation tool that renames classes and methods, causing compiled bytecode to be hard to read but still de‑compilable; drawbacks include limited scope, heavy build‑time, and incompatibility with some third‑party jars.

jar‑protect : a Spring‑Boot jar encryption tool using javaagent for runtime decryption; it encrypts class files but suffers from heavy DES encryption, class‑path conflicts, and inability to protect all third‑party details.

GraalVM : compiles Java applications to native binaries, offering massive startup speed and resistance to de‑compilation, yet it cannot support the company’s existing framework.

core‑lib/xjar : a Golang‑based encryption tool that encrypts all class files via a Maven plugin; drawbacks include doubled jar size, Golang runtime dependency, and lack of recent updates.

Problem Statement – Existing solutions mainly encrypt class files but fail to protect third‑party dependency details, which is a key requirement.

Proposed Solution

Encrypt third‑party dependency jars during Maven packaging, generating temporary decrypted files at runtime.

Encrypt the project’s own classes using Javassist to rewrite class bodies, leaving only signatures visible.

Maintain a lightweight encryption strategy with less than 5% overhead on startup time, package size, memory usage, and interface performance.

During decryption, the agent identifies encrypted classes, decrypts them, and returns the original bytecode to the classloader.

Design Details

Use Maven to repackage a fat jar, then encrypt the internal lib directory.

For core business code, employ Javassist to rewrite classes, clearing method bodies and resetting fields.

At runtime, decrypt the encrypted jars into a designated directory and add them to the Spring‑Boot classloader classpath.

The agent intercepts class loading, detects encrypted classes, decrypts them on‑the‑fly, and supplies the original byte array.

Key Considerations Javassist must have all library classes in its classpool. Encrypted classes should be placed in a separate directory to avoid class conflicts. The agent must be lightweight to avoid performance degradation. Re‑packaged jars may change class order, potentially causing conflicts (e.g., with Log4j); thorough testing is required. Conclusion – The proposed Maven encryption and agent decryption plugin provides a highly lightweight solution that encrypts both third‑party jars and business classes, preventing tools like jadx from de‑compiling them while keeping performance impact within acceptable limits. Additional Notes – The remainder of the source contains promotional material for a ChatGPT community, interview resources, and various marketing links, which are not part of the technical solution.