KR101366544B1 - Method and apparatus for detecting dll rootkit for hacking - Google Patents

Abstract

It has excellent client adaptability and provides technology to detect all malicious DLLs. DLL rootkit detection method for hacking according to an embodiment of the present invention, the device for detecting a DLL (Dynamic Linking Library) rootkit (hacking) for hacking, of the DLLs determined to be running in the user terminal Collecting the first DLL list as a list; If reading of any one of memories corresponding to at least one DLL using the address variable value received from the counter succeeds, the code value of the predetermined area among the code values stored in the read memory matches the preset first code. Determining whether or not; If it is determined that a value of a predetermined region among the values stored in the read memory matches the preset first code, determining whether the DLL information corresponding to the read memory exists in the first DLL list; And when it is determined that the DLL information corresponding to the read memory is not present in the first DLL list, adding the DLL information corresponding to the read memory to the second DLL list as a list of DLLs for the rootkit. Characterized in that.

Description

METHOD AND APPARATUS FOR DETECTING DLL ROOTKIT FOR HACKING}

The present invention relates to a technique for preventing hacking by accurately detecting a hidden rootkit file loaded on a game client to obtain an administrator account and the like, and specifically, a hidden rootkit DLL (dynamic link library, Unlike detection technology that could not be detected by Dynamic Linking Library, it relates to technology that can detect hidden rootkit DLL.

Recently, as various contents are transmitted / received and used through online, processes executed in user terminals are also diversified. In particular, a service for downloading a client for using various contents such as an SNS (social network service), a portal site, a bulletin board site, a club, a game, etc. through a network to a user terminal and using the content in online or offline is provided .

Due to the phenomenon as described above, in the user terminal, various client programs are installed and used in the user terminal. When the client runs, the most common load and run is a dynamic link library, or dynamic linking library (DLL). A DLL is a file for dividing the routines of algorithms and processes performed on the client, and loading only those necessary in memory and executing them.

The DLL is loaded and executed as needed when the client is executed. As the client is executed, the DLL that is loaded and executed may include a normal DLL that is loaded and executed to execute a normal function routine of the client.

However, in addition to the normal DLL, there may be a hidden DLL in the client for use in hacking. This DLL is commonly called a DLL rootkit. When the DLL rootkit is secretly executed according to the execution of the client, a user account can be extracted or used to automatically hunt and manipulate stats by manipulating the game client's functions.

The DLL rootkit can be secretly inserted into the client, and is used in other processes such that only the thread that is executed when the client is executed and is executed as a result of execution is executed on the client.

In the existing method of detecting a DLL rootkit as described above, a separate DLL file for detecting a DLL rootkit is generated for each client and inserted into the client, and the DLL file is executed according to the execution of the client. Methods have been used to detect DLLs.

However, according to the existing method, it is not possible to detect a method that prevents the DLL from being found by allowing only other threads to execute the thread according to the load of the DLL, and the client has to generate a different DLL file for each client. The problem of adaptability has been pointed out.

Accordingly, an object of the present invention is to solve the limitations of the existing DLL rootkit detection technology, to provide a technology capable of universal and accurate detection, and to provide a technique for preventing hacking through the DLL rootkit in advance.

In order to achieve the above object, a method for detecting a DLL rootkit for hacking according to an embodiment of the present invention, the apparatus for detecting a DLL (Dynamic Linking Library) rootkit (hacking) for hacking, at the user terminal Collecting a first DLL list as a list of DLLs determined to be running; When a reading of any one of memories corresponding to at least one DLL using the address variable value received from the counter succeeds, the code value of a predetermined area among the code values stored in the read memory is set to the preset first code. Determining whether or not a match; If it is determined that a value of a predetermined region among the values stored in the read memory matches the preset first code, determining whether the DLL information corresponding to the read memory exists in the first DLL list. ; And when it is determined that the DLL information corresponding to the read memory does not exist in the first DLL list, adding the DLL information corresponding to the read memory to the second DLL list as a list of DLLs for a rootkit. It characterized by including.

Determining whether or not the first code matches the preset first code comprises: receiving the address variable value from the counter; Comparing the received address variable value with memory execution information to determine whether a memory having the received address variable value as a memory address exists; And when there is a memory having the received address variable value as a memory address, determining a memory having the received address variable value as a memory address as the read memory.

Determining whether the first DLL list is present comprises: searching for a file matching the read memory; And determining whether the DLL information of the searched file exists in the first DLL list.

If retrieval of a file matching the read memory fails, adding a thread corresponding to the read memory to the first thread list as a list of threads for a rootkit. .

In the step of adding to the second DLL list, when the DLL information of the searched file does not exist in the first DLL list, it is preferable to add DLL information of the searched file to the second DLL list.

The determining of whether the first code matches the predetermined first code may include: among the code values stored in the read memory, a code value classified into a header area according to the structure of the read memory. It is desirable to determine whether they match.

Preferably, the predetermined first code is “MZ” as a header code value set in an executable file.

The determining whether the first variable corresponds to the preset first code may include, if the address variable value is equal to or smaller than a preset threshold variable value, using the address variable value to the at least one DLL. It is desirable to attempt reading to any of the corresponding memories.

The determining whether the first code corresponds to the preset first code may include: when the address variable value is greater than a preset threshold variable value, using one of the memory corresponding to the at least one DLL by using the address variable value. It is desirable to stop the reading attempt for the.

And after the adding to the second DLL list, updating the address variable value by adding a predetermined unit memory address change value to the address variable value stored in the counter.

After updating the address variable value, if the updated address variable value is equal to or less than the predetermined threshold variable value, among the memory corresponding to at least one DLL using the updated address variable value If any one of the readings is successful, it is preferable to repeat the step of determining whether a code value of a predetermined region among the code values stored in the read memory is identical to the preset first code.

After determining whether the DLL information corresponding to the read memory exists in the first DLL list, when it is determined that the DLL information corresponding to the read memory exists in the first DLL list, the counter Updating the address variable value by adding a predetermined unit memory address change value to the address variable value stored in the memory; And when the updated address variable value is equal to or smaller than a predetermined threshold variable value, when reading of any one of memories corresponding to at least one DLL using the updated address variable value succeeds, The method may further include determining whether a code value of a predetermined region among the code values stored in the read memory matches the predetermined first code.

The collecting of the first DLL list may include a common API function provided by an operating system of the user terminal and the first function using a first function which is a function of extracting a list of DLLs that are determined to be executed in the user terminal. It is desirable to collect a list of DLLs.

The apparatus for detecting a DLL rootkit for hacking according to an embodiment of the present invention may include: a list collector configured to collect a first DLL list as a list of DLLs determined to be executed in a user terminal; A memory reading unit for reading a memory by using an address variable value received from a counter; When a reading of the memory reading unit is successful and any one of memories corresponding to at least one DLL is read, whether a code value of a predetermined region among the code values stored in the reading memory matches the predetermined first code A file search unit for determining whether to determine whether or not a value of a predetermined region among the values stored in the read memory matches a preset first code, the file search unit extracting DLL information corresponding to the read memory; And determining whether the extracted DLL information exists in the first DLL list, and when it is determined that the DLL information corresponding to the read memory does not exist in the first DLL list, the extracted DLL information corresponds to the read memory. And a rootkit list manager for adding the DLL information to the second DLL list as a list of DLLs for the rootkit.

The memory reading unit compares the address variable value received from the counter with memory execution information, and when there is a memory having the received address variable value as a memory address, the memory having the received address variable value as a memory address. Is preferably determined as the read memory.

The file search unit may search for a file matching the read memory, and determine whether the DLL information of the searched file exists in the first DLL list.

The rootkit list manager may add a thread corresponding to the read memory to the first thread list as a list of threads for the rootkit when a search for a file matching the read memory fails. .

The file search unit may determine whether a code value classified into a header area according to the structure of the read memory among the code values stored in the read memory matches the preset first code.

Preferably, the predetermined first code is “MZ” as a header code value set in an executable file.

The memory reading unit attempts to read any one of memories corresponding to the at least one DLL by using the address variable value when the address variable value is equal to or smaller than a predetermined threshold variable value. It is desirable to.

The counter may add, in the rootkit list manager, DLL information corresponding to the read memory to the second DLL list as a list of DLLs for the rootkit, or the DLL information corresponding to the read memory may be added to the first DLL list. After it is determined to exist, it is preferable to update the address variable value by adding a predetermined unit memory address change value to the address variable value stored in the counter.

Preferably, the memory reading unit attempts to read the memory repeatedly by using the updated address variable value.

According to the present invention, a hidden DLL rootkit or a malicious thread in which the DLL does not exist can be detected based on memory. Also, instead of detecting a rootkit by inserting a DLL file inside the client, it can be detected by an external process using a memory address, which has the advantage of excellent adaptability to the client. This has the effect of detecting DLL rootkits and malicious threads in a universal and accurate manner.

1 is a flowchart of a DLL rootkit detection method for hacking according to an embodiment of the present invention.
2 illustrates a flow in which execution of a DLL rootkit detection method for hacking is controlled according to an embodiment of the present invention.
3 illustrates an example of a flow in which an address variable value is updated according to an embodiment of the present invention.
4 illustrates an example of a flow of collecting a first DLL list according to an embodiment of the present invention.
5 illustrates an example of a flow of managing a second DLL list according to an embodiment of the present invention.
6 illustrates an example of a flow of detecting a DLL to be included in a second DLL list according to an embodiment of the present invention.
7 is a block diagram of an apparatus for detecting a DLL rootkit for hacking according to an embodiment of the present invention.
8 is a view for explaining a function performed by the list collector according to an embodiment of the present invention.
9 is a diagram for describing a function performed by a memory reading unit according to an exemplary embodiment of the present invention.
10 to 12 illustrate examples of executing a DLL rootkit in an embodiment of the present invention.

Hereinafter, a method and apparatus for detecting a DLL rootkit for hacking according to each embodiment of the present invention will be described with reference to the accompanying drawings.

The following embodiments are detailed description to help understand the present invention, and it should be understood that the present invention is not intended to limit the scope of the present invention. Accordingly, equivalent inventions performing the same functions as the present invention are also within the scope of the present invention.

In addition, in adding reference numerals to the constituent elements of the drawings, it is to be noted that the same constituent elements are denoted by the same reference numerals even though they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected to or connected to the other component, It should be understood that an element may be "connected," "coupled," or "connected."

In the embodiments of the present invention, " communication ", " communication network ", and " network " The three terms refer to wired and wireless local area and wide area data transmission and reception networks capable of transmitting and receiving a file between a user terminal, a terminal of another user, and a download server.

1 is a flowchart of a DLL rootkit detection method for hacking according to an embodiment of the present invention.

First, the term " process " in the present invention means the program itself or a part thereof being executed in the user terminal. Also, the term " process " means a series of processes for manipulating or processing input or output of data.

Each process is performed under the jurisdiction of the OS (Operating System). In this case, the kernel that allocates system resources to programs corresponding to each process under the operating system is called a kernel (hereinafter referred to as a kernel).

The kernel is an essential component of a computer operating system, and is a component of a system that provides a pervasive service to other parts of an operating system under an OS. Typically, the kernel includes an interrupt handler, which handles all requests that compete for kernel services, such as terminated I / O operations, a scheduler, which determines in what order the programs will share the processing time of the kernel, And a supervisor who licenses the computer to each process.

The kernel also has a memory manager that manages the address space of the operating system in memory or storage and distributes them to all the peripherals and other users of the kernel's services. The services of the kernel are requested through different parts of the operating system, or through a set of program interfaces, often known as system calls.

In the present invention, a DLL (Dynamic Linking Library) is an operating system (OS) function of OS / 2, Windows, etc., which divides software routines into several files, puts them on a disk, and loads only those necessary in the execution memory for use. As a file, a file used as a DLL is called a 'dll file' because the file extension is 'dll'. The advantage of DLLs is that they use routines in common. The collection of functions in a routine is called a data collection, which is often compiled when the executable file is created. However, this method is inefficient because multiple executables have the same routine. DLLs can be shared by multiple executables, saving disk space and memory. Also, if you want to modify the program, it may be completed by modifying only the DLL file. In Windows, you can share DLLs with applications as well as OS functions, but it is difficult to determine at the user level whether applications such as DLL files are shared.

In addition, a thread refers to an execution path existing inside a process when a computer program is executed. After all, a thread is a series of executable code, a process is just a shell, and the actual work is the thread. When a process is created, one main thread is created to handle most of the work. When the main thread terminates, the process also terminates. Multitasking is the environment in which multiple processes run concurrently in one operating system, and multithreading is the execution of multiple threads in one process at the same time.

A DLL rootkit means a hidden DLL that is loaded when the program is executed for malicious purposes. A DLL that exists externally for malicious purposes and that is arbitrarily created when the program is executed may also be a type of DLL rootkit.

When the rootkit is installed, it changes all the paths it has penetrated and hides the commands so that even if the hacker is hacking the system remotely, it is difficult to detect the fact that the rootkit is installed. An intruder first cracks a password or finds a system vulnerability to gain access privileges for a user, then installs a rootkit on the computer. Rootkits detect root user IDs and passwords on other computers on the network and provide root privileges, system information, and other special access rights to hackers. It also provides features such as monitoring traffic and keystrokes, installing backdoors in the system for the purpose of hackers, modifying log files, attacking other computers on the network, and modifying existing system tools to avoid detection.

If you use a rootkit, the DLL can be hidden. In other words, the DLL rootkit disappears from the currently running DLL, and thus the hacking can be performed through the rootkit after the DLL becomes invisible.

There are several ways to prevent the DLL rootkit from being included in the list of currently running DLLs. For example, by modifying (hooking) a general function (a common API) used to collect a list of DLLs currently running in the operating system, the DLL can not appear in the list.

Alternatively, you can bypass the link inside the PEB structure containing the list information of the DLLs loaded in the process so that the DLLs do not appear in the DLL list using the common API. Alternatively, you can hide the DLL by letting the DLL load it into the target process, creating a thread only, and forcibly unloading the DLL.

In general, in order to detect a malicious DLL, that is, a DLL for hacking, a separate detection DLL is inserted into a corresponding process to detect a malicious DLL. However, this method has a disadvantage in that it is inadequate to the client and does not detect the method of creating only a thread in the above-mentioned example.

To this end, in the method for detecting a DLL rootkit for hacking according to an embodiment of the present invention, an apparatus for detecting a DLL rootkit for hacking (hereinafter, referred to as a device) is a first list of DLLs loaded in a memory of a user terminal. 1 collect a DLL list (S10).

When a DLL needed to execute a process is loaded in a series of processes, the DLL is executed by allocating a memory value with a constant address in memory. The device generally collects a first DLL list, which is a list of DLLs collected by a general function, which is loaded and executed in a memory using a general function provided by an operating system.

At this time, the detailed flow of collecting the first DLL list is the same as the embodiment of FIG. 4.

4 illustrates an example of a flow of collecting a first DLL list according to an embodiment of the present invention.

Referring to FIG. 4, the apparatus first performs a step S14 of loading a first function, which is a common API function of an operating system of a user terminal. As mentioned above, the common API function refers to a general function provided by an operating system to collect identification information of a DLL that is determined to be loaded into memory.

Thereafter, the apparatus generates a first DLL list by performing a step S15 of collecting the first DLL list by using the loaded first function.

When the first DLL list is collected, the device attempts to read the memory of the user terminal by using an address variable value, which is a variable corresponding to a memory address value, as a value generated by a numerical value generating means such as a counter (S20). ).

Reading the memory means determining whether an object currently loaded and executed exists in the memory address using the memory address. If the DLL is loaded and running at that memory address, reading of the memory will succeed.

That is, the device first receives the address variable value, which is the aforementioned variable, from the counter, and then compares the received address variable value with the execution information of the memory to determine whether there is a memory value having the received address variable value as the memory address. Will be judged. In this case, when it is determined that the memory value exists, the device determines that the reading of the memory is successful by using the address variable value as described above, thereby determining the memory as the read memory.

In operation S20, the device determines whether the reading of the memory is successful (S30). If the reading of the memory succeeds, the device determines the code value of the predetermined area among the code values stored in the read memory. In operation S40, it is determined whether the first code matches the predetermined first code. A detailed embodiment of the above step S40 is shown in FIG. 6.

6 illustrates an example of a flow of detecting a DLL to be included in a second DLL list according to an embodiment of the present invention.

Referring to FIG. 6, the apparatus first performs a step of determining whether reading of a memory is successful using an address variable value as in step S30 of FIG. 1.

If the reading of the memory is successful, the device extracts a code value classified into a predetermined area, that is, a header area of the DLL, among the areas divided according to the structure of the read memory (S41). Thereafter, it is determined whether the extracted header value matches the first code of 'MZ' (S42).

After the step S42, if the header value is a predetermined first code, that is, 'MZ', step S50 of FIG. 1 is performed. If the header value is not 'MZ', the DLL corresponding to the memory is included in the second DLL list. It does not perform whether or not.

Most malicious DLL codes are codes that correspond to executable files. On the other hand, each DLL code includes a code value indicating the characteristics of the file in the header part, and 'MZ', which is commonly referred to as 'magic number', refers to an executable file of MS-DOS. That is, a DLL file for executing a process, whether it is a normal executable file or a hidden DLL file, contains a code value of 'MZ' in its header area. Accordingly, the device determines whether the header area has a code value of 'MZ' and determines whether to add a DLL corresponding to the read memory to the second DLL list, which is a list of malicious DLLs. Will be determined.

In operation S40, when it is determined that the value of the preset region matches the preset first code, the device determines whether the DLL information corresponding to the read memory exists in the first DLL list (S50). In this case, if the DLL information corresponding to the read memory does not exist in the first DLL list, step S60 of adding the DLL information corresponding to the read memory to the second DLL list is performed.

Specifically, the step S50 may mean searching for a file matching the read memory, and analyzing the DLL information of the searched file to determine whether the analyzed DLL information exists in the first DLL list.

In this case, step S60 means that if the DLL information of the searched file does not exist in the first DLL list, the DLL information of the searched file is added to the second DLL list.

Meanwhile, a specific embodiment of adding DLL information corresponding to the read memory to the second DLL list is illustrated in FIG. 5.

5 illustrates an example of a flow of managing a second DLL list according to an embodiment of the present invention.

Referring to FIG. 5, the device first performs step S40 of FIG. 1 to determine whether a character of a DLL file corresponding to a read memory is an executable file.

If it is determined that the memory is allocated according to the execution of the executable file in the read memory, the device first searches for a file matching the memory value (S51).

In operation S51, the device determines whether a search for a file matching the memory value is successful (S52).

If, as a result of performing the step S52, the file search fails, the device corresponds to a case where only a thread exists by forcibly unloading the DLL among the above-mentioned types of DLL rootkits, and thus the device rootkit corresponding to the corresponding memory value. It is added to the first thread list as a list of threads for.

Although the first thread list is mentioned separately from the second DLL list, in the present invention, since the first thread list is the same as the list for the rootkit target, the first thread list may mean the same list. That is, when a file search fails, step S60 of FIG. 1, that is, adding a thread or a DLL corresponding to the read memory to the second DLL list may be performed.

On the other hand, if the file is successfully searched, the device determines whether the DLL information of the searched file exists in the first DLL list (S53), and as mentioned above, the device does not exist in the first DLL list. If it is determined, step S60 of adding DLL information of a file matched with the read memory to the second DLL list is performed.

On the other hand, if it is determined that it exists in the first DLL list, step S70 of immediately changing the address variable value is performed.

Returning to the description of FIG. 1 again, step S70 is performed in two cases. First, when DLL information corresponding to the read memory exists in the first DLL list, the address variable value is immediately updated without updating the second DLL list.

On the other hand, if the search for the file corresponding to the read memory fails or if it is determined that the DLL information of the searched file does not exist in the first DLL list, after the step of adding the information to the second DLL list (S60) , The address variable value is updated.

Through the above process, in the present invention, by directly accessing the memory and attempting to read the memory using the address variable value, there is an effect of detecting a hidden DLL or a malicious thread in any way. In addition, since the DLL is detected by reading the memory from the outside with the address variable value instead of using the DLL, the DLL can be detected using the same method for all clients, thereby providing excellent adaptability to the client.

On the other hand, since the step S70, that is, updating the address variable value means attempting to read the memory for all the memory address values, the address variable is a numerical value corresponding to the end of the memory address from the start point of the memory address of the user terminal. Means to update the value. Through this, the user terminal attempts to read all values of the memory area allocated according to the load of the DLL loaded as the process executes. Specific examples thereof will be described in the following description with reference to FIGS. 2 and 3.

2 illustrates a flow in which execution of a DLL rootkit detection method for hacking is controlled according to an embodiment of the present invention.

As mentioned in FIG. 1, the address variable value is used for reading a memory. The address variable value may be changed at each detection time as mentioned in step S70 of FIG. 1.

To this end, referring to FIG. 2, when the first DLL list is collected (S10), the device performs a step (S11) of calling the address variable value at the current detection time from the counter.

The address variable value has a start point and end point as described above corresponding to the address of the memory. In the present invention, the last corresponding numerical value is used as the threshold variable value.

That is, the address variable value is used while changing from the start point to the threshold variable value corresponding to the last value, and used for reading the memory in the user terminal.

Therefore, before the device attempts to read the memory by using the address variable value, the device performs whether the address variable value at the present detection time exceeds the threshold variable value (S12), and does not need to try to read the memory. Will be judged.

As a result of the operation of S12, when the address variable value at the present detection time is equal to or smaller than the threshold variable value, step S20 of FIG. 1, that is, attempting to read the memory using the current address variable value is performed. do.

However, when it is determined that the address variable value at the present detection time is larger than the threshold variable value as a result of the operation of S12, since the device does not need to attempt reading of the memory further, the device may not be attempted. In step S13, a method of detecting a DLL rootkit for hacking, that is, ending an attempt of memory reading may be performed.

This avoids unlimited repetitive detections and attempts to read memory with minimal system resources, reducing system load and rethinking the effectiveness of DLL rootkit detection.

3 illustrates an example of a flow in which an address variable value is updated according to an embodiment of the present invention.

As mentioned in FIGS. 1 and 2, an address variable value is used as a numerical value corresponding to a memory address while its value is changed, and is used to attempt reading of a memory. Therefore, the address variable value will have to be changed at each detection point.

For this purpose, referring to FIG. 3, the device first determines whether reading of the memory is successful using the address variable value at step S30 of FIG. 1.

In this case, when the DLL information corresponding to the read memory exists in the first DLL list, the detected DLL information is skipped without storing the detected DLL information in the second DLL list. Meanwhile, if the DLL information corresponding to the read memory does not exist in the first DLL list, the device performs step S60 of FIG. 1, that is, adding the detected DLL information to the second DLL list.

When the step S60 is performed or the DLL information corresponding to the read memory is not stored in the second DLL list, that is, when a series of processes according to the determination result is finished as any determination result, the device controls the counter to set the address variable value. Update it.

At this time, the address variable value is updated by adding the unit memory address variation value allocated in the memory to the address variable value at the present detection time (S71).

If the address variable value is updated, the device may perform a step of attempting to read the memory again using the updated address variable value.

That is, whenever an address variable value is updated, a reading of the memory is attempted, and this series of steps may be repeatedly performed from the beginning of the memory address to the end.

Through this, as mentioned above, any hidden DLL can be detected by the present invention using any method, and accordingly, there is an effect of detecting a rootkit for hacking.

7 is a block diagram of an apparatus for detecting a DLL rootkit for hacking according to an embodiment of the present invention. In the following description, portions overlapping with the description of Figs. 1 to 6 will be omitted.

Referring to FIG. 7, the apparatus for detecting a DLL rootkit 10 for hacking according to an embodiment of the present invention may include a list collecting unit 11, a memory reading unit 12, a file searching unit 13, and a rootkit list managing unit. (14). The memory reading unit 12 may be connected with a counter 15 for providing an address variable value.

As mentioned above, the list collecting unit 11 uses the first function provided by the operating system, and is a first DLL that is a list of DLLs 50 and 51 that are currently loaded into the memory 30 and determined to be running. Perform a function to collect a list.

The DLL list collected by the list collecting unit 11 is transferred to the rootkit list management unit 14 for later comparison.

The memory reading unit 12 receives the address variable value from the counter 15 and then determines whether a memory value having the corresponding address variable value exists from the memory 30 by using the received address variable value; That is, it tries to read memory.

That is, after comparing the address variable value received from the counter 15 with the execution information of the memory 30, and if there is a memory having the received address variable value as the memory address, the received address variable value as the memory address. The memory having the above function is determined as the read memory.

At this time, as mentioned above, the memory reading unit 12 receives an address variable value that is repeatedly updated from the counter 15, and repeatedly tries to read the memory 30 using the address variable value. The above attempt will be repeated from the beginning of the address of the memory 30 to the end.

At this time, the reading of the memory 30 is attempted only when the last address of the memory 30, that is, the current address variable value is less than or equal to the threshold variable value, and the address variable value is larger than the threshold variable value. Stop reading for 30 and stop the process of the present invention.

When the memory read from the memory reading unit 12 is detected, the file retrieval unit 13 determines that a value of a predetermined region among the values stored in the read memory corresponds to the preset first code. Extracts the DLL information corresponding to the read memory.

Referring to FIG. 7, there are allocated memory values 31 in the memory 30, each of which corresponds to each of the DLL information 51 of any of the sets of DLLs 50. Of course, as mentioned above, in the case of the malicious thread, the DLL information 51 corresponding to the memory value 31, that is, the file may not exist.

Meanwhile, as mentioned above, the file search unit 13 determines whether the code value classified as the header area among the values stored in the read memory is 'MZ', the header code value corresponding to the executable file, and determines the header code value. When the DLL of 'MZ' is searched for, it is transmitted to the rootkit list manager 14.

When the rootkit list manager 14 determines that the header code value is 'MZ' and extracts DLL information corresponding to the read memory and receives the extracted DLL information from the file search unit 13, the rootkit list management unit 14 receives the extracted DLL information. It is determined whether the extracted DLL information is substituted into the first DLL list in the first DLL list, and when it is determined that the extracted DLL information does not exist, the corresponding DLL information is added to the second DLL list which is a list of DLLs for the rootkit and the database (60). Save to).

At this time, as mentioned above, when the file search unit 13 receives the information that the search for the file matching the read memory is determined to have failed or is determined to fail, the first or second list is the same as or different from the second DLL list. 1 Information corresponding to the memory can be stored in the thread list.

On the other hand, the counter 15 performs a function of providing an address variable value to the memory reading unit 12 as mentioned above, and updates the address variable value for this purpose. At this time, the counter 15 adds DLL information corresponding to the memory read by the rootkit list manager 14 to the second DLL list, or determines that the DLL information corresponding to the read memory exists in the first DLL list. If two cases are detected, the address variable value stored in the counter is updated.

The update of the address variable value is made by adding the unit memory address variation value to the address variable value at the present detection time.

8 is a view for explaining a function performed by the list collecting unit 11 according to an embodiment of the present invention.

Referring to FIG. 8, there are DLLs 51 and 52 corresponding to each other in the memory 30, and the list collecting unit 11 uses the first function, which is the above-mentioned public API function, provided from the operating system 20. Search whether a memory value corresponding to the DLL 50 exists. As a result, the information of the DLL information (excluding DLL1, DLL2, and DLL3 which is a malicious DLL) which is determined to be loaded into the memory 30 at the current operating system 20 stage is transmitted to the list collecting unit 11.

9 is a diagram for describing a function performed by the memory reading unit 12 according to an exemplary embodiment of the present invention.

Referring to FIG. 9, the memory reading unit 12 attempts to read a memory by receiving an address variable value 121 at the current sensing time from the counter 15 and transferring it to the memory 30.

The memory 30 has allocated memory values 31 and 32, among which a memory value 32 corresponding to a DLL that may not be retrieved through the public API used in the embodiment of FIG. There may be a memory value 31 corresponding to a normal DLL retrieved through the API.

At this time, since the memory reading unit 12 attempts to read the memory directly from the memory 30 using the address variable value 121, the memory reading unit 12 responds to the malicious DLL as well as the memory value 31 corresponding to the normal DLL. The memory value 32 to be detected is also detected without discriminating.

10 to 12 illustrate examples of executing a DLL rootkit in an embodiment of the present invention.

First, referring to FIG. 10, information about the PEB structure 211 may be stored in the kernel 21, and the PEB structure 211 includes address link information 212 of a DLL. The address link information 212 is used by the first function provided by the above-mentioned operating system 20 to generate the first DLL list.

At this time, the malicious DLL 52 among the DLLs included in the DLL stage 50 bypasses the link between the DLL and the address link information 212 in the PEB structure 211, unlike the normal DLL 51. In FIG. 10, the connection to the address link information 212 is broken from the DLL stage 50, but it should be understood that the link is bypassed.

In this case, the malicious DLL 52 is not included in the address link information 212, so that the information of the corresponding DLL 52 will not be retrieved using the public API function.

In the embodiment of Figure 11, it can be seen that the information of the threads (81, 82) currently in progress in the process (80) is displayed. The threads 81 and 82 may be generated when a normal DLL 51 included in the DLL 50 is loaded to perform a task.

However, the malicious thread 82 is created by forcibly unloading the DLL rootkit 53 after loading, so that the information of the DLL does not exist, that is, the file does not exist and only the thread exists.

At this time, of course, only the DLL 51 corresponding to the currently loaded normal thread 81 will exist in the DLL stage 50, and the DLL corresponding to the malicious thread 82 will not exist.

In this case, only the list of the normal DLL 51 may exist in the first DLL list 70 using the common API.

Referring to the embodiment of FIG. 12, the operating system 21 may have a common API, that is, the above-mentioned first function 22, so that the first DLL list may be extracted. In the DLL stage 50, a normal DLL 51 and a malicious DLL 52 may exist.

At this time, the rootkit 53 corresponding to the malicious DLL 52 modulates (Hooking) the first function 22 by execution, so that the first function 22 to the rootkit 53 when extracting the first DLL list. Information of the corresponding DLL 52 may not be included in the first DLL list.

The DLL rootkit detection method for hacking according to the above-described embodiment of the present invention is executed by an application basically installed in a terminal (which may include a program included in a platform or an operating system basically loaded in the terminal). It may also be executed by an application (ie, a program) that the user directly installs on the terminal through an application providing server such as an application store server, an application, or a web server associated with the corresponding service. In this sense, the method for detecting a DLL rootkit for hacking according to an embodiment of the present invention described above is implemented as an application (ie, a program) that is basically installed in a terminal or directly installed by a user, and can be read by a computer such as a terminal. Can be recorded on the medium.

Such a program may be recorded on a recording medium that can be read by a computer and executed by a computer so that the above-described functions can be executed.

As described above, in order to execute the DLL rootkit detection method for hacking according to each embodiment of the present invention, the above-described program is coded in a computer language such as C, C ++, JAVA, or machine language, which can be read by a computer processor (CPU). Code may be included.

The code may include a function code related to a function or the like that defines the functions described above and may include an execution procedure related control code necessary for the processor of the computer to execute the functions described above according to a predetermined procedure.

In addition, such code may further include memory reference related code as to what additional information or media needed to cause the processor of the computer to execute the aforementioned functions should be referenced at any location (address) of the internal or external memory of the computer .

In addition, when a processor of a computer needs to communicate with any other computer or server, etc., to perform the above-described functions, the code may be stored in a computer's communication module (e.g., a wired and / ) May be used to further include communication related codes such as how to communicate with any other computer or server in the remote, and what information or media should be transmitted or received during communication.

The functional program for implementing the present invention and the related code and code segment may be implemented by programmers of the technical field of the present invention in consideration of the system environment of the computer that reads the recording medium and executes the program, Or may be easily modified or modified by the user.

Examples of the computer-readable recording medium on which the above-described program is recorded include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical media storage, and the like.

Also, the computer-readable recording medium on which the above-described program is recorded may be distributed to a computer system connected via a network so that computer-readable codes can be stored and executed in a distributed manner. In this case, any of at least one of the plurality of distributed computers may execute some of the functions presented above and transmit the result of the execution to at least one of the other distributed computers, and transmit the result The receiving computer may also perform some of the functions described above and provide the results to other distributed computers as well.

In particular, a computer-readable recording medium that records an application that is a program for executing a DLL rootkit detection method for hacking according to each embodiment of the present invention may be associated with an application store server, an application, or a corresponding service. It may be a storage medium (eg, a hard disk, etc.) included in an application provider server such as a web server or the application providing server itself.

A computer capable of reading a recording medium recording an application which is a program for executing a DLL rootkit detection method for hacking according to each embodiment of the present invention is not only a general PC such as a general desktop or a laptop, but also a smart phone or a tablet PC. It may include mobile terminals, such as PDA (Personal Digital Assistants) and mobile communication terminal, as well as to be interpreted as all computing devices (Computing).

In addition, a computer capable of reading a recording medium recording an application which is a program for executing a DLL rootkit detection method for hacking according to an embodiment of the present invention is a smart phone, a tablet PC, a personal digital assistant (PDA), a mobile communication terminal, or the like. In the case of a mobile terminal, the application may be downloaded from the application providing server to a general PC and installed on the mobile terminal through a synchronization program.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. That is, within the scope of the present invention, all of the components may be selectively coupled to at least one. In addition, although all of the components may be implemented as one independent hardware, some or all of the components may be selectively combined to perform a part or all of the functions in one or a plurality of hardware. As shown in FIG. Codes and code segments constituting the computer program may be easily inferred by those skilled in the art. Such a computer program can be stored in a computer-readable storage medium, readable and executed by a computer, thereby realizing an embodiment of the present invention. As a storage medium of the computer program, a magnetic recording medium, an optical recording medium, or the like can be included.

It is also to be understood that the terms such as " comprises, "" comprising," or "having ", as used herein, mean that a component can be implanted unless specifically stated to the contrary. But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used terms, such as predefined terms, should be interpreted to be consistent with the contextual meanings of the related art, and are not to be construed as ideal or overly formal, unless expressly defined to the contrary.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be interpreted by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present invention.

Claims (23)

A device that detects a DLL (Dynamic Linking Library) rootkit,
Collecting the first DLL list as a list of DLLs determined to be running in the user terminal;
If reading of any one of memories corresponding to at least one DLL using the address variable value received from the counter succeeds, the code value of a predetermined area among the code values stored in the read memory is set to the preset first code; Determining whether or not a match;
If it is determined that a value of a predetermined region among the values stored in the read memory matches the preset first code, determining whether the DLL information corresponding to the read memory exists in the first DLL list. ; And
If it is determined that the DLL information corresponding to the read memory does not exist in the first DLL list, adding the DLL information corresponding to the read memory to the second DLL list as a list of DLLs for a rootkit; DLL rootkit detection method for hacking comprising a. Claim 2 has been abandoned due to the setting registration fee. The method of claim 1,
Determining whether or not matching with the first predetermined code,
Receiving the address variable value from the counter;
Comparing the received address variable value with memory execution information to determine whether a memory having the received address variable value as a memory address exists; And
And determining a memory having the received address variable value as a memory address as the read memory when the memory having the received address variable value as a memory address exists. Rootkit detection method. The method of claim 1,
Determining whether or not the first DLL list is present,
Searching for a file matching the read memory; And
Determining whether the DLL information of the searched file exists in the first DLL list. The method of claim 3,
And when a search for a file matching the read memory fails, adding a thread corresponding to the read memory to the first thread list as a list of threads for a rootkit. How to detect DLL rootkits for hacking. The method of claim 3,
Adding to the second DLL list,
The DLL rootkit detection method for hacking, if the DLL information of the searched file does not exist in the first DLL list, adds the DLL information of the searched file to the second DLL list. The method of claim 1,
Determining whether or not matching with the first predetermined code,
Detecting a DLL rootkit for hacking, wherein among the code values stored in the read memory, it is determined whether a code value classified into a header area according to the structure of the read memory matches the predetermined first code. Way. The method according to claim 6,
The predetermined first code is "MZ" as a header code value set in an executable file. Claim 8 was abandoned when the registration fee was paid. The method of claim 1,
Determining whether or not matching with the first predetermined code,
When the value of the address variable is equal to or less than the predetermined threshold variable value, attempting to read any one of the memory corresponding to the at least one DLL using the address variable value, characterized in that How to detect DLL rootkits for hacking. Claim 9 has been abandoned due to the setting registration fee. 9. The method of claim 8,
Determining whether or not matching with the first predetermined code,
Detecting a DLL rootkit for hacking, if the address variable value is larger than a predetermined threshold variable value, attempting to read any one of memories corresponding to the at least one DLL using the address variable value is stopped. Way. Claim 10 has been abandoned due to the setting registration fee. The method of claim 1,
After adding to the second DLL list,
And updating the address variable value by adding a predetermined unit memory address change value to the address variable value stored in the counter. Claim 11 was abandoned when the registration fee was paid. The method of claim 10,
After updating the address variable value,
When the updated address variable value is equal to or smaller than a predetermined threshold variable value, when a reading of any one of memories corresponding to at least one DLL using the updated address variable value is successful, the And determining whether a code value of a predetermined region among the code values stored in the read memory coincides with the preset first code. Claim 12 is abandoned in setting registration fee. The method of claim 1,
After determining whether the DLL information corresponding to the read memory exists in the first DLL list,
If it is determined that DLL information corresponding to the read memory exists in the first DLL list, updating the address variable value by adding a preset unit memory address change value to the address variable value stored in the counter; And
When the updated address variable value is equal to or smaller than a predetermined threshold variable value, when a reading of any one of memories corresponding to at least one DLL using the updated address variable value is successful, the And determining whether a code value of a predetermined region among the code values stored in the read memory is identical to the preset first code. Claim 13 has been abandoned due to the set registration fee. The method of claim 1,
Collecting the first DLL list,
Hacking, characterized in that the first API list provided by the operating system of the user terminal, the first DLL list is collected using a first function which is a function of extracting a list of DLLs determined to be running in the user terminal. To detect a DLL rootkit. A list collecting unit collecting the first DLL list as a list of DLLs determined to be running in the user terminal;
A memory reading unit for reading a memory by using an address variable value received from a counter;
When a reading of the memory reading unit is successful and any one of memories corresponding to at least one DLL is read, whether a code value of a predetermined region among the code values stored in the reading memory matches the predetermined first code A file search unit for determining whether to determine whether or not a value of a predetermined region among the values stored in the read memory matches a preset first code, the file search unit extracting DLL information corresponding to the read memory; And
It is determined whether the extracted DLL information exists in the first DLL list, and when it is determined that the DLL information corresponding to the read memory does not exist in the first DLL list, the extracted DLL information corresponds to the read memory. And a rootkit list manager for adding DLL information to the second DLL list as a list of DLLs for the rootkit. Claim 15 is abandoned in the setting registration fee payment. 15. The method of claim 14,
The memory reading unit,
Comparing the address variable value received from the counter with memory execution information, and if there is a memory having the received address variable value as a memory address, the read memory having the memory having the received address variable value as a memory address DLL rootkit detection device for hacking, characterized in that determined by. Claim 16 has been abandoned due to the setting registration fee. 15. The method of claim 14,
The file search unit,
And detecting a file matching the read memory to determine whether a file matching the read memory is found. Claim 17 has been abandoned due to the setting registration fee. 17. The method of claim 16,
The rootkit list management unit,
If a search for a file matching the read memory fails, a DLL rootkit for hacking is added to the first thread list as a thread list corresponding to the read memory as a list of threads for the rootkit. Sensing device. Claim 18 has been abandoned due to the setting registration fee. 15. The method of claim 14,
The file search unit,
Detecting a DLL rootkit for hacking among the code values stored in the read memory determines whether a code value classified into a header area according to the structure of the read memory matches the predetermined first code. Device. Claim 19 is abandoned in setting registration fee. 19. The method of claim 18,
The predetermined first code is a DLL rootkit detection device for hacking, characterized in that "MZ" as a header code value set in an executable file. Claim 20 has been abandoned due to the setting registration fee. 15. The method of claim 14,
The memory reading unit,
When the value of the address variable is equal to or less than the predetermined threshold variable value, attempting to read any one of the memory corresponding to the at least one DLL using the address variable value, characterized in that DLL rootkit detection device for hacking. Claim 21 has been abandoned due to the setting registration fee. 15. The method of claim 14,
The above-
The rootkit list manager adds the DLL information corresponding to the read memory to the second DLL list as a list of DLLs for the rootkit, or determines that the DLL information corresponding to the read memory exists in the first DLL list. And updating the address variable value by adding a predetermined unit memory address change value to the address variable value stored in the counter. Claim 22 is abandoned in setting registration fee. 22. The method of claim 21,
The memory reading unit,
And attempting to read the memory repeatedly by using the updated address variable value. A device that detects a DLL (Dynamic Linking Library) rootkit,
Collecting the first DLL list as a list of DLLs determined to be running in the user terminal;
When a reading of any one of memories corresponding to at least one DLL using the address variable value received from the counter succeeds, the code value of a predetermined area among the code values stored in the read memory is set to the preset first code. Determining whether or not a match;
If it is determined that a value of a predetermined region among the values stored in the read memory matches the preset first code, determining whether the DLL information corresponding to the read memory exists in the first DLL list. ; And
If it is determined that the DLL information corresponding to the read memory does not exist in the first DLL list, adding the DLL information corresponding to the read memory to the second DLL list as a list of DLLs for a rootkit; A computer-readable recording medium having recorded thereon a program for implementing a method for detecting a DLL rootkit for hacking comprising a.

Images