Java code protection method and system for private deployment offline environment

Abstract

The application discloses a Java code protection method and system for a private deployment offline environment, and belongs to the technical field of computer software security and data protection, which comprises the following steps: encrypting the bytecode file of a core business class by using a key; splitting the key into at least two key fragments, and storing the split key in an external file and a protected area of a Native layer respectively; collecting the hardware fingerprint of the deployment environment in the local runtime, and verifying whether the current environment has the running permission based on the pre-stored offline authorization file; if the running permission is available, reading the key fragments in the Native layer and combining and restoring the complete key; based on the Java custom class loader, when the encrypted core business method is called, the complete key is used to decrypt and execute the encrypted bytecode file on demand, and the plaintext data in the memory is cleared after the method execution is completed. The key leakage risk is reduced, and illegal agents are effectively intercepted and stolen.

Description

Technical Field

[0001] This application belongs to the field of computer software security and data protection technology, and specifically relates to a Java code protection method and system for privately deployed offline environments. Background Technology

[0002] With the increasing prevalence of enterprise-level software private deployment models, more and more core Java business code is being delivered directly to user-side servers for execution. This exposes the code to the risks of decompilation, reverse engineering, and unauthorized modification. Current mainstream Java code protection solutions typically employ bytecode encryption combined with custom class loading, completing decryption only during the class loading phase. At runtime, the JVM still relies on storing the plaintext key and plaintext bytecode in memory. This approach suffers from two critical vulnerabilities: 1. Deserialization attack risk: Attackers can use Java's native deserialization mechanism to launch deserialization attacks on custom class loaders and encrypted core business classes in memory, bypassing bytecode encryption protection to directly obtain plaintext code; 2. Risk of illegitimate agent bytecode theft: Even if the deserialization path is protected, attackers can still steal plaintext bytecode by injecting an illegitimate Java agent registration converter to intercept the custom class loading and decryption process.

[0003] Most existing protection methods only block a single layer and do not achieve multi-layered protection. Furthermore, the keys are stored centrally and are easily extracted as a whole, which cannot meet the high security protection requirements of core code in private scenarios. Summary of the Invention

[0004] To address the issues of easy key leakage, inadequate deserialization protection, and high risk of interception and theft by unauthorized proxies in traditional solutions, the technical solution adopted in this application is: 1. The key is split and stored in pieces. After the core business code is encrypted, the decryption key is split into two pieces. The key pieces are isolated and stored in an independent external file and the native layer through a memory protection mechanism to prevent cracking attacks. No single piece can restore the complete key. 2. Offline fingerprint authorization: This method generates fingerprint signatures and certificates by collecting hardware characteristics of the computer environment. At startup, it extracts hardware fingerprint information and compares it with the offline authorization file for authentication, binding it to the runtime environment. This avoids the risks of hijacking online authorization through public cloud and the risks of service transfer environment usage. 3. Runtime method-level dynamic decryption: When the product runs on the target server, it uses a dynamic link library security loading device under a hybrid architecture to realize integrity verification of the JAR package, and implements on-demand decryption of class bytecode based on a custom class loader. It is automatically destroyed after execution, which greatly reduces the bytecode memory residence time, and there is no complete plaintext key persistent storage throughout the process. 4. Deserialization and Serialization Interception: At startup, serialization and deserialization monitors are registered via proxy injection to intercept serialization and deserialization of core business logic and custom class loaders, thus blocking serialization attacks. 5. Implement a Java Agent whitelist verification mechanism. By scanning injected agents, when an illegal class converter is detected, implement an automatic exit strategy or remove the class converter of the illegal Java Agent to avoid malicious third-party code injection to steal bytecode and destroy business logic.

[0005] This application provides a Java code protection method for privately deployed offline environments, including: Encrypt the bytecode files of core business classes using a key; The key is split into at least two key fragments, and the split keys are stored in an external file and a protected area of ​​the Native layer, respectively. The hardware fingerprint of the deployment environment is collected during local runtime, and the current environment is verified to have running permissions based on the locally pre-stored offline license file. If the user has the necessary permissions, the key fragments are read and merged at the Native layer to obtain the complete key. Based on a custom Java class loader, when calling the encrypted core business method, the complete key is used to decrypt and execute the encrypted bytecode file as needed, and the plaintext data in memory is cleared after the method execution is completed.

[0006] Optionally, splitting the key into at least two key fragments and storing the split keys in an external file and a protected area of ​​the Native layer respectively includes: The key is split into at least two fragments using a preset secret sharing algorithm; Perform obfuscation operations on the split key fragments; The obfuscated first key fragment is stored in the external file, and the obfuscated second key fragment and the compilation pipeline ID are stored in the protected area of ​​the Native layer.

[0007] Optionally, the step of reading the key fragments and merging them at the Native layer to obtain the complete key includes: The first key fragment and the second key fragment are read from the external file and the protected area of ​​the Native layer, respectively, and deobfuscation is performed to restore the original value of the fragment; The secret sharing algorithm is used to merge the restored fragmented original values ​​to obtain the original key text; The original key is concatenated with the compilation pipeline ID stored in the protected area of ​​the Native layer to generate a complete key for decryption.

[0008] Optionally, the offline license file generation step includes: Hardware features are collected on the target deployment server, and the collected hardware features are hashed and concatenated to generate a unique hardware fingerprint for the server. Generate an asymmetric encryption key pair, use the private key to sign the hardware fingerprint, generate an offline authorization file containing the signature information, and pre-store the public key as an authentication certificate in a specified path on the target deployment server.

[0009] Optionally, the step of verifying whether the current environment has execution permissions based on locally pre-stored offline license files includes: Read the locally stored offline authorization file and public key certificate. The offline authorization file contains authorization information generated by signing the hardware fingerprint using the private key. The public key certificate is invoked at the Native layer to verify the authorization information. If the verification is successful, it is determined that the user has the right to run.

[0010] Optionally, after merging and restoring to obtain the complete key, before the step of using the complete key to decrypt and execute the encrypted bytecode file on demand when calling the encrypted core business method based on the Java custom class loader, the following steps are also included: Override the writeReplace and readResolve methods in a custom class loader to throw an exception when attempting to serialize or deserialize a core business class or a custom class loader. Dynamically inject a Java Agent, obtain an Instrumentation instance, and register a custom security monitor; The security monitor intercepts the methods of the Java deserialization core entry class and inserts verification logic at the beginning of the method. When a deserialization operation on the core business class or the custom encryption class loader is detected, an exception is thrown.

[0011] Optionally, after obtaining runtime permissions, before the step of reading the key fragments and merging them to restore the complete key at the Native layer, the following steps are also included: Scan and verify class converters that have been injected into the Java proxies of the current JVM; Obtain the signature information of pre-stored legitimate class converters, and verify the currently scanned class converters based on the signature information; If the verification result indicates the existence of an illegal class converter, then terminate the current program execution or remove the illegal class converter through reflection.

[0012] Based on the same inventive concept, this application also provides a Java code protection system for privately deployed offline environments, comprising: The code encryption module is used to encrypt the bytecode files of core business classes using a key; A key fragment storage module is used to split the key into at least two key fragments and store the split keys in an external file and a protected area of ​​the Native layer, respectively. The environment authorization module is used to collect the hardware fingerprint of the deployment environment during local runtime and verify whether the current environment has the right to run based on the locally pre-stored offline authorization file. The dynamic decryption module, if it has the necessary permissions, reads the key fragments at the Native layer and merges them to restore the complete key. The execution module is used to decrypt and execute the encrypted bytecode file on demand using the full key when calling the encrypted core business method based on a Java custom class loader, and clear the plaintext data in memory after the method execution is completed.

[0013] Furthermore, this application also provides an electronic device, comprising: at least one processor and a memory; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, a Java code protection method for privately deployed offline environments is implemented as described above.

[0014] In another aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements a Java code protection method for a privately deployed offline environment as described above.

[0015] Compared with the prior art, this application has the following advantages: This application provides a Java code protection method and system for privately deployed offline environments, comprising: encrypting the bytecode file of a core business class using a key; splitting the key into at least two key fragments and storing the split keys in an external file and a protected area in the Native layer, respectively; collecting the hardware fingerprint of the deployment environment at local runtime and verifying whether the current environment has running permissions based on a locally pre-stored offline authorization file; if running permissions are granted, reading the key fragments in the Native layer and merging them to obtain the complete key; and, based on a Java custom class loader, using the complete key to decrypt and execute the encrypted bytecode file on demand when calling the encrypted core business method, and clearing the plaintext data in memory after the method execution is completed.

[0016] The beneficial effects are: 1. Compared to traditional full Java layer encryption schemes, the risk of plaintext key leakage is reduced by more than 90%; 2. Effectively blocks known bytecode theft attacks based on serialization and deserialization and illegal proxy injection, with a protection coverage of nearly 100%. 3. It does not intrude on the original core business and has no significant impact on the performance of normal business operations.

[0017] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This paper presents a schematic diagram of the Java code protection method for privately deployed offline environments provided in this application. Figure 2 The flowchart of the encrypted packaging process provided in this application is shown; Figure 3 The flowchart of the offline licensing process for the operating environment provided in this application is shown; Figure 4 The flowchart of the startup verification provided in this application is shown; Figure 5 The flowchart of the on-demand method-level decryption provided in this application is shown; Figure 6 This application provides a schematic diagram of the structure for protection against unauthorized agents. Figure 7 This application presents a diagram illustrating the architecture of a Java code protection system for privately deployed offline environments. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] Example 1 This application provides a Java code protection method for privately deployed offline environments, such as... Figure 1 ,include: Encrypt the bytecode files of core business classes using a key; The key is split into at least two key fragments, and the split keys are stored in an external file and a protected area of ​​the Native layer, respectively. The hardware fingerprint of the deployment environment is collected during local runtime, and the current environment is verified to have running permissions based on the locally pre-stored offline license file. If the user has the necessary permissions, the key fragments are read and merged at the Native layer to obtain the complete key. Based on a custom Java class loader, when calling the encrypted core business method, the complete key is used to decrypt and execute the encrypted bytecode file as needed, and the plaintext data in memory is cleared after the method execution is completed.

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the specific embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0023] I. Compilation and Packaging Stage On the development side, the core business code is hardened and output, with encryption applied only to the core business logic. The process includes the following steps: 1. Encryption and key sharding of core business code (1) For example Figure 2 As shown in module 201, an initial key is generated, a compilation sequence ID is bound, and a final key p is generated. (2) For example Figure 2 As shown in module 202, the core business class of the configuration is read, the name of the core business class that needs to be encrypted is obtained, and then the compiled Java bytecode file is scanned according to the core business class name. The key generated by the key generation device is concatenated with the compilation pipeline ID to encrypt the bytecode of the core business class, and the .dat file with the same name as the bytecode is output and placed in the bin directory. (3) For example Figure 2As shown in module 203, the improved Shamir private sharing algorithm is used to split the key into K1 and K2. After splitting, the two splits are obfuscated. The obfuscated first split is stored in a specific file and placed in the bin directory. The second split and the compilation pipeline ID are stored in the protected private area of ​​the Native license library in the form of a dynamic link library in the Native layer. After compilation, it is placed in the bin directory along with the dynamic link library. 2. Custom Java proxy class converter signature (1) For example Figure 2 As shown in module 204, obtain the bytecode file compiled by the custom proxy's ClassFileTransformer class converter; (2) Calculate the corresponding hash code H through the bytecode text, and then concatenate it with the pipeline ID to obtain the original signature text S. Use the enhanced signature algorithm I_M to generate a public key and private key pair. Use the private key to sign the aforementioned original signature text S to obtain the signature value V. Then, perform obfuscation operation on the generated public key and signature value V to generate a public key certificate file and a signature file pair, and put them into the corresponding resource directory. (3) Package the custom agent into a separate Agent JAR file and place it in the agent directory; 3. Supports storage of JAR package integrity verification codes. (1) For example Figure 2 As shown in module 205, the compiled raw bytecode is packaged into an executable program JAR, excluding the raw bytecode files corresponding to the core business classes during the packaging process; (2) Read the complete jar package, calculate the hash value, and obfuscate the calculated hash value and put it into the protected private area of ​​the Native licensed library in the form of a dynamic link library in the Native layer; (3) For example Figure 2 As shown in module 206, after completing the above steps, the generated encrypted code file, key fragment file, dynamic online library or static link library, executable jar package, resource file directory, agent directory, bin directory and dependency directory and other related necessary files will be packaged into a deployable package.

[0024] II. Authorization Binding Phase For the target server, authorization is completed by generating an offline authorization file through hardware fingerprint binding. The steps are as follows: 1. For example Figure 3As shown in module 301, hardware fingerprint collection: an authorized collection tool is run on the target server to automatically collect unchangeable hardware characteristics of the computer environment, including but not limited to CPU serial number, system disk GUID, network card MAC address, etc., and perform hash operation on each piece of data; 2. For example Figure 3 As shown in modules 302-303, offline authorization signature: The hash value is concatenated to form the server verification fingerprint F. The offline authorization tool system dynamically generates a public key-private key pair, uses the private key to sign the fingerprint F to generate a signature value, outputs the signature value as the offline authorization file license.lic, and then outputs the public key as the authentication certificate. The offline authorization file and the public key authentication certificate are stored in the specified path of the deployment server.

[0025] III. Startup Verification Phase When the target server starts up, the JAR file performs operations such as JAR package verification, environment authentication, and key restoration in sequence. The process includes the following stages: 1. For example Figure 4 As shown in module 401, after the Java startup entry class starts, it scans the JAR files and calculates the hash value. 2. The value is passed into the Native layer dynamic link library. The value is compared with the value stored in the protected private area of ​​the Native license library during the compilation stage through the instruction set to verify the integrity of the executable JAR package. If the comparison is successful, an environment check is performed to prevent it from being tampered with by third parties. 3. For example Figure 4 As shown in module 402, server hardware feature values ​​are extracted, and hardware fingerprints are constructed by hashing and passed to the native layer dynamic link library. The dynamic link library security loader under the hybrid architecture reads the public key certificate and authorization file from the specified path of the system server. The authorization information in the authorization file and the public key are used to complete the verification and authentication of the incoming hardware fingerprint information. Only when the verification is successful can the next step of execution be performed; otherwise, the operation stops and log information is recorded. 4. For example Figure 4 As shown in module 403, it connects to dynamic link libraries, scans for injected Java agent class converters, and uses an enhanced signature algorithm to verify the existence of an illegally injected agent by using the signature file and public key certificate of the corresponding class converter at compile time. If an illegal agent is found, the interception mechanism is activated and will not continue to be activated, thus preventing attackers from completing agent injection in advance. The illegal agent protection during the runtime protection phase can be seen in the signature process. 5. For example Figure 4As shown in module 404, the native layer dynamic link library is called to extract the key fragment K1 from the compile time and the key fragment K2 from the authorization library. After restoring the original value of the fragments through the instruction set, the improved private sharing algorithm is used to complete the fragment merging to obtain the original key text. At the same time, the pipeline ID stored in the native dynamic link library is concatenated with the key to obtain the decryption key. Then, the parsed decryption key is stored in the native private memory area, and the restored original fragment 1, fragment 2, original key text and pipeline ID are cleaned up. In the whole process, the complete original key is not written to the disk and is not exposed in the shared area of ​​the Java heap.

[0026] IV. Core Class Loading and Decryption Phase: On-Demand Decryption + Immediate Memory Clearing During runtime, an on-demand decryption mechanism is employed to prevent the full plaintext bytecode of core business logic from remaining resident in memory throughout the process. The steps are as follows: 1. For example Figure 5 As shown in module 501, when a business request calls the encrypted core business method, the custom class loader receives the class loading request, first loads the ciphertext data of the corresponding class, obtains the complete key information by calling the native layer dynamic link library, uses the key to restore the ciphertext to obtain the original bytecode, and executes the corresponding method after defining the class. 2. For example Figure 5 As shown in module 502, after the current method completes execution and returns a result, the Unsafe interface is immediately called using a custom class loader to release the bytecode memory block corresponding to the class and clear the plaintext data. Decryption is only completed again when the method is called again.

[0027] 3. For example Figure 5 As shown in module 503, an anti-debugging monitor is added: a periodic detector is added to the startup entry class, which continuously monitors the current JVM's attach state and memory read state after startup. If GDB debugging attach or class bytecode dump behavior is detected, the current JVM process is immediately terminated to block dynamic analysis.

[0028] V. Operational Protection Phase This stage is divided into two layers: protection against unauthorized agents and protection against deserialization. The steps are as follows: (1) Protection against illegal agents 1. For example Figure 5 As shown in module 501, a pre-start access verification is performed. Before starting the key concatenation, a dynamic link library is used to scan and verify the class converter of the injected Agent to check for illegal Agents. If the verification passes, the startup can proceed normally; if the verification fails, the startup cannot proceed. The checking method is as follows: a. Add an internal whitelist Agent management class. The Instrumentation instance obtained through this management class can replace the original maintained transformer list, which facilitates subsequent user management and maintenance. b. When using a dynamic link library to scan the injected Agent's class converter via reflection, directly scan the class converter objects in this list; c. Scan the location of your whitelisted guardian agents to obtain the corresponding raw bytecode information; d. When loading and packaging, the signature value and public key of the corresponding class converter are used to verify the original bytecode information using a digital signature verification algorithm. If the verification is successful, the program continues to start; otherwise, the dynamic link library will call back to terminate the Java program or remove the illegal class converter by obtaining the Instrumentation instance through memory reflection.

[0029] 2. For example Figure 6 As shown in module 601, during the runtime on-demand decryption phase, such as before loading ciphertext, an illegal agent verification process is asynchronously triggered. If the signature verification passes, the program runs normally. If the signature verification fails, a reverse callback is made to terminate the Java program or remove the converter through memory reflection to prevent illegal hijacking. (2) Serialization and deserialization blocking 1. For example Figure 6 As shown in module 601, the writeReplace / readResolve serialization and deserialization methods are overridden in a custom class loader, which throws an exception in response to any serialization / deserialization operation, thus blocking the serialization attempt of the class loader itself from the source. 2. Dynamically inject Java Agent: After the custom encrypted class loader is registered, an Instrumentation Agent conforming to the JVM specification is dynamically generated using the open-source bytecode enhancement technology Byte Buddy, and the Agent is dynamically injected into the currently running JVM process. 3. Obtain the Instrumentation instance through the Agent, call the addTransformer method to register a custom ClassFileTransformer implementation class injection custom Java proxy security protection monitor, which will trigger a callback when the JVM loads or re-converts the class; 4. For example Figure 6As shown in modules 602-603, the callback intercepts the core entry points of Java deserialization, java.io.ObjectInputStream and java.io.ObjectOutputStream, modifies the bytecode of their resolveClass method (the core entry point for reading the target class in deserialization) and writeClassDescriptor method, and inserts verification logic at the beginning of the method. If the deserialized class is a core encryption business class or a custom encryption class loader, an exception is thrown directly.

[0030] Example 2 Based on the same inventive concept, this application also provides a Java code protection system for privately deployed offline environments, such as... Figure 7 ,include: The code encryption module is used to encrypt the bytecode files of core business classes using a key; A key fragment storage module is used to split the key into at least two key fragments and store the split keys in an external file and a protected area of ​​the Native layer, respectively. The environment authorization module is used to collect the hardware fingerprint of the deployment environment during local runtime and verify whether the current environment has the right to run based on the locally pre-stored offline authorization file. The dynamic decryption module, if it has the necessary permissions, reads the key fragments at the Native layer and merges them to restore the complete key. The execution module is used to decrypt and execute the encrypted bytecode file on demand using the full key when calling the encrypted core business method based on a Java custom class loader, and clear the plaintext data in memory after the method execution is completed.

[0031] The system in this embodiment includes four functional modules, and their deployment relationship is as follows: 1. Developer test reinforcement module: Deployed on the developer compilation server, it is used for key splitting, bytecode encryption of core business classes, class converter authorization signing of Java proxy, extraction of JAR integrity feature values, and packaging of various resource files, Java proxy and JAR packages and dependency packages into a deployable package; 2. Authorization Verification Module: This module uses a hybrid architecture to connect to the Native layer deployed on the target private server. It verifies the integrity of the JAR package by comparing its signature value with the signature value generated during the compilation phase. Then, it collects hardware fingerprints, reads the authorization file and public key to complete offline authorization verification and fragmented key concatenation, and cleans up the memory area. The core of this module is that all verification, public key, authorization information key concatenation, etc., are implemented in the Native layer to prevent Java layer hooking and tampering. 3. Runtime dynamic decryption module: The program runs in the JVM of the target server, implements method-level on-demand decryption based on a custom class loader, and is responsible for cleaning up plaintext content during execution.

[0032] 4. Run the protection module: This module performs two functions. The first is to perform Java serialization and deserialization proxy injection before startup. By modifying the bytecode of the core serialization and deserialization methods, protection and verification methods are added. When the serialization or deserialization of the core business class is detected, an exception is thrown to intercept it. Other classes are serialized and deserialized normally. The second function is to trigger an illegal Java Agent check synchronously when loading the core business class. By scanning all registered Java Agent class converters through the native layer, the authorization information generated at compile time is obtained to complete the verification. If an illegal Java Agent is found, the program is notified to exit, or the illegal class converter is removed by obtaining the Instrumentation instance through memory reflection.

[0033] Example 3 Based on the same inventive concept, this application also provides an electronic device. The electronic device of this application includes at least one processor and at least one storage medium electrically connected to each other. The storage medium is electrically connected to the processor, wherein the storage medium stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described above.

[0034] Example 4 Based on the same inventive concept, this application also provides a storage medium storing instructions executable by at least one processor, the instructions being executed by at least one processor to enable at least one processor to perform the method described above.

[0035] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for protecting Java code in a privately deployed offline environment, characterized in that, include: Encrypt the bytecode files of core business classes using a key; The key is split into at least two key fragments, and the split keys are stored in an external file and a protected area of ​​the Native layer, respectively. The hardware fingerprint of the deployment environment is collected during local runtime, and the current environment is verified to have running permissions based on the locally pre-stored offline license file. If the user has the necessary permissions, the key fragments are read and merged at the Native layer to obtain the complete key. Based on a custom Java class loader, when calling the encrypted core business method, the complete key is used to decrypt and execute the encrypted bytecode file as needed, and the plaintext data in memory is cleared after the method execution is completed.

2. The method according to claim 1, characterized in that, The step of splitting the key into at least two key fragments and storing the split keys in an external file and a protected area of ​​the Native layer, respectively, includes: The key is split into at least two fragments using a preset secret sharing algorithm; Perform obfuscation operations on the split key fragments; The obfuscated first key fragment is stored in the external file, and the obfuscated second key fragment and the compilation pipeline ID are stored in the protected area of ​​the Native layer.

3. The method according to claim 2, characterized in that, The process of reading the key fragments at the Native layer and merging them to restore the complete key includes: The first key fragment and the second key fragment are read from the external file and the protected area of ​​the Native layer, respectively, and deobfuscation is performed to restore the original value of the fragment; The secret sharing algorithm is used to merge the restored fragmented original values ​​to obtain the original key text; The original key is concatenated with the compilation pipeline ID stored in the protected area of ​​the Native layer to generate a complete key for decryption.

4. The method according to claim 1, characterized in that, The steps for generating the offline license file include: Hardware features are collected on the target deployment server, and the collected hardware features are hashed and concatenated to generate a unique hardware fingerprint for the server. Generate an asymmetric encryption key pair, use the private key to sign the hardware fingerprint, generate an offline authorization file containing the signature information, and pre-store the public key as an authentication certificate in a specified path on the target deployment server.

5. The method according to claim 1, characterized in that, The step of verifying whether the current environment has execution permissions based on the locally pre-stored offline license file includes: Read the locally stored offline authorization file and public key certificate. The offline authorization file contains authorization information generated by signing the hardware fingerprint using the private key. The public key certificate is invoked at the Native layer to verify the authorization information. If the verification is successful, it is determined that the user has the right to run.

6. The method according to claim 1, characterized in that, After merging and restoring to obtain the complete key, before the step of using the complete key to decrypt and execute the encrypted bytecode file on demand when calling the encrypted core business method based on the Java custom class loader, the following steps are also included: Override the writeReplace and readResolve methods in a custom class loader to throw an exception when attempting to serialize or deserialize a core business class or a custom class loader. Dynamically inject a Java Agent, obtain an Instrumentation instance, and register a custom security monitor; The security monitor intercepts the methods of the Java deserialization core entry class and inserts verification logic at the beginning of the method. When a deserialization operation on the core business class or the custom encryption class loader is detected, an exception is thrown.

7. The method according to claim 1, characterized in that, After obtaining runtime privileges, but before the step of reading the key fragments and merging them to restore the complete key at the Native layer, the following steps are also included: Scan and verify class converters that have been injected into the Java proxies of the current JVM; Obtain the signature information of pre-stored legitimate class converters, and verify the currently scanned class converters based on the signature information; If the verification result indicates the existence of an illegal class converter, then terminate the current program execution or remove the illegal class converter through reflection.

8. A Java code protection system for privately deployed offline environments, characterized in that, include: The code encryption module is used to encrypt the bytecode files of core business classes using a key; A key fragment storage module is used to split the key into at least two key fragments and store the split keys in an external file and a protected area of ​​the Native layer, respectively. The environment authorization module is used to collect the hardware fingerprint of the deployment environment during local runtime and verify whether the current environment has the right to run based on the locally pre-stored offline authorization file. The dynamic decryption module, if it has the necessary permissions, reads the key fragments at the Native layer and merges them to restore the complete key. The execution module is used to decrypt and execute the encrypted bytecode file on demand using the full key when calling the encrypted core business method based on a Java custom class loader, and clear the plaintext data in memory after the method execution is completed.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the Java code protection method for a privately deployed offline environment as described in any one of claims 1-7.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the Java code protection method for a privately deployed offline environment as described in any one of claims 1-7.

Images