JInstaller™: Frequently Asked Questions (FAQ)
- May one use the encryption of JAR files without an installation program?
- Besides Windows, Linux and Mac OS X, what other operating systems are supported?
- How can I create SJAR files per command line?
- Can I use encrypted archives in a java applet?
- Could you provide a more detailed explanation of the principles used by JarCryp?
- How secure is JarCryp? Which encryption technique is used?
- The JVM will soon become open-source. Do you think that the ability to modify the JVM will weaken the protection offered by JarCryp?
1. May one use the encryption of JAR files without an installation program?
Yes. You need the JInstaller™-Secure-Edition to create encrypted SJAR files. Within the JInstaller™-Creator menu choose File->"Create SJAR(s).." . Afterwards select all JAR files which shall be encrypted.
To load classes from the encrypted archives you need to use the class
com.componio.jarcryp.SjarClassLoader which is contained within the
sjarcl.jar archive. You may also want to consult the JarCryp™ documentation at
ext/jarcryp/doc/manual.index.html in your JInstaller installation folder.
In case you want to encrypt a stand alone application which is run through a command line, simply register the class
com.componio.jarcryp.SjarClassLoader as the system class loader. This can be done by defining the command line option
-Djava.system.class.loader. To run your application, simply include the desired SJAR files in your classpath and start your application in the following manner:
java -cp sjarcl.jar;xyz.sjar;... -Djava.system.class.loader=com.componio.jarcryp.SjarClassLoader com.your.Mainclass arguments...
Please also make sure that the native library
sjarcl can be found (see JarCryp documentation).
4. Can I use encrypted archives in a java applet?
Yes, in principal, but you have to make sure that your SJAR files and the libraries
sjarcl.dll/libsjarcl.so are locally available on the client machine. While support for loading SJAR archives through a URL is planned for the future, to this date, all SJAR archives have to be loaded from a local file
Do the following to load encrypted archives from a java applet:
- Copy the files sjarcl.jar and
libsjarcl.so, respectively) to
- Load the encrypted archive(s) in your applet using the following command:
SjarClassLoader cl = SjarClassLoader.getInstance(getClass().getClassLoader(), <my-sjar-files...>);
- Make sure all needed permissions are granted to your applet in
[JRE_HOME]/lib/security/java.policyor make use of signed JARs for your applet.
5. Could you provide a more detailed explanation of the principles used by JarCryp?
JarCryp provides a protection system for Jar files. Its main purpose is to prevent the contents of the archives from being extracted and modified through simple decompilation of the extracted files. The native implementation additionally assures that the decrypted classes cannot be intercepted in an easy fashion.
JarCryp basically consists of a native library implemented in C++ (currently available for Windows and Linux platforms) that is linked into the Java Virtual Machine (VM) via the Java Native Interface (JNI) during runtime. All classes in an encrypted archive are loaded individually and on-demand, decrypted in memory only for a very short period of time before being passed to the VM through the JNI. Likewise, resource files such as images or configuration files can be loaded by the same mechanism.
The native library does not call the defineClass methods in the java.lang.ClassLoader, so class data can't be intercepted by replacing the java.lang.ClassLoader by a compromised version. The native library also prevents any existing ClassLoadHooks of Java programming language agents using the JVMPI/JVMTI interfaces from receiving the decrypted raw class data before it is converted into the in-memory representation.
6. How secure is JarCryp? Which encryption technique is used?
Please note that code-protection on the client-side – similar to the protection of digital music files, for instance - cannot be 100 percent secure if the code is still to be executed, unless you deliver and run your software in a dedicated and physically secure hardware device or simply don't deliver your software at all (e.g. by executing it only on the server-side). All you can do is use appropriate means to heighten the barriers confronting a potential attacker in such a way that an attack will either be infeasible due to the limited technical capabilities of the attacker or be just not worth the effort. This is what JarCryp does. With JarCryp, circumventing the security mechanisms comes at the very high cost of machine-code disassembly, memory tracing or VM modification. This significantly increases the protection of your code and resources when compared to the use of unprotected Jar files.
Even though the encryption used in the SJAR files is based on a standard symmetric encryption algorithm, the security of the system must not be rated in a cryptological manner due to the insecure nature (in cryptological terms) of client-side code execution as noted above.
7. The JVM will soon become open-source. Do you think that the ability to modify the JVM will weaken the protection offered by JarCryp?
No, but you will lose the ability to run the software on any kind of virtual machine implementation. In the future, JarCryp will verify the type of VM implementation that is used and make sure that it is not a compromised one.