Shulou(Shulou.com)06/01 Report--

Keywords: source code encryption, source code encryption.

Why do source code encryption?

In source code development enterprises, how to protect their own products and maintain independent intellectual property rights is necessary in the process of enterprise development. For those who often do development, there are also many ways to encrypt the source code. For traditional languages such as C or C++, it is easy to protect the source code on Web, as long as it is not released. Unfortunately, the source code of the Java program is easy for others to peek at. As long as there is a decompiler, anyone can analyze other people's code. The flexibility of Java makes the source code easy to steal, but at the same time, it also makes it relatively easy to protect the code through encryption. The only thing we need to know is the ClassLoader object of Java. Of course, knowledge of Java Cryptography Extension (JCE) is also essential in the encryption process.

In the actual development process, there are several ways to "obfuscate" Java class files, which reduces the effect of decompiler processing class files. However, it is not difficult to modify the decompiler so that it can handle these obfuscated class files, so we can not simply rely on fuzzy technology to ensure the security of source code encryption.

We can use today's popular encryption tools to encrypt applications, such as PGP (Pretty Good Privacy) or GPG (GNU Privacy Guard). At this point, the final PC consumer must decrypt the application before running it. But after decryption, the end user has an unencrypted class file, which is no different from not encrypting it in advance.

The mechanism for loading bytecode at Java runtime implicitly means that bytecode can be modified. Each time JVM loads a class file, it needs an object called ClassLoader, which is responsible for loading the new class into the running JVM. JVM gives ClassLoader a string containing the name of the class to be loaded (such as java.lang.Object), and ClassLoader is responsible for finding the class file, loading the raw data, and converting it into a Class object.

We can modify the class file before it is executed by customizing the ClassLoader. This technology is widely used-in this case, it is used to decrypt class files when they are loaded, so it can be seen as an instant decryptor. Because the decrypted bytecode file will never be saved to the file system, it is difficult for the thief to get the decrypted code.

Since the process of converting the original bytecode into a Class object is entirely the responsibility of the system, it is not difficult to create a custom ClassLoader object, as long as you get the original data first, and then any transformation, including decryption, can be performed.

Java 2 simplifies the construction of custom ClassLoader to some extent. In Java 2, the default implementation of loadClass is still responsible for handling all the necessary steps, but it also calls a new findClass method to take into account the various custom class loading procedures.

This gives us a shortcut to writing custom ClassLoader and reduces the hassle: just overwrite findClass, not loadClass. This approach avoids repeating the common steps that all loaders must perform, because loadClass is responsible for all of this.

However, the custom ClassLoader for this article does not use this approach. The reason is simple. If the default ClassLoader looks for the encrypted class file first, it can find it; but because the class file is encrypted, it will not recognize the class file, and the loading process will fail. Therefore, we must implement loadClass ourselves.

Keywords: source code encryption, source code encryption.

Custom class loader

Every running JVM already has a ClassLoader. This default ClassLoader looks for the appropriate bytecode file in the local file system based on the value of the CLASSPATH environment variable.

The application of customized ClassLoader requires a deeper understanding of this process. We must first create an instance of a custom ClassLoader class, and then explicitly ask it to load another class. This forces JVM to associate this class and all the classes it needs to the custom ClassLoader. Listing 1 shows how to load class files with custom ClassLoader.

[Listing 1: load class files with custom ClassLoader]

/ / first create a ClassLoader object

ClassLoader myClassLoader = new myClassLoader ()

/ / load class files using custom ClassLoader objects

/ / and convert it to a Class object

Class myClass = myClassLoader.loadClass ("mypackage.MyClass")

/ / finally, create an instance of this class

Object newInstance = myClass.newInstance ()

/ / Note that all other classes required by MyClass will pass through the

/ / customized ClassLoader auto-loading

As mentioned earlier, customizing the ClassLoader simply takes the data from the class file and then passes the bytecode to the runtime system, which does the rest of the task.

ClassLoader has several important methods. When creating a custom ClassLoader, we only need to overwrite one of them, loadClass, providing the code to get the data from the original class file. This method takes two parameters: the name of the class, and a tag indicating whether JVM requires the class name to be resolved (that is, whether the dependent class is loaded at the same time). If the tag is true, we just need to call resolveClass before returning JVM.

[a simple implementation of Listing 2:ClassLoader.loadClass ()]

Public Class loadClass (String name, boolean resolve)

Throws ClassNotFoundException {

Try {

/ / the Class object we want to create

Class clasz = null

/ / required step 1: if the class is already in the system buffer

/ / We don't have to load it again

Clasz = findLoadedClass (name)

If (clasz! = null)

Return clasz

/ / here is the customization section

Byte classData [] = / * get bytecode data by some method * /

If (classData! = null) {

/ / Bytecode data was successfully read, now convert it into a Class object

Clasz = defineClass (name, classData, 0, classData.length)

}

/ / required step 2: if the above is not successful

/ / We try to load it with the default ClassLoader

If (clasz = = null)

Clasz = findSystemClass (name)

/ / required step 3: load related classes if necessary

If (resolve & & clasz! = null)

ResolveClass (clasz)

/ / return the class to the caller

Return clasz

} catch (IOException ie) {

Throw new ClassNotFoundException (ie.toString ())

} catch (GeneralSecurityException gse) {

Throw new ClassNotFoundException (gse.toString ())

}

}

Listing 2 shows a simple loadClass implementation. Most of the code is the same for all ClassLoader objects, but a small portion (marked with comments) is unique. During processing, the ClassLoader object uses several other helper methods:

FindLoadedClass: used to check to confirm that the requested class does not currently exist. The loadClass method should call it first.

DefineClass: after getting the bytecode data of the original class file, call defineClass to convert it into a Class object. Any loadClass implementation must call this method.

FindSystemClass: provides support for default ClassLoader. If the custom method used to find the class cannot find the specified class (or deliberately does not need a custom method), you can call this method to try the default loading method. This is useful, especially when loading standard Java classes from normal JAR files.

ResolveClass: when JVM wants to load not only the specified class, but also all other classes referenced by that class, it sets the resolve parameter of loadClass to true. At this point, we must call resolveClass before returning the Class object we just loaded to the caller.

Keywords: source code encryption, source code encryption.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.