KR20100113802A - System and method for protecting against malicious traffic and from hacking - Google Patents

Abstract

PURPOSE: A system and a method for controlling a harmful traffic and blocking hacking are provided to prevent the unnecessary load resulting from the inspection of all modules within a process space by selectively performing a malicious module inspection for the module actually involved in communication. CONSTITUTION: A communication request monitoring unit(111) monitors a communication request through an operating system using an application program(120), and a thread reading unit(112) reads out an originating thread of the communication request received at the communication request monitoring unit. A module inspection unit(113) selectively inspects the module related to the communication request through the stack reverse tracking of a stack memory of a read thread. According to the inspection result, a communication request processing unit(114) permit or blocks the communication request.

Description

System and method for protecting against malicious traffic and from hacking}

The present invention relates to a network firewall operating on a computer, and more specifically, to select a module (EXE, DLL, etc.) involved in actual network communication by using a method of backtracking a stack memory of a thread that attempted a network communication request. The present invention relates to an apparatus and method for inspecting and blocking a malicious hacking tool.

With the widespread use of high speed internet, most personal computers are always connected to the internet, and various security measures to prevent direct attack by malicious hackers through the internet or hacking through malicious code and leakage of personal information The need has arisen. Malware refers to programs that perform malicious operations contrary to the interests and intentions of computer users, such as generating harmful traffic (such as DDOS attacks or spam mailings) and hacking by leaking personal information.

Currently, the most widely used security countermeasures against these threats are antivirus products. However, the vaccine can defend against known malicious code, but it cannot defend against the problem of personal information leakage by the hacking tool that has not yet been discovered by the vaccine developer.

According to JoongAng Ilbo of February 11, 2009, on December 29, 2008, a malicious hacking tool installed on a personal PC caused the unauthorized certificate to fall into the hacker's hands and resulted in the unauthorized withdrawal of 14 million won from the bank account. In addition, on January 5, 2009, an illegal hacking tool intercepted the public certificate and keyboard input.

In addition, according to the New York Times, March 29, 2009, a Chinese hacker penetrated the computer networks of governments and private organizations in 103 countries around the world, hacking documents on 1295 computers, and this was also called "ghostnet." Information leaks have been identified by a named malicious hacking tool. In this case, the damage caused by malicious hacking tools was found to be severe because the hacking was found on the computer of the Korean Embassy.

As shown in these examples, blocking of unknown hacking tools such as hacking tools produced by hackers with existing antivirus products is limited, and network firewall products must be prevented to prevent information leakage by these malicious hacking tools. Must be used together.

Early firewall products used to filter traffic based on the packet's source address, port and destination addresses, and ports. However, this method has a problem that it is difficult to prevent hacking by a hacking tool that exploits a port number allowed by an administrator, and it is difficult to apply to an instant messenger or a P2P application that uses an ephemeral port number.

Recent more advanced firewall products use a method of specifying a list of programs (EXEs) that allow network communication. In this method, a user may manually enter a list of programs to allow network communication, or add a new program to the list of allowed programs by asking the user whether to allow the program when a specific program tries to communicate. In this way, instant messenger or P2P programs using temporary port numbers can be flexibly configured. The firewall included with the Windows operating system is an example of this model.

However, in the method based on the EXE file list, the allowance is set based on the EXE file representing the process. Therefore, the DLL injection technique is used to infiltrate a malicious DLL into the normal process space, or the EXE file is implied or specified. If the DLL file to be loaded is a malicious module that has been tampered with by a virus or created for malicious purposes, there is a problem in that it cannot be distinguished and blocked.

DLL injection is a technology commonly used in hacking tools. It refers to a technology that infiltrates any DLL module into an arbitrary process space and executes a function desired by the creator of a malicious DLL module in the process with the authority of the corresponding process.

Also, in the model that allows network communication based on the list of EXE files, to check whether malicious DLL module is loaded in the process, the whole module loaded in the process needs to be examined. There is a problem that occurs.

The present invention devised to solve the above-mentioned problems of the prior art, by using a method of reading the thread that attempted the network communication and trace back the stack memory of the thread, only the modules actually involved in the communication just before the communication is made. By selectively inspecting malicious codes, hacking by DLL injection or mutated DLLs can be prevented, and unnecessary loads generated by inspecting all modules in the process space by selectively inspecting only modules that are actually involved in communication. An object of the present invention is to provide an apparatus and method for preventing harmful traffic and preventing hacking.

The present invention for achieving the above object, as a device for blocking harmful traffic control and hacking,

A communication request monitoring unit configured to monitor a communication request requested by the application program to the operating system;

A thread reader for reading the originating thread of the communication request received by the communication request monitoring unit;

A module checker through a stack traceback for selectively checking a stack memory of a thread read by the thread reader and selectively checking a module related to the communication request;

A communication request processing unit allowing or blocking a communication request according to a test result of the module inspecting unit through the stack traceback;

Characterized in that it comprises a.

In addition, the present invention for achieving the above object, as a method for blocking harmful traffic control and hacking,

A communication request monitoring step of monitoring a communication request requested by an application program to an operating system;

A thread reading step of reading the originating thread of the communication request from the communication request received in the communication request monitoring step;

A module checking step of stack tracing to check malicious modules in a method of tracing a stack memory of a thread read in the thread reading step;

A communication request processing step of allowing or blocking a communication request according to a check result of the module checking step through the stack traceback;

Characterized in that it comprises a.

According to the apparatus and method for blocking harmful traffic control and hacking invented in the present invention, by using a method of reading the thread that attempted network communication and backtracking the stack memory of the thread, only the modules actually involved in the communication are made. By inspecting malicious code selectively before losing, it can block hacking by DLL injection or modified DLL, and by inspecting all modules in the process space by selectively inspecting malicious modules only for modules involved in communication. Unnecessary unnecessary load can be prevented.

Therefore, by incorporating the present invention into the firewall software, it is possible to block even in case of a DLL injection or a malicious module infected with a virus or the like, which cannot be blocked by the conventional firewall technology, and personal information generated by a malicious hacking tool that has not yet been found. Hacking incidents such as leaks or unauthorized withdrawal through internet banking can be prevented. In addition, by selectively inspecting only the modules involved in the actual communication, the load generated when the firewall software is operated can be reduced.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram showing an apparatus for blocking harmful traffic control and hacking according to a preferred embodiment of the present invention.

Referring to FIG. 1, the apparatus 110 for blocking harmful traffic control and hacking includes a communication request monitoring unit 111 for monitoring a network communication request of an application program 120; A thread reader 112 for reading outgoing threads of a network communication request received by the communication request monitoring unit; A module checker (113) through a stack traceback that checks the modules involved in the communication request while tracing the stack memory of the thread read by the thread reader; And a communication request processing unit 114 to allow or block a network communication request according to the module test result.

The device 110 for blocking the harmful traffic control and hacking is located between one or more applications 120 running in the computer and the network interface card 130 to target outgoing traffic and incoming traffic. Block harmful traffic control and hacking.

The communication request monitoring unit 111 monitors and receives a network communication request requested by the application program 120 to the operating system. The application program 120 performs network communication by calling a communication-related API provided by the operating system. The network communication includes data transmission, data reception, opening a server port, and a connection to a counterpart host. Examples of communication-related APIs used here include connect (), listen (), recv (), send (), recvfrom (), and sendto ().

The communication request monitoring unit may be implemented by using a kernel mode driver and using API hooking.

When implementing as a kernel mode driver, it is preferable to implement as a filter driver on top of a transport layer driver provided by an operating system. The transport layer driver is a driver that implements protocols such as TCP and UDP corresponding to the transport layer of the OSI reference model in the Windows operating system. It is located at the top of the network-related driver stack. When installed as a filter driver on top of this transport layer driver, it runs in the same context as a user mode thread requesting network communication, which makes it easier to read the thread requesting the network communication. The transport layer driver exposes a standardized interface inside an operating system called a TDI (Transport Driver Interface) to an upper driver or a TDI client. Accordingly, the filter driver implementing the communication request monitoring unit 111 may monitor the connection request, the server port opening request, the data transmission request, and the data reception request according to the TDI interface provided by the transport layer driver. Details of the TDI interface are documented by Microsoft. In addition to the filter driver on the top of the transport layer driver, it is also possible to implement it as an NDIS IM (Intermediate) driver.

When the communication request monitoring unit 111 is implemented as a driver in a kernel mode, the network communication request requested by an application is transmitted to the driver dispatch routine in the form of an I / O Request Packet (IRP) by an I / O manager of the Windows kernel. do. Thus, by looking at the contents of the IRP data structure passed to the driver, it is possible to monitor the contents of the specific communication. The types of IRP structures and the meaning of member variables are described in the Windows Driver Kit (WDK) manual.

In addition, it is also possible to implement the communication request monitoring unit 111 using API hooking. API hooking is a way to replace the API provided by the operating system with an arbitrary function created by the developer so that when an application calls the API provided by the operating system, the relevant information can be monitored and processed before the operating system's API is actually called. Say API hooking maps a DLL containing a function with the same functional type as the API provided by the operating system into the application's process, and then calls a function included in a module such as KERNEL32.DLL, USER32.DLL, or GDI32.DLL. This can be done by replacing the function address in the IAT (Import Address Table) used. It is also possible to implement API hooking by replacing the function address in the system service dispatch table (SSDT) in kernel mode.

When the communication request monitoring unit 111 is implemented using API hooking, it is possible to receive parameters used when calling a function of a Windows API or a native system service. You can examine and monitor the details of the function called by your application.

The thread reading unit 112 reads the originating thread of the communication request received by the communication request monitoring unit 111. The purpose of reading the originating thread of the communication request is to selectively inspect only the modules related to the communication request in the module inspection unit 113 through the stack traceback. The read result is preferably represented by a thread ID.

When the communication request monitoring unit 111 is implemented as a kernel mode driver, a method of reading the originating thread of the corresponding IRP may be performed by directly examining the Tail.Overlay.Thread (ETHREAD structure type) field in the IRP structure or by NT kernel. From 5.1 onwards, it can be obtained by giving Tail.Overlay.Thread as a parameter to PsGetThreadID () function. Alternatively, when the kernel mode driver that implements the communication request monitoring unit 111 is implemented as a filter driver that operates on the upper layer of the transport layer driver, a call of the dispatch routine of the driver requests a user mode thread for network communication. Since it is executed in the same context, it is also possible to call PsGetCurrentThreadId () to read.

When the communication request monitoring unit 111 is implemented using API hooking, the API hooking function is executed in the same thread context as the thread calling the API, so that the network communication request is made by calling the GetCurrentThreadId () API. Can be read.

The module inspecting unit 113 through the stack traceback selectively checks the module involved in the corresponding communication request by using the method of backtracking the stack memory of the thread read by the thread reader 112. This detailed process will be described later with reference to FIG. 2.

The communication request processing unit 114 allows or blocks a communication request according to the inspection result of the module inspecting unit 113 through the stack traceback.

When the communication request monitoring unit 111 is implemented as a kernel mode driver, in order to block communication, the received communication request IRP may be completed by using IoCompleteRequest () without sending down the received communication request IRP to the lower driver. At this time, the completion code is set to Failed and returned to the application as communication failed. On the other hand, in order to allow communication, the IRP is passed to the lower driver by calling IoCallDriver ().

When the communication request monitoring unit 111 is implemented using API hooking, in order to block communication, a failure may be immediately returned without calling the original function within the hooked API function. On the other hand, to allow communication, pass the parameters received by the hooked API function to the original API function.

If communication is allowed, the corresponding communication request may transmit and receive a packet with the Internet 140 via the network interface card 130.

2 is a block diagram illustrating the module inspecting unit 113 through the stack traceback in more detail.

The thread context extractor 201 extracts the context of the thread from the thread read by the thread reader 112. The reason for extracting the thread context is that the instruction pointer register value and the base pointer register value existing in the thread context are needed by the stack traceback unit 202 below.

Modern personal computer and server computer operating systems mostly support multi-threaded environments, where a single process can contain more than one thread. In addition, in a time-sharing operating system environment, multiple threads share the CPU's time slice evenly, allowing multiple threads to run concurrently. Therefore, in order to replace a large number of threads in a limited number of CPUs, it is necessary to save the CPU state for each thread. In the case of the Windows operating system, the data structure called CONTEXT is managed in the kernel thread object. This CONTEXT data structure contains the values of the various registers of the CPU.

To obtain the context of the thread using the ID of the thread extracted by the thread reader 112, first obtain a thread handle by passing the thread ID as an argument to the OpenThread () API, and then initialize the thread handle and the GetThreadContext () API. Passes the address of the constructed CONTEXT structure. In this case, if the thread is not blocked, it is preferable to suspend the thread using the SuspendThread () API before calling the GetThreadContext () API to prevent the CPU from changing while the GetThreadContext () API is running.

The stack traceback unit 202 traces back the stack memory of the thread read by the thread reader 112 and extracts one or more instruction pointers stored in the stack frame. This detailed process will be described later by way of example.

The module extractor 203 extracts a module corresponding to the address of the instruction pointer extracted by the stack tracer 202. First, the EnumProcessModules () API is used to traverse all the modules loaded in the process including the thread read by the thread reader 112, and each module uses the GetModuleInformation () API and the base address of the module. After obtaining the size of the module, the handle of the module corresponding to the address of the instruction pointer is obtained by comparing whether the address of the instruction pointer extracted by the stack traceback unit 202 is included in the address range of the module. Then, the GetModuleFileNameEx () API is called with the handle of the module as a parameter to obtain the path on the disk of this module.

The malicious module inspection unit 205 performs a malicious module inspection on the module extracted by the module extraction unit 203. The malicious module inspection unit 205 preferably performs a malicious module inspection using the module DB 206. The module DB 206 is a database that stores information about modules (EXE, DLL, etc.), and stores unique code values of each module and whether the module is malicious. Preferably, a unique code value for distinguishing each module uses a hash value calculated by applying a one-way hash function to a part or all of the modules, or uses a method of extracting and storing a unique signature of a module. The module data of module DB 206 may be added by the user or updated in real time using a central server. Various embodiments of examining malicious modules are well known to those skilled in the art, and thus detailed descriptions thereof will be omitted.

Alternatively, the module extracting unit 203 obtains the address range in which the module is located directly in the memory using the module's base address and size without obtaining the module path on the disk, and then directly searches the module in the memory for the malicious module checking unit 205. You can also check using. The advantage of this approach is that malicious modules can be detected even if the module has been tampered with by a virus after being loaded into memory.

On the other hand, since it may be inefficient in some cases to perform a malicious module inspection on all the modules extracted by the module extraction unit 203, using the additional module filtering unit 204 malicious to the extracted module You can decide whether to inspect the module. For example, the same module may exist multiple times in the list of modules extracted through the stack traceback unit 202. In this case, the module filtering unit 204 is not necessary because the same module does not need to be duplicated. It is desirable to omit unnecessary inspection. Alternatively, even when the module extracted by the module extracting unit 203 is a module which can be sure that the module is not malicious in various contexts, the unnecessary load can be reduced by omitting the malicious module inspection.

Hereinafter, the details of the stack traceback unit 202 will be described with reference to FIGS. 5 through 8.

5 is a block diagram illustrating a process internal structure 500 of an application 120. In the illustrated process block diagram, there are two threads 507 and 508. Thread 1 507 is a thread started from the EXE execution module 501 representing the process, and requests network communication in kernel mode via the normal module 502, WS2_32.DLL 504, and NTDLL.DLL 505 in that order. Doing Thread 2 (508) is a thread originating from a malicious module 503 that has penetrated into a normal process, and requests network communication in kernel mode via WS2_32.DLL 504 and NTDLL.DLL 505. WS2_32.DLL is a DLL module that implements WinSock (Windows Socket). NTDLL.DLL is a DLL module that provides an entry point to native system services provided by the kernel. In this figure, other DLL modules required for program execution, such as KERNEL32.DLL, USER32.DLL, and GDI32.DLL, are not shown separately, but this is simplified for illustrative purposes.

FIG. 6 is a block diagram illustrating a virtual memory address space of the process illustrated in FIG. 5.

When a process is created, the operating system allocates an independent address space for each process, which is divided into a kernel address space and a user address space. All modules (EXEs, DLLs, etc.) involved in the execution of the process are mapped in this address space. In Fig. 6, NTDLL.DLL 601, WS2_32.DLL 602, malicious module 605, normal module 606, and execution module 607 are properly mapped to the address space.

In addition, each time a thread is created, the operating system allocates a separate stack memory space for each thread. As illustrated in FIG. 5, when there are two threads 507 and 508 in a process, two stack memory regions 603 and 604 are created in the process address space, respectively. The stack memory 603 of 0x00800000 to 0x00900000 is allocated to the thread 1 507, and the stack memory 604 of 0x00700000 to 0x00800000 is allocated to the thread 2 508.

7 is a block diagram illustrating in detail the stack memory 604 allocated to thread 2 508.

Stack memory creates a new stack frame each time a function (subroutine) is called through a CALL instruction. Each stack frame is pushed on the stack by the parameters passed to the called function, the instruction pointer register value at the time the CALL instruction is executed, the memory address where the base pointer register value of the previous stack frame was stored, and the local variables used by the function. push). Although FIG. 7 shows that the parameters and local variables in each stack frame each occupy 4 bytes, this is for illustrative purposes and in practice this size varies depending on the function being called.

When the operating system allocates independent stack memory for newly created threads, it sets the bottom of the stack to NULL, which prevents the stack from underflowing. The 0x007FFFFC 711 of the stack bottom 710 of FIG. 7 is the location where the value of the instruction pointer register when the original function is called is stored, but since this is the bottom of the stack, the operating system sets the value to NULL. Also, the 0x007FFFF8 (712) location is where the memory address where the value of the base pointer register of the previous stack frame is stored, but since the previous stack frame does not exist at the bottom of the stack, the operating system also sets the value to NULL here. Do it.

When the stack of FIG. 7 was first created, only the stack bottom 710 was present. If a function call to WS2_32.DLL 504 occurred while the malicious module 503 was executing, stack frame 1 720 was generated. do. 0x007FFFF0 address 722 of stack frame 1720 stores the value of the instruction pointer register immediately before the function call to WS2_32.DLL, which is 0x00600100, which is within the address range 605 of the malicious module 503. It can be seen that it is included. In addition, the 0x007FFFEC address 723 stores a memory address where the value of the base pointer register is stored in the previous stack frame, and this value indicates 0x007FFFF8 indicating the bottom of the stack.

On the other hand, if thread 2 508 executes the code in WS2_32.DLL 504, and a function call to NTDLL.DLL 505 occurs again, stack frame 2 730 is generated. 0x007FFFE0 address 732 of stack frame 2 (730) stores the value of the instruction pointer register just before the function call to NTDLL.DLL occurs. This value is 0x71C00100, which is the address range (602) of WS2_32.DLL (504). You can see that it is within). In addition, the 0x007FFFDC address 733 stores the memory address value in which the value of the base pointer register is stored in the previous stack frame, which is 0x007FFFEC, and the value of the base pointer register of the stack frame 1 720 that is the previous stack frame. It can be seen that it points to the stored memory address 723.

8 is a block diagram illustrating a kernel thread object when the thread 2 508 makes a communication request to the kernel.

Referring to FIG. 8, the EIP 811 in the CONTEXT data structure 810 stores the address of the next instruction to be executed immediately as a value of the current instruction pointer register, and the EBP 812 is a stack located on a stack top. It stores the memory address value that stores the base pointer register value of the previous stack frame in the frame.

In the example of FIG. 8, the EIP value is 0x7D600100, and this address falls within the address range 601 of NTDLL.DLL 505. In other words, the EIP value obtained from the thread's context shows that this thread is currently executing code in the NTDLL.DLL module. In addition, in the example of FIG. 8, the EBP value is 0x007FFFDC, which indicates that the memory address 733 stores the previous EBP value in the stack frame 2 730 located in the current stack top.

Based on the above description, the process of backtracking the module involved in the communication request while the stack traceback unit 202 traces the stack to the thread read by the thread reader 112 will be described by way of example. . The following example is based on a 32-bit Intel compatible CPU, where the instruction pointer register is EIP and the base pointer register is EBP.

First, the CONTEXT data structure 810 of the kernel thread object 800 illustrated in FIG. 8 is extracted using the thread context extractor 201.

Next, using the EIP 811 value in the thread context, the module currently running is extracted using the module extracting unit 203. In the example of FIG. 8, since the value of the EIP is 0x7D600100, it can be seen that the corresponding module corresponding to this address is NTDLL.DLL 601.

Next, the stack frame 2 730 located in the stack top is obtained by using the EBP 812 value in the CONTEXT data structure 810. Since the value of the EBP 812 in the CONTEXT data structure 810 is 0x007FFFDC, it can be seen that this address is the memory address 733 in which the EBP value of the previous stack frame is stored in the stack frame 2 730. By calculating the relative position from the EBP position in stack frame 2 730, the EIP value in stack frame 2 730 can be obtained. In stack frame 2 730, the EIP value is at the location of the EBP address + 4 bytes, and the address is 0x007FFFE0 732. Using this EIP value, it can be seen that the address that was being executed when the stack frame 2 730 was generated is 0x71C00100, and the module corresponding to this address is WS2_32.DLL 602 using the module extracting unit 203. Able to know.

Next, since the EBP value 733 obtained in the stack frame 2 730 is not NULL, it can be known that the previous stack frame exists. The previous stack frame can be obtained by using the EBP value as an address. Since the value of EBP obtained in stack frame 2 730 is 0x007FFFEC, it can be seen that this address is a memory address 723 in which stack EBP value of the previous stack frame is stored in stack frame 720. By calculating the relative position from the EBP position in stack frame 1 720, the EIP value in stack frame 1 720 can be obtained. The value of EIP 722 in stack frame 1 720 is 0x00600100. Using this EIP value, it can be seen that the address that was being executed when the stack frame 1 720 was generated is 0x00600100, and the module corresponding to this address is the malicious module 605 using the module extractor 203. Able to know.

Next, since the EBP value obtained in the stack frame 1 720 is not NULL, the previous stack frame is obtained. The EBP 723 value of stack frame 1 720 is 0x007FFFF8, and this address indicates the address where the EBP value is stored in the previous stack frame. However, if you extract the value of address 0x007FFFF8, you can see that the value is NULL, and it can be determined that there is no stack frame to process any more.

Through the above process, the stack traceback unit 202 is a module used by thread 2 508 to make a communication request in kernel mode such as NTDLL.DLL (505), WS2_32.DLL (504), and malicious module ( 503) can be traced back.

When the stack traceback unit 202 accesses stack memory in a specific process, it is preferable to obtain a process handle using the OpenProcess () API and then read the memory value using the ReadProcessMemory () API.

Hereinafter, a method of blocking harmful traffic control and hacking according to a preferred embodiment of the present invention will be described.

3 is a flowchart illustrating a method of blocking harmful traffic control and hacking according to a preferred embodiment of the present invention.

Referring to FIG. 3, the application program monitors and receives a communication request requested by the operating system using the communication request monitoring unit 111 (S301).

The originating thread of the communication request received in the communication request monitoring step is read using the thread reader 112 (S302).

Only the modules involved in the communication are selectively checked for malicious modules by using the module inspecting unit 113 through the stack traceback of the stack memory of the thread read in the thread reading step (S303).

If a malicious module is included in the module involved in the communication request as a result of the malicious module check (S304), the communication request is blocked (S306), and if the malicious module is not included (S304), the communication request is allowed (S305).

4 is a flowchart for explaining a module inspection step S303 through the stack traceback.

Referring to FIG. 4, the context of the thread read in the thread reading step S302 is extracted using the thread context extracting unit 201, and the base pointer register value in the thread context is converted into a BP variable, and the instruction pointer register value is set. Store in an IP variable (S401).

Next, the module corresponding to the IP variable is extracted using the module extracting unit 203 based on the address stored in the IP variable (S402).

It is determined whether the malicious module needs to be examined for the extracted module (S403), and if necessary, the malicious module is examined (S404).

If it is determined that the malicious module is a malicious module (S405), a malicious module is found (S406). If it is determined that the malicious module is not a malicious module (S405), the previous stack frame is extracted and the base pointer register value in the stack frame is converted into a BP variable. In operation S407, the instruction pointer register value is stored in the IP variable.

If the stack frame extraction step (S407) extracts the previous stack frame and determines that there are no more stack frames to be investigated (S408), it returns that no malicious module is found (S409) and determines that there are stack frames to be further investigated. In step S408, the process returns to the module extraction step S402 of the IP address and repeats the process.

The step S403 of determining whether to perform a malicious module inspection on the module extracted in the module extraction step S402 of the IP address may be omitted. In this case, a malicious module is examined for all modules extracted in the module extraction step S402 of the IP address.

As described above, an embodiment of the present invention has been described under a 32-bit Windows operating system environment running on a 32-bit x86 compatible processor. However, the present invention is not limited to such a specific platform, a specific operating system environment, the use of a specific API, the use of a specific variable name, etc., and the spirit of the present invention by those skilled in the art to which the present invention pertains. It is a matter of course that various modifications and variations can be made within the equivalent scope of the claims set out below.

1 is a block diagram of an apparatus for blocking harmful traffic control and hacking according to a preferred embodiment of the present invention,

FIG. 2 is a block diagram of a module inspecting unit through the stack traceback of FIG. 1.

3 is a flowchart of a method for blocking harmful traffic control and hacking according to a preferred embodiment of the present invention;

4 is a flowchart illustrating a module inspection step through the stack traceback of FIG. 3;

5 is a block diagram illustrating an intermodule call process of an application program for explaining a stack traceback process.

6 is a block diagram illustrating the layout of an address space allocated to a running application.

7 is a block diagram specifically illustrating a stack space of a specific thread executing in a process.

8 is a block diagram illustrating a kernel thread object used to manage a particular thread.

<Description of Major Reference Marks in Drawings>

110: Device to block harmful traffic and hacking

S403: Module Filtering Step

S408: final stack frame determination step

500: process of the application

800: kernel thread object

810: CONTEXT data structure in kernel thread objects

Claims (12)

A device for preventing harmful traffic control and hacking in a computer system, A communication request monitoring unit configured to monitor a communication request requested by the application program to the operating system; A thread reader for reading the originating thread of the communication request received by the communication request monitoring unit; A module checker through a stack traceback for selectively checking a stack memory of a thread read by the thread reader and selectively checking a module related to the communication request; A communication request processing unit allowing or blocking a communication request according to a test result of the module inspecting unit through the stack traceback; Apparatus for blocking harmful traffic control and hacking comprising a. The method of claim 1, Module inspection unit through the stack traceback, A thread context extracting unit for extracting a context of a thread read by the thread reading unit; A stack traceback unit which traces back the stack memory of the thread read by the thread reader using a value of the base pointer register extracted by the thread context extractor; A module extracting unit extracting a module corresponding to an address of an instruction pointer extracted from the thread context extracting unit and the stack traceback unit; A malicious module inspection unit which performs a malicious module inspection on the module extracted by the module extracting unit; Apparatus for blocking harmful traffic control and hacking comprising a. 3. The method of claim 2, If it is determined that the malicious module inspection is to be performed on the module extracted by the module extracting unit, and it is determined that the malicious module inspection is necessary, it is necessary to inspect the malicious module using the malicious module inspection unit, and perform the malicious module inspection. A module filtering unit to skip the malicious module check if it is determined that there is no; Apparatus for blocking harmful traffic control and hack further comprising a. The method according to any one of claims 1 to 3, And the communication request monitoring unit blocks harmful traffic control and hacking, wherein the communication request monitoring unit is made of a kernel mode driver. The method of claim 4, wherein Apparatus for blocking harmful traffic control and hacking, characterized in that the communication request monitored by the communication request monitoring unit has the form of an I / O Request Packet (IRP). The method according to any one of claims 1 to 3, The communication request monitoring unit blocks harmful traffic control and hacking, characterized in that using the API hooking. A method of preventing harmful traffic control and hacking in a computer system, A communication request monitoring step of monitoring a communication request requested by an application program to an operating system; A thread reading step of reading the originating thread of the communication request from the communication request received in the communication request monitoring step; A module checking step of stack tracing to check a malicious module by tracing the stack memory of the thread read in the thread reading step; A communication request processing step of allowing or blocking a communication request according to a check result of the module checking step through the stack traceback; Method for blocking harmful traffic control and hacks comprising a. The method of claim 7, wherein The module inspection step through stack traceback A thread context extraction step of extracting a context of a thread read in the thread reading step and assigning a base pointer in a thread context to a BP variable and an instruction pointer to an IP variable; Extracting a module of an IP address for extracting a module loaded at an address indicated by the value of the IP variable; A malicious module inspection step of performing a malicious module inspection on the extracted module and determining the module as a malicious module if it is a malicious module; A stack frame extracting step of extracting a stack frame from the stack memory of the thread, and storing a base pointer in a stack frame in a BP variable and an instruction pointer in an IP variable in the malicious module checking step; As a result of the execution of the stack frame extraction step, if there is no stack frame to be investigated further, it is determined that no malicious module is found. If there is a stack frame to be investigated further, the process returns to the module extraction step of the IP address and continues processing Stack frame determination step; Method for blocking harmful traffic control and hacks comprising a. The method of claim 8, It is determined whether to perform a malicious module test on the module extracted in the module extraction step of the IP address, and if it is determined that the malicious module needs to be inspected, the malicious module checker performs a malicious module check, and a malicious module check is performed. A module filtering step of omitting a malicious module check if it is determined that it is not necessary to do so; Method for blocking harmful traffic control and hack further comprising a. The method according to any one of claims 7 to 9, Receiving a communication request in the communication request monitoring step is performed by a kernel mode driver, the harmful traffic control and hacking method. The method of claim 10, The communication request received from the kernel mode driver is a method for blocking harmful traffic and hacking, characterized in that in the form of IRP (I / O Request Packet). The method according to any one of claims 7 to 9, Receiving a communication request at the communication request monitoring step uses API hooking.

Images