KR20100100488A - Method for scanning a fabrication or memory and device thereof - Google Patents

Abstract

PURPOSE: A method for sensing whether a memory is manipulated and a device using the same are provided to determine whether a code of an execution file loaded in a memory is manipulated during execution of a file to be protected. CONSTITUTION: An original CRC(Cyclic Redundancy Check) reading module(112) extracts an original confirmation code which is inserted into a file to be protected. A memory CRC generating module(114) stores data of a memory as the second processing target data. The memory CRC generating module processes the second processing target data by a preset period. The memory CRC generating module generates a memory confirmation code. A CRC comparing module(116) compares the generated memory confirmation code with the extracted original confirmation code.

Description

Method for detecting presence of memory operation and device using the same {Method for scanning a fabrication or memory and device about}

The present invention relates to a security method of a memory through a CRC code, and more particularly, after the execution file is executed and loaded into the memory, detecting the presence or absence of a memory operation for determining whether the loaded memory has been manipulated. The invention relates to a method.

Recently, as a tool for hacking a program such as a game, when the executable program is executed, a hacking tool for modifying the code located in the memory of the client where the executable file is operated to operate differently from the original operation of the game. A lot is spreading. This type of hack not only has the same effect as the crack of the executable file itself, but also can be changed dynamically in the middle of the game, thereby causing substantially more damage than the crack of the executable program itself.

The present invention has been made in view of the above circumstances, and an object of the present invention is to detect a memory operation for determining whether a code of an executable file loaded in a memory has been manipulated while a file to be protected is executed. have.

According to an aspect of the present invention, there is provided a method of detecting an operation of a memory, the method including generating a source identification code using a CRC algorithm on a file to be protected; Storing the generated original identification code in the file to be protected; Loading the protected file into which the original identification code is inserted, into a memory; Generating a memory check code for the code on the memory loaded on the memory using the CRC algorithm according to a predetermined period; And comparing the original identification code with the memory identification code.

It is also preferable that the file to be protected is an executable file, and the code in memory is a process.

And generating the original identification code only by generating the original identification code for the code section of the protected file.

In the generating of the memory check code, it is preferable to generate the memory check code only for the code section among the codes on the memory loaded in the memory.

The generating of the original verification code may include generating the original verification code by a predetermined data block unit among the protected files.

In the generating of the memory check code, it is preferable to generate the memory check code in units of the data block among the code on the memory loaded in the memory.

The data block unit is preferably a page unit managed by an operating system.

The method may further include monitoring dirty bit information in real time at a kernel level, and generating a memory check code for the page indicated by the changed dirty bit when specific dirty bit information is changed. Preferably, the original confirmation code is compared with the memory confirmation code.

Hooking an attribute change API function, which is an API function that changes a memory attribute; And if it is detected that the property of the memory is changed by using the property change API function, searching for a page whose property is changed by referring to an argument of the property change API function. It is preferable to generate a code and compare the original confirmation code with the memory confirmation code.

In addition, the property change API function is preferably a VirtualProtect function of Kernel32.dll.

And storing the generated original CRC in the protected file.

And checking the remaining area of all sections of the protected file. The original check code may be stored in the remaining area of the section where the first remaining area is found.

On the other hand, the memory operation presence detection device according to another embodiment of the present invention is a memory operation presence detection device for performing a function to detect whether the operation has been performed after the protection target file is loaded into the memory, Original CRC reading module for reading the stored original confirmation code; A memory CRC generation module for generating a memory verification code by using a CRC algorithm predetermined according to a predetermined period for the code on memory after the file to be protected is loaded on the memory; And a CRC comparison module for comparing the memory check code with the original check code.

And an original CRC insertion module for generating the original verification code using the CRC algorithm for the protected file and storing the generated original CRC in the protected file.

In addition, the original CRC reading module, the memory CRC generating module and the CRC comparison module are preferably loaded into the memory at the same time as the protected file is loaded on the memory.

The original CRC insertion module generates an original verification code only for a code section of the protected file.

The memory CRC generation module preferably generates a memory confirmation code for only a code section among the codes on the memory loaded in the memory.

In addition, the original CRC insertion module is characterized in that for generating the original confirmation code in the unit of the predetermined data block of the protected file,

The memory CRC generation module preferably generates a memory confirmation code in units of the data block among codes on the memory loaded in the memory.

The data block unit is preferably a page unit managed by an operating system.

It also includes a dirty bit detection module that monitors dirty bit information in real time at the kernel level.

The memory CRC generation module preferably generates a memory confirmation code for the page indicated by the changed dirty bit when the dirty bit is changed.

After hooking the property change API function, which is an API function for changing the memory property, and detecting that the property of the memory is changed using the property change API function, the page whose property is changed by referring to the argument of the property change API function Further includes a change page search module to search for,

The memory CRC generation module preferably generates a memory confirmation code for the page whose attribute is changed.

On the other hand, in a storage medium according to another embodiment of the present invention, when a file to be protected is loaded on a memory, a memory check code is generated by using the CRC algorithm according to a predetermined period with respect to the code on the memory loaded on the memory. Generating a; Reading the original identification code pre-stored in the protected file; And a program capable of performing the step of comparing the original identification code with the memory identification code.

On the other hand, the storage medium according to another embodiment of the present invention includes the steps of generating an original verification code for the protected file, using a CRC algorithm;

A program capable of performing the step of storing the generated original CRC in the protected file is stored.

As described in detail above, using the method for detecting the presence or absence of a memory operation according to the present invention, since the operation to be immediately known in the memory after the file to be protected on the memory is loaded, the memory operation attempt from a third party The effect is that protection is possible.

In addition, it checks only the necessary part of the file, so there is no big impact on the performance of the system. Also, the page is searched first and the page is suspected at the kernel and application level.

Cyclic redundancy check (CRC) refers to a method of determining a check value for checking whether there is an error in transmitted data when transmitting data through a network.

Before transmitting data, CRC value is calculated and attached to the data according to the value of the given data, and after the data transmission is over, the CRC value is calculated again with the received data value. Then, the two values are compared, and if the two values are different, it can be seen that an error is transmitted due to noise or the like during the data transmission process.

The present invention further improves and applies the concept of CRC algorithm, and utilizes the file stored in the actual hard disk and whether the file is forged by a hacker or the like after the file is executed and loaded into the memory.

1 is a block diagram of a memory operation presence detection device according to an embodiment of the present invention.

Memory operation detection device according to an embodiment of the present invention is largely composed of a detection function performing module 110 and the original CRC insertion module 120.

First, the original CRC insertion module 120 generates an original CRC code for a specific protected target file using a CRC algorithm, and stores the generated original CRC code in the protected target file.

In addition, the sensing function performing module 110 is composed of an original CRC reading module 112, a memory CRC generating module 114, and a CRC comparison module 116.

The original CRC reading module 112 reads the original CRC code generated by the original CRC insertion module 120 and inserted into the original file.

The memory CRC generation module 114 performs a function of generating a memory CRC code by using a CRC algorithm specified according to a predetermined period for the code on memory after the protected file is loaded on the memory. Here, the original CRC insertion module 120 uses the same algorithm as the CRC algorithm used when generating the original CRC code.

The CRC comparison module 116 generates and stores the original CRC code generated and stored by the original CRC insertion module 120 before the protected file is loaded into the memory, and the memory CRC generation module 114 after the protected file is loaded into the memory. Compare the memory CRC codes generated in the cycle specified by

If the original CRC code and the memory CRC code do not match, it means that a change has occurred since the protected file has been loaded into the memory.

2 is a diagram illustrating an example of a file area for explaining the present invention.

For example, suppose the protected file is an executable called GAME.EXE. There are three main areas for these executables. There is a code area 210 that contains the source code of the actual program, a data area 220 that is an area related to data required for driving the program, and a resource area 230 that is related to a resource.

When the executable file is executed, the file is mapped into memory and loaded. Thereafter, as the executable file is driven, values of a data region or a resource region mapped to a memory may be changed at any time. However, since the code area written by the actual programmer is mapped to the memory as it is, the code area in the file area and the code area loaded in the memory must match. If the code in the code area in the file (ie before it is loaded into memory) and the code in the code area after being loaded into memory are inconsistent with each other, then the memory has been manipulated by a hacker or the like. Therefore, the present invention applies particularly to codes in the code domain.

Instead of generating and comparing the memory CRC codes for the entire code area, the memory CRC codes are generated and compared by dividing by page, for example, by a predetermined size. Recently, as the program has become larger, the execution file also often exceeds several megabytes. Therefore, if the memory CRC code is generated for the entire execution file and compared with the original stored CRC code, It also affects performance. After dividing the code area into page units (approximately 4 kilobytes when the operating system is Windows), memory CRC codes are generated and compared for each page.

This process will be described later in more detail with reference to FIG. 3.

3 is a flowchart used to explain a method of detecting the presence or absence of a memory operation according to an exemplary embodiment of the present invention.

The following is an example of an executable file such as an EXE file as a file to be protected. Of course, the present invention is not only applicable to the executable file, but also to a file such as a DLL.

First, the original CRC code is generated for the executable file selected as the protection target file (S310). In this case, the original CRC code is created by applying the CRC algorithm to the code area in the executable file.

At this time, it is possible to create one original CRC code for the entire code area, but usually one original CRC code is created for each predetermined block unit or page unit.

Then, the original CRC code created is inserted into the executable file (S320). When inserting, it is possible to insert additionally at the end of the file, or it is possible to check the code area, the data area, and the report area in order to check whether there is an empty space in each area, and then insert into the empty space.

The executable file into which the original CRC code is inserted is loaded into the memory (S330). Typically, when the executable is run on a real system, the file is loaded into memory.

At this time, the sensing function performing module is also loaded into the memory (S340). The detection function execution module 110, which consists of the original CRC reading module 112, the memory CRC generation module 114, and the CRC comparison module 116, is generally distributed in the form of a DLL. Hereinafter, this is briefly referred to as a detection function execution DLL. do. Preferably, the sensing function execution DLL is set to execute the protected executable file at the same time. That is, the detection function execution DLL is preferably statically loaded from the executed executable file, that is, the protection function execution DLL is executed at the same time as the execution of the detection function execution DLL.

This is because most hacking tools use a technique of injecting malicious code into the protected process after hooking the stub-code function group created by the compiler when executing the target executable file to determine the time after packing. Accordingly, code information CRC of the corresponding function of Kernel32.dll is generated and managed in advance at the DLL_PROCESS_ATTACH point which is called before the execution time of the corresponding function.

If, in the protected executable, the detection function execution DLL is dynamically loaded, that is, the detection function execution module is loaded after executing the execution of the protection target executable, and a memory is manipulated by a hacking tool in between. In this case, an undetectable situation may occur.

When the detection function execution DLL starts, the memory CRC code corresponding to the code area of the memory code (codes executed in the execution file and mapped to the memory, hereinafter referred to as memory code) is periodically stored in a separate thread. It generates (S350). Of course, the algorithm for generating the memory CRC code at this time should use the same algorithm as the algorithm for generating the original CRC code in step S310.

Executable files stored in a storage medium such as a hard disk are executed and loaded into the memory so that the codes on the memory are mapped to each other and are identical. Of course, the data area may vary depending on the execution. However, the data in the code area, that is, the data in the code area of the executable file and the code area in the code in memory, must be the same. Therefore, the original CRC code generated from the data in the code area of the executable file and the memory CRC code generated from the later memory code must be identical.

Thereafter, the original CRC code of the protected process stored in advance and the memory CRC code are compared (S360).

If it matches (S360-Y), since the contents of the portion where the memory CRC code is generated are not manipulated, steps S350 and S360 are performed again for the next page.

As described above, performing steps S350 and S360 for the entire code region of the process may adversely affect performance on the system. Therefore, the memory CRC code is generated for each page, and the memory CRC code is compared with the original stored CRC code to determine whether the corresponding page part is manipulated.

On the contrary, if there is no coincidence (S360-N), since there is an operation in the corresponding part, the memory operation contents are notified (S380).

On the other hand, after dividing the code area into page units for system performance, steps S350 and S360 are performed for each page.

Accordingly, when the number of pages is large, for example, when 100 pages exist, the 100th page can be inspected only after the steps S350 and S360 are performed for about 100 times. To compensate for this, the following two algorithms can be further utilized.

First of all, you can refer to the dirty bit information supported by the operating system. In other words, at the kernel level of the operating system, whenever a memory change occurs, there is dirty bit information that generates the changed part in units of pages. Therefore, if there is a dirty bit change while referring to the dirty bit, and if the page indicated by the changed dirty bit is a page in the area monitored by the present invention, the dirty bit does not move to the next page from step S370 to step S350 again, Go directly to the page pointed to by performing steps S350 and S360.

The next method is to use APIs to change memory attributes at the application level of the operating system. In general, the code area in memory has the property of Read Only. Therefore, in order for a hacker to manipulate the contents of the code area on the memory, it is necessary to change the write property of the code area. Therefore, by hooking an API function that changes the memory property, a hacker can find out which page property is changed by referring to the argument of the function when using the API function.

If the page whose property is changed is a page within the area monitored by the present invention, if the property is changed to the page where the property is changed and the steps S350 and S360 are performed without returning to step S350, the process returns to step S350. do.

Meanwhile, in the present embodiment, the original CRC code and the memory CRC code are compared in step S360. In this case, the original CRC code may be an original CRC code existing in the memory. It is also possible. That is, the original CRC code is stored in the executable file itself in step S320, and then exists in the memory code loaded in the memory in step S330. When loaded into memory, the original CRC code is mapped as it is, so any one may be used.

Recently, however, the executable files are often packed at the distribution stage. If the executable files are packed after the S320 step, the original CRC code in the memory code is used.

So far, the method of detecting the presence or absence of a memory operation according to an exemplary embodiment has been described.

In the present embodiment, an executable file is taken as an example, but this is only an example. Therefore, besides the executable file, a file such as a DLL can be applied as a file to be protected.

In addition, in the present embodiment, a CRC value is cited as an example of the code value for the check, but is not limited thereto.

Therefore, in addition to the checksum data, hash value, various instructions, and unique values including instructions and operands, the present invention is an algorithm that can determine whether the corresponding data block has been changed. Of course, it is possible to apply.

In addition, although the preferred embodiment of the present invention has been shown and described above, the present invention is not limited to the specific embodiments described above, but the technical field to which the invention belongs without departing from the spirit of the invention claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or the prospect of the present invention.

1 is a block diagram of a memory operation presence detection device according to an embodiment of the present invention;

2 is a view showing an example of a file area for explaining the present invention; and

3 is a flowchart used to explain a method of detecting the presence or absence of a memory operation according to an exemplary embodiment of the present invention.

Explanation of symbols on the main parts of the drawings

100: operation presence detection device 110: detection function performance module

112: original CRC reading module 114: memory CRC generation module

116: CRC comparison module 120: original CRC insertion module

Claims (19)

An original identification code generation step of generating the original identification code by processing the first processing target data using the data included in the file to be protected as the first processing target data; An original identification code insertion step of inserting the generated original identification code into the protected file; A protected file loading step in which the protected file to which the original confirmation code is inserted is loaded onto a memory; A memory confirmation code generating step of generating a memory confirmation code by processing the second processing target data at predetermined intervals using the data on the memory loaded with the protection target file as a second processing target data; And And a verification code comparing step of comparing the original identification code with the memory identification code. The method of claim 1 The protected file is an executable file, The original verification code generation step Characterized in that to generate the original verification code by processing the first processing target data using a CRC algorithm, The memory verification code generation step And generating a memory confirmation code by processing the second processing target data using the same algorithm as the CRC algorithm used in the original confirmation code generation step. The method of claim 1 The original verification code generation step Extracting a code section from the protected file, and using the data included in the extracted code section as first processing data, processing the first processing data to generate an original identification code; The memory verification code generation step Extracting a code section from the data on the memory, and using the data included in the extracted code section as second processing target data, processing the second processing target data at predetermined intervals to generate a memory verification code; To detect the presence of memory operations. The method of claim 1 The original verification code generation step Characterizing the first processing target data in a predetermined block unit to generate an original confirmation code, The memory verification code generation step And processing the second processing target data in the same unit as the predetermined block unit of the original confirmation code generation step to generate a memory confirmation code. The method of claim 4 The predetermined block unit is Method for detecting the presence of memory operation, characterized in that the page unit managed by the operating system. The method of claim 5 A dirty bit monitoring step of monitoring dirty bit information in real time at a kernel level; A change page extraction step of extracting a page corresponding to the changed dirty bit when specific dirty bit information is changed; And And checking whether the extracted page includes the second processing target data. The memory verification code generation step, And if the extracted page includes the second processing target data, generating a memory check code for the data included in the extracted page. The method of claim 5 Hooking a hooking property change API function which is an API function to change a memory property; And And a change page extraction step of extracting a page whose property is changed by referring to an argument of the property change API function when it is detected that the property of the memory is changed by using the property change API function. The memory verification code generation step And if the extracted page includes the second processing target data, generating a memory check code for the data included in the extracted page. The method of claim 7, The attribute change API function is Kernel32.dll is a VirtualProtect function that detects the presence of memory manipulations. The method of claim 1 Inserting the original confirmation code is A non-occupied area detecting step of detecting a non-occupied area not occupied by data among the areas of each of the plurality of sections included in the protected file; And And inserting the original identification code into the detected non-occupied area. In the memory operation detection device that detects whether the operation has been performed after the protected file is loaded in the memory, An original CRC reading module for extracting an original confirmation code previously inserted into the protected file; After the file to be protected is loaded on the memory, the second object to be processed is processed at predetermined intervals using the data on the memory to which the file to be protected is loaded into the memory. A memory CRC generation module for generating; And And a CRC comparison module for comparing the generated memory check code with the extracted original check code. The method of claim 10 By using the data included in the protected object file as the first processing target data, the first processing target data is processed to generate an original confirmation code, And an original CRC insertion module for inserting the generated original identification code into the protection target file. The method of claim 10 And the original CRC reading module, the memory CRC generating module, and the CRC comparing module are loaded into the memory at the same time when the protected file is loaded into the memory. The method of claim 11, The original CRC insertion module Extracting a code section from the file to be protected, and using the data included in the extracted code section as first processing target data, processing the first processing target data to generate an original verification code, The memory CRC generation module Extracting a code section from the data on the memory, and using the data included in the extracted code section as second processing target data, processing the second processing target data at predetermined intervals to generate a memory verification code; Memory operation presence sensing device. The method of claim 11, The original CRC insertion module Characterizing the first processing target data in a predetermined block unit to generate an original confirmation code, The memory CRC generation module And a memory operation code generating unit for generating a memory confirmation code by processing the second processing target data in the same unit as the predetermined block unit of the original confirmation code generation step. The method of claim 14, The data block unit is Memory operation presence detection device, characterized in that the page unit managed by the operating system. The method of claim 15 It further includes a dirty bit detection module for monitoring dirty bit information in real time at the kernel level. The memory CRC generation module When specific dirty-bit information is changed, the page corresponding to the changed dirty-bit is extracted, and when the extracted page includes the second processing target data, the extracted And a memory operation code detecting device for generating a memory check code for the data contained in the page. The method of claim 15 After hooking an attribute change API function, which is an API function for changing a memory attribute, and detecting that an attribute of a memory is changed using the attribute change API function, the page whose attribute is changed is referred to by referring to the argument of the attribute change API function. It further includes a change page search module to extract, The memory CRC generation module And a memory check code for generating data included in the page whose attribute is changed. When the file to be protected is loaded on the memory, the data on the memory loaded into the memory as the data to be processed is processed, and the memory verification code is processed by processing the data to be processed in predetermined block units at predetermined intervals. Generating a memory check code; Extracting an original confirmation code pre-inserted into the protected file; And A storage medium storing a program for performing the step of comparing the extracted original identification code with the generated memory identification code. A protected file selecting step of selecting a protected file including a plurality of sections each having a storage area; A code section extracting step of extracting a code section among the plurality of sections; An original identification code generation step of generating an original identification code by processing the data occupying the storage area included in the code section extracted in the code section extraction step as a processing target data in a predetermined block unit; A non-occupied storage area detecting step of detecting an unoccupied storage area not occupied by data among the storage areas of each of the plurality of sections included in the protected file; And And a program storing a program for inserting the original confirmation code into the detected non-occupied storage area.

Images