Program labyrinth protection method based on jump statement and dispersed encrypted map construction

Abstract

The invention discloses a program labyrinth protection method based on jump statements and dispersed encrypted map construction, which comprises the following steps of: performing control flow analysis on an original program to generate an equivalent block, an initialization block, a redundant calculation block, an opaque predicate and an error path, and expanding a key control flow edge into a labyrinth structure comprising a plurality of correct paths and error paths. A binary maze map is generated for correct behaviors of each conditional jump intersection, and the map is fragmented, encrypted and disguised as common data to be stored dispersedly. During operation, the navigator calculates an index based on a current instruction address and a local execution context, locates and decrypts a target map fragment, and reads a map bit to control jump; meanwhile, sentinel points are arranged at key nodes of the labyrinth, a debugging environment and indexes are detected, abnormal decryption is carried out, progressive countering is triggered or an execution stream is guided to enter an error path, and therefore under the condition that the program performance is slightly influenced, the reverse and dynamic debugging resisting capacity of a program is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of computer software security protection technology, specifically to a program maze protection method based on jump statements and distributed encrypted maps. Background Technology

[0002] With the rapid development of the software industry, commercial software, sensitive algorithm programs, and core business systems face increasingly severe security threats such as reverse engineering, code tampering, and authorization bypassing. Software security protection technology has become a key support for safeguarding software intellectual property rights and operational security. Among these, code obfuscation technology, as one of the core means of software protection, effectively resists static reverse engineering and dynamic debugging by attackers by disrupting the control flow structure of the original program and increasing analysis complexity. It is widely used in scenarios such as commercial software authorization protection, core algorithm protection in the financial sector, and anti-tampering of industrial control programs.

[0003] Currently, among the mainstream program security protection technologies: 1. Control Flow Flattening is a software protection technique similar to this approach. This technique disrupts the original program's clear control flow structure, placing all basic blocks of functions or code within a unified scheduling loop. The jump relationships between these basic blocks are managed by a central scheduler, which determines the next basic block to execute based on the values ​​of one or more state variables. However, this technique has drawbacks such as a fixed model, susceptibility to automated cracking scripts, lack of anti-debugging capabilities, and permanent failure of static protection after a single crack.

[0004] 2. Hardware Dongle A hardware lock is a physical device, typically plugged into a computer's USB port. Software needs to detect the presence of a specific hardware lock or read critical data or code from it during runtime. This approach has significant drawbacks: high hardware costs, potential software malfunction due to physical damage or loss, and more complex deployment. Poorly designed hardware locks can also conflict with other peripherals, such as printers.

[0005] 3. Source Code Encryption Source code encryption attempts to transparently encrypt source code within the development environment and combine it with user permissions to prevent data leakage. However, due to the complex process call relationships during source code compilation and debugging, encryption operations can easily cause the development environment to lag, slow down, or even crash, impacting development efficiency. Furthermore, some encryption schemes may contain security vulnerabilities; for example, encrypted content may be accessible to memory scanning tools under certain conditions.

[0006] 4. Code Obfuscation Code obfuscation reduces code readability by renaming variables and methods, inserting obsolete code, and altering control flow. Its primary purpose is to increase the difficulty for attackers to analyze and reverse engineer the code. However, obfuscated code may run less efficiently, and for experienced attackers, it can only delay, not completely prevent, analysis.

[0007] 5. Virtualization Protection For example, the classic VMP replaces all instructions in the program code with custom instructions, which are then interpreted and executed by the virtual machine engine. Its drawback is that each instruction needs to be interpreted, leading to a significant performance degradation. Secondly, its static nature makes it vulnerable to a one-time crack. The state transition logic of this technology remains static and deterministic in each program run. An attacker only needs to draw the complete state transition diagram through a single dynamic debugging session to create a universal crack patch, achieving a one-time crack that is universally applicable. This makes it unsuitable for continuous protection needs in scenarios where the program is repeatedly launched or runs across multiple devices.

[0008] Meanwhile, with the continuous upgrading of software attack methods and the increasing maturity of automated deobfuscation tools, existing technologies are no longer sufficient to meet the needs of scenarios with high requirements for code logic security (such as high security and high performance). Existing software protection technologies (such as simple code encryption and anti-debugging) are mostly variations of publicly available technologies, and can often be identified and targeted by automated shell detection tools (such as Detect it Easy). There is an urgent need to design a completely new defense technology to resist the automated analysis of existing software cracking tools. This new solution should break through the limitations of fixed patterns, static protection, and passive defense, achieving a novel software protection scheme that prevents one-time cracking, is low-cost, has minimal impact on performance, and provides collaborative protection. Through innovative protection logic design, the ability of software to resist static analysis and dynamic debugging can be fundamentally improved, eliminating the risk of one-time cracking and protecting software intellectual property rights and operational security. Summary of the Invention

[0009] In view of the shortcomings of existing technologies, the purpose of this invention is to overcome the fixed patterns, static nature, and passive defense defects of existing software code obfuscation technologies based on control flow flattening, as well as the high cost, susceptibility to one-time cracking, and existence of corresponding software cracking tools of other software protection technologies. This invention provides a program maze protection method based on jump statements and distributed encrypted maps, which breaks the fixed patterns of traditional control flow obfuscation, avoids the risk of one-time cracking, improves the concealment and security of core boot information, and realizes the transformation from static passive defense to dynamic active defense. While ensuring that the normal functioning of the original program is not affected and that program performance is not excessively impacted, this invention meets the security needs of scenarios such as commercial software license protection, sensitive algorithm code protection, and anti-tampering of core business programs.

[0010] To achieve the above objectives, the technical solution adopted by this invention is: a program maze protection method based on jump statements and distributed encrypted maps, comprising: (1) Control flow analysis and maze construction: Analyze the original program, construct a control flow diagram containing multiple basic program blocks, replace some of the paths with intersection paths containing conditional jumps, equivalent paths (equivalent blocks) and composite path segments formed by the transformation and combination of error paths, and form a program maze structure with multiple correct execution paths and error paths. The correct execution paths are equivalent to the functions of the original program. (2) Initialization block and random path: An initialization block is set up to randomly select one of the multiple correct execution paths as the target correct path for this run when the program starts, and tamper with or forge the related instructions or dependency data of other correct paths, so that the other correct paths are invalid. This invalidation design makes the maze map extracted for a certain run likely to fail in the next run, making it impossible to crack stably; (3) Maze map and segmented encryption: A binary maze map is generated based on the correct jump behavior sequence of each condition jump intersection in the program maze. The map is then divided into multiple map segments and encrypted symmetrically. These segments are then distributed and hidden in different storage areas of the protected program as data. (4) Navigator and dynamic index: A navigator is implanted in the protected program. When the execution flow reaches the maze intersection, the navigator calculates the index value of the maze map based on the current instruction address and the internally maintained execution context information. Then, it locates and decrypts specific map fragments according to the index, reads the corresponding map positions, and controls the specific behavior of the jump statement accordingly, guiding the program to execute along the correct logical flow or run the incorrect logical flow. (5) Sentinel points and exception handling: Sentinel points are set on some paths of the program maze to detect whether it is in a debugging environment and the integrity of the maze map or other anomalies. When an anomaly is detected, progressive countermeasures are triggered and / or the execution flow is guided to the wrong path, thereby blocking the correct execution of the original program function.

[0011] Furthermore, in step (1), the control flow analysis of the original program is a static analysis at the binary level or intermediate representation level; the partial control flow edge is the function body corresponding to the function call or the branch statement corresponding to the conditional branch jump in the control flow graph of the original program.

[0012] Furthermore, in step (1), the equivalent block is 2 to 3 equivalent program blocks generated based on each basic block of the original program, with only simple changes. The equivalent block is the basis for the "deformation" of the program maze. The error path is the code block that ultimately leads to the program triggering illegal instructions, a crash scenario with a division by zero error, getting stuck in an infinite loop, or outputting a carefully constructed error result. The indirect path segment also includes redundant computation blocks and opaque predicate blocks. The redundant computation blocks are code blocks that perform mathematical or logical operations that have no actual function but are complex and time-consuming. The redundant computation blocks are subjected to instruction-level obfuscation processing, such as equivalent instruction replacement and garbage instruction insertion. The opaque predicate blocks are Boolean judgments whose results are determined (always true or always false) when written in the offline protection stage. They are constructed through complex expressions and are difficult to deduce through static analysis. They are used to wrap the real condition judgments to create false branches.

[0013] Furthermore, in step (1), the conditional jump intersection is constructed based on architecture-adaptive jump statements: if the original program runs on x86 architecture, the jump statement is a JCC instruction such as JZ instruction, JNZ instruction, JE instruction; if the original program runs on ARM architecture, the jump statement is a BXX instruction such as B instruction, BL instruction.

[0014] Furthermore, in step (3), each bit of the binary maze map corresponds to the correct execution direction of a conditional jump intersection in the program maze, where "1" indicates that the control jump statement is executed and "0" indicates that the control jump statement is not executed; the number of the multiple map segments is K, where K is a positive integer.

[0015] Furthermore, in step (4), the formula for calculating the maze map index value is: Index=H(Current_Instruction_Pointer⊕Local_Execution_Context)modL, Where H is a non-cryptographic hash function with good avalanche effect, Current_Instruction_Pointer is the memory address of the current conditional jump intersection code, Local_Execution_Context is the context value that changes with the execution flow, L is the total length of the binary maze map, and mod is the modulo operation.

[0016] Furthermore, the Local_Execution_Context is a local counter that increments with each access to a single-line maze intersection (a maze intersection that the program will not execute multiple times), or the value of the local counter after transformation by a mathematical identity; and the Local_Execution_Context includes a Boolean value indicating whether the time taken for the program to run to the preset node during initialization is greater than the reference value of 3 seconds, so that the Local_Execution_Context takes different values ​​in debug mode and non-debug mode.

[0017] Furthermore, before calculating the maze map index value, the Current_Instruction_Pointer is processed with a random base address or the random base address function of the original program is disabled to ensure that the instruction address used in the index calculation is consistent with the code layout when the program maze is constructed in the offline protection stage.

[0018] Furthermore, in step (3), the key used for symmetric encryption of each map segment is derived from the random number generated in the offline protection phase corresponding to steps (1) to (3) or the specific data of the original program; the different storage areas of the protected program include the global variable area, the static constant area, the memory area to be injected, and the gap of debugging information generated by the compiler.

[0019] Furthermore, in step (5), the progressive countermeasures are escalated step by step according to the severity of the anomaly, specifically including: Level 1 (Performance Degradation): Inserting meaningless loops and time-consuming operations significantly slows down the execution speed of the protected program, thus interfering with debugging efficiency; Level 2 (Function Restriction): Silently disables non-core or advanced functions of the protected program, causing the program to appear to have some functions disabled. Level 3 (Data Pollution): Maintaining the appearance of a protected program running normally by outputting carefully crafted, seemingly reasonable but actually erroneous data to mislead attackers; Level 4 (Delayed Crash): Instead of immediately triggering program termination at the anomaly detection point, the program crashes at a seemingly unrelated code location far from the protection point during subsequent execution to hide the protection logic.

[0020] The present invention adopts the above technical solution, and the specific beneficial effects are as follows: In this invention, by replacing some control flow edges of the original program with a program maze structure composed of conditional jump intersections, equivalent blocks, redundant computation blocks, opaque predicate blocks, and error path blocks, the original clear control flow is broken into a complex maze form with multiple correct execution paths and multiple error execution paths superimposed. Moreover, the correct execution paths are functionally equivalent to the original program. This fundamentally breaks away from the traditional flattened scheduling loop and fixed pattern of state variables in control flow, significantly increases the complexity of static analysis and control flow recovery, and enhances the resistance to automated deobfuscation tools.

[0021] In this invention, an initialization block is generated during the maze construction process. Each time the program starts, one of the multiple correct execution paths is randomly selected as the target correct path for this run. The maze nodes and / or data associated with other correct paths are tampered with or forged. At the same time, combined with the navigator mechanism that calculates the maze map index value based on the current instruction address and local execution context, the maze map is strongly bound to the specific running instance. Even if an attacker completely extracts the maze map and control flow in a single run, it is difficult to reuse them in subsequent runs or cross-device environments. This effectively avoids the problem of one-time cracking and the long-term effectiveness of general patches.

[0022] In this invention, the binary maze map is divided into multiple map segments according to its bit structure. Each map segment is encrypted using a symmetric encryption algorithm combined with random numbers generated during the offline protection phase or specific data from the original program. The encrypted map segments are then disguised as ordinary data such as global variables, static constants, memory areas to be injected, or gaps in debugging information and stored in a dispersed and hidden manner. Combined with the method of locating and decrypting the target map segment by index during navigator operation, the concealment and anti-tampering ability of the core guidance information are greatly improved. It is difficult for attackers to locate and restore the complete maze map in one go through static analysis, thereby enhancing the overall protection strength and reliability.

[0023] In this invention, by setting sentinel points at certain points along the program path, and by actively detecting the debugging environment and abnormal intervention behaviors through methods such as detecting debugger process window titles, checking debugger signatures, maze map indexes, and decryption result anomalies, and responding step by step with a progressive countermeasure strategy of performance degradation, function restriction, data pollution, and delayed crash when anomalies are detected, the debugger is guided to the wrong path or the program is terminated at a delayed position. This upgrades the static passive defense that simply hides the control flow to an active defense mechanism that can actively interfere with the debugging process and increase the cost of dynamic analysis, thus comprehensively improving the overall protection capability against static reverse engineering and dynamic debugging attacks. Attached Figure Description

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

[0025] Figure 1 This is a flowchart of the program maze protection method of the present invention; Figure 2 This invention performs maze-like reconstruction and generates a protected program flowchart; Figure 3 This is a flowchart of the program maze navigation and anti-debugging process during the online execution phase of this invention; Figure 4 This is a schematic diagram of the evolution of the program control flow of the present invention from its original form to a maze structure. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0027] Example 1 like Figure 1 As shown, this embodiment provides a program maze protection method based on jump statements and distributed encrypted maps, including: (1) Control flow analysis and maze construction: Analyze the original program, construct a control flow diagram containing multiple basic program blocks, replace some of the paths with intersection paths containing conditional jumps, equivalent paths (equivalent blocks) and composite path segments formed by the transformation and combination of error paths, and form a program maze structure with multiple correct execution paths and error paths. The correct execution paths are equivalent to the functions of the original program. (2) Initialization block and random path: An initialization block is set up to randomly select one of the multiple correct execution paths as the target correct path for this run when the program starts, and tamper with or forge the related instructions or dependency data of other correct paths, so that the other correct paths are invalid. This invalidation design makes the maze map extracted for a certain run likely to fail in the next run, making it impossible to crack stably; (3) Maze map and segmented encryption: A binary maze map is generated based on the correct jump behavior sequence of each condition jump intersection in the program maze. The map is then divided into multiple map segments and encrypted symmetrically. These segments are then distributed and hidden in different storage areas of the protected program as data. (4) Navigator and dynamic index: A navigator is implanted in the protected program. When the execution flow reaches the maze intersection, the navigator calculates the index value of the maze map based on the current instruction address and the internally maintained execution context information. Then, it locates and decrypts specific map fragments according to the index, reads the corresponding map positions, and controls the specific behavior of the jump statement accordingly, guiding the program to execute along the correct logical flow or run the incorrect logical flow. (5) Sentinel Points and Exception Handling: Sentinel points are set on some paths of the program maze to detect whether it is in a debugging environment and the integrity of the maze map or other anomalies. When an anomaly is detected, progressive countermeasures are triggered and / or the execution flow is redirected to the wrong path, thereby blocking the correct execution of the original program function.

[0028] As one implementation method, in step (1) of this embodiment, the control flow analysis of the original program is a static analysis at the binary level or intermediate representation level; the partial control flow edge is the function body corresponding to the function call or the branch statement corresponding to the conditional branch jump in the control flow graph of the original program.

[0029] This implementation constructs the control flow graph at the binary level and / or intermediate representation level, and prioritizes function call edges and conditional branch jump edges as maze replacement objects. This allows the maze reconstruction to directly affect the key control flow backbone of the original program, maximizing the destruction of the readability and predictability of the original control flow without changing the original functional semantics. This increases the difficulty for attackers to perform static analysis and reconstruct the real execution path based on the control flow graph.

[0030] As one implementation method, in step (1) of this embodiment, the equivalent block is 2 to 3 equivalent program blocks generated based on each basic block of the original program with only simple changes. The equivalent block is the "deformation" basis of the program maze; the error path is the code block that ultimately leads to the program triggering illegal instructions, a crash scenario with a division by zero error, getting stuck in an infinite loop, or outputting a carefully constructed error result. The indirect path segment also includes redundant computation blocks and opaque predicate blocks. The redundant computation blocks are code blocks that perform mathematical or logical operations that have no actual function but are complex and time-consuming. The redundant computation blocks are subjected to instruction-level obfuscation processing, such as equivalent instruction replacement and garbage instruction insertion. The opaque predicate blocks are Boolean judgments whose results are determined (always true or always false) when written in the offline protection stage. They are constructed through complex expressions and are difficult to deduce through static analysis. They are used to wrap the real condition judgments to create false branches.

[0031] By generating 2-3 equivalent blocks with only simple changes based on each original basic block, multiple functionally equivalent but instruction-form alternative paths exist for the same logical location in the program maze, thus providing a structural basis for subsequent random path selection of the initialization block. At the same time, redundant computation blocks and opaque predicate blocks are introduced to insert a large number of complex calculations with no practical effect and complex Boolean judgments of always true / always false into the control flow. On the one hand, this further increases the understanding cost during static analysis and dynamic tracing. On the other hand, combined with the carefully constructed results of erroneous paths, it makes it difficult for attackers to determine which path is the real and valid path even if they obtain partial path information, thus increasing the effect of misleading and confusing.

[0032] As one implementation method, in step (1) of this embodiment, the conditional jump intersection is constructed based on the architecture-adaptive jump statement: if the original program runs on the x86 architecture, the jump statement is a JCC jump instruction such as JZ instruction, JNZ instruction or JE instruction; if the original program runs on the ARM architecture, the jump statement is a BXX jump instruction such as B instruction, BL instruction or BX instruction.

[0033] By constructing maze entrances using native conditional jumps or branch instructions on different processor architectures, the program maze structure can be seamlessly embedded into the original compilation output, avoiding the introduction of additional virtual instruction sets or interpretation layers. While maintaining execution efficiency and compatibility, the maze entrances are difficult to distinguish from ordinary branch instructions at the instruction level, thereby reducing the possibility of attackers quickly filtering key nodes of the maze based on instruction patterns.

[0034] As one implementation method, in step (3) of this embodiment, each bit of the binary maze map corresponds to the correct execution direction of at least one conditional jump intersection in the program maze, where "1" indicates that the control jump statement is executed and "0" indicates that the control jump statement is not executed; the number of the multiple map segments is K, where K is a positive integer.

[0035] This implementation uses binary bit sequences to represent the maze map, encoding the correct direction at intersections as 0 / 1, making the map data structure compact, the access logic simple, and easy to combine with hash index calculations. At the same time, the overall map is divided into K discontinuous map fragments, which are encrypted and stored separately. Even if an attacker obtains some fragments through static analysis, it is difficult to reconstruct the complete correct path information in the absence of other fragments and index rules, thereby improving the security of core guidance data.

[0036] As one implementation method, in step (4) of this embodiment, the formula for calculating the maze map index value is: Index=H(Current_Instruction_Pointer⊕Local_Execution_Context)modL, Where H is a non-cryptographic hash function with good avalanche effect, Current_Instruction_Pointer is the memory address of the current conditional jump intersection code, Local_Execution_Context is the context value that changes with the execution flow, L is the total length of the binary maze map, and mod is the modulo operation.

[0037] By employing an unencrypted hash function with an avalanche effect to combine the current instruction address and local execution context and take the modulo of the map length, this implementation makes the index value highly sensitive to small changes in the input. This causes the context offset, execution path deviation, or instruction address relocation caused by debugging behavior to cause a large change in the index value, thereby accessing the wrong map position and causing the execution flow to naturally deviate into the wrong path. This transforms debugging and tampering behavior into conditions for the attacker to trigger the protection.

[0038] As one implementation method, in this embodiment, Local_Execution_Context is a local counter that increments with each access to a single-line maze intersection (a maze intersection that the program will not execute multiple times), or the value of the local counter after transformation by a mathematical identity; and Local_Execution_Context includes a Boolean value indicating whether the time taken for the program to run to a preset node during initialization is greater than a reference value of 3 seconds, so that Local_Execution_Context takes different values ​​in debug mode and non-debug mode.

[0039] By selecting a single-line maze intersection as the counting granularity, the local counter has a unique and predictable incremental sequence under the normal execution path. Then, by superimposing mathematical identity transformations and Boolean values ​​based on runtime thresholds, this implementation method encodes the execution path order and the existence of long-term pauses (such as single-step debugging and breakpoint suspension) into Local_Execution_Context without introducing additional external dependencies. This naturally reflects the difference between debugging and not debugging during the index calculation stage, which is beneficial for identifying abnormal debugging behavior without affecting the normal user experience.

[0040] As one implementation method, in this embodiment, before calculating the maze map index value, the Current_Instruction_Pointer is processed with a random base address or the random base address function of the original program is disabled to ensure that the instruction address used in the index calculation is consistent with the code layout when the program maze is constructed in the offline protection stage.

[0041] By explicitly controlling the address space layout on which Current_Instruction_Pointer is based before index calculation, this implementation ensures the stability of the address correspondence between offline maze map construction and online index calculation, avoiding index misalignment under normal execution conditions due to offsets introduced by the address randomization mechanism. Thus, while taking into account the address security mechanism, it ensures the predictability and reliable operation of the maze index logic.

[0042] As one implementation method, in step (3) of this embodiment, the key used for symmetric encryption of each map piece is derived from the random number generated in the offline protection stage corresponding to steps (1) to (3) or the specific data of the original program; the different storage areas of the protected program include the global variable area, the static constant area, the memory area to be injected, and the gap of debugging information generated by the compiler.

[0043] This implementation method generates map shard encryption keys using random numbers and specific data from the original program during the offline protection phase. This results in differences in key combinations and shard content between different protected program instances. In addition, the encrypted map shards are disguised as ordinary global variables, static constants, memory areas to be injected, or debug padding data and embedded in a dispersed manner. This significantly increases the difficulty for attackers to extract map data based on signature comparison or fixed offset, and reduces the risk of key leakage or the entire map being extracted at once.

[0044] As one implementation method, in step (5) of this embodiment, the progressive countermeasures are escalated step by step according to the severity of the anomaly, specifically including: Level 1 (Performance Degradation): Inserting meaningless loops and time-consuming operations significantly slows down the execution speed of the protected program, thus interfering with debugging efficiency; Level 2 (Function Restriction): Silently disables non-core or advanced functions of the protected program, causing the program to appear to have some functions disabled. Level 3 (Data Pollution): Maintaining the appearance of a protected program running normally by outputting carefully crafted, seemingly reasonable but actually erroneous data to mislead attackers; Level 4 (Delayed Crash): Instead of immediately triggering program termination at the anomaly detection point, the program crashes at a seemingly unrelated code location far from the protection point during subsequent execution to hide the protection logic.

[0045] By designing the countermeasure strategy as a multi-level progressive process from performance degradation and functional limitation to data pollution and delayed crash, this implementation does not simply and rudely terminate the program immediately when suspicious debugging behavior or indexing and decryption anomalies are detected. Instead, it gradually increases the interference intensity based on the frequency and severity of the anomalies, so that attackers will continuously encounter performance degradation, functional anomalies and result distortion during long-term debugging. This increases the cost and uncertainty of their ability to locate the real protection point and restore the real logic. At the same time, by using delayed crash, the program termination behavior is decoupled from the real detection point, which helps to mask the location and triggering conditions of the protection logic.

[0046] This embodiment, based on the maze-like reconstruction of the original program control flow, achieves a tight binding between the maze structure and the specific running instance through random path selection and path data tampering of the initialization block, fragmented encryption and scattered hiding of the binary maze map, dynamic index navigation based on the current instruction address and local execution context, and an active protection mechanism combining sentinel point detection and progressive countermeasures. It automatically guides attackers into incorrect paths or subjectes them to performance and result interference when they perform static analysis or dynamic debugging. Thus, compared with existing control flow flattening and simple encryption and redundant insertion schemes, it significantly improves the comprehensive protection capabilities against one-time cracking, automated deobfuscation and dynamic debugging attacks.

[0047] Example 2 This embodiment further explains the protection concept of the present invention from the perspective of program logic and instruction flow.

[0048] In this embodiment, the essence of a program can be understood as a logical structure. Software protection essentially adds extra redundant logic to the original program logic. This redundant logic itself does not contribute positively to the program's functionality and may even incur some performance overhead, but it can significantly increase the analysis and cracking costs for attackers. From the instruction level, software can be regarded as several instruction streams. The instruction stream logic is nothing more than two types: sequential execution and jump execution. For the sequential execution part, it can be processed through instruction equivalent substitution, code bloat, encryption and decryption, etc. (which may also include some jump execution). For the jump execution part, it can be combined with system-level mechanisms to set hooks or other protection logic at logic execution points that are not easily detected by attackers, so as to achieve runtime interception and protection.

[0049] Building upon existing program protection technologies, this embodiment proposes a novel protection approach: analogizing jump instructions in a program to real-life intersections, a "maze" can be constructed within the program if intersections can be simulated. To this end, without altering the original program's final execution result, numerous additional instructions are interwoven and inserted with the existing logic to form a program maze structure. Each maze is accompanied by a "map," a string of binary data, such as 100110011…, where 1 indicates a jump at the current intersection, and 0 indicates no jump at the current intersection. Each time the execution flow passes through a maze intersection (such as a JCC-type conditional jump statement), the value of the corresponding bit in the map determines whether a jump is executed: when following the path indicated by the map, the program executes the original functional code along the preset correct path; when deviating from the map's indicated path or jumping arbitrarily, the execution flow typically gets "lost" in the maze, leading to program crashes or entering other pre-designed incorrect routes. Therefore, a large number of JCC statements are added to the original program execution flow to form a "program maze". By controlling the jump behavior through map data, the program execution logic can be protected.

[0050] This embodiment provides a specific implementation method. Its core lies in inserting a large number of JCC statements into the original program, forming a maze-like structure. This hides the correct execution path within it. The entire solution is divided into an offline protection phase and an online execution phase.

[0051] like Figure 2 As shown, the offline protection stage of this invention takes the original program as input, performs a maze-like reconstruction on it, and generates a protected program. The specific process is as follows: Original program input: The original program to be protected (which can be a compiled binary or intermediate representation) is used as the input object for the offline protection stage, in preparation for analyzing and rewriting its control flow and data structure.

[0052] Static analysis and construction of control flow graph (CFG): Perform static analysis at the binary level or intermediate representation level on the original program to identify each basic block and the control flow transfer relationship between the basic blocks, and construct a control flow graph (CFG) to provide a precise structural blueprint for subsequent maze-like reconstruction.

[0053] Generate equivalent blocks, initialization blocks, error paths, and sentinel points: Based on CFG, generate multiple equivalent blocks with only simple changes to the original basic blocks, and design initialization blocks for randomly selecting the correct path, error path blocks for guiding the execution flow into error scenarios such as crashes or infinite loops, and reserve sentinel points at key locations such as maze entrances, exits, and main branches for subsequent embedding of anti-debugging detection and exception judgment logic.

[0054] Generate a program maze structure and insert redundant blocks and error paths: Based on the aforementioned CFG and maze nodes, replace the selected key control flow edges in the original program with indirect path segments composed of conditional jump intersections, equivalent blocks, redundant computation blocks, opaque predicate blocks, and error path blocks, constructing a program maze structure containing multiple correct execution paths and multiple error execution paths, and embed the original functional code into these paths.

[0055] Generate maze map and build index structure (support dynamic indexing): For the correct jump behavior of each conditional jump intersection in the program maze, generate the corresponding binary maze map, encode the correct execution direction of each intersection as 0 / 1 bits, and design the indexing method of the map in conjunction with the dynamic indexing mechanism of the subsequent online execution stage, so that the map can be located according to the current instruction address and local execution context.

[0056] Disassemble the maze map and encrypt each piece separately: Divide the complete maze map into multiple discontinuous map pieces, encrypt each piece separately using a symmetric encryption algorithm, and configure corresponding keys for different pieces. This prepares the map for later disguised as ordinary data and dispersed and hidden in different storage areas of the protected program.

[0057] Navigator Generation: Based on the aforementioned dynamic index design and encrypted map structure, the navigator generation module is used to calculate the map index value according to the current instruction address and local execution context during program runtime, locate and decrypt the target map piece, read the corresponding map position, and drive the corresponding conditional jump instruction to jump or not jump. At the same time, it works with the sentinel point logic to detect and handle abnormal behavior.

[0058] Linking and assembling the protected program: Through code instrumentation and linking techniques, the generated maze structure, initialization block, error path block, sentry point logic, encrypted map fragments, and navigator module are linked and assembled with the original program, and issues such as address relocation are handled, finally outputting a complete protected program.

[0059] Protection is applied, and the program enters the online execution phase: At this point, the offline protection phase ends, and the protected program will enter the online execution phase during actual deployment and runtime. The navigator and the maze structure will jointly protect the program's execution logic.

[0060] like Figure 3 As shown, the program maze navigation and anti-debugging process of this invention during the online execution phase is as follows: User runs protected program: When a user starts a protected program that has undergone the offline protection phase, the executable file is loaded into memory, and the program begins to run according to the maze-like control flow structure.

[0061] Initialize and enter the maze main loop: The program first executes the initialization logic, restores or establishes the local execution context, counters and other states required for the maze to run, and then enters the maze main loop. All subsequent business code and maze logic are repeatedly executed in this main loop.

[0062] Normal execution continues until an intersection is encountered: Before reaching the maze intersection, the program executes each basic block (including business code block, equivalent block, redundant calculation block, etc.) in the current control flow order. When the execution flow reaches the conditional jump instruction marked as a maze intersection, it is considered to have "encountered an intersection" and proceeds to the next step of processing.

[0063] Calculate the dynamic index I = H(PC ⊕ Context) When the execution flow reaches a maze intersection, the navigator invokes the dynamic index calculation logic to calculate the maze map index value based on the instruction address (PC) of the current intersection code and the local execution context (Context) maintained within the maze. I = H(PC⊕Context) mod L = H(PC ⊕ Context) \ mod L = H(PC⊕Context) mod L, which is used to determine the target location to be queried in the maze map.

[0064] The navigator queries a specified map segment and dynamically decrypts it to determine whether a redirect is necessary. The navigator locates the corresponding map segment based on index I, dynamically decrypts it using the key corresponding to that segment, and reads the map location corresponding to index I from the decryption result to determine whether to "jump" or "not jump" at the current intersection.

[0065] According to the map position control program flow: when the map position is 1, the corresponding branch "map position = 1 / 'execute jump to the next node'" in the map, the navigator controls the execution of the current condition jump instruction to jump to the preset next node; When the map position is 0, corresponding to the branch "Map position = 0 / 'Execute sequentially to the next node'" in the diagram, the navigator controls the current conditional jump instruction not to jump, and the program executes the path sequentially to the next node.

[0066] Continue execution by executing the code at the current node: Whether the program reaches the next node through a jump or sequential execution, it executes the corresponding business code or internal maze logic at that node. After completing the calculation and state update of the current node, it continues to execute until it reaches the sentinel node or a new maze intersection.

[0067] When encountering a sentinel node, determine if the program is in a debugging environment: When the execution flow reaches a pre-deployed sentinel node, execute the sentinel detection logic to check the current running environment and determine if the program is in an abnormal state such as a debugging environment. If the result is "no", that is, no debugging behavior is detected, return to the step of "normal execution until an intersection is encountered" along the path marked "no" on the right side of the diagram, and continue running in the main loop of the maze.

[0068] Yes—triggering gradual countermeasures If the sentinel's judgment result is "yes", that is, it confirms that the program is in a debugging environment or there is an abnormal situation, then it will follow the "yes" branch in the diagram to enter the "trigger progressive countermeasures" node, and execute measures such as performance degradation, function restriction, data pollution, and delayed crash according to the preset progressive countermeasure strategy to interfere with and attack the attacker's dynamic debugging behavior.

[0069] Through the above-described cyclical process, the protected program runs under the combined effect of the maze main loop, dynamic map navigation, and sentinel detection throughout the entire operation. On the one hand, it ensures that normal users can complete the program functions along the correct path, and on the other hand, it triggers corresponding countermeasures when debugging or anomalies are detected, thereby improving the overall security of the program.

[0070] The following is an extended explanation of this embodiment: Step 1: Deep Control Flow Analysis and Maze Reconstruction The original program is analyzed at the binary or intermediate representation level to accurately construct its control flow graph (CFG, which can be simply understood as a program flowchart). This graph consists of basic blocks (nodes) and control flow transitions (edges). Equivalent blocks are generated simultaneously, allowing for multiple paths at each program startup. Subsequently, this CFG is used as a blueprint for "maze-like" expansion. Specifically, for each critical edge in the original CFG (e.g., function calls, jumps after conditional branches), it is replaced with a non-direct path segment consisting of multiple maze nodes. Each path segment is a miniature control flow graph containing: Equivalent blocks: Based on each program block, generate 2-3 equivalent program blocks with only minor changes. Equivalent blocks are the foundation of the "morphing" maze, designed to allow the program to take a random correct route and generate a corresponding map each time it starts, then destroy other "correct paths." This mechanism ensures that the correct map cracked last time becomes invalid on the next run.

[0071] Conditional Jump Crossroads: The core of this node is a conditional jump instruction (such as JZ, JNZ, JE, etc. in x86 architecture), whose jump direction is determined by the subsequent maze map, and it is a key point for protection.

[0072] Redundant computation blocks: These are complex and time-consuming mathematical or logical operations that have no practical effect, such as looping calculations on meaningless variables, increasing code size and analysis difficulty. During this process, instruction-level obfuscation can be performed, such as equivalent instruction substitution and garbage instruction insertion, further enhancing the difficulty of static analysis. Since these are redundant blocks that will not be executed, they do not degrade program performance.

[0073] Opaque predicates: These are Boolean judgments whose results are determined at the time of writing (always true or always false), but constructed through complex expressions, making them difficult for static analysis to deduce. These predicates are used to wrap real conditional judgments, creating false branches. This is a traditional code obfuscation technique; for example, `a^2>0` is a judgment expression that is always true but will not be optimized away by the compiler, aiming to increase false paths and interfere with analysis.

[0074] Error path: Points to a block of code that will eventually cause the program to crash (such as triggering an illegal instruction, division by zero error), get stuck in an infinite loop, or output a carefully crafted error result.

[0075] Map Generation: In this process, the original clear control flow is replaced by a large, complex "program maze." The original basic blocks are embedded in the maze, forming several "correct paths" from the entrance to the exit. To ensure the maze can be traversed correctly, a maze map indicating the correct paths is needed. This map is essentially a long binary bit sequence, where each bit (0 or 1) corresponds to the correct direction of one or more conditional jumps in the maze (e.g., 1 indicates a jump, 0 indicates no jump). At this step, the initial map should be generated. Figure 4 This is a simplified drawing analogy for easier understanding: (The program itself also has branches, but here we only concern ourselves with the logic we added.) like Figure 4 The diagram shown illustrates the gradual evolution of the program control flow from its original form to a maze structure in this invention.

[0076] exist Figure 4 The left side shows a simplified representation of the control flow of the original program. The execution path is simplified to a single top-down path. In reality, there are numerous jumps at the business logic branches, but since all jumps are business logic, attackers can directly and clearly understand the original program logic by disassembling it. To clearly illustrate the extended logic of this solution on the original program, all business logic branches are simplified to a linear structure and are not illustrated.

[0077] exist Figure 4The middle section represents the structure after inserting a small number of JCC conditional jump intersections into the original control flow. It serves to demonstrate the basic implementation logic of this solution. By adding several intersection nodes to the original linear path and introducing equivalent blocks, redundant blocks, or simple branches, the originally clear business logic execution route is transformed into a broken-line, multi-branch path structure. This maze-like path lacks actual business logic characteristics, significantly increasing the cost of attacks.

[0078] exist Figure 4 On the right, we see a maze-like structure formed by repeatedly inserting intersections, equivalent blocks, redundant computation blocks, and erroneous paths. At this point, the original clear program business logic flow is filled with various jump-based "intersections," creating a complex maze. The correct execution path is hidden among numerous pseudo-paths and erroneous paths. Attackers, when performing static analysis or dynamic tracing, find it difficult to quickly identify which path corresponds to the truly valid business logic. This vividly illustrates the overall approach of this invention: gradually complicating and maze-ifying the control flow by "continuously adding JCC intersections and maze nodes."

[0079] As above Figure 4 The map is 001110, which indicates whether each intersection has a turn.

[0080] Initialization block: Due to the existence of equivalent blocks, there are multiple correct execution paths in the program. The initialization block should be responsible for randomly selecting one path and then shuffling the other paths (by arbitrarily modifying or deliberately forging some data). It is responsible for randomly transforming the maze each time the program starts.

[0081] Step 2: Dynamic Index Calculation Mechanism In the third step, we will shuffle and encrypt the map data, but before that, let's add some logic. Normally, map usage is done step by step. However, dynamic index calculation makes the specific location depend not only on Current_Instruction_Pointer (which intersection we are currently at) but also on Local_Execution_Context (runtime environment factors). This mechanism aims to achieve "non-one-time" protection, essentially hoping the map has Turing capabilities, detecting whether the current map user is a legitimate user, not a software attacker. At each maze intersection, the system does not directly use sequential indexes but instead queries the map using a dynamically calculated index value. From another perspective, we want the way the map is viewed to become more complex. On the one hand, it seems to perform some kind of normal logical judgment before JCC (Junior Crack Object) to interfere with the attacker's perception; on the other hand, even if the attacker knows the intention, it can prevent the attacker from permanently cracking the map after obtaining it once. The calculation formula for the map index is as follows: Index = H( Current_Instruction_Pointer ⊕ Local_Execution_Context ) mod L H: A fast, non-cryptographic hash function (such as XXHash, FNV-1a) with good avalanche effect, used to mix and compress the input into a fixed-length output.

[0082] Current_Instruction_Pointer: The memory address of the currently executing maze intersection code. This value strongly binds the index to the physical location of the code. (Random base addressing needs to be handled or disabled.) Local_Execution_Context: A context value maintained within the maze path and changing with the execution flow. This value must be deterministic under the correct execution sequence. A concrete implementation could be: A local counter that increments with each visit to a one-way maze intersection (a one-way intersection refers to an intersection that the program will not execute multiple times, such as some initialization code; otherwise, if it's a button function or something unpredictable, it would lead to randomness in the result). Based on this, some mathematical identities can be transformed.

[0083] This value can differ between debug and non-debug modes to achieve an anti-debugging effect. For example, adding a Boolean value equal to whether the time taken for the program to initialize and reach a certain point is greater than 3 seconds. Obviously, a value of 0 obtained in non-debugging mode will not interfere with the index value.

[0084] L: Total length of the maze map (in bits).

[0085] mod: Modulo operation, ensuring that the result falls within the valid index range of [0, L-1].

[0086] This dynamic indexing mechanism ensures that even for maze intersections with the same logical function, the queried map location will be completely different in different program runtime environments due to differences in time pauses caused by attacker debugging. In addition to maze protection, necessary protection is also implemented at the map level. Note: The maze is responsible for protecting the code logic from reverse engineering. Map protection, on the other hand, protects against program cracking. Usually, the two protections are intertwined because software authorization verification mechanisms are also part of the code logic.

[0087] Step 3: Dispersing and Hiding the Maze Map To enhance protection, this invention employs a segmented map management strategy: 1. Map Tile: Dividing a complete map sequence into K discontinuous regions is called map tile (Fragment_1, Fragment_2, ..., Fragment_K).

[0088] 2. Independent Encryption: Each map tile uses a different encryption key (Key_1, Key_2, ..., Key_K) for symmetric encryption. These keys may originate from random numbers generated during the protection phase or be related to program-specific data.

[0089] 3. Distributed Hiding: The encrypted map fragments are treated as ordinary data and can be distributed and hidden in multiple memory segments throughout the program's binary image, such as the global variable area, static constant area, memory allocation injection area, and even gaps in compiler-generated debugging information. This distribution makes it difficult for attackers to locate and extract all map data at once.

[0090] Step 4: Generate a protected program Subsequently, using a technique similar to automated code instrumentation, the generated maze structure, encrypted map tile data, map decryption and index calculation logic (navigator), and integrity verification code are linked with the original program blocks to generate the final program. During this process, care must be taken to handle tasks such as address relocation.

[0091] When a protected program runs, its execution flow is as follows: 1. Maze Navigation: When the execution flow enters the maze area, the navigator begins operation. At each intersection, it first calculates the dynamic index I according to the formula above. Subsequently, the navigator locates the corresponding map tile, decrypts it using the corresponding key, and extracts the value of the I-th bit. Based on this bit value (0 or 1), the program executes the corresponding conditional jump, thereby determining whether to proceed to the next correct node or mistakenly enter the wrong path.

[0092] 2. Sentinel Points in the Execution Flow: To proactively detect whether the execution flow has been tampered with by the debugger or has experienced unexpected jumps, sentinel points are embedded at key nodes in the maze (such as entrances, exits, and main branches). At each sentinel point, various existing anti-debugging techniques can be executed: for example, detecting programs with the window title "x64dbg" (a classic debugger), detecting signature codes, and so on.

[0093] 3. Progressive Countermeasure Strategy: When the sentinel detects an anomaly or other issues (such as map decryption errors), the system will not immediately crash, but will trigger a progressive countermeasure process. This process escalates countermeasures step by step based on the frequency or severity of the anomaly: Level 1: Performance degradation. Inserting meaningless loops and time-consuming operations significantly slows down program execution, interfering with the debugger's experience and efficiency.

[0094] Level 2: Functionality Restriction. Silently disables certain non-core or advanced functions of the program, causing the program to behave as if some functions are disabled.

[0095] Level 3: Data Pollution. This allows the program to continue running and producing output, but the output is carefully crafted, seemingly reasonable but actually erroneous data, misleading attackers into believing the analysis was successful.

[0096] Level 4: Delayed crash. Instead of crashing immediately at the detection point, the program terminates during subsequent execution at a seemingly unrelated code location far from the protection point, greatly increasing the difficulty for attackers to locate the detection point.

[0097] This "soft" failure mechanism can effectively consume the attacker's time and energy, and protect the core detection logic from being easily discovered.

[0098] Compared with the prior art, this embodiment has the following significant advantages and effects: 1. It achieves software protection, completely and in stages avoiding script kiddie attack patterns: this is the most crucial effect. Many attackers lack strong reverse engineering skills. When faced with this new type of protective shell, traditional cracking tools and reverse engineering methods will be helpless.

[0099] 2. Enhanced resistance to dynamic analysis and debugging: The dynamic indexing mechanism strongly correlates execution paths with code locations and execution sequences. Attackers using debuggers for single-step tracing or setting breakpoints inevitably alter the local execution context (e.g., causing abnormal incrementing order of local counters or corrupting context values ​​passed in registers), leading to subsequent index calculation errors. Wrong paths "stumbled" into the maze can trigger alarms. Combined with progressive countermeasures, it is no longer a fragile "one-touch" vulnerability that exposes protection points; delayed crashes make protection logic difficult to detect. This multi-layered, non-immediate resistance, this "cat-and-mouse game" design—from interference (slowing down) to deception (error output) to a hidden fatal blow (delayed crash)—significantly increases the attacker's analysis costs, psychological pressure, and uncertainty, transforming static passive defense into dynamic proactive maneuvering. This sets up a systemic obstacle for dynamic analysis that is difficult to circumvent with simple patching.

[0100] 3. Features methods to prevent one-time cracking: Unlike existing protection technologies, many shells can be easily replicated by attackers after they have spent considerable time analyzing the protection process. This embodiment uses equivalent blocks and random correct paths. The complete map data extracted by an attacker through arduous dynamic analysis during a single run becomes completely ineffective after the target program is restarted or moved to another machine. This embodiment changes the paradigm of software protection from static "hiding" to dynamic "change," and transforms the cost of cracking from a "one-time investment" to "continuous consumption," greatly improving protection strength and cost-effectiveness.

[0101] 4. A deep and organic integrated defense system is formed: This solution is not a simple aggregation of various technologies such as control flow obfuscation, data encryption, and time-based anti-debugging, but rather a deep coupling of them into an organic whole, adding new defense concepts. The maze's structure depends on the map, map access is controlled by dynamic indexes, index access is protected by sentinels, and the sentinels are hidden within the maze. This interlocking design makes each layer of protection interdependent and mutually reinforcing, making it difficult for attackers to find a single breakthrough point. Breaking one link cannot dismantle the entire system, forming a synergistic defense effect of "1+1>2".

[0102] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A program maze protection method based on jump statements and distributed encrypted maps, characterized in that: include: (1) Analyze the original program, construct a control flow diagram containing multiple basic program blocks, replace some of the paths with a composite path segment consisting of a combination of intersection paths containing conditional jumps, equivalent paths, and error paths, and form a program maze structure with multiple correct execution paths and error paths. The correct execution paths are equivalent to the functions of the original program. (2) Set an initialization block. When the program starts, it randomly selects one of the multiple correct execution paths as the target correct path for this run, and tampers with or forges the related instructions or dependency data of other correct paths, so that other correct paths are invalid. The invalidation design makes the maze map extracted for a certain run likely to fail in the next run, and cannot be stably cracked. (3) Generate a binary maze map based on the correct jump behavior sequence of each condition jump intersection in the program maze, divide it into multiple map pieces and symmetrically encrypt them, and then hide them as data in different storage areas of the protected program. (4) A navigator is implanted in the protected program. When the execution flow reaches the maze intersection, the navigator calculates the index value of the maze map based on the current instruction address and the execution context information maintained internally. Then, it locates and decrypts the specific map fragments according to the index, reads the corresponding map positions, and controls the specific behavior of the jump statement accordingly, guiding the program to execute along the correct logical flow or run the wrong logical flow. (5) Set up sentinel points on some paths of the program maze to detect whether it is in a debugging environment and the integrity of the maze map or other anomalies. When an anomaly is detected, trigger progressive countermeasures and / or redirect the execution flow to the wrong path, thereby blocking the correct execution of the original program function.

2. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 1, characterized in that: In step (1), the control flow analysis of the original program is a static analysis at the binary level or intermediate representation level; the partial control flow edge is the function body corresponding to the function call or the branch statement corresponding to the conditional branch jump in the control flow graph of the original program.

3. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 1, characterized in that: In step (1), the equivalent block is 2 to 3 equivalent program blocks generated based on each basic block of the original program with only simple changes. The equivalent block is the basis for the "deformation" of the program maze. The error path is the code block that ultimately leads to the program triggering illegal instructions, a crash scenario with a division by zero error, getting stuck in an infinite loop, or outputting a carefully constructed error result. The error path also includes redundant computation blocks and opaque predicate blocks. The redundant computation blocks are code blocks that perform mathematical or logical operations that have no actual function but are complex and time-consuming. The redundant computation blocks are subjected to instruction-level obfuscation processing, such as equivalent instruction replacement and garbage instruction insertion. The opaque predicate blocks are Boolean judgments whose results are determined (always true or always false) when written in the offline protection stage. They are constructed through complex expressions and are difficult to deduce through static analysis. They are used to wrap false branches that make real condition judgments.

4. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 1, characterized in that: In step (1), the conditional jump intersection is constructed based on the architecture-adaptive jump statement: if the original program runs on the x86 architecture, the jump statement includes at least one or more of the JZ instruction, JNZ instruction, JE instruction or JCC jump instruction; if the original program runs on the ARM architecture, the jump statement includes at least one or more of the B instruction, BL instruction, BX instruction or BXX jump instruction.

5. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 1, characterized in that: In step (3), each bit of the binary maze map corresponds to the correct execution direction of a conditional jump intersection in the program maze, where "1" indicates that the control jump statement is executed and "0" indicates that the control jump statement is not executed; the number of the multiple map segments is K, where K is a positive integer.

6. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 1, characterized in that: In step (4), the formula for calculating the maze map index value is: Index=H(Current_Instruction_Pointer⊕Local_Execution_Context)modL, Where H is a non-cryptographic hash function with good avalanche effect, Current_Instruction_Pointer is the memory address of the current conditional jump intersection code, Local_Execution_Context is the context value that changes with the execution flow, L is the total length of the binary maze map, and mod is the modulo operation.

7. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 6, characterized in that: The Local_Execution_Context is a local counter that increments with each visit to a single-line maze intersection (a maze intersection that the program will not execute multiple times), or the value of the local counter after being transformed by a mathematical identity; and the Local_Execution_Context contains a Boolean value indicating whether the time taken for the program to run to a preset node during initialization is greater than a preset time threshold, so that the Local_Execution_Context takes different values ​​in debug mode and non-debug mode.

8. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 6, characterized in that: Before calculating the maze map index value, the Current_Instruction_Pointer is processed with a random base address or the random base address function of the original program is disabled to ensure that the instruction address used in the index calculation is consistent with the code layout when the program maze is built in the offline protection stage.

9. The program maze protection method based on jump statements and distributed encrypted map construction according to claim 1, characterized in that: In step (3), the key used for symmetric encryption of each map piece is derived from the random number generated in the offline protection phase corresponding to steps (1) to (3) or the specific data of the original program; the different storage areas of the protected program include the global variable area, the static constant area, the memory area to be injected, and the gap of debugging information generated by the compiler.

10. The program maze protection method based on jump statements and distributed encrypted map construction according to any one of claims 1 to 9, characterized in that: In step (5), the progressive countermeasures are escalated step by step according to the severity of the anomaly, specifically including: Level 1 (Performance Degradation): Inserting meaningless loops and time-consuming operations significantly slows down the execution speed of the protected program, thus interfering with debugging efficiency; Level 2 (Function Restriction): Silently disables non-core or advanced functions of the protected program, causing the program to behave as if some functions are disabled. Level 3 (Data Pollution): Maintaining the appearance of a protected program's normal operation by outputting carefully crafted, seemingly reasonable but actually erroneous data to mislead attackers; Level 4 (Delayed Crash): Instead of immediately triggering program termination at the anomaly detection point, the program crashes at a seemingly unrelated code location far from the protection point during subsequent execution to hide the protection logic.

Images