Bidirectional mutual-debugging and self-debugging method, system, equipment and medium

Abstract

The embodiment of the invention provides a bidirectional mutual-debugging and self-debugging method and system, equipment and a medium, and the method comprises the steps that a process A executes each business logic included in a main program, detects the running state of each business logic in the process of executing the main program, and sends the target business logic to a process B when the running state of the target business logic is detected to be an abnormal state; a debugging calling request is sent to the process B, and the execution state of the target service logic is converted into a pause state; the process B responds to the debugging calling request and obtains abnormal triggering information; the process B determines a target service logic needing to be migrated and operated according to the abnormal trigger information, and switches a program counter to point to the target service logic after the target service logic is migrated; and the process B modifies the program counter of the target service logic in the pause state in the process A to point to the starting address of the next running service logic. Abnormal signal sensing and debugging instruction response execution can be independently completed, and it is ensured that information is completely transmitted without leakage.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software debugging and related technical fields, in particular, to a bidirectional mutual debugging self-debugging method, system, device and medium. BACKGROUND

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

[0003] Existing public intermediate anti-debugging frameworks such as Themida, VMProtect, Enigma Protector, etc. also widely use the above technical interfaces. However, with the emergence of more mature tools such as x64dbg, Cheat Engine custom plugins, this type of anti-debugging logic is also vulnerable to attacker proxy spoofing, hook deception, and debugging signal interception, thus bypassing it. More critically, these technologies are all based on passive possession of the operating system debugging life cycle, and lack active control flexibility at the organizational structure level.

[0004] The proposal of the self-debugging mechanism was once considered an important direction to break through the old defenses, with the core idea being that a running program generates a debugging child process (or another thread in the same process) attached to itself, and most operating systems only support a single debugger attached to a process at the same time, thus blocking external illegal debugger attachment requests.

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

[0006] 1. Attackers can debug the self-debugger itself, and once the debugger mechanism, breakpoint response path, and privileged event hook are exposed, the protection mechanism is reversed;

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

[0008] 3. The self-debugging interface call flow uses standard exception interrupts / signals (such as SIGTRAP, INT3, etc.) before and after the link exposure, and the new reverse tool can accurately simulate the key signal processing through path prediction and re-execution path, thereby realizing "bypass slip".

[0009] Therefore, there is an urgent need for a bidirectional mutual debugging self-debugging method to solve the problems existing in the prior art. SUMMARY

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

[0011] In a first aspect, according to the content of the disclosure, a bidirectional mutual debugging self-debugging method is provided, applied to a software anti-debugging system, the software anti-debugging system including a process A and a process B, comprising:

[0012] The process A executes each business logic included in a main program, detects the running state of each business logic in the process of executing the main program, and sends a call debugging request to the process B when detecting that the running state of a target business logic is an abnormal state, and converts the execution state of the target business logic to a pause state;

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

[0014] The process B determines a 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;

[0015] The process B modifies the program counter of the target business logic in the pause state in the process A to point to the start address of the next running business logic.

[0016] In some embodiments of the disclosure, before the process A executes each business logic included in a main program and detects the running state of each business logic in the process of executing the main program, it further comprises:

[0017] In response to the received start indication signal, a mutual additional mutual debugging mechanism of the process A and the process B is established.

[0018] In some embodiments of the disclosure, in response to the received start indication signal, the mutual additional mutual debugging mechanism of the process A and the process B is established, comprising:

[0019] In response to the received start indication signal, the process A starts the main program and pulls up the process B;

[0020] The process A, based on a debugging attachment interface of an operating system, attaches itself to the process B as a debugger, and establishes a standard debugging session mechanism with the process B;

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

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

[0023] The process B determines an exception type according to the exception triggering information;

[0024] According to exception context information of the exception triggering information, encapsulation information is extracted, wherein the encapsulation information includes exception 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;

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

[0026] In some embodiments of the present disclosure, the process B determines an exception type according to the exception triggering information, including:

[0027] The process B determines an exception source according to an exception triggering address and an exception code of the exception triggering information;

[0028] The process B determines an exception type according to the exception source.

[0029] In some embodiments of the present disclosure, the encapsulation information is extracted according to exception context information of the exception triggering information, including:

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

[0031] Signal fingerprint information pre-written by the process A is read, wherein the signal fingerprint information includes action ID, operation code and operation parameter;

[0032] According to the state information and the signal fingerprint information, encapsulation information is determined.

[0033] In some embodiments of the present disclosure, the determining the target business logic that needs to be migrated and run according to the encapsulation information, and switching the program counter to point to the target business logic after completing the migration of the target business logic, comprises:

[0034] determining the target business logic that needs to be migrated and run according to the encapsulation information;

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

[0036] In a second aspect, according to the content of the present disclosure, a software anti-debugging system is provided, which executes the bidirectional mutual debugging and self-debugging method as any one of the first aspect.

[0037] In a third aspect, according to the content of the present disclosure, a computer device is provided, comprising:

[0038] one or more processors;

[0039] a 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 any one of the first aspect.

[0041] In a fourth aspect, according to the content of the present disclosure, a computer readable storage medium is provided, which stores a computer program, and the program is executed by a processor to implement the method as any one of the first aspect.

[0042] The bidirectional mutual debugging self-debugging method, system, device and medium provided by the embodiments of the present disclosure first execute each service logic included in the main program by process A, detect the running state of each service logic in the process of executing the main program, and when detecting that the running state of the target service logic is an abnormal state, send a call debugging request to process B and convert the execution state of the target service logic to a pause state; then process B responds to the call debugging request, acquires abnormal trigger information, and according to the abnormal trigger information, determines the target service logic that needs to be migrated and run, and after completing the migration of the target service logic, switches the program counter of process B to point to the target service logic; finally, process B modifies the program counter of process A to the start address of the next running service logic. By establishing a mutual debugging process structure connected in a peer-to-peer manner, that is, two logical entities running in parallel for a long time, a protected application process and a self-debugger agent process, the two processes complete mutual attachment and mutual debugging in the initialization stage after system startup, one of which is attached to the other, and the attached party is attached again to form a peer-to-peer "debug role rotation mechanism". In this way, process A and process B can independently complete abnormal signal sensing and debugging instruction response execution without external access to the debugger in the entire program life cycle, forming a complete closed-loop control structure. In this structure, both parties are equal, each abnormal response is accompanied by a small debugger role switching and task dispatching, and the debugger controller startup, pause, decryption, verification and other structures rely on the context buffer as a relay to ensure complete information transmission without leakage.

[0043] The above description is only a summary of the technical solutions of the embodiments of the present application. In order to more clearly understand the technical means of the embodiments of the present application, the embodiments of the present application can be implemented according to the content of the specification, and in order to make the above and other purposes, features and advantages of the embodiments of the present application more obvious and easy to understand, the following specific embodiments of the present application are described. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings of the embodiments will be briefly described below. It should be noted that the drawings described below only relate to some embodiments of the present disclosure, but not limit the present disclosure, wherein:

[0045] Figure 1 is a flowchart of a bidirectional mutual debugging self-debugging method provided by an embodiment of the present disclosure;

[0046] Figure 2 is an interaction diagram of a bidirectional mutual debugging self-debugging method provided by an embodiment of the present disclosure;

[0047] Figure 3 is a structural diagram of a bidirectional mutual debugging self-debugging device provided by an embodiment of the present disclosure;

[0048] Figure 4 Figure 1 is a structural schematic diagram of a computer device provided by an embodiment of the present disclosure.

[0049] In the drawings, reference numbers of the last two digits that are the same, correspond to elements that are the same. It is to be noted that the elements in the drawings are schematic and not drawn to scale. DETAILED DESCRIPTION

[0050] In order to make the objects, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions of the embodiments of the present disclosure will be described clearly and completely below with reference to the drawings. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all the embodiments. Based on the described embodiments of the present disclosure, all other embodiments obtained by a person of ordinary skill in the art without creative effort belong to the scope of protection of the present disclosure.

[0051] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this present subject matter belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the specification and relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. As used herein, the statement that two or more parts are "connected" or "coupled" together refer to an indirect or direct connection or coupling between the parts, possibly through intervening parts.

[0052] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase "in an embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily all directed to the same embodiment, or to a common alternative embodiment. It is expressly understood that any of the embodiments described herein can be incorporated into any other embodiment.

[0053] The term "and / or", merely used as a description of associated objects, means that there can be three relationships, for example, A and / or B, can mean that A exists, A and B exist, and B exists. In addition, the character " / " in this paper generally represents that the front and rear associated objects are a "or" relationship.

[0054] In addition, in all embodiments of the present disclosure, terms such as "first" and "second" are only used to distinguish one component (or part of a component) from another component (or another part of a component).

[0055] In the description of the present application, unless otherwise specified, the meaning of "a plurality of" refers to more than two (including two), and similarly, "a plurality of groups" refers to more than two groups (including two groups).

[0056] In order for those skilled in the art to better understand the scheme of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings.

[0057] Based on the problems existing in the prior art, the present disclosure provides a bidirectional mutual debugging self-debugging method, the bidirectional mutual debugging self-debugging method provided by the present disclosure is applied to a software anti-debugging system, the software anti-debugging system includes a process A and a process B, Figure 1 is a flowchart of a bidirectional mutual debugging self-debugging method provided by the present disclosure, Figure 2 is an interaction diagram of the bidirectional mutual debugging self-debugging method provided by the present disclosure, in combination with Figure 1 and Figure 2 The specific process of the bidirectional mutual debugging self-debugging method includes:

[0058] S110, the process A executes each business logic included in the main program, detects the running state of each business logic in the process of executing the main program, and when the running state of the target business logic is detected as an abnormal state, sends a call debugging request to the process B, and converts the execution state of the target business logic to a paused state.

[0059] The bidirectional mutual debugging self-debugging method provided by the present disclosure first establishes a mutual attachment debugging mechanism of the process A and the process B in the software anti-debugging system, the two processes are attached to each other in the initialization stage, and each other plays the role of a debugger and a debuggee, when one party triggers an exception, the other party intervenes in the exception capture process through the debugger mechanism, the debugger does not have a general debugging function, and is highly customized, and can only be used to respond to internal signals or context switches included in the main program defined by the present disclosure; when the debugging roles need to be exchanged, the currently active debugger controls the exception throwing process, and the original debugger and the debuggee roles are exchanged.

[0060] Specifically, the software anti-debugging system includes the process A and the process B, when the process A is a debugger role, the process B is a debuggee role, when the process B is a debugger role, the process A is a debuggee role, the process as a debugger role in the software anti-debugging system is a protected application process, and the process as a debuggee role is a self-debugger process.

[0061] Process A and process B complete mutual attachment and mutual debugging in the initialization stage after system startup, one of which is attached to the other as a debugging process, and the party being attached reversely attaches to form a peer-to-peer "debugging role rotation mechanism". In this way, process A and process B can independently complete the abnormal signal sensing and debugging instruction response execution without external access to the debugger in the entire program life cycle, forming a complete closed-loop control structure.

[0062] In the software anti-debugging system, process A is taken as a "protected application process", and process B is taken as a "self-debugger process". Process A runs each business logic included in the main program, detects the running state of the business logic in the process of executing any business logic of the main program, and sends a call debugging request to process B when detecting that the running state of the target business logic is an abnormal state.

[0063] It should be noted that process A will manufacture abnormal signals in the running process through various ways (such as stealth code, illegal mapping memory access, soft zero, etc.), and then convert the abnormal signals into a debugger call debugging request, which is dispatched to process B through the operating system signal and is received and processed by process B.

[0064] The specific implementation process of process A manufacturing abnormal signals in the running process is that process A actively manufactures "controllable" exceptions at sensitive business logic (such as decryption, authorization, etc.) in a pre-programmed manner. Common practices include:

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

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

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

[0068] 4. Access violation: unauthorized cross-segment access, read / write restricted area;

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

[0070] Among them, the manufactured abnormal signals need to consider stealth and controllability, that is, the abnormal signals can only be "captured" by process A and determined as expected behavior, preventing external Dbg or error collector interference.

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

[0072] The exception trigger information includes an exception trigger address, an exception code, and exception context information.

[0073] Process B, as a "self-debugger process", when process A sends a call debugging request to process B, process B is in an "exception capture state", and a lightweight microkernel debugger ring is run inside process B, which identifies the exception type, extracts encapsulation information, confirms the target instruction, locally restores the context information, and then migrates the control right to the target business logic. At this time, the role is switched, and process A, which is originally the "caller", is paused, and the "target migration code" in process B starts running and continues until another exception is triggered. Next, the flow is switched in reverse, and the small debugger run by process A is processed.

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

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

[0076] When process A triggers a call debugging request during running, process B immediately responds to enter the "debugger" state, classifies, analyzes, and processes the exception trigger information. This mechanism disperses the execution path of the critical business logic to both ends, dynamically migrates and hides, making it difficult for attackers to trace or locate the core logic by breakpoints. The debugger role can perform in-depth inspection and repair on memory, registers, thread context, and exception throwing environment, and block unauthorized debuggers from intervening from the outside. At the same time, in cooperation with the exception throwing mechanism, the process migration and dynamic discrimination are actively triggered, so that the security protection is built in the 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 according to the exception trigger information, and switches the program counter of process B to point to the target business logic after completing the target business logic migration, including: process B determines the exception type according to the exception trigger information; according to the exception context information of the exception trigger information, encapsulation information is extracted, wherein the encapsulation information includes exception 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 when the exception occurs; according to the encapsulation information, the target business logic that needs to be migrated and run is determined, and after completing the target business logic migration, the program counter is switched to point to the target business logic.

[0078] The process B determines the exception type according to the exception trigger information, including: the process B determines the exception source according to the exception trigger address and the exception code of the exception trigger information; and the process B determines the exception type according to the exception source.

[0079] It is indicated in step S110 that the process A will generate an exception signal in the running process through various ways (such as a hidden code, an illegal mapping memory access, a software division zero, etc.), and thus the exception address and the exception code of the generated exception signal are known. After the process B receives the debugging call request, the process B first acquires the exception trigger information in the process A, and then determines the exception source according to the exception trigger address and the exception code in the exception trigger information, that is, it can be determined whether the exception trigger information is a prescribed inland section, a classified business forgery, or a random crash. When it is determined that the exception trigger information is the exception trigger information generated by the prescribed inland section or the classified business forgery, the process B matches the corresponding exception type according to the exception source.

[0080] After the exception type is determined, the encapsulation information is extracted according to the exception context information of the exception trigger information, wherein the encapsulation information includes a register group, a stack frame, a call instruction address, an action ID, an exception trace address, a parameter / operation data, a call type, an original program counter value, and a stack top snapshot when the exception occurs.

[0081] Specifically, first, the state information when the exception occurs is extracted according to the exception context information of the exception trigger information, wherein the state information includes exception trace 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 written in advance by the process A is read, wherein the signal fingerprint information includes an action ID, an operation code, and an operation parameter, such as a mode code filled in a certain register and next step action information (for example, "jump to the re-encryption address, and the operation code is 3"). Finally, the encapsulation information is determined according to the state information and the signal fingerprint information.

[0082] After the encapsulation information is determined, the target business logic that needs to be migrated and run is determined according to the encapsulation information, and after the migration of the target business logic 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 according to the operation code in the extracted encapsulation information, and then it is checked whether the target business logic is the business logic included in the main program. When the target business logic is the business logic included in the main program, the target business logic is migrated to the process B, and the actual position of the target business logic in the memory of the process B after the migration is locked. Finally, the program counter is switched to point to the target business logic.

[0084] S140, the process B modifies the program counter of the target business logic in the process A in the pause 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 the process A in the pause state is to achieve "safe migration" of code flow and "execution path confusion". After the process A detects that the running state of the target business logic is an abnormal state, the process A is currently in a pause debugging state. If the process B directly restores the program counter address of the process A after intervention, the attacker can easily reproduce and predict the flow. In contrast, by modifying the program counter of the process A (i.e., the address of the next instruction to be executed) under the drive of a specific exception or signal, the business logic can be jumped to a new code block that is remapped, hidden, or encrypted / checked.

[0086] Through the above setting, the execution path can be dynamically confused, and it is difficult for the attacker to restore the static flow; the breakpoints and hooks are prevented, and it is difficult for the attacker to grasp the stable key instruction flow, so that the code fragments / protection logic are highly dynamic in space and time; the kernel-level protection actions such as unlocking, verification, or authorization are implemented, such as jumping into a special self-check block; and the signal mechanism and information injection are closely matched, so as to facilitate the transfer of temporary sensitive data such as parameters, commands, and keys.

[0087] The modification of the program counter is a key hub of "abnormal signal conversion into safe business action", which deeply integrates the business flow and the security protection.

[0088] Specifically, after switching the program counter to point to the target business logic, the process B and the process A perform role switching, that is, the process B is a protected application process, the process A is a self-debugging process, the process B executes the target business logic, and detects the running state in the execution process. When the process B detects that the running state is an abnormal state in the execution process, the process B sends a call debugging request to the process A, and at this time, A acts as a debugger and responds to the call debugging request of the process B. The above process can be repeatedly executed to form a similar double-sided execution cycle cooperation mechanism. After all the alternations are completed, [close the mutual debugging state & clean up] is entered, including releasing the debugger relationship, releasing the occupied debugging session and state management area, and destroying the temporary instruction cache. Finally, the process guarantees that the entire protection module always maintains the design criteria of minimum exposure, control symmetry, and abnormal path diversity when resisting the attack of the attacker static symbol tracking, dynamic instruction flow interception, and debugger injection separation, and also meets the high-strength anti-reverse target.

[0089] Whether process B can correctly switch and execute the migration code depends entirely on the "signal content" passed when A side makes an exception, that is, A embeds the agreed instruction code, target address or behavior type parameter in a specific location in the exception context (registers, dedicated memory, stack) when making an exception. B, as the debugging side, identifies the exception and decodes the "business segment that needs to be migrated / run" according to the information carried by the exception, and then switches the PC to point to the business area. This is a set of closely coordinated "signal-action" protocols. If any party lacks the relevant agreement, the migration cannot be correctly executed, and the system will trigger a protective termination.

[0090] The bidirectional mutual debugging self-debugging method provided by the embodiments of the present disclosure first executes each business logic included in the main program by process A, detects the running state of each business logic in the process of executing the main program, and sends a call debugging request to process B when detecting that the running state of the target business logic is an abnormal state, and converts the execution state of the target business logic to a paused state; then process B responds to the call debugging request to obtain exception trigger information; and according to the exception trigger information, determines the target business logic that needs to be migrated and run, and switches the program counter of process B to point to the target business logic after completing the migration of 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 set of mutually connected mutual debugging process structure, that is, two logical entities running in parallel for a long time, the protected application process and the self-debugger agent process, the two processes complete mutual attachment and mutual debugging in the initialization stage after system startup, one of which is attached to the other, and the attached party is attached again to form a peer "debug role rotation mechanism". In this way, process A and process B can independently complete the exception signal sensing and debugging instruction response execution without external access to the debugger during the entire program life cycle, forming a complete closed-loop control structure. In this structure, both sides are equal, each exception response is accompanied by a small debugger role switching and task dispatching, and the debugger controller startup state, pause state, decryption state, verification state and the like rely on the context buffer as a relay to ensure complete information transmission but not disclosure.

[0091] On the basis of the above-mentioned embodiments, the bidirectional mutual debugging self-debugging method provided by the embodiments of the present disclosure further comprises, before step S110: in response to the received start indication signal, establishing a mutual attachment mutual debugging mechanism of process A and process B.

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

[0093] Specifically, the implementation core of establishing the mutual-attachment mutual-debugging mechanism of process A and process B lies in the interconnection binding between process A (a protected application process) and process B (a self-debugger process). When the system starts, process A starts a main program at the same time, forks or pulls up process B. Process A first uses a debugging-attachment interface (such as ptrace (PTRACE_ATTACH) of Linux or DebugActiveProcess / Debugger API of Windows) provided by the operating system to attach itself to process B as a debugger to establish a standard debugging session mechanism with process B. Process B, after completing initialization, reversely attaches itself to process A in the same way. The key to establishing the mutual-attachment mutual-debugging mechanism of process A and process B lies in that process A and process B are mutual debuggers, each of which can listen to and capture the exception and instruction flow of the other, forming an independent closed-loop debugging relationship in a peer-to-peer manner without the participation of an external debugger. This mechanism is implemented through underlying debugging APIs (signals, exceptions, breakpoints, etc.) of the operating system, ensuring that no third-party debugging session can intrude and preventing the process from being hijacked alone.

[0094] The purpose of the mutual-attachment mutual-debugging mechanism of process A and process B is to realize autonomous control over exceptions, debugging events, and protected code segments by means of the arranged mutual-debugging relationship. Whenever one party (process A or process B) issues a call for debugging during running, the other party immediately enters a "debugger" state to classify, analyze, and handle the exception scenario. This mechanism disperses the execution path of critical business logic to both ends, dynamically migrates and hides, making it difficult for attackers to trace or break the core logic. The debugger role can perform in-depth inspection and repair on memory, registers, thread context, and exception throwing environment to block the intervention of external unauthorized debuggers; at the same time, in cooperation with the exception throwing mechanism, process migration and dynamic discrimination are actively triggered, so that security protection is built in a constantly switching and unpredictable internal debugging environment.

[0095] On the basis of the above-mentioned embodiments, the disclosure further provides a bidirectional mutual-debugging self-debugging device. The bidirectional mutual-debugging self-debugging device provided by the disclosure is applied to a software anti-debugging system, and the software anti-debugging system includes process A and process B, Figure 3is a structural schematic diagram of a bidirectional mutual debugging self-debugging device provided by the embodiment of the present disclosure, as shown in Figure 3 The bidirectional mutual debugging self-debugging device comprises:

[0096] The calling debugging request generation module 310 is configured to execute each service logic included in the main program, detect the running state of each service logic in the process of executing the main program, and send a calling debugging request to the process B and convert the execution state of the target service logic to a pause state when detecting that the running state of the target service logic is an abnormal state.

[0097] The abnormal trigger information acquisition module 320 is configured to acquire abnormal trigger information in response to the calling debugging request, wherein the abnormal trigger information comprises an abnormal trigger address, an abnormal code and abnormal context information.

[0098] The switching module 330 is configured to determine the target service logic that needs to be migrated and run according to the abnormal trigger information, and switch the program counter to point to the target service logic after completing the migration of the target service logic.

[0099] The modification module 340 is configured to modify the program counter of the target service logic in the pause state in the process A to point to the start address of the next running service logic.

[0100] The bidirectional mutual debugging self-debugging device provided by the embodiments of the present disclosure first executes each service logic included in the main program by the process A, detects the running state of each service logic in the process of executing the main program, and sends a call debugging request to the process B when detecting that the running state of the target service logic is an abnormal state, and converts the execution state of the target service logic into a pause state; then the process B responds to the call debugging request, acquires abnormal trigger information, and determines the target service logic that needs to be migrated and run according to the abnormal trigger information, and switches the program counter of the process B to point to the target service logic after completing the migration of the target service logic; finally, the process B modifies the program counter of the process A to the start address of the next running service logic. By establishing a mutual debugging process structure of peer interconnection, that is, two logical entities of a protected application process and a self-debugger agent process running in parallel for a long time, the mutual attachment and mutual debugging of the two processes are completed in the initialization stage after the system is started, one of which is attached to the other, and the attached party is attached again to form a peer "debug role rotation mechanism". In this way, the process A and the process B can independently complete the abnormal signal sensing and the debugging instruction response execution without external access to the debugger in the entire program life cycle, forming a complete closed-loop control structure. In this structure, the two parties are equal, each abnormal response is accompanied by a small debugger role switching and task dispatching, and the debugger controller start state, pause state, decryption state, verification state and other structures rely on the context cache buffer as a relay to ensure complete information transmission but no leakage.

[0101] In a specific embodiment, before the process A executing each service logic included in the main program and detecting the running state of each service logic in the process of executing the main program, the process A further includes:

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

[0103] In a specific embodiment, in response to the received start indication signal, the mutual attachment mutual debugging mechanism of the process A and the process B is established, including:

[0104] In response to the received start indication signal, the process A starts the main program and pulls up the process B.

[0105] The process A, based on a debugging attachment interface of an operating system, attaches itself to the process B as a debugger, and establishes a standard debugging session mechanism with the process B.

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

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

[0108] The process B determines an exception type according to the exception trigger information.

[0109] According to exception context information of the exception trigger information, encapsulation information is extracted, wherein the encapsulation information includes a register group, a stack frame, a call instruction address, an action ID, an exception trace address, parameter / operation data, a call type, an original program counter value, and a stack top snapshot at the time of the exception occurrence.

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

[0111] In a specific embodiment, the process B determines an exception type according to the exception trigger information, including:

[0112] The process B determines an exception source according to an exception trigger address and an exception code of the exception trigger information.

[0113] The process B determines an exception type according to the exception source.

[0114] In a specific embodiment, the process B determines an exception type according to the exception trigger information, including:

[0115] According to exception context information of the exception trigger information, state information at the time of the exception occurrence is extracted, wherein the state information includes exception trace address information, register group address information, stack frame address information, call instruction address information, a call type, and a program counter value.

[0116] Signal fingerprint information pre-written by the process A is read, wherein the signal fingerprint information includes an action ID, an operation code, and operation parameters.

[0117] According to the state information and the signal fingerprint information, encapsulation information is determined.

[0118] In a specific embodiment, the process B determines an exception type according to the exception trigger information, including:

[0119] According to the encapsulation information, target business logic that needs to be migrated and run is determined.

[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, for example, flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), 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), a magnetic memory, a magnetic disk, an optical disk, etc. The RAM can include static RAM or dynamic RAM. In some embodiments, the memory 510 can be an internal storage unit of the computer device, for example, a hard disk or a memory of the computer device. In other embodiments, the memory 510 can also be an external storage device of the computer device, for example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, or a flash card, etc. equipped on the computer device. Of course, the memory 510 can include both an internal storage unit and an external storage device of the computer device. In this embodiment, the memory 510 is generally used to store an operating system and various application software installed on the computer device, for example, program codes of the above-described method, etc. In addition, the memory 510 can also be used to temporarily store various data that has been output or will be output.

[0126] The processor 520 is generally used to perform the overall operation of the computer device. In this embodiment, the memory 510 is used to store program codes or instructions, which include computer operation instructions, and the processor 520 is used to execute the program codes or instructions stored in the memory 510 or process data, for example, run the program codes of the above-described method.

[0127] In this document, the bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, among others. The bus system can be a system of address, data, and control buses, for example. For the sake of presentation, the detailed wiring for bus transactions has been omitted, except for the interconnection of buses themselves. In practice, the bus transactions are often moved along multiple parallel lines using a variety of bus protocols.

[0128] Another embodiment of the present application further provides a computer readable medium, which can be a computer readable signal medium or a computer readable storage medium. A processor in a computer reads the computer readable program code stored in the computer readable medium, so that the processor can perform the function actions specified in each step or combination of steps in the above method; and generates a device implementing the function actions specified in each block or combination of blocks in the block diagram.

[0129] The computer readable medium includes, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any suitable combination of the foregoing, for storing program codes or instructions, and the program codes include computer operation instructions. The processor is used to execute the program codes or instructions of the above method stored in the memory.

[0130] The definition of the memory and the processor can refer to the description of the foregoing computer device embodiment, which will not be repeated here.

[0131] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiment described above is only schematic, for example, the division of the module or unit is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0132] The function units or modules in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of software function unit.

[0133] If the integrated unit is implemented in the form of a software function unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the embodiments of the method of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0134] Unless the context clearly indicates otherwise, as used herein and in the appended claims, the singular form "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Accordingly, the use of "a" or "an" herein and in the following claims is intended to be interpreted to include the plural, unless the context clearly indicates otherwise. Similarly, the words "comprise," "comprises," and "comprising" are to be interpreted inclusively rather than exclusively. Likewise, the terms "include," "including," and "includes" should be construed to be inclusive, unless otherwise indicated herein. Where the term "example" is used occurring in this document, particularly with respect to a term or phrase, the "example" is merely an example and is not to be construed as preferred or advantageous over other examples.

[0135] Further aspects and scope of adaptation become apparent from the description provided herein. It should be appreciated that individual aspects of the present application can be implemented alone or in combination with one or more other aspects. It should also be appreciated that the description and specific examples herein are intended to be for illustrative purposes only and are not intended to limit the scope of the present application.

[0136] The above detailed description of several embodiments of the present disclosure, but obviously, those skilled in the art can make various modifications and variations to the embodiments of the present disclosure without departing from the spirit and scope of the present disclosure. The protection scope of the present 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, include: 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. 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; 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. 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.

2. The method according to claim 1, characterized in that, Before process A executes the various business logics included in the main program, and before checking the running status of each business logic during the execution of the main program, it also includes: In response to the received start instruction signal, a mutual attachment and debugging mechanism between process A and process B is established.

3. The method according to claim 2, characterized in that, The mechanism for mutual attachment and debugging between process A and process B in response to the received start indication signal includes: In response to the received start instruction signal, process A starts the main program and launches process B; 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. 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.

4. The method according to claim 1, characterized in that, 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, including: Process B determines the exception type based on the exception triggering information; 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; 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.

5. The method according to claim 4, characterized in that, Process B determines the exception type based on the exception triggering information, including: Process B determines the source of the anomaly based on the anomaly trigger address and anomaly code in the anomaly trigger information; Process B determines the exception type based on the source of the exception.

6. The method according to claim 4, characterized in that, The step of extracting encapsulation information based on the exception context information of the exception triggering information includes: 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; Read the signal fingerprint information pre-written by process A, wherein the signal fingerprint information includes action ID, operation code and operation parameters; The encapsulation information is determined based on the status information and the signal fingerprint information.

7. The method according to claim 4, characterized in that, 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: Based on the encapsulation information, determine the target business logic that needs to be migrated and run; 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.

8. A software anti-debugging system, which executes the bidirectional mutual debugging and self-debugging method as described in any one of claims 1-7.

9. A computer device, comprising: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described in any one of 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images