Two-way mutual debugging and self-debugging methods, systems, equipment and media

Abstract

The bidirectional mutual debugging and self-debugging method, system, device, and medium provided in this disclosure include: Process A executes various business logics included in a main program, and detects the running status of each business logic during the execution of the main program; when the running status of a target business logic is detected to be abnormal, it sends a debugging request to Process B and changes the execution status of the target business logic to a paused state; Process B responds to the debugging request and obtains abnormal trigger information; based on the abnormal trigger information, Process B determines the target business logic that needs to be migrated and run, and after completing the migration of the target business logic, it switches the program counter to point to the target business logic; Process B modifies the program counter of the paused target business logic in Process A to point to the start address of the next running business logic. It can independently complete the abnormal signal perception and debugging instruction response execution, ensuring complete information transmission without leakage.

Description

Technical Field

[0001] This invention relates to the field of software debugging technology and related technical fields, specifically to a bidirectional mutual debugging and self-debugging method, system, device, and medium. Background Technology

[0002] With the rapid development of software systems, anti-debugging technology has gradually become the primary defense mechanism against reverse engineering. Especially in license protection schemes and security hardening toolchains, anti-debugging is often the most basic link. From the earliest Windows API attack detection functions such as CheckRemoteDebuggerPresent(), to system-level PEB structure field checks (BeingDebugged, NtQueryInformationProcess), and then to injection debugging traps (breakpoints, trap scheduling tables), these technologies all serve one goal—to prevent the intervention of illegal debugging behavior.

[0003] Existing publicly available intermediate anti-debugging frameworks such as Themida, VMProtect, and Enigma Protector also widely utilize the aforementioned technical interfaces. However, with the emergence of more mature tools such as x64dbg and custom plugins for Cheat Engine, this type of anti-debugging logic is easily bypassed by attackers through proxy spoofing, hooking deception, and debugging signal interception. More importantly, these techniques are all based on passively occupying the operating system's debugging lifecycle, lacking the proactive control flexibility at the organizational structure level.

[0004] The introduction of self-debugging mechanism was once considered an important direction to break through the old defenses. Its core idea is that the running program actively generates a debugging child process (or another thread in the same process) to attach to itself. Most operating systems only support a single debugger attaching process at a time, thus blocking the attachment requests from illegal external debuggers.

[0005] However, the existing self-debugging mechanism has the following three typical problems:

[0006] 1. Attackers can debug the debugger itself. Once the debugger mechanism, breakpoint response path, and privileged event hooks are exposed, the protection mechanism is reversed.

[0007] 2. The self-debugger build path is too explicit, and calls to debugging interfaces such as ptrace() and DebugActiveProcess() are easily detected, instrumented, and replaced at the assembly code level;

[0008] 3. The self-debugging interface call process uses standard exception interrupts / signals (such as SIGTRAP, INT3, etc.) to expose the link before and after. The new reverse engineering tool can accurately simulate the processing of key signals through path prediction and re-execution of the path, thereby achieving "bypass slippage".

[0009] Therefore, there is an urgent need for a two-way mutual debugging and self-debugging method to solve the problems existing in the current technology. Summary of the Invention

[0010] The embodiments described herein provide a bidirectional mutual debugging and self-debugging method, system, device, and medium that address the problems existing in the prior art.

[0011] Firstly, according to the content of this disclosure, a self-debugging method without bidirectional mutual debugging is provided, applied to a software anti-debugging system, wherein the software anti-debugging system includes process A and process B, comprising:

[0012] Process A executes the business logics included in the main program, and detects the running status of each business logic during the execution of the main program. When it detects that the running status of the target business logic is abnormal, it sends a call debugging request to process B and changes the execution status of the target business logic to a paused state.

[0013] The process B responds to the call debugging request and obtains exception trigger information, wherein the exception trigger information includes exception trigger address, exception code and exception context information;

[0014] Based on the abnormal triggering information, process B determines the target business logic that needs to be migrated and run, and after completing the migration of the target business logic, switches the program counter to point to the target business logic.

[0015] Process B modifies the program counter of the target business logic that is in a suspended state in process A to point to the start address of the next running business logic.

[0016] In some embodiments of this disclosure, before process A executes the various business logics included in the main program and detects the running status of each business logic during the execution of the main program, the process further includes:

[0017] In response to the received start instruction signal, a mutual attachment and debugging mechanism between process A and process B is established.

[0018] In some embodiments of this disclosure, the step of establishing a mutual attachment and debugging mechanism between process A and process B in response to a received startup indication signal includes:

[0019] In response to the received start instruction signal, process A starts the main program and launches process B;

[0020] Process A attaches itself to process B as a debugger based on the operating system's debug attachment interface, establishing a standard debug session mechanism with process B.

[0021] After initialization, process B attaches itself to process A as a debugger based on the operating system's debug attachment interface and establishes a standard debug session with process A.

[0022] In some embodiments of this disclosure, process B determines the target business logic that needs to be migrated and run based on the exception triggering information, and after completing the migration of the target business logic, switches the program counter to point to the target business logic, including:

[0023] Process B determines the exception type based on the exception triggering information;

[0024] Based on the exception context information of the exception triggering information, the encapsulation information is extracted, wherein the encapsulation information includes exception source address information, register group address information, stack frame address information, call instruction address information, call type, program counter value, action ID, opcode and operation parameters;

[0025] Based on the encapsulation information, the target business logic that needs to be migrated and run is determined, and after the migration of the target business logic is completed, the program counter is switched to point to the target business logic.

[0026] In some embodiments of this disclosure, process B determines the exception type based on the exception triggering information, including:

[0027] Process B determines the source of the anomaly based on the anomaly trigger address and anomaly code in the anomaly trigger information;

[0028] Process B determines the exception type based on the source of the exception.

[0029] In some embodiments of this disclosure, extracting encapsulation information based on the exception context information of the exception triggering information includes:

[0030] Based on the exception context information of the exception triggering information, the state information at the time of the exception is extracted, wherein the state information includes exception source address information, register group address information, stack frame address information, call instruction address information, call type and program counter value;

[0031] Read the signal fingerprint information pre-written by process A, wherein the signal fingerprint information includes action ID, operation code and operation parameters;

[0032] The encapsulation information is determined based on the status information and the signal fingerprint information.

[0033] In some embodiments of this disclosure, determining the target business logic to be migrated and run based on the encapsulation information, and switching the program counter to point to the target business logic after completing the migration of the target business logic, includes:

[0034] Based on the encapsulation information, determine the target business logic that needs to be migrated and run;

[0035] When the target business logic is the main business logic included in the main program, the program counter is switched to point to the target business logic.

[0036] Secondly, based on the content of this disclosure, a software anti-debugging system is provided, which performs the bidirectional mutual debugging and self-debugging method as described in any of the first aspects.

[0037] Thirdly, according to the present disclosure, a computer device is provided, comprising:

[0038] One or more processors;

[0039] Storage device for storing one or more programs.

[0040] When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any of the first aspects.

[0041] Fourthly, according to the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the methods described in any of the first aspects.

[0042] The bidirectional mutual debugging and self-debugging method, system, device, and medium provided in this disclosure firstly involve process A executing the various business logics included in the main program, and detecting the running status of each business logic during the execution of the main program. When the running status of the target business logic is detected to be abnormal, a debugging request is sent to process B, and the execution status of the target business logic is changed to a paused state. Then, process B responds to the debugging request, obtains the abnormal trigger information, and determines the target business logic that needs to be migrated and run based on the abnormal trigger information. After completing the migration of the target business logic, process B switches the program counter to point to the target business logic. Finally, process B modifies the program counter of process A to the start address of the next running business logic. By establishing a peer-to-peer debugging process structure, namely two logical entities running in parallel for a long time—the protected application process and the self-debugger agent process—these two processes complete mutual attachment and debugging during the initialization phase after system startup. One process attaches to the other as a debugging process, and the attached process then unattaches itself, forming a peer-to-peer "debug role rotation mechanism." In this way, process A and process B can independently complete the detection of abnormal signals and the execution of debugging instructions throughout the entire program lifecycle without the need for an external debugger, forming a complete closed-loop control structure. In this structure, the two parties are equal, and each abnormal response is accompanied by a small-scale switch of the debugger role and task dispatch. The debugger controller's startup state, paused state, decryption state, verification state, and other structures rely on the context buffer as a relay to ensure that information is transmitted completely but not leaked.

[0043] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0045] Figure 1 This is a flowchart illustrating a bidirectional mutual debugging and self-debugging method provided in an embodiment of this disclosure;

[0046] Figure 2 This is an interactive schematic diagram of a bidirectional mutual debugging and self-debugging method provided in an embodiment of this disclosure;

[0047] Figure 3 This is a schematic diagram of the structure of a bidirectional mutual debugging and self-debugging device provided in an embodiment of this disclosure;

[0048] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure.

[0049] In the accompanying diagram, markers with the same last two digits correspond to the same elements. It should be noted that the elements in the diagram are schematic and not drawn to scale. Detailed Implementation

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

[0051] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the specification and in the relevant art, and shall not be interpreted in an idealized or overly formal form unless otherwise explicitly defined herein. As used herein, the statement of “connecting” or “coupling” two or more parts together shall mean that these parts are directly joined together or joined through one or more intermediate components.

[0052] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of the phrase "embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0053] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists, A and B exist simultaneously, or B exists. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0054] Furthermore, in all embodiments of this disclosure, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

[0055] In the description of this application, unless otherwise stated, "multiple" means two or more (including two), and similarly, "multiple groups" means two or more (including two groups).

[0056] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0057] Based on the problems existing in the prior art, this disclosure provides a bidirectional mutual debugging and self-debugging method. This method is applied to a software anti-debugging system, which includes process A and process B. Figure 1 This is a flowchart illustrating a bidirectional mutual debugging and self-debugging method provided in an embodiment of this disclosure. Figure 2 This is an interactive schematic diagram of the bidirectional mutual debugging and self-debugging method provided in the embodiments of this disclosure, combined with... Figure 1 and Figure 2 The specific process of the two-way mutual debugging and self-debugging method includes:

[0058] S110. Process A executes the business logic included in the main program, and detects the running status of each business logic during the execution of the main program. When it detects that the running status of the target business logic is abnormal, it sends a call debugging request to process B and changes the execution status of the target business logic to a paused state.

[0059] The bidirectional mutual debugging and self-debugging method provided in this disclosure first establishes a mutual attachment debugging mechanism between process A and process B in the software anti-debugging system. These two processes attach to each other during the initialization phase, playing the roles of debugger and debugged. When one of them causes an exception, the other intervenes in the exception capture process through the debugger mechanism. This debugger does not have general debugging functions and is highly customized, and can only be used to respond to internal signals or context switching included in the main program defined in this disclosure. When the debugging roles need to be swapped, the currently active debugger manipulates the exception-throwing process, and the original debugger and debugged roles are swapped.

[0060] For example, a software anti-debugging system includes process A and process B. When process A is the debugger, process B is the debugged. When process B is the debugger, process A is the debugged. In the software anti-debugging system, the process acting as the debugger is the protected application process, and the process acting as the debugged is the self-debugging process.

[0061] Processes A and B complete mutual attachment and debugging during the initialization phase after system startup. One process attaches to the other as a debugging process, while the attached process then unattaches itself, forming an equal "debug role rotation mechanism." In this way, processes A and B can independently complete the detection of abnormal signals and the execution of debugging instructions throughout the entire program lifecycle without the need for an external debugger, forming a complete closed-loop control structure.

[0062] In this software anti-debugging system, a specific example is used to illustrate the concept. Process A is the "protected application process", and process B is the "self-debugging process". Process A runs the various business logics included in the main program, and detects the running status of any business logic during the execution of the main program. When it detects that the running status of the target business logic is abnormal, it sends a call to debug to process B.

[0063] It should be noted that during its execution, process A will generate exception signals in various ways (such as hidden code, illegal mapped memory access, soft division by zero, etc.), and then convert the exception signals into debugger call debugging requests. These debug calls are dispatched to process B through operating system signals, and are received and processed by process B.

[0064] The specific implementation process of process A generating exception signals during runtime involves process A proactively generating "controllable" exceptions in a pre-programmed manner at business logic-sensitive locations (such as decryption, authorization, etc.). Common practices include:

[0065] 1. Hardware anomalies: such as null pointer dereference (accessing address 0), accessing unmapped memory, illegal instructions (such as executing an unauthorized OPCODE), or attempting to write to a read-only segment;

[0066] 2. Arithmetic exceptions: such as integer / floating-point division by zero, overflow;

[0067] 3. Software exceptions: Calling raise(SIGTRAP), int 3 (x86 architecture breakpoint), software breakpoint insertion;

[0068] 4. Access violation: Unauthorized access to cross-segment areas, read / write restricted areas;

[0069] 5. Other techniques: Requesting non-existent resources from the kernel (such as illegal file handle operations);

[0070] Among them, the generated abnormal signals need to balance concealment and controllability, that is, the abnormal signals can only be "captured" by process A and judged as expected behavior, preventing interference from external Dbg or error collectors.

[0071] S120, Process B responds to the call debugging request and obtains the exception trigger information.

[0072] The exception triggering information includes the exception triggering address, exception code, and exception context information.

[0073] Process B acts as a "self-debugger process." When process A sends a debug request to process B, process B enters an "exception capture state." Internally, process B runs a lightweight microkernel debugger ring that identifies the exception type, extracts encapsulation information, confirms the target instruction, restores the local context, and then transfers control to the target business logic. At this point, the roles switch; process A, originally the "caller," is paused, and the "target migration code" in process B begins execution, continuing until another exception is issued. Next, the process reverses, entering the small debugger run by process A for processing.

[0074] In the specific implementation logic, when process A sends a debug call request to process B, process B responds to the debug call request and reads the exception trigger information that caused the exception in process A, that is, it reads the exception trigger address, exception code and exception context information that caused the exception.

[0075] S130. Based on the exception triggering information, process B determines the target business logic that needs to be migrated and run, and after completing the migration of the target business logic, switches the program counter to point to the target business logic.

[0076] When process A triggers a debug request during its execution, process B immediately responds by entering "debugger" mode. It then categorizes, analyzes, and handles the exception trigger information accordingly. This mechanism distributes the execution path of critical business logic across both ends, dynamically migrating and hiding it, making it difficult for attackers to trace or set breakpoints to locate the core logic. The debugger role can perform deep inspection and repair of memory, registers, thread context, and exception throwing environment, blocking unauthorized external debuggers from intervening. Simultaneously, in conjunction with the exception throwing mechanism, it proactively triggers process migration and dynamic discrimination, ensuring that security protection is built within a constantly switching and unpredictable internal debugging environment.

[0077] In the specific implementation, process B determines the target business logic that needs to be migrated and run based on the exception triggering information, and after completing the migration of the target business logic, switches the program counter of process B to point to the target business logic. This includes: process B determining the exception type based on the exception triggering information; extracting encapsulation information based on the exception context information of the exception triggering information, wherein the encapsulation information includes the exception source address information, register group address information, stack frame address information, call instruction address information, call type, program counter value, action ID, opcode, and operation parameters at the time the exception occurred; determining the target business logic that needs to be migrated and run based on the encapsulation information, and switching the program counter to point to the target business logic after completing the migration of the target business logic.

[0078] In this process, process B determines the exception type based on the exception triggering information, including: process B determines the exception source based on the exception triggering address and exception code in the exception triggering information; and process B determines the exception type based on the exception source.

[0079] Step S110 states that during its execution, process A generates exception signals through various means (such as hidden code, illegal mapped memory access, soft division by zero, etc.). Therefore, the exception address and exception code of the generated exception signals are known. When process B receives the debug call request, it first obtains the exception trigger information from process A, and then determines the source of the exception based on the exception trigger address and exception code in the exception trigger information. That is, it determines whether the exception trigger information is generated by a specified segment or classified business forgery, or a random crash. When it is determined that the exception trigger information is generated by a specified segment or classified business forgery, process B matches the corresponding exception type according to the exception source.

[0080] After determining the exception type, the encapsulation information is extracted based on the exception context information of the exception triggering information. The encapsulation information includes the register group, stack frame, call instruction address, action ID, exception source address, parameters / operation data, call type, original program counter value, and stack top snapshot at the time of the exception.

[0081] Specifically, firstly, based on the exception context information of the exception triggering information, the state information at the time of the exception is extracted. The state information includes the exception source address information, register group address information, stack frame address information, call instruction address information, call type, and program counter value. Then, the signal fingerprint information pre-written by process A is read. The signal fingerprint information includes the action ID, opcode, and operation parameters, such as the mode code inserted into a certain register and the next action information (e.g., "jump to the re-encryption address, opcode is 3"). Finally, based on the state information and signal fingerprint information, the encapsulation information is determined.

[0082] After determining the encapsulation information, the target business logic that needs to be migrated and run is determined based on the encapsulation information, and after the target business logic migration is completed, the program counter is switched to point to the target business logic.

[0083] Specifically, first, the target business logic to be executed is determined based on the opcode in the extracted encapsulation information. Then, it is verified whether this target business logic is included in the main program. If the target business logic is included in the main program, the target business logic is migrated to process B, and the actual memory location of the target business logic in process B after migration is locked. Finally, the program counter is switched to point to the target business logic.

[0084] S140. Process B modifies the program counter of the target business logic in process A, which is in a suspended state, to point to the start address of the next running business logic.

[0085] The fundamental purpose of modifying the program counter of the target business logic in process A, which is currently in a suspended state, is to achieve "secure migration" and "execution path obfuscation" of the code flow. After process A detects that the target business logic is in an abnormal running state, process A is currently in a suspended debugging state. If process B intervenes and directly restores the program counter address of process A, attackers can easily reproduce and predict the flow. Conversely, by modifying the program counter of process A (i.e., the address of the next instruction to be executed) under specific exception or signal-driven conditions, the business logic can be redirected to a remapped, hidden, or encrypted / verified new code block.

[0086] The above settings can dynamically obfuscate the execution path, making it difficult for attackers to restore the static flow; prevent breakpoints and hooks, making it difficult for attackers to grasp the stable key instruction flow, making code fragments / protection logic highly dynamic in space and time; implement kernel-level protection actions such as unlocking, verification, or authorization, such as jumping into special self-check blocks; and work closely with signal mechanisms and information injection to facilitate the transfer of temporary sensitive data such as parameters, commands, and keys.

[0087] Modifying the program counter is the key to "transforming abnormal signals into secure business actions," enabling a deep integration of business processes and security protection.

[0088] Specifically, after switching the program counter to point to the target business logic, processes B and A switch roles. Process B becomes the protected application process, and process A becomes the self-debugging process. Process B executes the target business logic and monitors its running status during execution. When process B detects an abnormal running status, it sends a debug request to process A. At this point, process A acts as the debugger and responds to process B's debug request. This process may be repeated, forming a double-sided execution loop collaboration mechanism. After all alternations are complete, the process enters the [close mutual debugging state & cleanup] phase, which includes dissolving the debugger relationship, releasing the occupied debug session and state management area, and destroying the temporary instruction cache. Ultimately, this process ensures that the entire protection module maintains the design principles of minimum exposure surface, symmetric control, and diverse abnormal paths when resisting attackers' static symbol tracing, dynamic instruction stream interception, debugger injection separation, and other attack methods, while also meeting high-intensity anti-reverse engineering requirements.

[0089] Whether process B can correctly switch and execute migration code depends entirely on the "signal content" transmitted when A creates an exception. That is, when A intentionally creates an exception, it embeds pre-defined instruction codes, target addresses, or behavior type parameters at specific locations within the exception context (registers, dedicated memory, stack). B, as the debugging party, identifies the exception, decodes the "business segment that needs to be migrated / run" according to this information, and then switches the PC to point to that business area. This is a tightly coordinated "signal-action" protocol; if either party lacks the relevant agreement, the migration cannot be executed correctly, and the system will trigger a protective termination.

[0090] The bidirectional mutual debugging and self-debugging method provided in this embodiment first involves process A executing the business logics included in the main program, and detecting the running status of each business logic during the execution of the main program. When the running status of the target business logic is detected to be abnormal, a debugging request is sent to process B, and the execution status of the target business logic is changed to a paused state. Then, process B responds to the debugging request, obtains the exception trigger information, and determines the target business logic that needs to be migrated and run based on the exception trigger information. After completing the migration of the target business logic, process B switches the program counter to point to the target business logic. Finally, process B modifies the program counter of process A to the start address of the next running business logic. By establishing a peer-to-peer debugging process structure, namely two logical entities running in parallel for a long time—the protected application process and the self-debugger agent process—these two processes complete mutual attachment and debugging during the initialization phase after system startup. One process attaches to the other as a debugging process, and the attached process then unattaches itself, forming a peer-to-peer "debug role rotation mechanism." In this way, process A and process B can independently complete the detection of abnormal signals and the execution of debugging instructions throughout the entire program lifecycle without the need for an external debugger, forming a complete closed-loop control structure. In this structure, the two parties are equal, and each abnormal response is accompanied by a small-scale switch of the debugger role and task dispatch. The debugger controller's startup state, paused state, decryption state, verification state, and other structures rely on the context buffer as a relay to ensure that information is transmitted completely but not leaked.

[0091] Based on the above embodiments, the bidirectional mutual debugging and self-debugging method provided in this disclosure further includes, before executing step S110: in response to the received start indication signal, establishing a mutual attachment and mutual debugging mechanism between process A and process B.

[0092] In the specific implementation, in response to the received start indication signal, a mutual attachment and debugging mechanism between process A and process B is established, including: in response to the received start indication signal, process A starts the main program and launches process B; process A attaches itself as a debugger to process B based on the operating system's debug attachment interface, and establishes a standard debugging session mechanism with process B; after process B completes initialization, process B attaches itself as a debugger to process A based on the operating system's debug attachment interface, and establishes a standard debugging session with process A.

[0093] Specifically, the core of establishing a mutual attach and debug mechanism between process A and process B lies in the interconnection and binding between process A (the protected application process) and process B (the self-debugger process). When the system starts, process A launches its main program and simultaneously forks or restarts process B. Process A first uses the debugging attachment interface provided by the operating system (such as Linux's ptrace (PTRACE_ATTACH) or Windows' DebugActiveProcess / DebuggerAPI) to attach itself as a "debugger" to process B, establishing a standard debugging session mechanism with process B. After initialization, process B reattaches itself back to process A in the same way. The key to establishing this mutual attach and debug mechanism is that processes A and B act as debuggers for each other—each can listen to and capture the other's exceptions and instruction streams, forming an equal, independent, closed-loop debugging relationship without external debugger involvement. This mechanism is implemented through the operating system's low-level debugging APIs (signals, exceptions, breakpoints, etc.), ensuring that no third-party debugging session can intrude and preventing processes from being hijacked independently.

[0094] The purpose of the mutual attachment and debugging mechanism between process A and process B is to achieve autonomous control over exceptions, debugging events, and protected code segments through orchestrated mutual debugging relationships. Whenever one process (A or B) issues a debugging request during its execution, the other immediately responds by entering "debugger" mode, classifying, analyzing, and handling abnormal situations accordingly. This mechanism distributes the execution path of critical business logic across both ends, dynamically migrating and hiding it, making it difficult for attackers to trace or set breakpoints to locate core logic. The debugger role can perform deep inspection and repair of memory, registers, thread context, and exception-throwing environments, blocking unauthorized external debuggers from intervening. Simultaneously, in conjunction with the exception-throwing mechanism, it proactively triggers process migration and dynamic discrimination, ensuring that security protection is built within a constantly switching and unpredictable internal debugging environment.

[0095] Based on the above embodiments, this disclosure also provides a bidirectional mutual debugging and self-debugging device. The bidirectional mutual debugging and self-debugging device provided in this disclosure is applied to a software anti-debugging system, which includes process A and process B. Figure 3This is a schematic diagram of the structure of a bidirectional mutual debugging and self-debugging device provided in an embodiment of this disclosure, as shown below. Figure 3 As shown, the bidirectional mutual debugging and self-debugging device includes:

[0096] The debug request generation module 310 is used to execute the various business logics included in the main program, and to detect the running status of each business logic during the execution of the main program. When the running status of the target business logic is detected to be abnormal, a debug request is sent to the process B, and the execution status of the target business logic is changed to a paused state.

[0097] The exception trigger information acquisition module 320 is used to respond to the call debugging request and acquire exception trigger information, which includes exception trigger address, exception code and exception context information;

[0098] The switching module 330 is used to determine the target business logic that needs to be migrated and run based on the abnormal triggering information, and to switch the program counter to point to the target business logic after the migration of the target business logic is completed.

[0099] Modification module 340 is used to modify the program counter of the target business logic that is in a suspended state in process A to point to the start address of the next running business logic.

[0100] The bidirectional mutual debugging and self-debugging device provided in this embodiment firstly involves process A executing the various business logics included in the main program. During the execution of the main program, process A detects the running status of each business logic. When the running status of the target business logic is detected to be abnormal, process A sends a debugging request to process B and changes the execution status of the target business logic to a paused state. Then, process B responds to the debugging request, obtains the exception trigger information, and determines the target business logic that needs to be migrated and run based on the exception trigger information. After completing the migration of the target business logic, process B switches the program counter of process B to point to the target business logic. Finally, process B modifies the program counter of process A to the start address of the next running business logic. By establishing a peer-to-peer debugging process structure, namely two logical entities running in parallel for a long time—the protected application process and the self-debugger agent process—these two processes complete mutual attachment and debugging during the initialization phase after system startup. One process attaches to the other as a debugging process, and the attached process then unattaches itself, forming a peer-to-peer "debug role rotation mechanism." In this way, process A and process B can independently complete the detection of abnormal signals and the execution of debugging instructions throughout the entire program lifecycle without the need for an external debugger, forming a complete closed-loop control structure. In this structure, the two parties are equal, and each abnormal response is accompanied by a small-scale switch of the debugger role and task dispatch. The debugger controller's startup state, paused state, decryption state, verification state, and other structures rely on the context buffer as a relay to ensure that information is transmitted completely but not leaked.

[0101] In a specific implementation, before process A executes the various business logics included in the main program and checks the running status of each business logic during the execution of the main program, it further includes:

[0102] In response to the received start instruction signal, a mutual attachment and debugging mechanism between process A and process B is established.

[0103] In a specific implementation, the step of establishing a mutual attachment and debugging mechanism between process A and process B in response to the received startup indication signal includes:

[0104] In response to the received start instruction signal, process A starts the main program and launches process B;

[0105] Process A attaches itself to process B as a debugger based on the operating system's debug attachment interface, establishing a standard debug session mechanism with process B.

[0106] After initialization, process B attaches itself to process A as a debugger based on the operating system's debug attachment interface and establishes a standard debug session with process A.

[0107] In a specific implementation, process B determines the target business logic that needs to be migrated and run based on the exception triggering information, and after completing the migration of the target business logic, switches the program counter to point to the target business logic, including:

[0108] Process B determines the exception type based on the exception triggering information;

[0109] Based on the exception context information of the exception triggering information, the encapsulation information is extracted, wherein the encapsulation information includes the register group, stack frame, call instruction address, action ID, exception source address, parameter / operation data, call type, original program counter value and stack top snapshot at the time of the exception;

[0110] Based on the encapsulation information, the target business logic that needs to be migrated and run is determined, and after the migration of the target business logic is completed, the program counter is switched to point to the target business logic.

[0111] In a specific implementation, process B determines the exception type based on the exception triggering information, including:

[0112] Process B determines the source of the anomaly based on the anomaly trigger address and anomaly code in the anomaly trigger information;

[0113] Process B determines the exception type based on the source of the exception.

[0114] In a specific implementation, the step of extracting encapsulation information based on the exception context information of the exception triggering information includes:

[0115] Based on the exception context information of the exception triggering information, the state information at the time of the exception is extracted, wherein the state information includes exception source address information, register group address information, stack frame address information, call instruction address information, call type and program counter value;

[0116] Read the signal fingerprint information pre-written by process A, wherein the signal fingerprint information includes action ID, operation code and operation parameters;

[0117] The encapsulation information is determined based on the status information and the signal fingerprint information.

[0118] In a specific implementation, the step of determining the target business logic to be migrated and run based on the encapsulation information, and switching the program counter to point to the target business logic after completing the migration of the target business logic, includes:

[0119] Based on the encapsulation information, determine the target business logic that needs to be migrated and run;

[0120] When the target business logic is the main business logic included in the main program, the program counter is switched to point to the target business logic.

[0121] This application also provides a software anti-debugging system that executes the bidirectional mutual debugging and self-debugging method as described in any of the above embodiments, and has the beneficial effects described in any of the above embodiments. This disclosure does not provide specific details on this aspect.

[0122] This application also provides a computer device, please refer to the following for details. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0123] The computer device includes a memory 510 and a processor 520 that are interconnected via a system bus. It should be noted that only a computer device with components 510-520 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components may be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0124] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0125] The memory 510 includes at least one type of readable storage medium, including non-volatile memory or volatile memory, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. RAM may include static RAM or dynamic RAM. In some embodiments, the memory 510 may be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the memory 510 may also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, or flash card equipped on the computer device. Of course, the memory 510 may include both internal storage units and external storage devices of the computer device. In this embodiment, the memory 510 is typically used to store the operating system and various application software installed on the computer device, such as the program code of the method described above. In addition, the memory 510 may also be used to temporarily store various types of data that have been output or will be output.

[0126] The processor 520 is typically used to perform the overall operation of a computer device. In this embodiment, the memory 510 is used to store program code or instructions, including computer operation instructions. The processor 520 is used to execute the program code or instructions stored in the memory 510 or to process data, such as program code that runs the methods described above.

[0127] In this article, the bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus system can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0128] Another embodiment of this application also provides a computer-readable medium, which may be a computer-readable signal medium or a computer-readable medium. A processor in a computer reads computer-readable program code stored in the computer-readable medium, enabling the processor to execute the functional actions specified in each step or combination of steps in the above method; and to generate means for implementing the functional actions specified in each block or combination of blocks in the block diagram.

[0129] Computer-readable media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared memory or semiconductor systems, devices or apparatuses, or any suitable combination thereof, wherein the memory is used to store program code or instructions, the program code including computer operation instructions, and the processor is used to execute the program code or instructions of the above-described methods stored in the memory.

[0130] The definitions of memory and processor can be found in the description of the foregoing computer device embodiments, and will not be repeated here.

[0131] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0132] In the various embodiments of this application, the functional units or modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0133] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0134] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0135] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0136] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. A bidirectional mutual debugging and self-debugging method, applied to a software anti-debugging system, wherein the software anti-debugging system includes process A and process B, characterized in that, The process A executes each business logic included in the main program, detects a running state of each business logic in the process of executing the main program, and sends a call debugging request to the process B and converts an execution state of the target business logic to a pause state when detecting that the running state of the target business logic is an abnormal state. The process B acquires abnormal trigger information in response to the call debugging request, wherein the abnormal trigger information includes an abnormal trigger address, an abnormal code and abnormal context information. The process B determines the target business logic that needs to be migrated and run according to the abnormal trigger information, and switches a program counter to point to the target business logic after completing the migration of the target business logic. The process B modifies the program counter of the target business logic in the pause state in the process A to point to a start address of the next running business logic. The process A executes each business logic included in the main program, and before detecting a running state of each business logic in the process of executing the main program, further includes:

2. The method of claim 1, wherein, In response to the received start indication signal, a mutual attachment mutual debugging mechanism of the process A and the process B is established. In response to the received start indication signal, a mutual attachment mutual debugging mechanism of the process A and the process B is established.

3. The method of claim 2, wherein, In response to the received start indication signal, the process A starts the main program and pulls up the process B. The process A, based on a debugging attachment interface of an operating system, attaches itself to the process B as a debugger to establish a standard debugging session mechanism with the process B. After completing the initialization, the process B, based on the debugging attachment interface of the operating system, attaches itself to the process A as a debugger to establish a standard debugging session with the process A. The process B determines the target business logic that needs to be migrated and run according to the abnormal trigger information, and switches the program counter to point to the target business logic after completing the migration of the target business logic, including:

4. The method of claim 1, wherein, The process B determines an abnormal type according to the abnormal trigger information. According to the abnormal context information of the abnormal trigger information, encapsulation information is extracted, wherein the encapsulation information includes abnormal trace address information, register group address information, stack frame address information, call instruction address information, call type, program counter value, action ID, operation code and operation parameter. According to the encapsulation information, the target business logic that needs to be migrated and run is determined, and the program counter is switched to point to the target business logic after completing the migration of the target business logic. The process B determines an abnormal type according to the abnormal trigger information, including:

5. The method of claim 4, wherein, The process B determines an abnormal source according to the abnormal trigger address and the abnormal code of the abnormal trigger information. The process B determines the abnormal type according to the abnormal source. According to the abnormal context information of the abnormal trigger information, the encapsulation information is extracted, including:

6. The method of claim 4, wherein, ​ According to the abnormal context information of the abnormal trigger information, state information at the time of the abnormality is extracted, wherein the state information comprises abnormal trace address information, register group address information, stack frame address information, call instruction address information, call type and program counter value; Signal fingerprint information written in advance by the process A is read, wherein the signal fingerprint information comprises action ID, operation code and operation parameter; According to the state information and the signal fingerprint information, encapsulation information is determined.

7. The method of claim 4, wherein, According to the encapsulation information, target business logic needing to be migrated and run is determined, and after the migration of the target business logic is completed, the program counter is switched to point to the target business logic, comprising: According to the encapsulation information, target business logic needing to be migrated and run is determined; When the target business logic is business logic included in the main program, the program counter is switched to point to the target business logic.

8. A software anti-debugging system, which executes the bidirectional mutual debugging self-debugging method according to any one of claims 1-7.

9. A computer device, comprising: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, so that the one or more processors implement the method according to any one of claims 1-7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method according to any one of claims 1-7.

Images