Verification methods, verification devices, electronic equipment and storage media

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for verifying image files. It enables verification of image files during the boot loading phase, ensuring the integrity and consistency of the image files downloaded to the boot partition. The verification method includes: during the boot loading phase, obtaining a first verification value corresponding to the original file from a verification file in the boot partition, wherein the original file is an image file locally stored on the electronic device; calculating a second verification value corresponding to a target file, wherein the target file is the file after the original file has been downloaded to the boot partition; and verifying the target file based on the first and second verification values ​​to obtain a verification result.

Description

Technical Field

[0001] This application relates to the field of document verification technology, and in particular to verification methods, verification devices, electronic devices and storage media, wherein the verification method is used to verify image files. Background Technology

[0002] Smart devices such as mobile phones and smartwatches require three separate stages to boot up: the boot process, the kernel startup process, and the application system startup process. The boot process is also known as the boot loading process.

[0003] During the boot loading phase, the smart terminal loads or downloads the image file required for booting from the local machine to the boot partition in memory to guide the smart terminal to execute the boot process.

[0004] In related technologies, during the download process of the image file from the local machine to the boot partition in memory, the data in the image file may change, causing the image file to malfunction during the boot loading stage, ultimately resulting in the smart terminal failing to boot normally. Summary of the Invention

[0005] Therefore, in response to the above problems, this application proposes a method, device, electronic device, and storage medium for verifying image files, which can verify image files during the boot loading stage to ensure the integrity and consistency of image files downloaded to the boot partition.

[0006] Firstly, this application provides a verification method for verifying image files, including:

[0007] During the boot loading phase, the first checksum corresponding to the original file is obtained from the checksum file in the boot partition, where the original file is the image file stored locally on the electronic device;

[0008] Calculate the second checksum corresponding to the target file, where the target file is the file after the original file has been downloaded to the boot partition;

[0009] The target file is verified based on the first and second check values ​​to obtain the verification result.

[0010] Optionally, in one possible implementation of the first aspect, the above verification method further includes:

[0011] Using a verification algorithm, calculate the first verification value corresponding to the original file, with one first verification value corresponding to one original file;

[0012] A verification file is generated based on the first verification value, wherein the verification file includes at least one first verification value;

[0013] When the original file is downloaded to the boot partition, the verification file is also downloaded to the boot partition.

[0014] Optionally, in one possible implementation of the first aspect, if the verification algorithm is the MD5 algorithm, then the first verification value is the first MD5 value;

[0015] Calculate the second checksum corresponding to the target file, including:

[0016] The MD5 algorithm is used to calculate the second MD5 value corresponding to the target file. One target file corresponds to one target file, and the second check value is the second MD5 value.

[0017] Optionally, in one possible implementation of the first aspect, the above method further includes:

[0018] If the verification result is that the first verification value is equal to the second verification value, then the kernel startup stage is determined and the boot process continues.

[0019] If the verification result shows that the first verification value is not equal to the second verification value, the boot failure is determined, and the target file is re-verified.

[0020] Alternatively, in one possible implementation of the first aspect, the verification file includes:

[0021] The system includes a header information area and a mirror verification value area. The header information area contains indication information corresponding to the verification result, and the mirror verification value area contains the first verification value.

[0022] Optionally, in one possible implementation of the first aspect, the header information area also includes:

[0023] Verification instruction information is used to indicate whether the target file should be verified during the boot loading phase.

[0024] Optionally, in one possible implementation of the first aspect, the mirror verification value area further includes:

[0025] Image file type information, used to indicate the file format of the target file, wherein the file format of the target file includes at least one of RAW or EXT4 file formats.

[0026] Secondly, this application provides a verification device, comprising:

[0027] The module consists of an acquisition module, a calculation module, and a verification module.

[0028] The acquisition module is used to: during the boot loading phase, obtain the first checksum corresponding to the original file from the checksum file in the boot partition, where the original file is an image file stored locally on the electronic device;

[0029] The calculation module is used to calculate the second checksum corresponding to the target file, where the target file is the file after the original file is downloaded to the boot partition;

[0030] The verification module is used to verify the target file based on the first verification value and the second verification value to obtain the verification result.

[0031] Thirdly, this application provides a verification device, comprising:

[0032] Processor and memory;

[0033] The memory stores executable code, which, when executed by the processor, causes the processor to perform the verification method as described in the first aspect above, or any implementation thereof.

[0034] Fourthly, this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to execute the verification method as described in the first aspect above, or any implementation thereof.

[0035] The technical solution provided in this application has at least the following beneficial effects:

[0036] During the boot loading phase, the first checksum corresponding to the original file is obtained from the checksum file in the boot partition, and the second checksum corresponding to the target file is calculated. Finally, the target file is checked based on the first and second checksums. Since the original file is an image file stored locally on the electronic device, and the target file is the file after the original file is downloaded to the boot partition, the above checksum method can determine whether the downloaded target file is the same as the original file. This achieves the checksum verification of the image file during the boot loading phase, ensuring the integrity and consistency of the image file downloaded to the boot partition.

[0037] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0038] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0039] Figure 1 This is a schematic diagram of one embodiment of the verification method in this application;

[0040] Figure 2 This is a schematic diagram of the structure of the verification file in an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of the structure of the header information area in the verification file in an embodiment of this application;

[0042] Figure 4 This is a schematic diagram of a mirrored MD5 value region in the verification file in an embodiment of this application;

[0043] Figure 5 This is a schematic diagram of the verification device in an embodiment of this application;

[0044] Figure 6 This is another structural schematic diagram of the electronic device in the embodiments of this application. Detailed Implementation

[0045] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0046] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0047] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0048] To understand the technical solution in this application, the boot process of a smart terminal is described below:

[0049] A smart terminal needs to go through three independent stages to boot up: the boot stage, the kernel stage, and the application system stage.

[0050] The boot phase, also known as the boot loading phase, is the first phase after a smart terminal is powered on. The main tasks of the boot loading phase include power-on detection of various hardware components and flash memory partitioning. During the boot loading phase, the smart terminal's system has not yet started.

[0051] After the bootloader completes loading, the kernel startup phase begins, and the smart terminal's system starts booting. The kernel is the most fundamental part of the operating system, also known as the kernel. The kernel is a piece of software that provides secure access to hardware for numerous applications. This access is limited, and the kernel determines when a program can operate on a particular part of the hardware and for how long. The kernel startup phase mainly involves kernel initialization, copying the image file, etc.

[0052] After the kernel boots up, the smart terminal will then enter the application system startup phase. The application system startup phase mainly includes system configuration and loading various applications.

[0053] The technical solution in this application is applicable to the aforementioned boot stage, i.e., the boot loading stage, and is used to verify the image file during the boot loading stage to ensure the integrity and consistency of the image file.

[0054] To better understand the technical solutions in this application, the verification method for image files in the embodiments of this application is described below with reference to the accompanying drawings:

[0055] Figure 1 This is a schematic diagram of one embodiment of the verification method in this application.

[0056] like Figure 1 As shown, one embodiment of the verification method in this application is applicable to verifying image files, specifically verifying image files downloaded to the boot partition, including:

[0057] 101. During the boot loading phase, obtain the first checksum corresponding to the original file from the checksum file in the boot partition.

[0058] In this embodiment, the original file is a mirror file stored locally on an electronic device. The electronic device includes, but is not limited to, smart terminals such as mobile phones and smartwatches. The verification file is newly created and stores a first verification value corresponding to the original file. This first verification value is calculated using a verification algorithm on the original file. The verification algorithm includes at least: MD5 checksum algorithm or parity check, etc. When the original file is downloaded to the boot partition, the verification file is also downloaded to the boot partition.

[0059] Specifically, the MD5 algorithm, also known as the MD5 hash algorithm, is a one-way encryption function that accepts a message of arbitrary length as input and returns a fixed-length digest value as output, used to verify the original message. In this embodiment, the MD5 algorithm is used to verify the image file.

[0060] Optionally, in one embodiment of this application, the verification method further includes:

[0061] Using a verification algorithm, calculate the first verification value corresponding to the original file, with one first verification value corresponding to one original file;

[0062] A verification file is generated based on the first verification value, wherein the verification file includes at least one first verification value;

[0063] When the original file is downloaded to the boot partition, the verification file is also downloaded to the boot partition.

[0064] Optionally, in one embodiment of this application, the verification file includes: a header information area and a mirror verification value area, wherein the header information area includes indication information corresponding to the verification result, and the mirror verification value area includes a first verification value. If the verification algorithm is the MD5 algorithm, then the mirror verification value area includes a first MD5 value.

[0065] Further optionally, in one embodiment of this application, the header information area further includes: verification indication information, used to indicate whether the target file is verified during the boot loading stage.

[0066] Further optionally, in one embodiment of this application, the image verification value area further includes: image file type information, used to indicate the file format of the target file, wherein the file format of the target file includes at least one of RAW or EXT4 file formats.

[0067] To better understand the composition of the verification file in the embodiments of this application, the following description combines... Figures 2-4 The structure of the verification file was explained using the MD5 algorithm as an example, and will not be repeated here.

[0068] 102. Calculate the second checksum corresponding to the target file.

[0069] In this embodiment, the target file is the file after the original file has been downloaded to the boot partition. It should be understood that if the file download proceeds without error, the target file is substantially the same as the original file; otherwise, the target file is different from the original file. Conversely, if the target file is the same as the original file, it can be inferred that the original file was downloaded to the boot partition without error; if the target file is different from the original file, it can be inferred that the original file encountered an error during download to the boot partition. It should be understood that an error refers to changes in data or bytes within the file.

[0070] The second checksum is calculated on the target file using a checksum algorithm, which may include at least MD5 checksum or parity check.

[0071] Optionally, if the verification algorithm is MD5, then the first verification value is the first MD5 value. It should be understood that the first MD5 value is obtained by calculating the original file using the MD5 verification algorithm. In this case, calculating the second verification value corresponding to the target file includes: using the MD5 algorithm to calculate the second MD5 value corresponding to the target file, where one target file corresponds to one target file, and the second verification value is the second MD5 value.

[0072] 103. Based on the first and second check values, the target file is checked to obtain the check result.

[0073] In this embodiment of the application, the verification result includes the following two results: the first verification value and the second verification value are equal, or the first verification value and the second verification value are not equal.

[0074] Furthermore, in one embodiment of this application, after obtaining the verification result, the method further includes:

[0075] If the verification result is that the first verification value is equal to the second verification value, then the kernel startup stage is determined and the boot process continues.

[0076] If the verification result shows that the first verification value is not equal to the second verification value, the boot failure is determined, and the target file is re-verified.

[0077] It should be understood that if the first checksum equals the second checksum, it indicates that the target file downloaded to the boot partition is complete and consistent with the original file; otherwise, it indicates that the data or bytes in the target file downloaded to the boot partition have been changed.

[0078] Furthermore, if the verification algorithm is the MD5 algorithm, specifically: if the verification result is that the first MD5 value is equal to the second MD5 value, it is determined to enter the kernel boot stage and continue to execute the boot process;

[0079] If the verification result shows that the first MD5 value is not equal to the second MD5 value, the boot failure is confirmed, and the target file is re-verified.

[0080] In summary, in this embodiment of the application, during the boot loading stage, a first verification value corresponding to the original file is obtained from the verification file in the boot partition, and a second verification value corresponding to the target file is calculated. Finally, the target file is verified based on the first and second verification values. Since the original file is an image file stored locally on the electronic device, and the target file is the file after the original file is downloaded to the boot partition, the above verification method can determine whether the downloaded target file is the same as the original file. This achieves the verification of the image file during the boot loading stage, ensuring the integrity and consistency of the image file downloaded to the boot partition.

[0081] Furthermore, by verifying the image file (target file) downloaded to the boot partition as described above, and determining whether to continue the boot process based on the verification results, it is possible to accurately determine whether an error occurred during the download of the image file to the boot partition in the boot loading stage. Furthermore, determining whether to continue the boot process or re-verify the target file based on the verification results can effectively reduce the probability of errors during device boot and improve device performance.

[0082] The following uses the MD5 algorithm as an example to illustrate the composition structure of the verification file in the embodiments of this application, with reference to the accompanying drawings:

[0083] Figure 2 This is a schematic diagram of the structure of the verification file in an embodiment of this application.

[0084] like Figure 2 As shown in the embodiment of this application, the verification file is an md5.img file, which includes: a header information area, an image md5 value area, an ext4 image organization format area, and an md5 partition md5 value area.

[0085] The specific steps for generating the verification file md5.img are as follows: first, obtain the image file (i.e., the original file) to be verified, then calculate the md5 value of the original file, and then create an md5.img file, saving the calculated md5 values ​​of each original file into the md5.img file.

[0086] The structure of the header information area in the md5.img file is explained below with reference to the accompanying diagram.

[0087] Figure 3 This is a schematic diagram of the structure of the header information area in the verification file in an embodiment of this application.

[0088] like Figure 3As shown, in this embodiment of the application, when the verification file is an md5.img file, the size of the md5.img file is 512K, and the entire file can be represented by an md5checksum_header data structure, which is defined as follows:

[0089] The value of `checksum_flag` determines whether a smartphone or other smart device performs an MD5 checksum during the boot process (LK). In the `md5.img` file, this value is always 1, indicating that an MD5 checksum is always required. An MD5 checksum is performed the first time the smartphone or other smart device boots into LK. If the checksum is successful, this member value is set to 0 so that an MD5 checksum will not be performed on subsequent boots. The aforementioned checksum indication information includes the value of `checksum_flag`.

[0090] The checksum_num member represents the number of partition images that need to be verified. This value is set and obtained when generating the verification file (i.e., the md5.img file) from the original file.

[0091] The `md5_failed` member is 0 if the MD5 check was successful and 1 if it failed. The initial value is 0, and it will be set to 1 if the MD5 check fails within `lk`. The `md5_failed` member is included in the indication information corresponding to the above check results.

[0092] The date member array is currently unused; it was added to expand the header information area to 32 bytes.

[0093] The above four parts—checksum_flag, checksum_num, md5_failed, and date—constitute the header information area of ​​the md5.img file.

[0094] The mirrored MD5 value area is specifically the MCI member in the aforementioned md5checksum_header structure, which stores the MD5 value information of each original file.

[0095] In the aforementioned `md5checksum_header` structure, the ext4 mirror organization format area and the MD5 partition MD5 value area are not directly reflected in the `md5checksum_header` structure, but are hidden in the final `reserved` member. The entire `md5checksum_header` structure is 512 x 1024 bytes in size, and the `reserved` member was added specifically for this purpose.

[0096] Furthermore, the structure of the mirrored MD5 value region in the md5.img file is explained in conjunction with the accompanying diagram.

[0097] Figure 4 This is a schematic diagram of the structure of the mirrored MD5 value area in the verification file in an embodiment of this application.

[0098] like Figure 4 As shown above, the information in the image MD5 value area of ​​the md5.img file ensures that the mci members shown in the header information area can be used. Figure 4 The md5checksum_info structure shown here has the following layout:

[0099] The `need_checksum` parameter is used to determine whether the original file needs to be checked using MD5 after it is burned into a mobile phone or other smart terminal. Currently, the initial value of this parameter for all configured original files is 1, indicating that MD5 checksum is required.

[0100] `image_size` stores the size of the image file to be burned. Any image file that needs verification (including at least one original file) can be represented as a `boot.img` file. For example, if the `boot.img` file is 2400 bytes in size, then the value of `image_size` is set to 2400. After the `boot.img` file is burned to the phone's boot partition, when performing MD5 verification on the image file during the boot loading phase, only the first 2400 bytes of the boot partition are read to recalculate the MD5 value and compare it with the first MD5 value of the boot partition in the `md5.img` file to confirm a match. It's important to note that `image_size` only takes effect when the image file type (`image_type`) is RAW.

[0101] The `image_type` parameter is used to determine the image's format. Currently, there are two types: RAW and EXT4. If the image is packaged in EXT4 format, the `image_type` will be EXT4, such as `system.img` or `cache.img`. Otherwise, it will be in RAW format, such as `boot.img`. The image file type information mentioned above includes the `image_type` parameter.

[0102] `is_failed` is used to store the MD5 checksum result of the corresponding image file, with an initial value of 0. 0 indicates successful checksum verification, and 1 indicates failed checksum verification.

[0103] The partition is used to save the image file to the corresponding partition name in the boot partition. During the boot loading stage, the contents of the corresponding boot partition will be read according to the partition name, and the second MD5 value will be calculated and compared.

[0104] The checksum contains the first MD5 value corresponding to the original file, which is 32 bytes in size.

[0105] Performing MD5 verification during the boot loading phase can specifically include the following three steps:

[0106] Step 1: Read the MD5 partition content into the MD5checksum_header structure variable.

[0107] The md5 partition is the part of the boot partition that stores the original files. For example, if image_size is 2400, the md5 partition is the first 2400 bytes of the boot partition.

[0108] Step 2: Based on the read MD5 partition content, obtain the partitions that need to be checked with MD5, calculate the second 2MD5 value of these partitions, and compare it with the corresponding partition in the MD5 partition to confirm whether they match.

[0109] The size of the MD5 partition corresponds to the total number of bytes in the original files. For example, if there are 3 original files, the size of the MD5 partition is the sum of the bytes of the 3 original files. The MD5 partition can be divided into 3 partitions according to the number of original files, with each partition corresponding to one original file.

[0110] Step 3: If the MD5 checksum of any partition in the MD5 partition fails, the failed partition will be printed on the screen, and the mobile phone or other smart terminal will be powered off. Upon the next boot, the mobile phone or other smart terminal will perform the MD5 checksum again. Otherwise, if the MD5 checksum succeeds, the information in the header area will be set according to the checksum structure, and the modified information will be saved to the checksum file. Next, the system will boot into the kernel.

[0111] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a verification device, an electronic device, a storage medium, and corresponding embodiments.

[0112] Figure 5 This is a schematic diagram of the verification device in an embodiment of this application.

[0113] like Figure 5 As shown, in this embodiment of the application, the verification device 50 includes: an acquisition module 501, a calculation module 502, and a verification module 503;

[0114] The acquisition module 501 is used to: during the boot loading phase, obtain the first check value corresponding to the original file from the check file in the boot partition, wherein the original file is an image file stored locally on the electronic device;

[0115] The calculation module 502 is used to: calculate the second check value corresponding to the target file, wherein the target file is the file after the original file is downloaded to the boot partition;

[0116] The verification module 503 is used to: verify the target file based on the first verification value and the second verification value to obtain the verification result.

[0117] Optionally, in one embodiment of this application, the calculation module 502 is further configured to: use a verification algorithm to calculate a first verification value corresponding to the original file, wherein one original file corresponds to one first verification value; the verification device 50 further includes: a generation module 504 and a download module 505;

[0118] The generation module 504 is used to: generate a verification file based on the first verification value, wherein the verification file includes at least one first verification value;

[0119] Download module 505 is used to: download a verification file to the boot partition when the original file is downloaded to the boot partition.

[0120] Optionally, in one embodiment of this application, the verification algorithm is the MD5 algorithm, then the first verification value is the first MD5 value; the calculation module 502 is specifically used to: use the MD5 algorithm to calculate the second MD5 value corresponding to the target file, where one target file corresponds to one target file, and the second verification value is the second MD5 value.

[0121] Optionally, in one embodiment of this application, the verification module 503 is further configured to perform the following operations: if the verification result is that the first verification value is equal to the second verification value, determine to enter the kernel startup stage and continue to execute the boot process; if the verification result is that the first verification value is not equal to the second verification value, determine that the boot has failed and re-verify the target file.

[0122] Optionally, in one embodiment of this application, the verification file includes: a header information area and a mirror verification value area, wherein the header information area includes indication information corresponding to the verification result, and the mirror verification value area includes a first verification value.

[0123] Optionally, in one embodiment of this application, the header information area further includes: verification indication information, used to indicate whether the target file is verified during the boot loading stage.

[0124] Optionally, in one embodiment of this application, the image verification value area further includes: image file type information, used to indicate the file format of the target file, wherein the file format of the target file includes at least one of RAW or EXT4 file formats.

[0125] In summary, the verification device 50 of this application embodiment, during the boot loading stage, obtains the first verification value corresponding to the original file from the verification file in the boot partition through the acquisition module 501, and calculates the second verification value corresponding to the target file through the calculation module 502. Finally, the verification module 503 verifies the target file based on the first and second verification values. Since the original file is an image file stored locally on the electronic device, and the target file is the file after the original file is downloaded to the boot partition, the above verification method can determine whether the downloaded target file is the same as the original file, thereby realizing the verification of the image file during the boot loading stage and ensuring the integrity and consistency of the image file downloaded to the boot partition.

[0126] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0127] Figure 6 This is another structural schematic diagram of the electronic device in the embodiments of this application.

[0128] like Figure 6 As shown, in this embodiment of the application, the electronic device 60 includes a memory 601 and a processor 602. The memory stores executable code, which, when executed by the processor, causes the processor to perform the methods described in any of the above embodiments.

[0129] Processor 602 can be a CPU, or other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0130] Memory 601 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 602 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 601 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 601 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0131] The memory 601 stores executable code, which, when processed by the processor 602, can cause the processor 602 to execute part or all of the methods described above.

[0132] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0133] Alternatively, this application may be implemented as a computer-readable storage medium (or machine-readable storage medium) storing executable code (or computer program, or computer instruction code) thereon, which, when executed by a processor of an Internet of Things (IoT) terminal (or electronic device, server, etc.), causes the processor to perform part or all of the steps of the above-described method according to this application.

[0134] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0135] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0136] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0137] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0140] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method of checking, characterized by, Used to verify image files, including: During the boot loading phase, a first checksum corresponding to the original file is obtained from a checksum file in the boot partition, wherein the original file is an image file stored locally on the electronic device; the checksum file includes: a header information area and an image checksum area, wherein the header information area includes indication information corresponding to the checksum result, and the image checksum area includes the first checksum; the header information area also includes: checksum indication information, used to indicate whether the target file is checked during the boot loading phase; the image checksum area also includes: image file type information and image file size information, wherein the image file type information is used to indicate the file format of the target file, wherein the file format of the target file includes at least one of RAW or EXT4 file formats; when the file format is RAW, the specified size content of the partition where the target file is located is checked according to the image file size information; Calculate the second check value corresponding to the target file, wherein the target file is the file after the original file is downloaded to the boot partition; The target file is verified based on the first verification value and the second verification value to obtain a verification result; if the verification is successful, the verification indication information in the verification file is modified so as to indicate that the target file is not verified in the subsequent boot loading stage.

2. The method of claim 1, wherein, The method further includes: Using a verification algorithm, a first verification value corresponding to the original file is calculated, wherein one original file corresponds to one first verification value; The verification file is generated based on the first verification value, wherein the verification file includes at least one of the first verification values. When the original file is downloaded to the boot partition, the verification file is also downloaded to the boot partition.

3. The method of claim 2, wherein, If the verification algorithm is MD5, then the first verification value is the first MD5 value; The calculation of the second verification value corresponding to the target file includes: Using the MD5 algorithm, a second MD5 value corresponding to the target file is calculated, wherein one target file corresponds to one target file, and the second check value is the second MD5 value.

4. The method of any one of claims 1-3, wherein, The method further includes: If the verification result is that the first verification value is equal to the second verification value, it is determined that the kernel startup stage will be entered and the boot process will continue. If the verification result is that the first verification value is not equal to the second verification value, the boot failure is determined, and the target file is re-verified.

5. A checking device, characterized in that include: The module consists of an acquisition module, a calculation module, and a verification module. The acquisition module is used to: during the boot loading phase, obtain the first verification value corresponding to the original file from the verification file in the boot partition, wherein the original file is an image file stored locally on the electronic device; The verification file includes a header information area and an image verification value area. The header information area includes indication information corresponding to the verification result, and the image verification value area includes the first verification value. The header information area also includes verification indication information, used to indicate whether the target file is verified during the boot loading stage. The image verification value area also includes image file type information and image file size information. The image file type information indicates the file format of the target file, wherein the file format of the target file includes at least one of RAW or EXT4 file formats. When the file format is RAW, the specified size of the content of the partition where the target file is located is verified according to the image file size information. The calculation module is used to: calculate a second check value corresponding to the target file, wherein the target file is the file after the original file is downloaded to the boot partition; The verification module is used to: verify the target file according to the first verification value and the second verification value to obtain a verification result; if the verification is successful, modify the verification indication information in the verification file so as to indicate that the target file is not verified in the subsequent boot loading stage.

6. An electronic device, comprising: include: Processor and memory; The memory stores executable code, which, when executed by the processor, causes the processor to perform the verification method as described in any one of claims 1-4.

7. A computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the verification method as described in any one of claims 1-4.

Images