Firmware Program Vulnerability Detection Method and System

Abstract

The present invention discloses a firmware program vulnerability detection method and system. The method includes: creating a vulnerability label library; obtaining the binary file of the firmware program; performing disassembly operation on the binary file to extract the function to be tested; extracting the function features of the function to be tested and extracting each basic block in the function to be tested; extracting basic block features; performing function similarity matching and screening out several candidate feature labels with high similarity; performing basic block similarity matching and calculating the final similarity between the function to be tested and the vulnerability function represented by each candidate feature label according to the similarity matching results of all basic blocks in the function to be tested to confirm whether the function to be tested has vulnerabilities; based on the above method, when performing similarity measurement, first, coarse-grained function similarity matching is performed, and then fine-grained basic block similarity matching is performed to accurately determine whether the function to be tested has vulnerabilities, thus taking into account both the vulnerability detection efficiency and accuracy of the firmware program.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware security detection, and particularly to a method and system for detecting firmware program vulnerabilities. Background Art

[0002] With the development of automotive intelligence and networking, the development of vehicle networking devices including intelligent connected vehicles, roadside units, and in-vehicle units has been rapid, and the amount of code therein has increased explosively. To increase development agility, the automotive industry has gradually adopted flexible software development methods. Among them, reusing open-source components has become an efficient method for in-vehicle software development. Due to reasons such as the architecture organization and coding specifications of open-source working groups, open-source components may contain potential cybersecurity vulnerabilities, which will be transmitted to vehicle networking devices that use open-source components, bringing corresponding cybersecurity risks. In addition, code reuse problems are extremely common between different vehicle models and between devices of different versions. If the reused code has a cybersecurity vulnerability, the vulnerability will also be transmitted to subsequent devices.

[0003] Based on the security consideration of firmware programs, detecting code reuse is an effective way to detect vulnerabilities. As long as it can be determined that the tested code contains a code segment with a vulnerability, the tested code will also contain the specific vulnerability in the reused code segment. Among them, code similarity measurement is a technology for judging whether codes are similar, which can determine the similarity degree of two pieces of code, and then determine whether the code segment to be tested contains a specific code segment. Code similarity measurement is mainly divided into source-code-based similarity measurement and binary-code-based similarity measurement. In vehicle networking, in many cases, the source code of vehicle networking devices cannot be obtained. Therefore, the firmware vulnerability scanning method based on binary code similarity measurement becomes even more important.

[0004] However, in the binary-based code similarity measurement scheme, complex feature representation (representing code segments with features) will make code similarity measurement a complex task with a huge amount of calculation, resulting in low detection efficiency. Too simple feature representation will lose some characteristics of the code, leading to the lack of accuracy in similarity measurement. For example, in the Chinese invention patent (CN111310178 A, a method for detecting firmware vulnerabilities in a cross-platform scenario), features are only extracted at the function level for comparison. Summary of the Invention

[0005] The purpose of the present invention is to provide a method and system for detecting firmware program vulnerabilities that uses binary similarity measurement to detect firmware vulnerabilities while taking into account both accuracy and efficiency.

[0006] To achieve the above purpose, the present invention discloses a method for detecting firmware program vulnerabilities, which includes:

[0007] Create a vulnerability tag library, in which there are stored a number of characteristic tags of functions carrying known vulnerabilities, and the characteristic tags include a first tag representing the overall content and structural characteristics of the function and a number of second tags respectively representing the content and structural characteristics of each basic block within the function;

[0008] Obtain the binary file of the firmware program;

[0009] Perform disassembly operations on the executable files in the binary file to extract each function to be tested in the executable files;

[0010] For any one of the functions to be tested, extract the overall content and structural characteristics of the function to be tested to obtain the function characteristics of the function to be tested, and extract each basic block in the function to be tested;

[0011] Extract the content and structural characteristics of each basic block to obtain basic block characteristics;

[0012] Compare the function characteristics of the function to be tested with the first tags of each of the characteristic tags in the vulnerability tag library respectively for function similarity matching, and screen out a number of candidate characteristic tags with high similarity;

[0013] Compare the basic block characteristics of each basic block of the currently tested function with a number of second tags in the candidate characteristic tags pairwise for basic block similarity matching, and calculate the final similarity between the function to be tested and the vulnerable function represented by each candidate characteristic tag according to the similarity matching results of all basic blocks in the function to be tested to confirm whether the function to be tested has vulnerabilities.

[0014] Preferably, the extraction method of the basic block characteristics includes:

[0015] Count the number of instructions of a preset instruction type in the current basic block to obtain the basic block content characteristics, and the preset instruction type includes data operation arithmetic type, call type, numerical operation access type, and logical type;

[0016] Count the out-degree and in-degree of the current basic block in the function to which it belongs to obtain the basic block structural characteristics.

[0017] Preferably, the extraction method of the basic block characteristics further includes:

[0018] Use a preset unified expression to replace the expressions of instruction types under a variety of known different instruction set architectures, and count the number of instructions of a preset instruction type in the current basic block according to the unified expression.

[0019] Preferably, the extraction method of the function characteristics includes:

[0020] Count the number of parent functions, child functions, and data reference items related to the current function in the executable file;

[0021] Count the number of the basic blocks and the number of edges in the control flow graph that the current function has.

[0022] Preferably, the method for function similarity matching includes:

[0023] Construct a function feature vector Sf1 = (Cn, Pn, SI, Bn, En), where Cn, Pn, Bn, En are numerical type feature data, SI is string type feature data, Cn is the number of child functions, Pn is the number of parent functions, Bn is the number of basic blocks, En is the number of edges in the control flow graph, and SI is the data reference item;

[0024] Use the following formula to calculate the similarity S of two functions to be matched,

[0025]

[0026] where L i is the distance between any dimensions in the feature vectors Sf1 of two functions to be matched, and W i is the weight of this dimension.

[0027] Preferably, the method for basic block similarity matching includes:

[0028] Construct a basic block content feature vector Sf2 = (a, b, c, d), where a is the number of instructions of the arithmetic type of data operation, b is the number of instructions of the call type, c is the number of instructions of the access type of numerical operation, and d is the number of instructions of the logical type;

[0029] Use the Pearson correlation coefficient P to represent the similarity score between the content feature vectors of two basic blocks to be matched;

[0030] Calculate the basic block content similarity S1 of two basic blocks to be matched according to the following formula,

[0031] S1 = P * W1

[0032] where W1 is a preset weight;

[0033] Construct a basic block structure feature vector Sf3 = (o, i), where o is the out-degree of the current basic block in the function it belongs to, and i is the in-degree of the current basic block in the function it belongs to;

[0034] Calculate the similarity score Q of two basic blocks to be matched according to the following formula,

[0035]

[0036] Among them, i1 and i2 respectively represent the in-degree values in the basic block structure feature vector Sf3 of two basic blocks to be matched;

[0037] Calculate the basic block structure similarity S2 of two basic blocks to be matched according to the following formula

[0038] S2 = Q * W2

[0039] Among them, W2 is a preset weight;

[0040] Calculate the similarity S of two basic blocks according to the following formula

[0041] S = S1 + S2

[0042] Preferably, when it is determined that there is a vulnerability in the current function to be tested according to the basic block similarity matching, the vulnerability verification program and test instance are used to verify the vulnerability existing in the function to be tested.

[0043] The present invention also discloses a firmware program vulnerability detection system, which includes:

[0044] A vulnerability library creation module, which is used to create a vulnerability label library, and the vulnerability label library stores feature labels of several functions carrying known vulnerabilities, and the feature labels include a first label representing the overall content and structure features of the function and several second labels respectively representing the content and structure features of each basic block in the function;

[0045] A disassembly module, which is used to obtain the binary file of the firmware program and perform a disassembly operation on the executable file in the binary file to extract each function to be tested in the executable file;

[0046] A function feature extraction module, which is used to extract the function features in any function to be tested, and the function features represent the overall content and structure features of the function to be tested;

[0047] A basic block extraction module, which is used to extract each basic block in each function to be tested;

[0048] A basic block feature extraction module, which is used to extract the content and structure features of each basic block to obtain basic block features;

[0049] A primary matching module, which is used to compare the function features of the function to be tested with the first label of each feature label in the vulnerability label library respectively for function similarity matching;

[0050] A primary screening module, which is used to screen out several candidate feature labels with high similarity according to the matching result of the primary matching module;

[0051] A secondary matching module is configured to compare the basic block features of each basic block of the current function to be tested with a plurality of second labels in the candidate feature labels in pairs to perform basic block similarity matching;

[0052] The confirmation module is used to calculate the final similarity between the function to be tested and the vulnerability function represented by each candidate feature label according to the matching result of the secondary matching module, so as to confirm whether the function to be tested has a vulnerability.

[0053] The present invention also discloses a firmware program vulnerability detection system, which includes:

[0054] one or more processors;

[0055] Memory;

[0056] and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for executing the firmware program vulnerability detection method as described above.

[0057] The present invention also discloses a computer-readable storage medium, characterized in that it includes a computer program, and the computer program can be executed by a processor to implement the firmware program vulnerability detection method as described above.

[0058] Compared with the prior art, the above technical solution of the present invention uses a binary similarity measurement method to determine whether there is a code fragment identical to the vulnerability code fragment in the firmware program, thereby detecting the target vulnerability and effectively ensuring the security performance of the firmware. In addition, when performing similarity measurement, candidate feature labels are first found through coarse-grained function similarity matching, and then fine-grained basic block similarity matching is used to accurately determine whether the function to be tested has a vulnerability and the vulnerability type, thereby taking into account both the efficiency and accuracy of vulnerability detection in the firmware program. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 This is a flow chart of a firmware program vulnerability detection method according to an embodiment of the present invention.

[0060] Figure 2 This is a schematic diagram of the principle structure of a firmware program vulnerability detection system in an embodiment of the present invention. DETAILED DESCRIPTION

[0061] In order to explain the technical content, structural features, achieved objectives and effects of the present invention in detail, the following is a detailed description in conjunction with the embodiments and the accompanying drawings.

[0062] This embodiment discloses a firmware program vulnerability detection method for detecting vulnerabilities in firmware. Since the source code of the firmware program is not easy to obtain, this embodiment detects whether there are security vulnerabilities in the firmware program based on the measurement of binary code similarity. Figure 1 , the detection method comprises the following steps:

[0063] S1: Create a vulnerability tag library. The vulnerability tag library stores several feature tags. Each feature tag represents a vulnerable function with a known vulnerability. The feature tags include a first tag representing the overall content and structural characteristics of the vulnerable function and several second tags representing the content and structural characteristics of each basic block within the function. In this embodiment, a basic block refers to a section of code that is executed sequentially in a program. It has only one entry and one exit. This means that once a statement in a basic block is executed, subsequent statements will also be executed. Therefore, a basic block can be considered as a single, integrated behavior.

[0064] S2: Get the binary file of the firmware program.

[0065] S3: Perform a disassembly operation on the executable file in the binary file to extract each function to be tested in the executable file.

[0066] S4: For any function to be tested, extract the overall content and structural features of the function to be tested to obtain the function signature of the function to be tested, and extract each basic block in the function to be tested. The function signature (and the first label) is an abstraction and summary of the binary code behavior at the function level.

[0067] S5: Extract the content and structural features of each basic block to obtain basic block features. Basic block features (and the second label) are the abstraction and generalization of binary code behavior at the basic block level.

[0068] S6: Compare the function features of the function to be tested with the first label of each feature label in the vulnerability label library to perform function similarity matching. For example, the vulnerability label library has three feature labels corresponding to three vulnerable functions, namely B1, B2, and B3. The first label in B1 is B10, and there are three second labels, namely B11, B12, and B13. The first label in B2 is B20, and there are three second labels, namely B21, B22, and B23. The first label in B3 is B30, and there are three second labels, namely B31, B32, and B33. The function feature of one of the functions H to be tested in the current firmware program is A1. Then, A1 is matched with B10, B20, and B30 for similarity.

[0069] S7: According to the function similarity matching result in step S6, several candidate feature labels with high similarity are screened out. If the similarity between A1 and B10 is greater than a preset value, the feature label B1 is used as a candidate feature label.

[0070] S8: Compare the basic block features of each basic block of the current function to be tested with several second labels in the candidate feature labels to perform basic block similarity matching. Specifically, the function to be tested H has three basic blocks, and the basic block features of these three basic blocks are A10, A11, and A12 respectively. Then, first, perform similarity matching on A10 with B11, B12, and B13 respectively. Then, perform similarity matching on A11 with B11, B12, and B13 respectively. Finally, perform similarity matching on A12 with B11, B12, and B13 respectively.

[0071] S9: Based on the similarity matching results of all basic blocks in the test function in step S8, the final similarity between the test function and the vulnerable function represented by each candidate feature label is calculated. In this embodiment, an algorithm (such as a greedy weighted bipartite graph matching algorithm, referred to as a greedy algorithm) is used to calculate the final similarity between the test function H and the vulnerable function corresponding to the feature label B1 to confirm whether the test function has a vulnerability. If the final similarity is greater than a preset value, it is determined that the test function H has a vulnerability corresponding to the feature label B1.

[0072] Furthermore, basic block features include basic block content features and basic block structure features. In this embodiment, the basic block features are extracted by:

[0073] Counting the number of instructions of a preset instruction type in the current basic block to obtain basic block content characteristics, the preset instruction types include data operation arithmetic type, call type, numerical operation access type, and logical type;

[0074] The out-degree and in-degree of the current basic block in its function are counted to obtain the basic block structure characteristics.

[0075] For the basic block structure features, they reflect the information of basic blocks in the internal control flow graph of a function. The internal control flow graph of a function takes basic blocks as nodes and the jump relationships between basic blocks as edges. The in-degree and out-degree of each node can reflect the information of the node in the graph. The out-degree of a basic block represents the number of its sub-blocks, and the in-degree represents the number of its parent blocks. The in-degree of a basic block has three value types: 0, 1, and greater than 1, and the out-degree has two types: 0 and 1, 2. The out-degrees of 1 and 2 correspond to the direct jump and conditional jump instructions at the end of the basic block respectively. According to the in-degree and out-degree of basic blocks in the internal control flow graph of a function, the basic block structure features are divided into 6 different value types, as shown in Table 1 below. Type 1 is a single basic block function, that is, the function consists of only one basic block, so the in-degree and out-degree of this basic block in the internal control flow graph of the function are both 0. Type 4 is the starting basic block, and Types 2 and 3 are the ending basic blocks. Types 5 and 6 are the regular basic blocks in the internal basic block structure of the function. The basic block structure features include two elements: the out-degree and in-degree of the basic block.

[0076] Value type Basic block in-degree Basic block out-degree 1 0 0 2 1 0 3 >1 0 4 0 1,2 5 1 1,2 6 >1 1,2

[0077] Table 1

[0078] In addition, during the process of extracting the content features of basic blocks, since it is necessary to count the number of instructions of multiple instruction types, and the expressions of instruction types under different instruction set architectures are different. Therefore, for the convenience of counting, in this embodiment, a preset unified expression is used to replace the known expressions of instruction types under multiple different instruction set architectures, and the number of instructions of the preset instruction types in the current basic block is counted according to the unified expression.

[0079] Specifically, there are currently three commonly used instruction set architectures, namely x86, MIPS, and ARM. There are significant differences in the operation codes and operands of instructions under different instruction set architectures. For example, for the x86 and MIPS instruction sets, the operation codes for the same operation are different, the number of operation codes of the same type is different, and the registers for storing operands are also different. Therefore, in order to compare binary files under different instruction set architectures, a method is needed to mask this difference, and the instructions need to be normalized, that is, to find a normalization expression that can not only represent different instruction set architectures, but also summarize the characteristics of different instruction set architectures and can be used for binary comparison.

[0080] Different instruction set architectures have their own characteristics, but all instruction set architectures describe the functional flow of a program through an instruction sequence. The function of a program is mainly controlled by the operation codes of the instructions, and these operation codes can be mainly divided into the following five types: call type, arithmetic type, logical type, access type, and jump type. Instruction operands are mainly stored in registers, and some operands come from memory or immediate values. Usually, only access operations can directly access memory, so registers are the main source of instruction operands. According to the different uses of registers for storing operands in the instruction set, registers are divided into three types: data registers, program control registers, and other registers.

[0081] In summary, according to the different classifications of instruction operation codes and operands, as shown in Table 2 below, instructions are divided into seven types and normalized. When extracting the content features of basic blocks, instructions of control operation types and jump types are not used as features for extraction. The reasons are as follows: a. Control operation instructions are usually located in the starting basic block and ending basic block of a function, and the quantity is small; b. Different instruction set architectures use different calling conventions, and the control operations are also different; c. Jump instructions reflect the connection relationship between basic blocks, and this relationship can be represented by the out-degree of basic blocks in the basic block structure feature vector.

[0082]

[0083] Table 2

[0084] Furthermore, the extraction methods of function features include:

[0085] Count the number of parent functions, child functions, and data reference items related to the current function in the executable file;

[0086] Count the number of basic blocks and the number of edges in the control flow graph of the current function.

[0087] That is, in this embodiment, function features include five feature items, namely the number of parent functions, the number of child functions, the number of basic blocks of data reference items, and the number of edges in the control flow graph. Among them, the number of parent functions and the number of child functions belong to call features, the data reference item belongs to data flow features, and the number of basic blocks and the number of edges in the control flow graph belong to internal features.

[0088] For call features:

[0089] The function call graph consists of all functions and their call relationships in the binary file, and is a directed graph, where functions are nodes and the call relationships between functions are edges. For the same program segment, whether under cross-instruction set architectures or different compilation conditions, its function call graph changes very little, so the changes in these two features, namely the number of parent functions called by the function and the number of child functions called by the function, are also very small. Therefore, these two features are added to the function feature set.

[0090] Regarding the data flow characteristics:

[0091] The data reference graph represents the reference relationship between functions and data. A function may reference multiple data items, and a data item may be referenced by multiple functions. Binary files can usually be divided into different segments according to different functions. The segment named ".data" is the data segment, which is used to store the data of the binary file, such as constants, program control information, strings, etc. For a function to implement its function, it must reference the corresponding data in the data segment. Therefore, the special strings or immediate numbers corresponding to the function can be used as the basis for identifying the function, and such data will not change with the change of the instruction set architecture and compilation conditions. Therefore, the function data reference items are added to the function feature set. The function data reference items include the special strings and the set of immediate numbers referenced by the function.

[0092] Regarding the internal characteristics:

[0093] In this embodiment, the unit body inside the function is the basic block. Therefore, the internal characteristics of the function are represented by the overall characteristics of the basic block. For the content characteristics, since they have been involved in the basic block characteristics, they are not considered here, and only the structural characteristics are considered. The number of basic blocks refers to the number of basic blocks contained in the function, and the number of edges in the internal control flow chart reflects the call relationship between the basic blocks in the function. These two characteristics are both extracted from the internal control flow chart of the function. When the same piece of code is compiled under different instruction set architectures, or the binary files are generated using the same instruction set architecture but different compilers and compilation options, the number of basic blocks and the number of edges in the internal control flow chart of the functions with the same function will not change. Therefore, the two characteristics of the number of basic blocks and the number of edges in the internal control flow chart are added to the function feature set.

[0094] In summary, the method for function similarity matching at the function level includes:

[0095] Construct a function feature vector Sf1(Cn, Pn, SI, Bn, En), where Cn, Pn, Bn, En are numerical type feature data, and SI is string type feature data. Cn is the number of sub-functions, Pn is the number of parent functions, Bn is the number of basic blocks, En is the number of edges in the control flow chart, and SI is the data reference item.

[0096] Use the following formula (1) to calculate the similarity SH of the two functions to be matched, that is, calculate the similarity between the function to be tested and the vulnerability function represented by the feature label in the vulnerability label library.

[0097]

[0098] Among them, L iis the distance between any dimension of the feature vectors Sf1 of the two functions to be matched, and W i is the weight value of this dimension.

[0099] In this embodiment, the Manhattan distance calculation method is used to calculate the distance of numerical type feature data. This method takes the sum of the absolute values of the coordinate differences between two points as the distance between the two points.

[0100] For example, for the distance calculation of the dimension Cn in the feature vector Sf1, formula (2) is used:

[0101] L i = |Cn1 - Cn2| (2)

[0102] Among them, Cn1 and Cn2 respectively represent the values of Cn in the two feature vectors Sf1 to be matched. Accordingly, the distance calculation methods of Pn, Bn, and En are the same as that of Cn, which will not be elaborated here.

[0103] In this embodiment, for the string type feature data SI, the distance between strings in SI is calculated by finding the longest common substring of the two function strings. Assume two different strings C1 and C2, where the length of C1 is L1 and the length of C2 is L2, and Llcs represents the length of the longest common substring of C1 and C2. Then, the distance calculation of C1 and C2 uses formula (3):

[0104] d = 1 - Llcs / max(L1, L2) (3).

[0105] Since a function data reference item usually contains multiple pieces of data, it is necessary to consider the distance of set type data. The data reference items are divided into string type sets and immediate number type sets. For the string type set, assume Z1 and Z2 are the string sets in two function data reference items. N1 and N2 are the number of elements in Z1 and Z2 respectively, ai and bj are the i-th string in Z1 and the j-th string in Z2 respectively, and di and dj represent the distance between the strings ai and bj. Then, the distance calculation between Z1 and Z2 uses formula (4):

[0106]

[0107] For the numerical type set, assume I1 and I2 are the immediate number sets in two function data reference items. N1 and N2 respectively represent the number of elements in I1 and I2, and n represents the number of identical elements in I1 and I2. Then, the distance calculation between the two numerical type sets uses formula (5):

[0108] dI = N1 + N2 - 2 * n (5)

[0109] In addition, since the data types of different function features are different, different methods are used when calculating the distance. In order to eliminate the influence of different calculation methods on the distance value, the distance of various features should also be normalized. The process of normalizing the data belongs to conventional data processing technology and will not be elaborated here.

[0110] Furthermore, the weight of a feature reflects the degree of influence of this feature on the function similarity relative to other features. Measuring the weights of each feature of a function mainly relies on experimental tests.

[0111] Further, the method for basic block similarity matching includes the calculation of basic block content similarity and the calculation of basic block structure similarity.

[0112] The process of calculating the basic block content similarity is as follows:

[0113] First, construct the basic block content feature vector Sf2 = (a, b, c, d), where a is the number of instructions of the arithmetic type of data operation, b is the number of instructions of the call type, c is the number of instructions of the access type of numerical operation, and d is the number of instructions of the logical type;

[0114] Then, use the Pearson correlation coefficient P to represent the similarity score between the two basic block content feature vectors to be matched;

[0115] Next, calculate the basic block content similarity S1 of the two basic blocks to be matched according to the following formula (6):

[0116] S1 = P * W1 (6)

[0117] where W1 is a preset weight value.

[0118] The process of calculating the basic block structure similarity is as follows:

[0119] First, construct the basic block structure feature vector Sf3 = (o, i), where o is the out-degree of the current basic block in the function to which it belongs, and i is the in-degree of the current basic block in the function to which it belongs;

[0120] Then, calculate the similarity score Q of the two basic blocks to be matched according to the following formula (7):

[0121]

[0122] where i1 and i2 respectively represent the in-degree values in the basic block structure feature vector Sf3 of the two basic blocks to be matched;

[0123] Next, calculate the basic block structure similarity S2 of the two basic blocks to be matched according to the following formula (8):

[0124] S2 = Q * W2 (8)

[0125] Among them, W2 is a preset weight value.

[0126] Finally, calculate the similarity SK of two basic blocks according to the following formula (9),

[0127] SK = S1 + S2 (9).

[0128] Furthermore, when a security vulnerability is found in the function to be tested according to the above method, the vulnerability in the function to be tested can also be verified through the corresponding vulnerability verification program and test cases, so as to verify the firmware vulnerability of the target device in a real physical environment, thereby ensuring the accuracy of the detection of firmware program security vulnerabilities. In addition, in this embodiment, a vulnerability verification environment combining a firmware simulation platform and a security test platform is provided. The simulation platform creates a simulated environment for the firmware to run, and dynamically verifies the firmware in the simulated running environment by using the vulnerability verification program. The test platform is based on the real physical environment, and uses the verification program to verify the vulnerability in combination with the test cases. The simulation platform has a higher efficiency in verifying vulnerabilities, but some firmware may not be able to be simulated. Therefore, a test platform in the real physical environment is added as a supplementary vulnerability verification environment.

[0129] In summary, the firmware program vulnerability detection method provided by the present invention determines whether there is a code segment in the firmware program that is the same as the vulnerability code segment based on the method of binary similarity measurement, so as to detect the target vulnerability, thereby effectively ensuring the security performance of the firmware. In addition, when performing similarity measurement, first, candidate feature tags are found through coarse-grained function similarity matching, and then it is accurately determined whether there is a vulnerability in the function to be tested and the type of vulnerability through fine-grained basic block similarity matching, thus taking into account both the efficiency and accuracy of the firmware program vulnerability detection. Finally, the verification program is also used to verify whether the program to be tested actually has the found security vulnerability, thereby making the vulnerability detection work more accurate.

[0130] In another preferred embodiment of the present invention, as Figure 2 , a firmware program vulnerability detection system is also disclosed, which includes a vulnerability library creation module, a disassembly module, a function feature extraction module, a basic block extraction module, a basic block feature extraction module, a primary matching module, a primary screening module, a secondary matching module, and a confirmation module.

[0131] The vulnerability library creation module is used to create a vulnerability label library, and the vulnerability label library stores feature tags of several functions carrying known vulnerabilities. The feature tags include a first tag representing the overall content and structural features of the function and several second tags respectively representing the content and structural features of each basic block in the function.

[0132] The disassembly module is used to obtain the binary file of the firmware program and perform disassembly operations on the executable files in the binary file to extract each function to be tested in the executable files.

[0133] The function feature extraction module is used to extract the function features in any function to be tested, and the function features represent the overall content and structural features of the function to be tested.

[0134] The basic block extraction module is used to extract each basic block in each function to be tested.

[0135] The basic block feature extraction module is used to extract the content and structural features of each basic block to obtain basic block features.

[0136] The primary matching module is used to respectively compare the function features of the function to be tested with the first tags of each feature tag in the vulnerability tag library for function similarity matching.

[0137] The primary screening module is used to screen out several candidate feature tags with high similarity according to the matching results of the primary matching module.

[0138] The secondary matching module is used to pairwise compare the basic block features of each basic block of the current function to be tested with several second tags in the candidate feature tags for basic block similarity matching.

[0139] The confirmation module is used to calculate the final similarity between the function to be tested and the vulnerability functions represented by each candidate feature tag according to the matching results of the secondary matching module to confirm whether the function to be tested has vulnerabilities.

[0140] In this embodiment, the working principle and process of the firmware program vulnerability detection system are as described in the above firmware program vulnerability detection method, which will not be elaborated here.

[0141] The present invention also discloses another firmware program vulnerability detection system, which includes one or more processors, a memory, and one or more programs, wherein one or more programs are stored in the memory and are configured to be executed by the one or more processors. The programs include instructions for executing the firmware program vulnerability detection method as described above. The processor can use a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs to implement the functions required to be executed by the modules in the firmware program vulnerability detection system of the embodiments of the present application, or execute the firmware program vulnerability detection method of the method embodiments of the present application.

[0142] The present invention also discloses a computer-readable storage medium, which includes a computer program, and the computer program can be executed by a processor to complete the firmware program vulnerability detection method as described above. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrating one or more available media. The available medium can be a read-only memory (ROM), a random access memory (RAM), a magnetic medium, for example, a floppy disk, a hard disk, a magnetic tape, a magnetic disk, or an optical medium, for example, a digital versatile disc (DVD), or a semiconductor medium, for example, a solid state disk (SSD), etc.

[0143] The embodiment of the present application also discloses a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the above-mentioned firmware program vulnerability detection method.

[0144] The above-disclosed are only the preferred embodiments of the present invention. Of course, the scope of the rights of the present invention cannot be limited thereby. Therefore, equivalent changes made according to the scope of the patent application of the present invention still fall within the scope covered by the present invention.

Claims

1. A method for detecting firmware program vulnerabilities, characterized in that, include: Creating a vulnerability tag library, wherein the vulnerability tag library stores characteristic tags of functions with known vulnerabilities, wherein the characteristic tags include a first tag representing the overall content and structural features of the function and a plurality of second tags representing the content and structural features of each basic block within the function; Get the binary file of the firmware program; Performing a disassembly operation on the executable file in the binary file to extract each function to be tested in the executable file; For any of the functions to be tested, extract the overall content and structural features of the function to be tested to obtain the function features of the function to be tested, and extract each basic block in the function to be tested; extracting content and structural features of each basic block to obtain basic block features; Comparing the function features of the function to be tested with the first label of each feature label in the vulnerability label library to perform function similarity matching, and screening out several candidate feature labels with high similarity; Comparing the basic block features of each basic block of the current function to be tested with a plurality of second labels in the candidate feature labels in pairs to perform basic block similarity matching, and calculating the final similarity between the function to be tested and the vulnerability function represented by each candidate feature label based on the similarity matching results of all basic blocks in the function to be tested, so as to confirm whether the function to be tested has a vulnerability; Basic block similarity matching methods include: Construct the basic block content feature vector Sf2 = (a, b, c, d), where a is the number of data operation arithmetic type instructions, b is the number of call type instructions, c is the number of numerical operation access type instructions, and d is the number of logical type instructions; The Pearson correlation coefficient P is used to represent the similarity score between the content feature vectors of two basic blocks to be matched; The basic block content similarity S1 of the two basic blocks to be matched is calculated according to the following formula: Among them, is a preset weight value; Construct the basic block structure feature vector Sf3 = (o, i), where o is the out-degree of the current basic block in the function it belongs to, and i is the in-degree of the current basic block in the function it belongs to; The similarity score Q of the two basic blocks to be matched is calculated according to the following formula: （3） Among them, and respectively represent the in-degree values in the basic block structure feature vector Sf3 of two basic blocks to be matched; The basic block structure similarity S2 of the two basic blocks to be matched is calculated according to the following formula: Among them, is a preset weight value; The similarity S between two basic blocks is calculated according to the following formula: S=S1+S2.

2. The firmware program vulnerability detection method according to claim 1, wherein The basic block feature extraction method includes: Counting the number of instructions of a preset instruction type in the current basic block to obtain basic block content characteristics, wherein the preset instruction types include a data operation arithmetic type, a call type, a numerical operation access type, and a logical type; The out-degree and in-degree of the current basic block in its function are counted to obtain the basic block structure characteristics.

3. The firmware program vulnerability detection method according to claim 2, wherein The basic block feature extraction method also includes: A preset unified expression is used to replace expressions of instruction types under multiple known different instruction set architectures, and the number of instructions of the preset instruction type in the current basic block is counted according to the unified expression.

4. The firmware program vulnerability detection method according to claim 1, wherein The method of extracting the function feature includes: Count the number of parent functions, child functions, and data reference items related to the current function in the executable file; The number of basic blocks and the number of control flow graph edges of the current function are counted.

5. The firmware program vulnerability detection method according to claim 4, wherein Function similarity matching methods include: Construct a function feature vector Sf1 = (Cn, Pn, SI, Bn, En), where Cn, Pn, Bn, and En are numerical feature data, Cn is the number of child functions, Pn is the number of parent functions, Bn is the number of basic blocks, En is the number of control flow graph edges, and SI is a data reference item; The similarity S of the two functions to be matched is calculated using the following formula: Among them, is the distance between any two dimensions of the feature vectors Sf1 of the two functions to be matched, is the weight value of this dimension.

6. The firmware program vulnerability detection method according to claim 1, characterized in that When it is determined that the current function to be tested has a vulnerability based on basic block similarity matching, the vulnerability in the function to be tested is verified through the corresponding vulnerability verification program and test instance.

7. A firmware program vulnerability detection system, characterized in that, include: A vulnerability library creation module is used to create a vulnerability tag library. The vulnerability tag library stores characteristic tags of functions with known vulnerabilities. The characteristic tags include a first tag representing the overall content and structural features of the function and a plurality of second tags representing the content and structural features of each basic block within the function. A disassembly module, which is used to obtain a binary file of the firmware program and perform a disassembly operation on the executable file in the binary file to extract each function to be tested in the executable file; A function feature extraction module is used to extract function features from any function to be tested, wherein the function features represent the overall content and structural features of the function to be tested; A basic block extraction module is used to extract each basic block in each function to be tested; A basic block feature extraction module, which is used to extract the content and structural features of each basic block to obtain basic block features; A primary matching module, which is used to compare the function features of the function to be tested with the first label of each feature label in the vulnerability label library to perform function similarity matching; A primary screening module, which is used to screen out several candidate feature tags with high similarity based on the matching results of the primary matching module; A secondary matching module is configured to compare the basic block features of each basic block of the current function to be tested with a plurality of second labels in the candidate feature labels in pairs to perform basic block similarity matching; A confirmation module, configured to calculate a final similarity between the function to be tested and the vulnerability function represented by each candidate feature label based on the matching result of the secondary matching module, so as to confirm whether the function to be tested has a vulnerability; Basic block similarity matching methods include: Construct the basic block content feature vector Sf2 = (a, b, c, d), where a is the number of data operation arithmetic type instructions, b is the number of call type instructions, c is the number of numerical operation access type instructions, and d is the number of logical type instructions; The Pearson correlation coefficient P is used to represent the similarity score between the content feature vectors of two basic blocks to be matched; The basic block content similarity S1 of the two basic blocks to be matched is calculated according to the following formula: Among them, is a preset weight value; Construct the basic block structure feature vector Sf3 = (o, i), where o is the out-degree of the current basic block in the function it belongs to, and i is the in-degree of the current basic block in the function it belongs to; The similarity score Q of the two basic blocks to be matched is calculated according to the following formula: （3） Among them, and respectively represent the in-degree values in the basic block structure feature vector Sf3 of two basic blocks to be matched; Calculate the basic block structure similarity S2 of two basic blocks to be matched according to the following formula Among them, is a preset weight value; Calculate the similarity S of two basic blocks according to the following formula S = S1 + S2 8. A firmware program vulnerability detection system, characterized in that including one or more processors a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the programs include instructions for executing the firmware program vulnerability detection method according to any one of claims 1 to 6 9. A computer-readable storage medium, characterized in that, including a computer program, which can be executed by a processor to complete the firmware program vulnerability detection method according to any one of claims 1 to 6

Images