Method, device and electronic equipment for checking extracted firmware data

Abstract

This application provides a method, apparatus, and electronic device for verifying extracted firmware data. The method includes: sending a read command to a chip under test, wherein the read command is used to extract firmware data; performing a first verification on the transmitted communication data during the firmware data extraction process to obtain a firmware extraction result, wherein the first verification is used to determine the correctness of the firmware data; and performing a second verification on the firmware extraction result to obtain a firmware data integrity score, wherein the second verification is used to determine the integrity of the firmware data. This application solves the problem in related technologies where there is a lack of effective means to verify the firmware data extraction process and the firmware extraction result, making it impossible to determine whether the extracted firmware data is authentic and reliable.

Description

Technical Field

[0001] This invention relates to the field of hardware security testing technology, and in particular to a method, apparatus, and electronic device for verifying extracted firmware data. Background Technology

[0002] Firmware extraction is a necessary method for penetration testing of intelligent connected vehicles. It typically involves manually extracting firmware data from the device by opening it and connecting it to a microcontroller unit (MCU) or flash memory chip.

[0003] Common methods for reading embedded MCU firmware data include: using firmware programming tools provided by the MCU chip supplier, utilizing the tool's "verification" function to read back and verify the MCU's built-in memory area, and saving the data content during the read-back operation of the firmware programming tool; and using an MCU chip debugger to read the chip memory during MCU program execution. Using these methods, operators mostly need to rely on experience to judge whether errors occurred during the firmware extraction process and whether the obtained data is authentic and reliable. Furthermore, because existing firmware extraction tools and methods do not verify the correctness of the firmware itself, or only verify firmware integrity through fixed-format digital signatures, hash checksums, etc., treating the firmware content as a semantically meaningless byte stream, this approach cannot guarantee that the firmware can be correctly loaded and run by the MCU after extraction and programming.

[0004] Therefore, existing technologies lack effective means to verify the firmware data extraction process and results, making it impossible to determine whether the extracted firmware data is authentic and reliable. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for verifying extracted firmware data, in order to at least solve the problem in the related art that there is a lack of effective means to verify the firmware data extraction process and firmware extraction results, making it impossible to determine whether the extracted firmware data is authentic and reliable.

[0006] According to one aspect of the embodiments of this application, a method for verifying extracted firmware data is provided, the method comprising:

[0007] Send a read command to the chip under test, wherein the read command is used to extract firmware data;

[0008] During the process of extracting the firmware data, a first verification is performed on the transmitted communication data to obtain the firmware extraction result, wherein the first verification is used to determine the correctness of the firmware data;

[0009] A second verification is performed on the firmware extraction result to obtain an integrity score for the firmware data, wherein the second verification is used to determine the integrity of the firmware data.

[0010] According to another aspect of the embodiments of this application, an apparatus for verifying extracted firmware data is also provided, the apparatus comprising:

[0011] The sending module is used to send a read command to the chip under test, wherein the read command is used to extract firmware data;

[0012] The first verification module is used to perform a first verification on the transmitted communication data during the process of extracting the firmware data, and obtain the firmware extraction result, wherein the first verification is used to determine the correctness of the firmware data.

[0013] The second verification module is used to perform a second verification on the firmware extraction result to obtain an integrity score of the firmware data, wherein the second verification is used to determine the integrity of the firmware data.

[0014] Optionally, the device further includes:

[0015] The determination module is used to determine the protocol used by the debugging interface of the chip under test;

[0016] An identification module is used to identify the chip parameters of the chip under test based on the protocol.

[0017] The output module is used to output the chip parameters.

[0018] Optionally, the first verification module includes:

[0019] An identification unit is used to identify the communication data;

[0020] The first recording unit is used to record the read success address and the firmware data corresponding to the data packet if the communication data is a data packet.

[0021] A decoding unit is configured to decode the error code to obtain the error type if the communication data is an error code;

[0022] The first judgment unit is used to determine whether the error type allows recovery;

[0023] The first transmitting unit is configured to retransmit the read command to the chip under test if recovery is permitted.

[0024] The second recording unit is used to record the read failure address corresponding to the error code if recovery is not allowed;

[0025] As a unit, when all data areas have been read, the read success address, the firmware data, and the read failure address are used as the firmware extraction result.

[0026] Optionally, the second verification module includes:

[0027] The first calculation unit is used to calculate the first preset hash value of the data area in the firmware extraction result, and compare the first preset hash value with the first target value to obtain the first verification score.

[0028] The second calculation unit is used to calculate the second preset hash value of the data area in the firmware extraction result, and compare the second preset hash value with the second target value to obtain the second verification score.

[0029] The first output unit is used to perform static analysis on the firmware data extracted from the firmware to obtain a third verification score.

[0030] The second unit is used to run the firmware program in virtualization and analyze the virtualization process to obtain the fourth verification score.

[0031] The third output unit is used to perform entropy analysis on the firmware data and obtain the fifth verification score;

[0032] The fourth unit is used to derive the sixth verification score based on the correspondence between the firmware extraction results and the scoring weights as defined in the custom specification.

[0033] The obtaining unit is used to obtain the integrity score of the firmware data based on the first verification score, the second verification score, the third verification score, the fourth verification score, the fifth verification score, and the sixth verification score.

[0034] Optionally, the first derived unit includes:

[0035] The first acquisition submodule is used to acquire the interrupt vector table in the firmware data, wherein the interrupt vector table contains a first preset number of function pointers;

[0036] The first judgment submodule is used to determine whether the function pointer points to a preset memory region;

[0037] A determining submodule is configured to determine that the function pointer is available if, when pointing to the preset memory region, the preset memory region contains an available preset function preamble, and there is a memory region within a preset distance of the preset memory region that can form a stack frame function;

[0038] The first submodule is used to obtain the third verification score based on the number of available function pointers and the first preset number.

[0039] Optionally, the second derived unit includes:

[0040] The extraction submodule is used to extract the reset function pointer from the interrupt vector table;

[0041] The execution submodule is used to execute assembly statements starting from the code region pointed to by the reset function pointer;

[0042] The second judgment submodule is used to determine whether the virtualization operation process meets the preset conditions. If it does, the execution of the assembly statement ends and the integrity verification is determined to be successful.

[0043] The determination submodule is used to terminate the execution of the assembly statement and determine that the integrity check fails if the virtualization process meets a preset error condition before the virtualization process meets a preset condition.

[0044] The generation submodule is used to generate the fourth verification score based on the integrity verification result.

[0045] Optionally, the third derived unit includes:

[0046] The second submodule is used to divide the firmware data into blocks according to a preset block size to obtain a second preset number of data blocks;

[0047] The third submodule is used to obtain a floating-point number sequence based on the data block, wherein the floating-point number sequence contains a second preset number of floating-point numbers;

[0048] The second acquisition submodule is used to acquire the upper threshold and lower threshold of the floating-point number;

[0049] The third acquisition submodule is used to acquire the number of first floating-point numbers in the floating-point number sequence that are between the upper threshold and the lower threshold.

[0050] The fourth acquisition submodule is used to acquire the number of second floating-point numbers in the floating-point number sequence that are higher than the lower threshold.

[0051] The fourth submodule is used to obtain the fifth verification score based on the first number of floating-point numbers and the second number of floating-point numbers.

[0052] Optionally, the determined module includes:

[0053] An initialization unit is used to initialize the chip under test.

[0054] The second judgment unit is used to send a first instruction according to the current debugging protocol and determine whether a first preset response from the chip under test is received.

[0055] The first test unit is used to start testing the next protocol if the first preset response is not received.

[0056] The second sending unit is used to send a second instruction and determine whether the second preset response of the chip under test is received if the first preset response is received.

[0057] The third judgment unit is used to send a second instruction and determine whether the second preset response of the chip under test is received if the first preset response is received.

[0058] The second test unit is used to begin testing the next protocol if no other response is received.

[0059] The fourth determination unit is used to initiate a secure debugging authorization if the other responses are received, and to determine whether a third preset response from the chip under test has been received.

[0060] The acquisition unit is configured to, if the second preset response or the third preset response is received, confirm a successful connection and successfully acquire the protocol.

[0061] According to another aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein the memory is used to store a computer program; and the processor is used to execute the method steps of any of the above embodiments by running the computer program stored in the memory.

[0062] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the method steps of any of the above embodiments when running.

[0063] In this embodiment, a read command is sent to the chip under test (DUT) to extract firmware data. During the firmware data extraction process, a first verification is performed on the transmitted communication data to obtain the firmware extraction result, whereby the first verification is used to determine the correctness of the firmware data. A second verification is performed on the firmware extraction result to obtain a firmware data integrity score, whereby the second verification is used to determine the integrity of the firmware data. Through the above method, during the firmware data extraction process, a first verification is performed on the transmitted communication data to determine whether errors have occurred during the firmware extraction process, thereby judging whether the extracted firmware data is authentic and reliable. After obtaining the firmware extraction result, a second verification is performed on the firmware extraction result to verify the extracted firmware data content from multiple perspectives and obtain a firmware data integrity score. The authenticity and usability of the firmware data are quantified through calculation, greatly improving the reliability of the firmware extraction result. This solves the problem in related technologies where there is a lack of effective means to verify the firmware data extraction process and firmware extraction result, making it impossible to determine whether the extracted firmware data is authentic and reliable. Attached Figure Description

[0064] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 This is a flowchart illustrating an optional method for verifying extracted firmware data according to an embodiment of this application.

[0067] Figure 2 This is a functional block diagram of an optional method for verifying extracted firmware data according to an embodiment of this application;

[0068] Figure 3 This is a timing diagram of an optional firmware extraction and bypass data verification according to an embodiment of this application;

[0069] Figure 4 This is a schematic flowchart illustrating an optional method for determining the protocol used by the debugging interface of the chip under test, according to an embodiment of this application.

[0070] Figure 5 This is a structural block diagram of an optional apparatus for verifying extracted firmware data according to an embodiment of this application;

[0071] Figure 6This is a structural block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0072] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0073] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application 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 this application 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 non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is 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 apparatus.

[0074] MCU (Microcontroller Unit), short for single-chip microcomputer, is a microcomputer that integrates a central processing unit, memory, timer / counter, input / output interfaces, and other units on a single integrated circuit chip. Methods for reading the firmware of embedded MCUs in automotive parts generally fall into two categories: one is to read the stored information directly from the MCU's internal memory area, and the other is to read the stored information from the MCU's external Flash chip. For example, the firmware of the RH850 series chip is stored in the MCU's internal memory area. Common methods for reading the contents of the MCU's internal memory area include using firmware programming tools provided by the MCU chip supplier or using an MCU chip debugger.

[0075] Because these tools are designed for embedded developers and not for firmware extraction in penetration testing scenarios, their use relies on operators having a comprehensive understanding of the chip, including chip series and sub-models, ROM size, and RAM size. Furthermore, these tools suffer from unintuitive interactive logic and unreliable stability. For example, when read / write security features are enabled in the MCU's built-in memory, they don't provide clear prompts but instead display the chip content as hexadecimal 00 or FF, or automatically erase the MCU's memory. Operators often need to rely on experience to determine if errors have occurred during the firmware extraction process. Additionally, they don't verify the firmware's correctness, failing to guarantee that the extracted and burned firmware will be correctly loaded and run by the MCU. These shortcomings mean that existing firmware extraction methods cannot guarantee successful and correct MCU firmware extraction in all situations.

[0076] Based on the above, according to one aspect of the embodiments of this application, a method for verifying extracted firmware data is provided, such as... Figure 1 As shown, the process of this method may include the following steps:

[0077] Step S101: Send a read command to the chip under test, wherein the read command is used to extract firmware data.

[0078] Optionally, the chip under test is an MCU chip, such as Figure 2 As shown, the solution in this application uses software to communicate with the debugger and the chip. After completing protocol adaptation and MCU parameter identification, the firmware extraction module sends a read command to the MCU to read the firmware data content.

[0079] Step S102: During the firmware data extraction process, the transmitted communication data is subjected to a first verification to obtain the firmware extraction result. The first verification is used to determine the correctness of the firmware data.

[0080] Optionally, during the firmware extraction operation, the communication data bypass verification module performs bypass data verification (i.e., the first verification) on the transport layer data packets to monitor their data correctness. After verification is completed, the firmware extraction result is obtained.

[0081] Step S103: Perform a second verification on the firmware extraction result to obtain a firmware data integrity score, wherein the second verification is used to determine the integrity of the firmware data.

[0082] Optionally, the firmware verification and virtualization operation module uses static analysis and virtualization operation as methods to perform integrity verification on the firmware extraction results by multiple sub-modules, i.e., the second verification. The second verification also includes a weighted average verification score of each sub-module, and finally obtains the integrity score of the firmware data.

[0083] In this embodiment, a read command is sent to the chip under test (DUT) to extract firmware data. During the firmware data extraction process, a first verification is performed on the transmitted communication data to obtain the firmware extraction result, whereby the first verification is used to determine the correctness of the firmware data. A second verification is performed on the firmware extraction result to obtain a firmware data integrity score, whereby the second verification is used to determine the integrity of the firmware data. Through the above method, during the firmware data extraction process, a first verification is performed on the transmitted communication data to determine whether errors have occurred during the firmware extraction process, thereby judging whether the extracted firmware data is authentic and reliable. After obtaining the firmware extraction result, a second verification is performed on the firmware extraction result to verify the extracted firmware data content from multiple perspectives and obtain a firmware data integrity score. The authenticity and usability of the firmware data are quantified through calculation, greatly improving the reliability of the firmware extraction result. This solves the problem in related technologies where there is a lack of effective means to verify the firmware data extraction process and firmware extraction result, making it impossible to determine whether the extracted firmware data is authentic and reliable.

[0084] As an optional embodiment, a first verification is performed on the transmitted communication data to obtain firmware extraction results, including:

[0085] Identify communication data;

[0086] If the communication data is a data packet, then record the address where the data packet was successfully read and the firmware data.

[0087] If the communication data is an error code, then the error code is decoded to obtain the error type;

[0088] Determine whether the error type allows for recovery;

[0089] If recovery is allowed, the read command is resent to the chip under test;

[0090] If recovery is not allowed, record the address where the read failed to read the corresponding error code;

[0091] When all data areas have been read, the successfully read address, firmware data, and the failed read address will be used as the firmware extraction results.

[0092] Optionally, such as Figure 3 As shown, after confirming the MCU chip information and receiving the firmware extraction command from the tester, the firmware extraction module uses the chip model, ROM memory offset address, and size returned by the MCU parameter identification module to send a read command to the MCU to extract the firmware. Each read command has a fixed number of bytes, which can be configured to any value between 1 and 256 via parameters.

[0093] During firmware extraction, the bypass data verification module monitors the communication data between the firmware extraction module and the MCU. If the MCU returns a data packet, it sends the packet back to the firmware extraction module, which records the successful read address and data. If the MCU returns an error code, the error code is decoded and an attempt is made to repair it. If an unrecoverable error is detected, such as a read protection error (STS-10), the failure address is marked, the error result is fed back to the tester, and the firmware extraction module records the read failure address. If a recoverable error is detected, such as a hash check error, the read command is resent to the MCU via the firmware extraction module. This process is repeated until all data areas have been read. Afterward, the recorded read failure address, read success address, and data are returned to the tester as the firmware extraction result.

[0094] In this embodiment, errors returned by the MCU are repaired. If repair is not possible, the error result is promptly fed back to the tester. The tester can accurately understand whether an error occurred during the firmware extraction process. The interaction logic is clear, and a communication data bypass verification mechanism is used to address the instability of the firmware extraction process, ensuring the reliability of the data results. This solves the problems of chaotic interaction logic and the lack of effective means to verify the firmware data extraction process in existing technologies.

[0095] As an optional embodiment, a second verification is performed on the firmware extraction results to obtain a firmware data integrity score, including:

[0096] Calculate the first preset hash value of the data area in the firmware extraction result, and compare the first preset hash value with the first target value to obtain the first verification score;

[0097] Calculate the second preset hash value of the data area in the firmware extraction result, and compare the second preset hash value with the second target value to obtain the second verification score;

[0098] Static analysis is performed on the firmware data extracted from the firmware to obtain the third verification score;

[0099] The firmware program is run in virtualization, and the virtualization process is analyzed to obtain the fourth verification score.

[0100] Entropy analysis is performed on the firmware data to obtain the fifth verification score;

[0101] The sixth verification score is derived based on the correspondence between the custom firmware extraction results and the scoring weights.

[0102] The integrity score of the firmware data is obtained based on the first verification score, the second verification score, the third verification score, the fourth verification score, the fifth verification score, and the sixth verification score.

[0103] Optionally, the firmware verification and virtualization operation module verifies the firmware extraction result data returned by the firmware extraction module and provides the verification result.

[0104] First, multiple sub-modules verify the firmware extraction results and output integrity verification scores (0-100) or verification results (pass or fail). Then, the integrity score of the firmware data (0-100) is obtained by weighted averaging. The verification results can be converted into integrity verification scores according to requirements, for example, setting 100 for pass and 0 for fail.

[0105] The CRC32 checksum submodule calculates the CRC32 hash value (first preset hash value) of the data area in the firmware extraction result and compares it with the value provided by the tester (first target value). If they match, the result is returned as "failed"; otherwise, it fails, and the first checksum score is obtained based on the returned result. Additionally, if the number of failed read addresses in the firmware extraction result is greater than 0, this output result is not included in the overall firmware integrity score.

[0106] The MD5 verification submodule calculates the MD5 hash value of the data area, i.e., the second preset hash value, and compares it with the value provided by the tester, i.e., the second target value. If they match, the result is returned as "failed"; otherwise, it fails, and a second verification score is obtained based on the returned result. Additionally, if the number of failed read addresses in the firmware extraction result is greater than 0, this output result is not included in the overall firmware integrity score.

[0107] The firmware static analysis submodule is used to guess the firmware's code and data partitions, and to determine whether the function pointers in the firmware's interrupt vector table are available, thereby obtaining the third verification score.

[0108] The firmware virtualization runtime submodule extracts the corresponding reset function pointer from the interrupt vector table, loads the firmware program through the MCU virtualization execution engine, runs assembly statements, analyzes the running process, and obtains the fourth verification score.

[0109] The firmware data is divided into blocks of a specified size using the entropy analysis module (the block size can be set to 1024 bytes or other sizes), and the Shannon entropy of each data block is calculated to obtain the fifth verification score.

[0110] The sixth verification score is derived by utilizing the correspondence between firmware extraction results and scoring weights defined by the tester within the customized verification submodule. Testers can write scripts in Python or C# to customize this correspondence for specific scenarios. For example, an asymmetric key and data signature value can be extracted from a specific signature area of ​​the firmware, and asymmetric digital signature verification can be performed on the firmware data area. The return result type and scoring weights can be set by the tester.

[0111] In this embodiment, multi-dimensional firmware verification based on static analysis and virtualization is used to verify the firmware extraction results from multiple perspectives. The authenticity and usability of the firmware data are quantified through calculation, greatly improving the reliability of the firmware extraction results and reducing reliance on the experience of testers. This solves the problem of existing technologies lacking effective means to verify firmware extraction results.

[0112] As an optional embodiment, static analysis is performed on the firmware data extracted from the firmware to obtain a third verification score, including:

[0113] Obtain the interrupt vector table from the firmware data, wherein the interrupt vector table contains a first preset number of function pointers;

[0114] Check whether the function pointer points to the preset memory area;

[0115] If the pointer points to a preset memory region, and the preset memory region contains a usable preset function preamble, and there is a memory region within a preset distance of the preset memory region that can form a stack frame function, then the function pointer is determined to be usable.

[0116] The third verification score is obtained based on the number of available function pointers and the first preset number.

[0117] Optionally, the firmware static analysis submodule is used to analyze firmware data, guess the firmware code and data partitions, and extract the firmware interrupt vector table. The interrupt vector table contains multiple function pointers, with a first preset number indicating multiple pointers, without a specific limit on the number.

[0118] Determine whether these function pointers point to a valid memory region, i.e., the preset memory region.

[0119] If the memory region pointed to by the function pointer is valid, the memory region is further analyzed. If the memory region contains a usable assembly language function prologue, and the memory regions near the memory region (within a preset distance) can form a complete function stack frame, then the function pointer is determined to be usable.

[0120] The third verification score is: (number of available function pointers in the interrupt vector table ÷ total number of function pointers in the interrupt vector table) × 100.

[0121] In this embodiment of the application, the authenticity and usability of firmware data are quantified by calculation, which greatly improves the reliability of firmware extraction results.

[0122] As an optional embodiment, the firmware is virtualized and the virtualization process is analyzed to derive a fourth verification score, including:

[0123] Extract the reset function pointer from the interrupt vector table;

[0124] Execute assembly statements starting from the code segment pointed to by the reset function pointer;

[0125] Determine whether the virtualization process meets the preset conditions. If it does, terminate the execution of the assembly statements and determine that the integrity check has passed.

[0126] If the virtualization process meets a preset error condition before the preset conditions are met, the execution of the assembly statements will end and the integrity check will be deemed to have failed.

[0127] Based on the integrity verification result, a fourth verification score is generated.

[0128] Optionally, the firmware virtualization runtime submodule can be used to extract the function pointer for the corresponding reset function from the interrupt vector table.

[0129] The firmware program is loaded through the MCU virtualization execution engine, and assembly statements are executed starting from the code area pointed to by the Reset function pointer.

[0130] If the execution reaches the following conditions (preset conditions), the assembly statement execution will terminate, and the integrity check will be deemed successful:

[0131] a) The program attempts to read values ​​from the ROM, RAM area or the MCU peripheral memory-mapped area.

[0132] b) The program attempts to write values ​​to the ROM, RAM area or the MCU peripheral memory-mapped area.

[0133] c) The virtualization engine executes more than a specified number of assembly statements without throwing an exception.

[0134] If other situations are encountered before the execution process meets the above termination conditions, such as: throwing an exception or encountering an unresolved assembly statement, the execution will terminate and the integrity check will be deemed to have failed.

[0135] The fourth verification score is obtained based on whether the integrity verification passes.

[0136] In this embodiment of the application, the authenticity and usability of firmware data are quantified by calculation, which greatly improves the reliability of firmware extraction results.

[0137] As an optional embodiment, entropy analysis is performed on the firmware data to derive a fifth verification score, including:

[0138] The firmware data is divided into blocks according to a preset block size to obtain a second preset number of data blocks;

[0139] Based on the data block, a floating-point number sequence is obtained, wherein the floating-point number sequence contains a second preset number of floating-point numbers;

[0140] Get the upper and lower thresholds for floating-point numbers;

[0141] Get the number of the first floating-point numbers in the floating-point number sequence that fall between the upper and lower thresholds;

[0142] Get the number of the second floating-point number in the floating-point number sequence that is higher than the lower threshold;

[0143] The fifth verification score is obtained based on the number of first and second floating-point numbers.

[0144] Optionally, the firmware data can be divided into blocks according to a specified block size using the entropy analysis word module (the block size can be set to 1024 bytes or other sizes) to obtain multiple data blocks, where the second preset number represents multiple.

[0145] For each data block, calculate the Shannon information entropy (output a floating-point number between 0 and 8), resulting in a sequence of floating-point numbers.

[0146] Set a lower threshold (typically between 0 and 1) and an upper threshold (typically between 6 and 8).

[0147] The fourth verification score is: (number of data between the upper and lower thresholds ÷ number of data above the lower threshold) × 100.

[0148] In this embodiment of the application, the authenticity and usability of firmware data are quantified by calculation, which greatly improves the reliability of firmware extraction results.

[0149] As an optional embodiment, the method further includes the following steps before sending a read command to the chip under test:

[0150] Determine the protocol used by the debug interface of the chip under test;

[0151] Based on the protocol, identify the chip parameters of the chip under test;

[0152] Output chip parameters.

[0153] Optionally, a protocol adaptation module can be used to perform protocol adaptation with the MCU under test, determine the MCU debugging interface protocol, and successfully connect to the MCU.

[0154] After the protocol adaptation module returns a connection success message, a pre-run check is performed on the MCU chip, and the following types of chip parameters are automatically extracted and identified based on the feature library:

[0155] 1. Size and memory offset address of the non-volatile memory area (ROM). If the MCU contains multiple ROM areas (such as CodeFlash and Data Flash), they are identified separately.

[0156] 2. Size of volatile storage area (RAM) and memory offset address.

[0157] 3. Chip model.

[0158] 4. Supplier ID.

[0159] 5. Unique chip ID.

[0160] After successful identification, the chip parameters are output for testers to confirm. These chip parameters include the necessary conditions for the firmware extraction module to operate.

[0161] In this embodiment, the proposed solution employs an automated feature extraction and recognition method based on a feature library to identify parameters of the MCU chip and detect the necessary conditions for the firmware extraction module to operate. This solves the problem of existing technologies requiring excessive prior knowledge about the chip model.

[0162] As an optional embodiment, determining the protocol used by the debug interface of the chip under test includes:

[0163] Initialize the chip under test;

[0164] Send the first instruction according to the current debugging protocol, and determine whether the first preset response from the chip under test is received.

[0165] If no first-preset response is received, the next protocol will be tested.

[0166] If the first preset response is received, a second instruction is sent and it is determined whether the second preset response from the chip under test is received.

[0167] If no second preset response is received, determine whether other responses have been received;

[0168] If no further response is received, begin testing the next protocol;

[0169] If other responses are received, a secure debugging authorization is initiated, and it is determined whether a third preset response from the chip under test has been received.

[0170] If a second or third preset response is received, the connection is successful and the protocol is successfully acquired.

[0171] Optionally, since different MCU debugging interfaces use different protocols—for example, the RH850 series MCUs support JTAG (Joint Test Action Group) and LPD (Low Pin Debug) debugging protocols—protocol adaptation with the MCU under test is required. Before extracting the firmware, the tester should connect the debugger to the computer and use probes, ribbon cables, debug cables, chip sockets, etc., to connect the MCU under test to the debugger.

[0172] Once the MCU under test is connected, the protocol adaptation module will send instructions to detect the connectivity between the computer and the debugger, and between the debugger and the MCU's debug interface. It will also enumerate debug protocols to confirm whether the MCU has its debug interface open. Based on different protocols, signals are sent to specific pins of the MCU to determine the protocol used by the MCU's debug interface.

[0173] like Figure 4 As shown, the process of enumerating debugging protocols and testing the connectivity of the debugging interface includes:

[0174] MCU hard reset (initializing the chip under test); send a baud rate set command (Baud Rate Set), i.e., the first command; check if the first preset response to the baud rate set command is received, which can be a positive response (ACK) as shown in the diagram; if the first preset response is not received, test the next protocol; if received, send a reset command (Reset), i.e., the second command; check if the second preset response to the reset command is received, which can be a positive response (ACK) as shown in the diagram; if the second preset response is not received, check if other responses are received, such as a negative response (NACK) or a denial of service (STS-04); if no other responses are received, start testing the next protocol; if other responses are received, attempt to initiate a secure debug authorization, and check if a third preset response to the secure debug authorization is received, which can be a positive response (ACK) as shown in the diagram; if no third preset response is received, the connection fails, and feedback is sent to the tester; if the second or third preset response is received, the connection is successful and the protocol is successfully acquired.

[0175] In this embodiment, by enumerating debugging protocols and testing the connectivity of the debugging interface, the protocol used by the debugging interface of the chip under test is finally obtained, and the chip under test is successfully connected, which improves the application scope of the solution and improves the firmware extraction efficiency.

[0176] According to another aspect of the embodiments of this application, an apparatus for verifying extracted firmware data is also provided for implementing the above-described method for verifying extracted firmware data. Figure 5 This is a structural block diagram of an optional apparatus for verifying extracted firmware data according to an embodiment of this application, such as... Figure 5 As shown, the device may include:

[0177] The sending module 501 is used to send a read command to the chip under test, wherein the read command is used to extract firmware data;

[0178] The first verification module 502 is used to perform a first verification on the transmitted communication data during the firmware data extraction process to obtain the firmware extraction result. The first verification is used to determine the correctness of the firmware data.

[0179] The second verification module 503 is used to perform a second verification on the firmware extraction results and obtain a firmware data integrity score. The second verification is used to determine the integrity of the firmware data.

[0180] It should be noted that the sending module 501 in this embodiment can be used to perform the above step S101, the first verification module 502 in this embodiment can be used to perform the above step S102, and the second verification module 503 in this embodiment can be used to perform the above step S103.

[0181] Through the aforementioned modules, during the firmware data extraction process, a first verification is performed on the transmitted communication data to determine whether any errors occurred during the firmware extraction process, thereby judging whether the extracted firmware data is authentic and reliable. After obtaining the firmware extraction result, a second verification is performed on the firmware extraction result, verifying the extracted firmware data content from multiple perspectives and deriving a firmware data integrity score. The authenticity and usability of the firmware data are quantified through calculation, greatly improving the reliability of the firmware extraction result. This solves the problem in related technologies that lack effective means to verify the firmware data extraction process and firmware extraction results, making it impossible to determine whether the extracted firmware data is authentic and reliable.

[0182] As an optional embodiment, the device further includes:

[0183] The determination module is used to determine the protocol used by the debugging interface of the chip under test;

[0184] The identification module is used to identify the chip parameters of the chip under test based on the protocol.

[0185] Output module, used to output chip parameters.

[0186] As an optional embodiment, the first verification module includes:

[0187] Identification unit, used to identify communication data;

[0188] The first recording unit is used to record the read success address and firmware data corresponding to the data packet if the communication data is a data packet.

[0189] The decoding unit is used to decode the error code to obtain the error type if the communication data is an error code;

[0190] The first judgment unit is used to determine whether the error type allows recovery;

[0191] The first transmitting unit is used to resend the read command to the chip under test if recovery is allowed;

[0192] The second recording unit is used to record the address of the read failure corresponding to the error code if recovery is not allowed.

[0193] As a unit, it is used to extract the firmware data as the successful read address, firmware data, and failed read address when all data areas have been read.

[0194] As an optional embodiment, the second verification module includes:

[0195] The first calculation unit is used to calculate the first preset hash value of the data area in the firmware extraction result, and compare the first preset hash value with the first target value to obtain the first verification score.

[0196] The second calculation unit is used to calculate the second preset hash value of the data area in the firmware extraction result, and compare the second preset hash value with the second target value to obtain the second verification score.

[0197] The first output unit is used to perform static analysis on the firmware data extracted from the firmware and to obtain the third verification score.

[0198] The second unit is used to run the firmware program in virtualization and analyze the virtualization process to obtain the fourth verification score.

[0199] The third unit is used to perform entropy analysis on the firmware data and obtain the fifth verification score.

[0200] The fourth unit is used to derive the sixth verification score based on the correspondence between the custom firmware extraction results and the scoring weights.

[0201] The obtaining unit is used to obtain the integrity score of firmware data based on the first verification score, the second verification score, the third verification score, the fourth verification score, the fifth verification score, and the sixth verification score.

[0202] As an optional embodiment, the first deriving unit includes:

[0203] The first acquisition submodule is used to acquire the interrupt vector table in the firmware data, wherein the interrupt vector table contains a first preset number of function pointers;

[0204] The first judgment submodule is used to determine whether the function pointer points to a preset memory area;

[0205] The determination submodule is used to determine if a function pointer is available when it points to a preset memory region. If the preset memory region contains available preset function preambles, and there is a memory region within a preset distance of the preset memory region that can form a stack frame function, then the function pointer is available.

[0206] The first submodule is used to obtain the third verification score based on the number of available function pointers and the first preset number.

[0207] As an optional embodiment, the second deriving unit includes:

[0208] The extraction submodule is used to extract the reset function pointer from the interrupt vector table;

[0209] The execution submodule is used to execute assembly statements starting from the code region pointed to by the reset function pointer.

[0210] The second judgment submodule is used to determine whether the virtualization operation process meets the preset conditions. If it does, the execution of the assembly statement ends and the integrity check is deemed to have passed.

[0211] The determination submodule is used to terminate the execution of assembly statements and determine that the integrity check fails if the virtualization process meets the preset error conditions before the virtualization process meets the preset conditions.

[0212] The generation submodule is used to generate a fourth verification score based on the integrity verification result.

[0213] As an optional embodiment, the third deriving unit includes:

[0214] The second submodule is used to divide the firmware data into blocks according to a preset block size to obtain a second preset number of data blocks;

[0215] The third submodule is used to obtain a floating-point number sequence based on the data block, wherein the floating-point number sequence contains a second preset number of floating-point numbers;

[0216] The second acquisition submodule is used to acquire the upper and lower thresholds of floating-point numbers;

[0217] The third acquisition submodule is used to acquire the number of first floating-point numbers in the floating-point number sequence that are between the upper threshold and the lower threshold.

[0218] The fourth acquisition submodule is used to obtain the number of second floating-point numbers in the floating-point number sequence that are higher than the lower threshold;

[0219] The fourth submodule is used to obtain the fifth verification score based on the first number of floating-point numbers and the second number of floating-point numbers.

[0220] As an optional embodiment, the determining module includes:

[0221] An initialization unit is used to initialize the chip under test.

[0222] The second judgment unit is used to send a first instruction according to the current debugging protocol and determine whether the first preset response of the chip under test is received.

[0223] The first test unit is used to start testing the next protocol if no first preset response is received.

[0224] The second sending unit is used to send a second instruction and determine whether the second preset response from the chip under test has been received if the first preset response is received.

[0225] The third judgment unit is used to send a second instruction and determine whether the second preset response from the chip under test is received if the first preset response is received.

[0226] The second test unit is used to start testing the next protocol if no other response is received.

[0227] The fourth judgment unit is used to initiate a secure debugging authorization if other responses are received, and to determine whether a third preset response from the chip under test has been received.

[0228] The acquisition unit is used to confirm a successful connection and successful acquisition of the protocol if a second or third preset response is received.

[0229] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments.

[0230] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described method for verifying extracted firmware data is also provided. The electronic device may be a server, a terminal, or a combination thereof.

[0231] Figure 6 This is a structural block diagram of an optional electronic device according to an embodiment of this application, such as... Figure 6 As shown, it includes a processor 601, a communication interface 602, a memory 603, and a communication bus 604. The processor 601, communication interface 602, and memory 603 communicate with each other via the communication bus 604.

[0232] Memory 603 is used to store computer programs;

[0233] When processor 601 executes a computer program stored in memory 603, it performs the following steps:

[0234] Send a read command to the chip under test, whereby the read command is used to extract firmware data;

[0235] During the firmware data extraction process, the transmitted communication data is first verified to obtain the firmware extraction result. The first verification is used to determine the correctness of the firmware data.

[0236] A second verification is performed on the firmware extraction results to obtain a firmware data integrity score. The second verification is used to determine the integrity of the firmware data.

[0237] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0238] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0239] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0240] As an example, such as Figure 6 As shown, the memory 603 may include, but is not limited to, the sending module 501, the first verification module 502, and the second verification module 503 in the device for verifying the extracted firmware data. Furthermore, it may include, but is not limited to, other module units in the device for verifying the extracted firmware data, which will not be elaborated further in this example.

[0241] The processors mentioned above can be general-purpose processors, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; they can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0242] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0243] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. The device that implements the above method for verifying the extracted firmware data can be a terminal device, such as a smartphone (e.g., an Android phone, an iOS phone), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic devices. For example, the terminal device may also include components that are more advanced than those described above. Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0244] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, ROM, RAM, disk or optical disk, etc.

[0245] According to another aspect of the embodiments of this application, a storage medium is also provided. Optionally, in this embodiment, the storage medium can be used to store program code for executing a method to verify extracted firmware data.

[0246] Optionally, in this embodiment, the storage medium may be located on at least one of the network devices in the network shown in the above embodiment.

[0247] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps:

[0248] Send a read command to the chip under test, whereby the read command is used to extract firmware data;

[0249] During the firmware data extraction process, the transmitted communication data is first verified to obtain the firmware extraction result. The first verification is used to determine the correctness of the firmware data.

[0250] A second verification is performed on the firmware extraction results to obtain a firmware data integrity score. The second verification is used to determine the integrity of the firmware data.

[0251] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated in this embodiment.

[0252] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0253] In the description of this specification, the references to terms such as "this embodiment," "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0254] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A method for verifying extracted firmware data, characterized in that, The method includes: Send a read command to the chip under test, wherein the read command is used to extract firmware data; During the process of extracting the firmware data, a first verification is performed on the transmitted communication data to obtain the firmware extraction result, wherein the first verification is used to determine the correctness of the firmware data; A second verification is performed on the firmware extraction result to obtain an integrity score for the firmware data, wherein the second verification is used to determine the integrity of the firmware data; The second verification of the firmware extraction result to obtain a firmware data integrity score includes: calculating a first preset hash value of the data area in the firmware extraction result and comparing the first preset hash value with a first target value to obtain a first verification score; calculating a second preset hash value of the data area in the firmware extraction result and comparing the second preset hash value with a second target value to obtain a second verification score; performing static analysis on the firmware data in the firmware extraction result to obtain a third verification score; virtualizing and running the firmware program and analyzing the virtualization process to obtain a fourth verification score; performing entropy analysis on the firmware data to obtain a fifth verification score; obtaining a sixth verification score based on a customized correspondence between the firmware extraction result and the scoring weights; and obtaining a firmware data integrity score based on the first verification score, the second verification score, the third verification score, the fourth verification score, the fifth verification score, and the sixth verification score.

2. The method according to claim 1, characterized in that, The transmitted communication data undergoes a first verification to obtain the firmware extraction results, including: Identify the communication data; If the communication data is a data packet, then record the read success address corresponding to the data packet and the firmware data; If the communication data is an error code, then the error code is decoded to obtain the error type; Determine whether the error type allows for recovery; If recovery is permitted, the read command is resent to the chip under test; If recovery is not allowed, record the address where the read failed to read the error code. When all data areas have been read, the address where the read was successful, the firmware data, and the address where the read failed are taken as the firmware extraction result.

3. The method according to claim 1, characterized in that, The third verification score is obtained by statically analyzing the firmware data extracted from the firmware, including: Obtain the interrupt vector table from the firmware data, wherein the interrupt vector table contains a first preset number of function pointers; Determine whether the function pointer points to a preset memory region; If, when pointing to the preset memory region, the preset memory region contains a usable preset function preamble, and there exists a memory region within a preset distance of the preset memory region that can form a stack frame function, then the function pointer is determined to be usable. The third verification score is obtained based on the number of available function pointers and the first preset number.

4. The method according to claim 3, characterized in that, The virtualized running firmware is analyzed, and the virtualization running process is analyzed to obtain a fourth verification score, including: Extract the reset function pointer from the interrupt vector table; The assembly statements are executed starting from the code region pointed to by the reset function pointer; Determine whether the virtualization process meets preset conditions. If it does, terminate the execution of the assembly statement and determine that the integrity check has passed. If the virtualization process meets a preset error condition before the virtualization process meets the preset condition, then the execution of the assembly statement will end and the integrity check will be determined to have failed. Based on the integrity verification result, the fourth verification score is generated.

5. The method according to claim 1, characterized in that, The entropy analysis of the firmware data to obtain the fifth verification score includes: The firmware data is divided into blocks according to a preset block size to obtain a second preset number of data blocks; Based on the data block, a floating-point number sequence is obtained, wherein the floating-point number sequence contains a second preset number of floating-point numbers; Obtain the upper and lower threshold values ​​of the floating-point number; Obtain the number of first floating-point numbers in the floating-point number sequence that fall between the upper threshold and the lower threshold; Obtain the number of second floating-point numbers in the floating-point number sequence that are higher than the lower threshold; The fifth verification score is obtained based on the first number of floating-point numbers and the second number of floating-point numbers.

6. The method according to claim 1, characterized in that, Before sending the read command to the chip under test, the method further includes: Determine the protocol used by the debug interface of the chip under test; Based on the protocol, the chip parameters of the chip under test are identified; Output the chip parameters.

7. The method according to claim 6, characterized in that, The determination of the protocol used by the debugging interface of the chip under test includes: Initialize the chip under test; Send a first instruction according to the current debugging protocol, and determine whether a first preset response from the chip under test is received; If the first preset response is not received, the next protocol will be tested. If the first preset response is received, a second instruction is sent and it is determined whether a second preset response from the chip under test is received. If the second preset response is not received, determine whether other responses have been received; If no other response is received, begin testing the next protocol; If the other responses are received, a secure debugging authorization is initiated, and it is determined whether a third preset response from the chip under test has been received. If the second preset response or the third preset response is received, the connection is successful and the protocol is successfully acquired.

8. An apparatus for verifying extracted firmware data, characterized in that, include: The sending module is used to send a read command to the chip under test, wherein the read command is used to extract firmware data; The first verification module is used to perform a first verification on the transmitted communication data during the process of extracting the firmware data to obtain the firmware extraction result, wherein the first verification is used to determine the correctness of the firmware data. The second verification module is used to perform a second verification on the firmware extraction result and obtain an integrity score of the firmware data, wherein the second verification is used to determine the integrity of the firmware data; The second verification module includes: a first calculation unit, used to calculate a first preset hash value of the data area in the firmware extraction result, and compare the first preset hash value with a first target value to obtain a first verification score; a second calculation unit, used to calculate a second preset hash value of the data area in the firmware extraction result, and compare the second preset hash value with a second target value to obtain a second verification score; a first derivation unit, used to perform static analysis on the firmware data in the firmware extraction result to obtain a third verification score; a second derivation unit, used to virtualize and run the firmware program, and analyze the virtualization process to obtain a fourth verification score; a third derivation unit, used to perform entropy analysis on the firmware data to obtain a fifth verification score; a fourth derivation unit, used to obtain a sixth verification score based on a custom correspondence between the firmware extraction result and the scoring weights; and a obtaining unit, used to obtain an integrity score of the firmware data based on the first verification score, the second verification score, the third verification score, the fourth verification score, the fifth verification score, and the sixth verification score.

9. An electronic device comprising a processor, a communication interface, a memory, and a communication bus, wherein, The processor, the communication interface, and the memory communicate with each other via the communication bus, characterized in that... The memory is used to store computer programs; The processor is configured to perform the steps of the method according to any one of claims 1 to 7 by running the computer program stored in the memory.

Images