Java bytecode encryption (Sharing)

Common Methods for Java code encryption are code obfuscation tools, such as proguard. Obfuscation is a logical encryption, and the obfuscated code is stillYesDecompilation, but because the name is equivalent to the replacement in the program processReadabilityIt becomes very poor, making the code hard to be understood and stolen. But if there is a way to make the code fundamentalCannot be decompiledThe effect is obviously better than the logic encryption, and one way to achieve this is bytecode encryption.

 

The actual running of Java code has little to do with the source code (*. Java) and only relies on the compiled bytecode file (*. class ). The content of the class file is very compact and strictly agreed so that JVM can identify and execute code functions. The Decompilation tool also uses this agreed structure to reverse parse bytecode into source code. As longDamageClassFile structureTo make this file completely invalid and becomeImpossibleDecompiled.

 

Of course, the encrypted class file cannot be normally loaded by JVM, but the Java class loading mechanism supports customization, which leaves room for decryption. You can use a custom class loader to implement "decryption first and then loading", so that the JVM can "normally" execute the encrypted class file. The following describes how to implement the above bytecode Encryption Policy.

 

First, write an interface for encryptor to implement various bytecode encryption algorithms. The two methods are to perform some transformation and inverse transformation for a byte array:

 

The following is a simple implementation:

This encryptor only changes the first byte to a custom special byte magicindex. The following shows the encryption result of a Java byte code using the bytecode viewing tool:

Can such a simple "algorithm" be encrypted? The following is the result of viewing the encrypted file using the decompilation plug-in JD of Eclipse:

 

This proves that the content of a bytecode file is a strictly constrained structure, and the entire file can be damaged if one byte is different. If you use a slightly complex encryption algorithm, it is impossible to decompile it.

 

Next, write a jar package encryption method. The logic is very simple: extract the class file from the original package, encrypt it, and write it to the new package.

Similarly, the decryption method retrieves a (encrypted) class file from a jar package and decrypts it to a JVM-recognizable bytecode. A small change is made here. Write multiple Encryptors in a map (cipherconfig. ciphermap) and use the first byte of the encrypted file as the identifier:

It is simpler to load from a file system (rather than a jar package) because the zipentry iterator is not required to locate the file name.

 

The next step is how to call the decryption method, which involves the class loading mechanism of Java. Generally, a custom class is loaded by inheriting the java. Lang. classloader class or its subclass, rewriting the findclass (name) method, and calling the method using the reflection mechanism. But here weI don't know the loading time and sequence of a published encryption project, nor the reference relationship between classes.(These are determined by the JVM's execution mechanism). Therefore, it is difficult to run an encrypted jar package on the JVM in a common way. To solve this problem, here we adopt a method that sounds a little "scary", that is, modifying the source code of the Java System class. The following describes the implementation method.

 

The custom classes are all loaded using the sun. Misc. lancher $ appclassloader. loadclass (name) method. The call time of this method is determined by the JVM underlying layer, and the return value is directly loaded into the JVM memory. The source code is as follows:

 

In essence, the last line is to call the underlying native method (which will be involved in subsequent articles) to load the bytecode into the memory. If the bytecode file of the corresponding class name is encrypted, this method cannot be parsed and a classnotfoundexception exception is thrown. The modification method is simple. When the default loading fails, try to use the custom Decryption Method to decrypt the loading:

 

After the preceding class is modified, the bin/Sun/MISC/launcher $ appclassloader will be compiled. class file (note that the namespace must be the same as the system) with JRE \ Lib \ RT. the corresponding file in the jar package can run the encrypted jar package normally. For example, if you write the loadfromjar method in other custom classes (such as tool classes), add the class to Rt. Jar together. The namespace must also be sun. Misc. Otherwise, the system will not be able to load the class itself. We will discuss the issue of rewriting the system class namespace in the future.

 

The "cost" of modifying the system class is that a custom JRE needs to be bound when the program is released, which seems "Uncomfortable", but if you analyze it carefully, the advantage is greater than the disadvantage. First, the program's independence and integrity are enhanced without JVM incompatibility issues. In the absence of a Java terminal, attaching a JVM is essential. Second, the encryption strength is further enhanced because the general JRE cannot run the encryption code. Third, modifying the system class or even JVM source code helps you understand the underlying principles of the Java Virtual Machine, custom System Classes and JVM also enable developers to control code greatly. The only drawback may be that binding JRE increases the total size of the program, but you can search for keywords such as "Green JRE" or "JRE slimming" through some uncomplicated optimization measures ), the JRE required by most programs can be compressed to less than 10 MB. In addition, the "light client mode" discussed in subsequent articles of the application can be fully accepted at the cost of space.

 

If you are interested in the light client, you can join our group: 291694807. This group is mainly used to discuss light clients. The technology used includes QT, flex, Java, and VC.

You can also follow my weibo http://weibo.com/liuxue9527