Software verification method, device, medium and program product

Abstract

Embodiments of the present application provide a software verification method and device, a medium and a program product, and relate to the technical field of software engineering. The method comprises: downloading a description file containing verification parameters of a plurality of data blocks, the plurality of data blocks being obtained by block division of to-be-verified software; receiving the plurality of data blocks and, after transmission of any data block is completed, executing an asynchronous verification task on any data block according to the verification parameters in the description file; and in the asynchronous verification task, verifying the plurality of data blocks one by one and recording identification information of a data block that fails verification. Based on the method, the real-time performance and flexibility of the verification process can be improved, the centralized consumption of system resources can be reduced through asynchronous verification logic, and efficient, real-time and error-locatable verification can be achieved.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a software verification method, device, medium, and program product. Background Technology

[0002] In intelligent connected vehicles, the Electronic Control Unit (ECU) is responsible for core functions such as vehicle power control, safety systems, and infotainment. The complexity of its software functions and the frequency of upgrades increase significantly with the improvement of vehicle intelligence. For example, during the vehicle's life cycle, the ECU software may need to be remotely upgraded via Over-The-Air (OTA) to fix vulnerabilities, optimize performance, or adapt to new regulations.

[0003] However, such software upgrades face multiple technical challenges. First, ECUs typically operate in resource-constrained microcontroller units (MCUs), whose main loops need to respond to sensor data and execute control logic in real time. Any prolonged blocking operations (such as overall hash calculations) can cause system response delays and even security risks. Second, data errors may occur during software transmission due to communication interference, power fluctuations, or storage media failures. If errors are not detected in time, invalid transmission or system malfunction may result. Third, traditional verification methods can only determine the overall data integrity and cannot pinpoint the specific error location. This necessitates retransmission of all data after verification failure, significantly increasing upgrade time and network load. Furthermore, software upgrades for automotive ECUs must meet high security requirements, necessitating digital signature verification of software origin trustworthiness. However, existing solutions struggle to balance security and verification efficiency.

[0004] Therefore, there is an urgent need for a verification method that can ensure software integrity and reliability while also being efficient, real-time, and capable of locating errors, in order to meet the reliability and real-time requirements of intelligent vehicles for software upgrades. Summary of the Invention

[0005] This application provides a software verification method, device, medium, and program product for achieving efficient, real-time, and error-locating verification during software verification.

[0006] In a first aspect, embodiments of this application provide a software verification method, the method comprising:

[0007] Download the description file containing verification parameters for multiple data blocks, which are obtained by dividing the software to be verified into blocks;

[0008] Receive multiple data blocks and, after the transmission of any data block is completed, perform an asynchronous verification task on any data block according to the verification parameters in the description file;

[0009] In the asynchronous verification task, multiple data blocks are verified one by one, and the identification information of the data blocks that fail to be verified is recorded.

[0010] In one possible implementation, an asynchronous verification task is performed on any data block according to the verification parameters in the description file, including:

[0011] Extract the data to be verified from the data block that has been transmitted, based on the address and length of the data block in the description file;

[0012] Calculate the hash value of the data to be verified using a secure hash algorithm;

[0013] The calculated hash value is compared with the expected hash value stored in the description file.

[0014] In one possible implementation, the hash value of the data to be verified is calculated using a secure hash algorithm, including:

[0015] The hardware acceleration module is invoked, and the data to be verified is directly read through the hardware acceleration module to perform secure hash algorithm calculation and output the hash value of the data to be verified; the hardware acceleration module is an independent functional module used for hash value calculation.

[0016] In one possible implementation, after recording the identification information of the data block that failed verification, the method further includes:

[0017] Based on the identification information of the data blocks that failed verification, an incremental re-flush request is generated;

[0018] Incremental refresh requests are used to retransmit data blocks that failed to be validated.

[0019] In one possible implementation, the description file is obtained as follows:

[0020] The storage structure of the software to be verified is analyzed to determine the address, length, and checksum of each of the multiple data blocks.

[0021] Write the addresses, lengths, and checksums of multiple data blocks into a description file in a self-describing format.

[0022] In one possible implementation, the multiple data blocks are obtained by dividing the data into blocks in the following manner:

[0023] Obtain information about the functional areas of the software to be verified, the network bandwidth of the communication channel through which the software to be verified is transmitted, and / or receive the load status of the receiver of the software to be verified.

[0024] Based on functional area information, network bandwidth and / or load status, determine the size of the data blocks to be divided into multiple data blocks, and divide the software to be verified into blocks according to the determined data block size.

[0025] In one possible implementation, the method further includes:

[0026] If all data blocks have been verified and passed, perform signature verification on the description file and return the signature verification result to the sending end of the software to be verified.

[0027] Secondly, embodiments of this application provide a software verification device, the device comprising:

[0028] The download module is used to download a description file containing verification parameters that includes multiple data blocks. These multiple data blocks are obtained by dividing the software to be verified into blocks.

[0029] The verification module is used to receive multiple data blocks and, after the transmission of any data block is completed, to perform an asynchronous verification task on any data block according to the verification parameters in the description file.

[0030] The recording module is used to verify multiple data blocks one by one in an asynchronous verification task and record the identification information of the data blocks that fail to be verified.

[0031] In one possible implementation, the verification module is specifically used for:

[0032] Extract the data to be verified from the data block that has been transmitted, based on the address and length of the data block in the description file;

[0033] Calculate the hash value of the data to be verified using a secure hash algorithm;

[0034] The calculated hash value is compared with the expected hash value stored in the description file.

[0035] In one possible implementation, the verification module is specifically used for:

[0036] The hardware acceleration module is invoked, and the data to be verified is directly read through the hardware acceleration module to perform secure hash algorithm calculation and output the hash value of the data to be verified; the hardware acceleration module is an independent functional module used for hash value calculation.

[0037] In one possible implementation, the device includes a retransmission module, which is used to:

[0038] Based on the identification information of the data blocks that failed verification, an incremental re-flush request is generated;

[0039] Incremental refresh requests are used to retransmit data blocks that failed to be validated.

[0040] In one possible implementation, the description file is obtained as follows:

[0041] The storage structure of the software to be verified is analyzed to determine the address, length, and checksum of each of the multiple data blocks.

[0042] Write the addresses, lengths, and checksums of multiple data blocks into a description file in a self-describing format.

[0043] In one possible implementation, the multiple data blocks are obtained by dividing the data into blocks in the following manner:

[0044] Obtain information about the functional areas of the software to be verified, the network bandwidth of the communication channel through which the software to be verified is transmitted, and / or receive the load status of the receiver of the software to be verified.

[0045] Based on functional area information, network bandwidth and / or load status, determine the size of the data blocks to be divided into multiple data blocks, and divide the software to be verified into blocks according to the determined data block size.

[0046] In one possible implementation, the apparatus further includes a verification module, which is used for:

[0047] If all data blocks have been verified and passed, perform signature verification on the description file and return the signature verification result to the sending end of the software to be verified.

[0048] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0049] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0050] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0051] The software verification method, device, medium, and program product provided in this application have the following advantages: The method involves downloading a description file containing verification parameters for multiple data blocks. Upon receiving the transmission of any data block, it performs an asynchronous verification task on that data block according to the verification parameters in the description file. This eliminates the need to wait for all data from the software to be verified to be transmitted before starting verification, achieving asynchronous verification through task splitting and improving the overall efficiency of software verification. Furthermore, by recording the identification information of data blocks that fail verification during the asynchronous verification task, necessary foundations and criteria can be provided for locating and retransmitting erroneous data. Based on this, the method not only improves the real-time performance and flexibility of the verification process but also reduces the concentrated consumption of system resources through asynchronous verification logic, achieving efficient, real-time, and error-locating verification. Attached Figure Description

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

[0053] Figure 1 A flowchart illustrating the software verification method provided in this application embodiment;

[0054] Figure 2 A schematic diagram of the SIM structure and dual-layer protection mechanism provided in the embodiments of this application;

[0055] Figure 3 One of the three-stage timing flowcharts for integrity verification provided in the embodiments of this application;

[0056] Figure 4 The second schematic diagram of the three-stage timing flow for integrity verification provided in the embodiments of this application;

[0057] Figure 5 The third schematic diagram of the three-stage timing flow for integrity verification provided in the embodiments of this application;

[0058] Figure 6 A schematic diagram comparing existing solutions with the solutions provided in this application for the embodiments of this application;

[0059] Figure 7 This is a schematic diagram of the structure of the software verification device provided in the embodiments of this application;

[0060] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0061] Figure 9 This is a schematic diagram of the architecture of a software verification system provided in an embodiment of this application.

[0062] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0063] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0064] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0065] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0066] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0067] In the embodiments of this application, the use of terms such as "first" and "second" is to distinguish between identical or similar items that have essentially the same function and effect. For example, "first electronic device" and "second electronic device" are merely used to distinguish different electronic devices and do not limit their order of execution. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0068] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0069] In existing technologies, the integrity verification of automotive ECU software flashing primarily employs a whole-file hash + digital signature verification scheme. The core process of this scheme typically involves calculating a hash value for the entire software file after transmission and verifying the source of the hash value's trustworthiness through a digital signature. If the hash value matches the expected value and the signature is valid, the flashing is considered successful. While this scheme offers certain security advantages, it also suffers from several drawbacks.

[0070] Existing methods suffer from drawbacks such as long computation time and blocking of the main loop. Specifically, performing overall hash calculations on large-capacity software such as megabytes (MB) requires a large amount of central processing unit (CPU) resources, causing the ECU main loop to be blocked for a long time, affecting the execution of real-time tasks (such as sensor data acquisition and safety control logic), and potentially causing system anomalies or security risks.

[0071] Existing methods also suffer from delayed verification timing. Specifically, existing schemes only trigger verification after all data transmission is complete, failing to detect errors in real time during transmission. This results in erroneous data potentially being written to storage, increasing the complexity of error handling.

[0072] Existing methods also suffer from difficulties in error localization. Specifically, when verification fails, existing schemes can only determine that the overall data is abnormal, but cannot locate the specific erroneous data block, which necessitates retransmitting all data, wasting communication resources and time.

[0073] Existing methods also suffer from high recovery costs. Specifically, even with only a few data errors, current solutions still require re-flashing the entire software, significantly reducing upgrade efficiency, especially in low-bandwidth or high-latency network environments.

[0074] Existing methods also suffer from the drawback of balancing security and verification efficiency. Specifically, existing schemes rely on overall hashing and overall signature verification, which can ensure security but cannot meet the real-time requirements of resource-constrained environments and is difficult to balance with verification efficiency.

[0075] In addition, existing solutions do not make sufficient use of self-describing structures such as Software Integrity Manifest (SIM), lack asynchronous design for the verification process, and are difficult to adapt to the real-time and low-power requirements of resource-constrained MCU environments.

[0076] Starting from the technical problems discovered in the prior art, the inventors gradually constructed the technical solutions of the embodiments of this application, which specifically include the following aspects.

[0077] First, a block-based processing and asynchronous verification scheme is proposed. To address the main loop blocking issue, the software can be divided into multiple data blocks before being sent. These blocks are then verified one by one using an asynchronous task mechanism (such as state machine scheduling), avoiding prolonged blocking of the main loop. Second, a self-describing Software Integrity Inventory (SIM) is used to resolve the ECU's dependency on pre-set information. By employing a SIM structure and storing all verification parameters (such as block address, length, and hash value) in a self-describing format, the ECU can dynamically parse the verification logic without pre-setting block information.

[0078] Furthermore, by employing a precise error location and incremental recovery mechanism, and through block-by-block verification, the error block can be located instantly. Based on the error identity document (ID), an incremental re-flash process is triggered, requiring only the error block to be retransmitted, significantly reducing recovery time.

[0079] In addition, a dual-layer protection mechanism can be introduced. Specifically, to balance security and reliability, the inventors proposed a dual-layer protection mechanism, which can be understood as follows: data integrity is verified through a first-layer block-level hash, and the source credibility is verified through a second-layer SIM signature. If either layer fails, the write operation is rejected, ensuring both security and reliability.

[0080] Based on the above technical concept, the method of this application embodiment aims to achieve efficient, real-time, and location-based software verification by introducing a SIM-based self-describing block mechanism, an instantaneous asynchronous verification process, precise error location capabilities, and an incremental re-flash strategy, while ensuring a balance between security and resource consumption, thus meeting the high requirements of intelligent vehicle ECU software upgrades.

[0081] In view of this, embodiments of this application provide a software verification method. This method combines a block-based asynchronous verification mechanism with a self-describing software integrity manifest to achieve real-time, location-based, and efficient data integrity verification during software flashing. The method, centered on "block processing + asynchronous verification + incremental recovery," transforms the single-point blocking problem of existing overall hash verification into an asynchronous, phased, lightweight verification task. Simultaneously, it stores verification parameters using a SIM structure, avoiding reliance on pre-set information in the ECU and ensuring the flexibility and security of the verification process.

[0082] The software verification method provided in this application can be widely applied to scenarios such as software flashing of automotive electronic control units, especially in OTA-based remote upgrade scenarios where it can efficiently verify software. For example, in intelligent connected vehicles, the ECU needs to run in a resource-constrained MCU environment, and its main loop needs to respond to sensor data and execute control logic in real time, while software upgrades need to meet high security requirements. Existing overall hash verification schemes suffer from low upgrade efficiency and even system anomalies due to long computation time, inability to detect errors in real time, and difficulty in error location. The method in this application, through a block asynchronous verification mechanism, can verify each data block in real time during transmission, accurately locate errors, and only re-flash the erroneous parts, significantly improving upgrade efficiency and system reliability.

[0083] The technical solutions of this application will be described in detail below with reference to specific embodiments. The specific embodiments described below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0084] Figure 1 This is a flowchart illustrating the software verification method provided in an embodiment of this application. The execution subject of this method can be an electronic device with corresponding data storage and computing capabilities, such as an ECU or other processors. Figure 1 As shown, the method includes:

[0085] S101, Download the description file containing verification parameters for multiple data blocks. The multiple data blocks are obtained by dividing the software to be verified into blocks.

[0086] For example, the software to be verified can be of any size, type, and / or purpose, and must be verified. For instance, it could be upgrade software for an onboard ECU. Here, software can be understood as a computer program that includes computer instructions and / or data.

[0087] A data block can be understood as a verification unit after the software is divided. The size of a data block can be fixed or dynamic. For example, a data block can be a code segment of fixed size of 4 kilobytes (KB).

[0088] A description file can be understood as a self-describing structured file that stores data block verification parameters. For example, it may contain the number, address, length, and verification value of multiple data blocks. In other words, a description file can be understood as a SIM file.

[0089] The sender (such as a host computer or diagnostic tool) can divide the software to be verified into multiple data blocks before sending it. Based on the metadata of each data block, such as address, length, and checksum, a description file can be generated for the receiver to use for data verification. After the sender and receiver establish a communication channel, the receiver can download the description file.

[0090] S102: Receive multiple data blocks and, after the transmission of any data block is completed, perform an asynchronous verification task on any data block according to the verification parameters in the description file.

[0091] For example, the sender can send multiple data blocks of the software to be verified to the electronic device (receiver) executing the method. The asynchronous verification task can be understood as a verification process executed through a non-blocking scheduling mechanism (such as a state machine or task queue), ensuring that the main loop does not need to wait for verification to complete. Verification parameters can be understood as technical indicators used to verify the integrity of the data blocks, such as the address, length, and hash value of the data blocks.

[0092] Based on step S102, an instantaneous asynchronous verification mechanism can be implemented. Verification is triggered immediately after each block transmission is completed, without waiting for all blocks to complete. After the verification service is triggered, the ECU sets the asynchronous task flag and immediately returns to wait for a response, while the main loop periodically schedules and executes the actual verification.

[0093] The verification process can be performed block-by-block, including reading block information, calculating hash values, and comparing them with expected hash values. Each scheduler can process at least one block without blocking the main loop. The key to this step lies in the software processing flow; for example, triggering single-block verification by transmitting data out of service, using an asynchronous state machine for non-blocking processing, rather than the existing synchronous blocking verification after all transmissions are completed.

[0094] In one possible implementation, an asynchronous verification task is performed on any data block according to the verification parameters in the description file, including: extracting the data to be verified from the transmitted data block according to the address and length of the data block in the description file; calculating the hash value of the data to be verified using a secure hash algorithm; and comparing the calculated hash value with the expected hash value stored in the description file.

[0095] For example, a secure hash algorithm can be understood as an encryption algorithm used to generate data digests, such as the Secure Hash Algorithm 256-bit (SHA-256). The output value of a secure hash algorithm is unique and irreversible. The expected hash value can be understood as the hash value corresponding to the data block pre-stored in the description file, used to verify the integrity of the data block.

[0096] For example, after each data block is transmitted, the data block to be verified can be located based on its address and length in the description file. For instance, reading 4KB of data from the 0x1000~0x1FFF address range of flash memory can locate a data block. Then, the SHA-256 secure hash algorithm is used to calculate the hash value of this data block. This hash value is then compared with the expected hash value of the data block pre-stored in the description file to verify the data block.

[0097] For example, if the calculated hash value and the expected hash value are different, it indicates that the two hash values ​​are inconsistent, triggering an error logging process. This might involve writing the data block's identification information (such as Block ID 3 and data block address 0x1000) to the error log to record that the data block failed the verification. If the calculated hash value and the expected hash value are the same, it indicates that the two hash values ​​are consistent, and the error logging process will not be triggered. This process achieves data block integrity verification through block processing and hash comparison, ensuring that the main loop can continue executing other tasks without waiting for the verification to complete.

[0098] In this embodiment, precise verification at the data block level is achieved through block-by-block calculation and comparison using a secure hash algorithm. The combination of block processing and hash value comparison avoids the lag in overall hash calculation of the software to be verified, while the uniqueness of hash values ​​ensures highly reliable verification of whether data blocks have been tampered with. Furthermore, the irreversibility of hash calculation prevents attackers from bypassing verification by modifying data block content, thereby improving verification efficiency while enhancing the security and reliability of the task.

[0099] S103, in the asynchronous verification task, verifies multiple data blocks one by one and records the identification information of the data blocks that fail to be verified.

[0100] For example, the identification information can be understood as a unique identifier of the data block recorded when the verification fails, such as one or more of the following: the data block's identity (Block ID), storage address, and data length. For instance, a Block index is maintained, and each Block is verified, with the hash value matching result determined in real time. When a mismatch occurs, the Block ID, address, length, etc., of the erroneous Block are recorded, and an error message is returned immediately.

[0101] For example, before executing step S101, the sender can divide the software to be verified into multiple data blocks and generate a description file to store verification parameters (such as address, length, hash value, etc.), thus ensuring the flexibility and scalability of the verification process. When executing step S101, the receiver can download the description file to perform data block verification based on the verification parameters in the description file.

[0102] After any data block has been transmitted, the electronic device executing the task can trigger an asynchronous verification task based on the verification parameters in the description file to verify the newly transmitted data block. For example, when executing the verification task, a non-blocking scheduling mechanism (such as a state machine) can be used to process data blocks one by one, avoiding the main loop resources being occupied for a long time.

[0103] The specific process of an asynchronous verification task can be as follows: read the data block information in the description file, calculate the hash value of the current data block and compare it with the expected value of the hash value of the data block in the description file. If the two are inconsistent, record the identification information of the data block (such as Block ID, address, etc.).

[0104] The entire process described above can be implemented asynchronously through block processing and asynchronous scheduling to ensure the priority of real-time tasks in the main loop, while enabling error location through block-by-block verification and error recording mechanisms.

[0105] The software verification method provided in this application solves the main loop blocking problem caused by existing overall hash verification by combining block reception with asynchronous verification tasks. Block reception can divide a large-capacity software verification task into multiple lightweight tasks. Each task only needs to process the verification logic of a single data block, which significantly reduces the CPU resource consumption of a single verification and avoids blocking the main loop.

[0106] For example, asynchronous verification tasks can be executed through a non-blocking scheduling mechanism (such as a state machine), and the main loop can continue to execute other real-time tasks (such as sensor data acquisition and safety control logic) without waiting for the verification to complete, thereby avoiding the main loop from being blocked.

[0107] Furthermore, the block-by-block verification and error logging mechanism can detect data errors as early as possible by instantly identifying erroneous data blocks and recording their identification information. This provides a precise basis for subsequent error recovery, thus improving the overall efficiency of software verification. Based on this, this method not only enhances the real-time performance and flexibility of the verification process but also reduces the concentrated consumption of system resources through asynchronous verification logic. It is particularly suitable for resource-constrained MCU environments, significantly enhancing the reliability and efficiency of software upgrades.

[0108] For example, calculating the hash value of a data block on an MCU would be time-consuming, affecting the execution of the main loop, especially in scenarios involving large-scale software upgrades. Therefore, the method in this embodiment can perform the hash value calculation of the block using a hardware acceleration module built into the MCU, such as a SHA-256 coprocessor, to directly read the data block's data and output the corresponding hash value, thus reducing the CPU resource consumption of the main loop.

[0109] In one possible implementation, calculating the hash value of the data to be verified using a secure hash algorithm includes: calling a hardware acceleration module, directly reading the data to be verified through the hardware acceleration module to perform secure hash algorithm calculation, and outputting the hash value of the data to be verified; wherein, the hardware acceleration module is an independent functional module used for hash value calculation.

[0110] For example, a hardware acceleration module can be understood as an independent functional module in a microcontroller unit environment that can be used to perform hash value calculations. It can be a dedicated hardware unit, such as an SHA-256 coprocessor. The hardware acceleration module can directly access memory and read data without CPU intervention.

[0111] For example, when calculating the hash value of the data to be verified, the electronic device can call the hardware acceleration module built into the MCU (such as the SHA-256 coprocessor) to directly read the data to be verified (such as 0x1000~0x1FFF of Block 3) from the memory through the hardware acceleration module. After reading the data, the hash value is calculated directly and the hash value is output. This can reduce the CPU resource consumption of the main processor unit such as the ECU.

[0112] For example, because the hardware acceleration module can quickly complete hash value calculation through a dedicated instruction set, it can shorten the time consumption of a single verification. For instance, the SHA-256 coprocessor can complete the hash value calculation of a block in microseconds, while software algorithms based on the main processor may take several milliseconds. Therefore, the solution in this embodiment not only improves verification efficiency but also reduces the time and energy consumption of the verification process, thereby extending the ECU battery life. In addition, the low power consumption characteristics of the hardware acceleration module also make this solution more suitable for scenarios with high energy efficiency requirements, such as automotive equipment.

[0113] In this embodiment of the application, the application of the hardware acceleration module can significantly shorten the hash value calculation time, reduce the interference of the verification process on the main loop, reduce the resource competition of the hash value calculation on the main loop, and improve the verification efficiency and the overall hardware resource energy efficiency ratio.

[0114] For example, existing methods can only determine the overall data is abnormal when verification fails, but cannot pinpoint the specific error location, which necessitates re-flushing all data, thus wasting communication resources and time. Therefore, the method in this application embodiment records the verification result (pass or fail) block by block during asynchronous verification, and stores the ID, address, and / or length of the erroneous block. When verification fails, only the incremental re-flush process of the erroneous block is triggered, instead of retransmitting the entire software, saving communication resources and time.

[0115] In one possible implementation, after recording the identification information of the data block that failed verification, the method further includes: generating an incremental re-flush request based on the identification information of the data block that failed verification; and requesting the retransmission of the data block that failed verification through the incremental re-flush request.

[0116] For example, an incremental re-flash request can be understood as a retransmission request instruction that only requests the retransmission of data blocks that failed verification, such as an instruction sent via OTA protocol to retransmit data for a data block that failed verification (such as Block ID 3).

[0117] After recording the identification information of the data block that failed verification (such as Block ID 3, address 0x1000), the electronic device can generate an incremental re-flash request, for example, by sending a command to the server (sender) to "re-flash the data of Block 3" through the communication interface. Upon receiving the incremental re-flash request, the server can respond to the request and transmit only the data of Block 3, rather than retransmitting the entire software data to be verified. Combining the advantages of the aforementioned block-based transmission and verification, this embodiment can implement a fine-grained failure retransmission mechanism based on the identification information of the data block that failed verification, avoiding invalid retransmission of the entire data.

[0118] Because the identification information of the data blocks that failed verification is recorded during the asynchronous verification process, a foundation is laid for a precise error location mechanism. Fine-grained, real-time error block location can only be achieved through block-by-block verification and error information recording. For example, if Block 3 verification fails, the ECU only needs to re-download the data for Block 3, rather than the entire software.

[0119] In this embodiment, incremental re-flush requests enable partial recovery of erroneous data blocks that failed verification. By retransmitting only the data blocks that failed verification, communication resource consumption and upgrade time can be significantly reduced. For example, the technical advantages of this solution are even more pronounced in low-bandwidth or high-latency network environments.

[0120] Incremental re-flash mechanism avoids invalid data transmission, reduces the write pressure on ECU storage units, and helps extend their service life. Furthermore, the structured storage of error information (such as the error data block ID + address) provides accurate data support for subsequent fault diagnosis and log analysis.

[0121] For example, existing verification schemes require pre-configured block information (such as address and length), which necessitates reconfiguration of verification parameters after ECU firmware updates, resulting in poor flexibility and high maintenance costs. Therefore, the method in this application embodiment encapsulates the number of blocks, address, length, and hash value within a self-describing format SIM (Software Integrity Manifest). The ECU dynamically obtains verification parameters by parsing the SIM, eliminating the need for pre-configured information and supporting compatibility verification across different software versions.

[0122] In one possible implementation, the description file is obtained by parsing the storage structure of the software to be verified, determining the address, length, and checksum of each of the multiple data blocks, and writing the address, length, and checksum of the multiple data blocks into the description file according to a self-describing format.

[0123] For example, a self-describing format can be understood as a file structure containing metadata of data blocks, enabling the file content to be parsed without external configuration, such as the header + entry structure of a SIM. Storage structure can be understood as the physical layout of software within a storage medium, such as the address mapping of a Flash memory.

[0124] The SIM's description file can use a self-describing format to store verification parameter information. For example, the header contains: the number of blocks (data blocks) N (e.g., a fixed number of bytes); entries: N block entries, each containing an address, length, and expected hash value; the ECU does not need to pre-configure block information; it can obtain all verification parameters by parsing the SIM. Taking a typical implementation as an example, the header can use 4 bytes to store the number of blocks, and each entry can use an address (4 bytes) + length (4 bytes) + hash value (32 bytes) structure, totaling 40 bytes.

[0125] Before generating the description file, the storage structure of the software to be verified can be parsed. For example, the starting address (e.g., 0x1000) and length (e.g., 4KB) of each data block can be determined by traversing the code segments of the Flash memory. Then, the parsed addresses, lengths, and checksums are written into the description file according to a self-describing format (e.g., the header stores the number of blocks, and entries store the address, length, and expected hash value sequentially). This process allows the description file to be independent of the ECU firmware configuration, enabling the ECU to dynamically parse verification parameters without pre-setting data block information.

[0126] For example, the SIM self-describing structure stores verification parameters centrally in the SIM file, allowing the ECU to dynamically parse the verification logic without pre-setting block information. For instance, when upgrading to a new software version, the ECU directly reads the block verification parameters from the latest SIM file without modifying the firmware configuration.

[0127] This approach enhances the flexibility and maintainability of the verification process while supporting compatibility verification during version iterations (e.g., distinguishing different versions using SIM version identifiers). Furthermore, the standardized design of the SIM structure reduces system integration complexity, making it particularly suitable for the frequent software version changes required in OTA upgrade scenarios.

[0128] In this embodiment, dynamic parsing of verification parameters can be achieved through a self-describing format description file. By standardizing the structure of the description file, the ECU can adapt to different software upgrades without relying on preset configurations.

[0129] For example, using a fixed-size block partition in all cases cannot adapt to different network environments or ECU load states, potentially limiting transmission efficiency and verification flexibility. Therefore, the method in this application dynamically adjusts the block size based on network bandwidth, ECU load state, and / or the software characteristics of the software to be verified (such as critical code regions). For instance, increasing the block size in low-bandwidth scenarios reduces the number of transmissions, while decreasing the block size in high-load scenarios increases the verification frequency.

[0130] In one possible implementation, the multiple data blocks are obtained by dividing the software into blocks in the following manner: obtaining the functional area information of the software to be verified, the network bandwidth of the communication channel for transmitting the software to be verified, and / or the load status of the receiver of the software to be verified; determining the size of the data blocks to be divided into multiple data blocks based on the functional area information, network bandwidth, and / or load status, and dividing the software to be verified into blocks according to the determined data block size.

[0131] For example, a functional area can be understood as a segment of code in the software to be verified that performs a specified task. For instance, a segment of code for safety control logic is a functional area, or a segment of code for power control logic is a functional area. Functional area information can be understood as information indicating each functional area, such as the label, location, and / or start and end marks of each functional area.

[0132] Network bandwidth can be understood as the data transmission rate of a communication channel. For example, the network bandwidth of an in-vehicle Ethernet communication channel is 100 megabits per second (Mbps), and the network bandwidth of a Controller Area Network Bus (CAN) communication channel is 1 Mbps.

[0133] The load status of the receiver can be understood as information that characterizes the data processing status of the receiver, such as network throughput, ECU task queue length, CPU utilization, etc.

[0134] The data block partitioning strategy can be dynamically adjusted based on real-time conditions. For example, when network bandwidth is low (such as with a CAN bus), the block size can be increased to reduce the number of transmissions. When the ECU load is high (such as when the main loop task queue is too long), the block size can be decreased to increase the verification frequency. If blocks are partitioned according to the functional areas of the software to be verified, critical functional areas (such as safety control logic) can be set to smaller blocks to prioritize the verification of these higher-priority functional areas.

[0135] Dynamic block segmentation strategies can dynamically configure block size parameters by monitoring the receiver's load status in real time and invoking preset block segmentation rule bases such as sliding window algorithms. Taking in-vehicle software upgrades as an example, when the in-vehicle network is congested, increasing the block size reduces the number of transmissions and improves throughput. When the ECU is under high load, decreasing the block size prioritizes the verification of critical code areas, reducing the probability of ECU anomalies. This significantly improves the adaptability and efficiency of the verification process; simultaneously, differentiated block segmentation strategies (such as setting smaller blocks for safety control code areas) enhance verification security.

[0136] In this embodiment, a dynamic block partitioning strategy enables the verification process to be adaptive. For example, reducing the number of transmissions in low-bandwidth scenarios can improve throughput, while finer-grained block partitioning in high-load scenarios allows for earlier error detection. Based on this, the number of transmissions and the verification frequency can be dynamically balanced, improving the efficiency and resource utilization of data transmission and verification.

[0137] For example, to further enhance the reliability of verification and software flashing, a two-layer protection mechanism can be used for verification. The first layer, block-level hash verification, verifies data integrity, while the second layer, SIM signature-level hash verification, verifies the trustworthiness of the SIM's origin. If either layer fails, the flashing process can be immediately terminated and rejected, thus ensuring the security and reliability of the software update.

[0138] In one possible implementation, the method further includes: performing signature verification on the description file after all multiple data blocks have been verified and have passed verification, and returning the result of the signature verification to the sending end of the software to be verified.

[0139] For example, signature verification can also be understood as digital signature verification, which is a cryptographically based security verification operation that verifies the integrity and authenticity of a piece of data (or software, file), ensuring that the data has not been tampered with during transmission or storage and that it indeed comes from the claimed sender. When performing signature verification, for example, it can be implemented using the signature algorithm of the Rivest-Shamir-Adleman-2048 Probabilistic Signature Scheme (RSA-2048-PSS).

[0140] Signature verification results can include success and failure. A successful verification result indicates that the source of the description file is reliable; a failure result indicates that the source of the description file is unreliable. If the signature verification is successful, a message indicating successful signature verification can be returned to the sender of the software being verified; if the signature verification fails, a message indicating a signature mismatch can be returned to the sender of the software being verified. By returning the signature verification result to the sender of the software being verified, the sender can know whether the flashing was successful. If the flashing was unsuccessful, the sender can take appropriate follow-up actions.

[0141] In this embodiment, after multiple data blocks have been verified and all have passed verification, signature verification is performed on the description file. This verifies the reliability of the description file and improves the credibility of the data source. Based on this, the solution in this embodiment implements a two-layer protection mechanism for security verification, thereby enhancing the security of the software being verified.

[0142] For example, based on the method of any of the embodiments of this application above, in order to optimize resource allocation during verification, the granularity of a single execution of the asynchronous verification task can be dynamically adjusted based on the ECU load, that is, the number of data bytes processed by the hash calculation in each main loop scheduling can be dynamically adjusted. When the ECU is under high load, the amount of data processed in a single execution is reduced, so that the hash calculation is completed in more scheduling sessions, thereby shortening the time occupied by each scheduling session in the main loop and reducing the waiting latency of other tasks (such as diagnostic tasks) in the main loop; when the ECU is under low load, the amount of data processed in a single execution is increased, the number of scheduling sessions is reduced, and the verification is completed faster. The above granularity adjustment can be achieved by adding load awareness judgment to the scheduling entry of the existing asynchronous state machine, without introducing an additional scheduling mechanism.

[0143] Based on this, the verification task runs asynchronously in the main loop, and the high-priority task driven by interrupt is not affected. The benefits of dynamic granularity adjustment are: reducing CPU load rate and waiting latency of other tasks in the main loop under high load, accelerating the verification process and shortening the total upgrade time under low load, while maintaining the real-time verification characteristics, and adapting to ECUs with different computing power levels.

[0144] For example, based on the method of any of the embodiments of this application above, in order to further improve upgrade efficiency, the SIM can be designed as a multi-level structure, including a base SIM and an incremental SIM, suitable for incremental download scenarios (this upgrade only downloads and writes the newly added or modified blocks, while the base version blocks are already stored in Flash). The base SIM stores the verification parameters of all blocks in the base version and includes integrity protection information for the incremental SIM; the incremental SIM only records the verification parameters of the newly added or modified blocks.

[0145] During the upgrade, the ECU first verifies the digital signature of the base-level SIM, then verifies the incremental-level SIM through the integrity protection information in the base-level SIM, and then performs an instantaneous asynchronous hash verification on the newly written block.

[0146] Based on this, the incremental SIM only contains the verification parameters of the difference block, which can significantly reduce the amount of data transmitted in the upgrade package and is suitable for small-scale upgrade scenarios such as OTA patch updates; the multi-level structure can also be extended to support complex scenarios such as cross-version upgrades, enhancing the scalability and applicability of the solution.

[0147] Below, in conjunction with Figures 2 to 6 The software verification method provided in the embodiments of this application will be further described. Figure 2 This is a schematic diagram of the SIM structure and dual-layer protection mechanism provided in the embodiments of this application. Block-level hash protection can be achieved in the first layer, and SIM-level signature protection can be achieved in the second layer.

[0148] like Figure 2 As shown, the SIM data structure is as follows: Header: Block Count field, indicating N Blocks; Block entries can be 0~N-1: each entry contains address + length + expected hash value. Self-describing feature: The SIM contains all the information needed for verification; the ECU can parse the SIM to obtain the Block Count, Address, Length, and Expected Hash Value.

[0149] The first layer is block-level hash protection. Specifically, this involves the actual software data from Block 0 to N-1. The arrows indicate that a secure hash algorithm is used to calculate the hash value for each block, and this hash value is compared with the expected hash value stored in the SIM. The purpose of this comparison is primarily to verify data integrity and accurately locate erroneous blocks.

[0150] The second layer is SIM signature protection. Specifically, the digital signature protects the entire SIM. The arrow indicates that all content of the SIM is protected by the signature. Its main function is to verify the trustworthiness of the SIM's origin and prevent SIM tampering.

[0151] Based on the two-layer protection mechanism formed by the first and second layers described above, a protection chain can be formed: "digital signature → protected SIM → hash value in SIM protects all blocks". The verification strategy can be to terminate immediately and refuse to flash the application if verification fails at any layer.

[0152] Figure 3 This is one of the three-stage timing flowcharts for integrity verification provided in the embodiments of this application. Figure 4 This is the second of the three-stage timing flowcharts for integrity verification provided in the embodiments of this application. Figure 5 This is the third of a three-stage timing flowchart for integrity verification provided in an embodiment of this application. Figures 3 to 5 As shown, stage 1 is the SIM download stage; stage 2 is the asynchronous verification stage of downloading and verifying each block one by one; stage 3 is the SIM signature trustworthiness verification stage, which is also known as signature verification.

[0153] The diagnostic tool acts as the transmitter, and the ECU as the receiver. The ECU includes an ECU diagnostic layer and an ECU flashing layer. The receiver also includes storage that works in conjunction with the ECU, such as Flash memory. In Phase 1, the SIM is downloaded from the diagnostic tool to a fixed location in the receiver's Flash memory via a request to download, data transfer, and service termination. The SIM contains the addresses, lengths, and expected hash values ​​of all blocks. In Phase 2, blocks are downloaded and verified one by one. The download and verification process for each block includes steps 2.1 to 2.8 as shown in Table 1 below.

[0154] Table 1

[0155]

[0156] In Phase 2, during asynchronous execution, after the transmission exits the service and returns a waiting response, the actual verification is performed in the main loop without blocking other tasks. During immediate verification, each block is verified immediately after transmission, without waiting for all blocks to complete. During precise location, the block ID and address are returned upon verification failure, quickly locating the problematic block. During incremental re-flush, only the faulty block needs to be re-downloaded, without re-flushing all data.

[0157] In Phase 3, SIM signature trustworthiness verification is performed through steps 3.1 to 3.5 as shown in Table 2 below.

[0158] Table 2

[0159]

[0160] Through the three stages described above, a two-layer protection mechanism is achieved. Block hashing ensures integrity, and SIM signature ensures trustworthiness; failure at either layer results in rejection of the write operation. Ultimately, transmission only requires SIM verification, reducing verification time.

[0161] Figure 6 A comprehensive comparison diagram of existing solutions and solutions provided in this application for the embodiments of this application is shown, as follows: Figure 6 As shown, the existing solution's process is as follows: large-capacity software overall processing; overall hash calculation (blocking the main loop); overall hash value; digital signature verification; result determination. The existing solution suffers from problems such as main loop blocking, inability to locate errors, and the need to re-flush everything upon failure.

[0162] The solution of this application embodiment mainly includes the following processes: dividing the software to be verified into Blocks (Block 0~N); downloading and verifying each Block one by one in real time; asynchronous execution; storing the hash value in the SIM structure; SIM signature verification; and result determination (precise location). Compared with existing solutions, the solution of this application embodiment has many advantages, such as real-time error detection, non-blocking, precise location, and only re-flashing the erroneous Block. A detailed comparison is shown in Table 3 below.

[0163] Table 3

[0164]

[0165] As can be seen from the comparison of the above solutions, the software verification method for MCU software flashing integrity based on SIM provided in this application effectively solves many of the shortcomings of the overall hash + signature verification scheme in the existing solutions.

[0166] The method in this application achieves several technological breakthroughs through an instant verification mechanism and an asynchronous processing architecture. First, it enables instant error detection: each block is verified immediately after transmission, without waiting for all transmissions to complete, thus promptly detecting errors and avoiding invalid transmissions. Second, it avoids main loop blocking: an asynchronous batch verification mechanism is used, processing only the hash calculation of one block at a time, resulting in short execution time and not affecting the real-time requirements of the ECU. Third, it enables precise error location: when verification fails, the ID and address of the erroneous block can be immediately determined, providing accurate information for fault diagnosis. Fourth, it enables incremental re-flash recovery: based on precise location capabilities, only the erroneous block needs to be re-flashed, significantly reducing recovery time after a flash failure.

[0167] The solution in this application embodiment ensures security through a dual-layer protection mechanism. The first layer verifies data integrity using block-level hash verification, and the second layer verifies the trustworthiness of the SIM source using digital signature verification. Failure at either layer will result in rejection of the flashing process, providing security guarantees no less than those of existing solutions. The method provided in this application embodiment is applicable to automotive ECU software upgrade scenarios, especially OTA remote upgrades of large-capacity software, which can significantly improve flashing efficiency and reliability, and reduce after-sales costs caused by flashing failures.

[0168] This application also provides a software transmission method, which is applied at a sending end. The method includes: dividing the software to be verified into multiple data blocks and generating a description file containing verification parameters of the multiple data blocks; sending the description file to a receiving end and sending the multiple data blocks; wherein the receiving end is used to download the description file, and is also used to receive the multiple data blocks and, after the transmission of any data block is completed, to perform an asynchronous verification task on any data block according to the verification parameters in the description file; the receiving end is also used to verify the multiple data blocks one by one in the asynchronous verification task and record the identification information of the data blocks that fail to be verified.

[0169] In one possible implementation, an asynchronous verification task is performed on any data block according to the verification parameters in the description file, including: extracting the data to be verified from the transmitted data block according to the address and length of the data block in the description file; calculating the hash value of the data to be verified using a secure hash algorithm; and comparing the calculated hash value with the expected hash value stored in the description file.

[0170] In one possible implementation, calculating the hash value of the data to be verified using a secure hash algorithm includes: calling a hardware acceleration module, directly reading the data to be verified through the hardware acceleration module to perform secure hash algorithm calculation, and outputting the hash value of the data to be verified; wherein, the hardware acceleration module is an independent functional module used for hash value calculation.

[0171] In one possible implementation, after recording the identification information of the data block that failed verification, the method further includes: generating an incremental re-flush request based on the identification information of the data block that failed verification; and requesting the retransmission of the data block that failed verification through the incremental re-flush request.

[0172] In one possible implementation, generating a description file containing verification parameters of multiple data blocks includes: parsing the storage structure of the software to be verified, determining the address, length, and verification value of each of the multiple data blocks, and writing the address, length, and verification value of the multiple data blocks into the description file according to a self-describing format.

[0173] In one possible implementation, the software to be verified is divided into multiple data blocks, including: obtaining functional area information of the software to be verified, network bandwidth of the communication channel for transmitting the software to be verified, and / or receiving the load status of the receiver of the software to be verified; determining the size of the data blocks to be divided into multiple data blocks based on the functional area information, network bandwidth and / or load status, and dividing the software to be verified into blocks according to the determined data block size.

[0174] In one possible implementation, if all data blocks have been verified and all have passed verification, the receiving end is also used to perform signature verification on the description file and return the signature verification result to the sending end of the software to be verified.

[0175] The software sending method provided in this application embodiment is similar in principle and technical effect to the software verification method provided in any of the above embodiments of this application. For details, please refer to the description in the above embodiments. This embodiment will not be repeated here.

[0176] This application also provides a software transceiver system, which includes a sending end and a receiving end. The sending end is used to divide the software to be verified into multiple data blocks and generate a description file containing verification parameters for the multiple data blocks. The sending end is also used to send the description file to the receiving end and send the multiple data blocks. The receiving end is used to download the description file, receive the multiple data blocks, and, after the transmission of any data block is completed, perform an asynchronous verification task on any data block according to the verification parameters in the description file. The receiving end is also used to verify the multiple data blocks one by one in the asynchronous verification task and record the identification information of the data blocks that fail to be verified.

[0177] In one possible implementation, the receiving end is configured to: extract the data to be verified from the transmitted data block according to the address and length of the data block in the description file; calculate the hash value of the data to be verified using a secure hash algorithm; and compare the calculated hash value with the expected hash value stored in the description file.

[0178] In one possible implementation, the receiving end is specifically used to: invoke the hardware acceleration module, and directly read the data to be verified through the hardware acceleration module to perform a secure hash algorithm calculation, and output the hash value of the data to be verified; wherein, the hardware acceleration module is an independent functional module used for hash value calculation.

[0179] In one possible implementation, the receiving end is further configured to: generate an incremental re-flush request based on the identification information of the data block that failed the verification; and request the retransmission of the data block that failed the verification through the incremental re-flush request.

[0180] In one possible implementation, the sending end is specifically used to: parse the storage structure of the software to be verified, determine the address, length and check value of each of the multiple data blocks; and write the address, length and check value of the multiple data blocks into a description file according to a self-describing format.

[0181] In one possible implementation, the sending end is specifically configured to: acquire functional area information of the software to be verified, network bandwidth of the communication channel through which the software to be verified is transmitted, and / or receive the load status of the receiver of the software to be verified; determine the data block size for dividing multiple data blocks based on the functional area information, network bandwidth, and / or load status, and divide the software to be verified into blocks according to the determined data block size.

[0182] In one possible implementation, if all data blocks have been verified and all have passed verification, the receiving end is also used to perform signature verification on the description file and return the signature verification result to the sending end of the software to be verified.

[0183] The software transceiver system provided in this application embodiment is similar in implementation principle and technical effect to the software verification method provided in any of the above embodiments of this application. For details, please refer to the description in the above embodiments. This embodiment will not be repeated here.

[0184] Figure 7 This is a schematic diagram of the structure of the software verification device provided in the embodiments of this application, as shown below. Figure 7 As shown in the figure, this application provides a software verification device, which includes: a download module 701, used to download a description file containing verification parameters of multiple data blocks, wherein the multiple data blocks are obtained by dividing the software to be verified into blocks; a verification module 702, used to receive the multiple data blocks and, after the transmission of any data block is completed, to perform an asynchronous verification task on any data block according to the verification parameters in the description file; and a recording module 703, used to verify the multiple data blocks one by one in the asynchronous verification task and record the identification information of the data blocks that fail to be verified.

[0185] In one possible implementation, the verification module 702 is specifically used to: extract the data to be verified from the transmitted data block according to the address and length of the data block in the description file; calculate the hash value of the data to be verified using a secure hash algorithm; and compare the calculated hash value with the expected hash value stored in the description file.

[0186] In one possible implementation, the verification module 702 is specifically used to: call the hardware acceleration module, and directly read the data to be verified through the hardware acceleration module to perform a secure hash algorithm calculation, and output the hash value of the data to be verified; wherein, the hardware acceleration module is an independent functional module used for hash value calculation.

[0187] In one possible implementation, the apparatus includes a retransmission module, which is configured to: generate an incremental re-flush request based on the identification information of the data block that failed the verification; and request the retransmission of the data block that failed the verification through the incremental re-flush request.

[0188] In one possible implementation, the description file is obtained by parsing the storage structure of the software to be verified, determining the address, length, and checksum of each of the multiple data blocks, and writing the address, length, and checksum of the multiple data blocks into the description file according to a self-describing format.

[0189] In one possible implementation, the multiple data blocks are obtained by dividing the software into blocks in the following manner: obtaining the functional area information of the software to be verified, the network bandwidth of the communication channel for transmitting the software to be verified, and / or the load status of the receiver of the software to be verified; determining the size of the data blocks to be divided into multiple data blocks based on the functional area information, network bandwidth, and / or load status, and dividing the software to be verified into blocks according to the determined data block size.

[0190] In one possible implementation, the apparatus further includes a verification module, which is configured to: perform signature verification on the description file after multiple data blocks have been verified and all have passed the verification, and return the result of the signature verification to the sending end of the software to be verified.

[0191] The software verification device provided in this application can be used to execute the technical solution of the software verification method in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again here.

[0192] This application also provides a software verification method based on block verification. The method includes: downloading a description file containing verification parameters of multiple data blocks and storing the description file in a storage module, wherein the multiple data blocks are obtained by dividing the software to be verified into blocks; after the communication module receives the multiple data blocks and after the transmission of any data block is completed, the processing module performs an asynchronous verification task on any data block according to the verification parameters in the description file; in the asynchronous verification task, the processing module verifies the multiple data blocks one by one and records the identification information of the data blocks that fail to be verified.

[0193] For example, a storage module can be understood as a hardware unit used to store description files, such as the Flash memory of an ECU. A communication module can be understood as a hardware unit responsible for data block transmission, such as a CAN bus interface or an OTA communication chip. A processing module can be understood as a hardware unit that performs verification tasks, such as the CPU or coprocessor of an MCU.

[0194] This method uses a storage module to store a description file (such as a SIM) to ensure the persistent storage of verification parameters. After receiving a data block, the communication module sends a signal to the processing module to trigger an asynchronous verification task. The processing module verifies the data block by block according to the address, length, and hash value in the description file, and records identification information (such as a Block ID) when an error is detected. The entire process achieves asynchronous execution of the verification task through the coordinated work of the hardware modules.

[0195] The software verification method based on block verification provided in this application is similar in principle and technical effect to the software verification method provided in any of the above embodiments of this application. For details, please refer to the description in the above embodiments. This embodiment will not be repeated here.

[0196] This application embodiment also provides an electronic control unit, which includes: a storage module for storing a description file containing verification parameters for multiple data blocks; a communication module for receiving the description file and data blocks and triggering an asynchronous verification task; and a processing module connected to the storage module and the communication module for verifying each data block according to the verification parameters in the description file and recording the identification information of the data blocks that fail verification.

[0197] For example, an electronic control unit (ECU) can be understood as the core control device of an automotive electronic system, such as a powertrain control unit or a body control module. A storage module can be understood as non-volatile memory within the ECU, such as Flash memory or electrically erasable programmable read-only memory (EEPROM). A communication module can be understood as the ECU's communication interface, such as a CAN controller or an Ethernet communication module.

[0198] The ECU stores a description file (such as a SIM) through a storage module to ensure the persistent storage of verification parameters. After receiving a data block, the communication module sends a signal to the processing module to trigger an asynchronous verification task. The processing module verifies the data block by block according to the verification parameters (such as address, length, and expected hash value) in the description file, and records identification information (such as Block ID) when an error is detected. This hardware architecture achieves efficient execution of the verification process through modular design.

[0199] The electronic control unit provided in this application embodiment is similar in implementation principle and technical effect to the software verification method provided in any of the above embodiments of this application. For details, please refer to the description in the above embodiments. This embodiment will not be repeated here.

[0200] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 8 As shown, the electronic device of this embodiment may include: at least one processor 801; and a memory 802 communicatively connected to the at least one processor; wherein the memory 802 stores instructions that can be executed by the at least one processor 801, and the instructions are executed by the at least one processor 801 to cause the electronic device to perform the method as described in any of the above embodiments.

[0201] Optionally, the memory 802 can be either standalone or integrated with the processor 801.

[0202] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0203] This application also provides a software verification system. Figure 9 This is a schematic diagram of the architecture of a software verification system provided in an embodiment of this application. Figure 9 As shown, the software verification system includes a cloud server, an in-vehicle MCU, and a storage unit.

[0204] For example, the on-board MCU can be any microcontroller unit in the vehicle, such as the MCU of an electronic control unit. The storage unit can be a storage unit based on any form of storage medium, such as Flash memory. The storage unit is connected to the on-board MCU and is used to store the data and instructions required by the MCU. For example, when the on-board MCU is being flashed with software, the storage unit can be used to store the description file and multiple data blocks of the software to be verified downloaded to the on-board MCU.

[0205] A cloud server can be understood as a server that provides remote data services to the vehicle's MCU. For example, it can be a server cluster consisting of multiple servers. The cloud server can store the software to be flashed to the vehicle's MCU, and after receiving a flashing request from the vehicle's MCU, it can send the software to be flashed along with a description file used for flashing verification to the vehicle's MCU.

[0206] like Figure 9 As shown, the vehicle-mounted MCU can establish a connection with the cloud server via wireless data communication. When the vehicle-mounted MCU needs software flashing, it can send a flashing request to the cloud server through the established connection. After receiving and verifying the flashing request, the cloud server can send a description file of the software to be flashed to the vehicle-mounted MCU. This description file includes verification parameters for multiple data blocks, which are obtained by dividing the software to be verified (i.e., the software to be flashed) into blocks. Verification parameters include, for example, the address, length, and expected hash value of each data block.

[0207] After receiving the description file, the onboard MCU can store it in the storage unit for later use in the asynchronous data block verification task. After receiving the description file, the onboard MCU can continue to download multiple data blocks after the software to be flashed has been divided into blocks from the cloud server via a connection, and can store these data blocks in the storage unit.

[0208] Upon receiving each data block, the onboard MCU can access the description file in the storage unit to read the verification parameters within the description file and perform integrity verification on the received data block. During verification, the hash value calculated based on the data block is compared with the expected hash value of that data block in the description file. If they match, the data block verification is successful; if they do not match, the data block verification fails. In cases of verification failure, the identifier information of the failed data block can be recorded so that it can be re-downloaded and re-verified at a later time until verification is successful.

[0209] After the onboard MCU downloads and verifies all data blocks, it can also perform signature trustworthiness verification on the description file to verify the trustworthiness of the description file's source. Signature trustworthiness verification can be a cryptographically based secure verification operation that verifies the integrity and authenticity of the description file, ensuring that the data has not been tampered with during transmission or storage and indeed originates from the claimed sender. A successful signature verification result indicates that the description file's source is reliable; a failed signature verification result indicates that the description file's source is unreliable.

[0210] When signature verification is successful, the vehicle MCU can return a signature verification pass message to the cloud server. When signature verification fails, the vehicle MCU can return a signature mismatch message to the cloud server. By returning the signature verification result to the cloud server, the cloud server can know whether the software flashing was successful, so that subsequent flashing processes can be completed or flashing problem reporting processes can be performed.

[0211] Based on the software verification system provided in this application embodiment, the vehicle MCU can be flashed in blocks through a cloud server, and the efficiency and reliability of software flashing and verification are improved through asynchronous verification and data block verification based on description files.

[0212] The software verification system provided in this application embodiment is similar in principle and technical effect to the software verification method provided in any of the above embodiments of this application. For details, please refer to the description in the above embodiments. This embodiment will not be repeated here.

[0213] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.

[0214] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments.

[0215] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0216] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0217] It should be understood that the aforementioned processor can be a central processing unit (CPU) or other general-purpose processors. The processor can also be a digital signal processor (DSP) or an application-specific integrated circuit (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0218] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be various media that can store program code, such as USB flash drives, portable hard drives, read-only memory (ROM), disks or optical discs.

[0219] The aforementioned storage medium can be implemented using any type of volatile or non-volatile storage device or a combination thereof. Examples of storage media include Static Random-Access Memory (SRAM) or Electrically Erasable Programmable Read-Only Memory (EEPROM).

[0220] Storage media can be, for example, erasable programmable read-only memory (EPROM) or programmable read-only memory (PROM). Storage media can also be read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0221] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside within an application-specific integrated circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components within an electronic device or host device.

[0222] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0223] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0224] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0225] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0226] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0227] It should be further noted that although the steps in the flowchart are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order requirement for the execution of these steps, and they can be executed in other orders.

[0228] Furthermore, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0229] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0230] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0231] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A software verification method, characterized in that, The method includes: Download a description file containing verification parameters of multiple data blocks, wherein the multiple data blocks are obtained by dividing the software to be verified into blocks; After receiving the plurality of data blocks and completing the transmission of any data block, perform an asynchronous verification task on any data block according to the verification parameters in the description file; In the asynchronous verification task, the multiple data blocks are verified one by one, and the identification information of the data blocks that fail to be verified is recorded.

2. The method according to claim 1, characterized in that, The step of performing an asynchronous verification task on any data block according to the verification parameters in the description file includes: Based on the address and length of the data block in the description file, extract the data to be verified from the data block that has been transmitted. The hash value of the data to be verified is calculated using a secure hash algorithm; The calculated hash value is compared with the expected hash value stored in the description file.

3. The method according to claim 2, characterized in that, The step of calculating the hash value of the data to be verified using a secure hash algorithm includes: The hardware acceleration module is invoked, and the data to be verified is directly read through the hardware acceleration module to perform a secure hash algorithm calculation, and the hash value of the data to be verified is output; wherein, the hardware acceleration module is an independent functional module for performing hash value calculation.

4. The method according to any one of claims 1-3, characterized in that, After recording the identifier information of the data block that failed verification, the method further includes: Based on the identification information of the data blocks that failed verification, an incremental re-flush request is generated; The incremental re-flash request requests the retransmission of the data block that failed the verification.

5. The method according to any one of claims 1-3, characterized in that, The description file was obtained in the following way: The storage structure of the software to be verified is analyzed to determine the address, length, and checksum of each of the multiple data blocks; The addresses, lengths, and checksums of the multiple data blocks are written into the description file in a self-describing format.

6. The method according to any one of claims 1-3, characterized in that, The multiple data blocks are obtained by dividing the data into blocks in the following manner: Obtain the functional area information of the software to be verified, the network bandwidth of the communication channel transmitting the software to be verified, and / or receive the load status of the receiver of the software to be verified; Based on the functional area information, the network bandwidth, and / or the load status, the data block size for dividing the multiple data blocks is determined, and the software to be verified is divided into blocks according to the determined data block size.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: If all data blocks have been verified and passed, a signature verification is performed on the description file, and the result of the signature verification is returned to the sending end of the software to be verified.

8. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images