Test method and device applied to vehicle-mounted firmware and electronic equipment

Abstract

The invention discloses a test method and device applied to vehicle-mounted firmware and electronic equipment, and the method comprises the steps: providing the vehicle-mounted firmware to be tested, and enabling the vehicle-mounted firmware to be tested to correspond to firmware identification information; under the condition that the firmware identifier does not exist in the preset firmware database, performing firmware simulation based on the to-be-tested vehicle-mounted firmware to obtain firmware simulation information corresponding to the to-be-tested vehicle-mounted firmware; performing firmware debugging on the firmware simulation information, and determining target simulation information based on a firmware debugging result; determining an expected input parameter corresponding to the vehicle-mounted firmware to be tested; and performing firmware testing based on the expected input parameter and the target simulation information to obtain a firmware testing result. According to the method, the vehicle-mounted firmware to be tested is subjected to firmware simulation, and the firmware test is performed based on the target simulation information and the expected input parameters, so that the paralysis of the test terminal caused by incapability of identifying the vehicle-mounted firmware to be tested can be avoided, and the test comprehensiveness is improved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and in particular to a testing method, device and electronic equipment applied to vehicle-mounted firmware. Background Art

[0002] As a frequently used means of transportation, cars need to have their various components tested to ensure their driving safety. Usually, firmware simulation technology is used in conjunction with simulators to simulate the test environment and firmware information, thereby testing the vehicle firmware to discover possible vulnerabilities or defects in the vehicle firmware.

[0003] Simulation technology has limitations in implementation. For example, most existing simulation technologies are targeted at x86 architecture and firmware based on Linux system. For the testing of ARM architecture and non-Linux system firmware, due to the differences in architecture and system, the simulator lacks its working logic and therefore cannot respond to and implement its testing. Therefore, the existing technology has the defects of being unable to implement testing or having low test accuracy for vehicle firmware of specific architecture, specific system or conventional architecture. Summary of the invention

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

[0005] In order to solve at least one of the above-mentioned technical problems, the present invention discloses a testing method, a device and an electronic device applied to vehicle-mounted firmware.

[0006] According to one aspect of the present disclosure, a testing method applied to vehicle firmware is provided, comprising:

[0007] Providing a vehicle firmware to be tested, wherein the vehicle firmware to be tested corresponds to firmware identification information;

[0008] When 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] Performing firmware debugging on the firmware simulation information, and determining target simulation information based on the firmware debugging result;

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

[0011] A firmware test is performed based on the expected input parameters and the target simulation information to obtain a firmware test result.

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

[0013] Determine the hardware interaction function corresponding to the simulation target program, and update the function address in the hardware interaction function to obtain an updated simulation target program;

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

[0015] Based on the initial fuzzy test data and the external input data, the simulated target program is firmware-driven debugged to obtain a firmware debugging result; the firmware debugging result includes updated fuzzy test data and path feedback information;

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

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

[0018] Get the conditional constraint model;

[0019] Inputting the initial fuzzy test data into the conditional constraint model to obtain data constraint conditions corresponding to the initial fuzzy test data;

[0020] Based on the data constraint condition 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 result.

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

[0023] Inputting the updated fuzzy test data into the simulated target program;

[0024] Driving the simulated target program to perform symbolic execution on the updated fuzzy test data, and determining a program execution state of the simulated target program;

[0025] When the program execution state corresponds to an execution exception, terminating the symbolic execution and generating a first execution result corresponding to the updated fuzzy test data;

[0026] Specifically executing the updated fuzzy test data to obtain a second execution result corresponding to the updated fuzzy test data;

[0027] It is determined that the first execution result and the second execution result are the firmware debugging results, and the first execution result and the second execution result both include the path feedback information.

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

[0029] Performing function type detection on the program execution state to obtain a function detection result;

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

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

[0032] Comparing the quantitative relationship between the function execution cycle and a preset execution cycle;

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

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

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

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

[0037] Performing binary static analysis based on the program data information, and extracting symbol information included in the program data information based on the static analysis result;

[0038] A firmware symbol table corresponding to the vehicle firmware to be tested is constructed based on the symbol information and the function address information.

[0039] According to a second aspect of the present disclosure, a testing device for vehicle-mounted firmware is provided, the device comprising:

[0040] A firmware determination module, used for providing the vehicle firmware to be tested, wherein the vehicle firmware to be tested corresponds to firmware identification information;

[0041] A firmware simulation module, configured to perform firmware simulation based on the vehicle firmware to be tested, and obtain firmware simulation information corresponding to the vehicle firmware to be tested, if the firmware identifier does not exist in the preset firmware database;

[0042] A firmware debugging module, used to perform firmware debugging on the firmware simulation information and determine target simulation information based on the firmware debugging result;

[0043] A parameter determination module, used to determine expected input parameters corresponding to the vehicle firmware to be tested;

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

[0045] According to a third aspect of the present disclosure, an electronic device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction and at least one program, and the at least one instruction and the at least one program are loaded and executed by the processor to implement the test method applied to vehicle-mounted firmware as described above.

[0046] According to a fourth aspect of the present disclosure, a computer storage medium is provided, in which at least one instruction and at least one program are stored, and the at least one instruction and the at least one program are loaded and executed by a processor to implement the test method applied to vehicle-mounted firmware as described above.

[0047] The implementation of the present invention has the following beneficial effects:

[0048] In the present invention, for the vehicle-mounted firmware to be tested, it is first determined whether it is a known device according to its firmware identification information, that is, whether there is firmware identification information matching the vehicle-mounted firmware to be tested in a preset firmware database; further, in the case that the vehicle-mounted firmware to be tested is an unknown device, firmware simulation is performed on it to obtain firmware simulation information, and then firmware debugging is performed according to the firmware simulation information to obtain target simulation information corresponding to the vehicle-mounted firmware to be tested, and combined with expected input parameters and target simulation information, the test terminal can still perform testing according to its target simulation information when facing an unknown device, thereby improving the comprehensiveness and reliability of the vehicle-mounted firmware test. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solution of the present invention, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 A flow chart of a testing method for vehicle-mounted firmware provided by an embodiment of the present invention;

[0051] Figure 2 A schematic diagram of a corresponding flow chart for constructing a firmware symbol table provided in an embodiment of the present invention;

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

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

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

[0055] Figure 6 A second flow chart corresponding to the firmware debugging provided in an embodiment of the present invention;

[0056] Figure 7 A third flow chart corresponding to the firmware debugging provided in the embodiment of the present invention;

[0057] Figure 8 An architecture diagram corresponding to a firmware dynamic debugging system provided by a specific embodiment of the present invention;

[0058] Fig. 9 A schematic diagram of the structure of a testing device applied to vehicle-mounted firmware provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0059] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

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

[0061] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0062] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0063] The term "and / or" herein is only a description of the association relationship of the associated objects, indicating that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" herein represents any combination of at least two of any one or more of a plurality of. For example, including at least one of A, B, and C can represent including any one or more elements selected from the set consisting of A, B, and C.

[0064] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present disclosure.

[0065] Figure 1 The flowchart corresponding to the test method for vehicle firmware provided by the embodiment of the present invention is shown; the execution subject can be any terminal device that can implement the test method for vehicle firmware, such as the emulator QEMU (Quick EMU l ator, fast emulator); please refer to Figure 1 , a testing method applied to vehicle firmware, comprising:

[0066] Step S101: providing a vehicle firmware to be tested, wherein the vehicle firmware to be tested corresponds to firmware identification information;

[0067] In a feasible embodiment, the vehicle firmware to be tested can be an external hardware device applied to the vehicle, such as a register, etc., and can be equipped with an ARM architecture and a non-Li nux system, such as an embedded QNX system. That is, it can be considered that the disclosed embodiment of the present invention is mainly used to implement QEMU's testing of QNX vehicle firmware based on the ARM architecture, and it can also implement QEMU's testing of any unknown peripherals based on the vehicle firmware testing method disclosed in the present invention. The 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 has been tested and / or interacted with by the emulator and can respond, and an unknown device is a vehicle firmware that the emulator obtains information and / or tests for the first time.

[0068] Figure 2 A schematic diagram of a corresponding flow chart for constructing a firmware symbol table provided in an embodiment of the present invention, Figure 3 For a schematic diagram of the vehicle firmware to be tested provided in a specific embodiment of the present invention, please refer to Figure 2-3 After providing the vehicle firmware to be tested, the method includes:

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

[0070] In a specific embodiment, after providing the on-board firmware to be tested, the on-board firmware to be tested can be initialized first, and the objects of initialization can include boot startup simulation and symbolic execution engine initialization. The execution steps of initialization can include: simulating the stack in IPL (Initial Program Load), locating and loading the operating system image, completing the hardware initialization configuration, the symbolic execution engine obtains basic information and initializes the execution environment, the memory area used by the peripherals is marked as unimplemented, that is, the firmware identification information corresponding to the on-board firmware to be tested is an unknown device, and the program initialization data structure is constructed to obtain the initialization program.

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

[0072] Step S203: performing binary static analysis based on the program data information, and extracting symbol information included in the program data information based on the static analysis result;

[0073] In a specific embodiment, the program data information may at least include function address information and function call relationship; binary static analysis is performed on the initialization program, and symbol information in the static analysis result is extracted, and the symbol information may include function name, function address information, etc.

[0074] Step S204: constructing 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 may include function names, function address information, function call relationships, and symbol value information; wherein the function address information may correspond to the address of each function, and is used to locate the entry address corresponding to the function during program execution; the symbol value information may be a symbol value associated with each function, and is used to solve constraints during symbolic execution.

[0076] During the firmware startup phase, generating a firmware symbol table can facilitate the change of function addresses. For example, according to the configuration of the input program read from the external storage, the corresponding function address in the firmware symbol table is changed, and then the abnormal chip program or abnormal firmware program is modified to the program in the input program configuration to achieve the function of program repair. Through the function address in the firmware symbol table, the functions in the firmware can be used directly without introducing other programs, thereby reducing the amount of repeated code and the size of the input program image, thereby increasing the speed of firmware startup. In the firmware symbol table, if the clock and memory initialization functions are configured in the input program image, the correct function address can be directly obtained through the firmware symbol table and executed, so that the clock, memory and other key devices can be initialized in time in the startup firmware, and in the subsequent startup process, it can run at a higher main frequency and complete memory space.

[0077] Step S102: when 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;

[0078] In a specific embodiment, the firmware identifier can be first 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 test process. If it is an unknown device, the vehicle firmware to be tested needs to be simulated first to obtain the corresponding firmware simulation information; Figure 4 The architecture diagram of an embedded simulation framework provided by a specific embodiment of the present invention can be based on Figure 4The hybrid execution debugging framework shown realizes the simulation of the vehicle firmware to be tested. The vehicle firmware to be tested is equipped with a target program, so the firmware simulation information includes not only the hardware information and configuration information corresponding to the vehicle firmware to be tested, but also a simulated target program corresponding to the target program.

[0079] Step S103: performing firmware debugging on the firmware simulation information, and determining target simulation information based on the firmware debugging result;

[0080] In a specific embodiment, after the firmware simulation information is obtained, the firmware simulation information is debugged to determine the target simulation information. The target simulation information can be considered to be obtained by the simulator through firmware simulation and firmware debugging of the vehicle firmware to be tested. Specifically, Figure 5 The first flow chart corresponding to the firmware debugging provided by the embodiment of the present invention is as follows: Figure 5 As shown, the firmware debugging of the firmware simulation information and determining the target simulation information based on the firmware debugging result include:

[0081] Step S501: determining a hardware interaction function corresponding to the simulation target program, and updating a function address in the hardware interaction function to obtain an updated simulation target program;

[0082] In a specific embodiment, the configuration file of the system operation is first parsed to obtain the plt address of the library function, the offset address and the actual address of each section, and then the interface corresponding to the hardware interaction function that needs to be plugged in is matched, the code of the address source is rewritten, and the code for simulating hardware interaction is written in the newly expanded code area to obtain an updated simulation target program.

[0083] Step S502: obtaining initial fuzzy test data, and determining external input data corresponding to the simulated target program;

[0084] Step S503: Based on the initial fuzzy test data and the external input data, the simulated target program is firmware-driven debugged to obtain a firmware debugging result; the firmware debugging result includes updated fuzzy test data and path feedback information;

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

[0086] In a specific embodiment, the external input data corresponding to the simulation target program is analyzed by stub analysis, and the binary code corresponding to the simulation target program is translated into VEXI R intermediate language and the jump address associated with the external input data is stubbed. Specifically, a simulation runner can be generated and configured, and the unknown device peripheral reading can be configured so that the simulation runner triggers different conditional constraints according to different conditions when simulating the execution of the binary program, and solves the constraints through symbolic execution, thereby covering the exception error handling; the simulation runner is run, and when the branch jump is executed, the processor context information and another unexecuted control flow branch are saved, and the execution continues; when the end address is executed, the control flow branch that has not been executed before is switched to by backtracking, and the processor context information is restored for simulation operation; when all control flow branches are executed, the simulation runner stops running; the structure is used to store the number of inserted symbolic execution branch jumps and the information of which branch of the corresponding symbolic execution branch jump is executed, so as to realize the stub of the jump address associated with the external input data.

[0087] Figure 6 FIG. 2 shows a second flow chart corresponding to the firmware debugging provided by an embodiment of the present invention. Figure 6 As shown, based on the initial fuzzy test data and the external input data, the simulated target program is firmware-driven debugged to obtain a firmware debugging result, including:

[0088] Step S601: Obtain a conditional constraint model;

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

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

[0091] In a specific embodiment, the simulator can provide a conditional constraint model for generating data constraints, so as to perform constraint solving on fuzzy test data according to the data constraints. Specifically, fuzzy test samples and constraint solving of symbolic execution are generated according to the constructed model constraints; the weights of fuzzy test samples that have completed the test are updated and sorted, multiple fuzzy test samples are selected, and the updated fuzzy test data is obtained by using the sample mutation algorithm.

[0092] Since QEMU may not respond to unknown devices, constraints can be solved on the simulated test data to obtain test sample data that matches the vehicle firmware to be tested.

[0093] Step S604: Based on the updated fuzzy test data, the simulated target program is firmware-driven debugged to obtain the firmware debugging result.

[0094] Specifically, Figure 7 A third flow chart corresponding to the firmware debugging provided in the embodiment of the present invention, Figure 8 For the architecture diagram corresponding to the firmware dynamic debugging system provided by the embodiment of the present invention, please refer to Figure 7 as well as Figure 8 , based on the updated fuzzy test data, the simulated target program is debugged with a firmware driver to obtain the firmware debugging result, that is, step S604 may include:

[0095] Step S701: inputting the updated fuzzy test data into the simulated target program;

[0096] Step S702: driving the simulated target program to perform symbolic execution on the updated fuzzy test data, and determining a program execution state of the simulated target program;

[0097] In a specific embodiment, during the fuzz testing of the simulated target program using updated fuzz testing data for specific execution and symbolic execution, the goal of symbolic execution is to find the optimal path and guide QEMU to this path. The optimal path information needs to be able to pass the internal inspection of the firmware and avoid interrupting the firmware execution. The use of symbolic execution can be achieved through a set of firmware-specific heuristics to avoid generating problematic external device inputs that may cause execution interruption.

[0098] For symbolic execution, its first instruction is always a peripheral read, and correspondingly, a symbolic variable set is assigned to the peripheral read; in each branch execution, for each explicit instruction that requires context switching, the symbolic execution is terminated and the execution is transferred to the specific execution so that the symbolic execution can always maintain the original execution mode; for the solved symbols, they are stored for replay; for the unrecognizable instructions that do not affect the program control flow, they are replaced with NOP instructions; for the unrecognizable instructions that directly change the control flow or update the general registers, I terminate the symbolic execution.

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

[0100] In a specific embodiment, the program execution status may include at least: execution type, execution result, execution function type and function execution cycle. The execution type may include symbolic execution and specific execution. The execution result may include normal execution and abnormal execution. The execution function type may include long loop function and non-long loop function. The function execution cycle may 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 to generate a symbol list. Every time a branch is encountered, the path selection algorithm is run to select the optimal path information. For synchronous exceptions and abnormal returns, the symbolic execution is terminated and the corresponding first execution result is generated.

[0102] The determination of the optimal path can be achieved by the following steps:

[0103] Step 1: Determine whether there are infinite loops in multiple paths led by a branch. If it is found that these paths all have infinite loops, mark this branch and compare the execution status in each path. If any two states are the same, it means that the processor registers have not changed at different times. We regard the corresponding path as an infinite loop and skip execution.

[0104] Step 2: Considering that the branch marked as infinite loop may be incorrectly filtered, the mark will be selected with the lowest priority; so that when the execution switches back to the specific execution, an interrupt can be triggered and handled, effectively unlocking the infinite loop.

[0105] Step 3: Record the paths that keep failing and executing the same path in the while loop, and perform similarity checks on them. Symbolic execution will select new paths and exclude completely similar paths until all paths are consumed.

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

[0107] Step S704: specifically executing the updated fuzzy test data to obtain a second execution result corresponding to the updated fuzzy test data;

[0108] When symbolic execution terminates, the value of the symbol list that will execute navigation to the current path is calculated, and the resolved value is provided to QEMU for concrete execution, driving firmware execution by constantly switching between concrete execution and symbolic execution passes.

[0109] Specifically, implementing the transfer of the specific execution state of the program to the symbolic execution process may include: inferring the expected behavior of the firmware and the satisfiability model theory through the Angr symbolic execution assisted 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 specific 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 a specific embodiment, the updated fuzz test data can be used to perform specific execution of the simulated target program, simulate execution of the symbolic execution system, and optimize the mutation process of the fuzz test sample through path feedback information. Monitoring is achieved through the network and local processes. When no feedback from the simulated target program is received for a preset time or the target process in the simulated target program is detected to be dead, the fuzz test sample executed this time is saved to the local storage and the target process is restarted.

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

[0113] In addition, since long loops consume a lot of time during program execution, the execution type is transferred to specific execution when there are long loops; when the maximum execution branch limit is reached, that is, when the execution depth layer is reached, the execution type is also transferred to specific execution. The simulation target program includes multiple functions, the program execution state includes the execution type and the execution function type, and the method also includes:

[0114] Performing function type detection on the program execution state to obtain a function detection result;

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

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

[0117] For the function type of each function in the simulation target program, it is possible to determine whether it is a long loop function based on its execution cycle. Specifically, the relationship between the function execution cycle and the preset execution cycle can be compared, and when the function execution cycle is greater than the preset execution cycle, it is determined that the function corresponding to the function execution cycle is a long loop function. The number corresponding to the preset execution cycle can be 5.

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

[0119] In a specific embodiment, when the on-board firmware to be tested is an unknown device, the emulator will be paralyzed due to inability to respond. If the emulator provides random values, the execution is likely to be stuck, so it is necessary to calculate the expected input parameters. When encountering a branch, the path selection algorithm is run to select the optimal path. When the symbolic execution terminates, the value of the symbol list that will execute the navigation to the optimal path is calculated and provided to QEMU to determine the expected input parameters. The expected input parameters can be determined by the context-preserving scanning algorithm.

[0120] Specifically, the context preserving scanning algorithm can be executed through the following steps:

[0121] Step 1: Initialize the context information table; create a context information table before starting scanning to record the processed data blocks and related information;

[0122] Step 2: Data scanning: 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 related information to the context information table; if the data block already exists in the context information table, directly skip the processing of the data block;

[0124] Step 4: Processing data blocks: For each data block that has not been skipped, perform corresponding processing operations according to the content included in it, and save the results in the context information table.

[0125] Step 5: Repeat steps 2 to 4 until all data blocks are processed and the expected input parameters are obtained. The scanning 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 testing results.

[0127] In a specific embodiment, the vehicle firmware to be tested is tested by combining expected input parameters and target simulation information. Specifically,

[0128] The embodiment of the present invention also provides a testing device for vehicle firmware, such as Fig. 9 As shown, the device comprises:

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

[0130] A firmware simulation module 920, configured to perform firmware simulation based on the vehicle firmware to be tested, and obtain firmware simulation information corresponding to the vehicle firmware to be tested, if the firmware identifier does not exist in the preset firmware database;

[0131] A firmware debugging module 930, configured to perform firmware debugging on the firmware simulation information and determine target simulation information based on the firmware debugging result;

[0132] A parameter determination module 940, configured to determine expected input parameters corresponding to the vehicle firmware to be tested;

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

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

[0135] An interactive function determination module, used to determine the hardware interactive function corresponding to the simulation target program, and update the function address in the hardware interactive function to obtain an updated simulation target program;

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

[0137] A first debugging module, configured to perform firmware driver debugging on the simulated target program based on the initial fuzzy test data and the external input data to obtain a firmware debugging result; the firmware debugging result includes updated fuzzy 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 some other embodiments, the first debugging module includes:

[0140] A model acquisition module is used to obtain a conditional constraint model;

[0141] A condition determination module, used for inputting the initial fuzzy test data into the condition constraint model to obtain data constraint conditions corresponding to the initial fuzzy test data;

[0142] A data updating module, used for updating the initial fuzzy test data based on the data constraint condition 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 to obtain the firmware debugging result.

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

[0145] A data input module, used for inputting the updated fuzzy test data into the simulation target program;

[0146] A first execution module, used for driving the simulated target program to perform symbolic execution on the updated fuzzy test data, and determining a program execution state of the simulated target program;

[0147] A first termination module, configured to terminate the symbolic execution and generate a first execution result corresponding to the updated fuzzy test data when the program execution state corresponds to an execution exception;

[0148] A second execution module, used to specifically execute the updated fuzzy test data to obtain a 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 the first execution result and the second execution result both include the path feedback information.

[0150] In some other embodiments, the device further comprises:

[0151] A type detection module, used to perform function type detection on the program execution state to obtain a 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 some other embodiments, the device further comprises:

[0154] A comparison module, used for comparing the quantitative relationship between the function execution cycle and a preset execution cycle;

[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 some other embodiments, the device further comprises:

[0157] A program construction module, used to construct an initialization program corresponding to the vehicle firmware to be tested;

[0158] A program information acquisition module, used to acquire program data information corresponding to the initialization program; the program data information includes function address information;

[0159] A static analysis module, configured to perform binary static analysis based on the program data information, and extract symbol information included in the program data information based on the static analysis result;

[0160] A symbol table construction module is used to construct a firmware symbol table corresponding to the vehicle firmware to be tested based on the symbol information and the function address information.

[0161] The device and method embodiments in the device embodiment are based on the same inventive concept and are used to implement the above-mentioned test method applied to vehicle-mounted firmware.

[0162] An embodiment of the present invention also provides an electronic device, comprising: a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and 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 test method applied to vehicle-mounted firmware as described in any one of the method embodiments.

[0163] An embodiment of the present invention also provides a storage medium, which can be set in a server to store at least one instruction, at least one program, a code set or an instruction set for implementing a test method applied to vehicle-mounted firmware in a method embodiment. The at least one instruction, the at least one program, the code set or the instruction set are loaded and executed by the processor to implement a test method applied to vehicle-mounted firmware as described in any of the method embodiments.

[0164] Optionally, in an embodiment of the present invention, the above-mentioned storage medium may be located in at least one of a plurality of network servers of a computer network. Optionally, in an embodiment of the present invention, the above-mentioned storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0165] It can be seen from the embodiments provided by the present invention that, in the present invention, for the vehicle-mounted 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-mounted firmware to be tested in the preset firmware database; further, in the case that the vehicle-mounted firmware to be tested is an unknown device, firmware simulation is performed on it 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-mounted firmware to be tested, combined with the expected input parameters and the target simulation information, so that the test terminal can still perform testing according to its target simulation information when facing an unknown device, thereby improving the comprehensiveness and reliability of the vehicle-mounted firmware testing.

[0166] It should be noted that various embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The choice of terms used in this article is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A testing method applied to vehicle firmware, characterized in that: The method comprises: Providing a vehicle firmware to be tested, wherein the vehicle firmware to be tested corresponds to firmware identification information; When 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; Performing firmware debugging on the firmware simulation information, and determining target simulation information based on the firmware debugging result; Determining expected input parameters corresponding to the vehicle firmware to be tested; A firmware test is performed based on the expected input parameters and the target simulation information to obtain a firmware test result.

2. A testing method for vehicle-mounted firmware according to claim 1, characterized in that: The vehicle-mounted firmware to be tested is equipped with a target program; the firmware simulation information includes a simulated target program corresponding to the target program; The performing firmware debugging on the firmware simulation information and determining target simulation information based on the firmware debugging result includes: Determine the hardware interaction function corresponding to the simulation target program, and update the function address in the hardware interaction function to obtain an updated simulation target program; Acquire initial fuzzy test data, and determine external input data corresponding to the simulated target program; Based on the initial fuzzy test data and the external input data, the simulated target program is firmware-driven debugged to obtain a firmware debugging result; the firmware debugging result includes updated fuzzy test data and path feedback information; The firmware simulation information, the updated simulation target program, the updated fuzzy test data and the path feedback information are determined to be the target simulation information.

3. A testing method for vehicle firmware according to claim 2, characterized in that: The step of performing firmware driver debugging on the simulated target program based on the initial fuzzy test data and the external input data to obtain a firmware debugging result includes: Get the conditional constraint model; Inputting the initial fuzzy test data into the conditional constraint model to obtain data constraint conditions corresponding to the initial fuzzy test data; Based on the data constraint condition 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 result.

4. A testing method for vehicle-mounted firmware according to claim 3, characterized in that: The step of performing firmware driver debugging on the simulated target program based on the updated fuzzy test data to obtain the firmware debugging result includes: Inputting the updated fuzzy test data into the simulated target program; Driving the simulated target program to perform symbolic execution on the updated fuzzy test data, and determining a program execution state of the simulated target program; When the program execution state corresponds to an execution exception, terminating the symbolic execution and generating a first execution result corresponding to the updated fuzzy test data; Specifically executing the updated fuzzy test data to obtain a second execution result corresponding to the updated fuzzy test data; It is determined that the first execution result and the second execution result are the firmware debugging results, and the first execution result and the second execution result both include the path feedback information.

5. A testing method for vehicle-mounted firmware according to claim 4, characterized in that: The simulation target program includes a plurality of functions, and the program execution state includes an execution type and an execution function type; The method further comprises: Performing function type detection on the program execution state to obtain a function detection result; When the function detection result indicates that the execution function type of the currently executed function is a long loop function, and the execution type is symbolic execution, the symbolic execution of the currently executed function is terminated, and the currently executed function is specifically executed.

6. A testing method for vehicle-mounted firmware according to claim 1, characterized in that: The simulation target program includes multiple functions; the program execution state also includes the function execution cycle of each function; The method further comprises: Comparing the quantitative relationship between the function execution cycle and a preset execution cycle; When the function execution period is greater than the preset execution period, it is determined that the function corresponding to the function execution period is a long-loop function.

7. A testing method for vehicle firmware according to claim 1, characterized in that: After providing the vehicle firmware to be tested, the method includes: Constructing an initialization program corresponding to the vehicle firmware to be tested; Acquire program data information corresponding to the initialization program; the program data information includes function address information; Performing binary static analysis based on the program data information, and extracting symbol information included in the program data information based on the static analysis result; A firmware symbol table corresponding to the vehicle firmware to be tested is constructed based on the symbol information and the function address information.

8. A testing device for vehicle-mounted firmware, characterized in that: The device comprises: A firmware determination module, used for providing the vehicle firmware to be tested, wherein the vehicle firmware to be tested corresponds to firmware identification information; A firmware simulation module, configured to perform firmware simulation based on the vehicle firmware to be tested, and obtain firmware simulation information corresponding to the vehicle firmware to be tested, if the firmware identifier does not exist in the preset firmware database; A firmware debugging module, used to perform firmware debugging on the firmware simulation information and determine target simulation information based on the firmware debugging result; A parameter determination module, used to determine expected input parameters corresponding to the vehicle firmware to be tested; The firmware testing module is used to perform firmware testing based on the expected input parameters and the target simulation information to obtain firmware testing results.

9. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores at least one instruction and at least one program, and the at least one instruction and the at least one program are loaded and executed by the processor to implement the test method applied to vehicle-mounted firmware as described in any one of claims 1-7.

10. A computer storage medium, characterized in that: The computer storage medium stores at least one instruction and at least one program, and the at least one instruction and the at least one program are loaded and executed by the processor to implement the testing method applied to vehicle-mounted firmware as described in any one of claims 1-7.

Images