How to protect Java code __3

In Java code often contains some very sensitive information, some related to the interests of developers, some may be because of the use of the environment is related to the interests of software users, so the Java program is shirtless or armed with the real problem in front of the Java developers, so in this case, From both the developer and the user perspective, it is very necessary to protect the Java program. Here are some common protection measures and common tools from a technical perspective to see how to effectively protect Java code:

1. package Java as exe
Features: Packaging jars into executables for ease of use, but without any protection from Java programs.

Do not assume that the generated EXE is the same as the normal executable file. These packaged EXE-like programs will release the jar file to the Temp directory for easy access.

Commonly used tools are exe4j, Jsmooth, Nativej and so on. Jsmooth generated EXE runtime temp directory in the EXE directory or user temporary directory; exe4j generated EXE runtime temp directory in user temporary directory; Nativej generated EXE is opened directly with WinRAR and then repaired in zip format into a jar file. We get the original document. Using these tools is a good choice if you don't need to protect your Java code just for ease of use and release.

2. Java Obfuscation device
Features: Using one or more processing methods to confuse the class file, Java source code to generate a new class, so that confusing code is not easy to decompile, and the decompile code is difficult to read and understand.

This type of obfuscation tool is numerous and effective.

Disadvantage: Although confusing code is not easy to read after compiling, but for experienced people or spend more time, still can find or calculate the sensitive content hidden in your code, and in many applications not all of the code can be confused, often some key library, class name, method name, Variable names, and so on, are not confused by the limitations of the use requirements.

3. Isolating Java programs to the service side
Features: the Java program to the server, so that users can not access to the class file and related files, the client access only through the interface.

This method can protect the Java code better in the application of Customer/service mode.

The disadvantage is that it must be a customer/service pattern, which limits the scope of use of this method; The client is always a weak link because of the logic exposure, so the security authentication is generally required to access the interface.

4. Java Encryption Protection
Features: Custom ClassLoader, the class file and related files encryption, the runtime from this ClassLoader decrypt the relevant files and load classes, to play a protective role must be set The semantic local code executor also protects the related classes and supporting files for custom ClassLoader and encryption decryption.

This approach can be very effective in protecting Java code.

Disadvantage: Java bytecode can be intercepted by replacing Java classes or virtual machine dynamic libraries that are related to class loading in the JRE package.
Jar2exe belong to this kind of tool.

5. Pre-compiling technology (AOT)
Features: The Java code is statically compiled at cost machine code, out of the generic JRE.

This is a way to protect Java code very effectively, and the program starts a little faster than a general-purpose JVM.

The representative is the GNU GCJ, which is capable of fully compiling the Java code in advance, but GCJ has many limitations, such as not having full support for JRE 5, and not supporting JRE 6 and later versions.
Because of the complexity of the Java platform, it is very difficult to be able to support the latest Java version in a timely manner and fully advance compilation of the JRE, so such tools tend to be flexible, where just-in-time compilation is used, and is a hybrid of early compilation and Just-in-time compilation.

Disadvantages: Due to differences with the generic JRE and complexity in Java application, not all jars in the Java program are fully protected; You can only use a running environment provided by this tool, and you may not be able to get support for tools that are delayed or you need a specific version of the JRE.
Excelsior jet belongs to this type of tool.

6. Use the Jni method to protect
Features: The sensitive methods and data are processed by JNI way.

This approach is similar to "isolating Java programs to the server" and can be seen as "isolating" the code and data that need to be protected into a dynamic library, which can be used in stand-alone programs.
The disadvantages are similar to the above "isolating Java programs to the server".

7. Protection from an integrated approach to the JRE
Features: Not in advance, not from the JRE, the use of a variety of soft protection, in many ways to prevent Java programs from being stolen.

This approach protects the Java code very effectively by taking a variety of protection measures, such as custom actuators and loaders, encryption, JNI, security detection, generating executables, and so on.
Disadvantage: Because of changes in the way the jar file exists and the complexity in Java usage, not all jars in the Java program are fully protected; it is likely that all JRE versions will not be supported.
Jxmaker belong to this type of tool.

8. Use encryption lock hardware protection
Features: Using a dedicated hardware-related program to boot the Java virtual machine into the shell, the virtual machine supporting files and Java programs are encrypted, starting with the shell program, the shell program to create a hardware-related protected operating environment, in order to enhance security and encryption lock embedded in the program interaction.

This approach is similar to the above "comprehensive approach to JRE protection", with only dedicated hardware devices and good protection of Java code.
Disadvantage: Some people think that the encryption lock user is not easy to use, and each installation needs to be accompanied by one.

As we can see from the above description:

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

2. To better protect Java code should use comprehensive protection measures

3. In a stand-alone environment to truly effectively protect the Java code, you must have local code program with

Of course, security is relative, on the one hand, look at your protection and the use of the tools can be achieved, on the one hand, the willingness and ability of hackers, not only technical protection of intellectual property rights. All in all, there are a number of possible ways to protect Java code, not to be stuck in those rules.