KR101014814B1 - How to Monitor Computer Systems With Kernel Watcher and How to Monitor Kernels - Google Patents

Abstract

A computer system with a kernel watchdog and a kernel watchdog method are provided. In the kernel monitoring method according to the present invention, a first code region including an instruction for calling a monitored system service function is replaced with a first replacement code among codes of a module relaying a call of a system service function in kernel mode. Wherein the first replacement code comprises an instruction to jump to a first hooking module and consists of bytes, such as bytes occupied by the first code region, the monitoring by a process running in user mode. When the first replacement code and the first hooking module are executed sequentially by calling a system service function that is a target of the first hooking module, calling the main monitoring module by using the information of the system service function as a parameter; The main monitoring module monitors information about a system service function called by the process. And the state monitoring module, said first hooking module after the return to the said first hooking module includes the step of executing at least one command to invoke a system service function is called by the process.

System Service Handler, Operating System, Hacking, Monitoring, KiSystemService

Description

Kernel monitoring module installed computer system and kernel monitoring method

The present invention relates to a computer system and kernel monitoring method provided with a kernel monitor. More specifically, the hacking module monitors the hacking module using a hooking method that jumps a code area that calls a system service function among the system service function handling module codes included in the operating system (OS) kernel to the monitoring module. It relates to a computer system with a kernel watchdog installed and a kernel watchdog method which detours a module to prevent evasion.

Today, general-purpose operating systems running multiple processes are widely used in PCs and servers. Operating systems often allow many processes or threads to collaborate without affecting each other's execution. In the past, the operating system had some confidence in the processes that were run because the user installed only the verified program himself. However, due to the development of the Internet, it has become common to download and execute various programs that are difficult to distinguish whether the user is a safe or malicious malicious code program. Malicious programs use services provided by the operating system to monitor and observe the operation information of other programs, and to leak the information to the outside via the Internet. The purpose of writing system service functions is to allow the operating system to manage hardware resources efficiently and to allow applications to use hardware resources easily and safely. However, malicious programs have the problem of exploiting these system service functions.

In situations where all processes running on top of the operating system are not completely reliable, it is essential to monitor the system service functions provided by the operating system. For example, if an arbitrary process A uses a memory read function in an illegal manner, it can read the memory area of another process. If Process A attempts to hack a memory using these functions, it could cause an Internet banking financial crash. Therefore, in the case of illegally calling a system service function, a function is required to prevent the call. To do this, the first step is to monitor which process wants to call a system service function.

Among the conventional system service function monitoring techniques, there is a method of replacing the address of a system service function stored in a table of system service functions with the address of a monitoring function, and calling the system service function from the monitoring function. However, this method has a problem that the system service function handling module is bypassed by modifying the system service function handling module and immediately calling the system service function without passing through the monitoring function.

As another method of the conventional system service function monitoring technique, there is a method of monitoring by inserting a hooking code to jump to the monitoring function in the prolog code of the system service function to be monitored. However, this method also has a problem of being bypassed by modifying the system service function handling module to call the copied system service function or to jump to the instruction following the hooking code.

In many cases, a malicious process attempts to detect whether a system service function monitoring method is installed in the operating system and bypass the installed monitoring method as described above. Surveillance techniques should therefore be able to detect or prevent these bypass techniques. However, existing monitoring techniques are vulnerable to the bypass of the monitoring module that malicious processes attempt.

The technical problem to be solved by the present invention is a kernel monitor that provides a system service function monitoring function that can prevent the system service function monitoring bypass of the hacking code by monitoring the attempt to call the system service function before the system service function is called. It is to provide an installed computer system.

Another technical problem to be solved by the present invention is to replace the system service function handling module with the original system service function handling module if the modification is applied to the system service function handling module before installing the kernel watcher to install the kernel watcher hacking module It provides a computer system and kernel monitoring method installed with a kernel watcher that provides a system service function monitoring function to prevent the monitoring bypass attempt.

Another technical problem to be solved by the present invention is to provide a computer system with a kernel monitor that can be optimized to monitor function calls for only system service functions to be monitored.

The technical problems of the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description.

Kernel monitoring method according to an aspect of the present invention for achieving the technical problem is a first including a command to call the monitored system service function of the code of the module relaying the call of the system service function in the kernel (kernel) mode Replacing a code region with a first replacement code, wherein the first replacement code includes an instruction to jump to a first hooking module and comprises a byte equal to a byte occupied by the first code region; When the first replacement code and the first hooking module are executed sequentially by calling a system service function to be monitored by a process running in the user mode, the first hooking module may parameter information of the system service function. Calling the main monitoring module, when the process calls the main monitoring module. Monitoring information about a system service function and after the main monitoring module returns to the first hooking module, the first hooking module executes at least one instruction for calling a system service function called by the process. It includes a step.

A computer system provided with a kernel monitoring apparatus according to another aspect of the present invention for achieving the above technical problem includes a first replacement code replacing the first code region including instructions for calling a monitored system service function, The first replacement code includes a command to jump to a first hooking module, the system service function handler module comprising a byte equal to a byte occupied by the first code area, and the system service function to be monitored by a process running in user mode. Is executed by jumping from the first replacement code, calling the main monitoring module with the information of the system service function as a parameter, and calling the system service function called by the process after the main monitoring module is returned. The first to execute at least one instruction for And a main monitoring module for monitoring the information of the system service function provided through the hooking module and the parameters.

According to the present invention as described above, even if the malicious process bypasses the monitoring module to call the system service function, there is an effect that can record all the system service function call-related data of the process.

In addition, the system service function call-related data of the process has an effect that can be used as the basic data of the antivirus program that can prevent the malicious process to call the system service function in an unauthorized manner.

Advantages and features of the present invention, and methods for achieving them will be apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but can be implemented in various forms. The embodiments of the present invention make the posting of the present invention complete and the general knowledge in the technical field to which the present invention belongs. It is provided to fully convey the scope of the invention to those skilled in the art, and the present invention is defined only by the scope of the claims. Like reference numerals refer to like elements throughout.

Hereinafter, the present invention will be described with reference to a block diagram or a flowchart illustrating a computer system in which a kernel monitor is installed according to embodiments of the present invention. At this time, it will be understood that each block of the flowchart illustrations and combinations of flowchart illustrations may be performed by computer program instructions. Since these computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, those instructions executed through the processor of the computer or other programmable data processing equipment may be described in flow chart block (s). It creates a means to perform the functions. These computer program instructions may be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular manner, and thus the computer usable or computer readable memory. It is also possible for the instructions stored in to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block (s). Computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operating steps are performed on the computer or other programmable data processing equipment to create a computer-implemented process to generate a computer or other programmable data. Instructions for performing the processing equipment may also provide steps for performing the functions described in the flowchart block (s).

In addition, each block may represent a portion of a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of order. For example, the two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the corresponding function.

In this case, the term 'module' refers to software or a hardware component such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and a module plays a role. However, modules are not meant to be limited to software or hardware. The module may be configured to be in an addressable storage medium and may be configured to play one or more processors. Thus, as an example, a module may include components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, procedures, subroutines, and the like. , Segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within the components and modules may be combined into a smaller number of components and modules or further separated into additional components and modules.

In addition, the components and modules may be implemented to reproduce one or more central processing units (CPUs) in a device or secure multimedia card.

First, the location where the kernel monitor according to an embodiment of the present invention is installed will be described with reference to FIGS. 1 and 2.

1 is a conceptual diagram showing the basic configuration of a computer system.

The computer system includes a CPU 100 that interprets and executes a set of instructions loaded into the main memory 106, an auxiliary memory 102 for storing data even when the computer system is turned off, and a signal from a user of the computer system. It may include an input and output device 104 for receiving the input and output the operation result.

As shown in FIG. 1, the main memory 106 of the computer system is an area in which an instruction code for executing a process is loaded and executed from an original file, and is an area for achieving main functions of a process, such as a function call or branching. (160), the data area 162 which is a region in which data necessary for executing the command code of the code region 160 is stored, and the data region 162, which is an area where data already estimated and allocated from the source code, is stored, and a variable which refers to a heap region and a stack region. It includes a data area 164.

The kernel monitor according to the present embodiment may be installed in the auxiliary memory 102 and the main memory 106 among the components of the computer system, and may be executed in the CPU 100. In more detail, data of a module related to kernel monitoring is stored in the auxiliary storage device 102 so that no loss occurs even when the power is turned off. It is loaded in the code area 160 to perform a kernel monitoring function.

To describe in more detail the installation location of the kernel monitor according to the present embodiment, the code region 160 after the operating system is loaded will be described with reference to FIG. 2. 2 is a conceptual diagram illustrating a configuration of a code region after an operating system is loaded.

In general, an operating system provides system service functions 208 to securely and effectively perform application access to hardware. The type and number of system service functions provided vary by operating system. The mode in which the application runs is called user mode, and the mode in which the kernel of the operating system runs is called kernel mode. The system service function 208 is a function executed in kernel mode. In order for the process 200 running in user mode to call the required system service function 208, a switch to kernel mode must be made. Switching methods include providing system call instructions, for example using the Intel architecture SYSENTER instruction, and using specific software interrupts in system calls.

Regardless of what you use to switch to kernel mode, the kernel must know the type and arguments of the system service functions you requested, and the module responsible for this task is the system service function handler module 204. The operating system maintains a stored system service function table 206 of how many system service functions it provides in memory. The system service function table 206 includes an index of the system service function and an address in the main memory 160 of the system service function corresponding thereto. The process 200 executed in the user mode may use a function provided by the user mode library 202, and the function existing in the user mode library 202 may be a kernel mode using the system call command or interrupt. After switching to the user mode, the system service function that determines and calls the requested system service function, that is, the system service function handler module 204 is executed. Depending on the operating system, the system service function table 206 may be several instead of one. In addition, the system service table may be formed in a hierarchical structure. In any case, however, there is one system service function handler module 204.

The system service function handler module 204 may be a KiSystemService () function of Microsoft Windows, for example, and the system service function table 206 may be a System Service Descriptor Table (SSDT), for example, of Microsoft Windows.

The kernel monitor according to the present embodiment is executed in the CPU 100 by modifying some code areas of the system service function handler module 204 and loading modules required for kernel monitoring into the code area 160 of the main memory 106. do. It is preferable to store the module and the system service function handler module 204 necessary for the kernel monitoring in the auxiliary memory 102 in case the kernel monitor according to the present embodiment is powered off.

Hereinafter, the structure and operation of a computer system provided with a kernel monitor according to another embodiment of the present invention will be described with reference to FIGS. 3, 4, and 5.

3 is a structural diagram of a computer system provided with a kernel monitor according to the present embodiment.

As shown in FIG. 3, the computer system in which the kernel monitor is installed according to the present embodiment includes a main monitoring module 210, at least one sub monitoring module 212, a first hooking module 214, and a second hooking module 216. ), The system service function handler module 218, and the source maintenance module 220. The system service function table 206 and the system service function 208 have already been described with reference to FIG. 2 and the detailed description thereof will be omitted since the module is provided by the operating system.

The original maintenance module 220 is a module that operates when installing a kernel monitor in a computer system according to an embodiment of the present invention. The original maintenance module 220 stores the original code of the system service function handler module 218. The code source may vary depending on the type and version of the operating system. The original maintenance module 220 determines whether the original of the code matches the code of the system service function handler module 218 loaded in the main memory 106 or stored in the auxiliary memory 102 before installing the kernel monitor. If the result of the determination does not match, the code of the system service function handler module 218 is replaced with the original code. This behavior of the source maintenance module 220 is a hack that copies the system service function itself and inserts hooking code into the system service function handling module 204 to call the copied system service function directly without referring to the system service function table. To prevent the technique.

The system service function handler module 218 replaces a first code region including an instruction for calling a monitored system service function based on a system service function handler module 204 provided by an operating system with a first replacement code. The second code region containing the instruction to jump to the first code region is replaced with the second replacement code. In order to facilitate understanding of the present invention, the first code region, the second code region, the first substitute code and the second substitute code will be first described with reference to FIGS. 4 and 5.

4 is a diagram illustrating a system service function handler module 204 before installing a kernel monitor according to an embodiment of the present invention. In the understanding of the contents shown in Figure 4, the described machine language and assembly code is described for ease of understanding, it is only a code as an example corresponding to the contents of the present invention, the contents of the present invention is the machine language and It should be understood that this is only for assembly code and should not be interpreted.

In order to install the kernel monitor according to an embodiment of the present invention, the code to be replaced with the first code area and the second replacement code, which are areas of the code to be replaced with the first replacement code, among the codes of the system service function handler module 204. A second code area, which is an area of, must be specified respectively. Hereinafter, the criteria for designating the first code region and the second code region among the codes of the system service function handler module 204 will be described.

The code of the system service function handler module 204 includes code for calling a system service function called by a process running in the user mode. In more detail, the code of the contents which are called by referring to the address of the system service function registered in the system service function table 206 using the index number of the system service function 208 is contained. The first code area includes a command for calling a system service function to be monitored by referring to an address of a system service function registered in the system service function table 206 as described above.

As shown in Fig. 4, the first code area consists of three machine instructions. The first line of each machine instruction represents a machine language, and the second line represents an assembly language for the machine language. For example, “FFD3 call ebx” means the machine instruction FFD3 means “call ebx” in assembly language, which means to make a function call with the address value stored in the EBX register. The machine instructions in each column of the first code area shown in FIG. 4 occupy 6 bytes, 2 bytes, and 2 bytes in size.

Meanwhile, of the three machine instructions included in the first code area, only the third instruction 'call ebx' is a command for calling a system service function. Nevertheless, the reason why two instructions preceding 'call ebx' are additionally designated as the first code region will be described later with reference to FIG. 5.

The first code region may be in another location within the code of the system service function handler module 204 in accordance with the system service function 208. Therefore, as many first code areas as the number of system service functions to be monitored can be specified. For example, if you want to monitor system service functions 1, 3, and 5, three different locations containing instructions for calling the addresses of system service functions 1, 3, and 5 stored in the system service function table 206 The first code region may be designated.

Meanwhile, the second code area is designated to solve a problem that may occur when the first code area is replaced with the first replacement code, respectively. The problem is that, for example, when an instruction to jump to the first code region among the codes included in the system service function handler module 204 is executed, the jump position is replaced with the first replacement code. ) Command can occur. A code of a predetermined area including an instruction to jump to the first code area may be designated as a second code area.

In order to solve the problem, the second code area must also be replaced with a second replacement code. The second code area exists in correspondence with the first code area. Depending on the type of operating system, one or more second code areas may exist for one first code area. It may not exist.

As shown in FIG. 4, the second command of the second code area may jump to the second command of the first code area, that is, “rep movs”. Therefore, although only the second instruction among the instructions of the second code region illustrated in FIG. 4 is the instruction jumping to the first code region, one preceding instruction is also designated as the second code region. The reason is the same as in the first code region, which will also be described later with reference to FIG. 5.

In the above, the criterion which designates the 1st code area and the 2nd code area among the codes of the system service function handler module 204 was demonstrated. As mentioned above, the first code area and the second code area of the system service function handler module 204 are respectively installed with the first replacement code and the second replacement code as the kernel monitor is installed according to an embodiment of the present invention. Is replaced by. Also, the first replacement code and the second replacement code include instructions for jumping to the first hooking module and the second hooking module, respectively. Hereinafter, the first replacement code and the second replacement code will be described with reference to FIG. 5.

5 is a diagram illustrating a system service function handler module 218 with a kernel monitor installed according to an embodiment of the present invention.

First, a first replacement code corresponding to the first code area will be described.

The first replacement code consists of three NOP instructions (0x90), which are instructions that consume only CPU cycles and do nothing, and a code (0xEAxxxxxxxx0800) that jumps to the first hooking module 214, as shown in FIG. The code that jumps to the first hooking module 214 also uses a FAR jump that can jump to other code segments to use the jump command reliably within the system. As a result, the jump code occupies 7 bytes.

Obviously, the first replacement code should consist of the same number of bytes as the first code area. If it is not the same number of bytes, because the offset of the instructions of the system service function handler module 204 is changed, the function of the system service function handler module 204 will be impaired. However, while the instruction for calling the system service function of the first code region shown in FIG. 4 is only 2 bytes, the first code region is designated as 10 bytes instead of 2 bytes because the jump code is 7 bytes. It became.

The reason why the first code area and the first replacement code are designated by 10 bytes will be described in more detail. Among the instructions of the first code area shown in FIG. 4, the system service function 208 call instruction is only one 'call ebx' composed of two bytes, but jumps to the first hooking module 214 included in the first replacement code. Because the instruction occupies seven bytes, the first code area should also consist of at least seven bytes. Also, 'rep movs', just before the 'call ebx' command, is only 2 bytes, which is less than 7 bytes. As a result, by including the 'jae offset' command in the first code area can exceed 7 bytes. On the other hand, since the first code area consists of 10 bytes exceeding 7 bytes by 3 bytes, it is necessary to add 3 bytes to the first replacement code. Since the added byte should not be a separate operation, three bytes may be added by including three NOP instructions.

In summary, when the first code area consists of more bytes than the bytes occupied by the instruction jumping to the first hooking module 214, the first code area may include instructions that precede or follow the system service function call instruction. Wherein the first replacement code includes at least one NOP instruction, wherein the number of no operation instructions is a byte count of the first code region and a jump instruction byte to the first hooking module. The difference in number is divided by the number of bytes occupied by the no-operation instruction. In this case, an instruction preceding or following the system service function call instruction included in the first code region is executed by the first hooking module 214.

Next, a second replacement code corresponding to the second code area will be described.

For the same reason that the first code region is composed of 10 bytes, the second code region is also composed of 10 bytes, and the second replacement code includes an instruction to jump to the second hooking module and three NOP instructions.

Each of the first code area and the second code area includes a command for calling a system service function and a command for jumping to the first code area, respectively, but the command is the first code area and the second code area. Note that it may consist of the first instruction in the code area, or it may consist of an intermediate instruction.

Next, the first hooking module 214 will be described. When the process of the user mode calls a system service function to be monitored, the first hooking module 214 is executed by executing an instruction that jumps to the first hooking module 214 of the first replacement code.

Table 1 is an example of an instruction configuration of the first hooking module 214 according to the first code region shown in FIG. 4 and the first alternative code shown in FIG. 5.

<Table 1: Example of Command Structure of First Hooking Module>

The first instruction (1 in Table 1) of the first hooking module 214 is for obtaining the same result as executing the first instruction in the first code area. The first instruction of the first code region jumps to the second code region of the system service function handler module 218 if the status bit of the CPU is set, otherwise it executes the next instruction of the call code, ie “rep movs”. Will run. Therefore, the first instruction of the first hooking module is an instruction to jump to the second hooking module 216 if the status bit of the CPU is set.

The second to fourth instructions of the first hooking module 214 (2 ~ 4 in Table 1) are for calling the main monitoring module 210. The EBX register stores the address of the system service function that the application wants to call, and the EAX register contains the index number of the system service function table 206, that is, the function number to be called. Therefore, when these three commands are executed, the main monitoring module 210 is called. The EAX register and the EBX register are the first and second parameters of the main monitoring module 210, which contain the address and function number of the system service function 208 to be called by the process running in the user mode.

The main monitoring module 210 performs a comparison test to identify whether a function call is registered in the system service function table 206 or a function call registered in another table by using the received two parameters. In addition, the main monitoring module 210 stores the process identification information, the index of the system service function 208 and the address value of the system service function 208 among the registers of the CPU, the main memory 206 and the auxiliary memory 102. By storing in at least one, it is possible to manage the system service function call history of each process later.

When all the commands included in the main monitoring module 210 have been executed, the main monitoring module 210 returns a return value, which corresponds to the sub-monitoring module 210 corresponding to the system service function 208 requested by the user mode process. You can set the address value. For example, if the CPU 100 is an IA-32 (x86) series, the return value is stored in the EAX register.

When the fifth instruction and the sixth instruction (⑤ ~ ⑥ in Table 1) are executed, the address value of the sub monitor module 212 is stored in the EBX register. Therefore, when the seventh instruction and the eighth instruction (⑦ ~ ⑧ of Table 1) is performed, the call of the sub-monitoring module 212 is made.

The secondary monitoring module 212 performs its various monitoring roles by examining its parameter values and then calls the corresponding system service function 208.

The ninth instruction (9 in Table 1) is the instruction jumping to the instruction following the first code area of the system service function handler module 218.

Hereinafter, the main monitoring module 210 and the sub-monitoring module 212 that are called by the first hooking module 214 when a call to the system service function to be monitored are requested will be described in more detail. The main monitoring module 210 is for monitoring information about the system service function 208 called by a process of the user mode, and the monitoring sub-functions 212 corresponding to the system service function to be monitored are the system service function 208. ) Specifically observes which parameter value is used in what way.

There is one primary monitoring module 210 and the secondary monitoring modules 212 are determined according to the number of system service functions to be monitored. For example, the main monitoring module 210 may monitor what kind of system service function is called by process A and how many times each kind of system service function is called.

However, after the kernel monitor is installed and executed in a computer system, when a function address registered in the system service function table 206 is changed by another program, an index and a function address performed by the main monitoring module 210 are changed. The comparison test used will not run normally. In order to solve this problem, the main monitoring module 210 changes the address of a function to be monitored by recognizing that it is hacked if the address of the function requested to be called is different from the address of the function stored at the beginning of kernel monitoring execution. By updating to, you can post an alarm message that will allow normal monitoring or notify you of the hack.

The sub-monitoring module 212 is a module that calls the system service function 208 and may be a module that corresponds to the system service function 208 one-to-one. The sub-monitoring module 212 may call the first hooking module 214 with reference to the address of the sub-monitoring module 212 set as the return value of the main monitoring module 210.

As an example of a system service function 208 that reads a memory, there may be one sub-monitoring module 212 that corresponds to the system service function 208 of the memory read function. For example, when the system service function 208 for reading a memory is NtReadVirtualMemory (), the secondary monitoring module 212 is configured with a function of the same prototype as the NtReadVirtualMemory () function, for example, the MonitoringNtReadVirtualMemory () function. Can be. At this time, the sub-monitoring module 212 can determine the specific memory addresses read by the process A by examining the parameter value input to the NtReadVirtualMemory () function before the call to the NtReadVirtualMemory () function.

Next, the second hooking module 216 will be described. The second hooking module 216 is executed to be executed when the instruction to jump to the second hooking module 216 of the second replacement code is executed or when the instruction of the first hooking module 214 to jump to the second code area is executed. do.

Table 2 is a command configuration example of the second hooking module 216 according to the second code area shown in FIG. 4 and the second alternative code shown in FIG. 5.

<Table 2: Example of Command Configuration of Second Hooking Module>

The second hooking module 216 includes a portion corresponding to the second code region and a jump code portion for executing the next instruction following the second code region existing in the system service function handler module 218. The second code region shown in FIG. 4 is composed of two instructions: a jump to the first code region and a previous instruction. Therefore, the part corresponding to the second code area is jumped to the first hooking module (2 in Table 2) to have the same result as the instruction jumping to the first code area, and the previous command (1 in Table 2) is used as it is. do. Second Code Area The jump portion for executing the next instruction makes the code jump to an instruction located behind the second code region of the system service function handler module 218 (3 in Table 2).

Hereinafter, a kernel monitoring method according to another embodiment of the present invention will be described with reference to FIGS. 6 and 7. 6 is a flowchart of a kernel monitoring method according to the present embodiment.

First, the kernel monitor is installed in the computer system (S600). Hereinafter, the installation method will be described first with reference to FIG. 7. 7 is a flowchart of a method of installing a kernel monitor according to the present embodiment.

The original system service function handler module is stored (S700). The original may be different according to the type and version of the operating system.

In the preparation step of installing the kernel monitor, it is determined whether the code of the system service function handler module 218 loaded in the main memory 106 or stored in the auxiliary memory 102 matches the original of the code (S702), If the result of the determination does not match, the code of the system service function handler module 218 is replaced with the original code (S704). The original match determination step (S702) and the step of replacing with the original code (S704) is to copy the system service function itself and insert the hooking code into the system service function handling module 204 to directly copy the system service function table without referring to it. This prevents hacking techniques that call system service functions.

Next, the first code area of the system service function handler module 204 is replaced with the first replacement code (S706), and the second code area of the system service function handler module 204 is also replaced with the second replacement code. (S706). The designation criteria of the first code area, the second code area, the first replacement code, the second replacement code, and the content of the included instructions are the same as those described in the computer system in which the kernel monitor is installed according to an embodiment of the present invention. A separate description will be omitted.

By performing steps S700 to S708, the system service function handler module 204 before the kernel watchdog is installed is changed to the system service function handler module 218 of the computer system where the kernel watcher is installed. The replacements S706 and S707 are preferably performed on both the main memory 106 and the system service function handler module 204 stored in the auxiliary memory 102. In particular, after the system service function handler module 204 stored in the main memory 106 is replaced, the system may be rebooted to reflect the changed contents.

Finally, the first hooking module 214, the second hooking module 216, the main monitoring module 210, and one or more secondary monitoring modules, which are modules required in addition to the system service function handler module 218, for kernel monitoring functions. By loading 212 into the main memory 106 and storing it in the secondary memory 102, the step S600 of installing the kernel monitor in the computer system is completed.

Hereinafter, when a process running in user mode actually calls a system service function (S602), a method of monitoring the same in kernel mode will be described with reference to FIG. 6 again. Hereinafter, it is assumed that the system service function is a system service function to be monitored. It should be noted that the kernel monitoring method according to the present embodiment does not have to be monitored for all system service functions provided by the operating system, but can be customized to provide a monitoring function for one or more system service functions. . It should be noted that the kernel monitoring function according to the present embodiment does not operate when a process running in the user mode calls a system service function that is not to be monitored.

In a system service function call (S602), the operating system executes a kernel level system service function handler module 218 (S604). Thereafter, the first replacement code included in the first code area and the instructions included in the first hooking module 214 are sequentially executed (S606). The first hooking module 214 calls the main monitoring module 210 with the information of the system service function as a parameter.

The main monitoring module 210 monitors the information on the system service function (S610). The monitoring can be performed in a variety of ways. For example, a comparison test may be performed to identify whether a function call is registered in the system service function table 206 or a function call registered in another table by using the received two parameters. In addition, the main monitoring module 210 stores the process identification information, the index of the system service function 208 and the address value of the system service function 208 among the registers of the CPU, the main memory 206 and the auxiliary memory 102. By storing in at least one, it is possible to manage the system service function call history of each process later. The result of the monitoring may be produced and posted as an alarm message or stored for later viewing.

As another monitoring method, the main monitoring module 210 changes the address of a function to be monitored by recognizing it as hacked if the address of the function requested to be called is different from the address of the function stored at the beginning of kernel monitoring execution. By updating to a function, you can then post an alarm message that will either allow normal monitoring or notify you of a hack.

When the main monitoring module 210 sets the address of the sub-monitoring module 212 corresponding to the system service function as a return value and returns to the first hooking module 214, the first hooking module 214 returns the sub-hook. The sub-monitoring module 212 corresponding to the system service function is called by referring to the address of the monitoring module (S612). The parameters included in the call S612 of the sub-monitoring module 212 are preferably the same as parameters included in the process running in the user mode by requesting the kernel to call the system service function.

The called submonitoring module 212 monitors the parameter information (S614). For example, when the called system service function is a system service function that reads a certain area of the main memory, the parameter may include a start address and the number of bytes to be read, so that the information can be monitored. The result of the monitoring may be produced and posted as an alarm message or stored for later viewing.

After monitoring all the monitoring-related data, the sub-monitoring module 212 calls the system service function (S616).

When all of the instructions included in the system service function are executed, the next instruction of the sub-monitoring module 212 call-related instruction of the first hooking module 214 is executed. Preferably, the next command is a command that jumps to the next command of the first code area.

Although the embodiments of the present invention have been described above with reference to the accompanying drawings, those skilled in the art to which the present invention pertains may implement the present invention in other specific forms without changing the technical spirit or essential features thereof. I can understand that. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive.

1 is a conceptual diagram showing the basic configuration of a computer system.

2 is a conceptual diagram illustrating a configuration of a code region after an operating system is loaded.

3 is a structural diagram of a computer system in which a kernel monitor is installed according to an embodiment of the present invention.

4 is a diagram illustrating a system service function handler module before installing a kernel monitor according to an embodiment of the present invention.

5 is a diagram illustrating a system service function handler module in a state where a kernel monitor is installed according to an embodiment of the present invention.

6 is a flowchart of a kernel monitoring method according to the present embodiment.

7 is a flowchart of a method of installing a kernel monitor according to the present embodiment.

Claims (16)

In a kernel mode, replace a first code area including a command for calling a monitored system service function among first codes of a module relaying a call of a system service function with a first replacement code, wherein the first replacement code is set as a first replacement code. 1 comprising instructions to jump to a hooking module and comprising bytes, such as bytes occupied by the first code region; When the first replacement code and the first hooking module are executed sequentially by calling a system service function to be monitored by a process running in the user mode, the first hooking module may parameter information of the system service function. Invoking the main monitoring module; The main monitoring module monitoring information about a system service function called by the process; And After the main monitoring module returns to the first hooking module, the first hooking module includes executing at least one instruction to call a system service function called by the process. The method of claim 1, And executing all instructions included in the system service function called after the first hooking module jumps to a next instruction of the first code region. The method of claim 1, When the first code region is composed of more bytes than the bytes occupied by the instruction jumping to the first hooking module, the first code region includes at least one instruction preceding or following the system service function call instruction, The first replacement code includes at least one NOP instruction, wherein the number of no operation instructions is determined by a difference between the number of bytes of the first code region and the number of bytes of jump instructions to the first hooking module. Kernel monitoring method divided by the number of bytes occupied by operation instructions. The method of claim 3, wherein The instruction that precedes or follows the system service function call instruction included in the first code region is executed by the first hooking module. The method of claim 1, The replacement of the first code region with the first replacement code comprises: 2. A kernel monitoring method for both the first code region loaded in the main memory and the first code region stored in the auxiliary memory. The method of claim 1, Replacing the first code region with a first replacement code, And after the replacement, rebooting the computer system. The method of claim 1, Instructions for jumping to the first hooking module included in the first replacement code include: Kernel monitoring method, which is a far jump instruction that can jump to other code segments. The method of claim 1, The information of the system service function, And an index of an access address in the main memory of the system service function and an index of a system service table of the system service function of the system service function. The method of claim 1, Executing a command to call the system service function, The main monitoring module returning an access address in the main memory of the secondary monitoring module corresponding to the called system service function; Calling, by the first hooking module, a sub-monitoring module having the same prototype as the called system service function using a parameter passed to the system service function; The secondary monitoring module monitoring the parameter; And And the sub-monitoring module includes invoking the called system service function using the parameter. The method of claim 1, Replacing the first code region with a first replacement code, Replacing a second code area with a second replacement code, the second code including a command to jump to the first code area of the code of the system service function handler module, wherein the second replacement code is replaced by a second hooking module. A kernel monitoring method comprising a jump instruction and a byte equal to a byte occupied by the second code area. The method of claim 1, Replacing the first code region with a first replacement code, Determining whether the code of the system service function handler module matches the original of the code; If the result of the determination does not match, replacing the code of the system service function handler module with the original code. The method of claim 1, Monitoring the information on the system service function, And recognizing that the function has been hacked and updating the address of the function to be changed to a changed function if the address of the function to which the call is requested and the address of the function stored at the beginning of kernel monitoring execution are different. A first replacement code replacing a first code area including an instruction to call a monitored system service function, the first replacement code including an instruction to jump to a first hooking module and the first code area being A system service function handler module composed of bytes such as bytes occupied; The supervised system service function is called by the process running in the user mode and jumps to the first alternative code to be executed. The main supervisory module is called by using the information of the system service function as a parameter. A first hooking module that executes at least one instruction for calling a system service function called by the process after being returned; And And a kernel monitoring device including a main monitoring module for monitoring information of the system service function provided through the parameter. The method of claim 13, At least one sub-monitoring module called by the first hooking module and monitoring the parameters passed to the system service function and calling the system service function, The first hooking module, And a kernel monitoring device installed to call the secondary monitoring module corresponding to the system service function after the main monitoring module is returned. The method of claim 13, A kernel monitoring further comprising an original maintenance module that determines whether the code of the system service function handler module matches the original of the code, and replaces the code of the system service function handler module with the original code when the result of the determination does not match Computer system on which the device is installed. The method of claim 13, The main monitoring module, A computer system with a kernel monitoring device that updates the address of a function to be monitored by recognizing that it is hacked if the address of the function requested to be called is different from the address of the function stored at the beginning of kernel monitoring execution.

Images