WO2018159881A1

WO2018159881A1 - Debugging detection method and system using inter-thread message processing

Info

Publication number: WO2018159881A1
Application number: PCT/KR2017/002295
Authority: WO
Inventors: 정상민; 전상훈; 정명주; 안성범; 서동필; 한광희; 김태우; 임성열; 류주현
Original assignee: 라인 가부시키가이샤
Priority date: 2017-03-03
Filing date: 2017-03-03
Publication date: 2018-09-07

Abstract

Provided is a debugging detection method and system using inter-thread message processing. A debugging detection method for a computer program may comprise the steps of: generating a request thread for requesting a message event; generating a reception thread for receiving the message event; generating the message event in the request thread, and checking a request time point of the message event; transferring the generated message event to the reception thread; confirming, as a reception time point, a first time point at which the message event has been received in the reception thread via a storage or a second time point at which the request thread has received a reception confirmation message event of the reception thread in response to the message event; calculating a time difference from the request time point to the reception time point; and determining whether debugging has been performed, on the basis of the time difference.

Description

Debugging detection method and system using message processing between threads

The following description relates to a debugging detection method using inter-thread message processing, a debugging detection system, and a computer program coupled to a computer and stored on a computer readable recording medium for executing the debugging detection method on a computer.

Applications distributed to client terminals can understand its operation through reverse engineering (reversing), and this reverse engineering enables the theft of application functions. In addition, by modifying the original function of the application to allow the application to operate differently from the intended operation, it may adversely affect the service provided through the application and the reliability of the system providing the service.

Debugging is essential in the analysis process of the application through reverse engineering, and thus, there are conventional techniques for detecting whether such debugging occurs. For example, the client terminal on which the application is installed and run may check a flag value indicating whether to debug using an API provided by the operating system, and determine whether to debug based on the checked flag value. However, such a prior art has a problem in that the flag value of the API provided by the operating system can be simply changed through reverse engineering, and the code for performing debugging detection can be easily bypassed through such reverse engineering.

In addition, there is a conventional technology that prevents debugging of the application to be protected by using a separate monitoring application. For example, Korean Patent No. 10-1054318 discloses a program to prevent the interpreting behavior of a program by a debugger. However, this conventional technology has a problem that it is assumed that a separate monitoring program should be installed and run on the client terminal.

Reference: <PCT / KR / 2014/010167, US20140019540A1, US20130332543A1, US20130260893>

It is combined with a debugging detection method, a debugging detection system, and a computer that detects debugging even when a single thread or an entire thread is stopped by using the speed difference of the message event processing that is always performed for the application to execute the debugging detection method. A computer program stored in a computer readable recording medium for execution by a computer is provided.

A computer program coupled to a computer and stored on a computer-readable recording medium for executing a debugging detection method on a computer, the method comprising: creating a request thread requesting a message event; Creating a receiving thread to receive the message event; Generating a message event in the request thread to identify a request time of the message event; Delivering the generated message event to the receiving thread; Confirming, as a reception time, a first time point at which the message event is received by the receiving thread through a storage, or a second time point at which the request thread receives an acknowledgment message event of the receiving thread for the message event; Calculating a time difference from the request time to the reception time; And determining whether or not to debug based on the parallax.

A debugging detection method for a computer program, comprising: creating a request thread requesting a message event; Creating a receiving thread to receive the message event; Generating a message event in the request thread to identify a request time of the message event; Delivering the generated message event to the receiving thread; Confirming, as a reception time, a first time point at which the message event is received by the receiving thread through a storage, or a second time point at which the request thread receives an acknowledgment message event of the receiving thread for the message event; Calculating a time difference from the request time to the reception time; And it provides a debugging detection method comprising the step of determining whether to debug based on the time difference.

A computer program for recording a computer program for executing the debugging detection method is provided.

You can detect debugging even when a single thread or all threads are stopped by taking advantage of the rate difference in message event processing that is normally performed for an application to run.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.

2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention.

3 is a diagram for describing message event processing between threads according to an embodiment of the present invention.

4 is a diagram for one example of detecting a debugging behavior through time difference for a message event according to one embodiment of the present invention.

5 is a diagram illustrating another example in which a debugging behavior is detected through a time difference for a message event according to one embodiment of the present invention.

6 is a block diagram illustrating an example of components that may be included in a processor of an electronic device according to an embodiment of the present invention.

7 is a flowchart illustrating an example of a debugging detection method that may be performed by an electronic device according to an embodiment of the present invention.

8 is a flowchart illustrating an example of a process of calculating parallax according to an embodiment of the present invention.

9 is a flowchart illustrating another example of a process of calculating parallax according to an embodiment of the present invention.

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

The debugging detection system according to the embodiments of the present invention may be implemented through an electronic device to be described later, and the debugging detection method according to the embodiments of the present invention may be performed through the electronic device described above. For example, a computer program (for example, an application installed in the electronic device to receive a specific service) may be installed and driven in the electronic device, and the electronic device may control the driven computer program. In accordance with the present invention, a debugging detection method may be performed. The computer program described above may be combined with an electronic device implemented as a computer and stored in a computer-readable recording medium for executing a debugging detection method on a computer.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention. The network environment of FIG. 1 illustrates an example including a plurality of

electronic devices

110, 120, 130, and 140, a plurality of

servers

150 and 160, and a network 170. 1 is an example for describing the present invention, and the number of electronic devices or the number of servers is not limited as shown in FIG. 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 a smart phone, a mobile phone, a navigation device, a computer, a notebook computer, a digital broadcasting terminal, a personal digital assistant (PDA), and a portable multimedia player (PMP). Tablet PC). For example, although FIG. 1 illustrates the shape of a smart phone as an example of the electronic device 1 110, in the embodiments of the present invention, the electronic device 1 110 may use a wireless or wired communication method to substantially connect the network 170. It may mean one of various physical devices that can communicate 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 using a communication network (for example, a mobile communication network, a wired internet, a wireless internet, a broadcasting network) that the network 170 may include, but also a 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). And one or more of networks such as the Internet. The network 170 may also include any one or more of network topologies, including bus networks, star networks, ring networks, mesh networks, star-bus networks, trees, or hierarchical networks, but It is not limited.

Each of the

servers

150 and 160 communicates with the plurality of

electronic devices

110, 120, 130, and 140 through the network 170 to provide a command, code, file, content, service, or the like. It may be implemented in 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 may also have a network ( It may be a system that provides a second service to the plurality of

electronic devices

110, 120, 130, and 140 connected through the 170. As a more specific example, the server 150 may provide a service associated with an application (computer program) installed in the plurality of

electronic devices

110, 120, 130, and 140 as the first service. As another example, the server 160 may provide a service for 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.

2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention. 2 illustrates an internal configuration of the electronic device 1 110 and the server 150 as an example of the electronic device. In addition, the other

electronic devices

120, 130, 140, or the server 160 may also have the same or similar internal configuration as the aforementioned electronic device 1 110 or the server 150.

The electronic device 1 110 and the server 150 may include

memories

211 and 221,

processors

212 and 222,

communication modules

213 and 223, and input /

output interfaces

214 and 224. The

memories

211 and 221 are computer-readable recording media, and may include non-volatile permanent storage devices such as random access memory (RAM), read only memory (ROM), and disk drives. In this case, the non-volatile mass storage device such as a ROM and a disk drive may be included in the electronic device 1 110 or the server 150 as a separate permanent storage device that is separated from the

memories

211 and 221. In addition, the

memory

211, 221 includes an operating system and at least one program code (for example, a browser installed and driven in the electronic device 1 110 or an application installed in the electronic device 1 110 to provide a specific service). Code) can be stored. These software components may be loaded from a computer readable recording medium separate from the

memories

211 and 221. Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, a disk, a tape, a DVD / CD-ROM drive, a memory card, and the like. In other embodiments, software components may be loaded into the

memory

211, 221 through the

communication module

213, 223 rather than a computer readable recording medium. For example, at least one program is a computer program that is installed by files provided by a file distribution system (for example, the server 160 described above) through the network 170 to distribute installation files of developers or applications. It may be loaded into the

memories

211 and 221 based on (for example, the above-described application).

Processors

212 and 222 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to the

processors

212, 222 by the

memory

211, 221 or the

communication modules

213, 223. For example, the

processors

212 and 222 may be configured to execute a command received according to a program code stored in a recording device such as the

memory

211 and 221.

The

communication modules

213 and 223 may provide a function for the electronic device 1 110 and the server 150 to communicate with each other through the network 170, and the electronic device 1 110 and / or the server 150 may communicate with each other. May provide a function for communicating with another electronic device (eg, electronic device 2 120) or another server (eg, server 160). For example, a request generated by the processor 212 of the electronic device 1 110 according to a program code stored in a recording device such as the memory 211 may be controlled by the server 170 through the network 170 under the control of the communication module 213. 150). Conversely, control signals, commands, contents, files, and the like provided according to the control of the processor 222 of the server 150 are transmitted to the communication module of the electronic device 1 110 via the communication module 223 and the network 170 ( It may be received by the electronic device 1110 through 213. For example, the control signal, command, content, file, etc. of the server 150 received through the communication module 213 may be transmitted to the processor 212 or the memory 211, and the content, file, etc. may be transferred to the electronic device 1. 110 may be stored as a storage medium (permanent storage described above) that may further include.

The input / output interface 214 may be a means for interfacing with the input / output device 215. For example, the input device may include a device such as a keyboard or a mouse, and the output device may include a device such as a display or a speaker. As another example, the input / output interface 214 may be a means for interfacing with a device in which functions for input and output are integrated into one, such as a touch screen. The input / output device 215 may be configured as one device with the electronic device 1110. In addition, the input / output interface 224 of the server 150 may be a means for interfacing with an apparatus (not shown) for input or output that may be connected to or included in the server 150. As a more specific example, the processor 212 of the electronic device 1110 uses data provided by the server 150 or the electronic device 2 120 in processing a command of a computer program loaded in the memory 211. The service screen or the content may be displayed on the display through the input / output interface 214.

Also, in other embodiments, the electronic device 1 110 and the server 150 may include more components than those of FIG. 2. However, it is not necessary to clearly show most of the prior art components. For example, the electronic device 1 110 may be implemented to include at least some of the above-described input / output devices 215 or other components such as a transceiver, a global positioning system (GPS) module, a camera, various sensors, a database, and the like. It may further include elements. More specifically, when the electronic device 1 110 is a smartphone, an acceleration sensor, a gyro sensor, a camera module, various physical buttons, a button using a touch panel, an input / output port, and vibration for a smartphone generally include Various components such as a vibrator may be implemented to be further included in the electronic device 1 110.

3 is a diagram for describing message event processing between threads according to an embodiment of the present invention. FIG. 3 discloses a plurality of threads 310 to 340 generated to process functions of an application (computer program) installed and driven in an electronic device (for example, the electronic device 1 110 described above). Although FIG. 3 discloses four threads 310 to 340, the number is not limited to that of FIG. 3, and the number of threads created and running at one time may vary according to the application (or the current state of the application). It is self-evident. 3 illustrates an example in which a request thread for processing a debugging detection method according to an embodiment of the present invention is implemented as a sub thread 3 330 and a receiving thread as a main thread 340. Other embodiments in which both the request thread and the receive thread may be implemented as sub-threads through the description according to the present embodiment will be easily understood. In other words, the processing of message events between the requesting thread and the receiving thread may be utilized by utilizing a general message routine of the main thread or by creating a thread that requests or processes a message event.

In the embodiment of FIG. 3, the sub-threads 310 to 330 may request the main thread 340 to process a message event. Message events for which the sub-threads 310-330 request processing may be stored in storage 350, which may be implemented as a message queue, for example, and sequentially (eg, First In Through a first-in, first-out process such as First Out)) to the main thread 340 for processing.

On the other hand, for reverse engineering of an application (computer program), debugging is indispensable, and when debugging is in progress, one or more threads are essentially stopped. In this case, since the debugger analyzes the progress of the application step by step, debugging requires physical time that can be perceived by humans. Therefore, the time required for debugging is compared to the time spent by the thread to process the message event or the time that the message event is stored in the storage 350 (the time the next message event waits to process the previous message event). It requires a relatively large amount of time. According to this characteristic, a time difference between a time point at which a message event is requested (hereinafter, referred to as a request time point) and a time point at which the main thread 340 receives a corresponding message event through the storage 350 (hereinafter, referred to as a 'first time point') or Debugging proceeds by using a time difference between the request time and a time point at which the sub thread 3 330, which is a request thread, receives the acknowledgment message event for the message event from the main thread 340 (hereinafter, referred to as 'second time'). Whether it can be detected. In this case, the first time point or the second time point may be a reception time, and the time difference may be a time difference value obtained by subtracting the request time from the reception time.

For example, the subthread 3 330, which is a request thread, may periodically transmit a message event to the main thread 340. At this time, when the above-described parallax exceeds a threshold value, it may be determined that debugging has occurred. The threshold can be determined in various ways. For example, in a test environment for a specific application, the request thread may periodically send a message event to the receiving thread n times, and calculate the n time difference values to set a maximum value among the calculated time difference values as a threshold value. . Alternatively, the threshold value may be set by adding an average value of n parallax values to a predetermined value. As another example, the time set in the operating system may be set as a threshold to generate an error message when the operating system has no answer from the main thread. The time set in the operating system will be easily understood by those skilled in the art through the related art related to the operating system.

On the other hand, even when debugging is not in progress, there is a possibility that the calculated time difference exceeds a threshold value in a special case such as an error. To this end, in embodiments of the present invention, it may be determined that debugging is in progress when the number of times when the parallax exceeds the threshold exceeds a predetermined number (for example, ten times).

In this way, whether debugging is necessary for the analysis process of reverse engineering is judged by using the speed difference of the message event processing that is always performed to execute an application, so that the debugging operation can be detected even when a single thread or the entire thread is stopped. Can be.

4 is a diagram for one example of detecting a debugging behavior through time difference for a message event according to one embodiment of the present invention. In this embodiment, the request thread 410 may generate a message event 1 430 for requesting processing by the receiving thread 420. In this case, the request thread 410 adds the request time a of the message event 1 430 and the integrity check information b of the message event 1 430 to the message event 1 430, thereby receiving the receiving thread ( 420). The requested message event 1 430 may be stored in the storage 440 and delivered to the receiving thread 420 when the processing order thereof is reached. The request time a may be added to the message event 1 430 in the form of a time stamp.

In this case, the reception thread 420 may first check the reception time c when the message event 1 430 is received through the storage 440. For example, the reception thread 420 may generate a timestamp of when the message event 1 430 is received as the reception time c.

In addition, the reception thread 420 may check the integrity of the message event 1 430 by using the integrity check information b added to the message event 1 430. For example, a hash value that is a result of inputting a message event 1 430 to which a request time a is added as a parameter of a preset hash function may be calculated as integrity verification information b. As such, those skilled in the art will readily appreciate that one of a variety of prior art techniques for verifying the integrity of data may be used.

In addition, the receiving thread 420 may check the request time a in the integrity confirmation message event 1 (430). Thereafter, the reception thread 420 may calculate the time difference d between the reception time c and the request time a.

In this case, the reception thread 420 may detect the debugging according to the comparison result by comparing the calculated time difference d with a preset threshold value e associated with the corresponding application. For example, the reception thread 420 may determine that debugging is in progress when the parallax d exceeds the threshold value e. According to an embodiment, the reception thread 420 calculates a time difference for a plurality of message events and compares it with a threshold value. When the number of times that the calculated time difference exceeds the threshold exceeds a predetermined number (for example, ten times), You can also decide that debugging is in progress.

5 is a diagram illustrating another example in which a debugging behavior is detected through a time difference for a message event according to one embodiment of the present invention. If the embodiment of FIG. 4 detects debugging in the receiving thread 420, FIG. 5 describes an embodiment of detecting debugging in the request thread 510.

The request thread 510 may generate the message event 1 530 and add the request time a and the integrity check information b of the message event 1 530 to the message event 1 530 and deliver the message event 1 530 to the receiving thread 520. . This message event 1 530 may first be stored in the storage 540 for the receiving thread 520 and delivered to the receiving thread 520 in its processing order.

The receiving thread 520 may check the integrity of the message event 1 530 by using the integrity check information b included in the message event 1 530, and the acknowledgment message event 1 550 for the message event 1 530. ) May be generated and delivered to the request thread 510. In this case, the reception thread 520 may add the request time a and the integrity confirmation information c to the acknowledgment message event 1 550 and transmit it to the request thread 510. In this case, the integrity acknowledgment information c is information for confirming the integrity of the acknowledgment message event 1 550 (for example, the above-described hash value). The acknowledgment message event 1 550 to which the request time a is added is a parameter of the hash function. It may be a result value entered as.

The acknowledgment message event 1 550 may also be delivered to the request thread 510 via the storage of the request thread 510 (for example, the message queue), but a description of the stationary of the request thread 510 is omitted. .

The request thread 510 may confirm a reception time d at which the acknowledgment message event 1 550 was received, and may verify the integrity of the acknowledgment message event 1 550 using the integrity confirmation information c. In addition, the request thread 510 may check the request time a added to the acknowledgment message event 1 550, and calculate a time difference e between the reception time d and the request time a. In this case, the request thread 510 may compare the parallax e with the threshold value f and determine that debugging is in progress when the parallax e exceeds the threshold value f. According to an embodiment, the request thread 510 may calculate a plurality of parallaxes using a plurality of message events and a plurality of acknowledgment message events, compare the parallaxes with a threshold, and calculate the parallax exceeding a threshold. If the number exceeds a certain number (for example, ten times), you may decide that debugging is in progress.

6 is a block diagram illustrating an example of a component that may be included in a processor of an electronic device according to an embodiment of the present invention, and FIG. 7 illustrates debugging that may be performed by the electronic device according to an embodiment of the present invention. A flowchart illustrating an example of a detection method.

As described above, the debugging detection system according to the exemplary embodiments of the present invention may be implemented in the form of a computer device such as the electronic device 1 110 in which a specific application is installed and driven. In addition, as shown in FIG. 6, the processor 212 of the electronic device 1 110 is a component for implementing a debugging detection system, and includes a request thread generator 610, a receiver thread generator 620, and a request timing check. The unit 630 may include a message event transmitter 640, a reception time checker 650, a disparity calculator 660, and a debugging decision determiner 670. The processor 212 and the components of the processor 212 may control the electronic device 1110 to perform steps 710 to 770 included in the debugging detection method of FIG. 7. In this case, the processor 212 and the components of the processor 212 may be implemented to execute instructions according to code of an operating system included in the memory 211 or code of at least one program. Here, the components of the processor 212 may be representations of different functions of the processor 212 performed by the processor 212 according to a control command provided by a code stored in the electronic device 1110. Can be. For example, the request thread generator 610 may be used as a functional representation of the processor 212 in which the processor 212 generates a request thread according to the above-described control command.

In operation 710, the request thread generator 610 may generate a request thread for requesting a message event. How the processor 212 creates a thread, how to deliver a message event between threads, a general method of handling the delivered message event, and the like will be readily understood by those skilled in the art through well known techniques. The request thread may be a general sub thread that communicates with the main thread of an application (computer program) that is subject to debugging detection, or may be a separate thread that is generated for the present embodiment and generates a special message event to request processing. .

In operation 720, the reception thread generator 620 may generate a reception thread that receives a message event. As described above, the reception thread may be a main thread of an application (computer program) that is a target of debugging detection, but is not limited thereto and may be a thread that is separately created for processing a message event requested by the requesting thread.

In operation 730, the request point checking unit 630 may check the request point of the message event generated by the request thread. This confirmation of the request time point may be substantially processed in the request thread, and the confirmed request time point may be added to the requested message event as described above.

In operation 740, the message event transmitter 640 may deliver the message event to the receiving thread. In this case, the message event may be delivered to the receiving thread through a storage such as a message queue storing messages requested by the receiving thread. As described above, message events stored in the message queue may be sequentially delivered to the receiving thread through a first-in, first-out processing method such as FIFO. If debugging is in progress, the message event stored in the repository will take a relatively large amount of time compared to the case where debugging is not progressed until the steps are taken in debugging and the order for processing the message event comes.

In operation 750, the reception point confirming unit 650 receives a first point in time at which a message event is received by the reception thread through a store or a second point in time when the request thread receives an acknowledgment message event of the reception thread for the message event. It can confirm as a viewpoint. Embodiments of the present invention relate to a technique for detecting debugging by using a time difference between a request time of a message event and a reception time of a message event, and the request time and the reception time may be determined in various ways. An embodiment in which the first view is used as a reception point has been described with reference to FIG. 4, and an embodiment in which the second view is used as the reception point has been described with reference to FIG. 5.

In operation 760, the disparity calculator 660 may calculate the disparity from the request time to the reception time. For example, the parallax calculation unit 660 may calculate the parallax by subtracting the value of the request time from the value of the reception time.

In operation 770, the debugging decision unit 770 may determine whether to debug based on the calculated parallax. For example, the debugging decision unit 770 may determine that debugging is detected when the calculated parallax exceeds a predetermined threshold. As another example, the debugging decision unit 770 may count when the calculated parallax exceeds a preset threshold value, and may determine that debugging is detected when the counted count exceeds the preset number.

8 is a flowchart illustrating an example of a process of calculating parallax according to an embodiment of the present invention. In the present embodiment, step 740 may include steps 810 through 830 as shown in FIG. 8, and step 750 may include steps 840 through 860 as shown in FIG. 8.

In operation 810, the message event transmitter 640 may add a first timestamp indicating the confirmed request time to the message event. In other words, the message event delivered to the receiving thread may include a first timestamp as information on a request time.

In operation 820, the message event transmitter 640 may generate integrity confirmation information of the message event to which the first time stamp is added. As described above, the message event to which the first time stamp is added is input as a parameter of a preset hash function, and the result value can be calculated as integrity confirmation information.

In operation 830, the message event transmitter 640 may add integrity confirmation information to the message event to which the first timestamp is added and transmit the integrity confirmation information to the receiving thread.

In operation 840, the reception point checker 650 may generate a second timestamp indicating a first point in time at which a message event is received. For example, the receiving thread may generate a second timestamp indicating when the message event was received when the message event is received from the repository.

In operation 850, the reception point confirming unit 650 may confirm the integrity of the message event using the integrity confirmation information added to the message event. For example, the receiving thread may extract the integrity check information from the message event, and input the message event to which the first time stamp is added as a parameter of a preset hash function to calculate a result value. In this case, when the integrity check information and the calculated result value are the same, the receiving thread may check the integrity of the message event to which the first time stamp is added.

In operation 860, the reception point acknowledgment unit 650 may transmit an acknowledgment message event for the message event to the request thread.

At this time, in step 760, the time difference calculator 660 may calculate the time difference using the first time stamp and the generated second time stamp included in the message event. In other words, FIG. 8 illustrates an embodiment in which the receiving thread calculates parallax. In this case, step 770 may also be processed in the receiving thread.

9 is a flowchart illustrating another example of a process of calculating parallax according to an embodiment of the present invention. In the present embodiment, step 740 may include steps 810 through 830 as shown in FIG. 8, and step 750 may include steps 910 through 930 as shown in FIG. 9. For example, the receiving thread may process steps 910 through 930 of FIG. 9 instead of steps 840 through 860 of FIG. 8 in processing step 750. Steps 810 to 830 are the same as in FIG. 8, and are thus omitted repeatedly.

In operation 910, the reception point confirming unit 650 may verify the integrity of the message event by using the integrity confirmation information added to the message event by the reception thread. As described above, the process of integrity extracts the integrity check information from the message event, inputs the message event with the first timestamp as a parameter of a preset hash function, calculates the result value, and then checks the integrity. This can be done by comparing the information with the calculated results.

In operation 920, the reception point checking unit 650 may check the first time stamp in the message event.

In operation 930, the reception point confirming unit 650 may generate an acknowledgment message event including the first timestamp and deliver the received acknowledgment event to the request thread.

In this case, in step 760, the time difference calculator 660 may calculate the time difference using the second time when the reception confirmation message event is received and the first time stamp included in the reception confirmation message event. In other words, in the present embodiment, steps 760 and 770 may be processed by the request thread.

In the above-described embodiments and once it is determined whether to debug via the request thread or the receiving thread, the processor 212 interrupts the execution of the application (computer program) or sends relevant information (information about the occurrence of debugging) to the network. The electronic device 1 110 may be controlled to transmit to the server (for example, the server 150 or the server 160) through the controller.

As described above, according to the embodiments of the present invention, debugging may be detected even in a stopped state of a single thread or an entire thread by using a speed difference of message event processing that is always performed to execute an application.

The system or apparatus described above may be implemented as a hardware component, a software component or a combination of hardware components and software components. For example, the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs). Can 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. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. It can be embodied in. The software may be distributed over networked computer systems so that they may be 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 embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.

Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the claims that follow.

Claims

A computer program coupled to a computer stored on a computer readable recording medium for executing a debugging detection method on a computer,

The debugging detection method,

Creating a request thread requesting a message event;

Creating a receiving thread to receive the message event;

Generating a message event in the request thread to identify a request time of the message event;

Delivering the generated message event to the receiving thread;

Confirming, as a reception time, a first time point at which the message event is received by the receiving thread through a storage, or a second time point at which the request thread receives an acknowledgment message event of the receiving thread for the message event;

Calculating a time difference from the request time to the reception time; And

Determining whether to debug based on the time difference

Computer program comprising a.
The method of claim 1,

Determining whether or not to debug,

And determine that debugging is detected when the parallax exceeds a preset threshold.
The method of claim 1,

Determining whether or not to debug,

And counting a case where the time difference exceeds a preset threshold value, and determining that debugging is detected when the counted number exceeds a preset number.
The method of claim 1,

The receiving thread comprises a main thread of the computer program,

And said storage comprises a message queue for storing messages requested to said main thread.
The method of claim 1,

Delivering the generated message event to the receiving thread,

Adding a first timestamp indicative of the confirmed request time to the message event;

Generating integrity confirmation information of the message event to which the first time stamp is added; And

Adding the integrity confirmation information to the message event to which the first timestamp is added and delivering it to the receiving thread.

Computer program comprising a.
The method of claim 5,

Confirming the first time point as the reception time point,

Generating a second timestamp indicating the first point in time at which the message event is received;

Confirming the integrity of the message event using the integrity confirmation information added to the message event; And

Forwarding an acknowledgment message event for the message event to the requesting thread;

Including,

Calculating the time difference from the request time to the reception time,

And the receiving thread calculates the time difference using a first timestamp included in the message event and the generated second timestamp.
The method of claim 5,

Confirming the second time point as the reception time point,

Checking, by the receiving thread, the integrity of the message event using the integrity confirmation information added to the message event;

Checking, by the receiving thread, the first timestamp in the message event; And

Generating, by the receiving thread, the acknowledgment message event including the first timestamp and forwarding to the requesting thread.

Including,

Calculating the time difference from the request time to the reception time,

And calculating the time difference by using the second time when the request thread receives the acknowledgment message event and the first timestamp included in the acknowledgment message event.
In the debugging detection method for a computer program,

Creating a request thread requesting a message event;

Creating a receiving thread to receive the message event;

Generating a message event in the request thread to identify a request time of the message event;

Delivering the generated message event to the receiving thread;

Confirming, as a reception time, a first time point at which the message event is received by the receiving thread through a storage, or a second time point at which the request thread receives an acknowledgment message event of the receiving thread for the message event;

Calculating a time difference from the request time to the reception time; And

Determining whether to debug based on the time difference

Debugging detection method comprising a.
The method of claim 8,

Determining whether or not to debug,

And when the time difference exceeds a preset threshold, determining that debugging is detected.
The method of claim 8,

Determining whether or not to debug,

And counting a case where the time difference exceeds a preset threshold value and determining that debugging is detected when the counted number exceeds a preset number.
The method of claim 8,

The receiving thread comprises a main thread of the computer program,

And said store comprises a message queue for storing messages requested to said main thread.
The method of claim 8,

Delivering the generated message event to the receiving thread,

Adding a first timestamp indicative of the confirmed request time to the message event;

Generating integrity confirmation information of the message event to which the first time stamp is added; And

Adding the integrity confirmation information to the message event to which the first timestamp is added and delivering it to the receiving thread.

Debugging detection method comprising a.
The method of claim 12,

Confirming the first time point as the reception time point,

Generating a second timestamp indicating the first point in time at which the message event is received;

Confirming the integrity of the message event using the integrity confirmation information added to the message event; And

Forwarding an acknowledgment message event for the message event to the requesting thread;

Including,

Calculating the time difference from the request time to the reception time,

And the receiving thread calculates the time difference using a first timestamp included in the message event and the generated second timestamp.
The method of claim 12,

Confirming the second time point as the reception time point,

Checking, by the receiving thread, the integrity of the message event using the integrity confirmation information added to the message event;

Checking, by the receiving thread, the first timestamp in the message event; And

Generating, by the receiving thread, the acknowledgment message event including the first timestamp and forwarding to the requesting thread.

Including,

Calculating the time difference from the request time to the reception time,

And the request time is calculated by the request thread using the second time when the acknowledgment message event is received and the first timestamp included in the acknowledgment message event.
A computer-readable recording medium having recorded thereon a computer program for causing a computer to execute the method of any one of claims 8-14.