ClassGuard FAQ

How does it work?

ClassGuard is a tool to prevent Java decompiling and for licensing Java applications.

The Java class files are encrypted using a 128Bit AES encryption. The AES key is generated randomly every time you start the encryption tool. The decryption is done transparently by a custom class loader. The main part of this class loader is written in C to prevent decompiling and other tampering.

The current version additionally contains a license manager. The main part of the license manager is also written in C. Java class files are only decrypted if a valid license is found.

How does Tomcat and Jboss support work?

As of Version 1.5, ClassGuard supports Tomcat and Jboss containers.

To use ClassGuard in combination with tomcat, you have to configure your web application for using the ClassGuard tomcat class loader. This can be set in the context of the web application.

To use ClassGuard in combination with Jboss, you have to include the ClassGuard Jboss service JbossClassGuard.sar in your ear file. Note that Jboss support is still experimental.

Support for other J2EE containers may be implemented on request, please ask.

Further links:

How do I start the encrypted Project?

There are two ways of starting the encrypted project:

  1. Explicitly set the bootstrap classloader to ClassGuard using the Java property java.system.class.loader
  2. Use a wrapper start class using reflection

Further links:

How secure is it really?

There is no way of cracking the used 128Bit AES Encryption. As the main part of ClassGuard is written in C, the key can't be extracted using a Java decompiler. However, there may be possibilities to crack the encryption using a debugger on the assembler level. At the moment, no such attempt is known.

Some experts state, it would be possible to crack byte code encryption by hacking some class files of the Java language itsself, e.g. defineClass() in java.lang.ClassLoader. Bytecode encrypted by ClassGuard is passed through to the virtual machine on the native level. The bytecode never appears in any Java class.

Is there a way of encrypting additional resources?

Since version 2.0, the encryption of addtional resources (e.g. property files or images) is possible in a transparent way. Encrypted resources may be loaded by getResource() or getResourceAsStream().

Further links:

What platforms are supported?

The upcoming version 2.0 currently supports Sun Java 5 and 6 for Windows and Linux on i386. More platforms are planned for Version 2.0, including MacOS X, Windows, Linux and Solaris on x86-64. The release planning for platforms is based on demand, more platforms may be available on request. Virtual machines besides Sun Java may work, but are not supported.

When I debug my encrypted project, I get a java.lang.NoClassDefFoundError

Currently, there are three ways to implement a Java debugger or profiler:

  • java.lang.instrument (-javaagent)
  • jvmti (-agentlib/-agentpath)
  • jvmpi (-Xrun)

It is possible to get Java bytecode by all of these ways. Therefor ClassGuard detects Java debuggers and refuses to decrypt any classes in case of any running debugger.

Can I combine ClassGuard and Code Obfuscation?

As ClassGuard works on the binary level of class files, it does not iterfere with Java code obfuscation tools.

How can I check if my class encryption tool works reliably?

You may use our debugging agent to test your code encryption tool. Download JSecurityAgent.jar and run your application with the additional parameter -javaagent:JSecurityAgent.jar. The bytecode agent displays all classes of which it can get the bytecode. If you see a line like

BytecodeAgent: Got bytecode of  my/encrypted/class

your tool is vulnerable.

Further links:

Top of page Print version  Imprint