It is known that Java class files are easy to reverse-engineer. The same properties that enable Java applications to be run anywhere make reverse translation straightforward. There are a number of Java decompilers on the market that produce amazingly readable source code. As a result, distribution of the application classes makes code theft and tampering easy, which in turn may cause stealing of user data and provoke user identity theft. Reverse translation has been a common headache for the Java application vendors who, for any reason, do not plan to open their source code.
On the contrary, the optimized native code produced by the JET Optimizer is as hard to reverse engineer as the code generated by highly optimizing C++ compilers. The understanding of your code will become a much more sophisticated and time-consuming task, so stealing your algorithms and know-how as well as tampering with your code will be much more difficult and expensive.
Note, however, that you may still need to employ a third party solution, such as a license manager or USB dongles, to prevent illegal use of your application.
Excelsior JET compiles your class files down to optimized native code and creates a monolithic binary executable. As a result, you no longer need to ship the application classes to your end users.
As compared to bytecode obfuscators, Excelsior JET provides a higher level of IP protection, because the reverse translation of optimized native code is a very hard task and it cannot be automated like Java bytecode decompilation. Here are the reasons why:
Although an optimized method is functionally equivalent to the original one, the resulting native code is quite distant from the initial source code which therefore cannot be easily restored.
When compiling a Java application, the JET Optimizer processes each jar file and directory listed in the classpath and, depending on the project settings, either compiles class files to native code or leaves them in the bytecode form. /The classes will be handled by the JIT compiler if the application tries to load them at run time./
For each classpath entry, the Optimizer supports the following protection modes:
If code protection for certain classpath entries is not important, you may set the "not required" mode for them. For example, there is no need to protect classes from open source libraries, such as Apache Commons.
You may select the desired code protection mode for any classpath entry as follows:
Open your project with the JET Control Panel and go to the Classpath page. Each row of the classpath grid corresponds to a single classpath entry — directory or jar file. The column named Protect contains the protection mode for each entry. Click the cell, and select the appropriate value from the drop-down list.
If you edit project files manually, use the PROTECT equation to control code protection. Refer to the JC reference chapter for more details.
Not available in the Standard Edition:
One difference between the executables created by the JET Optimizer and C/C++ compilers is that the former must contain Java reflection information for all classes. Although inspecting the names of classes, method, and fields does not help a malicious programmer to find the code of the respective methods, such exposure may be undesirable.
Moreover, while the JET Optimizer transforms Java bytecode to native code, constant data, such as Java string literals, appear verbatim in the resulting executable. This may be a potential weak point for IP protection.
Finally, the jar files may contain not only classes but also application data, for example, images, media files, various text and property files, XML configuration files, etc.
To protect the reflection information, strings, and program data, you may enable data encryption when compiling your application. As a result, the optimized executable will not include the resource files and strings in the original form. Decryption is performed on demand at application run time.
Unlike name obfuscation, the technique does not compromise the correctness of execution if the application heavily uses Java Reflection API and/or JNI. This is a unique feature that cannot be found in Java bytecode obfuscators because Excelsior JET provides data protection at the JVM level.
You enable data protection on the page Target of the JET Control Panel: check the Encrypt strings and resources box in the Executable settings pane. This setting affects all compiled classes and classpath entries.
If you edit project files manually, use the CRYPTSEED equation to enable data protection. Refer to the JC reference chapter for more details.
Note: resource files are protected only if they are placed in a jar file and the jar file is packed into the executable in the auto-detect mode (default for jar files). For more details, consult section Resource packing. If the resource files you need to protect are located in a directory listed in the classpath, you have to place the files in a jar file and add it to the classpath before compilation.
Enabling data protection increases neither compilation time nor the size of the resulting executable. It may slightly degrade application performance and start up time, though in our tests the impact was minimal.