A Vulnerability Analysis Method, System and Medium for Automotive ECU Firmware

Abstract

The present invention discloses a vulnerability analysis method, system and medium for an automotive ECU firmware. The system includes a static disassembly module, a basic block division module, a control flow graph generation module and a vulnerability analysis module; the vulnerability analysis includes: the vulnerability analysis method includes fine-grained taint analysis, behavior difference analysis and non-negative effect analysis; by using the method and system of the present invention, the software program can be safely analyzed in the absence of the source code of the ECU electronic software program; it no longer depends on prior vulnerability exposure, attack discovery and vulnerability clue knowledge such as security patches; at the same time, it is not necessary to pre-design all inputs covering the execution path of the binary code, and it does not depend on the specific execution environment, and can analyze any code segment.

Description

Technical Field

[0001] The present invention belongs to the technical field of automotive ECU firmware vulnerability analysis, and particularly relates to a method, a system and a medium for analyzing vulnerabilities of automotive ECU firmware. Background Art

[0002] From the perspective of the automotive electronic and electrical architecture, an automobile is a structure composed of ECUs (points) and buses (lines). Attacking an automobile is actually attacking different ECUs. Therefore, for vehicle defense, the security analysis and detection of ECUs are also the primary defense capabilities.

[0003] The security of ECUs involves many aspects such as hardware, operating systems, automotive electronic software, etc. Among them, automotive electronic software directly provides services and functions externally. Therefore, the security analysis of ECU firmware is one of the most important parts for ECU security. Firmware source code is unavailable in most cases of software security analysis. Therefore, firmware binary analysis is used in many aspects, including software forensics, malware analysis, performance analysis, and debugging. Currently, most binary vulnerability analyses belong to vulnerability passive discovery techniques, that is, analyzing the detailed information of vulnerabilities based on captured attack samples or security patches released by the developer.

[0004] The existing common method for analyzing binary vulnerabilities of ECU firmware is to scan based on existing exposed vulnerabilities and related POCs, match information such as versions and patches with the information in the vulnerability database, and screen out binary vulnerabilities according to the matching items. This technical solution requires a based-on existing vulnerability database, and vulnerability identification is lagging rather than ahead. When there are unknown vulnerabilities in the ECU, it is difficult to detect them and they pose a certain threat. Summary of the Invention

[0005] To solve the problem that existing software vulnerability analysis methods are mostly based on the passive discovery and analysis techniques of vulnerability security incidents that have already occurred or security patches for released vulnerabilities, and can only provide remedies after the event and cannot prevent problems before they occur. The present invention proposes a method, a system and a medium for analyzing vulnerabilities of automotive ECU firmware.

[0006] A method for analyzing vulnerabilities of automotive ECU firmware for achieving one of the purposes of the present invention includes the following steps:

[0007] Step 1: Perform static disassembly on the binary of the ECU firmware to obtain the assembly code of the ECU firmware;

[0008] Step 2: Divide the obtained assembly code into multiple basic blocks Block1~Block according to the execution order of the assembly code n, the basic block is a set of consecutive sequence statements with atomicity. Atomicity means that there is only one entry statement and one exit statement in the consecutive sequence statements, which can be controlled to flow in from the first statement and flow out from the last statement, without stopping or branching in the middle; when the program jumps to the basic block, all instructions in the basic block will be executed.

[0009] Further, the division principle of the basic block is the principle of the fewest number of blocks; that is, to make the number of divided basic blocks as few as possible.

[0010] Step 3: Analyze the jump relationship of program execution between each basic block one by one. When the target jumped to after Block i is executed is Block j and j≠i + 1, then construct a directed edge from Block i to Block j , otherwise construct a directed edge from Block i to Block i+1 ; generate a control flow graph based on all basic blocks and each directed edge; where the directed edge is used to control the execution order between basic blocks in vulnerability analysis.

[0011] Step 4: Perform vulnerability analysis on the control flow graph generated in the above step to obtain the vulnerability analysis result of the ECU firmware; the vulnerability analysis method includes performing fine-grained taint analysis, behavior difference analysis, and non-negative effect analysis on the control flow graph.

[0012] Further, the vulnerability analysis method in Step 4 includes:

[0013] Perform fine-grained taint analysis on the control flow graph. When the number of taint marks assigned in a memory unit or register exceeds the first set threshold, it is considered that the analyzed ECU firmware has a vulnerability; the first set threshold is positively correlated with the number of basic blocks.

[0014] Further, the vulnerability analysis method in Step 4 includes:

[0015] Perform behavior difference analysis on the control flow graph: When the proportion of abnormal behaviors of a basic block exceeds the second set threshold, it is considered that the code corresponding to the basic block has a vulnerability; the behavior difference analysis refers to inputting a preset value into the basic block and judging the behavior of the basic block according to the output of the basic block. If the value output by the basic block is different from the preset output value, it is considered that the behavior of the basic block is an abnormal behavior, otherwise it is considered that the behavior of the basic block is a normal behavior.

[0016] When the proportion of abnormal behaviors of the basic block exceeds the second set threshold, it can be to perform various different behavior difference analyses on the same basic block. When the abnormal behaviors of the basic block exceed the second set threshold, it is considered that there is a vulnerability in the analyzed ECU firmware. Specifically, there is a vulnerability in the code corresponding to the basic block. It can also be to perform one or more different behavior difference analyses on each basic block in the control flow graph. When the proportion of the number of basic blocks with abnormal behaviors in all basic blocks exceeds the second set threshold, it is considered that there is a vulnerability in the analyzed ECU firmware.

[0017] Further, the vulnerability analysis method described in step 4 includes:

[0018] Perform a non-negative effect analysis on the control flow graph: If there is a negative effect in the basic block of the current program flow chart, that is, the current basic block has a situation that causes the program to terminate abnormally, it is considered that there is a vulnerability in the analyzed ECU firmware;

[0019] An analysis system for binary vulnerabilities of automotive ECU firmware to achieve the second object of the present invention includes a static disassembly module, a basic block division module, a control flow graph generation module, and a vulnerability analysis module;

[0020] The static disassembly module is used to perform static disassembly on the binary code of the ECU firmware to obtain the assembly code of the ECU firmware;

[0021] The basic block division module is used to divide the obtained assembly code into multiple basic blocks Block1~Block according to the execution order of the assembly code. n The basic block is a set of consecutive sequences of assembly code with atomicity. The atomicity means that the basic block has only one program execution entry and one program execution exit. When the program jumps to the basic block, all instructions in the basic block will be executed;

[0022] The control flow graph generation module is used to analyze the jump relationship of program execution between each basic block one by one. When the target jumped to after Block i is Block j when j≠i + 1, then construct a directed edge pointing from Block i to Block j , otherwise construct a directed edge pointing from Block i to Block i+1 ; Generate a control flow graph according to all the basic blocks and each directed edge; The directed edge is used to control the execution order between basic blocks in the vulnerability analysis module;

[0023] The vulnerability analysis module is used to perform vulnerability analysis on the control flow graph generated by the control flow graph generation module to obtain the vulnerability analysis result of the ECU firmware.

[0024] A non-transitory computer-readable storage medium for achieving the third object of the present invention, on which a computer program is stored, and when the computer program is executed by a processor, any step of the analysis method for binary vulnerabilities of the automotive ECU firmware is implemented.

[0025] Beneficial effects:

[0026] 1. In the case of lacking the source code of the ECU electronic software program, the software program can be safely analyzed;

[0027] 2. It does not rely on prior knowledge of vulnerability clues such as vulnerability exposure, attack discovery, and security patches;

[0028] 3. It is not necessary to pre-design all inputs covering the execution paths of binary codes, does not depend on a specific execution environment, and can analyze any code segment. Description of the drawings

[0029] Figure 1 is a schematic flowchart of analyzing basic blocks in the embodiment of the method of the present invention;

[0030] Figure 2 is a block diagram of the system of the present invention. Detailed implementation manners

[0031] The following detailed implementation manners are used to explain the technical solutions of the claims of the present invention so that those skilled in the art can understand the claims of the present invention. The protection scope of the present invention is not limited to the following specific implementation structures. What those skilled in the art make that includes the technical solutions of the claims of the present invention and is different from the following detailed implementation manners is also within the protection scope of the present invention.

[0032] Embodiment 1

[0033] Step 1: Perform static disassembly on the binary of the ECU firmware to obtain the assembly code of the ECU firmware;

[0034] Step 2: According to the execution order of the assembly code, divide the obtained assembly code into multiple basic blocks Block1 to Block n , where the basic block is a group of consecutive sequence statements with atomicity, and atomicity means that there is only one entry statement and one exit statement in the consecutive sequence statements, which can be controlled to flow in from the first statement and flow out from the last statement, and there is no stop or branch in the middle; when the program jumps to the basic block, all instructions in the basic block will be executed.

[0035] The division principle of the basic block is the principle of the fewest number of blocks; that is, to minimize the number of basic blocks divided as much as possible;

[0036] As Figure 2 shown, the method for dividing the basic block is as follows:

[0037] S1. Set the basic block entry address for the current line of code;

[0038] S2. If the code on the current line is the code for the basic block exit, then define the code on this line as the exit address of the basic block; and set the entry address of this basic block, the code between the entry address and the exit address of the basic block, and the code at the exit address as a basic block, and save this basic block to a basic block array Block i～n in;

[0039] Each element in the basic block array stores the code of a basic block;

[0040] The code for the basic block exit means that there is a code termination or code jump instruction on this line of code; the code termination instruction includes; quit; the code jump instruction includes; LOOPNZ, LOOPNE, jump;

[0041] S3. Determine whether the code has been analyzed completely. If the code has not ended, jump to the next line and return to step S1.

[0042] Step 3. Analyze the jump relationship of the program execution between each basic block one by one. When the target of the jump after Block i executes is Block j , if j≠i + 1, then construct a directed edge from Block i to Block j , otherwise construct a directed edge from Block i to Block i+1 ; Generate a control flow graph based on all the basic blocks and each directed edge; the directed edge is used to control the execution order between basic blocks during vulnerability analysis;

[0043] Step 4. Perform the following vulnerability analysis on the control flow graph generated in the above steps to obtain the vulnerability analysis result of the ECU firmware.

[0044] I. Fine-grained taint analysis

[0045] The taint analysis is an analysis technique applied in fields such as vulnerability discovery and malware analysis. Its basic idea is to analyze whether there are security vulnerabilities and what types of vulnerabilities exist by tracking the propagation process of externally input data in the program and the final execution situation. It does not require any special aggressive test data, but judges the impact of externally transmitted data on jump addresses, return addresses, and function pointers in a traceable manner.

[0046] Fine-grained taint analysis is a type of taint analysis technique, which means that each byte of the input data is independently numbered and marked during the taint marking process, so that the propagation process and status information of each byte of the input data can be independently tracked during the program operation. The taint marking refers to marking the data that directly introduces untrusted data or confidential data in the values input to the program, and may trigger security-sensitive operations or disclose privacy data.

[0047] Perform fine-grained taint analysis on the control flow graph. When the number of taint marks assigned to a memory unit or register exceeds the first set threshold, it is considered that the analyzed ECU firmware has a vulnerability; the first set threshold is positively correlated with the number of basic blocks. In this embodiment, the value of the first set threshold is 20% of the number of basic blocks, but it is not limited to this value and can be determined according to the actual situation.

[0048] II. Behavioral difference analysis

[0049] The behavioral difference analysis refers to inputting a preset value into a basic block. If the obtained output value is the same as the preset output value, the behavior of the basic block is a normal behavior; if there is a difference, the behavior of the basic block is an abnormal behavior.

[0050] Perform behavioral difference analysis on the control flow graph: When the proportion of abnormal behaviors of the basic block exceeds the second set threshold, it is considered that there is a vulnerability in the control flow graph or the code corresponding to the basic block; the second set threshold is 10% in this embodiment, but the present invention is not limited to this value and is set according to actual requirements.

[0051] When the proportion of abnormal behaviors of the basic block exceeds the second set threshold, in one embodiment, it can be to perform multiple different behavioral difference analyses on the same basic block. When the abnormal behaviors of the basic block exceed the second set threshold, it is considered that the analyzed ECU firmware has a vulnerability. Specifically, the code corresponding to the basic block has a vulnerability; in another embodiment, it can also be to perform one or more different behavioral difference analyses on each basic block in the control flow graph. When the proportion of the number of basic blocks with abnormal behaviors among all basic blocks exceeds the second set threshold, it is considered that the analyzed ECU firmware has a vulnerability.

[0052] III. Non-negative effect analysis

[0053] The non - negative - effect analysis means that the current basic block has a situation that may cause the program to terminate abnormally.

[0054] If there is a negative effect in the basic block of the current program flow chart, that is, the current basic block has a situation that may cause the program to terminate abnormally, then it is considered that the analyzed ECU firmware has a vulnerability.

[0055] It should be noted that there is no order of execution for the above three vulnerability analysis processes, and no limitation should be constituted according to the implementation process of the embodiments of the present application.

[0056] Meanwhile, it should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The execution order of each analysis process should be determined by its function and internal logic, and no limitation should be constituted to the implementation process of the embodiments of the present application.

[0057] Embodiment 2

[0058] As Figure 1 shown, an embodiment of an analysis system for automotive ECU firmware binary vulnerabilities is further provided in the embodiments of the present application, including a static disassembly module, a basic block division module, a control flow graph generation module, and a vulnerability analysis module;

[0059] The static disassembly module is used to perform static disassembly on the binary code of the ECU firmware to obtain the assembly code of the ECU firmware;

[0060] The basic block division module is used to divide the obtained assembly code into multiple basic blocks Block1 to Block n , where the basic block is a set of consecutive sequences of assembly code with atomicity. The atomicity means that the basic block has only one program execution entry and one program execution exit. When the program jumps to the basic block, all instructions in the basic block will be executed;

[0061] The control flow graph generation module is used to analyze the jump relationship of program execution between each basic block one by one. When the target of the jump after Block i executes is Block j , if j≠i + 1, then a directed edge pointing from Block i to Block j is constructed, otherwise a directed edge pointing from Block i to Block i+1 is constructed; a control flow graph is generated according to all the basic blocks and each directed edge; where the directed edge is used to control the execution order between basic blocks in the vulnerability analysis module;

[0062] The vulnerability analysis module is used to perform vulnerability analysis on the control flow graph generated by the control flow graph generation module to obtain the vulnerability analysis result of the ECU firmware.

[0063] In another embodiment, the vulnerability analysis module includes a fine-grained taint analysis module, which is used to perform fine-grained taint analysis on the control flow graph. When the number of taint marks assigned to a memory unit or register exceeds the first set threshold, it is considered that the analyzed ECU firmware has a vulnerability.

[0064] In another embodiment, the vulnerability analysis module includes a behavior difference analysis module, which is used to perform behavior difference analysis on the control flow graph. When the proportion of abnormal behaviors of a basic block exceeds the second set threshold, it is considered that the analyzed ECU firmware has a vulnerability.

[0065] In another embodiment, the vulnerability analysis module includes a non-negative effect analysis module, which is used to perform non-negative effect analysis on the control flow graph. When there is a negative effect in the basic block of the control flow graph, that is, the current basic block causes the program to terminate abnormally, it is considered that the analyzed ECU firmware has a vulnerability.

[0066] Embodiment 3

[0067] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions. When the program instructions are executed by a processor, each step of the method described in the present invention is implemented, which will not be elaborated here.

[0068] The computer-readable storage medium may be the internal storage unit of the data transmission device or computer device provided in any of the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device.

[0069] Furthermore, the computer-readable storage medium may also include both the internal storage unit and the external storage device of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store the data to be output or already output.

[0070] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0071] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or a plurality of flows and / or blocks

[0072] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in Figure 1 one or more of the flows Figure 1 or a plurality of flows and / or blocks

[0073] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or a plurality of flows and / or blocks

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those of ordinary skill in the art should understand that: still can modify the specific embodiments of the present invention or make equivalent replacements, and any modification or equivalent replacement without departing from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

[0075] The content not described in detail in this specification belongs to the prior art well-known to those skilled in the art.

Claims

1. A vulnerability analysis method for automotive ECU firmware, characterized in that, The steps include the following: Step 1: Perform static disassembly on the binary code of the ECU firmware to obtain the assembly code of the ECU firmware; Step 2: Divide the obtained assembly code into multiple basic blocks Block1~Block according to the execution order of the assembly code n , where the basic block is a set of consecutive sequences of assembly code that are executed sequentially with atomicity. Atomicity means that the basic block has only one program execution entry and one program execution exit. When the program jumps to the basic block, all instructions in the basic block will be executed until completion; Step 3: Analyze the jump relationships of program execution between each basic block one by one. When the target of the jump after Block i executes is Block j and j ≠ i + 1, then construct a directed edge from Block i to Block j ; otherwise, construct a directed edge from Block i to Block i+1 ; Generate a control flow graph based on all the basic blocks and each directed edge; where the directed edge is used to control the execution order between basic blocks during vulnerability analysis; Step 4: Conduct vulnerability analysis on the control flow graph generated in the above step to obtain the vulnerability analysis result of the ECU firmware; The vulnerability analysis method in Step 4 includes performing behavioral difference analysis on the control flow graph. When the proportion of abnormal behaviors of a basic block exceeds a second set threshold, it is considered that the analyzed ECU firmware has vulnerabilities; When the proportion of abnormal behaviors of a basic block exceeds the second set threshold, it can be that multiple different behavioral difference analyses are performed on the same basic block. When the abnormal behaviors of this basic block exceed the second set threshold, it is considered that the analyzed ECU firmware has vulnerabilities; or it can be that one or more different behavioral difference analyses are performed on each basic block in the control flow graph. When the proportion of the number of basic blocks with abnormal behaviors in all basic blocks exceeds the second set threshold, it is considered that the analyzed ECU firmware has vulnerabilities; The vulnerability analysis method in Step 4 includes performing fine-grained taint analysis on the control flow graph: When the number of taint marks assigned to a memory unit or register exceeds a first set threshold, it is considered that the analyzed ECU firmware has vulnerabilities; The vulnerability analysis method in Step 4 includes performing non-negative effect analysis on the control flow graph. When there is a negative effect in the basic block of the control flow graph, that is, the current basic block causes the program to terminate abnormally, it is considered that the analyzed ECU firmware has vulnerabilities; The method for dividing basic blocks includes: S1: Set the basic block entry address for the current line of code; S2. If the code of the current line is the code for the basic block exit, define the address of this line of code as the exit address of the basic block; and set the entry address of this basic block, between the entry address and the exit address of the basic block, and the code of the exit address as a basic block, and save this basic block to a basic block array Block i~n in; Each element in the basic block array stores the code of a basic block; the code at the exit of the basic block is the line of code where there is a code termination or code jump instruction; S3: Determine whether the code has been analyzed completely. If the code has not ended, jump to the next line and return to Step S1.

2. An automotive ECU firmware vulnerability analysis system adopting the automotive ECU firmware vulnerability analysis method described in claim 1, characterized in that, It includes a static disassembly module, a basic block division module, a control flow graph generation module, and a vulnerability analysis module; The static disassembly module is used to perform static disassembly on the binary code of the ECU firmware to obtain the assembly code of the ECU firmware; The basic block division module is used to divide the obtained assembly code into multiple basic blocks Block1 to Block according to the execution order of the assembly code n , where the basic block is a set of consecutive sequences of assembly code that are executed sequentially with atomicity. Atomicity means that the basic block has only one program execution entry and one program execution exit. When the program jumps to the basic block, all instructions in the basic block will be executed to completion; The control flow graph generation module is used to analyze the jump relationship of program execution between each basic block one by one. When the target of the jump after the execution of Block i is Block j and j≠i + 1, a directed edge pointing from Block i to Block j is constructed. Otherwise, a directed edge pointing from Block i to Block i+1 is constructed. A control flow graph is generated based on all the basic blocks and each directed edge; the directed edge is used to control the execution order between basic blocks in the vulnerability analysis module; The vulnerability analysis module is used to conduct vulnerability analysis on the control flow graph generated by the control flow graph generation module to obtain the vulnerability analysis result of the ECU firmware.

3. The vulnerability analysis system for automotive ECU firmware according to claim 2, wherein, The vulnerability analysis module includes a fine-grained taint analysis module, which is used to perform fine-grained taint analysis on the control flow graph. When the number of taint marks assigned to a memory unit or register exceeds a first set threshold, it is considered that the analyzed ECU firmware has vulnerabilities.

4. The vulnerability analysis system for automotive ECU firmware according to claim 2, characterized in that, The vulnerability analysis module includes a behavioral difference analysis module, which is used to perform behavioral difference analysis on the control flow graph. When the proportion of abnormal behaviors of a basic block exceeds a second set threshold, it is considered that the analyzed ECU firmware has vulnerabilities.

5. The vulnerability analysis system for automotive ECU firmware according to claim 2, characterized in that, characterized in that, The vulnerability analysis module includes a non-negative effect analysis module, which is used to perform non-negative effect analysis on the control flow graph. When there is a negative effect in the basic block of the control flow graph, that is, the current basic block has a situation that causes the program to terminate abnormally, it is considered that the analyzed ECU firmware has a vulnerability.

6. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for analyzing vulnerabilities of the automotive ECU firmware as described in claim 1.

Images