KR102623022B1 - Debugger blocking method and system for program protection - Google Patents

Abstract

Provides a debugger blocking method and system to protect programs. A debugger blocking method executed by a processor of a computer includes executing a preemption process to preempt the debuggee process in response to execution of a debuggee process associated with the computer program to protect debugging operations for the computer program. ordering step; and connecting the executed preemption process to the debuggee process through a system call to preempt a debugging operation for the debuggee process.

Description

Debugger blocking method and system for program protection

The description below relates to a debugger blocking method for program protection, a debugger blocking system that performs the debugger blocking method, a computer program stored on a computer-readable recording medium in combination with a computer to execute the debugger blocking method on the computer, and the recording medium. will be.

The operation of applications distributed to client terminals can be identified through reverse engineering (reversing), and through reverse engineering, the theft of application functions becomes possible. Additionally, by modifying the original function of the application to cause the application to operate differently from its intended operation, this can have a negative impact on the services provided through the application and the reliability of the system that provides the service.

Debugging is essential in this process of analyzing applications through reverse engineering. Debugging refers to the act of checking and correcting program errors, and the program used for this act is called a debugger. This debugging can also be performed on normal programs without errors, and in this case, not only can the intended operation of the original program be changed, but it can also be used for malicious purposes to understand the operating principles inside the program.

Previously, in order to protect the built program, obfuscation techniques were used to change the original operation method or encrypt part of it to make it difficult to modify the code and understand the operation pattern. For example, Korean Patent No. 10-1328012 relates to an application code obfuscation device and method, and is a technology for converting important codes among codes used in an application and calling codes for calling important codes into native code form. is starting.

However, this prior art requires additional execution time to execute the obfuscated code, and has the problem that the original code must be loaded into memory at a specific point in time to perform the original operation.

A debugger blocking method that can block the debugger by preempting the process of the program to be protected and preventing the debugger process from attaching to the debuggee process, a debugger blocking system, and a computer that perform the debugger blocking method It provides a computer program stored on a computer-readable recording medium and the recording medium for executing a debugger blocking method on a computer.

In the method of blocking a debugger executed by a processor of a computer, in order to protect a debugging operation for a computer program, a preemption process for preempting the debuggee process in response to execution of the debuggee process associated with the computer program is performed. execution step; and connecting the executed preemption process to the debuggee process through a system call to preempt a debugging operation for the debuggee process.

Provided is a computer program stored on a computer-readable recording medium that is coupled to a computer and allows the computer to execute the debugger blocking method.

A computer-readable recording medium is provided, characterized in that a computer program for executing the debugger blocking method on a computer is recorded thereon.

At least one processor implemented to execute computer-readable instructions, wherein a debuggee process associated with the computer program is executed by the at least one processor to protect the debugging operation of the computer program. In response, a computer device is provided that executes a preemption process to preempt the debuggee process and connects the executed preemption process to the debuggee process through a system call to preempt a debugging operation for the debuggee process. .

The debugger can be blocked by preempting the process of the program you want to protect and preventing the debugger process from attaching to the debuggee process.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
Figure 2 is a block diagram for explaining the internal configuration of an electronic device and a server, according to an embodiment of the present invention.
Figure 3 is a diagram illustrating an example of a process for blocking a debugger in one embodiment of the present invention.
Figure 4 is a flowchart showing an example of a debugger blocking method according to an embodiment of the present invention.
Figure 5 is a flowchart showing an example of the operation of a preemption process according to an embodiment of the present invention.
Figure 6 is a flowchart showing an example of the operation of a debuggee process according to an embodiment of the present invention.

Best mode for carrying out the invention

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

For example, the debugger blocking system according to embodiments of the present invention may be implemented through a computer such as the computer device 200 illustrated in FIG. 2, and the debugger blocking method according to embodiments of the present invention may be implemented using such a computer. It can be performed through For example, a computer program according to an embodiment of the present invention (for example, an application installed on a computer device to provide a specific service) may be run on the computer, and the computer may run the present invention under the control of the driven computer program. The debugger blocking method according to one embodiment can be performed. The above-described computer program can be combined with a computer and stored in a computer-readable recording medium to execute the debugger blocking method on the computer.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention. The network environment in FIG. 1 shows an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170. Figure 1 is an example for explaining the invention, and the number of electronic devices or servers is not limited as in Figure 1.

The plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smart phones, mobile phones, navigation devices, computers, laptops, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Portable Multimedia Players). ), tablet PC, etc. For example, in Figure 1, the shape of a smartphone is shown as an example of electronic device 1 (110). However, in embodiments of the present invention, electronic device 1 (110) actually connects the network 170 using a wireless or wired communication method. It may refer to one of various physical devices capable of communicating with other electronic devices 120, 130, 140 and/or servers 150, 160.

The communication method is not limited, and may include not only a communication method utilizing a communication network that the network 170 may include (for example, a mobile communication network, wired Internet, wireless Internet, and a broadcast network), but also short-range wireless communication between devices. For example, the network 170 may include a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). , may include one or more arbitrary networks such as the Internet. Additionally, the network 170 may include any one or more of network topologies including a bus network, star network, ring network, mesh network, star-bus network, tree or hierarchical network, etc. Not limited.

Each of the servers 150 and 160 is a computer device or a plurality of computers that communicate with a plurality of electronic devices 110, 120, 130, 140 and a network 170 to provide commands, codes, files, content, services, etc. It can be implemented with devices. For example, the server 150 may be a system that provides a first service to a plurality of electronic devices 110, 120, 130, and 140 connected through the network 170, and the server 160 also provides a network ( It may be a system that provides a second service to a plurality of electronic devices 110, 120, 130, and 140 connected through 170). As a more specific example, the server 150 may provide a service associated with an application (computer program) installed on a plurality of electronic devices 110, 120, 130, and 140 as the first service. As another example, the server 160 may provide a service of providing an installation file of an application for the first service to a plurality of electronic devices 110, 120, 130, and 140 as the second service.

Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention. Each of the plurality of electronic devices 110, 120, 130, and 140 described above or each of the servers 150 and 160 may be implemented by the computer device 200 shown in FIG. 2. For example, a computer program according to an embodiment may be installed and driven in the computer device 200, and the computer device 200 blocks a Java debugger according to embodiments of the present invention according to control of the driven computer program. method can be performed.

As shown in FIG. 2, this computer device 200 may include a memory 210, a processor 220, a communication interface 230, and an input/output interface 240. The memory 210 is a computer-readable recording medium and may include a non-permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive. Here, non-perishable large-capacity recording devices such as ROM and disk drives may be included in the computer device 200 as a separate permanent storage device that is distinct from the memory 210. Additionally, an operating system and at least one program code may be stored in the memory 210. These software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210. Such separate computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, and memory cards. In another embodiment, software components may be loaded into the memory 210 through the communication interface 230 rather than a computer-readable recording medium. For example, software components may be loaded into memory 210 of computer device 200 based on computer programs installed by files received over network 170.

The processor 220 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Commands may be provided to the processor 220 by the memory 210 or the communication interface 230. For example, processor 220 may be configured to execute received instructions according to program code stored in a recording device such as memory 210.

The communication interface 230 may provide a function for the computer device 200 to communicate with other devices (eg, the storage devices described above) through the network 170. For example, a request, command, data, file, etc. generated by the processor 220 of the computer device 200 according to a program code stored in a recording device such as memory 210 is transmitted to the network ( 170) and can be transmitted to other devices. Conversely, signals, commands, data, files, etc. from other devices may be received by the computer device 200 through the communication interface 230 of the computer device 200 via the network 170. Signals, commands, data, etc. received through the communication interface 230 may be transmitted to the processor 220 or memory 210, and files, etc. may be stored in a storage medium (as described above) that the computer device 200 may further include. It can be stored as a permanent storage device).

The input/output interface 240 may be a means for interfacing with the input/output device 250. For example, input devices may include devices such as a microphone, keyboard, or mouse, and output devices may include devices such as displays and speakers. As another example, the input/output interface 240 may be a means for interfacing with a device that integrates input and output functions, such as a touch screen. The input/output device 250 may be configured as a single device with the computer device 200.

Additionally, in other embodiments, computer device 200 may include fewer or more components than those of FIG. 2 . However, there is no need to clearly show most prior art components. For example, the computer device 200 may be implemented to include at least some of the input/output devices 250 described above, or may further include other components such as a transceiver, a database, etc.

Figure 3 is a diagram illustrating an example of a process for blocking a debugger in one embodiment of the present invention. In order to protect debugging operations for computer programs installed and running on the computer device 200, the computer device 200 preempts the debuggee process 310 associated with the computer program through the preemption process 320. can do. In this case, the debugger process 330 that wants to debug the debugger process 310 will be connected to the debugger process 310 because the debugger process 310 is already preempted by the preemptive process 320. cannot be used, and thus the effect of blocking the debugger can be obtained.

To this end, the computer device 200 immediately executes the preemption process 320 in response to the execution of the debuggee process 310, thereby eliminating the possibility that the debugger process 330 is connected to the debuggee process 310 first. . For example, the code for executing the preemption process 320 may be included in a computer program to be protected from debugging operations. In this case, when the computer program is executed in the computer device 200 and the debuggee process 310 is executed accordingly, the computer device 200 immediately executes the preemption process 320 according to the code included in the computer program. The debuggee process 310 can be controlled to be preempted. As a more specific example, when the debuggee process 310 is executed, the computer device 200 forks the debuggee process 310 to preempt the process 320 with the same permissions as the debuggee process 310. It can be run. Forking a process may be the process of duplicating a process and creating a child process. In general, the debugger process 330 requires a process to elevate privileges in order to connect to the debuggee process 310, but when the preemption process 320 is created through fork, it has the same privileges as the debuggee process 310. Since the existing process is created as a preemptive process 320, the process for elevating privileges can be omitted. This method of creating a preemptive process 320 using a fork is only an example, and is not limited to this as long as it is a process creation method for creating a process that can preempt a debugging operation for the debuggee process 310. For example, instead of duplicating the debuggee process 310, a separate process may be created as the preemption process 320 and its privileges may be elevated to connect to the debuggee process 310.

For example, the preemption process 320 may be connected to the debuggee process 310 through a process trace (hereinafter 'ptrace'), which is a system call API (Application Programming Interface) found in Unix-based operating systems. For example, the preempting process 320 may pass the process identifier (PID) of the debuggee process 310 to the operating system through a system call such as ptrace. In this case, the operating system may communicate with the preempting process 320 that called ptrace. The debuggee process 310 identified through the process identifier can be connected, and the preemption process 320 can be recognized as a debugger. Therefore, even if the debugger process 330 requests to connect to the debuggee process 310 as a debugger, the debugger process 330 cannot System calls can fail, which has the effect of blocking the debugger.

At this time, the preemption process 320 may be connected to each thread created in the debuggee process 310. For example, Figure 3 shows n threads created in the debuggee process 310. At this time, the preemption process 320 may be connected to each of n threads. Since the preemption process 320 is a process created to preempt the debuggee process 310, a function for receiving and processing a signal from the debuggee process 310 may be included in the preemption process 320. On the other hand, since the debuggee process 310 is a process for a computer program, the debuggee process 310 can create a separate thread (hereinafter, 'monitor thread') to process signals from the preemption process 320. there is. Figure 3 shows an example in which thread n processes a signal from the preemption process 320 as a monitor thread.

The operations of each of the debuggee process 310 and the preemption process 320 will be described in more detail later.

Figure 4 is a flowchart showing an example of a debugger blocking method according to an embodiment of the present invention. The debugger blocking method according to this embodiment can be performed by the computer device 200 described above. For example, the processor 220 of the computer device 200 may be implemented to execute control instructions according to the code of an operating system and/or the code of at least one program included in the memory 210. For example, the above-mentioned program code may be the code of an application that is the target of debugging. In other words, the application may include code for blocking the debugger, and the processor 220 allows the computer device 200 to block the debugger in FIG. 4 according to control instructions provided by the code of the application stored in the computer device 200. The computer device 200 can be controlled to perform steps 410 and 420 included in the method. Depending on the embodiment, the program code may be provided through a separate program from the application that is the target of debugging. For example, the debuggee process is a process related to the application that is the target of debugging, and a preemption process created by a separate program may preempt the debuggee process. In this case, a separate program from the application that is the target of debugging may be further created in the computer device 200.

In step 410, the computer device 200 may execute a preemption process to preempt the debuggee process in response to execution of the debuggee process associated with the computer program to protect the debugging operation for the computer program. . For example, when executing a debuggee process, the computer device 200 may fork the debuggee process to create and execute a preemption process with the same permissions as the debuggee process. As already explained, there are no limitations to the methods for executing a preemptive process as long as it is possible to create and execute a process other than fork.

In step 420, the computer device 200 may preempt a debugging operation for the debuggee process by attaching the executed preemption process to the debuggee process through a system call. For example, it was previously explained that when the computer device 200 uses a Unix-based operating system, the preemption process can be connected to the debuggee process through ptrace, a system call API. In this way, the computer device 200 may allow the preemption process executed based on a predefined calling method according to the operating system to be connected to the debuggee process. The preemptive process can recognize the process created in association with the computer program to be protected as a debuggee process, and makes the operating system call the preempted process as the intended debuggee process through a system call using the process identifier (PID) of the recognized debuggee process. You can control it to connect to the buggy process. As already explained, because the preempting process has preempted the debuggee process for debugging operations, other debugger processes cannot connect to the debuggee process, and thus the debugger is blocked.

Figure 5 is a flowchart showing an example of the operation of a preemption process according to an embodiment of the present invention. Steps 510 to 560 of FIG. 5 describe the logical operation of the preemption process, and may actually be operations caused by the processor of the computer device 200 to perform the computer device 200. FIG. 5 illustrates an example of a process in which these steps 510 to 560 are included in step 420 of FIG. 4 and are performed by the computer device 200.

In step 510, the computer device 200 may find a thread created before execution of the preemption process in association with the debuggee process and connect it to the preemption process through a system call. As described above, the preemption process may be connected to each of the threads created by the debuggee process, and a thread created by the debuggee process may exist before execution of the preemption process. To connect to these threads, the preempting process can find threads created before the execution of the preempting process and connect to those threads through a system call. At this time, step 510 may be omitted depending on the embodiment.

In step 520, the computer device 200 may control the preemption process so that the preemption process waits for a signal to be received from the debuggee process. Logically, this may be a process in which the preemptive process waits for a signal to be received from the debuggee process.

In step 530, the computer device 200 may check whether the preemption process receives a thread creation signal from the debuggee process. The computer device 200 may perform step 540 when the preemption process receives a thread creation signal from the debuggee process, and step 550 when it does not receive the thread creation signal.

In step 540, the computer device 200 may connect the preemption process to the thread created in the debuggee process through a system call. This may be a process in which a preemptive process attaches to a thread created through a system call, such as ptrace, for that thread's task. The computer device 200 may connect the preemption process and the created thread through step 540 and then perform step 520 again to control the preemption process to wait for reception of a signal from the debuggee process.

In step 550, the computer device 200 may check whether the preemption process receives an end signal from the debuggee process. The computer device 200 performs step 560 when the preemption process receives a termination signal from the debuggee process, and performs step 520 again when the preemption process does not receive the termination signal from the debuggee process. You can control it to wait for reception.

In step 560, the computer device 200 may disconnect the thread connected to the preemption process and terminate the preemption process. When the debuggee process is terminated, the preemption process for preempting the debuggee process is also no longer needed, so the preemption process may also be terminated. At this time, the preemption process can be terminated stably by disconnecting from the threads of the debuggee process upon receiving the end signal of the debuggee process.

At this time, as shown through the steps in FIG. 5, signals related to debugging operations other than the thread creation signal and termination signal may be ignored. For example, the preemption process preempts the debugging operation of the debugger process like a debugger process, but since it does not actually perform the role of a debugger, the computer device 200 performs debugging while waiting for reception of a signal signal in step 520. If other signals related to the operation are received, the other signals can be ignored.

Figure 6 is a flowchart showing an example of the operation of a debuggee process according to an embodiment of the present invention. Steps 610 to 650 of FIG. 6 describe the logical operation of the debuggee process, and may actually be operations caused by the processor of the computer device 200 to perform the computer device 200. FIG. 6 illustrates an example of a process performed by the computer device 200 in which steps 610 to 650 are included in step 420 of FIG. 4 .

In step 610, the computer device 200 may create a monitor thread that processes signals from the preemption process. The monitor thread can handle signals from the preempting process.

In step 620, the computer device 200 may control the debuggee process so that the debuggee process waits for a signal to be received from the preemption process. Logically, this may be a process in which the monitor thread waits for a signal to be received from the preemption process.

In step 630, when the computer device 200 creates a thread associated with a debuggee process, it may transmit a thread creation signal to the preemption process. This may be a process in which the debuggee process (or monitor thread) transmits a thread creation signal to notify that a thread has been created in the debuggee process as a preemptive process. For example, the debuggee process can check whether this thread creation signal is received in step 530 of FIG. 5.

In step 640, the computer device 200 may check whether the debuggee process receives a termination signal from the preemption process. The computer device 200 may perform step 650 when the debuggee process receives a termination signal from the preempting process, and if it does not receive the termination signal, perform step 620 again to ensure that the debuggee process receives the termination signal from the preempting process. You can control the debuggee process to wait for a signal to be received. In other words, the monitor thread can ignore signals other than the termination signal from the preempting process.

In step 650, the computer device 200 may disconnect a thread connected to the debuggee process and terminate the debuggee process. This may be the process in which the debuggee process ends. In other words, as the debuggee process receives a termination signal from the preempting process, it can safely terminate after disconnecting all threads connected to the debuggee process. This may be a process to terminate the debuggee process as well when the preemption process is terminated in order to prevent only the preemption process from being terminated first and the debuggee process remaining to be debugged by another debugger.

Depending on the embodiment, for mutual debugging protection, a case of mutual debugging protection in which the debuggee process also preempts the preempting process and the debuggee process and the preempting process preempt each other's debugger ports may be considered. In this case, the debuggee process can also proceed with the process of preempting the preempting process and receive a thread creation signal from the preempting process. At this time, the monitor thread can ignore signals other than the thread creation signal and termination signal from the preemption process. For example, the computer device 200 connects the executed debugger process to the preempting process through a system call to preempt the debugging operation for the preempting process, thereby preventing the debugger process from accessing the preempting process.

In addition, even if the preempting process is terminated by some external factor while processing mutual debugging protection (for example, if it terminates abnormally), the debuggee process receives the termination signal of the preempting process and terminates the preempting process. You can check whether the debugger port is available, and you can maintain the protected state by re-running the preemption process and re-preempting the debugger port. For example, when the debuggee process receives a termination signal from the preempting process in step 420, the computer device 200 forks the debuggee process to another preempting process with the same permissions as the debuggee process. You can maintain preemption of debugging operations for the debuggee process by executing and connecting other executed preemption processes to the debuggee process through a system call.

Conversely, even when the debuggee process is terminated by some external factor (i.e., terminates abnormally), the preempting process receives the termination signal of the debuggee process to determine whether the debuggee process terminates and/or terminates abnormally. This can be determined, and the debuggee process can be re-executed based on this judgment. For example, in step 420, the computer device 200 may determine that the preemption process receives a termination signal from the debuggee process and the debuggee process terminates abnormally, and may re-execute the debuggee process.

As described above, according to embodiments of the present invention, the debugger can be blocked by preempting the process of the program to be protected and preventing the debugger process from attaching to the debuggee process.

The system or device described above may be implemented with hardware components, software components, or a combination of hardware components and software components. For example, devices and components described in embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), etc. , may be implemented using one or more general-purpose or special-purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include a plurality of processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. It can be embodied in . Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the medium may be specially designed and configured for the embodiment or may be known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -Includes optical media (magneto-optical media) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

Forms for practicing the invention

As described above, although the embodiments have been described with limited examples and drawings, various modifications and variations can be made by those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent.

Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the claims described below.

Claims (18)

In a computer program coupled to a computer and stored on a computer-readable recording medium for executing a debugger blocking method on the computer,
The debugger blocking method is:
executing a preemption process to preempt the debuggee process in response to execution of a debuggee process associated with the computer program to protect a debugging operation for the computer program; and
Connecting the executed preemption process to the debuggee process through a system call to preempt a debugging operation for the debuggee process
Including,
The preemption step is,
Finding a thread created in association with the debuggee process before execution of the preemption process and connecting it to the preemption process through a system call;
Waiting in the preemption process for a signal to be received from the debuggee process; and
When the preempting process receives a thread creation signal from the debuggee process, connecting the preempting process to the thread created in the debuggee process through a system call.
Including,
The debuggee process includes a monitor thread to ignore signals other than a termination signal from the preemptive process.
Characterized by a computer program. According to paragraph 1,
The steps to execute the above are,
When executing the debuggee process, executing the preemption process with the same permissions as the debuggee process through forking the debuggee process.
A computer program, including. According to paragraph 1,
The preemption step is,
When receiving the termination signal from the debuggee process, disconnecting a thread connected to the preemption process and terminating the preemption process
A computer program further comprising: delete According to paragraph 3,
The waiting step is,
A computer program that ignores signals associated with the debugging operation other than the thread creation signal and the termination signal. According to paragraph 1,
The preemption step is,
Waiting in the debuggee process for a signal to be received from the preemption process;
When creating a thread associated with the debuggee process, transmitting a thread creation signal to the preemption process; and
When receiving the termination signal from the preemption process, disconnecting a thread connected to the debuggee process and terminating the debuggee process
A computer program, including. According to clause 6,
The preemption step is,
creating the monitor thread to process the termination signal from the preempting process
A computer program further comprising: According to clause 6,
The waiting step is,
A computer program that ignores signals associated with the debugging operation other than the termination signal. According to paragraph 1,
The debugger blocking method is:
Connecting the debuggee process to the preemption process through a system call to preempt a debugging operation for the preemption process
A computer program further comprising: According to paragraph 1,
The debugger blocking method is:
When receiving the termination signal from the preemption process, another preemption process to preempt the debuggee process is executed, and the executed other preemption process is connected to the debuggee process through a system call to connect to the debuggee process. Steps to maintain preemption of debugging operations for
A computer program further comprising: According to paragraph 1,
The debugger blocking method is:
When the preemption process receives the termination signal from the debuggee process, re-executing the debuggee process based on the termination signal.
A computer program further comprising: In a method of blocking a debugger executed by a processor of a computer,
executing a preemption process to preempt the debuggee process in response to execution of a debuggee process associated with the computer program to protect a debugging operation for the computer program; and
Connecting the executed preemption process to the debuggee process through a system call to preempt a debugging operation for the debuggee process
Including,
The preemption step is,
Finding a thread created in association with the debuggee process before execution of the preemption process and connecting it to the preemption process through a system call;
Waiting in the preemption process for a signal to be received from the debuggee process; and
When the preempting process receives a thread creation signal from the debuggee process, connecting the preemption process to the thread created in the debuggee process through a system call.
Including,
The debuggee process includes a monitor thread to ignore signals other than a termination signal from the preemptive process.
A debugger blocking method characterized by . According to clause 12,
The steps to execute the above are,
When executing the debuggee process, executing the preemption process with the same permissions as the debuggee process through forking the debuggee process.
Debugger blocking methods, including: According to clause 12,
The preemption step is,
When receiving the termination signal from the debuggee process, disconnecting a thread connected to the preemption process and terminating the preemption process; and
Ignoring signals other than the thread creation signal and the termination signal.
A debugger blocking method further comprising: delete According to clause 12,
The preemption step is,
Waiting in the debuggee process for a signal to be received from the preemption process;
When creating a thread associated with the debuggee process, transmitting a thread creation signal to the preemption process;
When receiving the termination signal from the preemption process, disconnecting a thread connected to the debuggee process and terminating the debuggee process; and
Ignoring signals other than the termination signal
Debugger blocking methods, including . According to clause 16,
The preemption step is,
creating the monitor thread to process the termination signal from the preempting process
Debugger blocking methods, including . A computer-readable recording medium recording a computer program for executing the method of any one of claims 12 to 14, 16, or 17 on a computer.

Images