Code execution method and device based on dynamic loading and hiding design

Abstract

The invention relates to a dynamic code loading method and system based on cooperation of a remote service and a local server, and aims to realize dynamic updating and hidden execution of code logic. The method comprises the steps that a local server generates a request packet containing a unique identifier and a timestamp according to a preset rule; sending the request to a remote service through a request generation module; the remote service returns the encrypted data module according to the content of the request packet; the local server analyzes the content of the data packet through a decryption module and verifies the legality of the timestamp; dynamically splicing a plurality of modules to form a complete code logic; the spliced code is executed in a limited sandbox environment to ensure security and isolation. The remote service divides complete code logic into a plurality of independent encrypted storage modules, the confidentiality is improved by dynamically controlling the code loading sequence, plaintext codes are not stored in the operation process of the local server, and part of key logic is remotely calculated in real time and returned.

Description

Technical Field

[0001] The present invention relates to the technical field of software code protection, and in particular to a code execution method and device based on dynamic loading and concealment design, which are used to solve the security and concealment problems in source code protection, code tracking and dynamic updating. Background Art

[0002] In existing technologies, source code protection usually relies on code encryption, obfuscation or hard-coding protection. However, these technical methods face many problems during use: Although the code encryption scheme can encrypt and protect the source code, it needs to be decrypted at runtime, and there is still a risk of reverse engineering analysis; Hard-coded logic is difficult to modify and is not suitable for scenarios that require dynamic updates and flexible management. The widespread use of static analysis technology makes it difficult to effectively protect the sensitive logic of source code.

[0003] In response to the above problems, the present invention proposes a code execution method and device based on dynamic loading and hidden design. Through dynamic loading, modular splicing and timestamp control, combined with sandbox isolation and security verification, a code protection solution with both hiddenness and flexibility is provided. Summary of the invention

[0004] The present invention aims to provide a code execution method and device based on dynamic loading and hidden design, which solves the problems existing in the prior art that the source code is easily statically analyzed, has insufficient dynamic update capability and insufficient security guarantee by dynamically loading key code blocks, hiding source code logic and building a secure execution environment.

[0005] To achieve the above object, the present invention proposes the following technical solutions: In a first aspect, a method for dynamic code loading is provided, comprising: The local server initiates a request to the remote service through the HTTP protocol, and the remote service returns the AES-encrypted code block and encrypted timestamp information according to the request; After the local server decrypts the code block, it dynamically loads and executes it through the syntax tree interpretation mechanism, and clears the decrypted plaintext code to ensure that no sensitive data is retained in the memory; The decrypted code block is loaded and executed through a custom class loader, isolated from the main program to prevent unnecessary interference and tampering; In a second aspect, a method for dynamic loading timing based on timestamp control is provided, comprising: The remote service adds an encrypted timestamp when returning the code block, indicating the time point of the next code block request; The local server dynamically determines the timing of the next remote service call based on the decrypted timestamp. Calls outside the specified time period will receive forged code data to achieve code obfuscation. In a third aspect, a sandbox execution and timeout control mechanism is provided, including: Dynamically loaded code blocks are executed in a sandbox environment, and their access to system resources is restricted by the security manager; Set a timeout for code block execution to prevent the code block from executing in an infinite loop or occupying system resources; In a fourth aspect, a method for combining modular splicing with real-time computing is provided, comprising: The code block returned by the remote service is a part of the logic modularization code. Multiple code blocks are locally spliced ​​and decrypted to form a complete logic. Some key logic is calculated and returned in real time by remote services, further improving code concealment and flexibility.

[0006] In the embodiment of the present application, dynamic loading and hidden code execution are realized through the interaction between the local server and the remote service. Specifically, the local server obtains the encryption information of the target code block to be executed and the timestamp of dynamic loading by sending a request; obtains the executable logic of the target code block through decryption operation; loads the target code block into the isolated execution environment through the syntax tree interpretation mechanism; based on the dynamic control mechanism of loading timing, the remote service dynamically returns the encrypted timestamp of the next call; controls the loading timing through the timestamp, and enhances the concealment of the code block in combination with the forged data return mechanism.

[0007] In addition, during the execution process, the decrypted code blocks are executed through sandbox isolation technology, and an independent namespace is established through a custom class loader to prevent the code blocks from interfering with the main program; at the same time, a timeout control mechanism is set to prevent the dynamically loaded code blocks from causing system crashes due to resource occupation. For some critical logic, the remote service calculates in real time and returns, and only some non-sensitive logic is executed locally, effectively reducing the risk of critical code exposure.

[0008] This embodiment implements a code execution method based on dynamic loading and hidden design, which significantly improves the hiddenness and security of the code through modular design and dynamic control of timestamps, and effectively avoids the risks of static analysis and reverse engineering. At the same time, the code logic is dynamically updated without stopping the system operation or modifying the source code, which significantly improves the flexibility of system maintenance and management. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 This is one of the overall system architecture diagrams of a method for executing a code with dynamic loading and concealed design in one embodiment of the present application; Figure 2 This is a second code block dynamic loading flow chart of a code execution method with dynamic loading and concealed design in one embodiment of the present application; Figure 3 This is a third sandbox execution isolation diagram of a code execution method with dynamic loading and concealed design in one embodiment of the present application; Figure 4 This is the fourth modular splicing flow chart of a code execution method with dynamic loading and hidden design in one embodiment of the present application. DETAILED DESCRIPTION

[0010] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application. The numbering of the drawings in this application is only used to distinguish the various steps in the scheme, and is not used to limit the execution order of the various steps. The specific execution order is subject to the description in the specification.

[0011] In order to solve the above problems existing in the prior art, the embodiment of the present application provides a code execution method based on dynamic loading and hidden design, such as Figure 1 As shown, including: Through the collaborative work of the local server and the remote service, the encrypted code blocks are dynamically acquired, loaded, and executed to achieve the hidden delivery and execution management of the source code. The local server and the remote service communicate through the HTTP protocol. After receiving a legitimate request, the remote service generates an encrypted code block and its related information based on preset rules, and returns the encrypted data to the local server. After receiving the response data, the local server decrypts and interprets the syntax tree for loading, and executes it in isolation through a sandbox environment to ensure that the dynamically loaded code blocks are both anonymous and secure.

[0012] The local server calls the request generation module at runtime and builds a request packet containing a unique identifier and a timestamp according to preset rules. The unique identifier is used to identify the local server instance, and the timestamp is used to verify the legitimacy of the request. The local server sends the generated request packet to the remote service through a secure channel. The remote service verifies the identifier and timestamp in the request packet. When the identifier is legal and the timestamp is within the specified range, the remote service generates a target code module corresponding to the identifier, encrypts it with AES, and returns it. At the same time, the remote service also attaches the generated dynamic timestamp to the returned data packet for the next request verification of the local server, including: During the startup process, the local server loads and initializes the request generation module, which is responsible for generating a request packet for communication based on the current operating status of the system and preset rules. First, the request generation module reads the necessary initial parameters from the system configuration file. These parameters include basic information such as server identifier, encryption key, time offset value, etc., which are used to generate the basic content of the request packet; When building a request package, the request generation module first calls the unique identifier generator to generate a unique identifier for this request. The generation of the unique identifier is based on the system's current operating environment parameters, including server hardware information, process ID, and random number seed. By performing obfuscation calculations and hashing on these parameters, the generated unique identifier is ensured to be globally unique, while preventing external attackers from predicting the content of the identifier through fixed rules. After generating the unique identifier, the request generation module continues to construct the timestamp field of the request packet. The timestamp field records the sending time of the current request and is used to verify the timeliness of the remote service. In order to improve the anti-analysis ability of the timestamp, the request generation module encrypts or obfuscates the original time value. For example, a random seed-based encryption algorithm is used to perform a shift operation or an XOR operation on the timestamp, so that the true meaning of the timestamp can only be correctly interpreted on the remote server; After the core content of the request packet is generated, the request generation module encapsulates the identifier and timestamp into a fixed data structure, and adds other auxiliary fields, such as hash values ​​or digital signatures for verification. In order to prevent the request packet from being tampered with or intercepted during network transmission, the request generation module encrypts the complete request packet. The encryption process uses the AES encryption algorithm, and the key is negotiated and stored by the local server and the remote service during the initialization phase to ensure the security and uniqueness of the key; After the request packet is encrypted, the request generation module sends the encrypted data packet to the communication module to the remote service. During the data packet transmission process, the communication module is responsible for monitoring the stability and success rate of network transmission to ensure that the request packet can reach the remote service in time. If an abnormality occurs during the communication process, such as network interruption or data packet loss, the communication module will record the relevant logs and retry the sending mechanism until the request is successful or the maximum number of retries is reached.

[0013] Through the above operations, the local server can dynamically construct a request package containing a unique identifier and a timestamp, providing a reliable request basis for the subsequent remote service to return the dynamic code module. This mechanism ensures the uniqueness and timeliness of the request package, and at the same time improves the security of the request package during network transmission through an encryption protection mechanism. This implementation method provides an important basic guarantee for the security and reliability of dynamically loaded code logic.

[0014] After the local server receives the data packet returned by the remote service, it parses the data packet content through the decryption module and verifies the legitimacy of the timestamp. If the decryption is successful and the timestamp verification is passed, the decrypted code block is dynamically loaded through the syntax tree interpretation mechanism. The loaded code block is deployed to the sandbox environment for execution. The sandbox environment strictly constrains the running scope of the loaded code through class loader isolation, resource access restrictions, and execution timeout control mechanisms. Specifically, the sandbox environment prohibits code blocks from accessing non-whitelisted file system resources, and restricts network access rights to prevent dynamically loaded code blocks from generating unauthorized external communication behaviors. Figure 2 As shown, including: When the local server receives a data packet, it first completes the data packet reception operation through the communication module, and then hands the data packet to the decryption module for processing. After receiving the data packet, the decryption module performs a preliminary check on the data packet, mainly to check whether the integrity and format of the data packet are correct. The integrity check of the data packet is completed by comparing the hash value, that is, using the check code (such as MD5 or SHA-256) attached to the data packet to compare with the recalculated hash value. If the verification results are consistent, it is considered that the data packet has not been tampered with during transmission; After the data packet passes the integrity check, the decryption module calls the AES decryption algorithm to decrypt the data packet content. The key used for decryption is the symmetric key pre-negotiated by the remote service and the local server to ensure the security and reliability of the decryption process. After decryption, the data packet content is parsed into the following fields: encryption module data, timestamp, digital signature, and additional meta information (such as module identifier and splicing order); The decryption module extracts the decrypted timestamp information and verifies the legitimacy through the timestamp verification logic; After the timestamp verification is passed, the decryption module further calls the digital signature verification module to verify the source of the data packet. The digital signature verification process is completed based on an asymmetric encryption algorithm, that is, the signature field in the data packet is decrypted using the public key of the remote service, and the decrypted signature data is compared with the actual content of the data packet. If the verification is successful, it proves that the source of the data packet is credible and has not been tampered with during transmission; When both the timestamp verification and the digital signature verification are passed, the decryption module confirms the legitimacy of the data packet and transfers the decrypted module data and related meta-information to the subsequent code loading module for further processing. Through the above operations, the local server can ensure the security, integrity and timeliness of the data packet, effectively prevent malicious tampering, forgery and replay attacks, and provide security for the system's dynamic code loading.

[0015] Note that the timestamp verification mentioned above mainly includes the following steps: First, the decryption module compares the timestamp value with the current time of the local server to determine whether the timestamp is within the preset valid time range. The valid time range is usually set to a number of minutes before and after the current time (for example, ±5 minutes) to ensure the timeliness of the data. If the timestamp exceeds this range, the decryption module determines that the data packet is invalid data, records the abnormal log, and terminates subsequent operations; Secondly, the decryption module performs an obfuscation restoration operation on the decrypted timestamp according to the timestamp generation rules of the local server. Obfuscation restoration is usually based on a preset random seed or logic operation rule to ensure that the timestamp is consistent with the generation logic of the remote service. If the restored timestamp does not meet the rules, it is determined that the timestamp of the data packet has been tampered with or forged. The decryption module also records an alarm and refuses to process the data packet; In addition, to prevent replay attacks, the local server maintains a recent timestamp cache list. The decryption module checks whether the decrypted timestamp already exists in the cache list. If the timestamp is repeated, the data packet is determined to be replayed data and rejected to avoid malicious requests posing a threat to system security.

[0016] In order to enhance the dynamics and concealment of the code logic, the remote service divides the complete code logic into multiple modules, each of which is encrypted and stored independently. The local server can only obtain part of the modules and their loading order each time it requests. The local server accumulates module data through multiple requests, and after decryption, it splices the complete code logic and executes it in the order provided by the remote service. This modular splicing method effectively prevents attackers from restoring the complete code logic through a single interception of a data packet, while supporting dynamic updates and expansions of the code logic. Figure 3 As shown, including: The remote service analyzes the complete code logic during the initialization phase and divides the code into several logical units based on the functional characteristics, logical relevance, and execution priority of the code. Each logical unit independently constitutes a module, and the calling relationship between modules is realized through interface constraints. Modular processing can effectively reduce the amount of sensitive information exposed by a single module, while improving the combination flexibility of the code during dynamic loading; After the logical module division is completed, the remote service encrypts each module separately. Before encryption, the remote service generates a unique module identifier for each module. The identifier records the module's position in the complete logic and its dependencies. Subsequently, the remote service calls the AES symmetric encryption algorithm to encrypt the module's code content. The encryption key is independently managed by the remote service to ensure the security of the key. The encrypted module is stored in the remote service's module repository in binary form and indexed by the module identifier for subsequent retrieval and dynamic loading. After receiving a legitimate request from the local server, the remote service retrieves one or more matching logic modules from the module repository based on the identifier and related parameters contained in the request. To improve the concealment of dynamic loading, the remote service has designed a step-by-step loading strategy, that is, a single response only returns data for some logic modules, and other modules are gradually loaded in subsequent requests. The remote service attaches the module splicing order metadata in each response to guide the local server to complete module combination and execution; After the module data is selected, the remote service will package the module data again. Specifically, the remote service combines the module identifier, encrypted module data, and splicing order into a single data packet, and encrypts the entire data packet using a high-strength encryption algorithm. The encrypted data packet is sent to the local server through the communication interface to prevent the data from being stolen or tampered with during transmission; After receiving the module data returned by the remote service, the local server completes the decryption and parsing of the data packet by calling the decryption module, and combines the module data into executable logic blocks as needed based on the splicing order metadata. Finally, the combined code logic is loaded and run through the sandbox environment to ensure that the code remains hidden during the actual execution process; Through the above implementation, remote services can achieve flexible modular management of the complete code logic, while effectively reducing the risk of sensitive code leakage. The modular encrypted storage design not only enhances the dynamics and security of the code logic, but also supports the expansion of subsequent system functions. For example, when certain logic modules need to be updated or replaced, remote services only need to update the relevant modules without redelivering the complete code logic, thereby improving the maintenance efficiency and flexibility of the system.

[0017] On this basis, in order to further improve the anti-analysis capability, this application also designs a forged data return mechanism. When the local server's request timestamp is illegal or in an unspecified time period, the remote service returns an encrypted forged data packet. The forged data packet is structurally consistent with the real data packet, but the content is meaningless after decryption, and the content of the forged data is randomly generated to prevent attackers from obtaining patterns through repeated requests. The local server directly discards the data packet after the timestamp verification fails to ensure system security. Figure 4 As shown, including: When the remote service receives a request from the local server, it first verifies the legitimacy of the request through the request verification module. The verification process includes integrity checks and legitimacy checks on the unique identifier, timestamp, signature information and other fields of the request package. If the request fails the verification, the response is directly rejected and relevant log information is recorded; if the verification passes, the judgment process of the forged data return mechanism is entered; The triggering conditions of the forged data return mechanism are dynamically determined by the remote service according to preset rules. Specifically, the remote service comprehensively determines whether the forged data return mechanism needs to be triggered based on the current system operation status, the characteristics of the request content, and the records of historical requests. For example, when the remote service detects that there are multiple similar requests in a short period of time or the timestamp in the request deviates greatly from the system time, it determines that there may be an abnormal request, triggering the return of forged data; In the forged data generation phase, the remote service calls the forged data module to generate a set of fake module data. The forged data generation rules fully consider the similarity with the real module data, including the encryption method, data structure, module identifier format and meta-information splicing rules of the forged data. The forged data generation adopts a randomization strategy, so that the forged data generated each time has significant differences in content and characteristics, thereby further improving the anti-analysis capability; The generated forged data has the same external features as the real data and is also highly encrypted. The remote service packages the forged data into the same format as the real data packet, including the forged module identifier, encrypted data, and splicing meta information, and returns it to the local server through the communication module. At the same time, the remote service records the operation of returning the forged data, including the request source, the content of the forged data, and the triggering conditions, etc., for subsequent security analysis and anomaly tracking; After receiving the forged data, the local server processes it according to the normal decryption and verification process. Because the timestamp, signature information, and encryption fields of the forged data packet are carefully designed, after passing the initial integrity check and decryption operation, it may expose anomalies in the code loading stage. For example, when the logical content of the forged data is executed in a sandbox environment, it may trigger the preset error logic or fail to pass the module splicing verification. After the local server detects these anomalies, it records the forged data in the log and terminates the processing of the data packet; The design of the forged data return mechanism can effectively distract the attacker's analysis attention, forcing the attacker to process a large amount of invalid data when trying to restore the real code logic, increasing the difficulty of reverse engineering and analysis. At the same time, through the randomization design of forged data, even if the attacker intercepts the data packet multiple times, it is impossible to extract stable features from it, further improving the system's anti-analysis ability and security.

[0018] This embodiment achieves multi-level protection of system security by introducing a forged data interference mechanism during the real data transmission process. This design not only effectively reduces the risk of sensitive code logic being illegally obtained, but also enhances the concealment and unpredictability of dynamically loaded code, providing an important guarantee for the safe operation of the system.

[0019] It should be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0020] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A code execution method based on remote dynamic loading, characterized in that: include: The local server calls the request generation module and constructs a request packet containing a unique identifier and a timestamp according to preset rules; The local server sends the request packet to the remote service through the communication module; The remote service verifies the legitimacy of the request based on the identifier and timestamp contained in the request packet; The remote service modularizes the complete code logic and divides it into multiple logic modules, each of which is independently encrypted and stored; The remote service dynamically selects some logic modules based on the local server request, encrypts them, encapsulates them into data packets and returns them to the local server; After receiving the data packet, the local server parses the data packet content through the decryption module and verifies the legitimacy of the timestamp; The local server splices the logic modules according to the module meta-information to generate complete code logic; The local server loads the spliced ​​code logic into the sandbox environment and executes it through the reflection mechanism.

2. The method according to claim 1, characterized in that Request package construction, including: The unique identifier generation module generates a unique identifier based on the server hardware information, the process identifier and the random number seed; The timestamp generation module encrypts or obfuscates the current system time to generate a timestamp; The request generation module encapsulates the unique identifier, timestamp and verification information into a request packet.

3. The method according to claim 1 or 2, characterized in that: The remote service verifies the legitimacy of the request package, including: Verify the hash value or signature of the request packet to confirm the integrity of the data packet; Verify whether the deviation between the timestamp and the current time of the remote service is within the preset range; Check whether the request identifier complies with the preset generation rules.

4. The method according to claim 1, characterized in that: The steps for remote services to divide the complete code logic into multiple logical modules include: Divide the logic modules according to the functional characteristics and logical relevance of the code; Generate a unique identifier for each logical module; The logic module code content is AES encrypted and stored in the module repository.

5. The method according to claim 4, characterized in that Dynamic selection of logic modules by remote services, including: Retrieve the corresponding logic module according to the identifier in the request packet; Return part of the logic module in a single response; Appends the module's splicing order meta information in the return data packet.

6. The method according to claim 1, characterized in that Fake data return mechanism, including: Generate forged module data when the request packet passes verification but triggers the forgery condition; The generation rules of the forged module data include the encryption method, structure and identifier format consistent with the real module data; Returns forged module data to interfere with illegal analysis or attacks.

7. The method according to claim 1, characterized in that Loading and execution of the sandbox environment, including: The sandbox environment provides independent class loader isolation for loaded logical modules; Limit the input and output range of the logic module to prevent illegal access to external systems; Set an execution timeout mechanism to prevent the logic module from entering an infinite loop or occupying resources without limit.

8. The method according to claim 1, characterized in that: Timestamp verification, including: Compare the decrypted timestamp with the current time of the local server to ensure that it is within the valid range; Check whether the timestamp has been restored after obfuscation and complies with the preset rules; Verify that timestamps are not repeated in recent request records to prevent replay attacks.

9. The method according to claim 1, characterized in that: The steps of module splicing include: Arrange the logical modules in order according to the splicing order meta information in the returned modules; Check the integrity and consistency of the spliced ​​code logic; The complete code logic after splicing is loaded and executed by the reflection mechanism.

10. A code execution system based on remote dynamic loading, characterized in that: include: A request generation module, used to generate a request packet containing a unique identifier and a timestamp according to preset rules; A communication module, used to send request packets to remote services and receive data packets; A decryption module, used to decrypt received data packets and verify the legitimacy of the timestamp; A code splicing module is used to splice logic modules according to meta information; The sandbox environment is used to load the spliced ​​code logic and execute it through the reflection mechanism.

Images