Bytecode encryption method and system based on Java Agent startup

Abstract

The invention relates to a byte code encryption method and system based on Java Agent startup, and the method comprises the steps: configuring encryption parameters in a Java project file specified by a user; decompressing an original JAR packet in the Java project file, encrypting a specified class file in the decompressed JAR packet according to the encryption parameter and a preset encryption algorithm, and retaining corresponding data according to a preset parameter type; a MANIFEST.MF file of the original JAR packet is modified, Java Agent information is added, and the Java Agent information is used for verifying passwords corresponding to the encryption parameters and decoding the passwords; and repackaging the encrypted class file into a JAR packet. The method has the effect of solving the problems of cross-platform characteristic loss and efficiency reduction in the Java code protection process.

Description

Technical Field

[0001] The present invention relates to the technical field of Java code protection, and in particular to a bytecode encryption method and system based on Java Agent startup. Background Art

[0002] Currently, code security and maintaining Java's natural cross-platform features are two important considerations in the development and distribution of Java applications.

[0003] In existing technical solutions, a common practice is to compile Java code into native machine code to improve security. However, this method will cause Java programs to lose their cross-platform advantages because the compiled machine code can only run on specific operating systems and hardware architectures. In addition, this compilation process often does not retain the naming of methods, which is an obvious limitation for developers who want to use the code as a third-party dependency library for other programs to call; For example, the process of compiling Java source code or bytecode into native machine code for a specific operating system through a compiler usually includes the following steps: 1. Source code analysis: The compiler parses the source code and builds an abstract syntax tree (AST); 2. Code optimization: The compiler optimizes AST, deletes redundant code, and improves execution efficiency; 3. Target code generation: The compiler converts the optimized AST into machine code for the target platform; The limitation of this technique is that the generated machine code loses the cross-platform nature of Java and can only run on specific operating systems or hardware. On the Java platform, an example of this method is through the use of the GNU Compiler for Java (GCJ) compiler, but due to the lack of cross-platform support, it is no longer a recommended solution.

[0004] Another existing technology is that developers use other programming languages ​​to write a Java launcher, which decodes the encoded Java class when the program starts. Although this method can maintain a certain degree of cross-platform characteristics, it usually faces efficiency issues. Since the decoding process outside the Java virtual machine involves interaction with the underlying operating system, this cross-language solution may not be as efficient as a pure Java solution when operating memory. In addition, the introduction of non-Java languages ​​may also cause new cross-platform compatibility issues, because different operating systems may have different levels of support for non-Java languages; For example, a launcher technology written in other programming languages: a launcher for a Java application written in C / C++ or other languages ​​is responsible for decoding the encrypted class file when the application is started. This process usually involves the following steps: 1. Class file encryption: Java class files are encrypted using a specific algorithm before packaging; 2. Launcher writing: Write a program in C / C++ or other languages ​​that loads the encrypted class file into memory when it is started; 3. Decoding and execution: The launcher decodes the class file in the memory and passes the decoded class file to the Java virtual machine for execution; Although this technique maintains a certain degree of cross-platform compatibility, it is less efficient in terms of memory operations and code decoding, and introduces additional cross-platform compatibility issues. Summary of the invention

[0005] In order to solve the problem of cross-platform feature loss and efficiency reduction in the Java code protection process, the present application provides a bytecode encryption method and system based on Java Agent startup.

[0006] In the first aspect, the above-mentioned invention objective of the present application is achieved through the following technical solutions: A bytecode encryption method based on Java Agent startup, the bytecode encryption method based on Java Agent startup comprising: Configure encryption parameters in the Java project file specified by the user; Decompressing the original JAR package in the Java project file, encrypting the specified class file in the decompressed JAR package according to the encryption parameters according to a preset encryption algorithm, and retaining corresponding data according to the preset parameter type; By modifying the MANIFEST.MF file of the original JAR package, Java Agent information is added, and the JavaAgent information is used to verify the password and decode the encrypted parameters; Repackage the encrypted class files into a JAR package.

[0007] By adopting the above technical solution, users are allowed to flexibly configure encryption parameters in Java project files, including selecting class files to be encrypted, setting encryption algorithms and their parameters, etc., so that it can be applied to projects with different security requirements, providing users with a high degree of customization. By encrypting the specified class files through a preset encryption algorithm, direct leakage of source code and unauthorized access are effectively prevented, ensuring the security of the core logic. Even if the JAR package is illegally obtained, it is difficult for attackers to directly understand or modify the encrypted bytecode, thereby greatly improving the overall security of the software system. By modifying the MANIFEST.MF file of the JAR package and embedding the Java Agent information, seamless integration of the encryption and decryption processes is achieved. When the Java virtual machine is started, Java The Agent can automatically load and execute, ensuring efficient execution performance and simplifying the code protection workflow. It verifies the password and decodes the encrypted class file according to the encryption parameters, so that the encrypted JAR package can work normally at runtime just like before encryption. It is almost completely transparent to users and applications. The agent mechanism is used for decoding, which maintains the cross-platform characteristics while effectively avoiding performance and compatibility issues. During the encryption process, the corresponding data is retained according to the preset parameter type, ensuring that the encryption operation will not affect the necessary metadata and execution environment information in the class file, such as class name, method signature, field information, etc., ensuring that the encrypted class file can still be correctly loaded and executed by the Java virtual machine.

[0008] In a preferred example, the present application can be further configured as follows: the encryption parameters include an encryption password, a time limit, hardware binding, and remote control parameters.

[0009] By adopting the above technical solution, the encryption password is used as the basic access control method to ensure that only users or systems holding the correct password can decrypt and execute the encrypted code. The introduction of the time limit parameter realizes the precise control of the software usage time, effectively preventing the software from being used overtime or illegally extending the usage period. In addition, the hardware binding parameters further limit the scope of software use by associating the software operation with specific hardware devices, enhancing the security and anti-copying capabilities of the software. Through the configuration of remote control parameters, the administrator can remotely monitor, update or revoke the authorization status of the encrypted software, realizing flexible management of software authorization, which not only improves the efficiency of software maintenance, but also enables software vendors to respond quickly to market changes and adjust authorization strategies to meet the needs of different users.

[0010] In a preferred example, the present application may be further configured as follows: the decompressing the original JAR package in the Java project file includes: Unzip the original JAR package in the Java project file and create a temporary directory.

[0011] The step of encrypting the specified class file in the decompressed JAR package according to the encryption parameter includes: According to the specified package path in the encryption parameter, the temporary directory is queried, and the corresponding temporary directory is traversed according to the query result to find all class files under the specified package path.

[0012] By adopting the above technical solution and specifying the package path as part of the encryption parameters, the location of the class files that need to be encrypted can be accurately located, avoiding the performance loss and unnecessary complexity caused by indiscriminate encryption, and ensuring the pertinence and efficiency of the encryption operation. In the decompressed JAR package, by establishing a temporary directory and traversing and searching for class files according to the specified package path, the target class files can be quickly located and processed. Compared with a full disk scan, it is more efficient and can significantly shorten the encryption processing time and improve the overall processing efficiency. By specifying the package path as an encryption parameter, users or developers can flexibly select the range of class files that need to be encrypted according to their needs, which not only meets the differences in encryption requirements of different projects, but also enables the encryption strategy to be flexibly adjusted as the project develops. In a complex Java project, there may be a large number of non-core or non-encrypted class files. By specifying the package path for encryption, it can be ensured that only key or sensitive class files are encrypted, avoiding unnecessary encryption operations and potential impact on program performance.

[0013] In a preferred example, the present application can be further configured as follows: the step of encrypting the specified class file in the decompressed JAR package according to the encryption parameters according to a preset encryption algorithm includes: According to the specified package path in the encryption parameter, query the decompressed JAR package and traverse all class files corresponding to the specified package path; All class files under the specified package path are encrypted according to a preset encryption algorithm, and corresponding data is retained according to a preset parameter type.

[0014] By adopting the above technical solution, the specified package path can go deep into the internal structure of the Java project and accurately lock the set of class files that need to be encrypted. Subsequently, the preset encryption algorithm is used to encrypt these class files, ensuring the pertinence and depth of the encryption operation, and effectively preventing the leakage of sensitive information. During the encryption process, not only the encryption of the class file content is focused on, but also the corresponding data is retained according to the preset parameter type to ensure that the encrypted class file can maintain the original functional logic while being compatible with the original data type and interface, reducing the compatibility issues introduced by encryption, ensuring data integrity and system stability, and by first querying the class files under the specified package path and then encrypting them, the performance loss caused by indiscriminate encryption of the entire JAR package is avoided. At the same time, the preset encryption algorithm is optimized and selected to ensure encryption strength while improving the efficiency of encryption processing and reducing the occupation of system resources.

[0015] In a preferred example, the present application can be further configured as follows: in the decompressed JAR package, the specified class file is encrypted according to the encryption parameter according to a preset encryption algorithm, and the corresponding data is retained according to the preset parameter type, including: Use the preset ASM library to modify the original class file, retaining the method name, input parameters and return value; In the decompressed JAR package, the specified class file is encrypted according to the encryption parameters according to a preset encryption algorithm, and is stored in another file after encryption.

[0016] By adopting the above technical solution, the ASM library has the ability of efficient bytecode processing. Through the ASM library, the specified class file can be quickly encrypted while retaining the necessary information, reducing the intermediate conversion steps, improving the encryption efficiency, and reducing the occupation of system resources. When using the ASM library to modify the original class file, it is important to retain key information such as method name, input parameters and return value to ensure that the encrypted class file is consistent with the original class file at the interface level, thereby maintaining the compatibility of the API, so that the encrypted Java project can be seamlessly integrated into the existing system, while reducing the complexity of subsequent maintenance; by directly operating the bytecode through the ASM library, Developers can clearly see which parts are modified and which data are retained, thereby improving the transparency of the encryption process. In addition, since the ASM library provides a wealth of APIs, developers can flexibly adjust encryption strategies as needed, enhancing the controllability of the encryption process; encrypting the specified class file through a preset encryption algorithm and storing the encrypted file in another location effectively hides the true content of the original class file, increasing the difficulty for attackers to crack it. At the same time, due to the diversity and complexity of the encryption algorithm, even if the attacker obtains the encrypted file, it is difficult to easily restore the original code, thereby enhancing the security and concealment of encryption.

[0017] In a preferred example, the present application can be further configured as follows: the preset encryption algorithm includes: Extracting custom encryption information from the encryption parameters; For the designated class file according to the encryption parameter, encrypt according to the custom encryption information to obtain the target encrypted file; Encrypting the files in the decompressed JAR package except for the specified class files according to the encryption parameters by using an obfuscated encryption method to obtain a first obfuscated encrypted file and a second obfuscated encrypted file; Performing logical encryption on the target encrypted file and the first obfuscated encrypted file, or on the target encrypted file and the second obfuscated encrypted file, to obtain a mixed encrypted file; A character string constant is written into the mixed encrypted file.

[0018] By adopting the above technical solution, the custom encryption information in the encryption parameters is extracted. The custom encryption information allows users or developers to customize it according to actual needs, and can include specific encryption algorithms, keys, encryption strengths, etc., thereby achieving flexibility and personalization of the encryption process, enhancing the security of encryption, and enabling the encryption strategy to be flexibly adjusted as project requirements change. For designated class files based on encryption parameters, custom encryption information is used for precise encryption to ensure the security of key codes and data. At the same time, for non-designated class files, obfuscated encryption is used to further increase the difficulty for attackers to analyze and understand the code. The hybrid strategy of precise encryption and obfuscated encryption not only ensures the security of key information, but also improves the security of the entire JAR package. Security protection level; by introducing logical encryption steps, the target encrypted file and the obfuscated encrypted file are further processed to generate a hybrid encrypted file. Logical encryption may involve the rearrangement of the file structure, data organization or execution process, making the encrypted file more logically complex and difficult to be directly parsed or reverse engineered. In addition, writing string constants to the hybrid encrypted file further increases the randomness and unpredictability of the file content, thereby increasing the complexity of encryption and the difficulty of cracking. In addition, although a variety of encryption methods are used, while retaining key information (such as method names, input parameters and return values, etc.), it also ensures that the encrypted code is readable and maintainable to a certain extent, which is of great significance for subsequent code debugging, upgrading and maintenance.

[0019] In the second aspect, the above invention objective of the present application is achieved through the following technical solutions: A bytecode encryption system based on Java Agent startup, the bytecode encryption system based on Java Agent startup comprising: The encryption parameter configuration module is used to configure encryption parameters in the Java project file specified by the user; An encryption module, used to decompress the original JAR package in the Java project file, encrypt the specified class file in the decompressed JAR package according to the encryption parameters according to a preset encryption algorithm, and retain corresponding data according to a preset parameter type; An Agent adding module, used to add JavaAgent information by modifying the MANIFEST.MF file of the original JAR package, wherein the Java Agent information is used to verify the password corresponding to the encrypted parameter and decode it; The packaging module is used to repackage the encrypted class files into a JAR package.

[0020] Optionally, the encryption parameters include an encryption password, a time limit, hardware binding and remote control parameters.

[0021] In the third aspect, the above invention objective of the present application is achieved through the following technical solutions: A computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the bytecode encryption method based on Java Agent startup are implemented.

[0022] In a fourth aspect, the above-mentioned invention objective of the present application is achieved through the following technical solutions: A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the bytecode encryption method based on Java Agent startup are implemented.

[0023] In summary, the present application includes at least one of the following beneficial technical effects: 1. Allow users to flexibly configure encryption parameters in Java project files, including selecting class files to be encrypted, setting encryption algorithms and their parameters, etc., so that it can be applied to projects with different security requirements, providing users with a high degree of customization. Encrypting specified class files through a preset encryption algorithm effectively prevents direct leakage of source code and unauthorized access, ensuring the security of core logic. Even if the JAR package is illegally obtained, it is difficult for attackers to directly understand or modify the encrypted bytecode, thereby greatly improving the overall security of the software system. By modifying the MANIFEST.MF file of the JAR package and embedding Java Agent information, the encryption and decryption process is seamlessly integrated. When the Java virtual machine is started, Java Agent can automatically load and execute, ensuring efficient execution performance and simplifying the workflow of code protection. It verifies the password and decodes the encrypted class file according to the encryption parameters, so that the encrypted JAR package can work normally at runtime as before encryption. It is almost completely transparent to users and applications. The use of the agent mechanism for decoding maintains the cross-platform feature while effectively avoiding performance and compatibility issues. In the encryption process, the corresponding data is retained according to the preset parameter type, ensuring that the encryption operation will not affect the necessary metadata and execution environment information in the class file, such as class name, method signature, field information, etc., ensuring that the encrypted class file can still be correctly loaded and executed by the Java virtual machine; 2. Encryption passwords, as a basic means of access control, ensure that only users or systems holding the correct passwords can decrypt and execute the encrypted code. The introduction of time limit parameters enables precise control of software usage time, effectively preventing software overtime or illegal extension of usage period. In addition, hardware binding parameters further limit the scope of software use by associating software operation with specific hardware devices, enhancing the security and anti-copying capabilities of the software. Through the configuration of remote control parameters, administrators can remotely monitor, update or revoke the authorization status of encryption software, achieving flexible management of software authorization, which not only improves the efficiency of software maintenance, but also enables software vendors to quickly respond to market changes and adjust authorization policies to meet the needs of different users. 3. Specifying the package path as part of the encryption parameters can accurately locate the location of the class files that need to be encrypted, avoiding the performance loss and unnecessary complexity caused by indiscriminate encryption, and ensuring the pertinence and efficiency of the encryption operation. In the decompressed JAR package, by establishing a temporary directory and traversing the specified package path to find the class files, the target class files can be quickly located and processed. Compared with a full disk scan, it is more efficient and can significantly shorten the encryption processing time and improve the overall processing efficiency. Specifying the package path as an encryption parameter allows users or developers to flexibly select the range of class files that need to be encrypted as needed, which not only meets the differences in encryption requirements of different projects, but also enables the encryption strategy to be flexibly adjusted as the project develops. In complex Java projects, there may be a large number of non-core or non-encrypted class files. By encrypting by specifying the package path, it can ensure that only key or sensitive class files are encrypted, avoiding unnecessary encryption operations and potential impact on program performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a flow chart of the implementation of the bytecode encryption method based on Java Agent startup in the embodiment of the present application; Figure 2 It is a first implementation flow chart of S20 of the bytecode encryption method started based on Java Agent in the embodiment of the present application; Figure 3 It is a second implementation flow chart of S20 of the bytecode encryption method started based on Java Agent in the embodiment of the present application; Figure 4 It is a third implementation flow chart of S20 of the bytecode encryption method started based on Java Agent in the embodiment of the present application; Figure 5 It is a flowchart of the implementation of the encryption algorithm preset in the embodiment of the present application; Figure 6 It is a principle block diagram of a bytecode encryption system started based on Java Agent in an embodiment of the present application; Figure 7 It is a diagram of the internal structure of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The following is combined with Figure 1-7 This application is described in further detail.

[0026] In one embodiment, if Figure 1 As shown, the present application discloses a bytecode encryption method based on Java Agent startup, which specifically includes the following steps: S10: In the Java project file specified by the user, configure encryption parameters.

[0027] In this embodiment, the bytecode encryption method based on Java Agent startup is applied to a Java code protection tool implemented in the form of a Maven plug-in, which can be named ByteGuard.

[0028] Specifically, a class source code file is a file containing Java source code, usually with .java as the file extension, and contains the definition of a Java class, including the class's attributes (fields), methods, and constructors. Java source code is written in the Java programming language and follows Java's syntax rules, while a class bytecode file is a file generated after the Java source code file is compiled, usually with .class as the file extension, and contains instructions that can be directly executed by the Java Virtual Machine (JVM). Bytecode is an intermediate code that is neither machine code (directly executed by the computer's CPU) nor high-level language code (such as Java source code). The ByteGuard tool encrypts and protects class bytecode files; Therefore, before the implementation of project protection, for the Java project files specified by the user, the Java project files specified by the user in the form of class source code files will be converted into Java project files in the form of class bytecode files. The process of converting class source code files into class bytecode files can be completed by the Java compiler (javac). In the ByteGuard tool, users can be allowed to customize some encryption parameters, for example, including encryption passwords, time limits, hardware binding, remote control, etc., where the encryption password is the password used to encrypt the Java project files, the time limit is used to limit the running time of the code, the hardware binding is used to determine the hardware device, and the remote control is used to define the IP address and port of the remote control host. Functions such as time limits and hardware binding enable code providers to monitor and control the use of their software to prevent unauthorized copying and use. In addition, by providing flexible configuration parameters, ByteGuard allows users to customize security policies according to specific needs, thereby enhancing code security in multiple dimensions such as hardware binding, effective time limits, and remote control. And because ByteGuard is integrated into the build process as a Maven plug-in, it simplifies the deployment and operation process, and users do not need to perform complex configurations or manually handle encryption and decryption steps.

[0029] Furthermore, the ByteGuard plug-in can be introduced into the pom file of the Java project file specified by the user, and the required encryption parameters can be configured.

[0030] S20: decompressing the original JAR package in the Java project file, encrypting the specified class file in the decompressed JAR package according to the encryption parameters according to the preset encryption algorithm, and retaining the corresponding data according to the preset parameter type.

[0031] Specifically, before the JAR package is decompressed, it is a compressed package containing multiple Java class files (.class files), resource files, and metadata (such as the MANIFEST.MF file). These class files are bytecode files generated after the Java source code file (.java file) is compiled by the Java compiler (javac). The JAR package uses the ZIP compression format, but has an additional META-INF folder compared to ordinary ZIP files, which is used to store the metadata information of the JAR package. When compressed, encryption operations cannot be performed. Therefore, the original JAR package in the Java project file, that is, the original JAR package in the Java project file in the form of a class bytecode file, is decompressed. At this time, the user-defined encryption parameters include the class file information specified by the user for encryption. Therefore, according to the class file information specified by the user in the encryption parameters, in the decompressed JAR In addition, the corresponding data is retained according to the preset parameter type, such as class definition, fields, methods, method names, input parameters, return values, etc., that is, the file data of the corresponding preset parameter type is not encrypted; based on this, ByteGuard achieves encryption protection while retaining the cross-platform characteristics of Java code, which is something that the traditional compilation to local machine code method cannot provide. Users do not need to worry that code protection will limit their software to run only on a specific operating system. ByteGuard retains method naming during the encryption process, so that the encrypted code can still be easily called by other projects as a third-party dependency, which is extremely important for the open source community and modular programming. ByteGuard uses compile-time encryption rather than runtime decryption, which effectively reduces the performance overhead of the software runtime and improves the execution efficiency of the application.

[0032] In this embodiment, the preset encryption algorithm may be a symmetric encryption algorithm, an asymmetric encryption algorithm, or an obfuscated encryption algorithm.

[0033] Furthermore, when encrypting a specified class file, only the method body in the class file can be encrypted, because a Java class file is a binary file generated by the Java compiler (javac) after compiling the Java source code, and contains all the information required for the Java program to run, such as class definitions, fields, methods, and method implementations (i.e., method bodies). Encrypting a class file means that the contents of the entire file (including method bodies, field information, etc.) are encrypted, making it impossible for unauthorized readers to directly understand or modify the contents of these files. This usually results in the Java virtual machine (JVM) being unable to directly load and execute these encrypted class files, because the JVM expects class files to be unencrypted binary data that conforms to a specific format.

[0034] S30: by modifying the MANIFEST.MF file of the original JAR package, adding Java Agent information, the Java Agent information is used to verify the password and decode the corresponding encrypted parameters.

[0035] Specifically, the JAR (Java ARchive) file is a standard format used by the Java platform to package multiple class files, related metadata, and resource files (such as text, images, etc.). It allows these files to be compressed into one file for easy distribution and deployment. Therefore, by modifying the MANIFEST.MF file of the original JAR package and adding Java Agent information, ByteGuard uses the agent mechanism to decrypt inside the Java virtual machine at runtime through JavaAgent, ensuring efficient execution performance while simplifying the code protection workflow. In addition, ByteGuard uses the agent mechanism to dynamically load encrypted class files at runtime and decrypt them in memory, achieving unaware protection of the original code execution. This mechanism not only avoids complex operations directly on the source code or bytecode, but also improves the security of the software at runtime.

[0036] Furthermore, ByteGuard also supports web-based online authorization and encryption management.

[0037] In addition, as an alternative to Java Agent, you can consider: 1. Custom class loader: Implement a custom class loader that is specifically responsible for loading and decrypting class files without modifying MANIFEST.MF.

[0038] 2. Hooking at startup: When the virtual machine is started, a native library is hooked through the specified Java option (such as -agentlib) to be responsible for decryption operations; In addition to hardware binding and time control, the following alternatives to authorization verification can be used for authorization verification: 1. Online authorization check: Real-time authorization verification of software instances through network services to ensure that only authorized users can use the software.

[0039] 2. License file: Use a digitally signed license file to authorize software use. The license can contain user information, validity period, etc.

[0040] S40: repackage the encrypted class files into a JAR package.

[0041] Specifically, after the encryption of the specified class file is completed, the encrypted class file is repackaged into a JAR package.

[0042] Furthermore, at startup, ByteGuard's Java Agent verifies the password and decodes the method body to ensure that it can only run under the correct password and hardware environment.

[0043] In this embodiment, the ByteGuard tool can effectively solve the problems existing in the field of code protection, such as configuration complexity, connection stability, performance overhead and compatibility issues. Moreover, ByteGuard is easy to use and easy to integrate, and can be seamlessly embedded into the existing Java development and deployment process. The main application scenarios of ByteGuard tools include but are not limited to: 1. Code protection for enterprise-level applications: Applicable to enterprise software products that need to protect business logic and intellectual property rights; 2. Software projects of individual developers: Help individual developers prevent their innovative achievements from being easily copied or leaked; 3. Educational and scientific research institutions: When conducting software development and research, protect research results from being accessed by unauthorized third parties; The ByteGuard tool is suitable for any situation where Java development is used and code security is improved. ByteGuard's natural support for Maven projects makes ByteGuard widely used in Java projects of different sizes, including but not limited to financial services, medical information systems, e-commerce platforms, and any application that requires a high degree of code confidentiality.

[0044] In one embodiment, the encryption parameters include encryption passwords, time limits, hardware binding, and remote control parameters.

[0045] Specifically, encryption parameters include encryption passwords, time limits, hardware binding, and remote control parameters; For example, ByteGuard's main parameters include: - `password`: Encryption password, default is `cfasy`.

[0046] - `startTime` and `endTime`: define the time interval in which the code can run.

[0047] - `biosMark`: CPU serial number, used for hardware binding.

[0048] - `availableTime`: The remaining available time, used to limit the running time of the code.

[0049] - `libs`, `packages`, `excludes`: define the dependent libraries, package paths and exclusion paths that need to be encrypted.

[0050] - `host` and `port`: The IP address and port of the remote control host.

[0051] - `explain`: Project description.

[0052] - `isDebug`: whether to enable Debug mode.

[0053] - `rsaPublicKey`: Remote control public key.

[0054] - `relyLibPath`: external lib dependency.

[0055] By providing this series of configuration parameters, ByteGuard provides a flexible and powerful code protection mechanism for Java projects, solving the problems existing in existing technical solutions without negatively affecting the cross-platform characteristics and execution efficiency of Java itself.

[0056] Furthermore, ByteGuard can manage configuration parameters in different ways, for example: 1. Command line parameters: Allow users to pass configuration parameters directly through the command line when executing Maven builds.

[0057] 2. External configuration file: Supports the use of external configuration files (such as JSON or YAML files) to provide encryption parameters to replace or supplement the configuration in pom.xml.

[0058] In one embodiment, if Figure 2 As shown, in step S20, the original JAR package in the Java project file is decompressed, including: S201: Decompress the original JAR package in the Java project file and create a temporary directory.

[0059] Specifically, in order to access the class files and other resources inside the JAR package in order to encrypt or otherwise process them, ByteGuard decompresses the original JAR package into a temporary directory.

[0060] In the decompressed JAR package, the specified class files are encrypted according to the encryption parameters, including: S202: According to the specified package path in the encryption parameter, query the temporary directory, traverse the corresponding temporary directory according to the query result, and find all class files under the specified package path.

[0061] Specifically, after unpacking the JAR package, the ByteGuard plug-in will search for the package path specified by the user in the configured encryption parameters. The package path defines which Java packages (that is, class files in which directories) need to be encrypted. Users can specify these paths in the ByteGuard plug-in configuration to precisely control which code needs to be protected. For example, if the user wants to encrypt all class files under the com.example.myapp package, specify this package path in the ByteGuard plug-in configuration. Then, the ByteGuard plug-in will traverse the decompressed temporary directory, find and process all class files under this package path, thereby ensuring that only the code part that the user wants to protect is encrypted without affecting other code or resources that do not need to be protected.

[0062] In one embodiment, if Figure 3 As shown, in step S20, the specified class file is encrypted according to the encryption parameters in the decompressed JAR package according to the preset encryption algorithm, including: S211: According to the specified package path in the encryption parameter, query the decompressed JAR package and traverse all class files under the corresponding specified package path.

[0063] Specifically, according to the specified package path in the encryption parameter, the decompressed JAR package is queried, and all class files under the corresponding specified package path are traversed.

[0064] S212: Encrypt all class files under the specified package path according to a preset encryption algorithm, and retain corresponding data according to a preset parameter type.

[0065] Specifically, all class files under the specified package path are encrypted according to a preset encryption algorithm, and corresponding data is retained according to a preset parameter type; in addition, the method bodies in all class files under the specified package path can also be encrypted according to a preset encryption algorithm. The class bytecode file (usually with a .class suffix) is a file generated by the Java compiler (javac) after compiling the Java source code file. This file contains all the information required for the Java program to run, including class definitions, fields, methods, and bytecode instructions in the method body, etc. The method body is a core concept in programming, which refers to a code block containing code instructions for performing specific tasks. In object-oriented programming languages ​​such as Java, the method body is defined after the method name and is surrounded by a pair of curly brackets {}. It contains all the code that implements the method function and is an important part of the class bytecode file. Therefore, only the method body content is encrypted and the method name is retained. In combination with the encryption algorithm and the custom password policy, a powerful code encryption function is achieved.

[0066] In this embodiment, the structure of the class bytecode file can be roughly divided into the following parts: Magic Number: 4 bytes at the beginning of the file, used to identify the file as a Java class file, and its value is 0xCAFEBABE; Version information: The 4 bytes following the magic number represent the minor and major version numbers of the JDK used to compile the file. Constant Pool: used to store various literals and symbol references generated during compilation; Access Flags: Indicates the access level and characteristics of the class or interface; Class index, parent class index and interface index collection: point to the constant items in the constant pool that represent the fully qualified name of the class, the fully qualified name of the parent class and the fully qualified name of the implemented interface respectively; Fields: describes the fields declared in the class; Methods: describes the methods declared in a class. Each method table entry contains a constant entry reference pointing to the method name in the constant pool, as well as information such as the method's access flag, descriptor, and attribute table. Among them, the attribute table is an important part of the method table, which can contain multiple types of attributes, the most important of which is the Code attribute; The Code attribute is an attribute in the method table. It contains all the bytecode instructions in the method body and related auxiliary information (such as the maximum depth of the operand stack, the capacity of the local variable table, etc.). Therefore, it can be said that the code in the method body is converted into bytecode instructions after compilation and stored in the Code attribute of the class bytecode file.

[0067] In one embodiment, if Figure 4 As shown, in step S20, the specified class file is encrypted according to the preset encryption algorithm based on the encryption parameters in the decompressed JAR package, and the corresponding data is retained according to the preset parameter type, including: S221: Use the preset ASM library to modify the original class file and retain the method name, input parameters, and return value.

[0068] Specifically, ASM is a Java bytecode manipulation and analysis framework that allows Java class files to be read, modified, and generated programmatically. ASM provides a lower-level access capability than the Java reflection API, allowing direct manipulation of bytecode instructions. Therefore, in order to encrypt or modify specific parts of a class file without directly encrypting the entire class file, the preset ASM library is used to modify the original class file, that is, to retain the method name, input parameters, and return value so that these parameters will not be encrypted.

[0069] S222: Encrypt the designated class file in the decompressed JAR package according to the encryption parameters using a preset encryption algorithm, and store the encrypted file in another file.

[0070] Specifically, in the decompressed JAR package, the specified class file is encrypted according to the preset encryption algorithm based on the encryption parameters, and the method body content in the specified class file can also be encrypted according to the preset encryption algorithm based on the encryption parameters, and stored in another file after encryption, so that the encrypted class file part and the retained method name, input parameters and return value parts will be in different files.

[0071] In this embodiment, ByteGuard uses the AES algorithm for encryption by default, and the following alternative encryption algorithms can be considered: 1. DES / 3DES: As an alternative to AES, DES or its more secure variant 3DES can be used to encrypt class files. Although it may be slower than AES, it still has a certain degree of security.

[0072] 2. Blowfish / Twofish: These algorithms are known for their block encryption strength and efficiency and can also be used as an alternative to AES.

[0073] 3. Public key encryption algorithm: Using asymmetric encryption algorithms, such as RSA or ElGamal, can enhance the security of key management, although it has a greater impact on performance.

[0074] In one embodiment, if Figure 5 As shown, the preset encryption algorithms include: S01: Extract custom encryption information from encryption parameters.

[0075] Specifically, the custom encryption information in the encryption parameters, that is, the encryption password, is extracted.

[0076] S02: Encrypting a specified class file according to encryption parameters according to custom encryption information to obtain a target encrypted file.

[0077] Specifically, for the specified class files according to the encryption parameters, that is, the class files under the package path specified by the user, the custom encryption information is used to encrypt, that is, the custom encryption strategy is used to encrypt, and the target encrypted file is obtained. The target encrypted file represents the encrypted file corresponding to the user-defined encryption target.

[0078] In this embodiment, only the method body content in the class file is encrypted.

[0079] S03: Encrypting the files in the decompressed JAR package except for the class files specified according to the encryption parameters by using an obfuscated encryption method to obtain a first obfuscated encrypted file and a second obfuscated encrypted file.

[0080] Specifically, for files in the decompressed JAR package except for the specified class files according to the encryption parameters, that is, in the decompressed JAR package, other class files except the class files under the package path specified by the user are encrypted by using an obfuscation encryption method to obtain a first obfuscated encrypted file and a second obfuscated encrypted file. The first obfuscated encrypted file and the second obfuscated encrypted file refer to encrypted files after obfuscating and encrypting different class files. For example, in the decompressed JAR package, other class files except the class files under the package path specified by the user are divided into two parts, which can be evenly divided, and then the two parts of class files or the method bodies in the class files are encrypted respectively by two different obfuscation encryption methods to obtain the first obfuscated encrypted file and the second obfuscated encrypted file.

[0081] In this embodiment, in addition to using ASM to operate the bytecode for obfuscation encryption, ByteGuard can use the following obfuscation methods as alternatives: 1. Control flow obfuscation: obfuscates the program by changing the execution logic of the code, making reverse engineering more difficult.

[0082] 2. Instruction replacement: Replace common instructions with instructions that have similar performance but different appearance, increasing the difficulty of reverse engineering.

[0083] S04: Performing logical encryption on the target encrypted file and the first obfuscated encrypted file, or the target encrypted file and the second obfuscated encrypted file, to obtain a mixed encrypted file.

[0084] Specifically, logical encryption is performed on the target encrypted file and the first obfuscated encrypted file, or the target encrypted file and the second obfuscated encrypted file, that is, the first obfuscated encrypted file or the second obfuscated encrypted file that is obfuscated and encrypted in different ways can be randomly selected and mixed with the target encrypted file for secondary encryption. Such randomness increases the randomness of the encryption, and the secondary encryption further improves the strength of the encryption, thereby obtaining a mixed encrypted file after logical encryption of the target encrypted file and the first obfuscated encrypted file, or a mixed encrypted file after logical encryption of the target encrypted file and the second obfuscated encrypted file.

[0085] In this embodiment, the logic encryption may be performed using an RSA algorithm.

[0086] S05: Write a string constant to the mixed encryption file.

[0087] Specifically, string constants are written to the hybrid encrypted file, for example, string constants (i.e., fixed text values ​​used directly in the program) are embedded or written into the code, configuration files, databases, or other storage media. In Java, string constants are text sequences surrounded by double quotes, which can be any combination of letters, numbers, symbols, etc. The string constants here can include user-defined string constants.

[0088] In this way, the hybrid encrypted file that completes the writing of string constants is packaged together with the unencrypted reserved method name, input parameters, return value and other data files.

[0089] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0090] In one embodiment, a bytecode encryption system based on Java Agent startup is provided, and the bytecode encryption system based on Java Agent startup corresponds one-to-one to the bytecode encryption method based on Java Agent startup in the above embodiment. Figure 6 As shown, the bytecode encryption system based on Java Agent startup includes encryption parameter configuration module, encryption module, Agent joining module and packaging module. The detailed description of each functional module is as follows: The encryption parameter configuration module is used to configure encryption parameters in the Java project file specified by the user; The encryption module is used to decompress the original JAR package in the Java project file, encrypt the specified class file in the decompressed JAR package according to the encryption parameters according to the preset encryption algorithm, and retain the corresponding data according to the preset parameter type; The Agent adding module is used to add Java Agent information by modifying the MANIFEST.MF file of the original JAR package. The Java Agent information is used to verify the password and decode the corresponding encrypted parameters; The packaging module is used to repackage the encrypted class files into a JAR package.

[0091] Optionally, encryption parameters include encryption password, time limit, hardware binding, and remote control parameters.

[0092] Optionally, the encryption module includes: Create a submodule in a temporary directory, decompress the original JAR package in the Java project file and create a temporary directory; The directory-specified encryption submodule is used to query the temporary directory according to the specified package path in the encryption parameters, traverse the corresponding temporary directory according to the query results, and find all class files under the specified package path.

[0093] Optionally, the encryption module also includes: Specify a query submodule, which is used to query the decompressed JAR package according to the specified package path in the encryption parameter, and traverse all class files under the corresponding specified package path; The specified encryption submodule is used to encrypt all class files under the specified package path according to the preset encryption algorithm, and retain the corresponding data according to the preset parameter type.

[0094] Optionally, the encryption module also includes: The parameter preservation submodule is used to modify the original class file using the preset ASM library to preserve the method name, input parameters and return value; The multi-file encryption submodule is used to encrypt the specified class files in the decompressed JAR package according to the encryption parameters according to the preset encryption algorithm, and store them in another file after encryption.

[0095] Optionally, the bytecode encryption system started based on the Java Agent also includes: An encryption information extraction module is used to extract custom encryption information from encryption parameters; The target encryption module is used to encrypt the specified class files according to the encryption parameters according to the custom encryption information to obtain the target encrypted file; The obfuscated encryption module is used to encrypt the files in the decompressed JAR package except the specified class files according to the encryption parameters by using the obfuscated encryption method to obtain the first obfuscated encrypted file and the second obfuscated encrypted file; A hybrid encryption module, used for performing logical encryption on a target encrypted file and a first obfuscated encrypted file, or a target encrypted file and a second obfuscated encrypted file, to obtain a hybrid encrypted file; The always-on write module is used to write string constants to the hybrid encrypted file.

[0096] For the specific limitations of the bytecode encryption system based on Java Agent startup, please refer to the limitations of the bytecode encryption method based on Java Agent startup above, which will not be repeated here. Each module in the above-mentioned bytecode encryption system based on Java Agent startup can be implemented in whole or in part through software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0097] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 7 As shown. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store encryption parameters and preset encryption algorithms, etc. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a bytecode encryption method based on Java Agent startup is implemented.

[0098] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program: Configure encryption parameters in the Java project file specified by the user; Decompress the original JAR package in the Java project file, encrypt the specified class file in the decompressed JAR package according to the encryption parameters according to the preset encryption algorithm, and retain the corresponding data according to the preset parameter type; By modifying the MANIFEST.MF file of the original JAR package, add Java Agent information, which is used to verify the password and decode the corresponding encrypted parameters; Repackage the encrypted class files into a JAR package.

[0099] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented: Configure encryption parameters in the Java project file specified by the user; Decompress the original JAR package in the Java project file, encrypt the specified class file in the decompressed JAR package according to the encryption parameters according to the preset encryption algorithm, and retain the corresponding data according to the preset parameter type; By modifying the MANIFEST.MF file of the original JAR package, add Java Agent information, which is used to verify the password and decode the corresponding encrypted parameters; Repackage the encrypted class files into a JAR package.

[0100] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0101] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0102] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A bytecode encryption method based on Java Agent startup, It is characterized in that The bytecode encryption method based on Java Agent startup includes: Configure encryption parameters in the Java project file specified by the user; Decompressing the original JAR package in the Java project file, encrypting the specified class file in the decompressed JAR package according to the encryption parameters according to a preset encryption algorithm, and retaining corresponding data according to the preset parameter type; By modifying the MANIFEST.MF file of the original JAR package, Java Agent information is added, and the Java Agent information is used to verify the password and decode the encrypted parameters; Repackage the encrypted class files into a JAR package.

2. The bytecode encryption method based on Java Agent startup according to claim 1, It is characterized in that The encryption parameters include encryption password, time limit, hardware binding and remote control parameters.

3. The bytecode encryption method based on Java Agent startup according to claim 1, It is characterized in that The decompressing the original JAR package in the Java project file includes: Decompress the original JAR package in the Java project file and create a temporary directory; The step of encrypting the specified class file in the decompressed JAR package according to the encryption parameter includes: According to the specified package path in the encryption parameter, the temporary directory is queried, and the corresponding temporary directory is traversed according to the query result to find all class files under the specified package path.

4. The bytecode encryption method based on Java Agent startup according to claim 1, It is characterized in that The step of encrypting the specified class file in the decompressed JAR package according to the encryption parameters using a preset encryption algorithm includes: According to the specified package path in the encryption parameter, query the decompressed JAR package and traverse all class files corresponding to the specified package path; All class files under the specified package path are encrypted according to a preset encryption algorithm, and corresponding data is retained according to a preset parameter type.

5. The bytecode encryption method based on Java Agent startup according to claim 1, It is characterized in that The method of encrypting the specified class file according to the encryption parameter in the decompressed JAR package according to a preset encryption algorithm and retaining corresponding data according to the preset parameter type includes: Use the preset ASM library to modify the original class file, retaining the method name, input parameters and return value; In the decompressed JAR package, the specified class file is encrypted according to the encryption parameters according to a preset encryption algorithm, and is stored in another file after encryption.

6. The bytecode encryption method based on Java Agent startup according to any one of claims 1 to 5, It is characterized in that The preset encryption algorithm includes: Extracting custom encryption information from the encryption parameters; For the designated class file according to the encryption parameter, encrypt according to the custom encryption information to obtain the target encrypted file; Encrypting the files in the decompressed JAR package except for the specified class files according to the encryption parameters by using an obfuscated encryption method to obtain a first obfuscated encrypted file and a second obfuscated encrypted file; Performing logical encryption on the target encrypted file and the first obfuscated encrypted file, or on the target encrypted file and the second obfuscated encrypted file, to obtain a mixed encrypted file; A character string constant is written into the mixed encrypted file.

7. A bytecode encryption system based on Java Agent startup, It is characterized in that The bytecode encryption system started based on Java Agent includes: The encryption parameter configuration module is used to configure encryption parameters in the Java project file specified by the user; An encryption module, used to decompress the original JAR package in the Java project file, encrypt the specified class file in the decompressed JAR package according to the encryption parameters according to a preset encryption algorithm, and retain corresponding data according to a preset parameter type; An agent adding module, used to add Java Agent information by modifying the MANIFEST.MF file of the original JAR package, wherein the Java Agent information is used to verify the password corresponding to the encryption parameter and decode it; The packaging module is used to repackage the encrypted class files into a JAR package.

8. The bytecode encryption system based on Java Agent startup according to claim 7, It is characterized in that The encryption parameters include encryption password, time limit, hardware binding and remote control parameters.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, It is characterized in that When the processor executes the computer program, the steps of the bytecode encryption method based on Java Agent startup as described in any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium storing a computer program. It is characterized in that When the computer program is executed by a processor, the steps of the bytecode encryption method based on Java Agent startup as described in any one of claims 1 to 6 are implemented.

Images