How does Protector4J work?

Current issues with Java code protection solutions

Before we dive into how Protector4J works, let's first understand the issues with other Java code protection methods.

Code Obfuscation

Due to the high semantic nature of JVM bytecode, it is very easy to analyze and read it. Analyzing its running logic can be easily done through dynamic debugging. Writing dynamic debugging tools is not a very complicated task, so obfuscation is not a reliable protection solution.

For more information, please refer to the article: https://protector4j.com/articles/the-issues-of-code-obfuscation/

Class file encryption

Due to the existence of the JVM attachment mechanism, all so-called encrypted code that is not running outside the regular JVM can be easily read using additional tools. Therefore, this is the most ineffective protection scheme.

Specific references can be found in the article: The issues of class encryption in Java

VMP Protection

Virtualization protection is the most secure form of code protection, but due to its significant impact on performance, it cannot be applied to all code in the program. It can only protect critical code, while other code still has the risk of exposure. By using other parts of the code as entry points, it is possible to access the functional information of the virtualized code.

For more details, please refer to the article: https://protector4j.com/articles/the-issues-of-vm-protection/

AOT Compilation

The difficulty of configuring AOT compilation is high, the difficulty of compilation is high, and the probability of compilation failure is high. Even if the compilation is successful, the code logic is only transformed from bytecode representation to machine code representation. Its own operational logic still exists and has not been specially protected. If one can understand the compilation and operating mechanism of AOT, it is still possible to reverse engineer readable code.

Specific references can be found in the article:https://protector4j.com/articles/the-issues-of-vm-protection/

How does Protector4J work?

We have defined a private compressed package format: JARX

To protect Java code, we created a private compressed document format called JARX and integrated it into the JVM runtime system. This format also uses the Deflate algorithm to compress the content and encrypts it using AES. The JAR files processed by Protector4J are converted to the JARX format.

We have made deep customization and modification to the JVM

Through in-depth research on JVM, we have customized and modified JVM to remove all additional mechanisms. We have also strengthened and optimized at the binary security level, making it impossible for crackers to export your class information using existing methods. We believe that with the current level of strength, Protector4J encrypted applications already have a high level of security. However, cracking and anti-cracking will always be a continuous process of competition and improvement. We will continuously improve our encryption and protection solutions to enhance the security of applications.