Method, device, equipment and product for analyzing flash file of automobile electronic control unit

Abstract

The invention discloses a method, a device, equipment and a product for analyzing a flash file of an automobile electronic control unit, the flash file provided by the invention is a binary file, so that the parsed file occupies less space; meanwhile, before analysis, the file is in an encrypted state, so that the risk of data leakage in the analysis and transmission process can be reduced; furthermore, the flash file contains a file integrity checking byte, and file integrity checking can be performed based on the checking byte before analysis, so that whether the file is damaged or not can be determined in time before analysis, and the problems that the workload is increased and resources are wasted in the traditional technology are avoided; besides, detailed ECU data including flashing information, actual flashing data, user information and vehicle information can be analyzed, so that detailed flashing file information can be obtained, and the flashing accuracy can be ensured; therefore, the method is very suitable for large-scale application and popularization.

Description

Technical Field

[0001] The present invention belongs to the technical field of flash file analysis, and in particular relates to a flash file analysis method, device, equipment and product for an automotive electronic control unit. Background Art

[0002] At present, automotive electronic control units (ECUs) widely use hex, s19, and bin as flash file formats. However, in actual application scenarios, these three file formats have their own shortcomings, as shown below:

[0003] (1) The hex and s19 file formats are developed based on text files. When saving the flash data, the data will be converted into hexadecimal characters, which will increase the data size and generate a larger file. Therefore, it will occupy a larger data space after parsing. (2) The bin, hex and s19 file formats lack integrity verification of the entire file. When the file is damaged, it cannot be discovered in time before parsing. It is necessary to parse the file to find out. Based on this, it not only increases the workload but also wastes parsing resources. (3) The bin, hex and s19 file formats are all saved in the form of raw data without encryption. This leads to the risk of key data leakage during the parsing and transmission process. (4) The bin, hex and s19 file formats lack detailed flash information of the automotive electronic control unit (ECU). After parsing, the information is insufficient, which is easy to cause flash errors. Therefore, based on the above shortcomings, how to provide a parsing method for flash files with detailed parsing information, small space occupation, integrity verification before parsing, and high security has become a problem to be solved. Summary of the invention

[0004] The purpose of the present invention is to provide a method, device, equipment and product for parsing the flash file of an automobile electronic control unit, so as to solve the problems existing in the prior art that the parsed file occupies a large space, it is impossible to judge whether the file is complete before parsing, the security is not high and the information after parsing is insufficient.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions:

[0006] In a first aspect, a method for parsing a flash file of an automotive electronic control unit is provided, comprising:

[0007] Obtaining a flash file of the automobile electronic control unit, wherein the flash file is an encrypted binary file, the flash file includes a file header, a flash information segment, a vehicle information segment, a user information segment, and a flash data segment, and the file header includes an encryption type flag and a file integrity check byte;

[0008] Determining a decryption method for the flash file based on an encryption type flag in a file header of the flash file;

[0009] Decrypting the flash file using the decryption method to obtain a decrypted file;

[0010] Parsing the file header in the decrypted file to obtain the file integrity check byte in the file header;

[0011] Using the file integrity check bytes, determining whether the decrypted file is a complete file;

[0012] If yes, parse the flashing information segment, vehicle information segment, user information segment and flashing data segment in the decrypted file to obtain the flashing information, vehicle information, user information and flashing actual data of the automobile electronic control unit respectively;

[0013] The flashing information, vehicle information, user information and actual flashing data of the automobile electronic control unit are used to generate a parsing result of the flashing file of the automobile electronic control unit.

[0014] Based on the above disclosed content, the present invention first obtains the flash file of the automobile electronic control unit, wherein the flash file is an encrypted binary file and contains a flash information segment, a vehicle information segment, a user information segment, a flash data segment, an encryption type flag and a file integrity check byte; thus, the flash file provided by the present invention contains a file integrity check byte for file integrity verification, and ECU detailed data containing flash information, user information, flash data and vehicle information; thus, based on this, the complete parsing of the flash file can be achieved, and the process is: first, use the encryption in the flash file The encryption type flag is used to determine the decryption method, and then the decryption process is performed to obtain the decrypted file; then, the file header in the decrypted file is parsed to obtain the aforementioned file integrity check byte; then, based on the file integrity check byte, it is determined whether the file is complete. If the file is complete, the parsing can continue, that is, the flashing information segment, vehicle information segment, user information segment and flashing data segment in the aforementioned decrypted file are parsed, so as to obtain the flashing information, vehicle information, user information and actual flashing data of the automotive electronic control unit; finally, the aforementioned information can be used to form the parsing result, so as to complete the flashing of the ECU.

[0015] Through the above design, the flash file provided by the present invention is an encrypted binary file, that is, it is stored in binary format. In this way, compared with the traditional hexadecimal file format, the parsed file occupies less space; at the same time, before parsing, the file is in an encrypted state, therefore, the risk of data leakage during the parsing and transmission process can be reduced, thereby improving the security of the data; further, the flash file contains a file integrity check byte, and the file integrity check can be performed based on the check byte before parsing, so that it can be determined in time before parsing whether the file is damaged, thereby avoiding the problem of increased workload and waste of resources in traditional technology that requires the file to be parsed before knowing the file damage; in addition, the present invention can parse out detailed data of the ECU including flashing information, actual flashing data, user information and vehicle information, thereby, detailed flashing file information can be obtained, thereby ensuring the accuracy of the flashing; based on this, the present invention is very suitable for large-scale application and promotion.

[0016] In a possible design, the file header further includes: a flash information segment offset, a vehicle information segment offset, a user information segment offset, a flash data block number, and a flash data segment offset;

[0017] Wherein, after determining that the decrypted file is a complete file, the method further includes:

[0018] Parse the file header in the decrypted file to obtain the flash information segment offset, the vehicle information segment offset, the user information segment offset, the number of flash data blocks, and the flash data segment offset;

[0019] Correspondingly, parsing the flashing information segment, vehicle information segment, user information segment and flashing data segment in the decrypted file to obtain the flashing information, vehicle information, user information and flashing actual data of the automotive electronic control unit respectively includes:

[0020] Determine the starting position of the flash information segment in the decrypted file according to the flash information segment offset, determine the starting position of the vehicle information segment in the decrypted file according to the vehicle information segment offset, determine the starting position of the user information segment in the decrypted file according to the user information segment offset, and determine the starting position of the flash data segment in the decrypted file according to the flash data segment offset;

[0021] Based on the starting position of the flash information segment in the decrypted file, the flash information segment is parsed to obtain the flash information;

[0022] According to the starting position of the vehicle information segment in the decrypted file, the vehicle information segment is parsed to obtain the vehicle information;

[0023] Utilizing the starting position of the user information segment in the decrypted file, parsing the user information segment to obtain the user information; and

[0024] According to the starting position of the flash data segment in the decrypted file and the number of the flash data blocks, the flash data segment is parsed to obtain the actual flash data.

[0025] In a possible design, the flash information segment, the vehicle information segment and the user information segment respectively include a number of pieces of data, and each piece of data is set with a corresponding number of occupied bytes;

[0026] Wherein, determining the starting position of the flash information segment in the decrypted file according to the flash information segment offset includes:

[0027] Obtain the number of occupied bytes corresponding to the offset of the flash information segment, and convert the obtained number of occupied bytes into an unsigned integer;

[0028] Determine the starting position of the flash information segment in the decrypted file according to the unsigned integer;

[0029] Correspondingly, based on the starting position of the flash information segment in the decrypted file, the flash information segment is parsed to obtain the flash information, which includes:

[0030] Taking the starting position of the flash information segment in the decrypted file as the starting point, and reading the data in the flash information segment in sequence according to the number of occupied bytes corresponding to each piece of data in the flash information segment, so as to obtain a plurality of read data;

[0031] The flash information is composed of a plurality of read data.

[0032] In a possible design, the flash data segment includes p data blocks, and p is equal to the number of the flash data blocks;

[0033] The flashing data segment is parsed and processed according to the starting position of the flashing data segment in the flashing file and the number of the flashing data blocks to obtain the flashing actual data, including:

[0034] For the i-th data block in the flash data segment, take the end point of the i-1-th data block as the starting point, read n bytes after the starting point, and use n bytes to determine the starting address of the flash data block in the i-th data block, where n is the number of bytes occupied by the starting address of the flash data block in the i-th data block in the decrypted file, and when i is 1, the end point of the i-1-th data block is the starting position of the flash data segment in the decrypted file;

[0035] After reading n bytes, continue to read m bytes after n bytes, so as to determine the data length of the actual flush data in the i-th data block based on the read m bytes, wherein m is the data length of the actual flush data in the i-th data block, and the number of bytes occupied in the decrypted file;

[0036] After reading m bytes, continue to read k bytes after m bytes, so as to use the read k bytes as the actual write data in the i-th data block, wherein k is the data length of the actual write data in the i-th data block;

[0037] Add 1 to i, and start from the end of the i-1th data block again, read n bytes after the starting point, until i equals p, and get the starting address and actual writing data of each data block, where the initial value of i is 1;

[0038] The actual writing data is composed by using the starting address of the writing data block and the actual writing data in each data block.

[0039] In a possible design, before determining the decryption method of the flash file based on the encryption type flag in the file header of the flash file, the method further includes:

[0040] Obtain the file occupied capacity of the flash file;

[0041] Determine whether the file occupied capacity is greater than or equal to the minimum occupied capacity;

[0042] If so, the decryption method of the flash file is determined based on the encryption type flag in the file header of the flash file; otherwise, a file error prompt message is output.

[0043] In a possible design, the file header further includes: a file type flag, a version number of the file format, a generation date, a generation time, and a diagnostic system number, wherein the generation date includes the file generation year, the file generation month, and the file generation day, and the generation time includes the file generation hour, the file generation minute, and the file generation second;

[0044] After obtaining the flash file of the automobile electronic control unit, the method further includes:

[0045] Obtain the file type flag in the file header;

[0046] Determining the file type of the flash file according to the file type flag;

[0047] Determine whether the file type is a preset type;

[0048] If yes, determining the decryption method of the flash file based on the encryption type flag in the file header of the flash file;

[0049] Correspondingly, after determining that the decrypted file is a complete file, the method further includes:

[0050] Continue to parse the file header to obtain the version number, generation date, generation time and diagnostic system number of the flash file, so as to use the version number, generation date, generation time and diagnostic system number of the flash file, as well as the flash information, vehicle information, user information and actual flash data of the automotive electronic control unit to form the parsing result.

[0051] In a possible design, the file header further includes: a custom section offset, and the flash file further includes a custom section;

[0052] The flash information segment includes ECU model, ECU ID, ECU hardware ID, ECU hardware version number, ECU software ID, ECU software version number, ECU boot version, ECU calibration identification code, ECU code, system vendor ID, system vendor hardware number, system vendor hardware version number, system vendor software number and system vendor software version number;

[0053] The vehicle information segment includes vehicle brand, vehicle model, vehicle VIN, manufacturing year and month, engine model and engine serial number; the user information segment includes user registration mobile phone number, diagnostic platform type, VDI model, VDI SN code, hardware version, factory date, boot version number, app version number and chip ID.

[0054] In a second aspect, a device for parsing a flash file of an automotive electronic control unit is provided, comprising:

[0055] An acquisition unit, used for acquiring a flash file of a vehicle electronic control unit, wherein the flash file is an encrypted binary file, the flash file includes a file header, a flash information segment, a vehicle information segment, a user information segment and a flash data segment, and the file header includes an encryption type flag and a file integrity check byte;

[0056] A decryption unit, configured to determine a decryption method of the flash file based on an encryption type flag in a file header of the flash file;

[0057] The decryption unit is further used to decrypt the flash file using the decryption method to obtain a decrypted file;

[0058] A parsing unit, used for parsing a file header in the decrypted file to obtain a file integrity check byte in the file header;

[0059] A parsing unit, used to determine whether the decrypted file is a complete file by using the file integrity check bytes;

[0060] If yes, the parsing unit is used to parse the flashing information segment, the vehicle information segment, the user information segment and the flashing data segment in the decrypted file to obtain the flashing information, the vehicle information, the user information and the flashing actual data of the automobile electronic control unit respectively;

[0061] The parsing unit is also used to generate a parsing result of the flashing file of the automotive electronic control unit by using the flashing information, vehicle information, user information and actual flashing data of the automotive electronic control unit.

[0062] According to a third aspect, another device for parsing the flash file of an automotive electronic control unit is provided. Taking the device as an electronic device as an example, the device includes a memory, a processor and a transceiver which are communicatively connected in sequence, wherein the memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer program and execute the method for parsing the flash file of the automotive electronic control unit as in the first aspect or any possible design of the first aspect.

[0063] In a fourth aspect, a storage medium is provided, on which instructions are stored. When the instructions are executed on a computer, a method for parsing a flash file of the automotive electronic control unit as in the first aspect or any possible design of the first aspect is executed.

[0064] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, causes the computer to execute a method for parsing a flash file of an automotive electronic control unit as in the first aspect or any possible design of the first aspect.

[0065] Beneficial effects:

[0066] (1) The flash file provided by the present invention is an encrypted binary file, that is, it is stored in binary format. Thus, compared with the traditional hexadecimal file format, the parsed file occupies less space. At the same time, the file is in an encrypted state before parsing, thereby reducing the risk of data leakage during the parsing and transmission process, thereby improving data security. Furthermore, the flash file contains a file integrity check byte, which can be used to perform a file integrity check based on the check byte before parsing, thereby timely determining whether the file is damaged before parsing, thereby avoiding the problem of increased workload and waste of resources in traditional technologies that require the file to be parsed before knowing the file is damaged. In addition, the present invention can parse out detailed data of the ECU including flash information, actual flash data, user information and vehicle information, thereby obtaining detailed flash file information, thereby ensuring the accuracy of the flash. Based on this, the present invention is very suitable for large-scale application and promotion.

[0067] (2) The flash file provided by the present invention includes the number of flash data blocks, the address and length information of the flash data blocks; thus, when parsing, the detailed flash address of the actual flash data in each data block can be determined; based on this, the problem of not including the flash start address in the traditional technology, which easily causes data to be flashed to the wrong address, is avoided.

[0068] (3) It has scalability and forward compatibility. In particular, in the flash file provided by the present invention, except for the file header, all other data segments can be stored in any order at any position of the file, and the space size of each segment is not specified. In this way, when it is necessary to add extended information, it can be directly added based on the existing file format without worrying about the old format program making mistakes when parsing the new format file. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] Figure 1 A schematic flow chart of the steps of a method for analyzing a flash file of an automotive electronic control unit provided by an embodiment of the present invention;

[0070] Figure 2 A schematic diagram of the file structure of a flash file provided in an embodiment of the present invention;

[0071] Figure 3 A schematic diagram of the structure of a parsing device for flashing files of an automotive electronic control unit provided by an embodiment of the present invention;

[0072] Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0073] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in combination with the drawings and the description of the embodiments or the prior art. Obviously, the following description of the structure of the drawings is only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. It should be noted that the description of these embodiments is used to help understand the present invention, but does not constitute a limitation of the present invention.

[0074] It should be understood that although the terms first, second, etc. may be used herein to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another unit. For example, a first unit can be referred to as a second unit, and similarly, a second unit can be referred to as a first unit without departing from the scope of the exemplary embodiments of the present invention.

[0075] It should be understood that the term "and / or" that may appear in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can represent three situations: A exists alone, B exists alone, and A and B exist at the same time. The term " / and" that may appear in this article describes another type of association object relationship, indicating that two relationships may exist. For example, A / and B can represent two situations: A exists alone, and A and B exist alone. In addition, the character " / " that may appear in this article generally indicates that the previous and next associated objects are in an "or" relationship.

[0076] Example:

[0077] See also Figure 1 As shown, the parsing method of the flash file of the automotive electronic control unit provided in this embodiment is that the file is in an encrypted state before parsing, and it is possible to determine whether the file is damaged in time before parsing, so that the security of the data during the parsing transmission process can be guaranteed, and the problem that the traditional technology needs to parse the file completely before determining whether the file is damaged can be avoided; at the same time, the parsed file is a binary file, and it can be parsed to obtain detailed data of the ECU including the flash information, the actual flash data, the user information and the vehicle information; based on this, not only the occupied space of the parsed file can be reduced, but also the comprehensiveness of the parsed information can be guaranteed, thereby ensuring the accuracy of the ECU flashing; therefore, the method is very suitable for large-scale application and promotion in the field of ECU flashing parsing technology; among them, for example, the method can be but not limited to running on the flash file parsing end side, optionally, the flash file parsing end can be but not limited to a personal computer (personal computer, PC), it can be understood that the aforementioned execution subject does not constitute a limitation on the embodiment of the present application, and accordingly, the running steps of the method can be but not limited to the following steps S1 to S7.

[0078] S1. Obtain the flash file of the automobile electronic control unit, wherein the flash file is an encrypted binary file, and the flash file includes a file header, a flash information segment, a vehicle information segment, a user information segment and a flash data segment, and the file header includes an encryption type flag and a file integrity check byte; in a specific implementation, for example, the flash file may also include a custom segment, and the file header may also include but is not limited to a flash information segment offset, a vehicle information segment offset, a user information segment offset, a flash data block number, a flash data segment offset, a custom segment offset, a file type flag, a file format version number, a generation date, a generation time and a diagnostic system number (in this embodiment, the generation date includes the file generation year, the file generation month and the file generation day, and the generation time includes the file generation hour, the file generation minute and the file generation second); at the same time, for example, the flash information segment, the vehicle information segment and the user information segment respectively contain a number of data, and each data is set with a corresponding number of occupied bytes, so that the aforementioned information segments can be parsed based on the aforementioned number of occupied bytes, and the process is described in detail below.

[0079] In specific applications, this embodiment describes in detail each data in the flash file:

[0080] First, the order of arrangement of the data segments in the file header is: file type flag, encryption type flag, file integrity check byte, file format version number, information segment offset, vehicle information segment offset, user information segment offset, number of flash data blocks, flash data segment offset, generation date, generation time and diagnostic system number; and the composition of the entire file is: file header + flash information segment, vehicle information segment, user information segment, custom segment and flash data segment, the schematic diagram of which can be seen in Figure 2 shown.

[0081] At the same time, the number of bytes occupied by each type of data in the aforementioned file header and their functions are as follows:

[0082] File type flag, which occupies 4 bytes: used to quickly identify whether a file conforms to the current file format, generally should be "XRPM".

[0083] The encryption type flag occupies 4 bytes. It is used to indicate the encryption algorithm used in this file. For example, when the encryption type flag is 0x01020304, the corresponding encryption algorithm is the RC4 algorithm, which is a symmetric encryption algorithm that uses the same key for encryption and decryption operations. The key length is variable and ranges from 1 to 256 bytes. Of course, when the encryption type flag is other strings, the principle of determining the encryption algorithm and decryption algorithm is the same as the above example, so it will not be elaborated here.

[0084] The file integrity check byte occupies 4 bytes and is used to determine whether the file is complete. In this embodiment, the CRC32 check value is used as an example.

[0085] The version number of the file format occupies 4 bytes; it can be, but is not limited to, a decimal number in the format of yyyymmdd (year, month, day) and stored as a 4-byte unsigned integer; for example, a new version is determined on January 1, 2024, then the version number is set to 20240101 (decimal), and the corresponding hexadecimal representation is 0x0134D6E5; of course, the above examples are for illustration only and are not limited to this.

[0086] The flash information segment offset occupies 4 bytes and is used to determine the number of bytes offset from the file header to the "flash information segment".

[0087] The vehicle information segment offset occupies 4 bytes and is used to determine the number of bytes offset from the file header to the "vehicle information segment".

[0088] User information segment offset, which occupies 4 bytes; it is used to determine the number of bytes offset from the file header to the "user information segment".

[0089] The custom section offset occupies 4 bytes and is used to determine the number of bytes offset from the file header to the "custom section", where the custom section is the content added by the user.

[0090] The number of flash data blocks occupies 4 bytes and is used to indicate the number of data blocks in the "flash data segment". Since the addresses where the flash data is written into the chip are not necessarily continuous, there may be multiple discontinuous data blocks, so each data block should be stored separately and indicate their respective starting address and length.

[0091] The flash data segment offset occupies 4 bytes and is used to determine the number of bytes offset from the file header to the "flash data segment".

[0092] Generation date, which occupies 4 bytes: a decimal number in the format of yyyymmdd (year, month, day), stored as a 4-byte unsigned integer; for example, if the file is generated on January 1, 2024, the date is written as 20240101 (decimal), and the corresponding hexadecimal representation is 0x0134D6E5.

[0093] Generation time, which occupies 4 bytes: a decimal number in the hhmmss format (hour, minute, second), stored as a 4-byte unsigned integer; for example, if the file is generated at 18:29:42, the time is written as 182942 (decimal), and the corresponding hexadecimal representation is 0x0002CA9E.

[0094] Diagnostic system number, which occupies 48 bytes; it represents the software program number that generates the file. There is no limitation on the writing format, and ASCII character set encoding is usually used.

[0095] Furthermore, the flashing information segment described in the example may include but is not limited to: ECU model, ECU ID, ECU hardware ID, ECU hardware version number, ECU software ID, ECU software version number, ECU boot version, ECU calibration identification code, ECU code, system vendor ID, system vendor hardware number, system vendor hardware version number, system vendor software number and system vendor software version number; wherein the aforementioned ECU model, ECUID and other information are respectively taken as one piece of data, and each piece of data is set with a corresponding number of occupied bytes.

[0096] Similarly, the vehicle information segment includes vehicle brand, vehicle model, vehicle VIN, manufacturing year and month, engine model and engine serial number, while the user information segment may include but is not limited to user registration mobile phone number, diagnostic platform type, VDI model, VDI SN code, hardware version, factory date, boot version number, app version number and chip ID; among them, VDI stands for Vehicle Diagnos is Interface, which means vehicle diagnostic interface, which is a hardware device used to connect ECU and diagnostic software, and supports multiple vehicle network communication protocols such as CAN and RS485.

[0097] Specifically, the specific number of bytes occupied by the content contained in each of the aforementioned information segments is disclosed below.

[0098] The flash information segment contains the following:

[0099] ECU model, which occupies 20 bytes, is ASCII character encoding and is customized by the ECU manufacturer.

[0100] ECU ID, which occupies 20 bytes, is ASCII character encoding and is customized by the ECU manufacturer.

[0101] ECU hardware ID, which occupies 20 bytes, is ASCII character encoded and is customized by the ECU manufacturer.

[0102] ECU hardware version number, which occupies 20 bytes, is ASCII character encoded and is customized by the ECU manufacturer.

[0103] ECU software ID, which occupies 20 bytes, is ASCII character encoded and is customized by the ECU manufacturer.

[0104] ECU software version number, which occupies 20 bytes, is ASCII character encoded and is set by the ECU manufacturer.

[0105] The boot version of the ECU occupies 20 bytes, is ASCII character encoded, and is set by the ECU manufacturer.

[0106] The ECU calibration identification code occupies 20 bytes, is ASCII character encoded, and is set by the ECU manufacturer.

[0107] ECU code, which occupies 20 bytes, is ASCII character encoding and is customized by the ECU manufacturer.

[0108] System supplier ID, which occupies 20 bytes, is ASCII character encoding and is customized by the ECU manufacturer.

[0109] System vendor hardware number, which occupies 20 bytes, is ASCII character encoded and is set by the ECU manufacturer.

[0110] System vendor hardware version number, which occupies 20 bytes, is ASCII character code and is set by the ECU manufacturer.

[0111] System vendor software number, which occupies 20 bytes, is ASCII character encoded and is set by the ECU manufacturer.

[0112] System vendor software version number, which occupies 20 bytes, is ASCII character encoding and is customized by the ECU manufacturer.

[0113] Similarly, the vehicle information segment includes the following:

[0114] Vehicle brand, which occupies 20 bytes. The encoding format is not required and is usually encoded in ASCII characters.

[0115] Vehicle model, which occupies 20 bytes and is ASCII character code.

[0116] Vehicle VIN, which occupies 20 bytes: It is ASCII character encoding, and each vehicle's code is unique.

[0117] The year and month of manufacturing occupies 20 bytes and is ASCII character encoding. For example, January 1, 2024 is represented as "20240101".

[0118] Engine model, which occupies 20 bytes and is ASCII character code.

[0119] Engine serial number, which occupies 20 bytes: ASCII character encoding.

[0120] The user information section contains the following:

[0121] The user's registered mobile phone number occupies 20 bytes and is encoded in ASCII characters, for example, "18312345678".

[0122] Diagnostic platform type, which occupies 20 bytes: it is ASCII character encoding, the model of the software that generated the current file, usually the software model of the diagnostic instrument software.

[0123] VDI model, which occupies 20 bytes. It is ASCII character code and is customized by the diagnostic instrument manufacturer.

[0124] The SN code of VDI occupies 20 bytes and is an ASCII character code, which is customized by the diagnostic instrument manufacturer.

[0125] Hardware version, which occupies 20 bytes: It is ASCII character code and is customized by the diagnostic instrument manufacturer.

[0126] The date of manufacture occupies 20 bytes and is encoded in ASCII characters. For example, January 1, 2024 is represented as "20240101".

[0127] The boot version number occupies 20 bytes and is ASCII character encoded and is customized by the diagnostic instrument manufacturer.

[0128] The app version number occupies 60 bytes and is encoded in ASCII characters. It is customized by the diagnostic instrument manufacturer.

[0129] Chip ID, which occupies 40 bytes and is ASCII character code, for example, "ABCDEFGH12345678".

[0130] The custom section occupies 12 bytes and its content is customized by the user.

[0131] The flash data segment contains the following:

[0132] The starting address of the flash data block occupies 4 bytes, for example, 0x1234ABCD (hexadecimal).

[0133] The data length occupies 4 bytes, for example, 0x00001234 (hexadecimal).

[0134] Data: The actual flash data, stored in the form of a single byte. The byte length refers to the "data length".

[0135] In this way, based on the above description of the file structure of the flash file, file analysis can be performed based on the above file structure; wherein, for example, a structure table of the above flash file is provided in the flash file analysis terminal, and the table contains the specific content of the above file structure (such as the number of bytes occupied by different byte numbers, the meaning represented, etc.); in this way, file analysis can be completed based on this, and the process can be but not limited to the following steps S2 to S7.

[0136] Among them, before performing step S2, that is, before determining the decryption method, it is necessary to first obtain the file occupied capacity of the flash file; then, determine whether the file occupied capacity is greater than or equal to the minimum occupied capacity; among them, if it is greater than or equal to the minimum occupied capacity, perform file format verification, otherwise, output file error prompt information.

[0137] In this embodiment, since some fixed contents are specified in the file format, the file size must not be less than the minimum occupied capacity. If it is less than this, it indicates that the file is wrong. At this time, an error prompt message can be output and parsing can be stopped to avoid wasting parsing resources. At the same time, the minimum occupied capacity can be, but is not limited to, 817 bytes. Of course, it can be set according to the specific usage scenario and is not limited to the aforementioned example.

[0138] At the same time, if the capacity occupied by the file meets the above conditions, a file format check is required, that is, obtaining the file type flag in the file header (that is, reading the first 4 bytes in the flash file); then, according to the file type flag, determine the file type of the flash file; then, determine whether the file type is a preset type; if so, execute the following step S2, otherwise, output a file type error prompt message and stop parsing; wherein, the preset type can be specifically set according to actual use and is not specifically limited here.

[0139] In this way, after completing the aforementioned file size and format verification, the file can be decrypted, and the process can be but not limited to the following steps S2 and S3.

[0140] S2. Determine the decryption method of the flash file based on the encryption type flag in the file header of the flash file; in the specific implementation, it has been explained above that the encryption type flag is used to indicate the encryption algorithm adopted by the file, therefore, the 5th to 8th bytes in the flash file can be used as the encryption type flag; then, the encryption method of the file can be determined based on the encryption type flag; finally, the decryption method of the flash file can be determined based on the encryption method.

[0141] After the decryption method is determined, the decryption method can be used to perform decryption processing on the flash file, and the process can be but is not limited to the following step S3.

[0142] S3. Decrypt the flash file using the decryption method to obtain a decrypted file. In this embodiment, encryption and decryption can use common methods, which are not limited here.

[0143] After the decrypted file is obtained, a file integrity check may be performed to prevent the file from being damaged, and the process may be, but is not limited to, as shown in the following step S4.

[0144] S4. Parse the file header in the decrypted file to obtain the file integrity check byte in the file header; in specific application, it is equivalent to reading the 9th to 12th bytes in the decrypted file, and then using the 9th to 12th bytes as the file integrity check bytes; then, based on this, the file integrity check can be performed, and the process can be but not limited to as shown in the following step S5.

[0145] S5. Use the file integrity check byte to determine whether the decrypted file is a complete file. In this embodiment, for example, all bytes in the entire decrypted file except the file integrity check byte are subjected to CRC32 calculation to obtain a CRC32 value. Then, the obtained CRC32 value is compared with the file integrity check byte. If the comparison results are the same, it means that the file is complete, otherwise, the file is defective.

[0146] If it is determined that the decrypted file is not a complete file, a file damage prompt message may be output and the parsing process may be terminated; otherwise, file parsing is required, and the process may be, but is not limited to, as shown in the following step S6.

[0147] S6. If yes, parse the flash information segment, vehicle information segment, user information segment and flash data segment in the decrypted file to obtain the flash information, vehicle information, user information and actual flash data of the vehicle electronic control unit respectively; in this embodiment, for example, before performing step S6, it is also necessary to determine the version number of the flash file based on the version number of the file format in the file header, that is, read the 13th to 16th bytes in the decrypted file, and then use it as the version number of the flash file, so as to determine what version the current file format is based on this.

[0148] After the version number of the file is determined, the aforementioned flash information segment, vehicle information segment, user information segment and flash data segment may be parsed, and the process may be but is not limited to the following steps S61 to S66.

[0149] S61. Parse the file header in the decrypted file to obtain the flash information segment offset, the vehicle information segment offset, the user information segment offset, the number of flash data blocks and the flash data segment offset; in this embodiment, the 17th to 20th bytes of the decrypted file are read as the flash information segment offset, the 21st to 24th bytes of the decrypted file are read as the vehicle information segment offset, the 25th to 28th bytes of the decrypted file are read as the user information segment offset, the 29th to 32nd bytes of the decrypted file are read as the custom segment offset, the 33rd to 36th bytes of the decrypted file are read as the flash data block, and the 37th to 40th bytes of the decrypted file are read as the flash data segment offset; in this way, after obtaining the offsets of the aforementioned information segments, the starting positions of the flash information segment, the vehicle information segment, the user information segment and the flash data segment in the file can be determined based on this, and the process can be but is not limited to the following step S62.

[0150] S62. According to the flash information segment offset, determine the starting position of the flash information segment in the decrypted file, according to the vehicle information segment offset, determine the starting position of the vehicle information segment in the decrypted file, according to the user information segment offset, determine the starting position of the user information segment in the decrypted file, and according to the flash data segment offset, determine the starting position of the flash data segment in the decrypted file; in the specific implementation, the flash information segment offset is taken as an example for explanation, and the process can be but not limited to the following steps S62a and S62b as shown.

[0151] S62a. Obtain the number of occupied bytes corresponding to the offset of the flash information segment, and convert the obtained number of occupied bytes into an unsigned integer; in the present embodiment, it is equivalent to parsing the 4 bytes corresponding to the offset of the flash information segment into an unsigned integer type, and then, based on this, determining the starting file of the flash information segment in the decrypted file; wherein, the process of determining the starting position can be but is not limited to as shown in the following step S62b.

[0152] S62b. Determine the starting position of the flash information segment in the decrypted file based on the unsigned integer. In this embodiment, the unsigned integer is taken as n0, then the n0th byte of the decrypted file is used as the starting position of the flash information segment, starting from the beginning of the decrypted file.

[0153] Therefore, through the aforementioned steps S62a and S62b, the starting positions of the flash information segment, vehicle information segment, user information segment and flash data segment in the file can be determined; then, based on this, the aforementioned information segments and data segments can be parsed and processed, and the process can be but is not limited to the following steps S63 to S66.

[0154] S63. Based on the starting position of the flash information segment in the decrypted file, the flash information segment is parsed to obtain the flash information; in specific implementation, for example, but not limited to, the following steps S63a and S63b can be used to obtain the aforementioned flash information.

[0155] S63a. Taking the starting position of the flash information segment in the decrypted file as the starting point, the data in the flash information segment are read in sequence according to the number of occupied bytes corresponding to each data in the flash information segment to obtain multiple read data; in the specific implementation, it has been explained above that the flash information segment contains the ECU model, ECU ID, ECU hardware ID, ECU hardware version number, etc., and each data corresponds to the number of occupied bytes, so the file is parsed according to the number of occupied bytes; for example, starting from the starting position of the flash information segment, 20 bytes are read as the first data, that is, the ECU model; then, after the first reading of 20 bytes, another 20 bytes are read to obtain the ECUID; in this way, according to this principle, the data parsing of the flash information segment can be completed to obtain multiple read data; therefore, the aforementioned parsing process is essentially: starting from the starting position of the flash information segment, the data is read cyclically, 20 bytes are read each time, which is a complete message, until all bytes in the flash information segment are polled.

[0156] After obtaining a plurality of read data, the plurality of read data can be used to form the aforementioned flash information, and the process is shown in the following step S63b.

[0157] S63b. Use multiple read data to form the flash information.

[0158] In this way, through the aforementioned steps S63a and S63b, the parsing of the flash information segment can be completed; then, using the same principle, the parsing of the vehicle information segment and the user information segment can be completed, and the process is shown in the following steps S64 and S65.

[0159] S64. According to the starting position of the vehicle information segment in the decrypted file, the vehicle information segment is parsed to obtain the vehicle information; in this embodiment, the data is still read in a loop starting from the starting position of the vehicle information segment, 20 bytes are read each time, which is a complete piece of information, until all bytes in the vehicle information segment are polled, multiple pieces of vehicle data can be obtained, and the vehicle information is composed of multiple pieces of vehicle data.

[0160] S65. Utilize the starting position of the user information segment in the decrypted file to parse the user information segment to obtain the user information. In specific applications, data is read cyclically starting from the starting position of the user information segment. The number of bytes read each time can refer to the aforementioned step S1. In this way, all bytes in the user information segment are polled and the user information can be obtained.

[0161] After completing the parsing of the user information segment, the custom segment can be parsed. The process is the same as the parsing process of the flash information segment mentioned above, and will not be repeated here.

[0162] After completing the analysis of the custom segment, the analysis of the flash data segment may be performed, and the process may be, but is not limited to, as shown in the following step S66.

[0163] S66. According to the starting position of the flash data segment in the decrypted file and the number of the flash data blocks, the flash data segment is parsed to obtain the actual flash data; in this embodiment, it has been explained above that the number of flash data blocks is also set in the file header, that is, the flash data segment contains p data blocks, and p is equal to the number of flash data blocks; optionally, the 33rd to 36th bytes in the decrypted file are converted to an unsigned integer type to obtain the number of flash data blocks;

[0164] Based on this, the flash data segment can be parsed according to the number of flash data blocks and the starting position corresponding to the flash data segment. The specific process can be but is not limited to the following steps S66a to S66e.

[0165] S66a. For the i-th data block in the flash data segment, take the end point of the i-1-th data block as the starting point, read n bytes after the starting point, and use n bytes to determine the starting address of the flash data block in the i-th data block, wherein n is the number of bytes occupied by the starting address of the flash data block in the i-th data block in the decrypted file, and when i is 1, the end point of the i-1-th data block is the starting position of the flash data segment in the decrypted file; in this embodiment, for the first data block in the flash data segment, it is equivalent to reading n bytes from the starting position of the flash data segment as its corresponding starting address, and then, on this basis, continue reading to obtain the data length of the actual flash data in the first data block; optionally, the data length determination process can be but is not limited to the following step S66b.

[0166] S66b. After reading n bytes, continue to read m bytes after n bytes to determine the data length of the actual flush data in the i-th data block based on the read m bytes, wherein m is the data length of the actual flush data in the i-th data block, the number of bytes occupied in the decrypted file; in a specific implementation, assuming that the starting position of the flush data segment is the 80th byte and n is 5, then, starting from the 86th byte, m bytes are read to determine the data length of the actual flush data in the first data block based on the read m bytes; optionally, if m is 4, then bytes 86-89 are converted to unsigned integers as the data length.

[0167] After the data length is obtained, the actual write data in the first data block can be read based on the data length, and the process can be but not limited to the one shown in the following step S66c.

[0168] S66c. After reading m bytes, continue to read k bytes after m bytes to use the read k bytes as the actual flash data in the i-th data block, wherein k is the data length of the actual flash data in the i-th data block; in this embodiment, assuming that the data length is 20 bytes, then 20 bytes will be read starting from the 90th byte as the actual flash data of the first data block.

[0169] After completing the parsing of the first data block, the second data block can be parsed, that is, starting from the end point of the first data block, and continuing to read data according to the above principle after the starting point until all data blocks are read. At this time, the starting address and actual write data of the write data block corresponding to each data block can be obtained; wherein, the cyclic parsing process can be but is not limited to as shown in the following step S66d.

[0170] S66d. Add 1 to i, and start again with the end point of the i-1th data block, read n bytes after the starting point, until i is equal to p, to obtain the starting address of the flash data block and the actual flash data in each data block, where the initial value of i is 1; in this embodiment, based on the above example, the end point in the first data block is the 110th byte, then the second data block starts with the 110th byte, and starts reading data after the 110th byte, that is, starting from the 111th byte, read n bytes, so that, according to this principle, the parsing of the flash data segment can be completed; then, the data obtained by parsing can be used to form the actual flash data, and the process can be but not limited to as shown in the following step S66e.

[0171] S66e. Use the starting address of the flash data block in each data block and the actual flash data to compose the flash actual data.

[0172] Thus, through the aforementioned steps S61 to S66 and their sub-steps, the flashing information, vehicle information, user information and actual flashing data of the automobile electronic control unit can be obtained; then, the generation date, generation time and diagnostic system number can be parsed, that is, the 41st to 44th bytes in the decrypted file are read as the generation date, and the 45th to 48th bytes in the decrypted file are read as the generation time; similarly, the 49th to 96th bytes in the decrypted file are read as the diagnostic system number; finally, the data obtained by the aforementioned analysis can be combined to generate the analysis result of the file, and the process can be but is not limited to as shown in the following step S7.

[0173] S7. Generate a parsing result of the flashing file of the automotive electronic control unit by using the flashing information, vehicle information, user information and actual flashing data of the automotive electronic control unit; in this embodiment, the parsing result is essentially composed of the version number, generation date, generation time and diagnostic system number of the flashing file, as well as the flashing information, vehicle information, user information and actual flashing data of the automotive electronic control unit.

[0174] Thus, through the above explanation, the analysis process of the present invention can be summarized as follows:

[0175] Step 1: First determine whether the file size is greater than or equal to the minimum value required by the file format; since the file format stipulates some fixed contents, the file size must not be less than this minimum value, and the minimum value obtained by calculation is 817 bytes; if the above conditions are met, proceed to step 2.

[0176] Step 2: Read the first 4 bytes of the file and determine whether they are "0x58, 0x52, 0x50, 0x4D". The corresponding ASCII code is "XRPM". If it does not match, it means that the file is not in this format; if it matches, go to step 3.

[0177] Step 3: Read the 5th to 8th bytes of the file, which is the encryption type flag. The 4 bytes are used to determine which encryption algorithm is used, so as to derive the decryption algorithm based on the determined encryption algorithm and decrypt the file. After the decryption is completed, proceed to the following step 4.

[0178] Step 4: Read the 9th to 12th bytes of the file, which are the file integrity check bytes; perform CRC32 calculation on all bytes except these 4 bytes, and compare the obtained CRC32 value with the file integrity check byte. If the results are consistent, it means that the file is complete, otherwise, it means that the file is defective; after the file integrity check passes, proceed to the following step 5.

[0179] Step 5: Read the 13th to 16th bytes of the file, which is the version number of the file format. This version number is used to determine the version of the current file format.

[0180] Step 6: Read the 17th to 20th bytes of the file, which is the offset of the flash information segment. Parse these 4 bytes into an unsigned integer in little-endian format, represented by n0. Then the n0th byte from the beginning of the file is the flash information segment (that is, the starting position of the flash information segment). The length of the flash information segment is fixed at 280 bytes.

[0181] Step 6.1: Based on the flash information segment offset obtained above, now start parsing the flash information.

[0182] Step 6.2: Starting from the starting position of the flash information segment, read the data in a loop, reading 20 bytes each time, which is a complete message. The exact meaning of the information is described above; in this way, after completing the parsing of the flash information segment, the vehicle information segment can be parsed, as shown in the following step 7.

[0183] Step 7: Read bytes 21-24 of the file, which is the vehicle information segment offset. Refer to step 6 to find the vehicle information segment, which has a fixed length of 120 bytes.

[0184] Step 7.1: Based on the vehicle information segment offset obtained above, now start parsing the vehicle information.

[0185] Step 7.2: Starting from the beginning of the vehicle information segment, read the data in a loop, reading 20 bytes each time, which is a complete message. The exact meaning of the information is described above.

[0186] After the vehicle information segment is parsed, the user information segment may be parsed, and the process is shown in step 8 below.

[0187] Step 8: Read bytes 25-28 of the file, which is the offset of the user information segment. Refer to step 6 to find the user information segment, which has a fixed length of 300 bytes.

[0188] Step 8.1: Based on the user information segment offset obtained above, start parsing the user information.

[0189] Step 8.2: Starting from the start position of the user information segment, read the data in a loop. The length of the data read each time is described above. Each read is a complete piece of information. The exact meaning of the information is described above.

[0190] Next, the custom segment can be parsed, as shown in step 9 below.

[0191] Step 9: Read bytes 29-32 of the file, which is the custom segment offset. Refer to step 6 to find the custom segment, which has a fixed length of 12 bytes.

[0192] Similarly, after completing the analysis of the custom segment, the analysis of the flash data segment can be performed, and the process is shown in the following steps 10 and 11.

[0193] Step 10: Read bytes 33-36 of the file, which is the number of data blocks to be written. Parse these 4 bytes into an unsigned integer in little-endian format to obtain the number of data blocks to be written.

[0194] Step 11: Read bytes 37-40 of the file, which is the offset of the flash data segment. Refer to step 6 to find the flash data segment, the length of which is not fixed. When there are multiple blocks of flash data, these blocks are stored continuously in the flash data segment according to the starting address size.

[0195] Step 11.1: Get the number of data blocks to be written from step 10, represented by n2 here. The following steps 11.2 to 11.5 need to be executed in a loop n2 times.

[0196] Step 11.2: Based on the flash data segment offset obtained above, now start parsing the flash data.

[0197] Step 11.3: Starting from the start position of the flash data segment, read 4 bytes and parse them into an unsigned integer in little-endian format, which is the flash start address of the current flash data block.

[0198] Step 11.4: Continue reading 4 bytes from above and parse them into unsigned integers in little-endian format, which is the flash length of the current flash data block, represented by n1 here.

[0199] Step 11.5: According to the data length obtained above, continue to read n1 bytes, which is the actual flash data in the current flash data block.

[0200] In this way, by repeating the aforementioned steps 11.2 to 11.5, the parsing of the flash data segment can be completed, and then the production date, production time and diagnostic system number can be parsed, and the process is shown in the following steps 12 and S13.

[0201] Step 12: Read bytes 41-44 and bytes 45-48 of the file, which are the generation date and generation time, and parse these two groups of 4 bytes into unsigned integers in little-endian format and express them in decimal.

[0202] Step 13: Read bytes 49-96 of the file, which is the diagnostic system number. Refer to the previous description for parsing method.

[0203] Step 14: At this point, all files have been parsed.

[0204] Therefore, through the detailed description of the parsing method of the flash file of the automobile electronic control unit, the file is in an encrypted state before parsing in the present invention, and it is possible to determine whether the file is damaged in time before parsing. In this way, the security of the data during the parsing and transmission process can be guaranteed, and the problem that the traditional technology needs to parse the file completely before determining whether the file is damaged can be avoided; at the same time, the parsed file is a binary file, and it can be parsed to obtain detailed data of the ECU including the flash information, the actual flash data, the user information and the vehicle information; based on this, not only the space occupied by the parsed file can be reduced, but also the comprehensiveness of the parsed information can be guaranteed, thereby ensuring the accuracy of the ECU flashing; therefore, the present invention is very suitable for large-scale application and promotion in the field of ECU flashing and parsing technology.

[0205] like Figure 3 As shown, the second aspect of this embodiment provides a hardware device for implementing the method for parsing the flash file of the automotive electronic control unit described in the first aspect of the embodiment, including:

[0206] An acquisition unit, used for acquiring a flash file of a vehicle electronic control unit, wherein the flash file is an encrypted binary file, the flash file includes a file header, a flash information segment, a vehicle information segment, a user information segment and a flash data segment, and the file header includes an encryption type flag and a file integrity check byte;

[0207] A decryption unit, configured to determine a decryption method of the flash file based on an encryption type flag in a file header of the flash file;

[0208] The decryption unit is further used to decrypt the flash file using the decryption method to obtain a decrypted file;

[0209] A parsing unit, used for parsing a file header in the decrypted file to obtain a file integrity check byte in the file header;

[0210] A parsing unit, used to determine whether the decrypted file is a complete file by using the file integrity check bytes;

[0211] If yes, the parsing unit is used to parse the flashing information segment, the vehicle information segment, the user information segment and the flashing data segment in the decrypted file to obtain the flashing information, the vehicle information, the user information and the flashing actual data of the automobile electronic control unit respectively;

[0212] The parsing unit is also used to generate a parsing result of the flashing file of the automotive electronic control unit by using the flashing information, vehicle information, user information and actual flashing data of the automotive electronic control unit.

[0213] The working process, working details and technical effects of the device provided in this embodiment can be found in the first aspect of the embodiment and will not be described in detail here.

[0214] like Figure 4 As shown, the third aspect of this embodiment provides another device for parsing the flash file of an automotive electronic control unit. Taking the device as an electronic device as an example, it includes: a memory, a processor and a transceiver that are communicatively connected in sequence, wherein the memory is used to store computer programs, the transceiver is used to send and receive messages, and the processor is used to read the computer program to execute the method for parsing the flash file of the automotive electronic control unit as described in the first aspect of the embodiment.

[0215] For example, the memory may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out memory (FIFO) and / or first-in-last-out memory (FILO), etc. Specifically, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). At the same time, the processor may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state.

[0216] In some embodiments, the processor may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. For example, the processor may not be limited to a microprocessor of the STM32F105 series, a reduced instruction set computer (RISC) microprocessor, an X86 or other architecture processor, or a processor with an integrated embedded neural network processor (NPU); the transceiver may be, but is not limited to, a wireless fidelity (WIFI) wireless transceiver, a Bluetooth wireless transceiver, a general packet radio service technology (Genera l Packet Rad ioService, GPRS) wireless transceiver, a ZigBee protocol (a low-power LAN protocol based on the IEEE 802.15.4 standard, ZigBee) wireless transceiver, a 3G transceiver, a 4G transceiver and / or a 5G transceiver, etc. In addition, the device may also include, but is not limited to, a power module, a display screen and other necessary components.

[0217] The working process, working details and technical effects of the electronic device provided in this embodiment can be found in the first aspect of the embodiment and will not be described in detail here.

[0218] The fourth aspect of this embodiment provides a storage medium that stores instructions for the method for parsing the flash file of the automotive electronic control unit described in the first aspect of the embodiment, that is, the storage medium stores instructions, and when the instructions are run on a computer, the method for parsing the flash file of the automotive electronic control unit described in the first aspect of the embodiment is executed.

[0219] The storage medium refers to a carrier for storing data, which may include but is not limited to a floppy disk, a CD, a hard disk, a flash memory, a USB flash drive and / or a memory stick, etc. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0220] The working process, working details and technical effects of the storage medium provided in this embodiment can be found in the first aspect of the embodiment and will not be described in detail here.

[0221] The fifth aspect of this embodiment provides a computer program product comprising instructions, which, when executed on a computer, causes the computer to execute the method for parsing the flash file of the automotive electronic control unit as described in the first aspect of the embodiment, wherein the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0222] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for parsing a flash file of an automotive electronic control unit, characterized in that: include: Obtaining a flash file of the automobile electronic control unit, wherein the flash file is an encrypted binary file, the flash file includes a file header, a flash information segment, a vehicle information segment, a user information segment, and a flash data segment, and the file header includes an encryption type flag and a file integrity check byte; Determining a decryption method for the flash file based on an encryption type flag in a file header of the flash file; Decrypting the flash file using the decryption method to obtain a decrypted file; Parsing the file header in the decrypted file to obtain the file integrity check byte in the file header; Using the file integrity check bytes, determining whether the decrypted file is a complete file; If yes, parse the flashing information segment, vehicle information segment, user information segment and flashing data segment in the decrypted file to obtain the flashing information, vehicle information, user information and flashing actual data of the automobile electronic control unit respectively; The flashing information, vehicle information, user information and actual flashing data of the automobile electronic control unit are used to generate a parsing result of the flashing file of the automobile electronic control unit.

2. The method according to claim 1, characterized in that The file header also includes: a flash information segment offset, a vehicle information segment offset, a user information segment offset, a flash data block number and a flash data segment offset; After determining that the decrypted file is a complete file, the method further includes: Parse the file header in the decrypted file to obtain the flash information segment offset, the vehicle information segment offset, the user information segment offset, the number of flash data blocks, and the flash data segment offset; Correspondingly, parsing the flashing information segment, vehicle information segment, user information segment and flashing data segment in the decrypted file to obtain the flashing information, vehicle information, user information and flashing actual data of the automotive electronic control unit respectively includes: Determine the starting position of the flash information segment in the decrypted file according to the flash information segment offset, determine the starting position of the vehicle information segment in the decrypted file according to the vehicle information segment offset, determine the starting position of the user information segment in the decrypted file according to the user information segment offset, and determine the starting position of the flash data segment in the decrypted file according to the flash data segment offset; Based on the starting position of the flash information segment in the decrypted file, the flash information segment is parsed to obtain the flash information; According to the starting position of the vehicle information segment in the decrypted file, the vehicle information segment is parsed to obtain the vehicle information; Utilizing the starting position of the user information segment in the decrypted file, parsing the user information segment to obtain the user information; and According to the starting position of the flash data segment in the decrypted file and the number of the flash data blocks, the flash data segment is parsed to obtain the actual flash data.

3. The method according to claim 2, characterized in that The flash information segment, the vehicle information segment and the user information segment respectively contain a number of pieces of data, and each piece of data is provided with a corresponding number of occupied bytes; Wherein, determining the starting position of the flash information segment in the decrypted file according to the flash information segment offset includes: Obtain the number of occupied bytes corresponding to the offset of the flash information segment, and convert the obtained number of occupied bytes into an unsigned integer; Determine the starting position of the flash information segment in the decrypted file according to the unsigned integer; Correspondingly, based on the starting position of the flash information segment in the decrypted file, the flash information segment is parsed to obtain the flash information, which includes: Taking the starting position of the flash information segment in the decrypted file as the starting point, and reading the data in the flash information segment in sequence according to the number of occupied bytes corresponding to each piece of data in the flash information segment, so as to obtain a plurality of read data; The flash information is composed of a plurality of read data.

4. The method according to claim 3, characterized in that The flash data segment includes p data blocks, and p is equal to the number of the flash data blocks; The flashing data segment is parsed and processed according to the starting position of the flashing data segment in the flashing file and the number of the flashing data blocks to obtain the flashing actual data, including: For the i-th data block in the flash data segment, take the end point of the i-1-th data block as the starting point, read n bytes after the starting point, and use n bytes to determine the starting address of the flash data block in the i-th data block, where n is the number of bytes occupied by the starting address of the flash data block in the i-th data block in the decrypted file, and when i is 1, the end point of the i-1-th data block is the starting position of the flash data segment in the decrypted file; After reading n bytes, continue to read m bytes after n bytes, so as to determine the data length of the actual flush data in the i-th data block based on the read m bytes, wherein m is the data length of the actual flush data in the i-th data block, and the number of bytes occupied in the decrypted file; After reading m bytes, continue to read k bytes after m bytes, so as to use the read k bytes as the actual write data in the i-th data block, wherein k is the data length of the actual write data in the i-th data block; Add 1 to i, and start from the end of the i-1th data block again, read n bytes after the starting point, until i equals p, and get the starting address and actual writing data of each data block, where the initial value of i is 1; The actual flash data is composed by using the starting address of the flash data block in each data block and the actual flash data.

5. The method according to claim 1, characterized in that Before determining the decryption method of the flash file based on the encryption type flag in the file header of the flash file, the method further includes: Obtain the file occupied capacity of the flash file; Determine whether the file occupied capacity is greater than or equal to the minimum occupied capacity; If so, the decryption method of the flash file is determined based on the encryption type flag in the file header of the flash file; otherwise, a file error prompt message is output.

6. The method according to claim 1, characterized in that The file header also includes: a file type flag, a version number of the file format, a generation date, a generation time, and a diagnostic system number, wherein the generation date includes the file generation year, file generation month, and file generation day, and the generation time includes the file generation hour, file generation minute, and file generation second; After obtaining the flash file of the automobile electronic control unit, the method further includes: Obtain the file type flag in the file header; Determining the file type of the flash file according to the file type flag; Determine whether the file type is a preset type; If yes, determining the decryption method of the flash file based on the encryption type flag in the file header of the flash file; Correspondingly, after determining that the decrypted file is a complete file, the method further includes: Continue to parse the file header to obtain the version number, generation date, generation time and diagnostic system number of the flash file, so as to use the version number, generation date, generation time and diagnostic system number of the flash file, as well as the flash information, vehicle information, user information and actual flash data of the automotive electronic control unit to form the parsing result.

7. The method according to claim 1, characterized in that The file header also includes: a custom section offset, and the flash file also includes a custom section; The flash information segment includes ECU model, ECU ID, ECU hardware ID, ECU hardware version number, ECU software ID, ECU software version number, ECU boot version, ECU calibration identification code, ECU code, system vendor ID, system vendor hardware number, system vendor hardware version number, system vendor software number and system vendor software version number; The vehicle information segment includes vehicle brand, vehicle model, vehicle VIN, manufacturing year and month, engine model and engine serial number; the user information segment includes user registration mobile phone number, diagnostic platform type, VDI model, VDI SN code, hardware version, factory date, boot version number, app version number and chip ID.

8. A device for analyzing flash files of an automobile electronic control unit, characterized in that: include: An acquisition unit, used for acquiring a flash file of a vehicle electronic control unit, wherein the flash file is an encrypted binary file, the flash file includes a file header, a flash information segment, a vehicle information segment, a user information segment and a flash data segment, and the file header includes an encryption type flag and a file integrity check byte; A decryption unit, configured to determine a decryption method of the flash file based on an encryption type flag in a file header of the flash file; The decryption unit is further used to decrypt the flash file using the decryption method to obtain a decrypted file; A parsing unit, used for parsing a file header in the decrypted file to obtain a file integrity check byte in the file header; A parsing unit, used to determine whether the decrypted file is a complete file by using the file integrity check bytes; If yes, the parsing unit is used to parse the flashing information segment, the vehicle information segment, the user information segment and the flashing data segment in the decrypted file to obtain the flashing information, the vehicle information, the user information and the flashing actual data of the automobile electronic control unit respectively; The parsing unit is also used to generate a parsing result of the flashing file of the automotive electronic control unit by using the flashing information, vehicle information, user information and actual flashing data of the automotive electronic control unit.

9. An electronic device, characterized in that: include: A memory, a processor and a transceiver which are sequentially connected in communication, wherein the memory is used to store a computer program, the transceiver is used to send and receive messages, and the processor is used to read the computer program, and execute the method for parsing the flash file of the automotive electronic control unit as described in any one of claims 1 to 7.

10. A computer program product comprising instructions, characterized in that When the instruction is executed on a computer, the computer is caused to execute the method for analyzing the flash file of the automotive electronic control unit as claimed in any one of claims 1 to 7.

Images