A testing method, apparatus, and electronic device for automotive firmware.

Abstract

This invention discloses a testing method, apparatus, and electronic device for automotive firmware. The method includes: providing automotive firmware to be tested, and corresponding firmware identification information; if the firmware identification information is not found in a preset firmware database, performing firmware simulation based on the automotive firmware to be tested to obtain firmware simulation information corresponding to the automotive firmware to be tested; performing firmware debugging on the firmware simulation information and determining target simulation information based on the firmware debugging results; determining expected input parameters corresponding to the automotive firmware to be tested; and performing firmware testing based on the expected input parameters and the target simulation information to obtain firmware test results. This invention, by performing firmware simulation on the automotive firmware to be tested and performing firmware testing based on the target simulation information and expected input parameters, can avoid the paralysis of the test terminal due to the inability to identify the automotive firmware to be tested, thus improving the comprehensiveness of the test.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, specifically to a testing method, apparatus, and electronic device for vehicle firmware. Background Technology

[0002] As a frequently used mode of transportation, automobiles require testing of their various components to ensure driving safety. Typically, firmware emulation technology is used in conjunction with simulators to simulate the test environment and firmware information, thereby enabling the testing of the vehicle's firmware and identifying potential vulnerabilities or defects.

[0003] Simulation technology has limitations in its implementation. For example, most existing simulation technologies are designed for x86 architecture and Linux-based firmware. For ARM architecture and non-Linux system firmware, due to architectural and system differences, the simulator lacks the necessary operating logic and therefore cannot respond to or perform the tests. Thus, existing technologies have shortcomings in terms of the inability to test specific architectures, specific systems, or conventional automotive firmware, resulting in low test accuracy. Summary of the Invention

[0004] In view of the above-mentioned deficiencies of the prior art, the technical problem to be solved by the present invention is how to improve the comprehensiveness and reliability of vehicle firmware testing.

[0005] To address at least one of the aforementioned technical problems, this invention discloses a testing method, apparatus, and electronic device for vehicle firmware.

[0006] According to one aspect of this disclosure, a testing method for automotive firmware is provided, comprising:

[0007] Provide the vehicle firmware to be tested, and the vehicle firmware to be tested corresponds to firmware identification information;

[0008] If the firmware identifier does not exist in the preset firmware database, firmware simulation is performed based on the vehicle firmware to be tested to obtain firmware simulation information corresponding to the vehicle firmware to be tested.

[0009] Firmware debugging is performed on the firmware simulation information, and the target simulation information is determined based on the firmware debugging results;

[0010] Determine the expected input parameters corresponding to the vehicle firmware to be tested;

[0011] Firmware testing is performed based on the expected input parameters and the target simulation information to obtain firmware test results.

[0012] In some possible embodiments, the step of performing firmware debugging on the firmware simulation information and determining the target simulation information based on the firmware debugging results includes:

[0013] The hardware interaction function corresponding to the simulated target program is determined, and the function address in the hardware interaction function is updated to obtain the updated simulated target program;

[0014] Acquire initial fuzz test data and determine the external input data corresponding to the simulated target program;

[0015] Based on the initial fuzz test data and the external input data, firmware driver debugging is performed on the simulated target program to obtain firmware debugging results; the firmware debugging results include updated fuzz test data and path feedback information.

[0016] The firmware simulation information, the updated simulation target program, the updated fuzz test data, and the path feedback information are determined to be the target simulation information.

[0017] In some possible embodiments, the step of performing firmware driver debugging on the simulated target program based on the initial fuzz test data and the external input data to obtain firmware debugging results includes:

[0018] Obtain the conditional constraint model;

[0019] The initial fuzzy test data is input into the conditional constraint model to obtain the data constraint conditions corresponding to the initial fuzzy test data.

[0020] Based on the data constraints and the external input data, the initial fuzzy test data is updated to obtain the updated fuzzy test data.

[0021] Based on the updated fuzzy test data, firmware driver debugging is performed on the simulated target program to obtain the firmware debugging results.

[0022] In some possible embodiments, the step of performing firmware driver debugging on the simulated target program based on the updated fuzz test data to obtain the firmware debugging result includes:

[0023] The updated fuzz test data is input into the simulated target program;

[0024] The simulated target program is driven to perform symbolic execution on the updated fuzzy test data, and the program execution status of the simulated target program is determined.

[0025] When the program execution status corresponds to an execution exception, the symbol execution is terminated and the first execution result corresponding to the updated fuzz test data is generated.

[0026] The updated fuzzy test data is specifically executed to obtain the second execution result corresponding to the updated fuzzy test data;

[0027] The first execution result and the second execution result are determined to be the firmware debugging results, and both the first execution result and the second execution result include the path feedback information.

[0028] In some possible embodiments, the method further includes:

[0029] The program execution status is subjected to function type detection to obtain the function detection result;

[0030] When the function detection result indicates that the function type of the currently executing function is a long loop function and the execution type is symbolic execution, the symbolic execution of the currently executing function is terminated, and the current executing function is then executed.

[0031] In some possible embodiments, the method further includes:

[0032] Compare the number of execution cycles of the function with the number of preset execution cycles;

[0033] When the function execution period is greater than the preset execution period, the function corresponding to the function execution period is determined to be a long loop function.

[0034] In some possible embodiments, after providing the vehicle firmware to be tested, the method includes:

[0035] Construct the initialization program corresponding to the vehicle firmware to be tested;

[0036] Obtain the program data information corresponding to the initialization program; the program data information includes function address information;

[0037] Binary static analysis is performed based on the program data information, and symbol information included in the program data information is extracted based on the static analysis results;

[0038] Based on the symbol information and the function address information, a firmware symbol table corresponding to the vehicle firmware under test is constructed.

[0039] According to a second aspect of this disclosure, a testing apparatus for automotive firmware is provided, the apparatus comprising:

[0040] The firmware determination module is used to provide the vehicle firmware to be tested, and the vehicle firmware to be tested corresponds to firmware identification information;

[0041] The firmware simulation module is used to perform firmware simulation based on the vehicle firmware to be tested when the firmware identifier does not exist in the preset firmware database, and to obtain firmware simulation information corresponding to the vehicle firmware to be tested.

[0042] The firmware debugging module is used to debug the firmware simulation information and determine the target simulation information based on the firmware debugging results.

[0043] The parameter determination module is used to determine the expected input parameters corresponding to the vehicle firmware under test.

[0044] The firmware testing module is used to perform firmware testing based on the expected input parameters and the target simulation information, and obtain firmware test results.

[0045] According to a third aspect of this disclosure, an electronic device is provided, the electronic device including a processor and a memory, the memory storing at least one instruction and at least one program, the at least one instruction and the at least one program being loaded and executed by the processor to implement the testing method for automotive firmware as described above.

[0046] According to a fourth aspect of this disclosure, a computer storage medium is provided, wherein at least one instruction and at least one program are stored therein, the at least one instruction and the at least one program being loaded and executed by a processor to implement the testing method for automotive firmware as described above.

[0047] Implementing this invention has the following beneficial effects:

[0048] In this invention, the first step for testing the vehicle firmware is to determine whether it is a known device based on its firmware identification information, i.e., to determine whether there is firmware identification information matching the vehicle firmware under test in the preset firmware database. Further, if the vehicle firmware under test is an unknown device, firmware simulation is performed to obtain firmware simulation information. Then, firmware debugging is performed based on the firmware simulation information to obtain target simulation information corresponding to the vehicle firmware under test. By combining the expected input parameters and the target simulation information, the test terminal can still perform tests based on the target simulation information when facing an unknown device, thereby improving the comprehensiveness and reliability of vehicle firmware testing. Attached Figure Description

[0049] To more clearly illustrate the technical solution of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a flowchart illustrating a testing method for automotive firmware provided in an embodiment of the present invention.

[0051] Figure 2 This is a schematic diagram illustrating the process of constructing the firmware symbol table provided in this embodiment of the invention.

[0052] Figure 3 This is an architecture diagram of the vehicle firmware to be tested provided in a specific embodiment of the present invention;

[0053] Figure 4 An architecture diagram of an embedded simulation framework provided in a specific embodiment of the present invention;

[0054] Figure 5 This is a schematic diagram of the first process corresponding to firmware debugging provided in an embodiment of the present invention;

[0055] Figure 6 This is a schematic diagram of the second process corresponding to firmware debugging provided in an embodiment of the present invention;

[0056] Figure 7 This is a schematic diagram of the third process corresponding to firmware debugging provided in an embodiment of the present invention;

[0057] Figure 8 This is an architecture diagram of a firmware dynamic debugging system provided in a specific embodiment of the present invention;

[0058] Figure 9 This is a schematic diagram of the structure of a testing device for vehicle firmware provided in an embodiment of the present invention. Detailed Implementation

[0059] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0060] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such as a process, method, system, product, or server that includes a series of steps or units, not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0061] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0062] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0063] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0064] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0065] Figure 1 This diagram illustrates a flowchart of a testing method for automotive firmware provided in an embodiment of the present invention. The executing entity can be any terminal device capable of implementing the testing method for automotive firmware, such as a QEMU (QuickEMU latator). Please refer to [link to relevant documentation]. Figure 1 A testing method for automotive firmware, comprising:

[0066] Step S101: Provide the vehicle firmware to be tested, which has corresponding firmware identification information;

[0067] In one feasible embodiment, the vehicle firmware to be tested can be an external hardware device applied to the vehicle, such as a register, and can be equipped with an ARM architecture or a non-Linux system, such as an embedded QNX system. That is, the embodiments disclosed in this invention can be considered to be mainly used to implement QEMU testing of ARM-based QNX vehicle firmware, and can also be used to implement QEMU testing of any unknown peripheral device based on the vehicle firmware testing method disclosed in this invention. Firmware identification information is used to characterize whether the vehicle firmware to be tested is a known device or an unknown device. A known device is a vehicle firmware that the emulator has previously tested and / or interacted with and can respond to. An unknown device is a vehicle firmware that the emulator first obtains information from and / or tests.

[0068] Figure 2 This is a schematic diagram illustrating the process of constructing the firmware symbol table provided in an embodiment of the present invention. Figure 3 For an architecture diagram of the vehicle firmware under test provided in a specific embodiment of the present invention, please refer to [link / reference]. Figure 2-3 After providing the vehicle firmware to be tested, the method includes:

[0069] Step S201: Construct the initialization program corresponding to the vehicle firmware to be tested;

[0070] In one specific embodiment, after providing the vehicle firmware to be tested, the vehicle firmware to be tested can be initialized first. The initialization objects may include boot simulation and symbolic execution engine initialization. The initialization execution steps may include: simulating the stack in IPL (Initial Program Load), locating and loading the operating system image, completing hardware initialization configuration, the symbolic execution engine obtaining basic information and initializing the execution environment, marking the memory area used by peripherals as unimplemented, that is, the firmware identification information corresponding to the vehicle firmware to be tested is an unknown device, constructing the program initialization data structure and obtaining the initialization program.

[0071] Step S202: Obtain the program data information corresponding to the initialization program; the program data information includes function address information;

[0072] Step S203: Perform binary static analysis based on the program data information, and extract the symbol information included in the program data information based on the static analysis results;

[0073] In one specific embodiment, the program data information may include at least function address information and function call relationships; binary static analysis is performed on the initialization program, and symbol information is extracted from the static analysis results. The symbol information may include function names, function address information, etc.

[0074] Step S204: Construct a firmware symbol table corresponding to the vehicle firmware to be tested based on the symbol information and the function address information.

[0075] In a specific embodiment, matching can be performed based on function names, function address information, function call relationships, etc., and a corresponding firmware symbol table can be constructed. The firmware symbol table can include function names, function address information, function call relationships, and symbol value information. Among them, the function address information can correspond to the address of each function and is used to locate the entry address of the function during program execution. The symbol value information can be the symbol value associated with each function and is used to solve constraints during symbol execution.

[0076] During the firmware boot phase, generating a firmware symbol table facilitates the modification of function addresses. For example, based on the configuration of the input program read from external storage, the corresponding function addresses in the firmware symbol table can be modified. This allows for the modification of faulty chip programs or firmware programs to match the programs configured in the input program, thus enabling program repair. Functions within the firmware can be directly used through the function addresses in the firmware symbol table without importing other programs, reducing duplicate code and the size of the input program image, thereby improving firmware boot speed. If clock and memory initialization functions exist in the input program image, the correct function addresses can be directly obtained from the firmware symbol table and executed. This allows for timely initialization of critical devices such as the clock and memory during firmware boot, enabling operation at higher clock frequencies and within full memory space during subsequent boot processes.

[0077] Step S102: If the firmware identifier does not exist in the preset firmware database, perform firmware simulation based on the vehicle firmware to be tested to obtain firmware simulation information corresponding to the vehicle firmware to be tested.

[0078] In one specific embodiment, the firmware identifier can first be searched in a preset firmware database to determine whether the vehicle firmware to be tested is a known device or an unknown device. If it is a known device, the vehicle firmware to be tested can be tested according to the conventional testing procedure. If it is an unknown device, firmware simulation needs to be performed on the vehicle firmware to be tested first to obtain the corresponding firmware simulation information. Figure 4 An architecture diagram of an embedded simulation framework provided for a specific embodiment of the present invention can be based on... Figure 4The hybrid execution debugging framework shown simulates the vehicle firmware under test. Since the vehicle firmware under test carries a target program, the firmware simulation information includes not only the hardware and configuration information corresponding to the vehicle firmware under test, but also the simulated target program corresponding to the target program.

[0079] Step S103: Perform firmware debugging on the firmware simulation information, and determine the target simulation information based on the firmware debugging results;

[0080] In one specific embodiment, after obtaining the firmware simulation information, firmware debugging is performed on the firmware simulation information to determine the target simulation information. This target simulation information can be considered to be obtained by the simulator through firmware simulation and debugging of the vehicle-mounted firmware under test. Specifically, Figure 5 This is a schematic diagram of the first process corresponding to firmware debugging provided in an embodiment of the present invention, such as... Figure 5 As shown, the step of debugging the firmware simulation information and determining the target simulation information based on the firmware debugging results includes:

[0081] Step S501: Determine the hardware interaction function corresponding to the simulated target program, and update the function address in the hardware interaction function to obtain the updated simulated target program;

[0082] In one specific embodiment, the system first obtains the plt address of the library function, as well as the offset address and actual address of each section by parsing the configuration file of the system. Then, it matches the interface corresponding to the hardware interaction function that needs to be instrumented, rewrites the code at the address source, and writes the code for simulating hardware interaction in the newly expanded code area to obtain the updated simulation target program.

[0083] Step S502: Obtain initial fuzz test data and determine the external input data corresponding to the simulated target program;

[0084] Step S503: Based on the initial fuzz test data and the external input data, perform firmware driver debugging on the simulated target program to obtain firmware debugging results; the firmware debugging results include updated fuzz test data and path feedback information.

[0085] Step S504: Determine that the firmware simulation information, the updated simulation target program, the updated fuzz test data, and the path feedback information are the target simulation information.

[0086] In one specific embodiment, instrumentation analysis is performed on the external input data corresponding to the simulated target program, and the binary code corresponding to the simulated target program is translated into VEXI R intermediate language and instrumented with jump addresses associated with the external input data. Specifically, a simulator can be generated and configured, and unknown device peripherals can be configured to read the program. When the simulator executes the binary program, it triggers different conditional constraints according to different conditions, solves symbolic execution constraints, and thus covers exception error handling. When the simulator runs, when it reaches a branch jump, it saves the processor context information and another non-executable control flow branch, and continues execution. When it reaches the end address, it switches to the previously non-executable control flow branch by backtracking and restores the processor context information for simulation. When all control flow branches have been executed, the simulator stops running. A structure is used to store the number of instrumented symbolic execution branch jumps and which branch of the symbolic execution branch jump is executed, thereby realizing the instrumentation of jump addresses associated with external input data.

[0087] Figure 6 This diagram illustrates the second process for firmware debugging provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the firmware driver debugging of the simulated target program based on the initial fuzz test data and the external input data, to obtain the firmware debugging results, includes:

[0088] Step S601: Obtain the condition constraint model;

[0089] Step S602: Input the initial fuzzy test data into the condition constraint model to obtain the data constraint conditions corresponding to the initial fuzzy test data;

[0090] Step S603: Based on the data constraints and the external input data, update the initial fuzzy test data to obtain the updated fuzzy test data;

[0091] In one specific embodiment, the simulator can provide a constraint model for generating data constraints, thereby solving the constraints on the fuzzy test data based on the data constraints. Specifically, fuzzy test samples and symbolic constraint solutions are generated based on the constructed model constraints; the weights of the completed fuzzy test samples are updated and sorted; multiple fuzzy test samples are selected, and updated fuzzy test data is obtained using a sample mutation algorithm.

[0092] Since QEMU may not be able to respond to unknown devices, test sample data matching the vehicle firmware under test can be obtained by constraining the simulated test data.

[0093] Step S604: Based on the updated fuzz test data, perform firmware driver debugging on the simulated target program to obtain the firmware debugging results.

[0094] Specifically, Figure 7 This is a schematic diagram of the third process corresponding to firmware debugging provided in an embodiment of the present invention. Figure 8 For an architecture diagram of the firmware dynamic debugging system provided in this embodiment of the invention, please refer to [link / reference]. Figure 7 as well as Figure 8 The step S604, which involves debugging the firmware driver of the simulated target program based on the updated fuzz test data to obtain the firmware debugging result, may include:

[0095] Step S701: Input the updated fuzz test data into the simulation target program;

[0096] Step S702: Drive the simulated target program to perform symbolic execution on the updated fuzzy test data, and determine the program execution status of the simulated target program;

[0097] In one specific embodiment, during the fuzzing of a simulated target program using updated fuzzing data for both concrete and symbolic execution, the goal of symbolic execution is to find the optimal path and direct QEMU to this path. The optimal path information needs to pass internal firmware checks and avoid interrupting firmware execution. Symbolic execution can be implemented using a set of firmware-specific heuristics to avoid generating problematic external device inputs that could lead to execution interruptions.

[0098] For symbolic execution, the first instruction is always an external fetch, and correspondingly, a set of symbolic variables is allocated for the external fetch. In each branch of execution, for each explicit instruction that requires a context switch, symbolic execution is terminated and execution is transferred to the concrete execution, so that symbolic execution can always maintain its original execution mode. Resolved symbols are stored for replay. For instructions that are unrecognized and do not affect the program control flow, NOP instructions are used to replace them. For unrecognized instructions that directly change the control flow or update general-purpose registers, symbolic execution is terminated.

[0099] Step S703: When the program execution state corresponds to an execution exception, terminate the symbol execution and generate the first execution result corresponding to the updated fuzzy test data;

[0100] In a specific embodiment, the program execution state may include at least: execution type, execution result, execution function type, and function execution cycle. The execution type may include symbolic execution and concrete execution. The execution result may include normal execution and execution exception. The execution function type may include long loop function and short loop function. The function execution cycle can be accumulated according to the number of times the function is executed.

[0101] Since QEMU cannot respond to unknown devices, the corresponding execution type in the program execution state will be transferred to symbolic execution. During symbolic execution, each unknown device access is symbolized, generating a symbolic list. Each time a branch is encountered, the execution path selection algorithm chooses the optimal path information. For cases such as synchronization exceptions and exception returns, symbolic execution is terminated, and the corresponding first execution result is generated.

[0102] Determining the optimal path can be achieved through the following steps:

[0103] Step 1: Determine if any of the paths a branch leads to contain infinite loops. If all paths contain infinite loops, mark the branch and compare the execution states of each path. If any two states are the same, it means that the processor registers have not changed at different times, and we consider the corresponding path to be an infinite loop and skip its execution.

[0104] Step 2: Considering that branches marked as infinite loops may be filtered incorrectly, this mark will be selected with the lowest priority; thus, when execution switches back to specific execution, interruptions can be triggered and handled, thereby effectively unlocking the infinite loop.

[0105] Step 3: Record the paths that keep failing and being executed in the while loop, and perform a similarity check on them. Symbolic execution will select a new path and exclude completely similar paths until all paths have been exhausted.

[0106] Step 4: If there are still multiple candidate paths, select the one with the most branches; if the above steps cannot identify a branch, select a backtracking branch and continue executing the above steps.

[0107] Step S704: Perform the specific execution on the updated fuzzy test data to obtain the second execution result corresponding to the updated fuzzy test data;

[0108] When symbolic execution terminates, the value of the list of symbols that will be navigated to the current path is calculated, and the resolved value is provided to QEMU to implement concrete execution. Firmware execution is driven by constantly switching between concrete execution and symbolic execution.

[0109] Specifically, the process of transferring the program's execution state to the symbolic execution process can include: inferring the expected behavior of the firmware and the satisfiability model theory through the Angr symbolic execution auxiliary simulator to infer the expected inputs from the peripherals, and dynamically providing them to the simulated firmware to generate appropriate inputs to dynamically guide the execution.

[0110] Step S705: Determine that the first execution result and the second execution result are the firmware debugging results, and both the first execution result and the second execution result include the path feedback information.

[0111] In one specific embodiment, the mutation process of the fuzz test samples can be optimized by using updated fuzz test data to specifically execute the simulated target program, simulate execution by the symbolic execution system, and path feedback information. Monitoring is implemented through network and local processes. When no feedback is received from the simulated target program for a preset time or when the target process in the simulated target program is detected to have died, the fuzz test samples executed this time are saved to local storage and the target process is restarted.

[0112] Since the symbolic execution process can determine the optimal path information, the first execution result and the second execution result can be determined as firmware debugging results, and the optimal path information can be obtained.

[0113] Furthermore, long loops consume a significant amount of time during program execution; therefore, when long loops exist, the execution type is transferred to specific execution. Similarly, when the maximum execution branch limit is reached (i.e., the execution depth is reached), the execution type is also transferred to specific execution. The simulated target program includes multiple functions, and the program execution state includes the execution type and the type of the executed function. The method further includes:

[0114] The program execution status is subjected to function type detection to obtain the function detection result;

[0115] When the function detection result indicates that the function type of the currently executing function is a long loop function and the execution type is symbolic execution, the symbolic execution of the currently executing function is terminated, and the current executing function is then executed.

[0116] In one specific embodiment, when a function of type long loop is detected, symbolic execution can be terminated and the process can jump to actual execution to reduce the time and computational resource consumption of the fuzzing process, thereby improving testing efficiency.

[0117] For the function types of each function in the simulated target program, whether it is a long loop function can be determined based on its execution cycle. Specifically, the number of execution cycles of the function can be compared with the number of preset execution cycles. If the execution cycle of the function is greater than the preset execution cycle, the function corresponding to the execution cycle is determined to be a long loop function. The number of preset execution cycles can be 5.

[0118] Step S104: Determine the expected input parameters corresponding to the vehicle firmware to be tested;

[0119] In one specific embodiment, when the firmware of the vehicle under test is from an unknown device, the emulator may become unresponsive and crash. If the emulator provides random values, execution is likely to stall; therefore, it is necessary to calculate the expected input parameters. When a branch is encountered, a path selection algorithm is run to choose the optimal path. When symbol execution terminates, the value of the list of symbols that will navigate to the optimal path is calculated and provided to QEMU to determine the expected input parameters. The expected input parameters can be determined using a context-preserving scan algorithm.

[0120] Specifically, the context-preserving scan algorithm can be performed through the following steps:

[0121] Step 1: Initialize the context information table; Create a context information table before starting the scan to record the data blocks that have been processed and their related information;

[0122] Step 2: Data Scan: Scan the context information table in a certain order and check whether each data block already exists in the context information table;

[0123] Step 3: Update the context information table: If the data block does not exist in the context information table, add its relevant information to the context information table; if the data block already exists in the context information table, skip the processing of the data block.

[0124] Step 4: Process data blocks: For each data block that is not skipped, perform the corresponding processing operation according to its contents, and save the result to the context information table.

[0125] Step 5: Repeat steps 2-4 until all data blocks have been processed and the expected input parameters are obtained. The scan depth can be set to 5.

[0126] Step S105: Perform firmware testing based on the expected input parameters and the target simulation information to obtain firmware test results.

[0127] In one specific embodiment, the testing of the vehicle firmware under test is achieved by combining expected input parameters and target simulation information. Specifically,

[0128] This invention also provides a testing device for automotive firmware, such as... Figure 9 As shown, the device includes:

[0129] Firmware determination module 910 is used to provide vehicle firmware to be tested, wherein the vehicle firmware to be tested corresponds to firmware identification information.

[0130] Firmware simulation module 920 is used to perform firmware simulation based on the vehicle firmware to be tested when the firmware identifier does not exist in the preset firmware database, so as to obtain firmware simulation information corresponding to the vehicle firmware to be tested.

[0131] Firmware debugging module 930 is used to perform firmware debugging on the firmware simulation information and determine the target simulation information based on the firmware debugging results;

[0132] The parameter determination module 940 is used to determine the expected input parameters corresponding to the vehicle firmware under test.

[0133] Firmware testing module 950 is used to perform firmware testing based on the expected input parameters and the target simulation information, and obtain firmware test results.

[0134] In other embodiments, the firmware debugging module 930 includes:

[0135] The interaction function determination module is used to determine the hardware interaction function corresponding to the simulated target program, and update the function address in the hardware interaction function to obtain the updated simulated target program.

[0136] The data acquisition module is used to acquire initial fuzzy test data and determine the external input data corresponding to the simulated target program;

[0137] The first debugging module is used to perform firmware driver debugging on the simulated target program based on the initial fuzz test data and the external input data, and obtain firmware debugging results; the firmware debugging results include updated fuzz test data and path feedback information.

[0138] The first information determination module is used to determine that the firmware simulation information, the updated simulation target program, the updated fuzzy test data, and the path feedback information are the target simulation information.

[0139] In other embodiments, the first debugging module includes:

[0140] The model acquisition module is used to acquire conditional constraint models;

[0141] The condition determination module is used to input the initial fuzzy test data into the condition constraint model to obtain the data constraint conditions corresponding to the initial fuzzy test data.

[0142] The data update module is used to update the initial fuzzy test data based on the data constraints and the external input data to obtain the updated fuzzy test data.

[0143] The second debugging module is used to perform firmware driver debugging on the simulated target program based on the updated fuzzy test data, and obtain the firmware debugging results.

[0144] In other embodiments, the second debugging module includes:

[0145] The data input module is used to input the updated fuzz test data into the simulated target program;

[0146] The first execution module is used to drive the simulated target program to perform symbolic execution on the updated fuzzy test data and determine the program execution status of the simulated target program;

[0147] The first termination module is used to terminate the execution of the symbol and generate the first execution result corresponding to the updated fuzzy test data when the program execution state corresponds to an execution exception.

[0148] The second execution module is used to specifically execute the updated fuzzy test data to obtain the second execution result corresponding to the updated fuzzy test data;

[0149] The second information determines that the first execution result and the second execution result are the firmware debugging results, and both the first execution result and the second execution result include the path feedback information.

[0150] In other embodiments, the device further includes:

[0151] The type detection module is used to perform function type detection on the program execution state and obtain the function detection result;

[0152] The second termination module is used to terminate the symbolic execution of the current execution function and perform specific execution on the current execution function when the function detection result indicates that the execution function type of the current execution function is a long loop function and the execution type is symbolic execution.

[0153] In other embodiments, the device further includes:

[0154] The comparison module is used to compare the number of execution cycles of the function with the number of preset execution cycles;

[0155] The function type determination module is used to determine that the function corresponding to the function execution period is a long loop function when the function execution period is greater than the preset execution period.

[0156] In other embodiments, the device further includes:

[0157] The program construction module is used to construct the initialization program corresponding to the vehicle firmware to be tested;

[0158] The program information acquisition module is used to acquire program data information corresponding to the initialization program; the program data information includes function address information.

[0159] The static analysis module is used to perform binary static analysis based on the program data information, and to extract symbol information included in the program data information based on the static analysis results;

[0160] The symbol table construction module is used to construct a firmware symbol table corresponding to the vehicle firmware under test based on the symbol information and the function address information.

[0161] The apparatus and method embodiments described above are based on the same inventive concept and are used to implement the above-described testing method for vehicle firmware.

[0162] This invention also provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement a testing method for automotive firmware as described in any of the method embodiments.

[0163] Embodiments of the present invention also provide a storage medium, which may be disposed in a server to store at least one instruction, at least one program, code set, or instruction set for implementing a test method for automotive firmware as described in any of the method embodiments. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the test method for automotive firmware as described in any of the method embodiments.

[0164] Optionally, in embodiments of the present invention, the storage medium may be located at at least one of multiple network servers in a computer network. Optionally, in embodiments of the present invention, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0165] As can be seen from the embodiments provided by the present invention, in the present invention, for the vehicle firmware to be tested, it is first determined whether it is a known device based on its firmware identification information, that is, whether there is firmware identification information matching the vehicle firmware to be tested in the preset firmware database; furthermore, when the vehicle firmware to be tested is an unknown device, firmware simulation is performed to obtain firmware simulation information, and then firmware debugging is performed based on the firmware simulation information to obtain target simulation information corresponding to the vehicle firmware to be tested. By combining the expected input parameters and the target simulation information, the test terminal can still perform tests based on the target simulation information when facing an unknown device, thereby improving the comprehensiveness and reliability of vehicle firmware testing.

[0166] It should be noted that the various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technological improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A testing method for automotive firmware, characterized in that, The method includes: Provide the vehicle firmware to be tested, and the vehicle firmware to be tested corresponds to firmware identification information; If the firmware identifier does not exist in the preset firmware database, firmware simulation is performed based on the vehicle firmware to be tested to obtain firmware simulation information corresponding to the vehicle firmware to be tested. Firmware debugging is performed on the firmware simulation information, and the target simulation information is determined based on the firmware debugging results; Determine the expected input parameters corresponding to the vehicle firmware under test; Firmware testing is performed based on the expected input parameters and the target simulation information to obtain firmware test results. The vehicle firmware to be tested carries a target program; the firmware simulation information includes a simulated target program corresponding to the target program. The step of debugging the firmware simulation information and determining the target simulation information based on the firmware debugging results includes: The hardware interaction function corresponding to the simulated target program is determined, and the function address in the hardware interaction function is updated to obtain the updated simulated target program; Acquire initial fuzz test data and determine the external input data corresponding to the simulated target program; Based on the initial fuzz test data and the external input data, firmware driver debugging is performed on the simulated target program to obtain firmware debugging results; the firmware debugging results include updated fuzz test data and path feedback information. The firmware simulation information, the updated simulation target program, the updated fuzz test data, and the path feedback information are determined to be the target simulation information; After providing the vehicle firmware to be tested, the method includes: Construct the initialization program corresponding to the vehicle firmware to be tested; Obtain the program data information corresponding to the initialization program; the program data information includes function address information; Binary static analysis is performed based on the program data information, and symbol information included in the program data information is extracted based on the static analysis results; Based on the symbol information and the function address information, a firmware symbol table corresponding to the vehicle firmware under test is constructed.

2. The testing method for automotive firmware according to claim 1, characterized in that, The firmware driver debugging of the simulated target program based on the initial fuzz test data and the external input data, to obtain firmware debugging results, includes: Obtain the condition constraint model; The initial fuzzy test data is input into the conditional constraint model to obtain the data constraint conditions corresponding to the initial fuzzy test data. Based on the data constraints and the external input data, the initial fuzzy test data is updated to obtain the updated fuzzy test data. Based on the updated fuzzy test data, firmware driver debugging is performed on the simulated target program to obtain the firmware debugging results.

3. The testing method for automotive firmware according to claim 2, characterized in that, The firmware driver debugging of the simulated target program based on the updated fuzz test data, to obtain the firmware debugging results, includes: The updated fuzz test data is input into the simulated target program; The simulated target program is driven to perform symbolic execution on the updated fuzzy test data, and the program execution status of the simulated target program is determined. When the program execution status corresponds to an execution exception, the symbol execution is terminated and the first execution result corresponding to the updated fuzz test data is generated. The updated fuzzy test data is specifically executed to obtain the second execution result corresponding to the updated fuzzy test data; The first execution result and the second execution result are determined to be the firmware debugging results, and both the first execution result and the second execution result include the path feedback information.

4. The testing method for vehicle-mounted firmware according to claim 3, characterized in that, The simulated target program includes multiple functions, and the program execution state includes the execution type and the type of the executed function. The method further includes: The program execution status is subjected to function type detection to obtain the function detection result; When the function detection result indicates that the function type of the currently executing function is a long loop function and the execution type is symbolic execution, the symbolic execution of the currently executing function is terminated, and the current executing function is then executed.

5. The testing method for automotive firmware according to claim 1, characterized in that, The simulated target program includes multiple functions; the program execution status also includes the execution cycle of each function; The method further includes: Compare the number of execution cycles of the function with the number of preset execution cycles; When the function execution period is greater than the preset execution period, the function corresponding to the function execution period is determined to be a long loop function.

6. A testing device for automotive firmware, characterized in that, The device includes: The firmware determination module is used to provide the vehicle firmware to be tested, and the vehicle firmware to be tested corresponds to firmware identification information; The firmware simulation module is used to perform firmware simulation based on the vehicle firmware to be tested when the firmware identifier does not exist in the preset firmware database, and to obtain firmware simulation information corresponding to the vehicle firmware to be tested. The firmware debugging module is used to debug the firmware simulation information and determine the target simulation information based on the firmware debugging results. The parameter determination module is used to determine the expected input parameters corresponding to the vehicle firmware under test. The firmware testing module is used to perform firmware testing based on the expected input parameters and the target simulation information, and obtain firmware test results. The vehicle firmware to be tested carries a target program; the firmware simulation information includes a simulated target program corresponding to the target program. The step of debugging the firmware simulation information and determining the target simulation information based on the firmware debugging results includes: The hardware interaction function corresponding to the simulated target program is determined, and the function address in the hardware interaction function is updated to obtain the updated simulated target program; Acquire initial fuzz test data and determine the external input data corresponding to the simulated target program; Based on the initial fuzz test data and the external input data, firmware driver debugging is performed on the simulated target program to obtain firmware debugging results; the firmware debugging results include updated fuzz test data and path feedback information. The firmware simulation information, the updated simulation target program, the updated fuzz test data, and the path feedback information are determined to be the target simulation information; The device is also used to: construct an initialization program corresponding to the vehicle firmware to be tested; Obtain the program data information corresponding to the initialization program; the program data information includes function address information; Binary static analysis is performed based on the program data information, and symbol information included in the program data information is extracted based on the static analysis results; Based on the symbol information and the function address information, a firmware symbol table corresponding to the vehicle firmware under test is constructed.

7. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one instruction and at least one program, the at least one instruction and the at least one program being loaded and executed by the processor to implement the testing method for automotive firmware as described in any one of claims 1-5.

8. A computer storage medium, characterized in that, The computer storage medium stores at least one instruction and at least one program, which are loaded and executed by a processor to implement the testing method for vehicle firmware as described in any one of claims 1-5.

Images