KR20180060497A - Apparatus and method for analyzing embeded software vulnerability based on binary code - Google Patents

Abstract

The present invention relates to an apparatus and a method for analyzing vulnerability of binary code-based embedded software. The apparatus according to one embodiment of the present invention includes: a binary analysis unit for confirming whether a binary code can be converted into an intermediate representation format by extracting architecture information from the binary code; an intermediate representation conversion unit for converting the binary code into an intermediate representation code according to the confirmation result; an intermediate representation analysis unit for selecting a function to be analyzed for vulnerability by extracting a function call graph and a control flow graph from the intermediate representation code; a static vulnerability analysis unit for generating a static vulnerability detection list by determining whether the function to be analyzed for vulnerability has security vulnerability corresponding to a common weakness enumeration (CWE) vulnerability list; and a dynamic vulnerability analysis unit for performing symbolic execution by generating a test case for a function having vulnerability selected from the static vulnerability detection list. Therefore, the precision of vulnerability detection can be improved.

Description

[0001] APPARATUS AND METHOD FOR ANALYZING EMBEDDED SOFTWARE VULNERABILITY BASED ON BINARY CODE [0002]

The present invention relates to an apparatus and method for analyzing a vulnerability of an embedded software based on a binary code, and more particularly, to analyzing a security vulnerability of an embedded device by statically and dynamically analyzing a binary code after converting the binary code into an intermediate representation code The present invention relates to a binary code based embedded software vulnerability analyzing apparatus and method thereof.

In recent years, the use of vulnerable software has increased the exposure to cyber attacks such as hacking. Therefore, software developers are carrying out various studies to reduce security vulnerabilities from software development stage. As such, the importance of reducing software security vulnerabilities is growing. Here, a security vulnerability in an information system refers to an illegal user access to an information system, a threat that interferes with a normal information system service, and a threat of leakage, alteration or deletion of important data managed by the information system.

In general, major IT infrastructure management agencies analyze and manage software vulnerabilities that threaten business in information systems and operate a security vulnerability management process that enables immediate response when a serious threat occurs.

Recently, as power facilities have become more intelligent, such as the Smart Grid and the Power of the Internet (IoT), the power industry is also connecting to the power system operation network with the embedded devices necessary for information gathering and control. However, embedded devices are vulnerable to cyber attack threats when using vulnerable software. Accordingly, the electric power industry management agency needs to analyze and manage the security weaknesses of the software used in the embedded devices, and prepare a countermeasure process against the serious threats.

The following are the methods that can detect security vulnerabilities of conventional software.

First, a coding rule checking method based on a source code is a method of obtaining a source code of a target embedded device software and detecting problems related to a security vulnerability existing in the source code. Software security vulnerabilities are most effective at reducing vulnerabilities at the development stage. However, the source code is essential for the coding rule checking method based on the source code. In the case of a legacy system or a commercial system, the source code of the software can not be obtained or is not provided by the development company. Therefore, in this case, the binary code of the executable file is reversed to the source code using a binary reversing tool such as 'IDA Pro' on the market, and the software security vulnerability of the source code is reversed Analysis and detection. However, in this case, since a security patch can not be requested in advance until a government agency or a security company finds a vulnerable portion, security measures against the security vulnerability of the software itself impossible.

Next, the known binary pattern comparison method based on the binary is a method of scanning the target binary and inspecting the pattern to find and report a known binary pattern as a problem. Typically, vaccine technology is an example. Known binary pattern comparison method based on binary is difficult to analyze logical execution flow other than pattern. Therefore, vulnerability analysis is limited because only binary vulnerability pattern known as existing binary scanner is used.

Next, the binary direct analysis method by a human is a method for the security expert to directly check the binary code of the target embedded device software through the binary reversing tool such as IDA Pro and to find the problematic part.

Finally, 'dynamic black box testing method through simulation penetration test' is a method to check whether there is a problem by trying predetermined intrusion methods under the environment where the target embedded device actually operates. The dynamic black box testing method through simulation penetration test has a limit that it is limited to detecting security vulnerabilities existing in scenarios because it is based on execution scenarios as well as a driving environment similar to actual driving is required.

On the other hand, legacy system embedded devices such as a Feeder Remote Teminal Unit (FRTU), a Supervision Control and Data Acquisition RTU (SCADA RTU), an electronic watt hour meter, Commercially available embedded devices, such as data acquisition devices (DCUs), power IoT sensors, are difficult to secure source code for detecting software vulnerabilities. In this case, in order to detect the vulnerability of the software, it is necessary to analyze the security vulnerability from the executable binary code.

Conventionally, a binary code scanner is used to match a known malicious binary code. However, embedded devices have a variety of architectures due to their characteristics, and thus have different hardware-dependent instruction code systems. Therefore, when using a conventional binary code scanner, an embedded device must secure a method of scanning and matching binary by different architectures.

In addition, specialized personnel are needed to analyze security vulnerabilities from binary code. In other words, the general public lacks understanding of the binary code and can not understand and analyze all the architectures to be examined. Even if a skilled workforce is secured, it takes a considerable amount of time and labor to manually detect security vulnerabilities per binary file.

An object of the present invention is to provide a binary code-based embedded software vulnerability analyzing apparatus and method for analyzing vulnerability of software of an embedded device by statically and dynamically analyzing a binary code after converting the binary code into an intermediate representation code .

It is another object of the present invention to improve the accuracy of vulnerability detection through static and dynamic combined analysis for detecting a vulnerability that can occur in a binary and adding additional judgment information about the probability of occurrence of the vulnerability.

A binary code-based embedded software vulnerability analyzing apparatus according to an embodiment of the present invention includes a binary analyzer for extracting architecture information from a binary code and checking whether the architecture information can be converted into an intermediate representation format; An intermediate representation conversion unit for converting the binary code into an intermediate representation code according to the check result; An intermediate expression analyzer for extracting a function call graph and a control flow graph from the intermediate representation code to select a function to be subjected to the vulnerability analysis; A static vulnerability analyzer for generating a static vulnerability detection list by determining whether there is a security vulnerability corresponding to the Common Weakness Enumeration (CWE) vulnerability list for the vulnerability analysis target function; And a dynamic vulnerability analyzer for generating a test case for a function having a vulnerability selected from the static vulnerability detection list and executing the preference operation.

The binary analyzing unit extracts and stores character string information and symbol information, which are binary type information, from the binary code.

The intermediate representation conversion unit may generate a disassembly code through a disassembly process on the binary code, and then convert the disassembly code into the intermediate representation code corresponding to the disassembly code.

The intermediate expression analyzing unit parses the intermediate representation code to generate an abstract syntax tree, and then traverses the abstract syntax tree to generate a function call graph and a control flow graph.

The intermediate expression analyzing unit may select the function to be subjected to the vulnerability analysis by excluding a function list that does not require a security vulnerability analysis through analysis of a function call graph and a control flow graph.

The static vulnerability analysis unit analyzes the vulnerability analysis target function to identify an intermediate representation code of the same type as the previously known vulnerability information.

The static vulnerability detection list is characterized in that the vulnerability location and the vulnerability information are recorded.

The dynamic vulnerability analysis unit analyzes factor information, branch information, and call relationship information of a function having a selected vulnerability from the static vulnerability detection list.

According to another aspect of the present invention, there is provided a method of analyzing an embedded software vulnerability of a binary code, the method comprising: extracting architecture information from a binary code and confirming whether the information can be converted into an intermediate representation format; Converting the binary code into an intermediate representation code according to the result of the checking; Extracting a function call graph and a control flow graph from the intermediate representation code to select a function to be subjected to the vulnerability analysis; Generating a static vulnerability detection list for the vulnerability analysis target function by determining whether there is a security vulnerability corresponding to the Common Weakness Enumeration (CWE) vulnerability list; And generating a test case for a function having a vulnerability selected from the static vulnerability detection list to execute the preference execution.

Detecting a vulnerability that can be generated by combining the analysis result of the static vulnerability detection list and the result of performing the preference execution.

And operating the security vulnerability management process corresponding to the security threat according to the detection result after the detection step.

The checking step extracts and stores character string information and symbol information, which are binary type information, from the binary code.

The transforming step may include disassembling the binary code to generate a disassembly code, and then converting the disassembled code to the intermediate representation code corresponding to the disassembly code.

The selecting step generates an abstract syntax tree by parsing the intermediate representation code, and then traverses the abstract syntax tree to generate a function call graph and a control flow graph.

The selecting step may include selecting a function to be subjected to the vulnerability analysis by excluding a function list that does not require a security vulnerability analysis through analysis of a function call graph and a control flow graph.

And the generating step analyzes the vulnerability analysis target function to identify an intermediate representation code of the same type as the previously known vulnerability information.

The execution step analyzes the argument information, the branch information, and the call relationship information of the function having the selected vulnerability from the static vulnerability detection list.

The present invention can check the vulnerability of the software of the embedded device by analyzing the binary code statically and dynamically after converting the binary code into the intermediate representation code and analyzing it.

Also, the present invention can detect a vulnerability from a binary, which is an executable file of an embedded device, without source code through binary-based vulnerability analysis.

In addition, the present invention can check security vulnerabilities for embedded devices such as power equipment (RTU, FRTU) and power IoT sensors.

In addition, the present invention can improve vulnerability detection precision through static and dynamic combined analysis that detects a vulnerability that can occur in the binary and adds additional judgment information about the probability of occurrence of the vulnerability.

Further, the present invention requires a continuous correspondence to the intermediate expression conversion, and the intermediate expression based method can minimize the cost that is continuously required as compared with the binary code scanning method.

1 is a diagram of a binary code based embedded software vulnerability analyzing apparatus according to an embodiment of the present invention;
FIG. 2 is a diagram illustrating an example of source code for explaining vulnerability analysis in the vulnerability analysis apparatus of FIG. 1; FIG.
3 illustrates an example of analyzing a function call graph from intermediate representation codes in Tables 1 and 2,
4 shows a control flow graph from an intermediate representation code,
5 is a graph showing a control flow graph using a disassemble tool (IDA Pro)
6 is a diagram illustrating an example of a static vulnerability analysis of an intermediate representation code,
7 is a diagram showing a detailed configuration of a dynamic vulnerability analysis unit,
8 is a diagram illustrating a method of analyzing a vulnerability of an embedded software based on a binary code according to an embodiment of the present invention.

For a better understanding of the present invention, a preferred embodiment of the present invention will be described with reference to the accompanying drawings. The embodiments of the present invention may be modified into various forms, and the scope of the present invention should not be construed as being limited to the embodiments described in detail below. The present embodiments are provided to enable those skilled in the art to more fully understand the present invention. Therefore, the shapes and the like of the elements in the drawings can be exaggeratedly expressed to emphasize a clearer description. It should be noted that in the drawings, the same members are denoted by the same reference numerals. Detailed descriptions of well-known functions and constructions which may be unnecessarily obscured by the gist of the present invention are omitted.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram of a binary code based embedded software vulnerability analysis apparatus according to an embodiment of the present invention.

1, a binary code-based embedded software vulnerability analyzing apparatus (hereinafter referred to as a "vulnerability analyzing apparatus") 100 according to an embodiment of the present invention detects a vulnerability To detect and detect security vulnerabilities of embedded device software. That is, since the vulnerability analysis apparatus 100 can not secure a source code for detecting a security vulnerability of software of an embedded device in a legacy system, a commercial system, or the like, the vulnerability analysis apparatus 100 analyzes a security vulnerability from binary code as an executable file.

To this end, the vulnerability analysis apparatus 100 includes a binary analysis unit 110, an intermediate expression conversion unit 120, an intermediate expression analysis unit 130, a static vulnerability analysis unit 140, and a dynamic vulnerability analysis unit 150 do. In addition, the vulnerability management unit (not shown) operates a security vulnerability management process that allows the vulnerability analysis apparatus 100 to immediately respond to a serious threat based on the analysis result of the vulnerability analysis.

The binary analysis unit 110 extracts the architecture information of the embedded device from the binary code to be analyzed and confirms whether conversion into an intermediate representation format is possible. Here, the binary analyzer 110 further extracts binary type information (i.e., string information, symbol information, etc.) when the binary code can be converted into the intermediate representation format. The binary analysis unit 110 stores and manages architecture information, character string information, and symbol information.

The intermediate representation conversion unit 120 performs a disassembling process on the binary code to be analyzed and converts the intermediate code into an intermediate representation. Specifically, the intermediate representation conversion unit 120 performs a disassembly process on the binary code to generate disassembly code information. Then, the intermediate representation conversion unit 120 searches for the intermediate representation that can be transformed with respect to the disassemble code information, and converts the disassemble code information into the corresponding intermediate representation. Thus, the intermediate representation conversion unit 120 generates an intermediate representation of the binary code to be analyzed.

The intermediate representation analysis unit 130 performs a logical analysis based on the source code using the transformed intermediate representation. That is, the intermediate representation analysis unit 130 uses the function call graph (Fucntion Call) as the common information required for the vulnerability analysis process of the static vulnerability analysis unit 140 and the dynamic vulnerability analysis unit 150, Graph, Control Flow Graph (CFG), and Function List. Here, the intermediate expression analyzing unit 130 analyzes the function call relationship information among the extracted function lists, and selects a list of functions to be subjected to the vulnerability analysis. Specifically, the intermediate representation analysis unit 130 generates an abstract syntax tree (AST) by parsing the transformed intermediate representation. The intermediate expression analysis unit 130 traverses each node of the abstract syntax tree to generate a function call graph and a control flow graph. In this case, when the nodes of the abstract syntax tree are traversed, the intermediate expression analyzing unit 130 can use any one of the traversal methods such as dislocation traversal, middle traversal, and trailing traversal.

In addition, the intermediate expression analyzer 130 analyzes the function call graph and the control flow graph, and generates a list of functions to be subjected to the vulnerability analysis by excluding the function list that does not require the analysis of the security vulnerability.

The static vulnerability analysis unit 140 sequentially circulates the vulnerability analysis target function list to determine the intermediate representation code of the same type as that of the previously known vulnerability information. Then, the static vulnerability analysis unit 140 generates a static vulnerability detection list in which the identified vulnerability location and the identified vulnerability information are recorded according to the determination result.

Specifically, the static vulnerability analysis unit 140 analyzes the function call relationship of the vulnerability analysis target function, collects function call relationship information, and analyzes the control flow graph of the vulnerability analysis target function to collect logic flow information. The static vulnerability analysis unit 140 determines whether there is a security vulnerability of the same type in the CWE (Common Weakness Enumeration) vulnerability list for the static vulnerability detection for the vulnerability analysis target function. Thus, the static vulnerability analysis unit 140 generates a static vulnerability detection list.

The dynamic vulnerability analysis unit 150 sequentially traverses the functions to be subjected to the vulnerability analysis, judges a function capable of symbolic execution, and performs a symbol operation on the function. The dynamic vulnerability analysis unit 150 records the execution flow information of the symbolically performed functions.

Specifically, the dynamic vulnerability analysis unit 150 selects a function having a vulnerability from the static vulnerability detection list, and analyzes the factor information, the branch information, and the call relationship information. Then, the dynamic vulnerability analysis unit 150 generates a test case for the vulnerable functions based on the analyzed information. The dynamic vulnerability analysis unit 150 executes the symbol execution of the test cases.

The static and dynamic vulnerability analyzing units 140 and 150 conduct the intermediate expression analysis to analyze static vulnerability analysis and dynamic vulnerability analysis to select items likely to occur in the embedded software from the CWE items, The analysis can be used in combination to improve the breadth and accuracy of vulnerability detection. This is because the scope of detection is wider than that of the single vulnerability detection method, and more reliable vulnerability detection information can be provided through addition of possibility to be generated based on the dynamic symbol performance for the detected vulnerability.

In this way, when a series of execution flows is completed, the vulnerability analysis apparatus 100 discriminates the possibility of the vulnerability by synthesizing the vulnerability information and the execution flow information detected from the static vulnerability, and selects only the vulnerabilities considered to be possible. Through this process, the vulnerability analysis apparatus 100 can detect the vulnerability that can occur in the binary and increase the accuracy of the vulnerability detection through static and dynamic combined analysis that adds additional judgment information about the possibility of the occurrence.

As described above, the vulnerability analysis apparatus 100 can detect a vulnerability from a binary, which is an executable file of an embedded device, without source code through a binary-based vulnerability analysis. That is, the vulnerability analysis apparatus 100 can perform vulnerability analysis based on a general binary based on an intermediate expression in order to overcome the limit of detecting the vulnerability of an embedded device. Accordingly, the vulnerability analysis apparatus 100 can check security vulnerabilities on embedded devices such as a power plant (RTU, FRTU) and a power IoT sensor.

2 is a diagram illustrating an example of source code for explaining vulnerability analysis in the vulnerability analysis apparatus of FIG.

The source code of FIG. 2 is an example code for explaining a software vulnerability analysis. The source code of the following two vulnerabilities is presented.

The first vulnerability is a vulnerability due to the use of the string comparison function (strcmp) which does not consider string length. Here, the strcmp function (1) is a function for comparing two strings, and compares the size of the bytes sequentially from the first character, not comparing the lengths of the strings with each other. The header of the strcmp function (1) is 'string.h'. The type of the strcmp function (1) is 'char * strcmp (const char * s1, const char * s2);'. The argument 'char * s1' represents the target string to be compared, and the argument 'char * s2' represents the string to be compared. This strcmp function (1) has a vulnerability called a buffer overflow. It does not compare the memory size with the information received as an argument, thereby violating the memory of another area, causing a malfunction such as program malfunction and root privilege hijacking Is a function. Here, the buffer overflow refers to controlling the execution flow of the target program using a memory error and finally executing an arbitrary code desired by the attacker. Therefore, since the strcmp function (1) is vulnerable, it is preferable to replace it with the strncmp function.

The second vulnerability is a vulnerability in which the password (brilling) (2) is hard-coded and exposed. When the password is hard-coded, there is a weak point that the administrator's password is exposed, and it is not easy to modify the administrator periodically.

On the other hand, Tables 1 and 2 below show example codes in which the source code of FIG. 2 is transformed into an intermediate representation through disassembly. In other words, Tables 1 and 2 below show example codes obtained by converting the source code of FIG. 2 into binary code, which is an executable file after being compiled, into an intermediate representation code. Here, in the following Tables 1 and 2, the example code uses the LLVM intermediate representation.

One. ; ModuleID = 'test.c'
2. target datalayout = "em: o-i64: 64-f80: 128-n8: 16: 32: 64-S128"
3. target triple = "x86_64-apple-macosx10.11.0"
4.
5. @ .str = private unnamed_addr constant [9 x i8] c "brilling \ 00", align 1
6. @. Str1 = private unnamed_addr constant [8 x i8] c "Access \ 0A \ 00", align 1
7. @ .str2 = private unnamed_addr constant [6 x i8] c "Deny \ 0A \ 00", align 1
8.
9.; Function Attrs: nounwind uwtable
10.define i32 @check_auth (i8 *% password) # 0 {
11.entry:
12.% password.addr = alloca i8 *, align 8
13.% auth_flag = alloca i32, align 4
14. store i8 *% password, i8 **% password.addr, align 8
15. store i32 0, i32 *% auth_flag, align 4
16.% 0 = load i8 **% password.addr, align 8
17. call = call i32 @ strcmp (i8 *% 0, i8 * getelementptr inbounds ([9 x i8] * @. Str, i32
0, i32 0))
18.% cmp = icmp eq i32% call, 0
19. br i1% cmp, label% if.then, label% if.end
20.
21.if.then:; preds =% entry
22. store i32 1, i32 *% auth_flag, align 4
23. br label% if.end
24.
25.if.end:; preds =% if.then,% entry
26.% 1 = load i32 *% auth_flag, align 4
27. ret i32% 1
28.}
29.
30.declare i32 @ strcmp (i8 *, i8 *) # 1
31.
32 .; Function Attrs: nounwind uwtable
33.define i32 @main (i32% argc, i8 **% argv) # 0 {
34.entry:
35.% retval = alloca i32, align 4
36.% argc.addr = alloca i32, align 4
37.% argv.addr = alloca i8 **, align 8
38. store i32 0, i32 *% retval
39. store i32% argc, i32 *% argc.addr, align 4
40. store i8 **% argv, i8 ***% argv.addr, align 8
41.% 0 = load i32 *% argc.addr, align 4
42.% cmp = icmp slt i32% 0, 2
43. br i1% cmp, label% if.then, label% if.end
44.
45.if.then:; preds =% entry
46. store i32 -1, i32 *% retval
47. br label% return
48.

49.if.end:; preds =% entry
50.% 1 = load i8 ***% argv.addr, align 8
51.% arrayidx = getelementptr inbounds i8 **% 1, i64 1
52.% 2 = load i8 **% arrayidx, align 8
53.% call = call i32 @check_auth (i8 *% 2)
54.% tobool = icmp ne i32% call, 0
55. br i1% tobool, label% if.then1, label% if.else
56.
57.if.then1:; preds =% if.end
58.% call2 = call i32 (i8 *, ...) * @printf (i8 * getelementptr inbounds ([8 x i8] *
@. str1, i32 0, i32 0))
59. br label% if.end4
60.
61.if.else:; preds =% if.end
62.% call3 = call i32 (i8 *, ...) * @printf (i8 * getelementptr inbounds ([6 x i8] *
@. str2, i32 0, i32 0))
63. br label% if.end4
64.
65.if.end4:; preds =% if.else,% if.then1
66. store i32 0, i32 *% retval
67. br label% return
68.
69.return:; preds =% if.end4,% if.then
70.% 3 = load i32 *% retval
71. ret i32% 3
72.}
73.
74.declare i32 @printf (i8 *, ...) # 1
75.
76.attributes # 0 = {nounwind uwtable "less-precise-fpmad" = "false"
"no-frame-pointer-elim" = "true""no-frame-pointer-elim-
"no-inf-fp-math" = "false""no-nans-fp-math"
"use-soft-float" = "false""unsafe-fp-math" = "
}
77.attributes # 1 = {"less-precise-fpmad" = "false""no-
"no-frame-pointer-elim-non-leaf""no-infs-fp-math"
"no-nans-fp-math" = "false""stack-protector-buffer-size"
"unsafe-fp-math" = "false""use-soft-float" = "false"
78.
79.! Llvm.module.flags =! {0}
80.! Llvm.ident =! {! 1}
81.
82.! 0 =! {I32 1,! "PIC Level", i32 2}
83.! 1 =! {"Clang version 3.6.2 (https://github.com/llvm-mirror/clang
c2e93b903ffee0e691757284c53e5f81615bdc55) (https://github.com/llvm-mirror/llvm
19ade095e8c3ea61f84b71074433309f0c7c7b3b) "}

FIG. 3 shows an example of analyzing a function call graph from the intermediate representation codes of Tables 1 and 2 above.

The intermediate expression analyzing unit 130 analyzes the function call relation for utilizing the intermediate representation code for static / dynamic analysis through analysis of the call relation of the binary to be analyzed and extracts the function to be subjected to the vulnerability analysis by removing unnecessary analysis target information . That is, the intermediate expression analysis unit 130 analyzes the function call relationship as shown in FIG. 3, removes unnecessary analysis target information 11 such as a system function, and selects the vulnerability analysis target function 12. FIG.

FIG. 4 is a graph showing a control flow graph from an intermediate representation code, and FIG. 5 is a graph showing a control flow graph using a disassemble tool (IDA Pro). Table 3 below shows the source codes used to express the control flow graphs of FIGS. 4 and 5.

1. int check_auth (char * password) {
2. int auth_flag = 0;
3.
4. if (strcmp (password, "brilling") == 0)
5. auth_flag = 1;
6.
7. return auth_flag;
8. }

The intermediate expression analyzing unit 130 may extract the control flow graph as shown in FIG. 4 from the intermediate representation code converted from the source code of Table 3. [ That is, the intermediate expression analyzer 130 generates a control flow graph of the function to be subjected to the vulnerability analysis from the intermediate representation code. FIG. 4 shows an example of a case where the control flow graph for the 'check_auth' function is generated. As described above, the intermediate expression analysis unit 130 can grasp and provide the execution flow for all paths that the program in the vulnerability analysis target function can traverse during execution.

4 and 5, the control flow graph (see FIG. 4) generated by the intermediate expression analysis unit 130 is a control flow graph obtained by analyzing a binary by a professional worker using the reversing tool IDA Pro It can be seen that the same flow is expressed when compared with the graph (see FIG. 5). The control flow graph using the intermediate representation code can be used as vulnerability analysis information through conventional binary reversing.

1. define i32 @ check_auth (i8 *% password) # 0 {
2. entry:
3.% password.addr = alloca i8 *, align 8
4.% auth_flag = alloca i32, align 4
5. store i8 *% password, i8 **% password.addr, align 8
6. store i32 0, i32 *% auth_flag, align 4
7.% 0 = load i8 **% password.addr, align 8
I8 *% 0, i8 * getelementptr inbounds ([9 x i8] * @. Str, i320, i32 0)
9.% cmp = icmp eq i32% call, 0
10. br i1% cmp, label% if.then, label% if.end
11.
12.if.then:; preds =% entry
13. store i32 1, i32 *% auth_flag, align 4
14. br label% if.end
15.
16.if.end:; preds =% if.then,% entry
17.% 1 = load i32 *% auth_flag, align 4
18. ret i32% 1
19.}

Table 4 shows the intermediate representation codes of the function subject to vulnerability analysis. The intermediate expression analyzing unit 130 selects a function to be subjected to the vulnerability analysis from the intermediate expression code as shown in Table 4. Specifically, the intermediate expression analyzer 130 removes unnecessary analysis objects based on the function call graph and the control flow graph, thereby selecting the functions to be subjected to the vulnerability analysis. That is, the intermediate expression analyzer 130 removes unnecessary analysis objects from all the intermediate representation codes, and then selects the remainder as a function to be analyzed.

The intermediate representation codes in Table 4 are described below.

First, the code lines 3 to 6 include declarations for the variables used in the function or the intermediate expression codes (i.e., i8, i32, etc.), the alignment information (i.e., align 8, align 4, (That is,% password.addr,% auth_flag) and the execution of the initialization operation (store).

In addition, the code lines 7 to 19 show the actual string comparison function call and the conditional branch according to the result.

Specifically, code line 7 indicates loading the value of the password into the '0%' register. Here, the load command reads the value of the address indicated by the variable. Code line 8 indicates that the string comparison function (strcmp) is called, and the return value is entered in '% call'. Code line 9 indicates that the comparison results for '% call' and '0' are entered into '% cmp'. Here, the icmp instruction is a comparison instruction and the condition is 'eq (ie, equal)'. That is, 1 is entered if '% call' is equal to the constant '0', and 0 is entered into '% cmp'. Code lines 10 through 19 execute the branch instruction according to the input value of '% cmp'. Here, the br command is a branch instruction and branches according to the input value of% cmp inputted above. That is, if the input value of% cmp is '1', it branches to 'label% if.then', otherwise it branches to 'label% if.end'.

6 is a diagram illustrating an example of static vulnerability analysis of the intermediate representation code.

The static vulnerability analysis unit 140 analyzes the static vulnerability of the selected intermediate representation code through the intermediate expression analysis unit 130. [ That is, the static vulnerability analysis unit 140 determines whether there is a security vulnerability of the same type in the CWE (Common Weakness Enumeration) vulnerability list for the static vulnerability detection for the selected vulnerability analysis target function through the intermediate expression analysis unit 130 .

The '@. Str' (31) line of code line 1 represents the string 'brilling \ 00' (32) related to authentication in the global constant declaration. Code line 13 calls '@ strcmp' (33). The strcmp function is a vulnerable function. The strcmp function is also executed by taking the global constant '@. Str' (35) and '% 0' register (36) as arguments. Here, the confirmation of whether a buffer overflow vulnerability occurs for the two factors is performed through dynamic vulnerability analysis by the dynamic vulnerability analysis unit 150. [

7 is a diagram showing a detailed configuration of a dynamic vulnerability analysis unit.

The dynamic vulnerability analysis unit 150 includes a weak point function analysis unit 151, a symbol execution test generation unit 152, a symbol execution unit 153, and a symbol execution result analysis unit 154. The vulnerability function analysis unit 151 receives a static vulnerability analysis result from the static vulnerability analysis unit 140 to generate a test case for symbol execution. The vulnerability function analysis unit 151 analyzes the function having the vulnerability from the static vulnerability analysis result. The preference test generation unit 152 analyzes the argument information, the branch information, and the call relationship information of the object function to generate a preference test case. The symbol performing unit 153 executes symbolic execution using the generated symbol execution test case information. The symbol execution result analyzing unit 154 analyzes the executed execution result and analyzes and reports the information having the weakness.

8 is a diagram illustrating a method of analyzing a vulnerability of an embedded software based on a binary code according to an embodiment of the present invention.

The vulnerability analysis apparatus 100 extracts the architecture information of the embedded device from the binary code to be analyzed and confirms whether conversion into the intermediate expression format is possible (S201, S202). At this time, the vulnerability analysis apparatus 100 further extracts binary type information (i.e., string information, symbol information, etc.) when analysis is possible. In addition, the vulnerability analysis apparatus 100 stores extracted architecture information, character string information, and symbol information. Steps S201 and S202 are performed by the binary analysis unit 110 of the vulnerability analysis apparatus 100. [

Thereafter, the vulnerability analysis apparatus 100 disassembles the input binary code and converts it into an intermediate representation (S203). At this time, the vulnerability analysis apparatus 100 disassembles the input binary code to generate disassembly code information, and then searches the disassembly code for a convertible intermediate expression. Then, the vulnerability analysis apparatus 100 converts the intermediate representation code corresponding to the disassembly code. Step S203 is performed by the intermediate expression conversion unit 120 of the vulnerability analysis apparatus 100. [

Then, the vulnerability analysis apparatus 100 generates an abstract syntax tree (AST) by parsing the intermediate representation code (S204). Then, the vulnerability analysis apparatus 100 traverses the abstract syntax tree to extract and analyze a function call graph and a control flow graph (S205), and then selects a vulnerability analysis target function list (S206). The steps S204 to S206 are performed by the intermediate expression analyzing unit 130 of the vulnerability analysis apparatus 100.

Then, the vulnerability analysis apparatus 100 analyzes the function call relationship and the control flow relationship of the vulnerability analysis target function to check whether there is a vulnerability corresponding to the CWE vulnerability list (S207, S208). At this time, the vulnerability analysis apparatus 100 generates a static vulnerability detection list (S209). The steps S207 through S209 are performed by the static vulnerability analysis unit 140 of the vulnerability analysis apparatus 100. FIG.

Then, the vulnerability analysis apparatus 100 selects a function having a vulnerability among the static vulnerability detection lists (S210). Then, the vulnerability analysis apparatus 100 analyzes the function having the vulnerability and generates a test case (S211). At this time, the vulnerability analysis apparatus 100 analyzes the argument information, the branch information, and the call relation of the function having the vulnerability. In addition, the vulnerability analysis apparatus 100 performs a preference operation on the test case to report a result analysis on information having a vulnerability (S212). Then, the vulnerability analysis apparatus 100 synthesizes the static / dynamic vulnerability analysis results and detects possible vulnerabilities (S213).

The steps S210 to S213 are performed by the dynamic vulnerability analysis unit 150 of the vulnerability analysis apparatus 100.

It will be apparent to those skilled in the art that various modifications and variations may be made in the present invention. Accordingly, it is to be understood that the present invention is not limited to the above-described embodiments. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims. It is also to be understood that the invention includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

110: Binary analysis unit 120: Intermediate expression conversion unit
130: intermediate expression analysis unit 140: static vulnerability analysis unit
150: dynamic vulnerability analysis unit 151: vulnerability function analysis unit
152: Symbol performance test generation unit 153: Symbol performance unit
154: Symbol execution result analysis section

Claims (17)

A binary analysis unit for extracting the architecture information from the binary code and checking whether the architecture information can be converted into the intermediate representation format;
An intermediate representation conversion unit for converting the binary code into an intermediate representation code according to the check result;
An intermediate expression analyzer for extracting a function call graph and a control flow graph from the intermediate representation code to select a function to be subjected to the vulnerability analysis;
A static vulnerability analyzer for generating a static vulnerability detection list by determining whether there is a security vulnerability corresponding to the Common Weakness Enumeration (CWE) vulnerability list for the vulnerability analysis target function; And
A dynamic vulnerability analysis unit for generating a test case for a function having a vulnerability selected from the static vulnerability detection list and executing a preference operation;
Based embedded software vulnerability analysis apparatus.
The method according to claim 1,
Wherein the binary analyzer comprises:
And extracting and storing the string information and the symbol information as the binary type information from the binary code.
The method according to claim 1,
Wherein the intermediate expression conversion unit comprises:
Wherein the disassembly process is performed on the binary code to generate a disassembly code, and the disassembly code is converted into the intermediate representation code corresponding to the disassembly code.
The method according to claim 1,
The intermediate expression analyzing unit,
Generating an abstract syntax tree by parsing the intermediate representation code, and then traversing the abstract syntax tree to generate a function call graph and a control flow graph.
The method according to claim 1,
The intermediate expression analyzing unit,
Wherein the vulnerability analysis target function is selected by excluding a function list that does not require a security vulnerability analysis through analysis of a function call graph and a control flow graph.
The method according to claim 1,
The static vulnerability analysis unit,
And analyzing the vulnerability analysis target function to identify an intermediate representation code of the same type as the vulnerability information of a previously known type.
The method according to claim 1,
Wherein the static vulnerability detection list includes a vulnerability location and vulnerability information recorded in the static vulnerability detection list.
The method according to claim 1,
Wherein the dynamic vulnerability analysis unit comprises:
And analyzing factor information, branch information, and call relationship information of a function having a selected vulnerability from the static vulnerability detection list.
Extracting the architecture information from the binary code and confirming whether the architecture information can be converted into the intermediate representation format;
Converting the binary code into an intermediate representation code according to the result of the checking;
Extracting a function call graph and a control flow graph from the intermediate representation code to select a function to be subjected to the vulnerability analysis;
Generating a static vulnerability detection list for the vulnerability analysis target function by determining whether there is a security vulnerability corresponding to the Common Weakness Enumeration (CWE) vulnerability list; And
Generating a test case for a function having a vulnerability selected from the static vulnerability detection list and executing a preference operation;
A method for analyzing an embedded software vulnerability based on binary code.
10. The method of claim 9,
Detecting a possible vulnerability by synthesizing an analysis result of the static vulnerability detection list and a result of executing the preference execution;
A method for analyzing an embedded software vulnerability based on binary code.
11. The method of claim 10,
After the detecting step,
Operating a security vulnerability management process corresponding to a security threat according to the detection result;
A method for analyzing an embedded software vulnerability based on binary code.
10. The method of claim 9,
Wherein,
And extracting and storing the string information and the symbol information as the binary type information from the binary code.
10. The method of claim 9,
Wherein,
Generating a disassembly code through a disassembly process on the binary code, and converting the disassembled code into the intermediate representation code corresponding to the disassembly code.
10. The method of claim 9,
In the selecting step,
Generating an abstract syntax tree by parsing the intermediate representation code and then traversing the abstract syntax tree to generate a function call graph and a control flow graph.
10. The method of claim 9,
In the selecting step,
Wherein the vulnerability analysis target function is selected by excluding a function list that does not require a security vulnerability analysis through analysis of a function call graph and a control flow graph.
10. The method of claim 9,
Wherein the generating comprises:
And analyzing the vulnerability analysis target function to identify an intermediate representation code of the same type as the vulnerability information of a previously known type.
10. The method of claim 9,
Wherein,
And analyzing the argument information, the branch information, and the call relationship information of the function having the selected vulnerability from the static vulnerability detection list.

Images