Java is a cross-platform explanatory language. The bytecode in Java source code compilation is stored in the class file. Class file is an intermediate code in the form of bytecode, which contains a lot of source code information, such as variable names, method names and so on. Therefore, decompilation of Java intermediate code becomes very easy. At present, there are many free and commercialized decompilation software on the market, which can generate high-quality decompilation source code. Therefore, how to protect Java programs has become a very important challenge for developers. This paper first discusses the basic methods of protecting Java programs, and then makes a deep study on code confusion. Finally, combining with a practical application, this paper analyzes how to protect Java programs in practice. Decompilation has become the biggest challenge to protect Java programs. Usually, programs developed in C, C++ and other programming languages are compiled into object codes, which are all binary executable codes of this machine. Usually all source files are compiled and linked into an executable file. In these executable files, the compiler will delete variable names, method names and other information in the program, which are often expressed by memory addresses. For example, if you need to use a variable, you usually access it through its address. Therefore, it is very difficult to decompile these local object codes. The appearance of Java language makes decompilation very easy and effective. The reasons are as follows: 1. Due to the requirement of cross-platform, the instruction set of Java is relatively simple and universal, and it is easier to get the semantic information of the program; 2.Java compiler compiles each class into a separate file, which also simplifies the decompilation work; In three minutes. Java class files, all method names and variable names are still reserved, and variables and methods are accessed through these names. These symbols usually carry a lot of semantic information. Because of the characteristics of Java programs, the effect of decompiling unprocessed Java programs is very good. At present, there are many Java decompilation tools on the market, including free tools, commercial tools and open source tools. The decompilation speed and effect of these tools are very good. Good decompilation software can decompile a program that is very close to the source code. Therefore, by decompiling programs, hackers can change them or reuse them. Therefore, how to protect Java programs from decompilation is a very important issue. Due to the high abstraction of Java bytecode, common protection technologies are easily decompiled. This section introduces several common methods to protect Java bytecode from decompilation. Usually, these methods can not absolutely prevent the program from being decompiled, but only increase the difficulty of decompilation, because these methods have their own use environment and weaknesses. The simplest way to isolate Java programs is to prevent users from accessing Java programs, which is the most fundamental method and can be realized in many ways. For example, developers can put key Java classes on the server side, and clients can get services by accessing the relevant interfaces of the server instead of directly accessing the class files. So hackers can't decompile class files. At present, there are more and more standards and protocols for providing services through interfaces, such as HTTP, Web Service and RPC. However, many applications are not suitable for this kind of protection. For example, Java programs cannot be isolated from programs running on a single machine. This protection mode is shown in figure 1. Figure 1 Isolating Java Program Schematic Encrypting Class Files In order to prevent class files from being directly decompiled, many developers will encrypt some key class files, such as classes related to registration code and serial number management. Before using these encrypted classes, the program needs to decrypt them first and then load them into the JVM. Decryption of these categories can be done by hardware or software. In implementation, developers usually load encrypted classes by customizing the ClassLoader class (note that for security reasons, Applet do not support customized classloaders). The custom class loader first finds the encrypted class, then decrypts it, and finally loads the decrypted class into the JVM. In this way of protection, the custom class loader is a very important class. Because there is no encryption, it may be the first target of hackers. Encrypted classes can be easily decrypted if the related decryption keys and algorithms are conquered. The schematic diagram of this protection mode is shown in Figure 2. Fig. 2 is a schematic diagram of encrypting class files and converting programs into local codes, which is also an effective method to prevent decompilation. Because local code is often difficult to decompile. Developers can choose to convert the whole application into local code, or they can choose to convert key modules. If only key modules are converted, Java programs need to use JNI technology when using these modules. Of course, while using this technology to protect Java programs, it also sacrifices the cross-platform characteristics of Java. For different platforms, we need to maintain different versions of local code, which will increase the work of software support and maintenance. However, for some key modules, sometimes this scheme is often necessary. In order to ensure that these local codes cannot be modified and replaced, it is usually necessary to digitally sign these codes. Before using these local codes, it is usually necessary to authenticate these local codes to ensure that they have not been changed by hackers. If the signature check passes, the related JNI method is called. The schematic diagram of this protection mode is shown in Figure 3. Code obfuscation figure 3 is converted into a local code figure. Code obfuscation is the reorganization and processing of class files, so that the processed code and the preprocessed code can accomplish the same function (semantics). For confused code, it is difficult to decompile, that is, the code obtained after decompilation is very difficult to understand and obscure, so it is difficult for decompilers to know the true semantics of the program. Theoretically, if the hacker has enough time, the confused code may still be cracked, and some people are even developing anti-confusion tools. However, from the actual situation, due to the diversified development of obfuscation technology and the maturity of obfuscation theory, the obfuscated Java code can still prevent decompilation. Below we will introduce obfuscation technology in detail, because obfuscation is an important technology to protect Java programs. Fig. 4 is a diagram of code obfuscation. Figure 4 Summary of several technologies in the code confusion diagram All of the above technologies have different application environments and their own weaknesses. Table 1 is a comparison of related characteristics. Introduction table of obfuscation technology 1 comparison table of different protection technologies Up to now, obfuscation technology is still the most basic protection method of Java programs. There are many Java obfuscation tools, including commercial, free and open source. Sun also provides its own obfuscation tools. Most of them are confusing files, and a few tools deal with source code first, and then with classes, which increases the intensity of confusion processing. At present, the commercially successful confusion tools are 1stBarrier series of JProof Company, JShrink of Eastridge Company, SourceGuard of 4thpass.com, etc. According to the different confusion targets, the main confusion technologies can be divided into the following categories, namely symbol confusion, data confusion, control confusion and transformation prevention. There is a lot of information that has nothing to do with the program execution itself, such as method names and variable names. The names of these symbols often have certain meanings. For example, if a method is named getKeyLength (), then this method may be used to return the length of the key. Symbol confusion is to confuse these information into meaningless representations, such as numbering all variables from vairant_00 1; All methods are numbered from method_00 1 This will bring some difficulties to decompilation. For private functions and local variables, it is usually possible to change their symbols without affecting the running of the program. However, for some interface names, public functions and member variables, if other external modules need to refer to these symbols, we often need to keep these names, otherwise external modules cannot find methods and variables with these names. Therefore, most obfuscation tools provide rich options for symbol obfuscation, allowing users to choose whether and how to obfuscate symbols. Data obfuscation Figure 5 Changing data access Data obfuscation is to obfuscate the data used by the program. There are also many methods of confusion, which can be mainly divided into changing data storage and coding transformation and changing data access transformation. Changing data storage and coding will destroy the data storage method used by the program. For example, an array with 10 members is disassembled into 10 variables, and the names of these variables are scrambled; Convert a two-dimensional array into a one-dimensional array, etc. For some complex data structures, we will disrupt their data structures, such as replacing a complex class with multiple classes. Another method is to change data access. For example, when accessing the subscripts of an array, we can do some calculations, and Figure 5 is an example. In actual confusion processing, these two methods are usually used together, which not only disrupts data storage, but also disrupts data access. After confusing the data, the semantics of the program becomes complicated, which increases the difficulty of decompilation. Control confusion Control confusion is to confuse the control flow of a program and make it more difficult to decompile the control flow of the program. Usually, the change of control flow needs to add some extra calculation and control flow, so it will bring some negative effects to the performance of the program. Sometimes, there is a trade-off between the performance of a program and the degree of confusion. The technology to control chaos is the most complicated and has the most skills. These technologies can be divided into the following categories: adding confusion control can hide the original semantics of the program by adding additional complex control flows. For example, for two statements A and B that are executed in sequence, we can add a control condition to determine the execution of B ... so it is more difficult to disassemble them. But all interference control should not affect the execution of B. Figure 6 shows three ways to add obfuscation control to this example. Fig. 6 Adding three ways of confusion control to control the flow reorganization control flow is also an important confusion method. For example, if a program calls a method, the method code can be embedded into the calling program after confusion. On the contrary, Cheng