How to Protect Java code

Java code usually contains some very sensitive information, which is related to developers' interests. Some may be related to the interests of software users due to different environments. Therefore, the real problem of whether Java programs are running normally or fully armed is put in front of Java developers. In this case, from the developer and user perspectives, it is very necessary to protect Java programs. The following are common protection measures from the technical point of view:
And common tools to see how to effectively protect Java code:

1.
Package Java into exe
Features: it is easy to package jar files into executable files, but it has no protection for Java programs.

Do not assume that the generated EXE file has the same effect as the normal executable file. When these packaged as EXE programs run, the jar files will be released to the temporary directory, which is easy to obtain.

Common tools include exe4j, jsmooth, and nativej. The temporary directory generated by jsmooth during EXE running is in the directory where the EXE is located or in the temporary directory of the user; the temporary directory generated by exe4j during EXE running is in the temporary directory of the user; the EXE generated by nativej is opened directly with WinRAR, and then fixed into a jar file in ZIP format.
To obtain the original file. If Java code is not protected for ease of use and release, these tools are a good choice.

2.
Java obfuscators
Features: obfuscation of class files and Java source code in one or more ways leads to new classes, making the obfuscated code hard to be decompiled, the decompiled code is hard to read and understand.

There are many obfuscators and they are very effective.

Disadvantages: although obfuscation code is hard to understand after decompilation, you can still find or compute sensitive content hidden in your code for experienced users or who spend more time, in addition, not all codes can be confused in many applications. Some key library, class name, method name, variable name, and other restrictions are not obfuscated due to usage requirements.

3.
Isolate Java programs from the server
Features: place the Java program on the server, so that users cannot access the class file and related supporting files. The client only accesses the program through interfaces.

This method can effectively protect Java code in customer/service mode applications.

Disadvantage: the customer/service model is required. This feature limits the scope of use of this method. The client is always weak because of logical exposure, therefore, security authentication is generally required for access interfaces.

4.
Java encryption protection
Features: You can customize classloader to encrypt class files and related files. during runtime, classloader decrypts and loads related files, to protect the data, you must customize the local code executor to protect the classes and supporting files related to the custom classloader and encryption and decryption.

This method can effectively protect Java code.

Disadvantage: You can intercept Java bytecode by replacing the Java class or Virtual Machine Dynamic library related to class loading in the JRE package.
Jar2exe is a type of tool.

5.
AOT)
Features: static compilation of Java code cost-effective local machine code, out of the general JRE.

This method can effectively protect Java code, and program startup is faster than general JVM.

The Representative is the GNU gcj, which can fully compile Java code in advance. However, gcj has many limitations, such: JRE 5 cannot be fully supported, and JRE 6 and later versions are not supported.
Due to the complexity of the Java platform, it is very difficult to support the latest Java version and JRE compilation in advance in a timely manner. Therefore, such tools often adopt flexible methods and should be used for instant compilation, it is a mixture of advance compilation and instant compilation.

Disadvantages: Due to the difference from General JRE and the complexity of Java application, not all jar files in Java programs can be fully protected. Only one runtime environment provided by this tool can be used, if the tool update lags behind or you need a specific version of JRE, it may not be supported by this tool.
Excelsior jet is a type of tool.

6.
Use JNI Protection
Feature: Processes sensitive methods and data in JNI mode.

This method is similar to "isolating Java programs from the server". It can be seen that the code and data to be protected are "isolated" into the dynamic library. The difference is that they can be used in standalone programs.
The disadvantage is similar to the preceding "isolate Java programs to the server.

7.
Comprehensive JRE Protection
Features: Java programs are not compiled in advance and not separated from JRE. Multiple soft protection methods are used to prevent Java programs from being stolen.

This method greatly enhances protection by taking a variety of protection measures, such as custom actuators and loaders, encryption, JNI, security detection, and generation of executable files, it can also effectively protect Java code.
Disadvantages: due to the change in the way jar files exist and the complexity of Java application, not all jar files in Java programs can be fully protected; it is likely that not all JRE versions are supported.
Jxmaker belongs to this type of tool.

8.
Hardware protection with encryption locks
Features: hardware-related special programs are used to shell the Startup Program of the Java Virtual Machine, encrypt the file and Java program of the virtual machine, and start the shelling program, A hardware-related protected operating environment is established by the shelling program. To enhance security, it can interact with the program implanted in the encryption lock.

This method is similar to the above "comprehensive protection without leaving the JRE" method. It only uses dedicated hardware devices and can well protect Java code.
Disadvantage: Some people think that encryption lock users are not convenient to use, and each installation requires.

From the above descriptions, we can see that:

1.
Various protection methods have their advantages and disadvantages and should be selected based on the actual situation

2.
Comprehensive protection measures should be used to better protect Java code

3.
To effectively protect Java code in a standalone environment, local code programs must be used together.

Of course, security is relative. On the one hand, it depends on the extent to which your protection measures and tools can be achieved. On the other hand, it depends on the willingness and capabilities of hackers, and cannot only protect intellectual property rights technically. In short, in Java
In terms of code protection, various possible methods can be taken, so do not stick to those rules.