Code compiling method, storage medium and electronic device

Abstract

The application provides a code compiling method, a storage medium and an electronic device. The method comprises the following steps: obtaining device characteristic information of a client device through a bottom application program interface; determining a threat level of a code execution environment according to detected reverse tool behavior characteristic information; inputting the device characteristic information and the threat level into a machine learning model to determine a code obfuscation strategy; and compiling to-be-published code according to the code obfuscation strategy. Through the application, the problem that the code compiling efficiency is low and the code attack resistance is low due to the limitation of a static obfuscation strategy is solved, and the safety of the overall system is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a code compilation method, a storage medium, and an electronic device. Background Technology

[0002] Currently, client-side code protection technology faces severe challenges, particularly the limitations of static obfuscation strategies, the disconnect between encryption and obfuscation, insufficient cross-platform compatibility, and limited anti-reverse engineering methods. Traditional Abstract Syntax Tree (AST) obfuscation uses fixed rules, making it easily identifiable and reversible by automated tools. Encryption and obfuscation are implemented independently, and hard-coded key storage and unencrypted key transmission become entry points for attackers. Cross-platform code protection lacks support for architectures such as WebAssembly and RISC-V, and it is difficult to balance performance adaptation and resource consumption; for example, performance degradation can reach 23% on Raspberry Pi. Insufficient encryption strength also makes PC-side code vulnerable to cracking. Furthermore, protection methods rely excessively on syntax-level obfuscation, lacking multi-layered protection at the control flow, data flow, and runtime levels, making static analysis and dynamic debugging weak points. Faced with these technical bottlenecks, there is an urgent need for a new solution integrating dynamic obfuscation, encryption fusion, cross-platform compatibility, and multi-layered protection to build a more secure client-side code protection system. Summary of the Invention

[0003] This invention provides a code compilation method, storage medium, and electronic device to at least solve the problems of low code compilation efficiency and low code resistance to attacks caused by the limitations of static obfuscation strategies in related technologies.

[0004] According to an embodiment of the present invention, a code compilation method is provided, comprising: obtaining device characteristic information of a client device through a low-level application programming interface; determining the threat level of the code execution environment based on detected reverse engineering tool behavior characteristic information; inputting the device characteristic information and the threat level into a machine learning model to determine a code obfuscation strategy; and compiling the code to be released according to the code obfuscation strategy.

[0005] In one embodiment, the device characteristic information includes at least one of the following: device architecture, CPU utilization, memory utilization, power level, and network type.

[0006] In one embodiment, after inputting the device feature information and the threat level into a machine learning model to determine a code obfuscation strategy, the method further includes: using the runtime data obtained from executing the code to be released as input to a reward function to optimize the code obfuscation strategy.

[0007] In one embodiment, the code obfuscation strategy includes at least one of the following strategies: variable renaming strategy, key allocation embedding strategy, control flow strategy, expression obfuscation strategy, instruction obfuscation strategy, and memory protection strategy.

[0008] In one embodiment, the variable renaming strategy includes: converting the code to be released into an abstract syntax tree (AST); traversing the AST, identifying and collecting all variable names in the AST; generating a new variable name for one or more variables, and creating a mapping table to record the correspondence between the original variable name and the new variable name; updating one or more variable references in the AST according to the renaming mapping table, and replacing the original variable name of the one or more variables with the new variable name.

[0009] In one embodiment, the key distribution embedding strategy includes: splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released; and converting the modified AST back into the obfuscated code to be released.

[0010] In one embodiment, the code to be released includes function comment nodes. Splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released includes: marking the key fragments with specific tags; encoding the marked key fragments into strings; and inserting the resulting key strings into the function comment nodes.

[0011] In one embodiment, after splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released, the method further includes: extracting the key string from the code to be released based on the specific marker while running the code to be released; decoding the key string to obtain the corresponding key fragments; and storing the key fragments in an empty array being created.

[0012] In one embodiment, the control flow strategy includes: constructing a first control flow graph based on the code to be released, wherein each node in the first control flow graph represents a basic block of code and each edge represents a control flow transition; adjusting the control flow relationships between the basic blocks to break the natural logical structure of the code to be released; and / or adding dummy basic blocks in the first control flow graph.

[0013] In one embodiment, the expression obfuscation strategy includes at least one of the following: modifying the complexity of the expression in the code to be released; if the expression involves a function call, redefining or obfuscating the name and / or parameters of the function; modifying the order of parameters in the expression while preserving the data dependencies corresponding to the expression.

[0014] In one embodiment, the instruction obfuscation strategy includes at least one of the following: constructing a second control flow graph based on the instruction code in the code to be released; determining instruction dependencies from the second control flow graph and adjusting the instruction order according to the instruction dependencies; identifying the function type corresponding to the instruction code and modifying the function type corresponding to the instruction code; adding additional branches or loops based on the existing control flow structure in the second control flow graph, and inserting spurious control flows into the branches or loops.

[0015] According to yet another embodiment of the present invention, a storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0016] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0017] This invention, based on device characteristic information, an assessment of the threat level of the code execution environment, and the use of a machine learning model, dynamically generates an optimal obfuscation strategy, significantly improving the intelligent adaptability and anti-reverse engineering capabilities of code compilation. Specifically, the dynamic obfuscation strategy adjusts according to device performance and the real-time threat environment, ensuring efficient code execution on different devices while enhancing the code's resistance to reverse engineering tools and reducing the risk of code cracking. Therefore, it solves the problems of low code compilation efficiency and weak code resistance to attacks caused by the limitations of static obfuscation strategies, thereby improving the overall system security. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal for executing the code compilation method according to an embodiment of the present invention;

[0020] Figure 2 This is a flowchart of a code compilation method according to an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of the key fragmentation steganography technique according to an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram of the architecture of the WebAssembly obfuscation module according to an embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram of a cross-platform adaptation decision tree according to an embodiment of the present invention;

[0024] Figure 6 This is a schematic diagram of the workflow of the dynamic confusion decision model according to an embodiment of the present invention. Detailed Implementation

[0025] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0027] The following is an explanation of the technical expertise involved in the embodiments of the present invention:

[0028] AST, an abstract syntax tree generated from source code through lexical / syntactic analysis, is used to describe the code structure;

[0029] Dynamic obfuscation strategy; based on reinforcement learning, the combination of obfuscation modules is adjusted in real time to respond to environmental changes and threat levels;

[0030] Lightweight encrypted steganography, combining AES-CTR encryption with AST annotation node key fragmentation, and dynamic restoration at runtime;

[0031] Nondeterministic state machines generate multipath control flows with random noise, making it impossible for static analysis to reconstruct the original logic;

[0032] WebAssembly (WASM) obfuscation, including instruction reordering, type obfuscation, and fake jump injection techniques targeting WASM bytecode.

[0033] The threshold scheme (n,k) is a deep Q-Network (DQN) model that uses environmental feedback to optimize the confusion strategy and select the threshold scheme. The key is split into n pieces, and at least k pieces are required for reconstruction (n≥5,k≥3).

[0034] Current client-side code protection technologies face four core challenges that have not been effectively addressed in existing solutions:

[0035] (a) The inherent defects of static obfuscation strategies.

[0036] Traditional Abstract Syntax Tree (AST) obfuscation techniques employ a fixed set of rules (such as variable name replacement templates and control flow flattening patterns), making the obfuscation features easily identifiable by automated tools. According to the 2023 Web Security Report, statically obfuscated JavaScript code can be restored to 85% of its variable names and function logic in an average of 3.2 hours using the JSNice tool. Attackers can easily crack this obfuscation through the following steps:

[0037] 1. Use Esprima to parse obfuscated code and generate an AST.

[0038] 2. Identify variable renaming patterns (such as the distribution of single-letter variables) through statistical analysis.

[0039] 3. Use the control flow graph isomorphism algorithm to reconstruct the original execution path.

[0040] 4. Refactor business logic by combining code semantic analysis (such as API call sequences).

[0041] (ii) The disconnect between encryption and obfuscation design.

[0042] In existing solutions, encryption and obfuscation are implemented independently, making key storage a fatal weakness:

[0043] Hard-coded storage: 63% of obfuscation tools embed Advanced Encryption Standard (AES) keys directly in the code (e.g., const key = "a1b2c3..."), which can be directly extracted via Ghidra string search.

[0044] Key transmission exposure: Keys transmitted over the network are vulnerable to interception by MITM attacks. In one financial app, 73% of encrypted traffic could be decrypted because key transmission was not encrypted.

[0045] Decryption logic is solidified: the decryption function is separated from the business logic, and attackers can directly bypass the obfuscated code after locating the decryption entry point.

[0046] (iii) Lack of cross-platform compatibility.

[0047] With the rise of edge computing, code needs to run on diverse hardware environments, but existing solutions have limitations:

[0048] Performance mismatch: Performance loss reaches 23% on embedded devices such as Raspberry Pi (far exceeding the 5% threshold), while on PCs, it is easily cracked due to insufficient protection.

[0049] Architecture compatibility issues: Lack of support for emerging architectures such as WebAssembly and RISC-V; WASM code protection success rate is less than 30%.

[0050] Uncontrolled resource usage: After the code of an IoT device was obfuscated, its memory usage increased from 1.2MB to 4.7MB, triggering an OOM restart.

[0051] (iv) The reverse engineering methods are limited.

[0052] Traditional solutions rely too heavily on syntax obfuscation and lack multi-layered protection.

[0053] Static analysis is vulnerable: tools such as IDA Pro can track data flow through taint analysis.

[0054] Insufficient dynamic debugging protection: runtime protections such as anti-debugging and anti-memory dump are not implemented.

[0055] Side-channel leakage risk: Differences in CPU cache hits during encryption operations can be used for key recovery.

[0056] To address the aforementioned technical deficiencies, this invention proposes a code compilation method. This method includes a four-dimensional optimization objective, which can form a complete protection system. Specifically, it includes:

[0057] Dynamic protection: Develop a confusion decision system based on reinforcement learning to adjust protection strategies in real time;

[0058] Encryption Fusion: Combining lightweight encryption with AST steganography to achieve covert key storage and dynamic restoration;

[0059] Cross-platform adaptation: Develop a dedicated WASM obfuscation module and build a device-aware dynamic adaptation framework that can support 8 types of hardware architectures;

[0060] Multi-layered protection; integrating syntax layer / instruction layer / runtime protection to build a defense-in-depth system.

[0061] The method embodiment provided in Embodiment 1 of this application can be executed on a computer terminal, a computer terminal, or a similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure block diagram of a computer terminal for executing the code compilation method according to an embodiment of the present invention. For example... Figure 1 As shown, computer terminal 10 may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0062] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the code compilation method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0063] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0064] This embodiment provides a code compilation method that runs on the aforementioned computer terminal. Figure 2 This is a flowchart of a code compilation method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0065] Step S202: Obtain device characteristic information of the client device through the underlying application programming interface (API);

[0066] Step S204: Determine the threat level of the code execution environment based on the detected reverse engineering tool behavior characteristics; wherein, the reverse engineering tools include: developer tools and memory dumping tools;

[0067] Step S206: Input the device feature information and the threat level into the machine learning model to determine the code obfuscation strategy;

[0068] Step S208: Compile the code to be released according to the code obfuscation strategy.

[0069] Through the steps described above, based on device characteristic information, the assessed threat level of the code execution environment, and employing a machine learning model, an optimal obfuscation strategy can be dynamically generated, significantly improving the intelligent adaptability and resistance to reverse engineering of code compilation. Specifically, the dynamic obfuscation strategy can adjust according to device performance and the real-time threat environment, ensuring efficient code execution on different devices while enhancing the code's resistance to reverse engineering tools and reducing the risk of code cracking. Therefore, it can solve the problems of low code compilation efficiency and low code resistance to attacks caused by the limitations of static obfuscation strategies, thereby improving the overall security of the system.

[0070] In one embodiment, the device characteristic information includes at least one of the following: device architecture, CPU utilization, memory utilization, power level, and network type.

[0071] In one embodiment, obtaining the device fingerprint via the underlying API can be achieved using the following code:

[0072] / / c

[0073] / / C code example (embedded device)

[0074] DeviceInfo getDeviceInfo() {

[0075] return {

[0076] .arch = detectArchitecture(), / / Detect ARM / x86 / RISC-V

[0077] .cpuFreq = getCpuFrequency(), / / Get the CPU frequency (e.g., 1.4GHz)

[0078] .memSize = getTotalMemory(), / / Memory capacity (e.g., 512MB)

[0079] .batteryLevel = getBattery() / / Mobile device battery level

[0080] };

[0081] }

[0082] In one embodiment, determining the threat level of the code execution environment based on detected reverse engineering tool behavior characteristics can be achieved through the following code:

[0083] / / javascript

[0084] / / JavaScript example (browser environment)

[0085] function detectThreatLevel() {

[0086] const threats = [];

[0087] / / Detect developer tools

[0088] if (window.devtools.isOpen) threats.push("devtools");

[0089] / / Memory dump detection tool

[0090] if (checkMemoryDump()) threats.push("memory_dump");

[0091] / / Threat Level Mapping (Level 0-5)

[0092] return Math.min(threats.length 2, 5);

[0093] }

[0094] Among them, " / / Detect developer tools"

[0095] The code `if (window.devtools.isOpen) threats.push("devtools");` checks if developer tools are open in the browser environment. In many browsers, `window.devtools` provides access to the status of developer tools, while `isOpen` determines whether these tools are active. If developer tools are detected to be open, it means someone is attempting to reverse engineer code or search for potential security vulnerabilities, so the code adds the threat tag "devtools" to the `threats` array.

[0096] The `checkMemoryDump()` function is used to detect if a memory dump tool is running. Memory dump tools can copy memory segments from a running application, providing direct access to the internal state of code and data. If memory dump tool activity is detected, the threat tag "memory_dump" is added to the `threats` array.

[0097] In this embodiment, a threat level mapping rule is also defined, which calculates a threat level from 0 to 5 based on the length of the threats array.

[0098] The specific rules include: for each detected threat, the threat level increases by 2, but the final level is capped at 5 to avoid exceeding the predefined range. This design reflects the fact that as the number of detected threats increases, the security risks to the code also increase proportionally. Quantifying the threat level provides a more intuitive understanding of the urgency of current code protection, offering a basis for subsequent adjustments to dynamic obfuscation strategies.

[0099] In one embodiment, before inputting the device feature information and the threat level into a machine learning model to determine the code obfuscation strategy, the method further includes: defining a 12-dimensional environment state vector and an action space consisting of eight obfuscation techniques based on a deep reinforcement learning model. The deep reinforcement learning model is a DQN model.

[0100] In one embodiment, the device characteristic information and the threat level are input into a machine learning model to determine a code obfuscation strategy, including:

[0101] The collected device feature information and threat level are combined into a 12-dimensional environment vector, which serves as the state input for the DQN model.

[0102] Define 8 obfuscation modules; each obfuscation module represents a code protection technique, such as variable renaming, control flow flattening, etc.

[0103] Based on multiple 12-dimensional environment vectors and 8 obfuscation modules, and using binary encoding to represent all possible combinations of obfuscation modules, a set of 256 code obfuscation strategies is obtained.

[0104] In one embodiment, the collected device feature information and threat level are combined into a 12-dimensional environment vector, which is implemented by the following code:

[0105] / / python

[0106] # State Vector Example

[0107] state = [

[0108] device.arch, # Hardware architecture (0: ARM, 1: x86, 2: RISC-V)

[0109] device.cpuUsage, # CPU utilization (0-100)

[0110] device.memUsage, # Memory usage (0-100%)

[0111] threatLevel, # Threat Level (0-5)

[0112] batteryLevel, # Battery level (0-100%)

[0113] networkType, # Network type (0: Mobile, 1: WiFi)

[0114] lastAttackTime, # Last attack time (in seconds since then)

[0115] # ... Five other environmental features ]

[0117] In one embodiment, the names, performance overhead, and use cases of the eight obfuscation modules are shown in Table 1.

[0118]

[0119] In one embodiment, after inputting the device feature information and the threat level into a machine learning model to determine a code obfuscation strategy, the method further includes: using the runtime data obtained from executing the code to be released as input to a reward function to optimize the code obfuscation strategy.

[0120] The reward function is a key component in reinforcement learning algorithms, defining how the DQN model receives feedback from its actions, and directly affecting the model's training performance and policy optimization. To implement the reward function, the following specific steps are required:

[0121] 1. Define the decompilation time ((T_{reverse}))

[0122] Use automated tools or manual attempts to decompile the obfuscated code, recording the time spent from the start of the parsing attempt to completion or complete restoration.

[0123] Convert the time taken into a numerical value, in seconds. The longer the time taken, the larger the value, indicating a better protection effect.

[0124] 2. Calculate performance loss

[0125] Benchmark performance measurement: Measure the execution time of the code to be released in an unobfuscated state as a comparison benchmark.

[0126] Post-obfuscation performance measurement: After obfuscation, the code execution time is measured again.

[0127] Calculate the execution time: (\Delta T_{exec} = T_{exec_obfuscated} - T_{exec_baseline}), where (T_{exec_obfuscated}) and (T_{exec_baseline}) represent the execution time of the obfuscated and unobfuscated code, respectively.

[0128] 3. Determine the functional error rate (errorRate)

[0129] Functional testing: Perform functional verification tests on the obfuscated code, including unit tests, integration tests, performance tests, etc., to ensure the correctness and stability of the code.

[0130] Error statistics: Record any functional errors or anomalies during the testing process and calculate the error rate percentage.

[0131] 4. Implement reward function calculation

[0132] Data integration: Integrate the collected (\T_{reverse}), (\Delta T_{exec}), and (\errorRate) into the function.

[0133] Implement the function: Based on the formula (\ R = 0.6 \times T_{reverse} - 0.3 \times \Delta T_{exec} - 0.1 \times errorRate), use a programming language such as Python to implement the reward function calculation logic.

[0134] 5. Optimize the reward function

[0135] Weighting adjustment: Based on the actual test results, the weighting coefficients in the formula may need to be adjusted to more accurately reflect the contribution of various factors to the final protection effect.

[0136] Feedback loop: During training, the model adjusts its policy selection based on the output of the reward function. The accuracy of the reward function directly affects the model's decision optimization.

[0137] Here is a code implementation example of a reward function:

[0138] \\[ R = 0.6 \times T {reverse} - 0.3 \times \Delta T {exec} - 0.1 \times errorRate \\]

[0139] \\( T_{reverse} \\): Decompilation time (seconds)

[0140] \\( \Delta T_{exec} \\): Performance loss (milliseconds)

[0141] \\(errorRate) \\: Functional error rate (%)

[0142] In one embodiment, the method includes training a DQN model, including:

[0143] Step S1: Collect samples to construct an experience pool;

[0144] To train a DQN model, an experience pool needs to be built to store a large number of device environment state samples, obfuscation policy execution results, and their corresponding reward values. This step typically involves running code on different devices to collect device state information, performance data of code before and after obfuscation, and security assessment results.

[0145] Ensure that the sample pool covers at least 200 different device models, which can include a variety of hardware from IoT devices to high-performance servers, as well as different software environments, such as different operating systems and browser versions.

[0146] The collected data is cleaned to remove invalid or abnormal samples, and each sample is labeled with its environmental status, obfuscation strategy, and reward value.

[0147] Step S2: Initialize the DQN network;

[0148] Initialize a DQN network with 12 neurons in the input layer (corresponding to the 12 dimensions of the state vector), 256 neurons in the hidden layer and 128 neurons in the hidden layer, used for initial feature extraction and further processing, respectively, and 256 neurons in the output layer (corresponding to 256 confusion strategies).

[0149] The network weights are assigned values ​​using random initialization to prepare for training.

[0150] Step S3: Train the DQN model using the ε-greedy policy;

[0151] ε is a balance parameter between exploration and exploitation. An ε-greedy strategy represents a trade-off between taking the optimal action (exploitation) and taking random actions (exploration). In the early stages of training, ε is set to 0.9, meaning that the model has a 90% probability of taking random actions to explore different obfuscation strategies.

[0152] As training progresses, the ε value will linearly decrease from 0.9 to 0.1, reducing the probability of random actions and increasing the model's decision-making based on the current policy, thus gradually shifting the model from exploration to exploitation.

[0153] In each training step, based on the current state vector, an ε-greedy policy is used to select a confusion policy for simulation execution, and the execution results and reward values ​​are collected to update the network parameters.

[0154] Step S4: Synchronize target network parameters;

[0155] DQN models are typically designed to include two networks: a main network (for policy selection) and a target network (for calculating Q-values). The parameters of the target network are fixed and are only synchronized with the main network at specific time points to stabilize the training process and prevent training instability caused by excessively rapid updates to the target network parameters.

[0156] Every 1000 training steps, the parameter values ​​of the main network are synchronized to the target network, and its parameters are updated to ensure that the target network can provide a stable Q-value estimate.

[0157] Step S5: Online learning and model update;

[0158] Once the model has completed its initial training, it can be deployed to a real-world environment for further strategy optimization through online learning. During actual code execution, the model continuously receives environmental state information, selects a confusion strategy based on the current state, collects reward values, and then uses this data to update the model parameters.

[0159] During the online learning phase, model parameters can be set to be updated hourly to ensure that the model can quickly adapt to environmental changes and adjust obfuscation strategies to cope with new threats.

[0160] Through the detailed steps described above, the DQN model can effectively learn and optimize code obfuscation strategies to adapt to different device environments and threat levels, thereby improving the effectiveness and applicability of code protection.

[0161] In one embodiment, the code obfuscation strategy includes at least one of the following strategies: variable renaming strategy, key allocation embedding strategy, control flow strategy, expression obfuscation strategy, instruction obfuscation strategy, and memory protection strategy.

[0162] In one embodiment, the variable renaming strategy includes: converting the code to be released into an abstract syntax tree (AST); traversing the AST, identifying and collecting all variable names in the AST; generating a new variable name for one or more variables, and creating a mapping table to record the correspondence between the original variable name and the new variable name; updating one or more variable references in the AST according to the renaming mapping table, and replacing the original variable name of the one or more variables with the new variable name.

[0163] Specifically, a syntax parser (such as Esprima, Babel, etc.) is used to convert the code to be published into an AST for easier subsequent operations.

[0164] Traverse the AST, identify and collect all variable names in the AST (including local and global variables).

[0165] Generate a new, random name for each variable. For example, you can use a hash function or a random string generator to ensure the uniqueness of the new name; and create a mapping table to record the correspondence between the original variable names and their new variable names.

[0166] Based on the renaming mapping table, update all variable references in the AST, replacing the original variable names with the newly generated variable names.

[0167] The modified AST is regenerated to generate obfuscated source code, and then bundled and optimized using bundling tools (such as webpack, rollup, etc.) to prepare obfuscated code for release.

[0168] In one embodiment, the key distribution embedding strategy includes: splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released; and converting the modified AST back into the obfuscated code to be released.

[0169] Here is a code example for key generation:

[0170] AES-CTR key generation:

[0171] / / javascript

[0172] / / Web Crypto API Implementation

[0173] async function generateSecureKey() {

[0174] return window.crypto.subtle.generateKey(

[0175] { name: "AES-CTR", length: 256},

[0176] true, ["encrypt", "decrypt"] );

[0178] }

[0179] AES-CTR (Advanced Encryption Standard with Counter mode) is a commonly used symmetric encryption algorithm suitable for encrypting large amounts of data and offering good performance. In JavaScript, an AES-CTR key can be generated using the Web Crypto API. The detailed implementation steps are as follows:

[0180] Step S1, Environment Import: Run this script in a modern browser environment that supports the Web Crypto API.

[0181] Step S2: Call the `generateKey` method: Use the `window.crypto.subtle.generateKey` method to generate a 256-bit AES key for encryption and decryption. Note that the AES-CTR parameter does not actually directly support CTR mode; in subsequent encryption operations, CTR mode must be implemented by specifying the `counter` and `length` fields.

[0182] Step S3, parameter parsing, includes:

[0183] { name: "AES-CTR", length: 256}: Specifies the key algorithm and key length.

[0184] true: indicates whether the key can be exported.

[0185] ["encrypt", "decrypt"]: Key usage, can be used for encryption and decryption operations.

[0186] Step S4, asynchronously return the key: The generateKey method is asynchronous and returns a key object via a Promise. Therefore, in practice, the await keyword should be used to wait for the function to complete, or the .then() method should be used to process the returned key.

[0187] Here is a code example for key splitting:

[0188] Shamir threshold splitting:

[0189] / / python

[0190] # Python implementation (n=5, k=3)

[0191] from secretsharing import Shamir

[0192] def splitKey(keyBytes):

[0193] # Split the 256-bit key into 5 pieces

[0194] shares = Shamir.split(3, 5, keyBytes) # k=3,n=5

[0195] # Add a 4-byte CRC checksum to each shard

[0196] return [share + crc32(share).to_bytes(4, 'big') for share in shares]

[0197] The Shamir threshold scheme is a key-sharing mechanism that splits a key into multiple fragments, and the original key can only be recovered when a sufficient number of fragments are collected. The following are the specific implementation steps of the Shamir threshold scheme:

[0198] Step S1: Install the secretsharing library, which provides an implementation of the Shamir threshold scheme.

[0199] Step S2: Use the Shamir.split function to split the key into a specified number of fragments. The split function accepts three parameters: the minimum number of fragments required for recovery k, the total number of fragments n, and the keyBytes to be shared.

[0200] Step S3: Add a 4-byte CRC32 checksum after each fragment. This can be achieved using Python's built-in binascii.crc32 function.

[0201] Step S4: Return the list of shards with verification.

[0202] In one embodiment, the code to be released includes function comment nodes. Splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released includes: marking the key fragments with specific tags; encoding the marked key fragments into strings; and inserting the resulting key strings into the function comment nodes.

[0203] The following is a code example of key embedding code;

[0204] / / javascript

[0205] / / Babel plugin implementation

[0206] function embedKeyFragments(ast, fragments) {

[0207] const functionNodes = [];

[0208] / / Collect all function nodes

[0209] traverse(ast, {

[0210] FunctionDeclaration(path) {

[0211] function Nodes.push(path);

[0212] }

[0213] });

[0214] / / Distributed embedded fragments

[0215] fragments.forEach((frag, i) => {

[0216] const targetNode = functionNodes[i 3 % functionNodes.length];

[0217] / / Insert slices in function comments

[0218] targetNode.node.leadingComments.push({

[0219] type: "CommentLine",

[0220] value: ` / KEY_FRAG_${i}_${crc32(frag).toString(16)} ${frag.toString('base64')}

[0221] });

[0222] });

[0223] }

[0224] In this embodiment, the fragmentation embedding strategy includes:

[0225] Select function comment nodes as carriers (this does not affect code execution);

[0226] Use a specific format to mark fragments;

[0227] Different function nodes are embedded in a distributed manner (with at least 3 AST nodes between them).

[0228] In one embodiment, the code obfuscation strategy further includes a string encryption strategy, including:

[0229] Search for all string constants in the AST; where AST is an abstraction based on the code to be released; string constants are text that appears directly in the code, such as error messages, configuration parameters, API endpoints, etc.

[0230] The algorithm used to encrypt the string is determined; the algorithms for encrypting the string include: AES and RSA; in this embodiment, the AES-CTR mode is adopted.

[0231] Generate a key and initialization vector; generate a key and initialization vector for the encrypted string (if required by the algorithm). The key should be stored securely, for example, using the methods described in key-fragmented steganography systems.

[0232] Encrypt all identified string constants using the selected encryption algorithm, converting them into encrypted data.

[0233] Add a decryption function to the code to be released to ensure that the strings can be correctly decrypted and used at runtime.

[0234] The obfuscated code containing the decryption logic is built and optimized, and then packaged into a codebase or binary file for release.

[0235] By employing variable renaming, key fragmentation and code embedding, and string encryption techniques, the security of the code is enhanced. This makes it difficult for reverse engineers to understand the logic and function of the code directly from variable names and strings after the code is released, increasing the difficulty and cost of cracking the code.

[0236] Figure 3 This is a schematic diagram of the key fragmentation steganography technique according to an embodiment of the present invention, as shown below. Figure 3 As shown, the 256-bit AES key is split into 5 fragments using a (n=5, k=3) threshold scheme, and annotation nodes of different functions of the AST are embedded. At runtime, at least 3 fragments are extracted to reassemble the key.

[0237] In one embodiment, after splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released, the method further includes: extracting the key string from the code to be released based on the specific marker while running the code to be released; decoding the key string to obtain the corresponding key fragments; and storing the key fragments in an empty array being created.

[0238] The following is a code example for runtime key recovery:

[0239] / / javascript

[0240] async function recoverKey(ast) {

[0241] const fragments = [];

[0242] / / Extract all fragments

[0243] traverse(ast, {

[0244] enter(path) {

[0245] if (path.node.type === "CommentLine" && / KEY_FRAG_(\d+)_([0-9a-f]+) / .test(path.node.value)) {

[0246] const [_, index, crc] = path.node.value.match( / KEY_FRAG_(\d+)_([0-9a-f]+) / );

[0247] const frag = Buffer.from(path.node.value.split(' / ')[1], 'base64');

[0248] / / Check CRC

[0249] if (crc32(frag).toString(16) === crc) {

[0250] fragments[parseInt(index)] = frag.slice(0, -4); / / Remove checksums

[0251] }

[0252] }

[0253] }

[0254] });

[0255] / / Combine fragmented recovery keys

[0256] return Shamir.combine(fragments.filter(Boolean));

[0257] }

[0258] In one embodiment, the control flow strategy includes: constructing a first control flow graph based on the code to be released, wherein each node in the first control flow graph represents a basic block of code and each edge represents a control flow transition; adjusting the control flow relationships between the basic blocks to break the natural logical structure of the code to be released; and / or adding dummy basic blocks in the first control flow graph.

[0259] In one embodiment, the expression obfuscation strategy includes at least one of the following: modifying the complexity of the expression in the code to be released; if the expression involves a function call, redefining or obfuscating the name and / or parameters of the function; modifying the order of parameters in the expression while preserving the data dependencies corresponding to the expression.

[0260] In one embodiment, the instruction obfuscation strategy includes at least one of the following: constructing a second control flow graph based on the instruction code in the code to be released; determining instruction dependencies from the second control flow graph and adjusting the instruction order according to the instruction dependencies; identifying the function type corresponding to the instruction code and modifying the function type corresponding to the instruction code; adding additional branches or loops based on the existing control flow structure in the second control flow graph, and inserting spurious control flows into the branches or loops.

[0261] In this embodiment, the instruction obfuscation strategy is implemented using the WebAssembly obfuscation module. Figure 4 This is a schematic diagram of the architecture of the WebAssembly obfuscation module according to an embodiment of the present invention, as shown below. Figure 4 As shown, the parser converts the WASM module into an intermediate representation, control flow analysis identifies optimizable points, and instruction rearrangement and type obfuscator work together to generate a highly secure obfuscated WASM module.

[0262] Here is a code example of instruction reordering:

[0263] / / python

[0264] def canSwapInstructions(inst1, inst2, cfg):

[0265] # Check for data dependencies between instructions

[0266] def getDependencies(inst):

[0267] return {v for v in inst.uses if v in cfg.liveVariables(inst)}

[0268] deps1 = getDependencies(inst1)

[0269] deps2 = getDependencies(inst2)

[0270] # No dependencies, therefore exchangeable

[0271] return inst2 not in deps1 and inst1 not in deps2

[0272] Table 2 shows a comparison of the code after instruction rearrangement:

[0273] Table 2

[0274]

[0275] Here is a code example of parameter type manipulation:

[0276] / / wat

[0277] ;; Primitive function type

[0278] (func $calc (param i32 i32) (result i32)

[0279] local.get 0

[0280] local.get 1

[0281] i32.add )

[0283] Obfuscated type (actually still processed as i32)

[0284] (func $calc (param f64 f64) (result f64)

[0285] local.get 0

[0286] local.get 1

[0287] i32.add; Type mismatch but runtime compatibility. )

[0289] The following is a code example of fake control flow injection:

[0290] / / wat

[0291] (block $label0

[0292] block $label1

[0293] i32.const 0

[0294] br_table $label0 $label1 $label0 ;; All branches point to valid blocks.

[0295] unreachable;

[0296] end

[0297] unreachable

[0298] end

[0299] In one embodiment, the code obfuscation strategy includes: a basic code obfuscation strategy, an enhanced code obfuscation strategy, and an extreme code obfuscation strategy;

[0300] Among them, basic code obfuscation strategies include at least one of the following: variable renaming strategy, key distribution embedding strategy, and string encryption strategy;

[0301] Enhanced code obfuscation strategies include at least one of the following: control flow obfuscation strategy and expression obfuscation strategy.

[0302] Extreme code obfuscation strategies include at least one of the following: instruction obfuscation strategy and memory protection strategy.

[0303] Table 3 shows a comparison of the performance overhead of the three levels of code obfuscation strategies, as well as applicable scenarios.

[0304] Table 3

[0305]

[0306] In one embodiment, a cross-platform adaptation framework is also provided, which determines the appropriate strength of code obfuscation strategy by monitoring the performance of the client device and the threat level of the code execution environment.

[0307] Figure 5 This is a schematic diagram of a cross-platform adaptation decision tree according to an embodiment of the present invention, such as... Figure 5 As shown, the decision logic of this cross-platform adaptation decision tree is: to dynamically select the optimal obfuscation template based on device type, real-time performance data and threat level, balancing security and performance loss.

[0308] Specifically, the performance monitoring subsystem monitors the performance of client devices, and its code example is as follows:

[0309] / / c

[0310] / / Embedded device performance monitoring

[0311] typedef struct {

[0312] float cpuUsage; / / CPU utilization (0-100)

[0313] float memUsage; / / Memory usage (0-100)

[0314] float temp; / / Chip temperature (°C)

[0315] PerformanceData;

[0316] PerformanceData monitorPerformance() {

[0317] static unsigned long lastCheck = 0;

[0318] static unsigned long lastCpuCycles = 0;

[0319] unsigned long now = millis();

[0320] unsigned long cpuCycles = getCpuCycles();

[0321] / / Calculate CPU utilization

[0322] float usage = calculateCpuUsage(lastCpuCycles, cpuCycles, now -lastCheck);

[0323] lastCheck = now;

[0324] lastCpuCycles = cpuCycles;

[0325] return {

[0326] .cpuUsage = usage,

[0327] .memUsage = getMemoryUsage(),

[0328] .temp = getChipTemperature()

[0329] };

[0330] }

[0331] The code obfuscation strategy with corresponding strength is determined by a dynamic template matching algorithm. An example of this is shown below:

[0332] / / javascript

[0333] function selectTemplate(perfData, threatLevel) {

[0334] / / Select template based on performance and threat level

[0335] if (perfData.cpuUsage > 80 || perfData.temp > 85) {

[0336] return "basic level"; / / Degrade level under high load

[0337] } else if (threatLevel >= 4) {

[0338] return "Ultimate Level"; / / Upgrade when facing a high threat

[0339] } else {

[0340] return "Enhanced level"; / / Default level

[0341] }

[0342] }

[0343] This invention also provides an anti-debugging mechanism, a commonly used security technology in code protection, used to detect whether code is running in a debugging environment and to take corresponding actions when a debugger is detected, such as stopping program execution or triggering an error.

[0344] The following are the specific steps to implement an anti-debugging mechanism:

[0345] For Windows platform

[0346] Include header files: Include header files in your code<windows.h> This header file is required to access Windows API functions. Windows provides the IsDebuggerPresent() function to detect if a debugger is running in the current process.

[0347] Calling the IsDebuggerPresent() function: Within the antiDebugCheck function, the IsDebuggerPresent() function is called to check if the process is being debugged. If it returns TRUE, it means the current process is being debugged.

[0348] When a debugger is detected, the TerminateProcess function is used to immediately terminate the current process. The GetCurrentProcess() parameter is used to obtain the handle of the current process, while 0 is used as the termination code to indicate normal termination.

[0349] For Linux platform

[0350] Include header files: Include header files in your code<sys / ptrace.h> The header file allows access to the Linux ptrace function, another commonly used anti-debugging technique. The ptrace function can detect whether the current process is being traced by another process.

[0351] Calling the ptrace() function: The ptrace function is called within the antiDebugCheck function. If the current process is being traced, ptrace(PTRACE_TRACEME, 0, NULL, NULL) will return -1, and errno will be set to EPERM or EPERM.

[0352] Handling anti-debugging results: If the ptrace function returns -1 and errno is EPERM, it means that the current process is being debugged. The function can terminate the process immediately using exit(0) or a similar method.

[0353] Specifically, an example of anti-debugging mechanism code is as follows:

[0354] / c

[0355] void antiDebugCheck() {

[0356] #ifdef _WIN32

[0357] / / Windows anti-debugging

[0358] if (IsDebuggerPresent()) {

[0359] TerminateProcess(GetCurrentProcess(), 0);

[0360] }

[0361] #elif __linux__

[0362] / / Linux anti-debugging

[0363] if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) == -1) {

[0364] exit(0);

[0365] }

[0366] #endif

[0367] }

[0368] Through the above implementation, the antiDebugCheck function can detect the presence of a debugger depending on the runtime environment, and immediately terminate the process when a debugger is detected, thereby preventing debugging tools from conducting in-depth analysis of the code and increasing code security.

[0369] This invention also provides a memory protection mechanism that increases the difficulty of reverse engineering by restricting access permissions to code segments or data segments.

[0370] For Unix / Linux platforms

[0371] Include header files: Include header files in your code<sys / mman.h> The header file contains the necessary APIs for performing memory protection operations.

[0372] Calling the `mprotect()` function: This function modifies the access permissions of a memory region. The parameter `addr` represents the starting address of the memory region to be protected, and `size` represents the size of the protected memory region. `PROT_READ` indicates that only read permissions are allowed.

[0373] For Windows platform

[0374] Include header files: Include header files in your code<windows.h> This header file is required to access Windows API functions. Windows provides the VirtualProtect() function for changing the protection attributes of memory regions.

[0375] Call the VirtualProtect() function: This function is used to change or query the protection attributes of a specified memory region. The parameters are similar to mprotect(), where addr is the starting address of the memory region to be protected, size is the size of the protected region, and PAGE_READONLY indicates that only read permissions are allowed.

[0376] Here is a code example for memory protection:

[0377] / / c

[0378] void protectMemory(void addr, size_t size) {

[0379] #ifdef __unix__

[0380] mprotect(addr, size, PROT_READ); / / Read-only, cannot be modified

[0381] #elif _WIN32

[0382] VirtualProtect(addr, size, PAGE_READONLY, NULL);

[0383] #endif

[0384] }

[0385] Through the above implementation, the `protectMemory` function can restrict write permissions to specific memory regions based on different runtime environments, thereby protecting the code from debugging or dynamic modification and increasing code security.

[0386] Figure 6 This is a schematic diagram of the workflow of the dynamic confusion decision model according to an embodiment of the present invention, such as... Figure 6 As shown, the environmental parameter acquisition module monitors the device status and threat level in real time, inputs the DQN model to infer the optimal strategy, and after the code is processed by the obfuscation strategy application module, the strategy database is updated through the execution effect feedback to form a closed-loop optimization.

[0387] In one scenario embodiment, the code compilation process for protecting a smartphone e-commerce app (Android platform) includes:

[0388] Step S1. Environment Initialization

[0389] Equipment Information:

[0390] Architecture: ARMv8 (64-bit)

[0391] CPU: Snapdragon 660 (8 cores, 2.2GHz)

[0392] Memory: 4GB

[0393] Initial threat level: 2 (Basic reverse engineering tools detected)

[0394] Step S2. Generate a dynamic code obfuscation strategy;

[0395] The following is a code example of the output of the DQN model:

[0396] / / json

[0397] {

[0398] "selectedTemplate": "Enhancement Level",

[0399] "modules": ["Variable renaming", "Control flow flattening", "String encryption", "Expression obfuscation"],

[0400] "params": {

[0401] "renameDictSize": 10000, / / Size of the renamed dictionary

[0402] "cfFlatteningDepth": 3, / / Control flow flattening depth

[0403] "stringEncryption": "AES" / / String encryption algorithm

[0404] }

[0405] }

[0406] Step S3, execute the code obfuscation strategy

[0407] Here is a code example of implementing a code obfuscation strategy:

[0408] / / bash

[0409] # Building an obfuscated pipeline

[0410] obfuscator --input app.js \

[0411] --rename --dict-size 10000 \

[0412] --flatten --depth 3 \

[0413] --encrypt-strings --algo AES \

[0414] --output app_obf.js

[0415] Step S4: When the response to be published is run, monitor the device parameters, performance, etc.

[0416] Protective effect:

[0417] Decompilation attempt: Analysis using IDA Pro 7.7 took 14.3 hours and was not fully restored.

[0418] Performance impact: Startup time increased by 0.8 seconds (from 2.3s to 3.1s), memory usage increased by 12%.

[0419] Functionality verification: All business processes are normal, and the payment verification logic has not been cracked.

[0420] In one scenario implementation, WebAssembly game engine protection is involved, and the code example of the original WASM module is as follows:

[0421] / / wat

[0422] (module

[0423] (func (export "update") (param f32 f32) (result f32)

[0424] local.get 0

[0425] local.get 1

[0426] f32.add

[0427] f32.const 0.9

[0428] f32.mul ) )

[0431] The following is a code example of obfuscation for WASM modules:

[0432] / / bash

[0433] wasm-obfuscator --input game.wat \

[0434] --instr-reorder \

[0435] --type-confusion \

[0436] --fake-branches 5 \

[0437] --output game_obf.wasm

[0438] WASM analysis after confusion

[0439] Instruction sequence: The original 28 instructions have been increased to 73 (including 32 dummy instructions).

[0440] Control flow complexity: Number of CFG nodes increases from 4 to 19, number of edges increases from 5 to 47

[0441] Reverse engineering difficulty: The business logic cannot be directly understood after decompiling using wasm2c.

[0442] Through the above embodiments of the present invention, a real-time optimization method for obfuscation strategies based on deep reinforcement learning solves the problem of static rules being easily cracked. AES-CTR encryption and AST annotation node key sharding technology achieve key covert storage. A complete protection chain from instruction reordering and type obfuscation to fake control flow injection is established. A performance-aware hierarchical obfuscation template system achieves a dynamic balance between security and efficiency. It integrates syntax-level obfuscation, instruction-level transformation and runtime monitoring for defense in depth.

[0443] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0444] Embodiments of the present invention also provide a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0445] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0446] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0447] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0448] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation methods, and will not be repeated here.

[0449] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0450] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A code compilation method, characterized in that, include: Obtain device characteristic information of the client device through the underlying application programming interface; Based on the detected behavioral characteristics of reverse engineering tools, the threat level of the code execution environment is determined; The device feature information and the threat level are input into a machine learning model to determine a code obfuscation strategy. Compile the code to be released according to the code obfuscation strategy described above.

2. The method according to claim 1, characterized in that, in, The device characteristic information includes at least one of the following: device architecture, CPU utilization, memory utilization, power level, and network type.

3. The method according to claim 1, characterized in that, After inputting the device feature information and the threat level into a machine learning model to determine the code obfuscation strategy, the method further includes: Based on the runtime data obtained from executing the code to be released; The runtime data is used as input to a reward function, which is then used to optimize the code obfuscation strategy.

4. The method according to claim 1, characterized in that, in, The code obfuscation strategy includes at least one of the following strategies: variable renaming strategy, key allocation embedding strategy, control flow obfuscation strategy, expression obfuscation strategy, instruction obfuscation strategy, and memory protection strategy.

5. The method according to claim 4, characterized in that, in, The variable renaming strategy includes: Convert the code to be released into an Abstract Syntax Tree (AST); Traverse the AST, identify and collect all variable names in the AST; Generate a new variable name for one or more variables, and create a mapping table to record the correspondence between the original variable name and the new variable name; Based on the renaming mapping table, update one or more variable references in the AST, replacing the original variable names of the one or more variables with the new variable names.

6. The method according to claim 4, characterized in that, in, The key distribution embedding strategy includes: The generated key is split into multiple reconfigurable key fragments, and the key fragments are inserted into the code to be released. The modified AST was then converted back into obfuscated, release-ready code.

7. The method according to claim 6, characterized in that, in, The code to be released includes function comment nodes. The generated key is split into multiple reconfigurable key fragments, and these key fragments are inserted into the code to be released, including: The key fragments are marked with specific tags; The marked key fragments are encoded into strings, and the resulting key strings are inserted into the function comment nodes.

8. The method according to claim 7, characterized in that, After splitting the generated key into multiple reconfigurable key fragments and inserting the key fragments into the code to be released, the method further includes: When the code to be released is executed, the key string is extracted from the code to be released based on the specific marker; The key string is decoded to obtain the corresponding key fragments; The key fragments are stored in an empty array that is being created.

9. The method according to claim 4, characterized in that, in, The control flow obfuscation strategy includes: A first control flow graph is constructed based on the code to be released, wherein each node in the first control flow graph represents a basic block of code, and each edge represents a control flow transition; Adjust the control flow relationships between the basic blocks to break the natural logical structure of the code to be released; and / or, add dummy basic blocks to the first control flow graph.

10. The method according to claim 4, characterized in that, in, The expression obfuscation strategy includes at least one of the following: Modify the complexity of the expressions in the code to be released; In cases where the expression involves a function call, redefine or obfuscate the name and / or parameters of the function; Modify the order of parameters in the expression while preserving the data dependencies corresponding to the expression.

11. The method according to claim 4, characterized in that, in, The instruction obfuscation strategy includes at least one of the following: A second control flow graph is constructed based on the instruction code in the code to be released; instruction dependencies are determined from the second control flow graph, and the instruction order is adjusted according to the instruction dependencies; Identify the function type corresponding to the instruction code, and modify the function type corresponding to the instruction code; Based on the existing control flow structure in the second control flow graph, additional branches or loops are added, and dummy control flows are inserted into the branches or loops.

12. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 11 when it is run.

13. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method described in any one of claims 1 to 11.

Images