Hook determination method and system using API information clustering

Abstract

To provide a method, a computer apparatus, a program and a record medium for detecting API hooking, for abusing which intercepts an API call by API hooking so as to operate in an unintended form.SOLUTION: A hooking detection method comprises: specifying position information of a function referenced by an executable module from an outside or provided to the outside or a unique value of an executable code; and determining API hooking based on a classification acquired by comparing such unique values or by clustering the unique values.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The following description relates to a hook determination method and system that utilizes API information clustering. [Background technology]

[0002] Given a program (binary or source code), analyzing and understanding how that program operates is called "reverse engineering." Companies that sell finished products (binary files) hope that their products, which contain their company's technology, will not be easily reverse-engineered. Various techniques for obfuscating program code exist to make reverse engineering difficult. Examples include adding meaningless logic or code to the source code or encrypting or encoding data such as strings contained in the source code. Another example of obfuscation is modifying the format of an executable file or assembly code to make it difficult to interpret code sections in the final executable file. Patent Document 1 (Patent Document 1) relates to an application code obfuscation device and method, and discloses applying obfuscation to applications running on a Java Virtual Machine by modifying the code structure that constitutes the application. In other words, the above-mentioned prior art discloses an example of obfuscation performed by modifying the assembly code of a built application.

[0003] Meanwhile, API (Application Programming Interface) hooking is often used as a reverse engineering technique to understand the operating status of an application or change its behavior. APIs must receive factor values in a predetermined format and return the results. This allows for abuse, such as intercepting API calls in memory to understand the call status or changing the operating method to operate in a manner not intended by the developer. Conventional techniques for detecting API hooking have included checking the execution and installation status of debuggers or disassemblers that can test API hooking, checking the execution and installation status of frameworks that can perform reversing, and checking the address values of API functions in use.

[0004] However, such prior art technology indirectly determines the risk of API hooking based on the execution status or installation status of a program that may attempt API hooking, which means that it cannot eliminate the possibility of false detection, and when the location of modules stored in memory changes depending on the system status, it is difficult to detect whether or not hooking has occurred based on the address of an API function.Furthermore, when new types of hooking programs emerge or conceal their operations, or when the location of modules stored in memory changes, it is difficult to respond to API hooking in a timely manner. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Korean Patent No. 10-1328012 Summary of the Invention [Problem to be solved by the invention]

[0006] Provided are a hook determination method and system that can determine API hooks by identifying unique values for location information or execution code of functions that an executable module references from the outside or provides to the outside, and comparing such unique values or by utilizing classifications obtained by clustering the unique values. [Means for solving the problem]

[0007] Provided is a hook detection method for a computer device including at least one processor and a memory, the hook detection method including the steps of: checking, by the at least one processor, an offset or an executable code of a target function, which is associated with an executable module stored in the memory at the time of execution of the executable module and is an internal function provided by the executable module or an external function referenced by the executable module; generating, by the at least one processor, an identification value using the offset or the executable code of the target function; and determining, by the at least one processor, whether or not to hook the executable module using the generated identification value.

[0008] Provided is a hook detection method for a computer device including at least one processor and a memory, the hook detection method including: receiving, by the at least one processor, identification values from a plurality of clients, each of the identification values being associated with an executable module stored in the memory of the plurality of clients and generated based on an offset or execution code of a target function as an internal function provided by the executable module or an external function referenced by the executable module; clustering, by the at least one processor, the received identification values according to an identifier of the corresponding module or an identifier of the corresponding target function; and comparing, by the at least one processor, the identification values against any cluster to determine a hook status of the module or target function corresponding to the any cluster.

[0009] A computer apparatus is provided, comprising: at least one processor implemented to execute computer-readable instructions; the at least one processor receives identification values from a plurality of clients, each of the identification values being associated with an executable module stored in a memory of the plurality of clients and generated based on an offset or an executable code of a target function as an internal function provided by the executable module or an external function referenced by the executable module; the received identification values are grouped according to an identifier of the corresponding module or an identifier of the corresponding target function; and the identification value for any group is compared to determine a hook state of the module or target function corresponding to the any group. [Effects of the Invention]

[0010] An API hook can be determined by identifying unique values for the location information or executable code of functions that an executable module references from the outside or provides to the outside, and comparing such unique values or by using classifications obtained by clustering the unique values. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 illustrates an example of a network environment in accordance with an embodiment of the present invention. [Figure 2] FIG. 1 is a block diagram illustrating an example of a computing device according to an embodiment of the present invention. [Figure 3] 1 is a flowchart illustrating an example method for detecting a hook, in accordance with an embodiment of the present invention. [Figure 4] 10 is a flowchart illustrating an example process for determining the offset of an external function in accordance with an embodiment of the present invention. [Figure 5] 10 is a flowchart illustrating an example process for checking the offset of an internal function in accordance with an embodiment of the present invention. [Figure 6] 10 is a flowchart illustrating an example of a process for verifying execution code of an external function in accordance with an embodiment of the present invention. [Figure 7] 10 is a flowchart illustrating an example of a process for checking an execution code of an internal function in an embodiment of the present invention. [Figure 8] FIG. 10 is a diagram illustrating an example of acquiring an offset or an execution code according to an embodiment of the present invention. [Figure 9] FIG. 10 is a diagram illustrating an example of acquiring an offset or an execution code according to an embodiment of the present invention. [Figure 10] 1 is a flowchart illustrating an example of a method for detecting a hook in a server according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0012] <Summary of the Invention> Provided is a hook detection method for a computer device including at least one processor and a memory, the hook detection method including the steps of: checking, by the at least one processor, an offset or an executable code of a target function, which is associated with an executable module stored in the memory at the time of execution of the executable module and is an internal function provided by the executable module or an external function referenced by the executable module; generating, by the at least one processor, an identification value using the offset or the executable code of the target function; and determining, by the at least one processor, whether or not to hook the executable module using the generated identification value.

[0013] According to one aspect, the checking step may include the steps of checking foreign function information referenced by the executable module, obtaining a start address of the foreign module referenced by the foreign function information, obtaining a start address of the foreign function referenced by the foreign function information, and checking a difference between the start address of the foreign function and the start address of the external module as an offset of the target function.

[0014] According to another aspect, the checking step may further include determining that a hook exists for the executable module or the target function if the start address of the external function is not within the range of the start address and end address of the external module.

[0015] According to another aspect, the checking step may include checking internal function information provided in the executable module, checking a start address of the executable module, checking a start address of an internal function provided to the outside based on the internal function information, and checking a difference between the start address of the internal function and the start address of the executable module as an offset of the target function.

[0016] According to another aspect, the checking step may further include determining that a hook exists for the executable module or the target function if the start address of the internal function is not within the range of the start address and end address of the executable module.

[0017] According to another aspect, the verifying step may include the steps of verifying external function information referenced in the executable module, obtaining an address of the external function referenced in the external function information, and obtaining an execution code recorded at the address of the external function.

[0018] According to another aspect, the step of obtaining the execution code may be characterized by obtaining execution code from a start address of the external function to an address corresponding to a size of a move instruction word, or obtaining execution code from a start address of the external function to an end address.

[0019] According to another aspect, the verifying step may include verifying internal function information provided by the executable module, obtaining an address of the internal function provided to the outside based on the internal function information, and obtaining an execution code recorded at the address of the internal function.

[0020] According to another aspect, the step of obtaining the execution code may be characterized by obtaining execution code from a start address of the internal function to an address corresponding to a size of a move instruction word, or obtaining execution code from a start address of the internal function to an end address.

[0021] According to another aspect, the step of generating the identification value may be characterized by generating the identification value by associating an offset or an executable code of the target function with at least one of an identifier of a module in which the target function is included and an identifier of the target function.

[0022] According to another aspect, the verifying step may be characterized by verifying offsets or executable codes for all internal functions provided by the executable module or all external functions referenced by the executable module, and the generating step may be characterized by generating the identification value by associating one hash information for the verified offsets or executable codes for all the internal functions or all the external functions with an identifier of a corresponding module.

[0023] According to another aspect, the step of determining whether to hook may include comparing the generated identification value with a previous identification value to determine whether to hook the executable module.

[0024] According to another aspect, the previous identification value may include an offset or executable code of the target function previously confirmed for the executable module immediately after building a package file including the executable module, an offset or executable code of the target function previously confirmed for the executable module at a previous execution time of the executable module, or an offset or executable code of the target function previously confirmed for the executable module at a regular interval.

[0025] According to another aspect, the step of determining whether to hook may be implemented by transmitting the generated identification value to a server, and the server clustering the identification values collected from the clients according to the identifiers of the linked modules or the identifiers of the target functions, and comparing the clustered identification values to determine the hook status of a specific module or a specific target function for each cluster.

[0026] According to yet another aspect, the server may be implemented to determine, among the identification values included in a specific group, the same identification values as normal identification values, and to determine, as a hook state, specific modules or specific target functions of the client corresponding to the remaining identification values.

[0027] Provided is a hook detection method for a computer device including at least one processor and a memory, the hook detection method including: receiving, by the at least one processor, identification values from a plurality of clients, each of the identification values being associated with an executable module stored in the memory of the plurality of clients and generated based on an offset or execution code of a target function as an internal function provided by the executable module or an external function referenced by the executable module; clustering, by the at least one processor, the received identification values according to an identifier of the corresponding module or an identifier of the corresponding target function; and comparing, by the at least one processor, the identification values against any cluster to determine a hook status of the module or target function corresponding to the any cluster.

[0028] A computer program is provided that causes a computer device to execute the method.

[0029] A computer-readable recording medium is provided, on which a program for causing a computer device to execute the method is recorded.

[0030] A computer apparatus is provided, comprising: at least one processor implemented to execute computer-readable instructions; the at least one processor receives identification values from a plurality of clients, each of the identification values being associated with an executable module stored in a memory of the plurality of clients and generated based on an offset or an executable code of a target function as an internal function provided by the executable module or an external function referenced by the executable module; the received identification values are grouped according to an identifier of the corresponding module or an identifier of the corresponding target function; and the identification value for any group is compared to determine a hook state of the module or target function corresponding to the any group.

[0031] <Details of the Invention> Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings.

[0032] A hook determination system according to an embodiment of the present invention may be realized by at least one computer device, and a hook determination method according to an embodiment of the present invention may be executed by at least one computer device included in the hook determination system. A computer program according to an embodiment of the present invention may be installed and executed in the computer device, and the computer device may execute the hook determination method according to an embodiment of the present invention under the control of the computer program being executed. The computer program may be recorded on a computer-readable recording medium in combination with the computer device to cause the computer device to execute the hook determination method.

[0033] FIG. 1 is a diagram showing an example of a network environment in one embodiment of the present invention. The network environment in FIG. 1 shows an example including multiple electronic devices 110, 120, 130, and 140, multiple servers 150 and 160, and a network 170. FIG. 1 is merely an example for explaining the invention, and the number of electronic devices and the number of servers are not limited to those shown in FIG. 1. Furthermore, the network environment in FIG. 1 is merely an example of an environment applicable to this embodiment, and environments applicable to this embodiment are not limited to the network environment in FIG. 1.

[0034] The electronic devices 110, 120, 130, and 140 may be fixed or mobile terminals implemented by computers. Examples of the electronic devices 110, 120, 130, and 140 include smartphones, mobile phones, navigation systems, personal computers (PCs), notebook PCs, digital broadcasting terminals, personal digital assistants (PDAs), portable multimedia players (PMPs), and tablets. While FIG. 1 illustrates a smartphone as an example of the electronic device 110, in embodiments of the present invention, the electronic device 110 may represent one of a variety of physical computer devices capable of communicating with the other electronic devices 120, 130, and 140 and / or the servers 150 and 160 via the network 170 using a substantially wireless or wired communication method.

[0035] The communication method is not limited, and may include not only communication methods using communication networks (for example, a mobile communication network, a wired Internet, a wireless Internet, and a broadcast network) that can be included in network 170, but also short-range wireless communication between devices. For example, network 170 may include any one or more of networks such as 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), a broadband network (BBN), and the Internet. Furthermore, network 170 may include any one or more of network topologies including, but not limited to, a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, etc.

[0036] Each of the servers 150, 160 may be realized by one or more computer devices that communicate with multiple electronic devices 110, 120, 130, 140 via the network 170 to provide instructions, code, files, content, services, etc. For example, the server 150 may be a system that provides services (such as a file distribution service, a map service, a content provision service, a group call service (or an audio conference service), a messaging service, an email service, a social networking service, a translation service, a financial service, a payment service, a search service, etc.) to multiple electronic devices 110, 120, 130, 140 connected via the network 170.

[0037] 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention. Each of the electronic devices 110, 120, 130, and 140 and each of the servers 150 and 160 described above may be realized by a computer device 200 shown in FIG.

[0038] As shown in FIG. 2 , such a 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 storage medium and may include random access memory (RAM), read-only memory (ROM), and a persistent mass storage device such as a disk drive. The persistent mass storage device such as a ROM or a disk drive may be included in the computer device 200 as a separate persistent storage device distinct from the memory 210. The memory 210 may also store an operating system and at least one program code. Such software components may be loaded into the memory 210 from a computer-readable storage medium separate from the memory 210. Such separate computer-readable storage medium may include a computer-readable storage medium such as a floppy drive, a disk, a tape, a DVD / CD-ROM drive, or a memory card. In another embodiment, the software components may be loaded into the memory 210 through a communication interface 230, which is not a computer-readable storage medium. For example, the software components may be loaded into the memory 210 of the computer device 200 based on a computer program installed by a file received over the network 170 .

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

[0040] The communication module 230 may provide a function for the computer device 200 to communicate with other devices (e.g., the above-mentioned storage device) via the network 170. For example, requests, instructions, data, files, etc. generated by the processor 220 of the computer device 200 in accordance with program code stored in a storage device such as the memory 210 may be transmitted to other devices via the network 170 under the control of the communication interface 230. Conversely, signals, instructions, data, files, etc. from other devices may be received by the computer device 200 via the communication interface 230 of the computer device 200 via the network 170. The signals, instructions, data, etc. received via the communication module 230 may be transmitted to the processor 220 or the memory 210, and files, etc. may be recorded on a storage medium (e.g., the above-mentioned permanent storage device) that the computer device 200 may further include.

[0041] The input / output interface 240 may be a means for interfacing with the input / output device 250. For example, the input device may include a device such as a microphone, keyboard, or mouse, and the output device may include a device such as a display or speaker. As another example, the input / output interface 240 may be a means for interfacing with a device that integrates input and output functions into one, such as a touch screen. The input / output device 250 may be configured as a single device together with the computer device 200.

[0042] Also, in other embodiments, computing device 200 may include fewer or more components than those shown in Figure 2. However, most prior art components need not be explicitly shown in the figures. For example, computing device 200 may be implemented to include at least some of the input / output devices 250 described above, and may further include other components such as a transceiver, a database, etc.

[0043] FIG. 3 is a flowchart illustrating an example of a hook detection method for a client according to an embodiment of the present invention. The hook detection method according to this embodiment may be performed by a client computer device 200 that executes a computer program utilizing at least an executable module that is the target of hook detection. In this case, the processor 220 of the computer device 200 may be configured to execute control instructions from operating system code and at least one computer program code stored in the memory 210. Here, the processor 220 may control the computer device 200 to perform steps 310 to 330 of the method of FIG. 3 according to the control instructions provided by the code stored in the computer device 200.

[0044] In step 310, the computer device 200 may identify the offset or execution code of a target function associated with the executable module stored in the memory 210 at the time of execution of the executable module, as an internal function provided by the executable module or an external function referenced by the executable module.

[0045] An executable module may refer to a function (an external function from the perspective of the executable module, hereinafter referred to as an "external function") included in another external module (an external module from the perspective of the executable module, hereinafter referred to as an "external module") based on an API call, or may provide its own function (an internal function from the perspective of the executable module, hereinafter referred to as an "internal function") based on an API call from an external module. At this time, the computer device 200 may check the offset or executable code of a target function as an external or internal function. The offset may be used as a unique value for the location of the target function, and the executable code may be used as a unique value for the content of the target function. These unique values may then be used to generate an identification value in step 320. At this time, at least one of the offset of the external function and the executable code of the external function may be used, and / or at least one of the offset of the internal function and the executable code of the internal function may be used to generate the identification value. A method for obtaining the offset or executable code of a function will be described in more detail with reference to FIGS. 4 to 7.

[0046] In step 320, the computer device 200 may generate an identification value using an offset or executable code of the target function. In one embodiment, the computer device 200 may generate the identification value by associating the offset or executable code of the target function with at least one of an identifier of a module including the target function and an identifier of the target function. Here, the module including the target function may be an external module for an external function, or an executable module for an internal function. For example, the module identifier may be a module name, and the function identifier may be a function name. However, any value that can identify a specific module or function may be used without limitation. In another embodiment, in step 310, the computer device 200 may check the offset or executable code for each of all internal functions provided by the executable module or all external functions referenced by the executable module. In this case, in step 320, the computer device 200 may generate the identification value by associating one hash of the offset or executable code identified for all internal functions or all external functions with the identifier of the corresponding module.

[0047] In operation 330, the computer device 200 may determine whether to hook the executable module using the generated identification value. When an API hook occurs and a target function is hooked, causing a function other than the target function to be executed, the offset and / or executable code of the other function will be different from the offset and / or executable code of the target function. This means that identification values obtained for the same module and / or function will differ depending on the occurrence of the API hook. Therefore, the computer device 200 can determine whether to hook the executable module using the generated identification value. As a more specific example, the computer device 200 may compare the generated identification value with a previous identification value to determine whether to hook the executable module. In this case, if the generated identification value and the previous identification value are not the same, the computer device 200 can determine that a hook has occurred for the currently running executable module and / or target function. Here, the previous identification value may include (1) an offset or executable code of a target function previously confirmed for an executable module immediately after building a package file including the executable module, (2) an offset or executable code of a target function previously confirmed for an executable module at a previous execution time of the executable module, and / or (3) an offset or executable code of the target function previously confirmed for the executable module at regular intervals.

[0048] For example, if the identification value includes an offset of a target function, an identification value generated for the target function that is not the same as a previous identification value generated for the target function means that an API hook has occurred for the target function. As another example, if the identification value includes hash information for the offsets or executable codes of all internal functions provided by the executable module, an identification value that is not the same as a previous identification value means that an API hook has occurred for at least one of the internal functions of the executable module. As another example, if the identification value includes hash information for the offsets or executable codes of all external functions provided by the executable module, an identification value that is not the same as a previous identification value means that an API hook has occurred for a specific external module (particularly, at least one of the external functions referenced by the external module).

[0049] In this way, in the hook detection method according to this embodiment, a unique value (previous identification value) for the location information and content of the API function associated with the executable function is identified in advance, and the occurrence of a hook can be detected by comparing the identification value generated at the time of execution of the executable function with the previous identification value.

[0050] 4 is a flowchart illustrating an example of a process for checking the offset of an external function according to an embodiment of the present invention. Steps 410 to 450 illustrated in FIG. 4 are included in step 310 of FIG. 3 and may be performed by computer device 200.

[0051] In step 410, the computing device 200 may check the foreign function information referenced in the executable module. As an example, the foreign function information may correspond to an Import Address Table (IAT) defined for the executable module.

[0052] In step 420, the computer device 200 may obtain the start address of the external module referenced in the external function information.

[0053] In step 430, the computer device 200 may obtain the starting address of the external function referenced in the external function information.

[0054] In step 440, the computer device 200 may determine that a hook exists for the executable module or target function if the start address of the external function is not within the start address and end address range of the external module. The start address of an external function included in the external module must be at least within the start address and end address range of the external module. If an external function is hooked and another function is executed, the start address of the other function is recorded in the external function information as the start address of the external function, and the start address of the other function falls outside the start address and end address range of the external module. Therefore, in this case, it is possible to immediately determine whether a hook exists without using an offset as an identification value.

[0055] In operation 450, the computer device 200 may determine the difference between the start address of the foreign function and the start address of the external module as the offset of the target function. This offset may represent a relative address of the foreign function with respect to the start address of the external module. Even if the start address of the external module changes at each execution time, the offset of the foreign function does not change. Therefore, if an identification value including this offset is different from the previous identification value, it means that a hook has occurred for the corresponding foreign function and another function is being executed.

[0056] 5 is a flowchart illustrating an example of a process for checking the offset of an internal function according to an embodiment of the present invention. Steps 510 to 550 illustrated in FIG. 5 are included in step 310 of FIG. 3 and may be performed by computer device 200.

[0057] In step 510, the computer device 200 may check the internal function information provided in the executable module. As an example, the internal function information may correspond to an Export Address Table (EAT) defined for the executable module.

[0058] At step 520, the computing device 200 may ascertain the starting address of the executable module.

[0059] In step 530, the computer device 200 may determine the start address of the internal function provided to the outside based on the internal function information.

[0060] In step 540, the computer device 200 may determine that a hook exists for the executable module or target function if the start address of the internal function is not within the range of the start address and end address of the executable module. The start address of an internal function included in an executable module must be within the range of the start address and end address of the executable module. If an internal function is hooked and another function is executed, the start address of the other function is recorded in the internal function information as the start address of the internal function, and the start address of the other function falls outside the range of the start address and end address of the executable module. Therefore, in this case, it is possible to immediately determine whether a hook exists without using an offset as an identification value.

[0061] In operation 550, the computer device 200 may determine the difference between the start address of the internal function and the start address of the executable module as the offset of the target function. This offset may represent a relative address of the internal function with respect to the start address of the executable module. Even if the start address of the executable module changes at each execution time, the offset of the internal function does not change. Therefore, if an identification value including this offset is different from the previous identification value, it means that a hook has occurred for the corresponding internal function and another function is being executed.

[0062] 6 is a flowchart illustrating an example of a process for verifying the execution code of an external function according to an embodiment of the present invention. Steps 610 to 630 illustrated in FIG. 6 are included in step 310 of FIG. 3 and may be performed by computer device 200.

[0063] In step 610, the computing device 200 may check the foreign function information referenced in the executable module. As described above, the foreign function information may correspond to an Import Address Table (IAT) defined for the executable module.

[0064] In step 620, the computer device 200 may obtain the address of the external function referenced in the external function information. As an example, the address of the external function may include the start address of the external function recorded in the external function information.

[0065] In step 630, the computer device 200 may obtain the executable code recorded at the address of the external function.

[0066] In one embodiment, the computer device 200 may acquire executable code from the start address of the external function to an address corresponding to the size of the move instruction. Here, the move instruction may correspond to a hook instruction. For example, if a hook instruction is inserted into the start address of the external function, the executable code from the start address of the external function to an address corresponding to the size of the move instruction may correspond to the hook instruction. In other words, the executable code acquired before and after the hooking may change. If an identification value including such executable code is different from the previous identification value, it means that a hook has been generated for the corresponding external function and another function is being executed.

[0067] In another embodiment, the computer device 200 may obtain the execution code from the start address to the end address of the external function. This means obtaining the entire execution code for the external function. In this case, if a hook instruction is inserted into the external function, the execution code may be changed. If the identification value including the execution code is different from the previous identification value, it means that a hook has occurred for the corresponding external function and another function is being executed.

[0068] 7 is a flowchart illustrating an example of a process for checking the execution code of an internal function according to an embodiment of the present invention. Steps 710 to 730 illustrated in FIG. 7 are included in step 310 of FIG. 3 and may be performed by computer device 200.

[0069] In step 710, the computing device 200 may check the internal function information provided in the executable module. As described above, the internal function information may correspond to an Export Address Table (EAT) defined for the executable module.

[0070] In step 720, the computer device 200 may obtain an address of the internal function provided to the outside based on the internal function information, where the address of the internal function may include a start address of the internal function.

[0071] In operation 730, the computer device 200 may obtain the executable code recorded at the address of the internal function. In this case, the computer device 200 may obtain the executable code from the start address of the internal function to an address corresponding to the size of the move instruction, or from the start address to the end address of the internal function. When a hook instruction is inserted into the internal function and the executable code is changed, the identification value including the executable code and the previous identification value should be different, and therefore, it is possible to detect the occurrence of a hook on the internal function.

[0072] The identification value may be generated to include (1) the offset of the external function, (2) the offset of the internal function, (3) the execution code of the external function, or (4) the execution code of the internal function, but may also be generated to include two or more of (1) to (4).As described above, the identification value may be generated by converting the offsets or execution codes of all API functions of the module into a single hash function.

[0073] 8 and 9 are diagrams showing an example of obtaining an offset in an embodiment of the present invention. Figures 8 and 9 show examples of an executable module 810 and an external module 820 stored in the memory 210 of the computer device 200. The executable module 810 includes a code section (Code) 811, a data section (Data) 812, an IAT section (Import) 813, and an EAT section (Export) 814, and the external module 820 similarly includes a code section (Code) 821, a data section (Data) 822, an EAT section (Export) 823, and an IAT section (Import) 824.

[0074] In this case, FIG. 8 shows that for an external function 825 referenced by executable module 810, the start address of external module 820 and the start address of external function 825 are recorded in IAT section (Import) 813 of executable module 810, and the offset of external function 825 can be obtained using the difference between these two start addresses.

[0075] Figure 9 shows that the start address of an internal function 910 provided from an executable module 810 to the outside is recorded in the EAT section (Export) 814 of the executable module 810 and referenced by an external module 920, and at this time, the offset of the internal function 910 is obtained using the difference between the start address of the executable module 810 and the start address of the internal function 910 confirmed in the EAT section (Export) 814.

[0076] It will be easily understood that the execution code can also be obtained based on the start addresses of such external functions 825 and internal functions 910.

[0077] In the above, an embodiment has been described in which the computer device 200, which is a client terminal on which a computer program is executed, compares the current identification value with the previous identification value to determine whether to hook. In another embodiment, the server may group the identification values to determine whether to hook a specific module or function of the client.

[0078] For example, in FIG. 3, the computer device 200 implementing the client may transmit the generated identification values to the server in step 330. In this case, the server may be configured to cluster the identification values collected from the clients according to the identifiers of the linked modules or the identifiers of the target functions, compare the clustered identification values, and determine the hook status of a specific module or a specific target function for each cluster. More specifically, the server may determine that the same identification values included in a specific cluster are normal identification values, and determine that the specific module or specific target function of the client corresponding to the remaining identification values is in a hook status. As a more specific example, assume that 1,000 clients each send one identification value to the server for module A and function B. In this case, if 997 of the identification values are the same and three of the identification values are different, the server may determine that module A and / or function B have been hooked by the clients corresponding to the three different identification values. As described above, the offset and executable code are the same regardless of where the executable module or external module is stored in memory. Therefore, by utilizing the fact that the identification values including such offsets and executable codes are different from those of other clients, it is possible to recognize that a hook has occurred in the relevant module and / or function for a client that has sent a small number of different identification values.

[0079] To this end, the server may cluster the identification values sent by the clients over a certain period of time. The server can then determine the presence of a hook in real time using the identification values sent by the clients. For example, assume that 500 identical identifiers aaa are received through clustering over an initial certain period of time. If the server subsequently receives identifier aaa from client 1, the server may determine in real time that no hook has occurred in client 1 based on the clustered set of identifiers aaa. On the other hand, if the server receives identifier bbb, which is different from identifier aaa, from client 2, the server may determine in real time that a hook has occurred in client 2 based on the clustered set of identifiers aaa. In another embodiment, the server may determine the hook status of a client at regular intervals. For example, the server may cluster the identification values sent by clients over a certain period of time, compare the clustered identification values, and determine that a hook has occurred in the corresponding module and / or function for a client that sent a small number of different identification values.

[0080] 10 is a flowchart illustrating an example of a server hook detection method according to an embodiment of the present invention. The hook detection method according to this embodiment may be performed by a server computer device 200 that receives identification values from multiple clients. In this case, the processor 220 of the computer device 200 may be configured to execute control instructions from operating system code and at least one computer program code stored in the memory 210. Here, the processor 220 may control the computer device 200 to perform steps 1010 to 1030 of the method of FIG. 10 according to the control instructions provided by the code stored in the computer device 200.

[0081] In step 1010, the computer device 200 may receive identification values from multiple clients. As described above, each identification value may be associated with an executable module stored in the memory of the multiple clients and generated based on the offset or executable code of a target function, such as an internal function provided by the executable module or an external function referenced by the executable module. The identification value may be generated to include (1) the offset of the external function, (2) the offset of the internal function, (3) the executable code of the external function, or (4) the executable code of the internal function. However, the identification value may also be generated to include two or more of (1) to (4). Alternatively, as described above, the identification value may be generated by converting the offsets or executable codes of all API functions of the module into a single hash function.

[0082] In step 1020, the computing device 200 may cluster the received identification values according to the identifiers of the corresponding modules or the identifiers of the corresponding target functions. In other words, the identification values may be categorized by module and / or by function.

[0083] In step 1030, the computer device 200 may compare the identification values with respect to any given community and determine the hook state of a module or target function corresponding to the given community. For example, the computer device 200 may determine that the same identification values among the identification values included in the given community are normal identification values, and may determine that the client's module or target function corresponding to the remaining identification values, excluding the identification values determined as normal identification values, among the identification values included in the given community, are in the hook state.

[0084] As described above, according to an embodiment of the present invention, unique values for the location information or executable code of a function that an executable module references from the outside or provides to the outside can be identified, and such unique values can be compared or a classification obtained by clustering the unique values can be used to determine an API hook.

[0085] The above-described systems or devices may be realized using hardware components or a combination of hardware and software components. For example, the devices and components described in the embodiments may be realized using one or more general-purpose or special-purpose computers, such as a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or various devices 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 OS. The processing device may also 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. However, those skilled in the art will understand that a processing device may include multiple processing elements and / or multiple types of processing elements. For example, a processing device may include multiple processors or one processor and one controller. Other processing configurations, such as parallel processors, are also possible.

[0086] Software may include computer programs, codes, instructions, or a combination of one or more of these, and may configure a processing device to operate as desired or may independently or collectively instruct the processing device. The software and / or data may be embodied in any type of machine, component, physical device, virtual device, computer storage medium, or device to be interpreted by the processing device or to provide instructions or data to the processing device. The software may be distributed and stored and executed in a distributed manner across computer systems connected by a network. The software and data may be stored on one or more computer-readable recording media.

[0087] Methods according to embodiments may be implemented in the form of program instructions executable by various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The medium may continuously store a computer-executable program or temporarily store it for execution or download. Furthermore, the medium may be a variety of recording or storage means, including a single or multiple hardware devices, and is not limited to media directly connected to a computer system but may also be distributed over a network. Examples of media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; ROM, RAM, flash memory, and the like, configured to store program instructions. Other examples of media include recording media or storage media managed by application stores, other software distribution sites, servers, and the like. Examples of program instructions include not only machine language code, such as that generated by a compiler, but also high-level language code executed by a computer using an interpreter or the like.

[0088] Although the embodiments have been described above based on limited examples and drawings, those skilled in the art will appreciate that various modifications and variations may be made from the above description. For example, the described techniques may be performed in an order different from that described, and / or the described system, structure, device, circuit, or other element may be coupled or combined in a manner different from that described, or may be substituted or replaced by other elements or equivalents, and still achieve suitable results.

[0089] Therefore, different embodiments that are equivalent to the claims are within the scope of the appended claims. [Explanation of symbols]

[0090] 810: Executable module 820: External module 825: External functions 811, 821:Code 812, 822:Data 813, 823:Export 814, 824:Import

Claims

1. 1. A method for detecting hooks in a computer device including at least one processor and a memory, comprising: identifying, by the at least one processor, an offset and an executable code of a target function, or the executable code, associated with the executable module stored in the memory at the time of execution of the executable module, as an internal function provided by the executable module or an external function referenced by the executable module; generating, by the at least one processor, an identification value using the offset and executable code of the target function or the executable code; and determining whether to hook the executable module using the generated identification value by the at least one processor; Including, The step of confirming includes: checking information about external functions referenced by the executable module; obtaining an address of an external function referenced by the external function information; and obtaining an execution code recorded at the address of the external function; A hook detection method comprising:

2. The step of confirming includes: After the step of checking the external function information referenced in the executable module, obtaining a start address of an external module referenced by the external function information; obtaining a start address of the external function referenced by the external function information; and identifying a difference between the start address of the external function and the start address of the external module as an offset of the target function; 2. The hook detection method of claim 1, further comprising:

3. The step of confirming includes: determining that a hook exists for the executable module or the target function if the start address of the foreign function is not within the range of the start address and end address of the foreign module; 3. The hook detection method of claim 2, further comprising:

4. The step of confirming includes: checking internal function information provided by the executable module; determining the starting address of the executable module; determining a start address of an internal function provided to the outside based on the internal function information; and identifying a difference between the start address of the internal function and the start address of the executable module as an offset of the target function; 2. The hook detection method of claim 1, further comprising:

5. The step of confirming includes: determining that a hook exists for the executable module or the target function if the start address of the internal function is not within the range of the start address and end address of the executable module; 5. The hook detection method of claim 4, further comprising:

6. The step of obtaining the execution code includes:

2. The hook detection method of claim 1, wherein the execution code is obtained from the start address of the external function to an address corresponding to the size of the move instruction word, or the execution code is obtained from the start address of the external function to an end address.

7. A method for detecting a hook in a computer device including at least one processor and memory, comprising: identifying, by the at least one processor, an offset and an executable code of a target function, or the executable code, associated with the executable module stored in the memory at the time of execution of the executable module, as an internal function provided by the executable module or an external function referenced by the executable module; generating, by the at least one processor, an identification value using the offset and executable code of the target function or the executable code; and determining whether to hook the executable module using the generated identification value by the at least one processor; Including, The step of confirming includes: checking internal function information provided by the executable module; obtaining an address of an internal function provided to the outside based on the internal function information; and obtaining the execution code recorded at the address of the internal function; A hook detection method comprising:

8. The step of obtaining the execution code includes: The hook detection method of claim 7, characterized in that the execution code from the start address of the internal function to an address corresponding to the size of the move instruction word is obtained, or the execution code from the start address of the internal function to an end address is obtained.

9. The step of generating the identification value comprises: The hook detection method according to any one of claims 1 to 8, characterized in that the offset and execution code of the target function, or the execution code, is generated as the identification value and linked to at least one of an identifier of a module containing the target function and an identifier of the target function.

10. A method for detecting hooks in a computer device including at least one processor and memory, comprising: identifying, by the at least one processor, an offset and an executable code of a target function, or the executable code, associated with the executable module stored in the memory at the time of execution of the executable module, as an internal function provided by the executable module or an external function referenced by the executable module; generating, by the at least one processor, an identification value using the offset and executable code of the target function or the executable code; and determining whether to hook the executable module using the generated identification value by the at least one processor; Including, The step of confirming includes: determining an offset and / or an executable code for each internal function provided by the executable module or each external function referenced by the executable module; The step of generating the identification value comprises: The hook detection method generates the offsets and execution codes confirmed for all the internal functions or all the external functions, or one hash information for the execution codes, as the identification value, and associates it with the identifier of the corresponding module.

11. The step of determining whether to hook includes: The hook detection method according to any one of claims 1 to 10, wherein the generated identification value is compared with a previous identification value to determine whether or not the executable module is to be hooked.

12. 12. The hook detection method of claim 11, wherein the previous identification value includes the offset and executable code of the target function previously confirmed for the executable module immediately after building a package file including the executable module, or the executable code, the offset and executable code of the target function previously confirmed for the executable module at a previous execution point of the executable module, or the executable code, or the offset and executable code of the target function previously confirmed for the executable module at a regular interval.

13. The step of determining whether to hook includes: transmitting the generated identification value to a server; The hook detection method according to any one of claims 1 to 10, characterized in that the server is implemented to cluster the identification values collected from the clients according to the identifiers of the linked modules or the identifiers of the target functions, compare the clustered identification values, and determine the hook status of a specific module or a specific target function for each cluster.

14. A method for detecting hooks in a computer device including at least one processor and memory, comprising: identifying, by the at least one processor, an offset and an executable code of a target function, or the executable code, associated with the executable module stored in the memory at the time of execution of the executable module, as an internal function provided by the executable module or an external function referenced by the executable module; generating, by the at least one processor, an identification value using the offset and executable code of the target function or the executable code; and determining whether to hook the executable module using the generated identification value by the at least one processor; Including, The step of determining whether to hook includes: transmitting the generated identification value to a server; The server is implemented to cluster the identification values collected from the clients according to the identifiers of linked modules or the identifiers of target functions, compare the clustered identification values, and determine the hook status of a specific module or a specific target function for each cluster; The server determines that among the identification values included in a specific group, the same identification values are normal identification values, and determines that the specific modules or specific target functions of the client corresponding to the remaining identification values are in a hook state.

15. 1. A method for detecting hooks in a computer device including at least one processor and a memory, comprising: receiving, by the at least one processor, identification values from a plurality of clients, each of the identification values being associated with an executable module stored in memory of the plurality of clients and generated based on an offset or executable code of a target function as an internal function provided by the executable module or an external function referenced by the executable module; clustering, by the at least one processor, the received identification values according to the identifiers of the corresponding modules or the identifiers of the corresponding object functions; and and determining, by said at least one processor, a hook state of a module or target function corresponding to said given group by comparing the discrimination values for said given group. A hook detection method comprising:

16. The step of determining the hook state comprises: determining the same identification values among the identification values included in the arbitrary group as normal identification values; determining that the client modules or target functions corresponding to the remaining identification values, excluding the identification values determined as normal identification values, among the identification values included in the arbitrary group are in a hook state; 16. The hook detection method of claim 15, comprising:

17. A computer program causing a computer device to carry out the method according to any one of claims 1 to 16.

18. A computer-readable recording medium having recorded thereon a computer program for causing a computer device to execute the method according to any one of claims 1 to 16.

19. At least one processor implemented to execute computer-readable instructions Including, by the at least one processor receiving identification values from a plurality of clients, each of the identification values being associated with an executable module stored in the memory of the plurality of clients and including an offset or executable code of a target function as an internal function provided by the executable module or an external function referenced by the executable module; clustering the received identification values according to the identifiers of the corresponding modules or the identifiers of the corresponding object functions; Comparing the discrimination values for any given group to determine the hook state of the module or target function corresponding to said given group. A computer device comprising:

Images