KR20170079961A - Method for detectiing similarity of software and apparatus therefor - Google Patents

Abstract

To a software similarity measurement method and apparatus that can be used to detect software theft. The disclosed software similarity measuring method comprises the steps of: confirming a packing state through a dynamic analysis for a first software, releasing an execution compression in the case of a packing state, and analyzing the analysis result from a binary file of the first software Extracting a bus mark; comparing the extracted bus mark with a bus mark of the second software to calculate a degree of similarity; Dynamic analysis can be applied to measure the similarity of encrypted or packed software, and static analysis is applied to avoid the limitations of similarity measurement. In addition, the degree of similarity of software can be measured even when the number of system call functions is small or is not suitable for defining as feature information.

Description

[0001] METHOD FOR DETECTING SIMILARITY OF SOFTWARE AND APPARATUS THEREFOR [0002]

And more particularly, to a software similarity measurement method and apparatus that can be used to detect software theft.

As software development becomes more active, software similarity measurement, which can be used to detect software theft, is also becoming very important.

As one example of the prior art, there is a method of statistically or dynamically extracting a birthmark from a measurement target software suspected of being stolen, and then comparing the birthmark with a bus mark of the comparison target software to calculate the similarity. The software bus mark refers to unique feature information of the software, and can be used to compare the binary itself to judge whether or not it is stolen.

However, there is a problem that it is difficult to measure the degree of similarity with respect to the packed software in the similarity measurement method of statically extracting the bus mark. There is a problem that there is a limit to the degree of similarity measurement other than the execution path of the software.

As another example of the prior art, there is a method of defining a specific action of software as feature information.

However, since this behavior-based detection technology may not have a system call function to be defined as feature information when the number of system call functions provided by the operating system is small or is not suitable for defining the feature information, There is an inadequate problem.

Korean Patent Publication No. 2014-0035608, published on March 24, 2014.

The present invention provides a software similarity measuring apparatus and method for measuring similarity of software through dynamic analysis and static analysis.

The method for measuring the degree of software similarity according to the first aspect may include a step of checking the status of the first software through dynamic analysis and then releasing encryption or execution decompression. The method may further include extracting a bus mark from the binary file of the first software whose encryption or execution compression is released through static analysis. The step of comparing the extracted bus mark with the bus mark of the second software may be used to calculate the degree of similarity.

The software similarity measuring apparatus according to the second aspect may include a dynamic analyzing unit, a static analyzing unit, and a similarity calculating unit. The dynamic analysis unit can confirm the state of the first software through dynamic analysis, and then release the encryption or execution decompression. The static analysis unit may extract the bus mark through static analysis from the binary file of the first software whose encryption or execution decompression is released. The similarity calculating unit may calculate the similarity by comparing the extracted bus mark with the bus mark of the second software.

According to the embodiment, the degree of similarity with the software to be compared is calculated through dynamic analysis and static analysis of the software to be measured, which is suspected of theft. Dynamic analysis can be used to measure similarity to packed or encrypted software, and static analysis is applied to avoid the limitations of similarity measurement. In addition, the degree of similarity of software can be measured even when the number of system call functions is small or is not suitable for defining as feature information.

Furthermore, it is possible to consider the effect of the compiler type and the compile optimization option. In this case, the similarity of the software can be measured even when the bus mark is changed due to the influence of the compilation.

1 is a block diagram of a software similarity measuring apparatus according to an embodiment of the present invention.
2 is a flowchart illustrating a method of measuring the degree of software similarity according to an exemplary embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention and the manner of achieving them will become apparent with reference to the embodiments described in detail below with reference to the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. To fully disclose the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims.

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. The following terms are defined in consideration of the functions in the embodiments of the present invention, which may vary depending on the intention of the user, the intention or the custom of the operator. Therefore, the definition should be based on the contents throughout this specification.

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

1 is a block diagram of a software similarity measuring apparatus according to an embodiment of the present invention.

As shown, the software similarity measuring apparatus 100 includes a dynamic analyzer 110, a static analyzer 120, and a similarity calculator 130.

The dynamic analysis unit 110 checks the state of the software to be measured through dynamic analysis, and then releases the execution compression when it is in a packing state, and decrypts it when it is in an encryption state. The dynamic analysis unit 110 may include an input interface through which the software to be measured can be input. For example, the input interface may include an external interface through which the measurement target software is input in the form of a data file, a communication module through which the measurement target software is received, a user interface through which a user can input measurement target software, and the like.

The static analysis unit 120 extracts the bus mark from the binary file of the measurement target software whose encryption or execution compression is released through static analysis.

The static analyzer 120 may extract a compiler type of the software to be measured using a static tool, and then compile the compiler into an extracted compiler type to generate a binary file. Here, it is possible to generate a plurality of binary files by compiling each application option.

In addition, the static analysis unit 120 may extract at least one of an opcode, an operation code, an API (Application Programming Interface) calling frequency, an API reference order, a control flow graph, or a call graph as a bus mark .

Also, the static analysis unit 120 can extract an operation code on a function unit basis from a binary file. Here, when the function is called, the operation code can be extracted except for the API, and the API can be determined through the IAT (Import Address Table).

Also, in the case where the source code of the comparison target software exists, the static analysis unit 120 generates a source course by decompiling the measurement target software whose encryption or decryption is canceled by the dynamic analysis unit 110 . Here, the source code can be generated through a disassembler such as an IDA (Interactive Disassembler) Pro.

The similarity calculating unit 130 compares the bus mark extracted by the static analyzing unit 120 with the bus mark of the comparison target software to calculate the similarity. Alternatively, the similarity calculation unit 130 compares the source code generated from the measurement target software with the source code of the comparison target software, and calculates the similarity.

The similarity calculation unit 130 may include an output interface through which the calculated similarity value can be output. For example, the output interface may include an external interface for outputting the calculated similarity value in the form of a data file, a communication module for transmitting the calculated similarity value, and a display window for outputting the calculated similarity value in the form of screen data.

2 is a flowchart illustrating a method of measuring the degree of software similarity according to an exemplary embodiment of the present invention.

As shown in the figure, the software similarity measuring method includes steps (S201 to S205) of confirming the state of the software to be measured by dynamic analysis, releasing the execution compression when the state is a packing state, . Here, as a dynamic tool, a packing state or an unpacked state can be confirmed with respect to a measurement target software by using a DBI tool (Dynamic Binary Instrumentation tool). The DBI tools are available from Intel's Pin Tool, DynamoRIO, and Linux-based Valgrind. These DBI tools can analyze or track executable programs while running packed or encrypted computer programs.

The software similarity measuring method further includes a step (S207 to S213) of extracting a bus mark from a binary file of the execution target decompressed software through static analysis. To do this, you can use a static tool to extract the compiler type of the target software and then compile it into the extracted compiler type to generate a binary file. Here, it is possible to generate a plurality of binary files by compiling each application option. At least one of the operation code, API call frequency, API reference order, control flow graph, or call graph can be extracted as a bus mark. In addition, an operation code can be extracted from a binary file on the basis of a function unit. Here, when calling the function, the operation code can be extracted except for the API, and it is possible to judge whether the API is through the IAT.

In addition, the software similarity measuring method further includes steps (S221, S223, S231) for determining whether the source code and the binary file exist by confirming the status of the comparison target software.

And, the software similarity measuring method further includes a step (S225) of generating a source course through decompilation of the measurement target software whose encryption or execution decompression is released when the source code of the comparison target software exists.

The software similarity measuring method further includes a step (S233) of generating a plurality of binary files by compiling the binary files of the comparison target software according to the applicable options if the binary files of the comparison target software do not exist.

In addition, the software similarity measuring method further includes a step (S235) of extracting a bus mark from the binary file of the comparison target software through static analysis. To do this, you can create multiple binary files by compiling each application option using a static tool. At least one of the operation code, API call frequency, API reference order, control flow graph, or call graph can be extracted as a bus mark. In addition, an operation code can be extracted from a binary file on the basis of a function unit. Here, when calling the function, the operation code can be extracted except for the API, and it is possible to judge whether the API is through the IAT.

Next, the software similarity measuring method further includes a step S240 of calculating the similarity by comparing the software to be measured and the comparison target software. Here, the similarity can be calculated by comparing the bus mark extracted from the software to be measured with the bus mark of the comparison target software. For example, the degree of similarity of bus marks is calculated using a similarity comparison algorithm such as k-gram, Jaccard coefficient, LCS (Longest Common Subsequence), CS (Cosine Similarity), GCS (Greatest Common Subsequence) . Alternatively, the similarity can be calculated by comparing the source code of the software to be measured and the source code of the comparison target software. For example, the degree of similarity of the source code can be calculated using a similarity comparison algorithm such as MOSS (Measure of Software Similarity).

Hereinafter, the software similarity measuring process performed by the software similarity measuring apparatus according to the embodiment will be described in more detail with reference to FIGS. 1 and 2. FIG.

First, the dynamic analysis unit 110 confirms the state of the input measurement target software through dynamic analysis (S201), and if it is the encrypted state (S203), performs the process of deciphering and releasing (S207) In the case of the state (S205), the process of releasing the execution compression (S207) is performed.

Here, the dynamic analysis unit 110 can confirm the encryption state or the packing state of the measurement target software using the DBI tool as a dynamic tool. The DBI tools are available from Intel's Pin Tool, DynamoRIO, and Linux-based Valgrind. These DBI tools can analyze or track executable programs while running packed or encrypted computer programs.

The dynamic analyzer 110 prepares what information is to be analyzed and tracked in advance as a DLL, and then receives the software to be measured while driving the DBI tool. That is, the measurement target software is executed on the PIN tool.

For example, the dynamic analysis unit 110 can determine whether an unpacked computer program is packed with a UPX (Ultimate Packer for eXecutables) packer by using a dynamic tool. Run a dynamic tool, such as a PIN tool that can track dynamically running machine words, to determine if the stolen software is packed or unpacked. The UPX packer invokes the GetProcAddress API during uncompression, and unpacks it. Therefore, if you use the PIN tool to monitor the GetProcAddress API call, you can see when the GetProcAddress API call is made and the last called GetProcAddress API. Since the command to jump to the original entry point (OEP) is executed after the GetProcAddress API call is finished, the point at which the GetProcAddress API ends can be determined as the unpacking point.

Next, the static analysis unit 120 generates a binary file of the measurement target software using the static tool.

For this purpose, the static analysis unit 120 may extract the compiler type of the measurement target software (S209), and then compile the extracted compiler type to generate the binary file. Here, it is possible to generate a plurality of binary files (S211) by compiling for each application option. At this time, the static analysis unit 120 may use a static tool such as a GCC (GNU Compiler Collection) tool, a PEiD tool, or a DIE (Detect It Easy) tool.

For example, the GCC tool provides several options for optimization, such as '-0', '-01', '-02', '-03', '-0s', etc. Application options are available. When '-0' or '-01' is used, optimization is performed in a range where the compile time is not long, while reducing the size of an object or an executable to be created. The use of '-02' speeds up the execution time of the code, but optimizes the code so that the size does not increase much. When using '-0s', it uses all the optimizations provided by '-02', but performs optimizations except optimizations that increase the size of the code. '-03' does not care about the size of the code, only optimizes for faster execution. Then binary files are created for each optimization option such as '-0', '-01', '-02', '-03', and '-0s'.

Subsequently, the static analysis unit 120 extracts the software bus mark from the binary file identified in step S207 or the binary file generated in step S211 (S213). Here, at least one of an operation code, an API (Application Programming Interface) calling frequency, an API reference order, a control flow graph, or a call graph can be extracted as a bus mark.

For example, the static analysis unit 120 may extract an operation code on a function unit basis from a binary file. Here, when the function is called, the operation code can be extracted except for the API, and the API can be determined through the IAT (Import Address Table). The binary file generated in step S211 may differ in the structure and order of the operation code depending on the options used, and the static analysis unit 120 may extract the operation code for each generated plurality of binary files.

In the case where the bus mark of the comparison target software, that is, the computer program expected to be stolen, is not secured, the static analysis unit 120 checks the status of the comparison target software, and the source code and the binary file exist .

Here, when the source code of the comparison target software is present, the static analysis unit 120 can generate the source course of the comparison target software through decompilation of the binary file processed in step S207. Here, the source code can be generated through a disassembler such as an IDA (Interactive Disassembler) Pro.

In addition, when the binary file of the comparison target software does not exist, the static analysis unit 120 extracts the software bus mark through the static analysis.

For example, the static analysis unit 120 can generate a binary file by compiling the comparison target software, and extract the operation code from the binary file. In this case, the configuration of the binary file may vary depending on the compile option. If the binary file of the comparison target software exists, the operation code can be extracted from the binary file, and the compiler and the compile option used can be checked.

Next, the similarity calculating unit 130 compares the measurement target software with the comparison target software to calculate the similarity.

Here, the similarity calculating unit 130 compares the bus mark of the software to be measured with the bus mark of the comparison target software, calculates the similarity, and outputs the calculated similarity value (S240). For example, the similarity calculating unit 130 may calculate the similarity of bus marks using a similarity comparison algorithm such as k-gram, Jaccard coefficient, LCS, CS, GCS, SCS, The similarity degree calculating unit 130 may output the calculated similarity value in the form of screen data or in the form of a log file.

Alternatively, the similarity calculating unit 130 may compare the source code of the measurement target software generated in step S225 with the source code of the comparison target software, calculate the similarity, and output the calculated similarity value (S240). For example, the similarity calculation unit 130 may calculate the similarity of the source code using a similarity comparison algorithm such as MOSS. The similarity calculating unit 130 may output the calculated similarity value in the form of screen data or in the form of a log file.

As described so far, according to the embodiment, the degree of similarity with the software to be compared is calculated through dynamic analysis and static analysis of the software to be measured that is suspected of theft. Dynamic analysis can be applied to measure the similarity of encrypted or packed software, and static analysis is applied to avoid the limitations of similarity measurement. In addition, the degree of similarity of software can be measured even when the number of system call functions is small or is not suitable for defining as feature information.

Furthermore, you can take into account the type of compiler and its impact on compile optimization options, in which case the similarity of the software can be measured even if the bus mark is changed due to compilation impact.

Each block of the block diagrams attached hereto and combinations of steps of the flowchart diagrams may be performed by computer program instructions. These computer program instructions may be loaded into a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus so that the instructions, which may be executed by a processor of a computer or other programmable data processing apparatus, And means for performing the functions described in each step are created. These computer program instructions may also be stored in a computer usable or computer readable memory capable of directing a computer or other programmable data processing apparatus to implement the functionality in a particular manner so that the computer usable or computer readable memory It is also possible for the instructions stored in the block diagram to produce a manufacturing item containing instruction means for performing the functions described in each block or flowchart of the block diagram. Computer program instructions may also be stored on a computer or other programmable data processing equipment so that a series of operating steps may be performed on a computer or other programmable data processing equipment to create a computer- It is also possible that the instructions that perform the processing equipment provide the steps for executing the functions described in each block of the block diagram and at each step of the flowchart.

Also, each block or each step may represent a module, segment, or portion of code that includes one or more executable instructions for executing the specified logical function (s). It should also be noted that in some alternative embodiments, the functions mentioned in the blocks or steps may occur out of order. For example, two blocks or steps shown in succession may in fact be performed substantially concurrently, or the blocks or steps may sometimes be performed in reverse order according to the corresponding function.

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 construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

100: Software similarity measuring device
110: Dynamic Analysis Unit
120: static analysis section
130:

Claims (18)

Checking the status of the first software through dynamic analysis and then releasing encryption or execution decompression;
Extracting a bus mark from a binary file of the first software whose encryption or execution decompression is released through static analysis;
And comparing the extracted bus mark with a bus mark of the second software to calculate a degree of similarity
Software similarity measurement method. The method according to claim 1,
The step of extracting the bus mark may include extracting a compiler type of the first software using a static tool and then compiling the compiler into an extracted compiler type to generate the binary file
Software similarity measurement method. 3. The method of claim 2,
The step of extracting the bus mark may include a step of generating a plurality of binary files by compiling each application option
Software similarity measurement method. The method according to claim 1,
The step of extracting the bus mark may include extracting at least one of an operation code, an application programming interface (API) calling frequency, an API reference order, a control flow graph, and a call graph as the bus mark
Software similarity measurement method. 5. The method of claim 4,
The extracting of the bus mark may include extracting the operation code from the binary file on a function unit basis
Software similarity measurement method. 6. The method of claim 5,
The step of extracting the bus mark may include extracting the operation code except the API at the time of calling the function
Software similarity measurement method. The method according to claim 6,
The step of extracting the bus mark may include determining whether the API is an IAT (Import Address Table)
Software similarity measurement method. The method according to claim 1,
Generating a source course through decompilation for the first software for which the encryption or execution decompression is released if the source code of the second software exists;
And comparing the source code of the first software with the source code of the second software to calculate the similarity
Software similarity measurement method. A method for measuring a software similarity measure according to any one of claims 1 to 8,
A computer program stored on a computer readable recording medium. A method for determining a software similarity measure according to any one of claims 1 to 8,
A computer-readable recording medium storing a computer program. A dynamic analysis unit for checking the status of the first software through dynamic analysis and then releasing encryption or execution compression;
A static analysis unit for extracting a bus mark from the binary file of the first software whose encryption or execution compression is released through static analysis;
And a degree of similarity calculating unit for comparing the extracted bus mark with a bus mark of the second software to calculate a degree of similarity
Software similarity measuring device. 12. The method of claim 11,
The static analysis unit extracts a compiler type of the first software using a static tool, compiles the extracted compiler type into an extracted compiler type, and generates the binary file
Software similarity measuring device. 13. The method of claim 12,
The static analysis unit compiles a plurality of binary files according to application options
Software similarity measuring device. 12. The method of claim 11,
The static analysis unit may extract at least one of an operation code, an application programming interface (API) calling frequency, an API reference order, a control flow graph, or a call graph as the bus mark
Software similarity measuring device. 15. The method of claim 14,
The static analysis unit extracts the operation code based on a function unit from the binary file
Software similarity measuring device. 16. The method of claim 15,
The static analysis unit extracts the operation code except the API at the time of calling the function
Software similarity measuring device. 17. The method of claim 16,
The static analysis unit may determine whether the API is available through an IAT (Import Address Table)
Software similarity measuring device. 12. The method of claim 11,
Wherein the static analysis unit generates a source course through decompilation for the first software in which the encryption or execution decompression is released when the source code of the second software exists,
Wherein the similarity calculating unit compares the source code of the first software with the source code of the second software to calculate the similarity
Software similarity measuring device.

Images