WO2019062015A1 - Source code protection method, application server, and computer-readable storage medium - Google Patents

Abstract

Disclosed is a source code protection method. The method comprises: receiving a code encryption program input by a user, and using the code encryption program to encrypt a source code, to obtain an encrypted file; acquiring JDK, and using a code decryption program corresponding to the code encryption program to process the JDK, to obtain the processed JDK; running the processed JDK; and invoking the encrypted file through the processed JDK and decrypting same. Also provided is an application server. The source code protection method and the application server provided in the present application can effectively stop a source file from being decompiled, ensuring the security of the source file, also keeping the cross-platform property of a program, and improving the user experience.

Description

Source code protection method, application server, and computer readable storage medium

This application claims the priority of the Chinese patent application filed on September 30, 2017, the Chinese Patent Office, the application number is 201710914956.6, and the invention name is "source code protection method, application server and computer readable storage medium". The citation is incorporated in the application.

Technical field

The present application relates to the field of communications technologies, and in particular, to a source code protection method, an application server, and a computer readable storage medium.

Background technique

The Java language is cross-platform because the Java source code is translated into a class file by the compiler, and the class file is stored as intermediate code in a platform-independent format. One disadvantage of class files is that you can use the disassembler in the JDK to disassemble the class files, and then use the decompiler to decompile the disassembled results to get the source code for the class. This is very disadvantageous for programmers who need to prevent Java source code from being plagiarized or attacked.

The existing methods for class file protection mainly include the following: bytecode obfuscation technology, loader encryption technology, local compilation technology, and bytecode watermarking technology.

The bytecode obfuscation technique uses the obfuscator tool to prevent the compilation of the decompiler. The purpose is to make it difficult for the decompiler to understand the class program, so that reverse engineering will take more time and effort to translate the class file, most of the obfuscators. The tool scrambles the identifier in the bytecode file, and a meaningful name is replaced with a sequence or randomly generated meaningless name. However, this technology only achieves the ambiguity on the surface, but its internal business logic remains unchanged. If the cracker has patience, it can still be broken.

The loader encryption technology first encrypts the class file with a certain encryption algorithm, then transfers the file to the destination host, and then loads and parses the encrypted class file with a specific custom class loader. But because the class loader itself is written in java, it can't be encrypted by itself, so others can easily get your decryption method by decompiling your class loader.

Local compilation technology refers to the process of compiling a Java application to a local application, converting the text code program to a local binary file, which not only improves the running speed of the program, occupies less memory, but also makes the security reach the local executable application. Degree. But this technique makes the application lose its cross-platform features and is not suitable for large applications due to the immature native compiler.

Bytecode watermarking technology, like embedding watermarks in picture sounds, can also embed transparent, secure, and robust information in Java programs, providing valid evidence for confirming whether certain programs are plagiarized, but not Prevent class files from being reused or decompiled.

Summary of the invention

In view of this, the present application proposes a source code protection method and an application server, which effectively prevents the source file from being decompiled, ensures the security of the source file, and maintains the cross-platform characteristics of the program, thereby improving the user experience.

First, in order to achieve the above object, the present application provides an application server including a memory, a processor, and a source code protection program stored on the memory and executable on the processor, the source code The protection program implements the following steps when executed by the processor:

Receiving a code encryption program input by the user, and encrypting the source code by using the code encryption program to obtain an encrypted file;

Obtaining a JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK;

Running the processed JDK; and

The encrypted file is retrieved and decrypted by the processed JDK.

In addition, to achieve the above object, the present application further provides a source code protection method, where the method is applied to an application server, and the method includes:

Receiving a code encryption program input by the user, and encrypting the source code by using the code encryption program to obtain an encrypted file;

Obtaining a JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK;

Running the processed JDK; and

The encrypted file is retrieved and decrypted by the processed JDK.

Further, in order to achieve the above object, the present application further provides a computer readable storage medium storing an active code protection program, the source code protection program being executable by at least one processor, such that The at least one processor performs the steps of the source code protection method as described above.

Compared with the prior art, the application server, the source code protection method, and the computer readable storage medium proposed by the present application first receive a code encryption program input by a user, and encrypt the source code by using the code encryption program. Obtaining the encrypted file; secondly, obtaining the JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain the processed JDK; then, running the processed JDK; finally, The encrypted file is retrieved and decrypted by the processed JDK. In this way, the disadvantages of the prior art class files being reused or decompiled can be avoided, the source files are effectively prevented from being decompiled, the security of the source files is ensured, and the cross-platform characteristics of the programs are maintained, thereby improving the user experience.

DRAWINGS

1 is a schematic diagram of an optional hardware architecture of an application server of the present application;

2 is a block diagram showing the program of the first embodiment of the source code protection program of the present application;

3 is a block diagram showing a program module of a second embodiment of the source code protection program of the present application;

4 is a flowchart of a first embodiment of a source code protection method according to the present application;

FIG. 5 is a flowchart of a second embodiment of a source code protection method according to the present application; FIG.

6 is a flowchart of a third embodiment of a source code protection method according to the present application;

FIG. 7 is a flowchart of a fourth embodiment of a source code protection method according to the present application.

Reference mark:

application server	1
Memory	11
processor	12
Network Interface	13
Source code protector	200
Receiving module	201
Cryptographic module	202
Acquisition module	203
Execution module	204
Decryption module	205
Storage module	206

The implementation, functional features and advantages of the present application will be further described with reference to the accompanying drawings.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

It should be noted that the descriptions of "first", "second" and the like in the present application are for the purpose of description only, and are not to be construed as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. . Thus, features defining "first" and "second" may include at least one of the features, either explicitly or implicitly. In addition, the technical solutions between the various embodiments may be combined with each other, but must be based on the realization of those skilled in the art, and when the combination of the technical solutions is contradictory or impossible to implement, it should be considered that the combination of the technical solutions does not exist. Nor is it within the scope of protection required by this application.

Referring to FIG. 1, it is a schematic diagram of an optional hardware architecture of the application server 1.

The application server 1 may be a computing device such as a rack server, a blade server, a tower server, or a rack server. The application server 1 may be a stand-alone server or a server cluster composed of multiple servers.

In this embodiment, the application server 1 may include, but is not limited to, the memory 11, the processor 12, and the network interface 13 being communicably connected to each other through a system bus.

The application server 1 connects to the network through the network interface 13 (not shown in FIG. 1) to obtain information. The network 1 may be an intranet, an Internet, a Global System of Mobile communication (GSM), a Wideband Code Division Multiple Access (WCDMA), a 4G network, Wireless or wired networks such as 5G networks, Bluetooth, Wi-Fi, and call networks.

It is pointed out that Figure 1 only shows the application server 1 with components 11-13, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.

The memory 11 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (eg, SD or DX memory, etc.), and a random access memory (RAM). , static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), magnetic memory, magnetic disk, optical disk, and the like. In some embodiments, the memory 11 may be an internal storage unit of the application server 1, such as a hard disk or memory of the application server 1. In other embodiments, the memory 11 may also be an external storage device of the application server 1, such as a plug-in hard disk equipped with the application server 1, a smart memory card (SMC), and a secure digital ( Secure Digital, SD) cards, flash cards, etc. Of course, the memory 11 can also include both the internal storage unit of the application server 1 and its external storage device. In this embodiment, the memory 11 is generally used to store an operating system installed on the application server 1 and various types of application software, such as program code of the source code protection program 200. Further, the memory 11 can also be used to temporarily store various types of data that have been output or are to be output.

The processor 12 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 12 is typically used to control the overall operation of the application server 1, such as performing data interaction or communication related control and processing, and the like. In this embodiment, the processor 12 is configured to run program code or process data stored in the memory 11, such as running the source code protection program 200 and the like.

The network interface 13 may comprise a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the application server 1 and other electronic devices.

In this embodiment, the application code server 200 installs and runs an active code protection program 200. When the source code protection program 200 is running, the application server 1 receives a code encryption program input by a user, and utilizes the code. The encryption program encrypts the source code to obtain an encrypted file; obtains a JDK, and processes the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK; JDK; the encrypted file is retrieved and decrypted by the processed JDK. In this way, the disadvantages of the prior art class files being reused or decompiled can be avoided, the source files are effectively prevented from being decompiled, the security of the source files is ensured, and the cross-platform characteristics of the programs are maintained, thereby improving the user experience.

So far, the hardware structure and functions of the related devices of the various embodiments of the present application have been described in detail. Hereinafter, various embodiments of the present application will be proposed based on the above-described application environment and related devices.

First, the present application proposes a source code protection program 200.

In this embodiment, the source code protection program 200 includes a series of computer program instructions stored in the memory 11, and when the computer program instructions are executed by the processor 12, the source code protection of the embodiments of the present application can be implemented. Control operation. In some embodiments, the source code protection program 200 can be divided into one or more modules based on the particular operations implemented by the various portions of the computer program instructions. For example, in FIG. 2, the source code protection program 200 can be divided into a receiving module 201, an encryption module 202, an obtaining module 203, an executing module 204, and a decrypting module 205. among them:

The receiving module 201 is configured to receive a code encryption program input by a user.

The user enters a code encryption program at the mobile terminal. Specifically, the source code refers to source code of an application that needs to be deployed externally. In this embodiment, the code encryption program input by the user is described by taking a C language code (C code for short) encryption program as an example. By adding a C code encryption program to the source code of the application, and then compiling, the source code is encrypted at the same time as the compilation is completed. In the present embodiment, the C code encryption program and the following C code decryption program are some existing C code encryption and decryption programs, which will not be described in detail herein.

The encryption module 202 is configured to encrypt the source code by using the code encryption program to obtain an encrypted file.

The obtaining module 203 is configured to obtain a JDK, and process the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK.

JDK is a Java language software development kit for Java applications on mobile devices and embedded devices. Specifically, in order to implement the step of processing the JDK by using a code decryption program corresponding to the code encryption program, the obtaining module 203 is further configured to:

Parsing the JDK, acquiring a file processing code program of the JDK; inserting an encryption determination program before the file processing code program and inserting a call function of the code decryption program after the encryption determination program. The encryption judging program is configured to determine whether the file retrieved by the JDK is encrypted, and the calling function is configured to retrieve the code decryption program after determining that the file retrieved by the JDK is encrypted.

In this embodiment, the file processing code program includes: a load file program, a definition class file program, and a decompression compression package program.

In this embodiment, the obtained JDK is an existing open source JDK, such as JDK1.7, JDK1.8, etc., and the open source JDK can parse the code program of the implementation, and can be based on the existing code. The program adds a developer-defined function program. For example, in the embodiment, the load file program, the definition class file program, and the decompression compression package program may be added to the judgment program to determine whether the received file has been encrypted, and the specific judgment method. The normal parsing function can be called to parse the received file. If it can be parsed normally, it is not encrypted. Otherwise, it is encrypted. After the added judgment program and before loading the file program, defining the class file program, and extracting the compressed package program, the calling function of the C code decryption program may also be added to implement the call of the C code decryption program.

The execution module 204 is configured to run the processed JDK.

The decryption module 205 retrieves the encrypted file and decrypts it by using the processed JDK.

Specifically, before the step of retrieving the encrypted file by the processed JDK and decrypting, the decrypting module 205 is further configured to:

Obtaining whether the application corresponding to the encrypted file running in the Java Virtual Machine (JVM) satisfies the preset identifier; if the application corresponding to the encrypted file satisfies the preset identifier, the decrypting module 205 encrypts the The file is decrypted. Otherwise, if the application corresponding to the encrypted file does not satisfy the preset identifier, the decryption module 205 does not decrypt the encrypted file.

In this embodiment, there may be other applications on a server or an intelligent computing device, but in actual use, only the decryption process in the processed JDK needs to be performed for the target application, if the application that needs to be decrypted is not judged. , then the decryption process will be performed for any application, which affects the security of the application.

Through the above program modules 201-205, the source code protection program 200 proposed by the present application first receives a code encryption program input by a user, and encrypts the source code by using the code encryption program to obtain an encrypted file; Next, the JDK is obtained, and the JDK is processed by a code decryption program corresponding to the code encryption program to obtain a processed JDK; then, the processed JDK is executed; finally, the processed JDK is passed. The encrypted file is retrieved and decrypted. In this way, the disadvantages of the prior art class files being reused or decompiled can be avoided, the source files are effectively prevented from being decompiled, the security of the source files is ensured, and the cross-platform characteristics of the programs are maintained, thereby improving the user experience.

Further, based on the above-described first embodiment of the source code protection program 200 of the present application, a second embodiment of the present application (shown in FIG. 3) is proposed. In this embodiment, the source code protection program 200 further includes a storage module 206, and the storage module 206 is configured to:

The encrypted file is stored on the hard disk before the execution module 204 runs the processed JDK.

In this embodiment, the decryption module 205 is further configured to:

Reading the encrypted file from the hard disk; determining, by the processed JDK, whether the read encrypted file is encrypted; if the encrypted file is encrypted, using the processing The calling function in the post JDK calls the code decryption program to decrypt the encrypted file.

In this embodiment, the application is stored in the hard disk in the form of a source code class file before being executed by the JDK, so that the encrypted source code can be immediately called from the hard disk through the processed JDK. Decoding, does not involve the subsequent processing flow of the application source code, and achieves transparency to subsequent applications.

Through the above program modules 201-206, the source code protection program 200 proposed by the present application can immediately decode the encrypted source code from the hard disk through the processed JDK, and does not involve subsequent processing of the application source code. The process implements transparency for subsequent applications.

In addition, the present application also proposes a source code protection method.

Referring to FIG. 4, it is a flowchart of the first embodiment of the source code protection method of the present application. In this embodiment, the order of execution of the steps in the flowchart shown in FIG. 4 may be changed according to different requirements, and some steps may be omitted.

Step S401, receiving a code encryption program input by a user.

The code encryption program that the user enters at the mobile terminal. Specifically, the source code refers to source code of an application that needs to be deployed externally. In this embodiment, the code encryption program input by the user is described by taking a C language code (C code for short) encryption program as an example. By adding a C code encryption program to the source code of the application, and then compiling, the source code is encrypted at the same time as the compilation is completed. In the present embodiment, the C code encryption program and the following C code decryption program are some existing C code encryption and decryption programs, which will not be described in detail herein.

Step S402, encrypting the source code by using the code encryption program to obtain an encrypted file.

Step S403, acquiring the JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain the processed JDK.

JDK is a Java language software development kit for Java applications on mobile devices and embedded devices. Specifically, the specific steps of processing the JDK by using a code decryption program corresponding to the code encryption program will be described in detail in the second embodiment of the source code protection method of the present application (see FIG. 5).

Step S404, running the processed JDK.

Step S405, the encrypted file is retrieved and decrypted by the processed JDK.

Specifically, before the step of retrieving and decrypting the encrypted file by the processed JDK, the application server 1 further obtains an encrypted operation in a Java Virtual Machine (JVM). Whether the application corresponding to the file satisfies the preset identifier; if the application corresponding to the encrypted file satisfies the preset identifier, the application server 1 decrypts the encrypted file; otherwise, if the application corresponding to the encrypted file is not satisfied If the identifier is preset, the application server 1 does not decrypt the encrypted file.

In this embodiment, there may be other applications on a server or an intelligent computing device, but in actual use, only the decryption process in the processed JDK needs to be performed for the target application, if the application that needs to be decrypted is not judged. , then the decryption process will be performed for any application, which affects the security of the application.

Through the above steps S401-405, the source code protection method proposed by the present application first receives a code encryption program input by a user, and encrypts the source code by using the code encryption program to obtain an encrypted file; secondly, Obtaining a JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK; then, running the processed JDK; and finally, obtaining the processed JDK The encrypted file is decrypted. In this way, the disadvantages of the prior art class files being reused or decompiled can be avoided, the source files are effectively prevented from being decompiled, the security of the source files is ensured, and the cross-platform characteristics of the programs are maintained, thereby improving the user experience.

As shown in FIG. 5, it is a flowchart of the second embodiment of the source code protection method of the present application. In this embodiment, the step of processing the JDK by using a code decryption program corresponding to the code encryption program includes:

Step S501, parsing the JDK, and acquiring the file processing code program of the JDK.

In this embodiment, the file processing code program includes: a load file program, a definition class file program, and a decompression compression package program.

Step S502, inserting an encryption determination program before the file processing code program and inserting a call function of the code decryption program after the encryption determination program.

Step S503, determining, by the encryption determination program, whether the file retrieved by the JDK is encrypted. After the file retrieved by the JDK is encrypted, step S504 is performed; otherwise, the process ends.

Step S504, the code decryption program is called by the calling function.

In this embodiment, the obtained JDK is an existing open source JDK, such as JDK1.7, JDK1.8, etc., and the open source JDK can parse the code program of the implementation, and can be based on the existing code. The program adds a developer-defined function program. For example, in the embodiment, the load file program, the definition class file program, and the decompression compression package program may be added to the judgment program to determine whether the received file has been encrypted, and the specific judgment method. The normal parsing function can be called to parse the received file. If it can be parsed normally, it is not encrypted. Otherwise, it is encrypted. After the added judgment program and before loading the file program, defining the class file program, and extracting the compressed package program, the calling function of the C code decryption program may also be added to implement the call of the C code decryption program.

Through the above steps S501-S504, the source code protection method proposed by the present application can process the JDK by using a code decryption program corresponding to the code encryption program.

As shown in FIG. 6, it is a flowchart of a third embodiment of the source code protection method of the present application. In the present embodiment, the order of execution of the steps in the flowchart shown in Fig. 6 may be changed according to different needs, and some steps may be omitted.

Step S601, receiving a code encryption program input by the user.

Step S602, encrypting the source code by using the code encryption program to obtain an encrypted file.

Step S603, acquiring the JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain the processed JDK.

Step S604, storing the encrypted file on a hard disk.

Step S605, running the processed JDK.

Step S606, the encrypted file is retrieved and decrypted by the processed JDK.

Through the above steps S601-S606, the source code protection method proposed by the present application can immediately decode the encrypted source code by calling the processed JDK from the hard disk, and does not involve the subsequent processing flow of the application source code. , to achieve transparency of subsequent applications.

Based on the third embodiment of the source code protection method of the present application, a fourth embodiment of the source code protection method of the present application is proposed.

As shown in FIG. 7, it is a flowchart of the fourth embodiment of the source code protection method of the present application. In this embodiment, the step of retrieving and decrypting the encrypted file by using the processed JDK includes:

Step S701, reading the encrypted file from the hard disk.

Step S702, determining whether the read encrypted file is encrypted by using the processed JDK. If the encrypted file is encrypted, step S703 is performed, otherwise, the process ends.

Step S703, using the calling function in the processed JDK to call the code decryption program to decrypt the encrypted file.

In this embodiment, the application is stored in the hard disk in the form of a source code class file before being executed by the JDK, so that the encrypted source code can be immediately called from the hard disk through the processed JDK. Decoding, does not involve the subsequent processing flow of the application source code, and achieves transparency to subsequent applications.

Through the above steps S701-S703, the source code protection method proposed by the present application can retrieve the encrypted file and decrypt it through the processed JDK.

The serial numbers of the embodiments of the present application are merely for the description, and do not represent the advantages and disadvantages of the embodiments.

Through the description of the above embodiments, those skilled in the art can clearly understand that the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better. Implementation. Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.

The above is only a preferred embodiment of the present application, and is not intended to limit the scope of the patent application, and the equivalent structure or equivalent process transformations made by the specification and the drawings of the present application, or directly or indirectly applied to other related technical fields. The same is included in the scope of patent protection of this application.

Claims (20)

1. A source code protection method is applied to an application server, where the method includes:

   Receiving a code encryption program input by a user, and encrypting the source code by the code encryption program to obtain an encrypted file;

   Obtaining a JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK;

   Running the processed JDK; and

   The encrypted file is retrieved and decrypted by the processed JDK.
2. The source code protection method according to claim 1, wherein the step of processing the JDK by using a code decryption program corresponding to the code encryption program comprises:

   Parsing the JDK to obtain the file processing code program of the JDK;

   Inserting an encryption judging program for determining whether the file retrieved by the JDK is encrypted before the file processing code program; and

   Inserting a call function of the code decryption program after the encryption determination program, the calling function is configured to retrieve the code decryption program after determining that the file retrieved by the JDK is encrypted.
3. The source code protection method according to claim 1, wherein before the step of running the processed JDK, the method further comprises:

   The encrypted file is stored on the hard disk.
4. The source code protection method according to claim 3, wherein the step of retrieving and decrypting the encrypted file by the processed JDK comprises:

   Reading the encrypted file from the hard disk;

   Determining, by the processed JDK, whether the read encrypted file is encrypted; and

   If the encrypted file is encrypted, the encrypted file is decrypted by calling the code decryption program by the calling function in the processed JDK.
5. The source code protection method according to claim 3, wherein the step of processing the JDK by using a code decryption program corresponding to the code encryption program comprises:

   Parsing the JDK to obtain the file processing code program of the JDK;

   Inserting an encryption judging program for determining whether the file retrieved by the JDK is encrypted before the file processing code program; and

   Inserting a call function of the code decryption program after the encryption determination program, the calling function is configured to retrieve the code decryption program after determining that the file retrieved by the JDK is encrypted.
6. The source code protection method according to claim 1, wherein before the step of decrypting and decrypting the encrypted file by the processed JDK, the method further comprises:

   Obtaining whether the application corresponding to the encrypted file running in the JAVA virtual machine meets the preset identifier;

   Decrypting the encrypted file if the application corresponding to the encrypted file satisfies a preset identifier; and

   If the application corresponding to the encrypted file does not satisfy the preset identifier, the encrypted file is not decrypted.
7. The source code protection method according to claim 3, wherein before the step of retrieving and decrypting the encrypted file by the processed JDK, the method further comprises:

   Obtaining whether the application corresponding to the encrypted file running in the JAVA virtual machine meets the preset identifier;

   Decrypting the encrypted file if the application corresponding to the encrypted file satisfies a preset identifier; and

   If the application corresponding to the encrypted file does not satisfy the preset identifier, the encrypted file is not decrypted.
8. An application server, comprising: a memory, a processor, and a source code protection program stored on the memory and operable on the processor, the source code protection program being processed The following steps are implemented when the device is executed:

   Receiving a code encryption program input by a user, and encrypting the source code by the code encryption program to obtain an encrypted file;

   Obtaining a JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK;

   Running the processed JDK; and

   The encrypted file is retrieved and decrypted by the processed JDK.
9. The application server according to claim 8, wherein the step of processing the JDK by using a code decryption program corresponding to the code encryption program comprises:

   Parsing the JDK to obtain the file processing code program of the JDK;

   Inserting an encryption judging program for determining whether the file retrieved by the JDK is encrypted before the file processing code program; and

   Inserting a call function of the code decryption program after the encryption determination program, the calling function is configured to retrieve the code decryption program after determining that the file retrieved by the JDK is encrypted.
10. The application server according to claim 8, wherein said source code protection program is further executed by said processor before said step of executing said processed JDK:

    The encrypted file is stored on the hard disk.
11. The application server according to claim 10, wherein the step of retrieving and decrypting the encrypted file by the processed JDK comprises:

    Reading the encrypted file from the hard disk;

    Determining, by the processed JDK, whether the read encrypted file is encrypted; and

    If the encrypted file is encrypted, the code decryption program is called by the call function in the processed JDK to decrypt the encrypted file.
12. The application server according to claim 10, wherein the step of processing the JDK by using a code decryption program corresponding to the code encryption program comprises:

    Parsing the JDK to obtain the file processing code program of the JDK;

    Inserting an encryption judging program for determining whether the file retrieved by the JDK is encrypted before the file processing code program; and

    Inserting a call function of the code decryption program after the encryption determination program, the call function is configured to retrieve the code decryption program after determining that the file retrieved by the JDK is encrypted.
13. The application server according to claim 8, wherein said source code protection program is used by said processor before said step of retrieving said encrypted file by said processed JDK and decrypting said file Implementation steps are also implemented:

    Obtaining whether the application corresponding to the encrypted file running in the JAVA virtual machine meets the preset identifier;

    Decrypting the encrypted file if the application corresponding to the encrypted file satisfies a preset identifier; and

    If the application corresponding to the encrypted file does not satisfy the preset identifier, the encrypted file is not decrypted.
14. The application server according to claim 10, wherein said source code protection program is used by said processor before said step of decrypting said encrypted file by said processed JDK and decrypting said file Implementation steps are also implemented:

    Obtaining whether the application corresponding to the encrypted file running in the JAVA virtual machine meets the preset identifier;

    Decrypting the encrypted file if the application corresponding to the encrypted file satisfies a preset identifier; and

    If the application corresponding to the encrypted file does not satisfy the preset identifier, the encrypted file is not decrypted.
15. A computer readable storage medium storing an active code protection program, the source code protection program being executable by at least one processor to cause the at least one processor to perform the following steps:

    Receiving a code encryption program input by a user, and encrypting the source code by the code encryption program to obtain an encrypted file;

    Obtaining a JDK, and processing the JDK by using a code decryption program corresponding to the code encryption program to obtain a processed JDK;

    Running the processed JDK; and

    The encrypted file is retrieved and decrypted by the processed JDK.
16. The computer readable storage medium according to claim 15, wherein the step of processing the JDK by using a code decryption program corresponding to the code encryption program comprises:

    Parsing the JDK to obtain the file processing code program of the JDK;

    Inserting an encryption judging program for determining whether the file retrieved by the JDK is encrypted before the file processing code program; and

    Inserting a call function of the code decryption program after the encryption determination program, the calling function is configured to retrieve the code decryption program after determining that the file retrieved by the JDK is encrypted.
17. A computer readable storage medium according to claim 15 wherein said source code protection program is further executed by said processor prior to said step of executing said processed JDK:

    The encrypted file is stored on the hard disk.
18. The computer readable storage medium according to claim 17, wherein the step of retrieving and decrypting the encrypted file by the processed JDK comprises:

    Reading the encrypted file from the hard disk;

    Determining, by the processed JDK, whether the read encrypted file is encrypted; and

    If the encrypted file is encrypted, the code decryption program is called by the call function in the processed JDK to decrypt the encrypted file.
19. A computer readable storage medium according to claim 15, wherein said source code protection program is used before said step of retrieving said encrypted file by said processed JDK and decrypting said file The steps are also implemented when the processor is executed:

    Obtaining whether the application corresponding to the encrypted file running in the JAVA virtual machine meets the preset identifier;

    Decrypting the encrypted file if the application corresponding to the encrypted file satisfies a preset identifier; and

    If the application corresponding to the encrypted file does not satisfy the preset identifier, the encrypted file is not decrypted.
20. A computer readable storage medium according to claim 17, wherein said source code protection program is used before said step of retrieving said encrypted file by said processed JDK and decrypting said file The steps are also implemented when the processor is executed:

    Obtaining whether the application corresponding to the encrypted file running in the JAVA virtual machine meets the preset identifier;

    Decrypting the encrypted file if the application corresponding to the encrypted file satisfies a preset identifier; and

    If the application corresponding to the encrypted file does not satisfy the preset identifier, the encrypted file is not decrypted.

Images