Vehicle flashing method and device, vehicle and storage medium

Abstract

The embodiment of the invention discloses a vehicle flashing method and device, a vehicle and a storage medium, and relates to the technical field of vehicle control, and the method comprises the steps: responding to a preset flashing condition meeting a to-be-upgraded electronic control unit ECU, downloading an upgrade package of the to-be-upgraded ECU from a server, and analyzing the upgrade package to obtain signature data and a to-be-flashed file; writing the to-be-flashed file into a temporary cache region, performing signature verification on the signature data and the to-be-flashed file based on a preset security key and a public key ciphertext pre-stored in a parameter region to obtain a signature verification result, and writing the to-be-flashed file in the temporary cache region into a flash memory region when the signature verification result is that verification is passed; according to the method, the to-be-flashed file in the flash memory area is distributed to the to-be-upgraded ECU, so that the to-be-upgraded ECU determines the to-be-flashed partition from the at least two flash memory partitions, the received to-be-flashed file is written into the to-be-flashed partition, the to-be-flashed file runs on the basis of the to-be-flashed file in the to-be-flashed partition when the vehicle is started next time, and the vehicle flashing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a vehicle flashing method, device, vehicle, and storage medium. Background Technology

[0002] Even after a vehicle is put into actual use, various issues may still arise, and the market will continue to generate new changes and demands. To achieve purposes such as upgrading vehicle functions and fixing program vulnerabilities, rewriting and upgrading the various electronic control units (ECUs) of the vehicle is a relatively convenient and efficient method.

[0003] Currently, due to safety considerations, vehicle ECU remapping and upgrade operations are only permitted to be performed by the manufacturer. That is, the manufacturer's personnel use professional equipment to complete the ECU remapping and upgrade operations on-site. However, when vehicles are distributed in a relatively dispersed manner, or when it is necessary to upgrade the ECU of a vehicle that has already been sold, on-site remapping is often difficult to perform and has low feasibility, which in turn makes vehicle remapping inefficient. Summary of the Invention

[0004] This application provides a vehicle flashing method, apparatus, vehicle, and storage medium, which realizes the function of flashing and upgrading the ECU of a vehicle, thereby solving the problem of low efficiency in vehicle flashing in the prior art.

[0005] In a first aspect, embodiments of this application provide a vehicle flashing method, applied to a vehicle's remote information processor. The remote information processor's storage area includes a temporary cache area, a flash memory area, and a parameter area. The method includes:

[0006] In response to meeting the preset flashing conditions of the ECU to be upgraded, the upgrade package of the ECU to be upgraded is downloaded from the server, and the upgrade package is parsed to obtain signature data and the file to be flashed; the signature data is obtained by the manufacturer's device encrypting the file to be flashed based on the private key;

[0007] Write the file to be written to the temporary buffer area. Verify the signature data and the file to be written based on the preset security key and the public key ciphertext pre-stored in the parameter area to obtain the verification result. When the verification result is successful, write the file to be written to the flash memory area from the temporary buffer area.

[0008] The file to be flashed in the flash memory is distributed to the ECU to be upgraded, so that the ECU to be upgraded can determine the partition to be flashed from at least two flash memory partitions, write the received file to be flashed to the partition to be flashed, and run based on the file to be flashed in the partition to be flashed on the next boot.

[0009] In this embodiment, in response to meeting the preset flashing conditions of the Electronic Control Unit (ECU) to be upgraded, an upgrade package for the ECU to be upgraded is downloaded from the server. The upgrade package is parsed to obtain signature data and a file to be flashed. The signature data is obtained by the manufacturer's device encrypting the file to be flashed using a private key. Then, the file to be flashed is written to a temporary buffer. The signature data and the file to be flashed are verified based on a preset security key and a public key ciphertext pre-stored in the parameter area to obtain a verification result. If the verification result is successful, the file to be flashed in the temporary buffer is written to the flash memory area. The parameter area stores the public key ciphertext, not the plaintext of the public key, which prevents public key leakage and ensures the security and validity of the public key. Furthermore, the public key ciphertext pre-stored in the parameter area can be used to verify the upgrade package, thereby ensuring the integrity and accuracy of the file to be flashed in the flash memory area, thus improving the flashing accuracy of the ECU to be upgraded. Afterwards, the file to be flashed in the flash memory area is... The file is distributed to the ECU to be upgraded, allowing the ECU to determine the partition to be flashed from at least two flash memory partitions. The received flash file is then written to this partition, and the ECU runs on the next boot based on the flash file in the partition. This enables automatic flashing and upgrading of the vehicle ECU, eliminating the need for on-site manual flashing by manufacturer personnel, saving manufacturers time and manpower costs, and improving the feasibility and efficiency of vehicle flashing. Furthermore, by setting the ECU's flash memory to include at least two partitions and restricting the ECU to write the flash file to the partition to be flashed, rather than writing it to the running partition, seamless flashing and upgrading of the vehicle ECU is achieved. Even in the event of a flashing failure, the ECU continues to run based on the application in the running partition on the next boot, enabling a rollback function in case of flashing failure. This ensures the safe and stable operation of the ECU, thereby guaranteeing vehicle safety and reliability and improving the user experience.

[0010] Secondly, embodiments of this application provide a vehicle flashing device applied to a vehicle's remote information processor. The remote information processor's storage area includes a temporary cache area, a flash memory area, and a parameter area. The device includes:

[0011] The download module is used to download the upgrade package of the ECU to be upgraded from the server in response to the preset flashing conditions of the ECU to be upgraded, and to parse the upgrade package to obtain the signature data and the file to be flashed; the signature data is obtained by the manufacturer's device encrypting the file to be flashed based on the private key;

[0012] The signature verification module is used to write the file to be written to the temporary buffer area, verify the signature data and the file to be written based on the preset security key and the public key ciphertext pre-stored in the parameter area, obtain the signature verification result, and write the file to be written in the temporary buffer area to the flash memory area when the signature verification result is successful.

[0013] The distribution module is used to distribute the file to be flashed in the flash memory area to the ECU to be upgraded, so that the ECU to be upgraded can determine the partition to be flashed from at least two flash memory partitions, write the received file to be flashed to the partition to be flashed, and run based on the file to be flashed in the partition to be flashed on the next boot.

[0014] Thirdly, embodiments of this application provide a vehicle, the vehicle including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the vehicle flashing method of any embodiment of this application.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vehicle flashing method as described in any embodiment of this application.

[0016] The descriptions of the second, third, and fourth aspects in this application can be referenced to the detailed description of the first aspect; and the beneficial effects described in the second, third, and fourth aspects can be referenced to the analysis of the beneficial effects in the first aspect, which will not be repeated here.

[0017] In this application, the name of the aforementioned vehicle flashing device does not limit the device or functional module itself. In actual implementation, these devices or functional modules may appear under other names. As long as the function of each device or functional module is similar to that of this application, it falls within the scope of the claims of this application and its equivalents.

[0018] These or other aspects of this application will become more readily apparent in the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic flowchart of a vehicle flashing method provided in an embodiment of this application;

[0021] Figure 2 This is another schematic diagram of the vehicle flashing method provided in the embodiments of this application;

[0022] Figure 3 This is a schematic diagram of the vehicle writing device provided in an embodiment of this application;

[0023] Figure 4 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

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

[0026] Figure 1 This is a schematic flowchart of a vehicle flashing method provided in this application embodiment. This embodiment can be applied to scenarios where various ECUs in a vehicle need to be flashed and upgraded. The vehicle flashing method provided in this embodiment can be executed by the vehicle flashing device provided in this application embodiment, which can be implemented through software and / or hardware. In a specific embodiment, the vehicle flashing device can be integrated into the vehicle's telematics processor. The executing entity for this method can be the vehicle's telematics processor.

[0027] In one specific embodiment, the vehicle may include a telematics BOX and multiple ECUs; wherein the telematics BOX (T-BOX) is used for data transmission, remote control and status monitoring, etc., to realize remote information interaction between the vehicle and the cloud, between the vehicle and the user terminal, and communication with various ECUs inside the vehicle.

[0028] The remote information processor's storage area includes a temporary cache area, a flash memory area, and a parameter area. The temporary cache area stores temporary data, which is immediately lost after power failure and is used for real-time data transfer and temporary processing during operation. The flash memory area is a non-volatile storage area based on Flash memory, where data is retained long-term after power failure and is used for long-term storage of large amounts of data such as executable program code and related operating data. The parameter area is a non-volatile storage area for critical parameters, where data is retained long-term after power failure and is used to store small amounts of critical parameters. For example, the parameter area can be an electrically erasable programmable read-only memory (EEPROM).

[0029] See Figure 1 The vehicle flashing method in this embodiment includes, but is not limited to, the following steps:

[0030] S110. In response to meeting the preset flashing conditions of the electronic control unit (ECU) to be upgraded, download the upgrade package of the ECU to be upgraded from the server, and parse the upgrade package to obtain signature data and the file to be flashed.

[0031] The ECU to be upgraded refers to the ECU inside the vehicle that needs to be flashed and upgraded. The preset flashing conditions are pre-set flashing conditions used to ensure the safety and reliability of the flashing and upgrade process, avoiding flashing and upgrade failures or equipment damage due to abnormal environmental or vehicle conditions. The server is the storage, management, and distribution center for the upgrade package, responsible for data interaction with the vehicle's T-BOX, and initiating and monitoring the flashing and upgrade process. For example, the server is an Over-the-Air Technology (OTA) server.

[0032] The upgrade package is a collection of compressed files used to update the ECU software. It contains the signature data of the ECU to be upgraded and the files to be flashed. The signature data is used to verify the legitimacy and integrity of the files to be flashed, and is obtained by the manufacturer's device encrypting the files based on its private key. The files to be flashed are the files that need to be transmitted to the ECU to be upgraded, including the version number and the new version file; the new version file includes program code, configuration parameters, and other content.

[0033] Specifically, when a manufacturer determines that a certain type of ECU in a vehicle needs to be upgraded, the manufacturer's equipment determines the version number of the new version file for that type of ECU, and appends the version number to the beginning of the new version file for that type of ECU to obtain the file to be flashed. Then, the ED25519 (Edwards-curve Digital Signature Algorithm 25519) algorithm is used to encrypt the file to be flashed based on the private key to obtain signature data. At this time, the signature data obtained is of fixed length, and the signature data is appended to the beginning of the file to be flashed to obtain the upgrade package. Then, the upgrade package for that type of ECU is uploaded to the server.

[0034] Furthermore, the vehicle's T-BOX can periodically send software version query requests to the server at preset time intervals. These requests include the identifiers and current version numbers of each ECU within the vehicle. The server receives and parses these requests to obtain the identifiers and current version numbers of each ECU. Then, for each ECU, if its current version number is less than the version number of the corresponding ECU upgrade package uploaded by the manufacturer, it indicates that the current ECU is not the latest version and requires a flash upgrade. In this case, an upgrade command can be generated based on the current ECU's identifier and sent to the T-BOX. Otherwise, the current ECU is determined to be the latest version and does not require a flash upgrade. The preset time interval is a pre-set duration that represents the time interval between two consecutive software version query requests sent by the T-BOX to the server.

[0035] After receiving the upgrade command from the server, the T-BOX identifies the ECU corresponding to the identifier in the upgrade command as the ECU to be upgraded. Based on the identifier of the ECU to be upgraded, it generates an upgrade time confirmation request and then displays the upgrade time confirmation request on the vehicle's display screen or sends it to the user terminal so that the user terminal can display the upgrade time confirmation request. At this time, the user can select the upgrade time for the ECU to be upgraded on the vehicle's display screen or the user terminal's display screen. Then, the T-BOX can obtain the upgrade time selected by the user for the ECU to be upgraded and, when the upgrade time arrives, check whether the vehicle status meets the preset flashing conditions of the ECU to be upgraded. For example, if the vehicle is parked, the vehicle power supply is normal, the communication between the T-BOX and the ECU to be upgraded is normal, and the ECU to be upgraded is fault-free, then it is determined that the preset flashing conditions of the ECU to be upgraded are met.

[0036] In response to the preset flashing conditions of the ECU to be upgraded, T-BOX downloads the upgrade package of the ECU to be upgraded from the server via wireless network, and parses the upgrade package to obtain signature data and the file to be flashed.

[0037] S120. Write the file to be written to the temporary buffer area, verify the signature data and the file to be written to the temporary buffer area based on the preset security key and the public key ciphertext pre-stored in the parameter area, obtain the verification result, and write the file to be written to the flash memory area when the verification result is successful.

[0038] The preset security key is a pre-set key used to ensure the security of the public key, and it is stored in the parameter area. The public key ciphertext is the ciphertext corresponding to the public key; the public key is paired with the private key and used to decrypt the signature data. The verification result is the result obtained after verifying the signature data and the file to be written, including verification success and verification failure.

[0039] Specifically, the file to be written can be stored in a temporary cache area, and the public key ciphertext and preset security key pre-stored in the parameter area can be obtained. Then, the signature data and the file to be written can be verified based on the preset security key and the public key ciphertext to obtain the signature verification result. For example, the public key ciphertext can be decrypted using the preset security key to obtain the public key, and the signature data and the file to be written can be verified based on the public key to obtain the signature verification result.

[0040] If the verification result is successful, it indicates that the file to be flashed has not been tampered with, and the flashing and upgrade operation can continue. At this time, the file to be flashed in the temporary cache area can be written to the flash memory area. If the verification result is unsuccessful, it indicates that the file to be flashed may have been tampered with, and the flashing and upgrade operation cannot continue. At this time, a flashing failure prompt can be generated based on the identifier of the ECU to be upgraded and displayed on the vehicle's display screen, or the flashing failure prompt can be sent to the user terminal so that the user terminal can display the flashing failure prompt to remind the user that the ECU to be upgraded has failed to flash.

[0041] Optionally, the flash memory area can be divided into at least two flash memory partitions. That is, the flash memory area of ​​each ECU inside the vehicle includes at least two flash memory partitions, and the ECU runs based on the program files in one flash memory partition. It should be noted that the flash memory area of ​​the T-BOX also includes at least two flash memory partitions.

[0042] S130. Distribute the file to be flashed in the flash memory area to the ECU to be upgraded, so that the ECU to be upgraded can determine the partition to be flashed from at least two flash memory partitions, write the received file to be flashed to the partition to be flashed, and run based on the file to be flashed in the partition to be flashed on the next boot.

[0043] The partition to be flashed is the flash partition where the file to be flashed is to be written, which is either one of the two flash partitions of the ECU to be upgraded that is not the running partition; the running partition is the flash partition that stores the programs and data currently being used by the ECU to be upgraded.

[0044] Specifically, the T-BOX can distribute the file to be flashed from the flash memory to the ECU to be upgraded. Then, the ECU to be upgraded can receive the file to be flashed from the T-BOX and determine the partition to be flashed from at least two flash memory partitions. For example, when there are two flash memory partitions, the flash memory partition that is not the running partition is determined as the partition to be flashed. Next, the data in the partition to be flashed is erased. After erasing, the file to be flashed is written to the partition to be flashed. Then, after writing, the partition validity flag of the partition to be flashed is modified to be valid, and the partition validity flag of the running partition is modified to be invalid, to ensure that the ECU to be upgraded will load the program from the partition to be flashed and run it on the next boot. Then, a flashing success prompt is generated based on the identifier of the ECU to be upgraded and displayed to remind the user that the ECU to be flashed has been successfully upgraded. At this time, the user can restart the ECU to be upgraded.

[0045] During the next boot process, the ECU to be upgraded can check the partition validity flag of each flash partition through the bootloader, and load and run the application from the flash partition where the partition validity flag is valid, so as to run based on the file to be flashed in the partition to be flashed on the next boot.

[0046] It should be noted that when the ECU to be upgraded fails to be flashed, the ECU will not modify the partition validity flag of the partition to be flashed and the running partition. Therefore, it will still run based on the data in the running partition on the next boot, which means that a stable version of the application can still be run even when the flashing fails, thus ensuring the safe and stable operation of the ECU to be upgraded.

[0047] The technical solution of this application embodiment, in response to meeting the preset flashing conditions of the electronic control unit (ECU) to be upgraded, downloads the upgrade package of the ECU to be upgraded from the server, and parses the upgrade package to obtain signature data and the file to be flashed. The signature data is obtained by the manufacturer's device encrypting the file to be flashed based on a private key. Then, the file to be flashed is written to a temporary buffer. The signature data and the file to be flashed are verified based on a preset security key and a public key ciphertext pre-stored in the parameter area to obtain a verification result. If the verification result is successful, the file to be flashed in the temporary buffer is written to the flash memory area. The parameter area stores the public key ciphertext, not the plaintext, to prevent public key leakage, thereby ensuring the security and validity of the public key. Furthermore, the public key ciphertext pre-stored in the parameter area enables verification of the upgrade package, thus ensuring the integrity and accuracy of the file to be flashed in the flash memory area, thereby improving the flashing accuracy of the ECU to be upgraded. Afterwards, the file to be flashed in the flash memory area... The flashing file is distributed to the ECU to be upgraded, allowing the ECU to determine the flashing partition from at least two flash memory partitions. The received flashing file is written to this partition, and the ECU runs based on the flashing file in the next boot. This enables automatic flashing and upgrading of the vehicle ECU, eliminating the need for on-site manual flashing by manufacturer personnel, saving manufacturers time and manpower costs, and improving the feasibility and efficiency of vehicle flashing. Furthermore, by setting the ECU's flash memory to include at least two partitions and restricting the ECU to write the flashing file to the flashing partition instead of the running partition, seamless flashing and upgrading of the vehicle ECU is achieved. Even in the event of a flashing failure, the ECU continues to run based on the application in the running partition upon the next boot, enabling a rollback function in case of flashing failure. This ensures the safe and stable operation of the ECU, thereby guaranteeing vehicle safety and reliability and improving the user experience.

[0048] The following further describes a vehicle flashing method provided by an embodiment of this application. Figure 2 This is another schematic flowchart of the vehicle flashing method provided in this application. This application's embodiment is an optimization based on the above embodiments. See also... Figure 2 The method in this embodiment includes, but is not limited to, the following steps:

[0049] S201. In response to meeting the preset flashing conditions of the electronic control unit (ECU) to be upgraded, download the upgrade package of the ECU to be upgraded from the server, and parse the upgrade package to obtain signature data and the file to be flashed.

[0050] S202. Obtain the version number of the ECU to be upgraded, get the current version number, and extract the version number from the file to be flashed to get the new version number.

[0051] The current version number is the version number currently running on the ECU to be upgraded; the new version number is the version number in the file to be flashed.

[0052] S203. Determine whether the new version number is greater than the current version number.

[0053] Specifically, if the new version number is greater than the current version number, it indicates that the ECU to be upgraded needs to be flashed and upgraded, and S204 can be executed in this case; otherwise, it indicates that the ECU to be upgraded is already the latest version and does not need to be flashed and upgraded, and S211 can be executed in this case.

[0054] S204. When the new version number is greater than the current version number, the file to be flashed is written to the temporary cache area.

[0055] S205. Verify the signature data and the file to be written based on the preset security key and the public key ciphertext pre-stored in the parameter area to obtain the signature verification result.

[0056] Specifically, the pre-stored public key ciphertext is retrieved from the parameter area and decrypted using a preset security key to obtain the public key. For example, the AES128 (Advanced Encryption Standard 128-bit) algorithm is used to decrypt the public key ciphertext based on the preset security key. The signature data is then decrypted using the public key to obtain the first decrypted data. For example, the ED25519 algorithm is used to decrypt the signature data based on the public key, which can improve the decryption speed. If the first decrypted data matches the file to be flashed, the signature verification result is determined to be successful; if the first decrypted data does not match the file to be flashed, the signature verification result is determined to be unsuccessful. By decrypting the signature data with the public key and comparing the first decrypted data with the file to be flashed, it is possible to verify whether the file to be flashed has been tampered with during the download process, thereby ensuring the integrity and accuracy of the file to be flashed.

[0057] Optionally, the steps for determining the public key ciphertext are as follows: The system can receive the public key to be written from an external diagnostic device. Specifically, the external diagnostic device sends the public key to be written to the T-BOX via the 0x31 diagnostic service of the Unified Diagnostic Services (UDS) protocol. Then, the public key to be written is encrypted based on a preset security key to obtain the public key ciphertext, which is then written to the parameter area. Here, the external diagnostic device is a dedicated tool used to detect, diagnose, configure, or upgrade the vehicle's ECU, sensors, actuators, and overall system; for example, the external diagnostic device can be a diagnostic instrument. The public key to be written is a public key paired with the manufacturer's device's private key; here, it is the plaintext of the public key.

[0058] The preset security key is obtained by encrypting the device identifier of the remote information processor based on the preset root key. For example, the device identifier of the T-BOX is encrypted using the AES128-CBC (Advanced Encryption Standard 128-bit Cipher BlockChaining) algorithm based on the preset root key to obtain the preset security key. The preset root key is a pre-set key used to determine the preset security key. Furthermore, the preset root key is pre-stored in the parameter area.

[0059] In this embodiment, the function of writing public key ciphertext can be implemented, and the public key ciphertext is written to the parameter area instead of the public key plaintext. This can prevent public key leakage, thereby ensuring the security and validity of the public key and providing an accurate data foundation for subsequent signature verification operations.

[0060] It should be noted that the public key ciphertext determination process is performed on the vehicle production line, that is, the determined public key ciphertext is written into the parameter area of ​​the T-BOX during vehicle production.

[0061] Optionally, Sa1-Sa4 are also included before writing the public key ciphertext into the parameter area:

[0062] Sa1. Write the public key ciphertext into a temporary buffer and send a response to the external diagnostic device for the public key to be written, so that the external diagnostic device can generate a key check request based on the preset digest key and send the key check request back to the remote information processor.

[0063] The preset digest key is a key pre-set by the external diagnostic device and is used for key verification. The key verification request is generated by the external diagnostic device and is a request message used to confirm the validity, legitimacy, or consistency of the public key to be written.

[0064] Sa2, in response to a key check request sent by an external diagnostic device, decrypts the public key ciphertext in the temporary buffer based on a preset security key to obtain second decrypted data, and encrypts the second decrypted data based on a preset digest key in the key check request to obtain first digest information.

[0065] The second decrypted data is obtained by decrypting the public key ciphertext in the temporary buffer using a preset security key. The first digest information is obtained by encrypting the second decrypted data using a preset digest key; it is the digest information of the second decrypted data (i.e., the public key).

[0066] Sa3. Send the first summary information to the external diagnostic device so that the external diagnostic device compares the first summary information with the second summary information and sends a write confirmation command to the remote information processor when the comparison result shows that the data is consistent.

[0067] The second digest information is obtained by encrypting the public key to be written using a preset digest key by an external diagnostic device, and is a digest of the public key; the write confirmation command is used to confirm that the ciphertext of the public key is written to the parameter area.

[0068] Specifically, when the comparison results show that the data is consistent, the external diagnostic device sends a confirmation instruction to T-BOX through the 0x31 diagnostic service of the UDS protocol.

[0069] Sa4, in response to a write confirmation command sent by an external diagnostic device, triggers the writing of the public key ciphertext into the parameter area.

[0070] Specifically, in response to a write confirmation command sent by an external diagnostic device, the public key ciphertext is written to the parameter area. Once the public key ciphertext is written to the parameter area, it cannot be deleted or modified, thus ensuring the security and validity of the public key.

[0071] In this embodiment, the function of checking the public key ciphertext can be realized, thereby ensuring the integrity and accuracy of the public key ciphertext stored in the parameter area, and providing an accurate data foundation for subsequent signature verification operations.

[0072] Optionally, if the comparison result indicates data inconsistency, the external diagnostic device sends a write revocation command to T-BOX via the 0x31 diagnostic service of the UDS protocol. This write revocation command is generated by the external diagnostic device and is used to revoke the key writing operation. In response to the write revocation command sent by the external diagnostic device, T-BOX deletes the public key ciphertext in the temporary buffer and sends a public key retrieval request to the external diagnostic device. This allows the external diagnostic device to resend the public key to be written to T-BOX via the 0x31 diagnostic service of the UDS protocol. Then, the above key writing and checking operations are repeated until the public key ciphertext is successfully written to the parameter area.

[0073] Optionally, before the T-BOX receives the public key to be written from the external diagnostic device, it can enter the T-BOX's main boot process. Then, the external diagnostic device unlocks the security level of the current mode using the 0x27 diagnostic service of the UDS protocol. After successful unlocking, the external diagnostic device sends the public key to be written to the T-BOX via the 0x31 diagnostic service of the UDS protocol. After the public key ciphertext is written to the parameter area, a reset can be performed.

[0074] S206. Determine whether the verification result is "verification passed".

[0075] Specifically, if the signature verification result is successful, it indicates that the file to be written has not been tampered with, and S207 can be executed at this time; if the signature verification result is unsuccessful, it indicates that the file to be written may have been tampered with, and S210 can be executed at this time.

[0076] Optionally, the flash memory area includes an upgrade package partition, which is used to store upgrade packages downloaded from the server; the upgrade package partition may include at least two first sub-regions, and the remote information processor may include at least two first cores, i.e., T-BOX is a multi-core processor, and one first core controls one first sub-region.

[0077] S207. When the verification result is successful, the file to be written in the temporary cache is split to obtain at least two sub-files to be written.

[0078] The number of sub-files to be written is the same as the number of sub-regions.

[0079] Specifically, when the signature verification result is successful, the file to be written in the temporary cache can be split into at least two sub-files to be written, and the positional order between the at least two sub-files to be written can be marked, that is, the order between the positions of the at least two sub-files to be written in the file to be written.

[0080] S208: Use at least two first kernels to write at least two sub-files to be flashed into the corresponding first sub-region.

[0081] Specifically, a sub-file to be flashed can be sent to each first kernel, and each first kernel can write the received sub-file to be flashed into the corresponding first sub-region, so that a different sub-file to be flashed is stored in each first sub-region.

[0082] Optionally, the partition to be flashed in the ECU to be upgraded may include at least two second sub-regions, and the ECU to be upgraded may include at least two second cores, that is, the ECU to be upgraded is a multi-core processor, and one second core controls one second sub-region.

[0083] S209. Using at least two first kernels, the sub-files to be flashed in the corresponding first sub-region are transmitted in parallel to the ECU to be upgraded via a multiplexed controller area network bus, so that the ECU to be upgraded can use at least two second kernels to erase the corresponding second sub-region, write the received sub-files to be flashed into the corresponding second sub-region, and run based on the sub-files to be flashed in the at least two second sub-regions at the next startup.

[0084] Specifically, the Controller Area Network (CAN) bus between the T-BOX and the ECU to be upgraded can be configured as a multi-channel CAN bus. In this way, the T-BOX can use at least two first cores to transmit the sub-files to be flashed in the corresponding first sub-region to the ECU to be upgraded in parallel via the multi-channel CAN bus, which can shorten the transmission time of the files to be flashed and thus improve the transmission rate of the files to be flashed.

[0085] Then, the ECU to be upgraded can receive the sub-files to be flashed transmitted in parallel via multiple CAN buses, determine the positional order between at least two sub-files, and then obtain the loading order between the second sub-regions, i.e., the data loading order between at least two second sub-regions when the ECU to be upgraded starts. Based on the positional order between the at least two sub-files to be flashed and the loading order between the second sub-regions, the correspondence between the sub-files to be flashed and the second sub-regions is set, i.e., in which second sub-region the sub-file to be flashed is stored. This also determines the relationship between the sub-file to be flashed and the second sub-region. The correspondence between the two kernels is as follows: For example, if the positional order of the sub-files to be flashed is sub-file 1, sub-file 2, sub-file 3, and sub-file 4, and the loading order of the second sub-regions is second sub-region 1, second sub-region 2, second sub-region 3, and second sub-region 4, then sub-file 1 corresponds to second sub-region 1 (i.e., sub-file 1 should be stored in second sub-region 1), sub-file 2 corresponds to second sub-region 2, sub-file 3 corresponds to second sub-region 3, and sub-file 4 corresponds to second sub-region 4.

[0086] Next, the ECU to be upgraded sends each sub-file to be flashed to the corresponding second kernel. Then, it uses at least two second kernels to erase the data in the corresponding second sub-region and writes the corresponding sub-file to be flashed into the corresponding second sub-region. After the writing is completed, the partition validity flag of the partition to be flashed is modified to be valid, and the partition validity flag of the running partition is modified to be invalid. This ensures that the ECU to be upgraded will load the program from the partition to be flashed and run it on the next boot. Then, a flashing success message is generated and displayed based on the identifier of the ECU to be upgraded to remind the user that the ECU to be flashed has been successfully upgraded. At this time, the user can restart the ECU to be upgraded so that it will run on the next boot according to the loading order between at least two second sub-regions based on the sub-files to be flashed in at least two second sub-regions.

[0087] S210. When the verification result is a verification failure, generate a flashing failure prompt based on the identifier of the ECU to be upgraded, and display the flashing failure prompt.

[0088] S211. When the new version number is not greater than the current version number, generate a no-flash prompt based on the identifier of the ECU to be upgraded, and display the no-flash prompt.

[0089] The "No Flashing" prompt is used to remind users that there is no need to flash or upgrade the ECU to be upgraded.

[0090] The technical solution of this application embodiment, in response to meeting the preset flashing conditions of the electronic control unit (ECU) to be upgraded, downloads the upgrade package of the ECU to be upgraded from the server, parses the upgrade package to obtain signature data and the file to be flashed, then obtains the version number of the ECU to be upgraded, obtains the current version number, and extracts the version number from the file to be flashed to obtain the new version number. When the new version number is greater than the current version number, the file to be flashed is written to a temporary cache area; when the new version number is not greater than the current version number, a no-flash prompt is generated based on the identifier of the ECU to be upgraded and displayed. This can realize the version check function, which is beneficial for subsequent... The system provides a criterion for determining whether to perform a flash upgrade, thereby improving the accuracy of the flash upgrade. Next, based on a preset security key and a public key ciphertext pre-stored in the parameter area, the signature data and the file to be flashed are verified. If the verification result is successful, the file to be flashed in the temporary cache is split into at least two sub-files. Then, at least two first kernels are used to write these two sub-files into their corresponding first sub-regions. This allows for parallel writing of at least two sub-files to their corresponding first sub-regions, shortening the writing time and improving the flash upgrade efficiency. The file writing efficiency is improved, thus increasing the efficiency of flashing and upgrading. Then, at least two first cores are used to transmit the sub-files to be flashed in the corresponding first sub-region to the ECU to be upgraded in parallel via a multi-channel controller area network bus. This allows the ECU to use at least two second cores to erase the corresponding second sub-region, write the received sub-files to be flashed into the corresponding second sub-region, and run based on the sub-files to be flashed in the at least two second sub-regions upon the next startup. This enables parallel transmission of the sub-files to be flashed between the T-BOX and the ECU to be upgraded, shortening the transmission time of the flashed files and thus improving efficiency. The increased transmission rate of the files to be flashed improves the efficiency of the flashing and upgrading process. Furthermore, by configuring the ECU's flash memory area to include at least two flash partitions and restricting the ECU to write the files to be flashed to the designated partition instead of the running partition, seamless flashing and upgrading of the vehicle ECU is achieved. In the event of a flashing failure, the ECU will still run based on the application in the running partition upon the next startup, enabling a rollback function in case of flashing failure. This ensures the safe and stable operation of the ECU, thereby guaranteeing vehicle safety and reliability and enhancing the user experience.

[0091] Figure 3 This is a schematic diagram of a vehicle writing device provided in an embodiment of this application, referring to... Figure 3 The vehicle rewriting device may include:

[0092] The download module 310 is used to download the upgrade package of the ECU to be upgraded from the server in response to the preset flashing conditions of the ECU to be upgraded, and to parse the upgrade package to obtain signature data and the file to be flashed; the signature data is obtained by the manufacturer's device encrypting the file to be flashed based on the private key;

[0093] The signature verification module 320 is used to write the file to be written to the temporary buffer area, verify the signature data and the file to be written based on the preset security key and the public key ciphertext pre-stored in the parameter area, obtain the signature verification result, and write the file to be written in the temporary buffer area to the flash memory area when the signature verification result is successful.

[0094] The distribution module 330 is used to distribute the file to be flashed in the flash memory area to the ECU to be upgraded, so that the ECU to be upgraded can determine the partition to be flashed from at least two flash memory partitions, write the received file to be flashed into the partition to be flashed, and run based on the file to be flashed in the partition to be flashed on the next boot.

[0095] In one embodiment, the signature verification module 320 verifies the signature data and the file to be written based on a preset security key and a public key ciphertext pre-stored in the parameter area to obtain a signature verification result. This includes: obtaining the pre-stored public key ciphertext from the parameter area and decrypting the public key ciphertext using the preset security key to obtain a public key; decrypting the signature data using the public key to obtain first decrypted data; determining that the signature verification result is successful when the first decrypted data matches the file to be written; and determining that the signature verification result is unsuccessful when the first decrypted data does not match the file to be written.

[0096] In one embodiment, the flash memory area includes an upgrade package partition, which includes at least two first sub-regions. The remote information processor includes at least two first cores, with one first core controlling one first sub-region. The signature verification module 320 writes the file to be written in the temporary cache area into the flash memory area, including: splitting the file to be written in the temporary cache area to obtain at least two sub-files to be written, the number of sub-files to be written being the same as the number of first sub-regions; and using the at least two first cores to write the at least two sub-files to be written into the corresponding first sub-regions.

[0097] In one embodiment, the partition to be flashed in the ECU to be upgraded includes at least two second sub-regions, and the ECU to be upgraded includes at least two second cores, with one second core controlling one second sub-region. The distribution module 330 distributes the file to be flashed in the flash memory area to the ECU to be upgraded, including: using at least two first cores to transmit the file to be flashed in the corresponding first sub-region to the ECU to be upgraded in parallel via a multiplexer LAN bus, so that the ECU to be upgraded can use at least two second cores to erase the corresponding second sub-region, write the received file to be flashed into the corresponding second sub-region, and run based on the file to be flashed in the at least two second sub-regions at the next startup.

[0098] In one embodiment, the steps for determining the public key ciphertext in the signature verification module 320 are as follows: receiving the public key to be written sent by an external diagnostic device; encrypting the public key to be written based on a preset security key to obtain the public key ciphertext, and writing the public key ciphertext into the parameter area; wherein, the preset security key is obtained by encrypting the device identifier of the remote information processor based on a preset root key.

[0099] In one embodiment, the vehicle writing device further includes a key checking module, which is used to: write the public key ciphertext into a temporary buffer before writing it into the parameter area, and send a response to an external diagnostic device for the public key to be written, so that the external diagnostic device generates a key checking request based on a preset digest key and sends the key checking request to a remote information processor; in response to the key checking request sent by the external diagnostic device, decrypt the public key ciphertext in the temporary buffer based on a preset security key to obtain second decrypted data, and encrypt the second decrypted data based on the preset digest key in the key checking request to obtain first digest information; send the first digest information to the external diagnostic device, so that the external diagnostic device compares the first digest information and the second digest information and sends a write confirmation command to the remote information processor when the comparison result is consistent; the second digest information is obtained by the external diagnostic device encrypting the public key to be written based on the preset digest key; and in response to the write confirmation command sent by the external diagnostic device, trigger the execution of writing the public key ciphertext into the parameter area.

[0100] In one embodiment, the file to be flashed includes a version number, and the vehicle flashing device further includes a version checking module. The version checking module is used to: obtain the version number of the ECU to be upgraded before writing the file to be flashed into the temporary cache area, obtain the current version number, extract the version number from the file to be flashed, and obtain the new version number; when the new version number is greater than the current version number, trigger the execution of writing the file to be flashed into the temporary cache area.

[0101] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0102] The vehicle writing device provided in this embodiment can be applied to the vehicle writing method provided in any of the above embodiments, and has the corresponding functions and beneficial effects.

[0103] Figure 4 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Figure 4 A block diagram of an exemplary vehicle 11 suitable for implementing embodiments of this application is shown. Figure 4 The vehicle 11 shown is merely an example and should not impose any limitations on the functionality and scope of use of this embodiment.

[0104] like Figure 4 As shown, vehicle 11 is represented in the form of a general-purpose computing electronic device. Components of vehicle 11 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0105] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0106] Vehicle 11 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by vehicle 11, including volatile and non-volatile media, removable and non-removable media.

[0107] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Vehicle 11 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 4 Not shown; usually referred to as a "hard drive"). AlthoughFigure 4 As not shown, disk drives for reading and writing to removable non-volatile disks (e.g., "floppy disks") and optical disc drives for reading and writing to removable non-volatile optical discs (e.g., CD-ROMs, DVD-ROMs, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0108] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of this application.

[0109] Vehicle 11 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with vehicle 11, and / or with any device that enables vehicle 11 to communicate with one or more other computing devices (e.g., network interface card and modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, vehicle 11 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20.

[0110] like Figure 4 As shown, network adapter 20 communicates with other modules of vehicle 11 via bus 18. It should be understood that, although... ​ As not shown, other hardware and / or software modules may be used in conjunction with vehicle 11, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0111] The processing unit 16 executes various functional applications and page displays by running programs stored in the system memory 28, such as implementing a vehicle flashing method provided in this application embodiment, applied to a vehicle's telematics processor. The storage area of ​​the telematics processor includes a temporary cache area, a flash memory area, and a parameter area. The method includes: in response to meeting the preset flashing conditions of the electronic control unit (ECU) to be upgraded, downloading the upgrade package of the ECU to be upgraded from the server, and parsing the upgrade package to obtain signature data and a file to be flashed; the signature data is obtained by encrypting the file to be flashed by the manufacturer's device based on a private key; writing the file to be flashed into the temporary cache area, verifying the signature data and the file to be flashed based on a preset security key and a public key ciphertext pre-stored in the parameter area, obtaining a verification result, and writing the file to be flashed in the temporary cache area into the flash memory area when the verification result is successful; distributing the file to be flashed in the flash memory area to the ECU to be upgraded, so that the ECU to be upgraded determines the flashing partition from at least two flash memory partitions, writes the received file to be flashed into the flashing partition, and runs based on the file to be flashed in the flashing partition during the next startup.

[0112] Of course, those skilled in the art will understand that the processor can also implement the technical solutions of the vehicle flashing method provided in any embodiment of this application.

[0113] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a vehicle flashing method, such as the one provided in this application, applied to a vehicle's telematics processor. The telematics processor's storage area includes a temporary cache area, a flash memory area, and a parameter area. The method includes: in response to meeting preset flashing conditions of an electronic control unit (ECU) to be upgraded, downloading an upgrade package of the ECU to be upgraded from a server and parsing the upgrade package to obtain signature data and a file to be flashed; the signature data is obtained by encrypting the file to be flashed using a manufacturer's device based on a private key; writing the file to be flashed into the temporary cache area; verifying the signature data and the file to be flashed based on a preset security key and a public key ciphertext pre-stored in the parameter area to obtain a verification result; and when the verification result is successful, writing the file to be flashed from the temporary cache area into the flash memory area; distributing the file to be flashed from the flash memory area to the ECU to be upgraded, so that the ECU to be upgraded determines the flashing partition from at least two flash memory partitions, writes the received file to be flashed into the flashing partition, and runs based on the file to be flashed in the flashing partition upon the next startup.

[0114] The computer storage medium of this embodiment can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0115] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0116] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0117] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0118] Those skilled in the art will understand that the modules or steps described above in this application can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, which can then be stored in a storage device for execution by a computing device. Alternatively, they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0119] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant laws and regulations.

[0120] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments. Many other equivalent embodiments may be included without departing from the inventive concept of this application, and the scope of this application is determined by the scope of the appended claims.

Claims

1. A vehicle flashing method, characterized in that, A telematics processor for vehicles, wherein the storage area of ​​the telematics processor includes a temporary cache area, a flash memory area, and a parameter area, the method comprising: In response to meeting the preset flashing conditions of the ECU to be upgraded, the upgrade package of the ECU to be upgraded is downloaded from the server, and the upgrade package is parsed to obtain signature data and the file to be flashed; the signature data is obtained by the manufacturer's device encrypting the file to be flashed based on the private key; Write the file to be written to the temporary buffer area. Verify the signature data and the file to be written based on the preset security key and the public key ciphertext pre-stored in the parameter area to obtain the verification result. When the verification result is successful, write the file to be written to the flash memory area from the temporary buffer area. The file to be flashed in the flash memory is distributed to the ECU to be upgraded, so that the ECU to be upgraded can determine the partition to be flashed from at least two flash memory partitions, write the received file to be flashed to the partition to be flashed, and run based on the file to be flashed in the partition to be flashed on the next boot.

2. The vehicle flashing method according to claim 1, characterized in that, The signature data and the file to be written are verified based on the preset security key and the public key ciphertext pre-stored in the parameter area to obtain the verification result, including: Retrieve the pre-stored public key ciphertext from the parameter area, and decrypt the public key ciphertext using the preset security key to obtain the public key; The signature data is decrypted using the public key to obtain the first decrypted data; If the first decrypted data matches the file to be written, the signature verification result is determined to be successful. If the first decrypted data and the file to be written are inconsistent, the signature verification result is determined to be a verification failure.

3. The vehicle flashing method according to claim 1, characterized in that, The flash memory includes an upgrade package partition, which contains at least two first sub-regions. The remote information processor includes at least two first cores, with one first core controlling one first sub-region. The process of writing files to be flashed from the temporary cache to the flash memory includes: The file to be written in the temporary buffer is split into at least two sub-files to be written, and the number of sub-files to be written is the same as the number of the first sub-region. At least two first kernels are used to write at least two sub-files to be flashed into the corresponding first sub-region.

4. The vehicle flashing method according to claim 3, characterized in that, The partition to be flashed in the ECU to be upgraded includes at least two second sub-regions, and the ECU to be upgraded includes at least two second cores. Each second core controls one second sub-region. The flash files to be flashed are distributed to the ECU to be upgraded, including: At least two first kernels are used to transmit the sub-files to be flashed in the corresponding first sub-region to the ECU to be upgraded in parallel via a multi-channel controller area network bus. This allows the ECU to erase the corresponding second sub-region using at least two second kernels, write the received sub-files to be flashed into the corresponding second sub-region, and run based on the sub-files to be flashed in the at least two second sub-regions on the next startup.

5. The vehicle flashing method according to claim 1, characterized in that, The steps to determine the public key ciphertext are as follows: Receive the public key to be written from an external diagnostic device; The public key to be written is encrypted based on the preset security key to obtain the public key ciphertext, and then written into the parameter area; wherein, the preset security key is obtained by encrypting the device identifier of the remote information processor based on the preset root key.

6. The vehicle flashing method according to claim 5, characterized in that, Before writing the public key ciphertext into the parameter area, the following is also included: The public key ciphertext is written to a temporary buffer and the external diagnostic device is fed back the reception response information for the public key to be written, so that the external diagnostic device can generate a key check request based on the preset digest key and feed back the key check request to the remote information processor. In response to a key check request sent by an external diagnostic device, the public key ciphertext in the temporary buffer is decrypted based on a preset security key to obtain second decrypted data, and the second decrypted data is encrypted based on a preset digest key in the key check request to obtain first digest information; A first digest message is sent to an external diagnostic device so that the external diagnostic device can compare the first digest message with the second digest message and send a write confirmation command to the remote information processor when the comparison result shows that the data is consistent; the second digest message is obtained by the external diagnostic device by encrypting the public key to be written based on the preset digest key. In response to a write confirmation command sent by an external diagnostic device, the process of writing the public key ciphertext into the parameter area is triggered.

7. The vehicle flashing method according to claim 1, characterized in that, The file to be flashed includes a version number, and before writing the file to be flashed to the temporary cache, it also includes: Obtain the version number of the ECU to be upgraded, get the current version number, and extract the version number from the file to be flashed to get the new version number; When the new version number is greater than the current version number, the process is triggered to write the file to be flashed to the temporary cache area.

8. A vehicle writing device, characterized in that, A telematics processor for vehicles, the storage area of ​​which includes a temporary cache area, a flash memory area, and a parameter area, the device comprising: The download module is used to download the upgrade package of the ECU to be upgraded from the server in response to the preset flashing conditions of the ECU to be upgraded, and to parse the upgrade package to obtain the signature data and the file to be flashed; the signature data is obtained by the manufacturer's device encrypting the file to be flashed based on the private key; The signature verification module is used to write the file to be written to the temporary buffer area, verify the signature data and the file to be written based on the preset security key and the public key ciphertext pre-stored in the parameter area, obtain the signature verification result, and write the file to be written in the temporary buffer area to the flash memory area when the signature verification result is successful. The distribution module is used to distribute the file to be flashed in the flash memory area to the ECU to be upgraded, so that the ECU to be upgraded can determine the partition to be flashed from at least two flash memory partitions, write the received file to be flashed to the partition to be flashed, and run based on the file to be flashed in the partition to be flashed on the next boot.

9. A vehicle, characterized in that, The vehicles include: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the vehicle flashing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the vehicle flashing method as described in any one of claims 1 to 7.

Images