Differential upgrading method and terminal equipment

Abstract

The invention belongs to the technical field of software upgrading, and provides a differential upgrading method and terminal device.The method comprises the steps that in response to an upgrading instruction of a user, first firmware and second firmware are obtained; comparing the first firmware with the second firmware to obtain a differential packet; and sending the differential packet to the user side to enable the user side to finish upgrading, the second firmware comprises a bootstrap program partition mirror image and first to nth partition mirror images, the tail part of the ith partition mirror image comprises an abstract calculation tree of the ith partition mirror image, the first partition mirror image comprises an abstract root of the ith partition mirror image and signature information of the abstract root, n is an integer and is greater than 1, and i is an integer and belongs to (1, n). According to the method provided by the embodiment of the invention, the data volume of the upgrade package is small, the flow consumption during upgrade is reduced, and the original program is not changed during upgrade, so that the upgrade can be successfully carried out through step-by-step verification of secure startup.

Description

Technical Field

[0001] The present application belongs to the technical field of software upgrade, and in particular, relates to a differential upgrade method and terminal equipment. Background Art

[0002] With the continuous iteration of user devices, especially when the software of user devices needs to be frequently upgraded to meet new business functions, it is necessary to send upgrade packages through the remote platform. For Linux (Linus Benedict Torvalds) or Android systems, the complete upgrade package is very large, which consumes a lot of data traffic invisibly, so differential upgrades must be supported. That is, only a small amount of changes (such as some so libraries, logo file levels) need to be sent, rather than the entire firmware package.

[0003] The existing differential upgrade method will cause upgrade failure when applied to a system with a secure boot function. Therefore, a new software upgrade method is needed that can be applicable to the upgrade of a system with a secure boot function. Summary of the invention

[0004] In view of this, an embodiment of the present application provides a differential upgrade method and a terminal device to solve the problem that when using the existing differential upgrade method to perform software upgrade on a system with a secure boot function, the upgrade will fail.

[0005] A first aspect of an embodiment of the present application provides a differential upgrade method, which is applied to a server, and the method includes:

[0006] In response to the user's upgrade instruction, a second firmware is generated, wherein the second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a digest calculation tree of the i-th partition image, the first partition image includes a digest root of the i-th partition image and signature information of the digest root, n is an integer and n>1, i is an integer and i∈(1,n];

[0007] Acquire a first firmware, and compare the first firmware with the second firmware to obtain a differential packet;

[0008] Sending the differential packet to the user terminal so that the user terminal completes the upgrade;

[0009] The user terminal includes a boot program partition for storing partition images, and first to nth partitions, and the user terminal is used to:

[0010] Restoring a third firmware that is the same as the second firmware based on the differential package and the first firmware;

[0011] Flashing each partition image in the third firmware to the corresponding partition respectively;

[0012] In response to the restart instruction from the server, the device restarts to complete the upgrade.

[0013] A second aspect of an embodiment of the present application provides a differential upgrade method, which is applied to a user terminal, wherein the user terminal includes a boot program partition for storing partition images, and a first partition to an nth partition, and the method includes:

[0014] Restoring a third firmware that is identical to the second firmware based on the first firmware and the differential packet sent by the server;

[0015] Flashing each partition image in the third firmware to the corresponding partition respectively;

[0016] Responding to the restart instruction from the server, restarting the device to complete the upgrade;

[0017] Wherein, the server is used for:

[0018] In response to an upgrade instruction from a user, a second firmware is generated, wherein the second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a digest computation tree of the i-th partition image, the first partition image includes a digest root of the i-th partition image and signature information of the digest root, i is any integer greater than 1 and less than or equal to n, and n is an integer greater than 1;

[0019] Acquire a first firmware, and compare the first firmware with the second firmware to obtain a differential packet;

[0020] The differential packet is sent to the user end.

[0021] The third aspect of the embodiments of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the terminal device is a server, the processor implements the steps of the differential upgrade method provided in the first aspect of the embodiments of the present application when executing the computer program; when the terminal device is a user, the processor implements the steps of the differential upgrade method provided in the second aspect of the embodiments of the present application when executing the computer program.

[0022] A differential upgrade method provided in a first aspect of an embodiment of the present application is applied to a server, wherein the method obtains a first firmware and a second firmware by responding to an upgrade instruction of a user; compares the first firmware with the second firmware to obtain a differential package; sends the differential package to a user terminal to enable the user terminal to complete the upgrade; the user terminal includes a boot program partition for storing partition images, and a first partition to an nth partition, and the user terminal is used to: restore a third firmware identical to the second firmware based on the differential package and the first firmware; and flash each partition image in the third firmware to a corresponding partition respectively; In response to a restart instruction from the server, the device is restarted to complete the upgrade; wherein the second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1, n]. The upgrade package data volume of the method provided in the embodiment of the present application is small, the traffic consumption during the upgrade is reduced, and the method will not change the original program during the upgrade, so that the upgrade can be successfully completed through the step-by-step verification of the secure boot.

[0023] It can be understood that the beneficial effects of the second and third aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0025] Figure 1 This is a flow chart of a differential upgrade method provided in one embodiment of the present application;

[0026] Figure 2 This is a flow chart of a differential upgrade method provided by another embodiment of the present application;

[0027] Figure 3 is a schematic diagram of a second firmware provided by an embodiment of the present application;

[0028] Figure 4 This is a flow chart of a differential upgrade method provided by another embodiment of the present application;

[0029] Figure 5 This is a flow chart of a differential upgrade method provided by another embodiment of the present application;

[0030] Figure 6 is a schematic diagram of a differential directory structure provided in an embodiment of the present application;

[0031] Figure 7 This is a schematic diagram of a differential packet structure provided by an embodiment of the present application;

[0032] Figure 8 This is a flow chart of a differential upgrade method provided by another embodiment of the present application;

[0033] Fig. 9 This is a flow chart of a differential upgrade method provided by another embodiment of the present application;

[0034] Fig.10 This is a schematic diagram of a step-by-step verification of a secure boot provided by an embodiment of the present application;

[0035] Fig.11 is a schematic diagram of the structure of a differential upgrade device provided in an embodiment of the present application;

[0036] Fig.12 is a schematic diagram of the structure of a differential upgrade device provided in an embodiment of the present application;

[0037] Fig.13 It is a schematic diagram of the structure of the terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0039] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0040] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0041] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0042] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0043] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0044] Embodiment 1

[0045] The differential upgrade method provided in the embodiment of the present application is applied to the server, and can be executed by the processor of the terminal device when running a computer program with corresponding functions. By responding to the user's upgrade instruction, the first firmware and the second firmware are obtained; the first firmware is compared with the second firmware to obtain a differential package; the differential package is sent to the user end, so that the user end completes the upgrade; the user end includes a boot program partition for storing partition images, a first partition to an nth partition, and the user end is used to: restore a third firmware that is the same as the second firmware based on the differential package and the first firmware; and each partition image in the third firmware is flashed to the corresponding Partitioning; in response to a restart instruction from the server, restarting the device to complete the upgrade; wherein the second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1, n]. The upgrade package data volume of the method provided in the embodiment of the present application is small, the traffic consumption during the upgrade is reduced, and the method will not change the original program during the upgrade, so that the upgrade can be successfully completed through the step-by-step verification of the secure boot.

[0046] In the application, the terminal device can be a robot, a mobile phone, a personal digital assistant (PDA), a self-service terminal, a wearable device, a vehicle-mounted device, a tablet computer, a laptop computer, a personal computer (PC), a netbook, a server, etc. The embodiments of the present application do not impose any restrictions on the specific type of the terminal device.

[0047] In the application, the server can be a single physical server, a cluster consisting of multiple servers, or a virtualized service in a cloud environment. The server software usually includes a Web server, an application server, a database server, etc. The embodiment of the present application does not impose any restrictions on the specific type of the server.

[0048] In applications, the secure boot of the system can be a fully functional Linux system (GNU / Linux, Linux) booting from the SOC chip (system-on-chip) and then loading each program in the embedded multimedia card (Embedded Multi-Media Card, EMMC), which is a process of step-by-step verification and step-by-step safe operation. Specifically, it means that the security of the SOC chip itself is used as the root of trust for step-by-step verification. For example, the boot program partition (usually uboot) image program in the EMMC is first verified and verified. After the verification is passed, the next level kernel program is verified and verified. After the verification is passed, the next level rootfs file system is verified, and so on, until the last level user program partition program, completing the step-by-step verification of the entire operation link, forming a complete set of safe operation chains, preventing the risks caused by tampering of each process program, and ensuring safe boot.

[0049] like Figure 1 As shown, the differential upgrade method provided in the embodiment of the present application includes the following steps S101 to S103:

[0050] Step S101: Responding to an upgrade instruction from a user, obtaining a first firmware and a second firmware.

[0051] The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1,n].

[0052] In an application, when a user initiates an upgrade request in some way (for example, through a settings menu or dedicated update software), the system starts the upgrade process.

[0053] In the application, the first firmware is an old version of firmware that needs to be upgraded, and the second firmware includes a new version of firmware for replacing the existing firmware (i.e., the first firmware). The first firmware can be directly obtained by the server from the stored historical firmware database. The second firmware is pre-generated by the server, and includes image files of multiple partitions and necessary security information. The boot program partition image is used to boot the partition of the system, and usually includes key components such as a boot loader. The first partition image in the first partition image to the nth partition image is a signature data partition image, which is used to store the summary root of the i-th partition image and the signature information of the summary root, where i is an integer and i∈(1, n]. The summary root refers to the root node summary value of the summary calculation tree, which represents the data integrity of the entire partition. The remaining images in the first partition image to the nth partition image may also include at least one of a firmware upgrade partition image, a kernel program partition image, a file system partition image, and an application partition image. In addition to the boot program partition image and the signature data partition image, the tail of each remaining partition image contains a summary calculation tree of the partition image. The summary calculation tree is a data structure used to efficiently calculate the data summary (such as a hash value) of the entire partition.

[0054] Step S102: Compare the first firmware with the second firmware to obtain a differential packet.

[0055] In the application, the new and old firmware are split into partition images respectively through the differential tool on the server side, and then the partition images of the same level are restored to the corresponding file system directories. Then, based on the directories and files at all levels under the file system directory, all the difference files are merged together to form a differential file package, and then the differential file package, the file directory table (including the add / delete / modify operation attributes of each differential file), and the summary calculation tree at the end of the new version of the partition image are integrated together to form the differential image of this partition and used as a separate entry data; finally, the entry data (for example, if there are multiple partitions with file modifications, there will be multiple entry data) and the entry header are combined to form a complete differential package (this differential package is usually relatively small, a few MB to more than ten MB, much smaller than the full package of hundreds of BM to several GB of data).

[0056] Step S103: Send the differential packet to the user end, so that the user end completes the upgrade.

[0057] In the application, the server sends the differential package to the user end through the 4G network or other channels, such as the MDVR vehicle terminal (each vehicle terminal will be pre-installed with a complete base package of the current firmware version before shipment). Then, the system restart of the user end is triggered to enter the upgrade process.

[0058] After responding to the user's upgrade instruction, the embodiment of the present application obtains the first firmware (old version firmware) and the second firmware (new version firmware) to be upgraded, wherein the second firmware not only includes the boot program partition image, multiple partition images and their summary calculation trees, but also specially sets the first partition image to store the summary root and the signature information of the summary root to verify the partition data; next, the server compares the old and new firmware partition by partition through a differential tool, integrates all difference files into a differential file package, and attaches the summary calculation tree at the end of the new version partition image, and finally forms a compact differential package; finally, the server sends this differential package to the user end through the network, and the user end can upgrade after receiving it. By generating and transmitting smaller differential packages instead of complete firmware files, network bandwidth and storage space resources are greatly saved. At the same time, since the upgrade package restored based on the differential package will not change the original program structure, it can be perfectly adapted to the secure boot mechanism, ensuring that the upgrade process can proceed smoothly.

[0059] In one embodiment, the user terminal includes a boot program partition for storing partition images, a first partition to an nth partition, and the user terminal is used to:

[0060] Restoring a third firmware that is identical to the second firmware based on the differential package and the first firmware;

[0061] Flash each partition image in the third firmware to the corresponding partition respectively;

[0062] In response to the restart instruction from the server, the device restarts to complete the upgrade.

[0063] In the application, in the upgrade process, the user side reversely disassembles the differential package into each entry and the data items in each entry, and the data items include "differential file package", "file directory table", "summary calculation tree (such as hash tree, HASH TREE)", "new version partition image check value", "summary calculation tree location and size (such as HASH TREE location and size)". First, the partition image of each entry is decompressed, all directories and files are extracted, and the directory structure and files (marked as base directory structure) preset in the device corresponding to the partition image are compared. According to the file directory table of the differential package, the extracted files / so files with differences are reversely restored to the base directory structure, such as deletion (indicating that the new version does not need this file or so library), then the file under the base corresponding directory structure is deleted; modification and replacement (indicating that the new version updates the file or so library with the same name), then the extracted file is replaced to the base corresponding directory structure; addition (indicating that the new version adds this file or so library), then the extracted file is added to the base corresponding directory structure. After the operation, the base directory becomes the new version directory and is compressed into a new version partition image. The new version partition image is calculated and the result is compared with the extracted "new version partition image check value". After the comparison is passed, the extracted new version "HASH TREE" is appended to the end of the image to form a complete new partition image.

[0064] By analogy, after the same operation is performed on all entries, the restoration of all partitions is completed. Finally, all new partition complete images are integrated into a new base full package (i.e., the third firmware) to replace the original old base full package (i.e., the first firmware) and stored in the user end, such as a mobile digital video recorder (MDVR), for the next differential upgrade. Finally, the new partition images are flashed to each partition block of the EMMC to complete the upgrade action of the new version, and then the system restart is triggered to run the new version firmware (i.e., the third firmware that is the same as the second firmware).

[0065] In one embodiment, Figure 2 As shown, before step S101, the following steps S201 to S207 are included:

[0066] Step S201: Calculate the summary value of the boot program.

[0067] In the application, when the user initiates an upgrade request in some way (for example, through a settings menu or a special update software), the system will start the upgrade process and start generating the second firmware. When generating the second firmware, first generate a boot program partition image. The boot program can be the UBOOT bin file of the Linux system and the supporting secondary program loader (Secondary Program Loader, SPL). Calculating the summary value of the boot program can be calculating the summary value of the UBOOT bin file. The calculation method can use a digest algorithm (also called a hash algorithm or a hash algorithm) to perform a digest operation. The specific digest algorithm can be any algorithm in the message digest algorithm 5 (Message-Digest Algorithm 5, MD5) series or the secure hash algorithm (Secure Hash Algorithm, SHA) series that meets the requirements, and is not limited here.

[0068] Step S202: digitally sign the summary value of the boot program, and add the digital signature of the summary value and the public key to the end of the boot program to obtain a boot program partition image.

[0069] In the application, if the SHA256 HASH operation is used, the 32-byte operation result (i.e., the digest value, which is also the hash value of the SHA256 HASH operation) is digitally signed. The digital signature here can be a digital signature using an RSA private key. After signing, the public key used for decryption (such as an RSA public key) is stored in the tail of the boot program to obtain the boot program partition image.

[0070] Step S203: Calculate the summary computation tree of the jth partition to obtain the summary root of the jth partition.

[0071] In the application, for the second to nth partitions (j is 2, 3, ..., n in turn), the summary computation tree of each partition is calculated to obtain their respective summary roots. The summary computation tree is a special tree data structure, whose leaf nodes contain the summary of the data blocks of the files in the partition (such as hash values), and the internal nodes are the combined summary of the summaries of their child nodes. The root node summary of the final tree is the summary root of the entire partition, which represents the integrity check value of the partition content; in this way, it can be effectively verified whether each partition has not been tampered with before and after the upgrade, ensuring the security and reliability of the upgrade process. j = 2, 3, ..., n, that is, j is 2 to n in turn. When j is 2, the summary computation tree of the second partition is calculated here, and then j is 3, and the summary computation tree of the third partition is calculated, ... and so on, until j is n.

[0072] Step S204: Add the summary computation tree of the jth partition to the end of the jth partition to obtain the jth partition mirror.

[0073] In the application, a summary computation tree is constructed for each partition (i.e., the jth partition, where j is 2, 3, ..., n in sequence), and the summary computation tree is added to the end of the corresponding partition, thereby forming a complete jth partition image. By adding the summary computation tree to the end of the partition, the integrity and consistency of the partition content can be verified during the upgrade process, thereby enhancing the security of the upgrade process.

[0074] Step S205: digitally sign the summary root of the jth partition, and store the digital signature of the summary root, the summary root of the jth partition, and the summary computation tree offset of the jth partition in the data block corresponding to the jth partition in the first partition, where j = 2, 3, ..., n.

[0075] In the application, the summary root of each partition (i.e., the jth partition, where j is 2, 3, ..., n in sequence) is digitally signed, and the digital signature of the summary root, the summary root itself, and the offset of the summary calculation tree (when the hash algorithm is used, the hash offset (HASH Offset)) are stored in the corresponding data block in the first partition. This process ensures that the summary root of each partition is not only verified for its integrity, but also provides non-repudiation through digital signatures, which enhances the security and credibility of the entire upgrade process.

[0076] Step S206: Generate a first partition image.

[0077] In applications, such as Figure 3 As shown, the second partition to the nth partition are respectively a firmware upgrade partition, a kernel program partition, a file system partition and an application partition as examples to illustrate the embodiment of the present application. First, the entire HASH TREE is calculated for the firmware upgrade partition, and the RSA private key signature information, HASH TOP, and HASHOffset pointing (hash tree offset pointing) of the summary root (HASH TOP) are respectively stored in the "signature information", "HASH TOP", and "HASH Offset pointing" data of the sequence number ① data block in the "signature data partition (first partition)"; and the HASH TREE itself with a larger amount of data is stored at the end of the "firmware upgrade partition".

[0078] Similarly, the relevant information of the image partitions such as "kernel program partition", "file system partition", "application partition" are stored in the serial number ②③④ data blocks in the "signature data partition" respectively. At the same time, the HASH TREE of each partition is stored in the tail of its own image partition. Since the "signature digital drama partition" is usually an FDT (devcie tree device number) partition in the Linux system, its capacity is relatively small (for the compatibility of the device, its partition size cannot be changed at will), and it can only store HASH TOP and smaller data; while the HASH TREE is relatively large and can be stored together with the image. After the relevant data of all partition images are stored in the signature digital drama partition, a signature digital drama partition image is generated, that is, the first partition image.

[0079] In applications, the original images of "boot partition image", "signature partition image", "firmware upgrade partition image" and "kernel partition image" are usually bin files directly produced after the Linux system is compiled; while "file system partition image" and "application partition image" are with file systems, usually the file system tool (mksquashfs) compresses the directory into an image.

[0080] Step S207: Integrate the boot program partition image and the first partition image to the nth partition image to obtain a second firmware.

[0081] In the application, the production of each image in the full package (i.e. firmware) (including boot program partition image, signature data partition image, firmware upgrade partition image, kernel program partition image, file system partition image, application partition image) is completed, and then each image is packaged together to form a single large upgrade file (i.e. second firmware). At the same time, the firmware will also be stored in the historical firmware database of the server for subsequent differential upgrades.

[0082] The embodiment of the present application first calculates the summary value of the boot program and digitally signs it, and embeds it into the tail of the boot program together with the public key, thereby ensuring the integrity of the boot program and the authenticity of its source; then, the summary calculation tree is calculated for each functional partition, the summary root is obtained, and the summary root, the digital signature of the summary root, and the offset of the summary calculation tree are stored in the first partition, which not only provides an efficient verification mechanism for the integrity of the content of each partition, but also enhances the unforgeability of these summary roots through digital signatures; in addition, the summary calculation tree itself is placed at the end of the corresponding partition, which not only reduces the storage burden of the first partition but also maintains all the information required for verification; finally, all components including the boot program partition image and the first to nth partition images are integrated to generate the second firmware, thereby ensuring the overall consistency and security of the upgrade package. In summary, this technical solution realizes comprehensive protection from boot loading to each functional partition through the combination of multi-layer encryption, summary calculation and digital signature, significantly improving the system's anti-tampering ability during secure startup and upgrade. At the same time, through carefully designed data layout and storage strategy, it can adapt to the step-by-step verification in the system's secure startup to achieve secure differential upgrades.

[0083] like Figure 4 As shown, in one embodiment, step S102 includes the following steps S301 to S305:

[0084] Step S301: decompress the first firmware and the second firmware respectively to obtain a partition image of the first firmware and a partition image of the second firmware.

[0085] In the application, the second partition to the nth partition are respectively a firmware upgrade partition, a kernel program partition, a file system partition and an application program partition as examples to illustrate the embodiment of the present application. The first firmware and the second firmware are decompressed respectively to obtain each partition image in the old version of the firmware (including a boot program partition image, a signature digital drama partition image, a firmware upgrade partition image, a kernel program partition image, a file system partition image, and an application program partition image), and each partition image in the new version of the firmware (including a boot program partition image, a signature digital drama partition image, a firmware upgrade partition image, a kernel program partition image, a file system partition image, and an application program partition image).

[0086] Step S302: Compare the partition image of the first firmware with the partition image of the second firmware to obtain a differential file package of at least one partition from the second partition to the nth partition.

[0087] In the application, the differential file package refers to the partial content file package in the new version compared with the old version, including the changed files / so libraries and the added files / so libraries.

[0088] In one embodiment, Figure 5As shown, step S302 includes the following steps S401 to S404:

[0089] Step S401: Decompress the jth partition image of the first firmware and the jth partition image of the second firmware respectively to obtain the jth partition directory structure of the first firmware and the jth partition directory structure of the second firmware.

[0090] In the application, you need to choose the right tools and techniques to process partition image files. Usually, a partition image is a file that contains an exact copy of the entire partition, including all file system metadata, file contents, and possible free space. In order to restore the original directory structure from these image files, you can use tools such as ddrescue, imgtool, partclone, or more advanced firmware management software to decompress them. The decompression process will restore these images to the same file and directory structure as the actual partition, making it easier to compare these directories in subsequent steps.

[0091] Step S402: compare the j-th partition directory structure of the first firmware and the j-th partition directory structure of the second firmware.

[0092] In applications, you can use file system comparison tools (such as rsync, diff, etc.) to automatically identify the differences between two directories.

[0093] Step S403: When the comparison result shows that there is a difference, the files in the directory structure of the jth partition of the second firmware are extracted to generate a differential directory structure of the jth partition and a file directory table of the jth partition.

[0094] Wherein, j=2, 3, ..., n; the differential directory structure of the jth partition includes files that have been modified or added compared to the jth partition directory structure of the first firmware; the file directory table includes the file name, file path and modification type, and the modification type is at least one of addition, modification and deletion of the jth partition directory structure of the second firmware compared to the jth partition directory structure of the first firmware.

[0095] In the application, when the comparison result is a difference, the files in the directory structure of the jth partition of the second firmware need to be extracted to generate the differential directory structure of the jth partition and the file directory table of the jth partition. This process involves traversing the directory structure of the new version of the firmware and recording all changed files and their metadata, including file names, file paths, and modification types (such as addition, modification, or deletion). This information will be recorded in a file directory table, and the changed files will be placed in a new directory structure that only contains files that have changed relative to the old version of the firmware, that is, the differential directory structure of the jth partition.

[0096] In applications, such as Figure 6 As shown in the figure, taking the file system partition as an example, the left side of the figure shows the partition directory structure of the old version of the file system (the file system usually refers to the rootfs), and the right side shows the partition directory structure of the new version of the file system. After comparison, it is found that the new version has added file 1_3, modified file 3, and deleted file 1_2. After comparing the difference, file 1_3 and file 3 are retained (the directory below in the figure), that is, the differential directory structure of the file system partition. When generating the differential directory structure of the file system partition, a file directory table is also generated based on the file operations of adding, deleting, and modifying, as shown in the following table:

[0097] File name & path Modification Type File 12 Deleted File 13 Added File 3 Revise

[0098] The file directory table of the file system partition contains the file name, path, and modification type. Because file 1_2 is only deleted and the differential file package does not contain file 1_2, the file operation record must be made.

[0099] Step S404: compress the differential directory structure of the jth partition according to the original path to obtain the differential file package of the jth partition.

[0100] In the application, the remaining files, that is, the differential directory structure of the file system partition, are compressed (such as compressed using the mksquashfs command) as differential file packages according to the original path, and other identical and unchanged files (file 1_1, file 2) are not needed, saving data traffic.

[0101] Step S303: Generate a differential image of at least one partition from the second partition to the nth partition based on the differential file package.

[0102] In the application, the data used to form a partition differential image, in addition to the differential file package of the partition, also includes the file directory table of the partition, the summary calculation tree (such as HASH TREE) of the partition in the second firmware, the image check value of the partition in the second firmware, and the location and size of the summary calculation tree.

[0103] In one embodiment, step S303 includes the following step S3031:

[0104] Step S3031, integrate the differential file package of the jth partition, the file directory table of the jth partition, the summary computation tree of the jth partition of the second firmware, the image check value of the jth partition of the second firmware, and the position and size of the summary computation tree of the jth partition of the second firmware to obtain the differential image of the jth partition.

[0105] Step S304: assign entry tags to the first partition image and each differential image of the second firmware respectively to obtain entry headers.

[0106] In the application, j=2,3,…,n, that is, firstly, the new version and the old version of the second partition image are compared. When the comparison result is that there is a difference, the differential image of the second partition is generated according to the above method. Then, the new version and the old version of the third partition are compared. When the comparison result is that there is a difference, the differential image of the third partition is generated according to the above method, and so on, until j takes n, the differential image of one or more partitions can be obtained.

[0107] In the application, when the image changes in the new version, the SHA256 values ​​of some leaf nodes in the HASH TREE at the end of the image will also change, and the corresponding trunk node SHA256 values ​​will also change, so the HASH TOP finally stored in the corresponding serial number of the "signature data partition" must also be updated. Therefore, when making the final differential package, it is necessary to mark the "signature data partition" image (usually refers to the FDT partition), that is, the first partition image, in the new version with an entry, such as entry 1. Each differential image is assigned an entry tag and an entry header is obtained. The entry header contains information such as the total number of entries, entry type, and the total size of the image corresponding to all entries.

[0108] Step S305: Integrate the differential image, the entry header, and the first partition image of the second firmware to obtain a differential package.

[0109] In one embodiment, step S301 further includes the following steps S306 and S307:

[0110] Step S306: assign entry marks to one or more partition images in the partition images of the second firmware whose data volume is smaller than a preset value.

[0111] In applications, for some special partition images, such as the "kernel program partition" image, since its total data volume is relatively small, usually a few MB has little impact on the upgrade bandwidth, and the kernel does not change frequently, there is no file system, and file-level differentiation cannot be performed. The embodiment of the present application compares versions, and if the versions are consistent, they are not added to the final differential package; if the versions are inconsistent, the "kernel program partition" image (including the tail HASH TREE) is added to the final differential package, and an entry mark is given, such as entry 2.

[0112] Step S307: Integrate the differential image, the entry header, the first partition image of the second firmware, and one or more partition images in the second firmware whose data volume is less than a preset value to obtain a differential package.

[0113] In applications, such as Figure 7As shown, the second partition to the nth partition are respectively a firmware upgrade partition, a kernel program partition, a file system partition and an application program partition as examples to illustrate the embodiment of the present application. In the figure, the signature data partition image is marked as entry 1. Since the kernel program partition image has a small amount of data, it does not need to be differentiated. The kernel program partition image in the second firmware is directly used (the example scenario is a scenario where the kernel has changed, so it needs to be added to the differential package), marked as entry 2. The application partition image and the file system partition image have differences between the new and old versions, and the image file has a large amount of data, so they need to be differentiated. According to the above method, a file system partition differential image and an application partition differential image are produced, and each differential image contains a differential file package, a file directory table, a HASH TREE, a HASH TREE position and a size of the partition. For partitions that have not changed, they are not added to the differential package. They are marked as entries 3 and 4 respectively. Finally, the differential images corresponding to each entry (entries 1 to 4 corresponding to the image) are combined together, and the entry header (entry header, including information such as the total number of entries, the entry type, and the total size of the image corresponding to all entries) is added to form the final differential package.

[0114] Embodiment 2

[0115] The differential upgrade method provided in the embodiment of the present application is applied to a user end, and the user end includes a boot program partition for storing partition images, and a first partition to an nth partition, which can be executed by a processor of a terminal device when running a computer program with corresponding functions, and restores a third firmware that is the same as the second firmware based on the first firmware and a differential packet sent by the server; each partition image in the third firmware is flashed to the corresponding partition respectively; in response to a restart instruction of the server, the device is restarted to complete the upgrade; the server is used to: respond to the user's upgrade instruction, obtain the first firmware and the second firmware; and compare the first firmware with the second firmware. The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1, n]. The upgrade package data volume of the method provided in the embodiment of the present application is small, the traffic consumption during the upgrade is reduced, and the method will not change the original program during the upgrade, so that the upgrade can be successfully completed through the step-by-step verification of the secure boot.

[0116] In the application, the user terminal can be a computer, a laptop, a smart phone, a tablet computer, a smart home device, a smart wearable device, an industrial sensor, a smart car component (such as a vehicle-mounted MDVR terminal device), a printer, a scanner, etc. The embodiment of the present application does not impose any restrictions on the specific type of the user terminal.

[0117] like Figure 8 As shown, the differential upgrade method provided in the embodiment of the present application, the user end includes a boot program partition for storing partition images, a first partition to an nth partition, and the differential upgrade method includes the following steps S501 to S503:

[0118] Step S501: based on the first firmware and the differential packet sent by the server, restore a third firmware that is the same as the second firmware.

[0119] In the application, after the server generates the differential packet, it sends the differential packet to the user end via wireless or other means, and the user end performs restoration processing.

[0120] In one embodiment, Fig. 9 As shown, step S501 includes the following steps S601 to S607:

[0121] Step S601: decompress the first firmware to obtain a partition image of the first firmware.

[0122] In the application, the base full package pre-installed in the device is first decompressed (i.e., the first firmware), and the decompressed package contains all the partition images for secure startup (such as boot program partition image, signature data partition image, firmware upgrade partition image, kernel program partition image, file system partition image, application partition image). The embodiments of the present application are not limited to these images, but may also include other images, and the method is the same.

[0123] Step S602: decompress the differential package to obtain a differential image, an entry header, and a first partition image of the second firmware.

[0124] In the application, the sent differential package is decompressed, and the decompressed package contains (such as signature data partition image, kernel program partition image, file system partition differential image, application partition differential image). The embodiment of the present application is not limited to differential these images, and other images can also be differential, and the method is the same.

[0125] Step S603: Replace the partition image of the first firmware with the first partition image of the second firmware to obtain the first partition image of the third firmware.

[0126] In the application, the signature data partition image in the first firmware is replaced with the signature data partition image in the second firmware to obtain the signature data partition image of the third firmware.

[0127] Step S604: decompress the differential image of the kth partition to obtain a differential file package of the kth partition.

[0128] In the application, k = 2, 3, ..., n, that is, k is 2 to n in sequence. Decompressing the differential image of the kth partition means decompressing the differential images of the 2nd to nth partitions in sequence. Since not all partitions in the 2nd to nth partitions may have differential images, k may not actually be able to take every value in 2 to n. For example, if the nth partition takes 5, and the 3rd partition has no differential image, then k here takes 2, 4, and 5 in sequence.

[0129] Step S605: restore the kth partition image of the first firmware using the differential file package of the kth partition to obtain the kth partition image of the third firmware.

[0130] In the application, the kth partition differential file package is used to restore and update the kth partition image in the first firmware, thereby obtaining the kth partition image of the third firmware. In this way, we can efficiently apply the changes in the differential file package and avoid unnecessary data transmission and processing.

[0131] In one embodiment, step S605 includes the following steps S801 to S805:

[0132] Step S801: decompress the kth partition image of the first firmware to obtain the directory structure of the kth partition.

[0133] In the application, the kth partition image of the old version of the firmware is decompressed (usually the unsquashfs command is used to extract the file system directory structure of the old version. For file system partitions, the commands are different depending on the file system type, and the specific commands are determined according to the actual file system type) to obtain the directory structure of the kth partition.

[0134] Step S802: decompress the differential file package of the kth partition to obtain the differential directory structure of the kth partition.

[0135] In the application, the differential file package of the kth partition is decompressed (usually unpacked using the unsquashfs command) to obtain the differential directory structure of the kth partition, such as Figure 6 shown.

[0136] Step S803: decompress the differential image of the kth partition to obtain a file directory table of the kth partition.

[0137] In the application, the differential image of the kth partition is decompressed to obtain the file directory table of the kth partition.

[0138] Step S804: Based on the differential directory structure and the file directory table of the kth partition, at least one operation of adding, modifying, and deleting is performed on the corresponding files of the first firmware to obtain the kth partition directory structure of the third firmware.

[0139] In the application, according to the "file directory table" in the differential image, any one or more operations such as replacement, deletion, and addition are performed on the corresponding files in the directory structure of the old version. After the operation, the directory structure of the old version has become the directory structure of the new version.

[0140] Step S805: compress the kth partition directory structure of the third firmware according to the original path to obtain the kth partition image of the third firmware.

[0141] In the application, the new version directory structure is compressed, usually by using the mksquashfs command. For file system partitions, the commands vary depending on the file system, depending on the actual file system type.

[0142] In one embodiment, to ensure that the data content of the image generated by the user end is the same as the content of the new version image on the PC end, it is necessary to add relevant parameters to the mksquashfs command to remove variable metadata, such as timestamps, authority ownership, etc.; similarly, when previously creating a new version image on the PC end, it is also necessary to add relevant parameters to remove variable metadata.

[0143] Step S606: store the summary computation tree of the kth partition in the differential package into the tail of the kth partition image according to the position and size of the summary computation tree of the kth partition.

[0144] In the application, the HASH TREE in the differential package is stored in the tail of the kth partition image generated in step S606 according to the position and size of the HASH TREE of the partition image in the differential package, and finally a complete partition image file with secure boot function is generated.

[0145] In the application, k is sequentially set to 2, 3, ..., n, so as to restore different partition images in sequence.

[0146] Step S607: Integrate all partition images of the third firmware to obtain the third firmware, where k=2, 3, ..., n.

[0147] In the application, all partition images of the third firmware are merged into a new full package new base (ie, the third firmware) to serve as the base package for subsequent upgrades; and the old base package (ie, the first firmware) is deleted to save space.

[0148] Step S502: Flash each partition image in the third firmware to the corresponding partition.

[0149] In the application, the new image in the third firmware restored in step S607 (including signature data partition image, kernel program partition image, file system partition image, application partition image) is flashed; and the partition images that have not been modified (boot program partition image, firmware upgrade partition image) do not need to be flashed again. Flash each image file to each partition of EMMC, usually using the Linux standard dd command. After the flashing is completed, the unnecessary temporary files in the middle are deleted, and the relevant upgrade status and upgrade log are recorded in the specified directory for future inspection and analysis.

[0150] Step S503: Respond to the restart instruction from the server and restart the device to complete the upgrade.

[0151] In the application, after all partitions are flashed, the system restart is triggered (usually the reboot command), and the new version of the system is run after the restart.

[0152] In one embodiment, the server is used to:

[0153] In response to an upgrade instruction from a user, acquiring the first firmware and the second firmware;

[0154] Compare the first firmware with the second firmware to obtain a differential packet;

[0155] Send the differential packet to the user end so that the user end completes the upgrade;

[0156] The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1,n].

[0157] In one embodiment, before step S607, the following steps S701 to S702 are also included:

[0158] Step S701: decompress the differential package to obtain one or more partition images in the second firmware whose data volume is less than a preset value.

[0159] In the application, for images with a small amount of data, since no difference is performed when the differential package is generated, the decompressed image is a complete partition image, such as a signature data partition image and a kernel program partition image.

[0160] Step S702: Use one or more partition images in the second firmware whose data volume is smaller than a preset value to replace the corresponding partition images in the first firmware, so as to obtain one or more partition images in the third firmware whose data volume is smaller than the preset value.

[0161] In the application, for images with small data volume and differences from the old version, such as the signature data partition image and the kernel program partition image, they are replaced with the image decompressed by the second firmware. For example, the signature data partition image and the kernel program partition image in the old version are replaced with the signature data partition image and the kernel program partition image in the new version.

[0162] In one embodiment, before step S606, the following steps S901 to S903 are also included:

[0163] Step S901: Calculate the check value of the kth partition image of the third firmware.

[0164] In the application, in order to verify whether the restored kth partition image data is consistent with the kth partition image generated by the server, a check value calculation is performed on the kth partition image of the third firmware.

[0165] Step S902: Compare the calculated checksum value with the checksum value of the kth partition image.

[0166] In the application, the calculated check value is compared with the check value of the kth partition in the differential packet.

[0167] Step S903: If the calculated check value is consistent with the check value of the kth partition image, the summary calculation tree of the kth partition in the differential package is stored at the end of the kth partition image according to the position and size of the summary calculation tree of the kth partition;

[0168] The checksum of the kth partition image is obtained by decompressing the differential image of the kth partition.

[0169] In the application, if they are consistent, it means that the restoration result of the kth partition image on the user side is the same as the content of the kth partition image generated by the server side, and the anti-tampering mechanism in the secure boot process will not be triggered to perceive its abnormality, and then continue to execute step S606. Otherwise, it will be considered that it has been tampered with, resulting in the next device being unable to start. Therefore, when there is inconsistency, a differential upgrade failure signal is output and the upgrade process is exited.

[0170] In one embodiment, step S503 includes the following steps S111 to S118:

[0171] Step S111: Responding to the restart instruction from the server, executing device restart.

[0172] In the application, after each partition image in the third firmware is flashed to the corresponding partition, the server sends a restart instruction to the user terminal, triggering the user terminal to restart.

[0173] Step S112 : Run the program of the system-on-chip, calculate the digest value of the public key in the boot program partition, and compare it with the digest value stored in the system-on-chip.

[0174] In the application, when the initial version of the boot program partition image (including digital signature and public key) is burned into the UBOOT partition of the EMMC of the user end, that is, before the user end leaves the factory, the 32-byte hash value of the RSA public key is written into the EFUSE inside the SOC chip, and the EFUSE fuse is turned on, that is, the summary value of the public key is stored.

[0175] In the application, during secure boot, the ROM program stored in the SOC chip first determines that the EFUSE (EFUSE is a hardware device that stores hash values ​​inside the SOC chip. Once the fuse is blown, the hash value cannot be modified) inside the chip has been opened, and then the entire subsequent process is carried out according to the secure boot process. The ROM program obtains and calculates the hash value of the RSA public key in the "boot partition".

[0176] Step S113: If the calculated digest value of the public key is consistent with the digest value stored in the system-level chip, the digest value of the boot program partition image is calculated and compared with the digest value obtained by decrypting the public key.

[0177] In the application, if the summary value of the public key is consistent with the hash value of the EFUSE fuse, the RSA public key is credible. Then the hash value of the entire image of the "boot partition" is calculated and compared with the hash value obtained by decrypting and verifying the signature information at the end of the boot partition using the RSA public key.

[0178] Step S114: If the calculated digest value of the boot program partition image is consistent with the digest value obtained by decrypting the public key, the program of the boot program partition is run.

[0179] In the application, if the comparison is consistent, the boot program partition is credible, and the verification of the first-level program (the boot program is regarded as the first-level program) is completed. Then jump from the SOC chip to the boot program partition in the external EMMC and run the program in the boot program partition.

[0180] Step S115: Obtain the digital signature of the digest root of the jth partition from the jth partition, and decrypt the digital signature using the public key to obtain the digest root of the jth partition.

[0181] In the application, start the verification of the second-level program (the principle of verification, the verification of the same-level program). Figure 3First, read the signature information ② corresponding to the "kernel program partition" from the "signature data partition". Use the signature information ② to decrypt the digital signature and obtain the summary root of the kernel program partition (usually the HASH calculation method, using the SHA256 algorithm to ensure a very high anti-tampering detection capability).

[0182] Step S116: Compare the digest root of the jth partition obtained by decryption with the digest root stored in the jth partition.

[0183] In the application, the digest root of the decrypted kernel program partition is compared with the HASHTOP of the stored kernel program partition.

[0184] Step S117: If the digest root of the jth partition obtained by decryption is consistent with the digest root stored in the jth partition, the image content of the jth partition is verified using the digest root of the jth partition and the digest computation tree pointed to by the digest computation tree offset of the jth partition.

[0185] In the application, if they are consistent, the stored HASH TOP is credible. Then the content of the kernel program partition image is verified through the credible HASH TOP and the digest computation tree pointed to by the digest computation tree offset of the kernel program partition.

[0186] like Fig.10 As shown in the figure, after the HASH TOP is credible, the entire HASH TREE can be verified step by step through the HASH TOP. First, take out the HASH TOP, which usually represents a 32-byte value of the calculation result of SHA256. Calculate a 32-byte SHA256 value for all data of all HASH TREE trunk nodes at the next level, and compare the SHA256 value of the HASH TOP with the SHA256 results calculated by all trunks. If they are consistent, all the node values ​​of the trunk are credible. Then verify the leaf nodes, that is, take out the SHA256 value of a certain node of the trunk and compare it with the 32-byte values ​​calculated by SHA256 of all the leaf nodes covered. If they are consistent, the SHA256 values ​​of the covered leaf nodes are credible; and so on. Finally, take out the SHA256 value of a certain leaf node, and compare it with the 32-byte value calculated by SHA256 of a data block (usually 4KB) in the covered mirror data. If they are consistent, it means that the 4KB data in the mirror has not been tampered with and is credible. Therefore, the root HASH TOP is trusted. After all the trunk nodes and all the leaf nodes under the trunk are verified, the entire mirror data can be verified. If they are consistent, the mirror data is credible.

[0187] Step S118: If the verification is successful, the program in the jth partition is run; wherein j = 2, 3, ..., n.

[0188] In the application, if the verification passes, the program in the kernel program partition will be run.

[0189] Similarly, each partition can be verified in turn in the same way, and after the verification is passed, it can jump to the partition to run. Thus, the entire system ensures that all systems and services of the system are running through the above-mentioned step-by-step guidance and step-by-step verification mechanism.

[0190] In one embodiment, after the user terminal leaves the factory, the data of each EMMC partition (kernel, rootfs and other partitions) in the user terminal includes signatures and verification values. Any data change in the partition will cause the HASH TREE of the partition to be different, and the startup verification will fail. After the rootfs is upgraded in the embodiment of the present application, not only the new HASH TREE and signature value are carried. And because the differential package carries the new HASH TREE and signature value, the new HASH TREE and signature value are the signature values ​​of the new version of the image content on the PC side. When the image content restored on the user side is different, when the SOC starts, it cannot be started because the calculated HASH TREE and signature value are different from the carried ones, making the new HASH TREE and signature value ineffective. The embodiment of the present application also removes some variable metadata through parameter limitation to ensure that the image content restored on the user side is the same, to ensure safe startup, and no signature action is required on the user side.

[0191] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0192] Embodiment 3

[0193] The present application also provides a differential upgrade device for executing the steps of the differential upgrade method of embodiment 1. The differential upgrade device may be a virtual appliance (VA) in a terminal device, which is run by a processor of the terminal device, or may be the terminal device itself.

[0194] The first differential upgrade device 100 provided in the embodiment of the present application is as follows: Fig.11 As shown, including:

[0195] The second firmware generation module 101 is used to obtain the first firmware and the second firmware in response to the user's upgrade instruction;

[0196] The differential packet generation module 102 is used to compare the first firmware with the second firmware to obtain a differential packet;

[0197] The output module 103 is used to send the differential packet to the user end so that the user end completes the upgrade.

[0198] In one embodiment, the user terminal includes a boot program partition for storing partition images, a first partition to an nth partition, and the user terminal is used to:

[0199] Restoring a third firmware that is identical to the second firmware based on the differential package and the first firmware;

[0200] Flash each partition image in the third firmware to the corresponding partition respectively;

[0201] Responding to the restart instruction from the server, restarting the device to complete the upgrade;

[0202] The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1,n].

[0203] Embodiment 4

[0204] The embodiment of the present application also provides a differential upgrade device, which is used to execute the steps in the differential upgrade method of embodiment 2. The differential upgrade device can be a virtual appliance (VA) in the terminal device, which is run by a processor of the terminal device, or it can be the terminal device itself.

[0205] The second differential upgrade device 200 provided in the embodiment of the present application is as follows: Fig.12 As shown, including:

[0206] Restoration module 201, used to restore a third firmware that is the same as the second firmware based on the first firmware and the differential packet sent by the server;

[0207] The flashing module 202 is used to flash each partition image in the third firmware to the corresponding partition respectively;

[0208] The restart module 203 is used to respond to the restart instruction of the server and restart the device to complete the upgrade;

[0209] In one embodiment, the server is used to:

[0210] In response to an upgrade instruction from a user, acquiring the first firmware and the second firmware;

[0211] Compare the first firmware with the second firmware to obtain a differential packet;

[0212] Send the differential packet to the user end so that the user end completes the upgrade;

[0213] The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a summary calculation tree of the i-th partition image, the first partition image includes a summary root of the i-th partition image and signature information of the summary root, n is an integer and n>1, i is an integer and i∈(1,n].

[0214] In application, each module in the differential upgrade device may be a software program module, or may be implemented by different logic circuits integrated in a processor, or may be implemented by multiple distributed processors.

[0215] like Fig.13 As shown, the embodiment of the present application further provides a terminal device 300, including: at least one processor 301 ( Fig.13 Only one processor is shown in the figure), a memory 302, and a computer program 303 stored in the memory 302 and executable on at least one processor 301. When the processor 301 executes the computer program 303, the steps in the above-mentioned method embodiments are implemented.

[0216] In the application, the terminal device may include, but is not limited to, a processor and a memory. Those skilled in the art will understand that Fig.13 It is only an example of a terminal device and does not constitute a limitation on the terminal device. The terminal device may include more or fewer components than shown in the figure, or a combination of certain components, or different components.

[0217] In applications, the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0218] In applications, the memory may be an internal storage unit of a terminal device in some embodiments, such as a hard disk or memory of the terminal device. In other embodiments, the memory may also be an external storage device of the terminal device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (SecureDigital, SD) card, a flash card (Flash Card), etc. equipped on the terminal device. Further, the memory may also include both an internal storage unit of the terminal device and an external storage device. The memory is used to store an operating system, an application program, a boot loader (BootLoader), data, and other programs, such as program codes of a computer program. The memory may also be used to temporarily store data that has been output or is to be output.

[0219] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0220] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0221] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0222] An embodiment of the present application provides a computer program product. When the computer program product runs on a terminal device, the terminal device can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0223] If the integrated unit is implemented in the form of 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 present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the device / terminal device, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), an electric carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0224] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0225] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0226] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0228] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A differential upgrade method, characterized in that: Applied to the server, the method includes: In response to an upgrade instruction from a user, acquiring the first firmware and the second firmware; Compare the first firmware with the second firmware to obtain a differential packet; Sending the differential packet to the user terminal so that the user terminal completes the upgrade; The user terminal includes a boot program partition for storing partition images, and first to nth partitions, and the user terminal is used to: Restoring a third firmware that is the same as the second firmware based on the differential package and the first firmware; Flashing each partition image in the third firmware to the corresponding partition respectively; Responding to the restart instruction from the server, restarting the device to complete the upgrade; The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a digest calculation tree of the i-th partition image, the first partition image includes a digest root of the i-th partition image and signature information of the digest root, n is an integer and n>1, i is an integer and i∈(1,n].

2. The differential upgrade method according to claim 1, characterized in that: Before the first firmware and the second firmware are acquired in response to the user's upgrade instruction, the method includes: Compute bootstrap summary values; Digitally signing the summary value of the boot program, and adding the digital signature and the public key of the summary value to the tail of the boot program to obtain the boot program partition image; Calculate the summary computation tree of the jth partition and obtain the summary root of the jth partition; Adding the summary computation tree of the jth partition to the tail of the jth partition to obtain a jth partition image; Digitally sign the summary root of the jth partition, and store the digital signature of the summary root, the summary root of the jth partition, and the summary computation tree offset of the jth partition in the data block corresponding to the jth partition in the first partition, where j=2, 3, ..., n; Generate the first partition image; The boot program partition image and the first partition image to the nth partition image are integrated to obtain the second firmware.

3. The differential upgrade method according to claim 1, characterized in that: The comparing the first firmware with the second firmware to obtain a differential packet includes: Decompressing the first firmware and the second firmware respectively to obtain a partition image of the first firmware and a partition image of the second firmware; Comparing the partition image of the first firmware with the partition image of the second firmware to obtain a differential file package of at least one partition among the second partition to the nth partition; Generating a differential image of at least one partition among the second partition to the nth partition based on the differential file package; Assigning entry tags to the first partition image of the second firmware and each of the differential images respectively to obtain entry headers; The differential image, the entry header, and the first partition image of the second firmware are integrated to obtain a differential package.

4. The differential upgrade method according to claim 3, characterized in that: The step of comparing the partition image of the first firmware with the partition image of the second firmware to obtain a differential file package of at least one partition among the second partition to the nth partition includes: Decompressing the jth partition image of the first firmware and the jth partition image of the second firmware respectively to obtain the jth partition directory structure of the first firmware and the jth partition directory structure of the second firmware; comparing the j-th partition directory structure of the first firmware and the j-th partition directory structure of the second firmware; When the comparison result shows that there is a difference, extracting files in the directory structure of the jth partition of the second firmware to generate a differential directory structure of the jth partition and a file directory table of the jth partition; Compressing the differential directory structure of the jth partition according to the original path to obtain a differential file package of the jth partition; Among them, j=2, 3,…, n; the differential directory structure of the jth partition includes files that have been modified or added compared to the jth partition directory structure of the first firmware; the file directory table includes the file name, file path and modification type, and the modification type is at least one of addition, modification and deletion of the jth partition directory structure of the second firmware compared to the jth partition directory structure of the first firmware.

5. The differential upgrade method according to claim 4, characterized in that: The generating of a differential image of at least one of the second partition to the nth partition based on the differential file package includes: The differential file package of the jth partition, the file directory table of the jth partition, the summary computation tree of the jth partition of the second firmware, the image check value of the jth partition of the second firmware, and the position and size of the summary computation tree of the jth partition of the second firmware are integrated to obtain the differential image of the jth partition.

6. The differential upgrade method according to claim 3, characterized in that: After the first firmware and the second firmware are decompressed respectively to obtain the partition image of the first firmware and the partition image of the second firmware, the method further includes: assigning entry marks to one or more partition images of the partition images of the second firmware whose data volume is smaller than a preset value; The differential image, the entry header, the first partition image of the second firmware, and one or more partition images in the second firmware whose data volume is less than a preset value are integrated to obtain the differential package.

7. A differential upgrade method, characterized in that: Applied to a user terminal, the user terminal includes a boot program partition for storing partition images, and a first partition to an nth partition. The method includes: Restoring a third firmware that is identical to the second firmware based on the first firmware and the differential packet sent by the server; Flashing each partition image in the third firmware to the corresponding partition respectively; Responding to the restart instruction from the server, restarting the device to complete the upgrade; The server is used to: In response to an upgrade instruction from a user, acquiring the first firmware and the second firmware; Compare the first firmware with the second firmware to obtain a differential packet; Sending the differential packet to the user terminal so that the user terminal completes the upgrade; The second firmware includes a boot program partition image, a first partition image to an nth partition image, the tail of the i-th partition image includes a digest calculation tree of the i-th partition image, the first partition image includes a digest root of the i-th partition image and signature information of the digest root, n is an integer and n>1, i is an integer and i∈(1,n].

8. The differential upgrade method according to claim 7, characterized in that: The method of restoring a third firmware identical to the second firmware based on the first firmware and the differential packet sent by the server includes: Decompressing the first firmware to obtain a partition image of the first firmware; Decompressing the differential package to obtain a differential image, an entry header, and a first partition image of the second firmware; Replacing the partition image of the first firmware with the first partition image of the second firmware to obtain the first partition image of the third firmware; Decompress the differential image of the kth partition to obtain the differential file package of the kth partition; Restoring the kth partition image of the first firmware using the differential file package of the kth partition to obtain the kth partition image of the third firmware; The summary computation tree of the kth partition in the differential package is stored at the tail of the kth partition image according to the position and size of the summary computation tree of the kth partition; Integrate all partition images of the third firmware to obtain the third firmware; Among them, k = 2, 3,…, n.

9. The differential upgrade method according to claim 8, characterized in that: Before integrating all partition images of the third firmware to obtain the third firmware, the method further includes: Decompressing the differential package to obtain one or more partition images in the second firmware whose data volume is less than a preset value; One or more partition images in the second firmware whose data volume is smaller than a preset value are used to replace the corresponding partition images in the first firmware, so as to obtain one or more partition images in the third firmware whose data volume is smaller than a preset value.

10. The differential upgrade method according to claim 8, characterized in that: The method of restoring the kth partition image of the first firmware by using the differential file package of the kth partition to obtain the kth partition image of the third firmware includes: Decompressing the kth partition image of the first firmware to obtain a directory structure of the kth partition; Decompressing the differential file package of the kth partition to obtain the differential directory structure of the kth partition; Decompress the differential image of the kth partition to obtain the file directory table of the kth partition; Based on the differential directory structure and the file directory table of the kth partition, at least one operation of adding, modifying, and deleting corresponding files in the directory structure of the kth partition is performed to obtain the directory structure of the kth partition of the third firmware; The kth partition directory structure of the third firmware is compressed according to the original path to obtain the kth partition image of the third firmware.

11. The differential upgrade method according to claim 8, characterized in that: Before storing the summary computation tree of the kth partition in the differential package into the tail of the kth partition image according to the position and size of the summary computation tree of the kth partition, the method further includes: Performing checksum calculation on the kth partition image of the third firmware; Compare the calculated checksum value with the checksum value of the kth partition image; If the calculated check value is consistent with the check value of the kth partition image, the summary calculation tree of the kth partition in the differential package is stored at the tail of the kth partition image according to the position and size of the summary calculation tree of the kth partition; The checksum value of the kth partition image is obtained by decompressing the differential image of the kth partition.

12. The differential upgrade method according to claim 7, characterized in that: The step of responding to the restart instruction of the server and restarting the device to complete the upgrade includes: Responding to the restart instruction from the server, executing device restart; Running a program of the system-on-chip, calculating a digest value of the public key in the boot program partition, and comparing the digest value with the digest value stored in the system-on-chip; If the calculated digest value of the public key is consistent with the digest value stored in the system-level chip, then the digest value of the boot program partition image is calculated and compared with the digest value obtained by decrypting the public key; If the calculated digest value of the boot program partition image is consistent with the digest value decrypted using the public key, then running the program of the boot program partition; Obtaining a digital signature of a summary root of the jth partition from the jth partition, and decrypting the digital signature using the public key to obtain a summary root of the jth partition; Compare the digest root of the jth partition obtained by decryption with the digest root stored in the jth partition; If the digest root of the jth partition obtained by the decryption is consistent with the digest root stored in the jth partition, verifying the image content of the jth partition by using the digest root of the jth partition and the digest computation tree pointed to by the digest computation tree offset of the jth partition; If the verification passes, the program in the jth partition is run; Among them, j=2,3,…,n.

13. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the terminal device is a server, the processor implements the steps of the method according to any one of claims 1 to 6 when executing the computer program; When the terminal device is a user end, the processor implements the steps of the method according to any one of claims 7 to 12 when executing the computer program.

Images