CN108920962B - Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server - Google Patents

Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server Download PDF

Info

Publication number
CN108920962B
CN108920962B CN201810671878.6A CN201810671878A CN108920962B CN 108920962 B CN108920962 B CN 108920962B CN 201810671878 A CN201810671878 A CN 201810671878A CN 108920962 B CN108920962 B CN 108920962B
Authority
CN
China
Prior art keywords
firmware
sub
downloading
mobile terminal
downloaded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810671878.6A
Other languages
Chinese (zh)
Other versions
CN108920962A (en
Inventor
李泽锦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PAX Computer Technology Shenzhen Co Ltd
Original Assignee
PAX Computer Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by PAX Computer Technology Shenzhen Co Ltd filed Critical PAX Computer Technology Shenzhen Co Ltd
Priority to CN201810671878.6A priority Critical patent/CN108920962B/en
Publication of CN108920962A publication Critical patent/CN108920962A/en
Priority to PCT/CN2019/081043 priority patent/WO2020001111A1/en
Application granted granted Critical
Publication of CN108920962B publication Critical patent/CN108920962B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572Secure firmware programming, e.g. of basic input output system [BIOS]

Abstract

The application is applicable to the technical field of data processing, and provides a firmware downloading and signing checking method, a firmware publishing method, a mobile terminal, a server and a computer readable storage medium, wherein the firmware downloading and signing checking method comprises the following steps: the method comprises the steps of downloading sub-firmware of the firmware to be downloaded from a preset server, wherein the sub-firmware is obtained after the firmware to be downloaded is split, after the downloading of each sub-firmware is finished, verifying and signing the sub-firmware which is downloaded at the current end, burning the sub-firmware which is successfully verified and signed at the current time if the verification and signing of the current sub-firmware are successful, and forbidding burning of the sub-firmware which is unsuccessfully verified and signed at the current time and stopping the downloading of other sub-firmware in the firmware to be downloaded.

Description

Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server
Technical Field
The application belongs to the technical field of data processing, and particularly relates to a firmware downloading and signing checking method, a firmware publishing method, a mobile terminal and a server.
Background
The firmware refers to a device "driver" stored in the device, and the operating system can realize the running action of a specific machine according to the standard device driver through the firmware. Img firmware packages are not downloaded and verified, but as the requirement for security becomes higher and higher, many devices (such as pos machines and the like) require that the downloading of each firmware of the devices must have security, so that a security verification function for each firmware needs to be added.
Generally, the system img firmware is signed as a whole, then downloaded to a Random Access Memory (RAM) of the mobile terminal for signature verification, and written into a flash after the signature verification is passed. However, as the android system is upgraded, the system.img firmware is very large, so that the system.img firmware cannot be downloaded to the random access memory at one time, and cannot be written into the flash after the system.img firmware downloads the check label, and thus, potential safety hazards exist in the process of downloading the check label of the firmware.
Disclosure of Invention
In view of this, embodiments of the present application provide a firmware downloading and signing method, a firmware publishing method, a mobile terminal, a server, and a computer-readable storage medium, so as to solve the problem of potential safety hazard in the current firmware downloading and signing process.
A first aspect of an embodiment of the present application provides a method for downloading and verifying firmware, which is applied to a mobile terminal, and the method includes:
downloading a sub-firmware of a firmware to be downloaded from a preset server, wherein the sub-firmware is obtained after the firmware to be downloaded is split;
after downloading of each sub-firmware is finished, verifying and signing the sub-firmware which is downloaded at present;
if the current sub-firmware successfully verifies the signature, burning the sub-firmware successfully verified and signed currently;
and if the current sub-firmware fails to verify the signature, prohibiting the sub-firmware with the current signature verification failure from burning, and stopping downloading of other sub-firmware in the firmware to be downloaded.
A second aspect of the embodiments of the present application provides a firmware publishing method, which is applied to a server, and the publishing method includes:
receiving a downloading request of a firmware sent by a mobile terminal, wherein the downloading request comprises a maximum random access memory of the mobile terminal;
judging whether the maximum random access memory is smaller than the size of the firmware;
if the maximum random access memory is smaller than the size of the firmware, splitting the firmware into at least two sub-firmware which are not larger than the maximum random access memory, and sending the sub-firmware to the mobile terminal;
and if the maximum random access memory is larger than or equal to the size of the firmware, sending the firmware to the mobile terminal.
A third aspect of an embodiment of the present application provides a mobile terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of the method provided in the first aspect of the embodiment of the present application when executing the computer program.
A fourth aspect of embodiments of the present application provides a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method provided by the second aspect of embodiments of the present application when executing the computer program.
A fifth aspect of embodiments of the present application provides a computer-readable storage medium storing a computer program that, when executed by one or more processors, performs the steps of the method provided by the first aspect or the steps of the method provided by the second aspect of embodiments of the present application.
The method comprises the steps that a server side where firmware is located can divide the firmware into a plurality of sub-firmware, when the mobile terminal downloads the firmware to be downloaded from the server side, the sub-firmware of the firmware to be downloaded can be downloaded, after the downloading of each sub-firmware is finished, verification signature is carried out on the currently downloaded sub-firmware, and only after the verification signature of the current sub-firmware is successful, the sub-firmware with the verification signature is burned; and if the current sub-firmware fails to verify the signature, prohibiting the sub-firmware with the current signature verification failure from burning, and stopping downloading of other sub-firmware in the firmware to be downloaded. The method comprises the steps of splitting a firmware to be downloaded into a plurality of sub-firmware, downloading the sub-firmware into the random storage memory, verifying and signing the sub-firmware after downloading one sub-firmware, burning the sub-firmware in the random storage memory if the verification and signing are successful, and continuously downloading other sub-firmware, so that the sub-firmware is downloaded into the random storage memory firstly, and burning is carried out after the verification and signing pass, and the safety verification of the firmware is ensured.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
Fig. 1 is a schematic flow chart of an implementation of a method for verifying a firmware download according to an embodiment of the present application;
fig. 2 is a schematic flowchart illustrating an implementation flow of a firmware publishing method according to an embodiment of the present application;
FIG. 3 is a schematic flowchart illustrating an implementation flow of another method for verifying a firmware download according to an embodiment of the present application;
fig. 4 is a schematic block diagram of a mobile terminal according to an embodiment of the present application;
fig. 5 is a schematic block diagram of a server provided in an embodiment of the present application;
fig. 6 is a schematic block diagram of another mobile terminal provided in an embodiment of the present application;
fig. 7 is a schematic block diagram of another server provided in the embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the present application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the present application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
It should be further understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".
In this embodiment of the application, the mobile terminal may be a mobile terminal based on an android system, and the PCI security requires that the android system. Then, with the continuous upgrade of the android system, the increase of the system.img firmware also occurs, and for some older models, the Random Access Memory (RAM) is smaller, and at this time, the system.img firmware cannot be downloaded to the RAM at one time, that is, the system.img firmware cannot be written into the flash memory after all verification passes, only a part of the system is downloaded and written into a part of the flash memory, and the system img firmware is verified after all downloading is finished, so that if the system is illegally signed, but the image file is written into the flash memory, the original system is destroyed as soon as possible, and therefore, the potential safety hazard exists.
Fig. 1 is a schematic flow chart of an implementation process of a method for downloading a firmware verification tag, which is applied to a mobile terminal side and includes the following steps:
step S101, downloading a sub-firmware of a firmware to be downloaded from a preset server, wherein the sub-firmware is obtained after the firmware to be downloaded is split.
In this embodiment of the application, the server may split the firmware into a plurality of sub-firmware in advance, the size of the sub-firmware may be set, for example, the sub-firmware is split into a plurality of sub-firmware not greater than 500M, the server may store the sub-firmware in a memory of the server, and the sub-firmware of the firmware to be downloaded is an independent signature. When the mobile terminal downloads the firmware to be downloaded from the server, the plurality of sub-firmware split from the firmware to be downloaded need to be downloaded.
The server may be provided with a function of splitting the firmware into a plurality of sub-firmware and signing each sub-firmware, or an offline device (for example, a computer used by a developer) may split the firmware into a plurality of sub-firmware and sign the sub-firmware, and then upload the sub-firmware to the server for storage, which is not limited herein.
And step S102, after the downloading of each sub-firmware is finished, verifying and signing the currently downloaded sub-firmware.
In the embodiment of the application, when the sub-firmware of the firmware to be downloaded is downloaded, the sub-firmware can be downloaded one by one. Since the sub-firmware is independently signed, after downloading one sub-firmware, the signature is verified for the sub-firmware which is currently downloaded. And after the signature is verified, other sub-firmware of the firmware to be downloaded can be continuously downloaded.
Step S103, if the current sub-firmware successfully verifies the signature, burning the sub-firmware successfully verified and signed currently.
In the embodiment of the application, after the current sub-firmware verifies the signature successfully, the sub-firmware with the successfully verified signature can be burned, the burning operation can be to write the sub-firmware with the successfully verified signature into the flash memory, delete the sub-firmware stored in the RAM and just written into the flash memory after the sub-firmware is written into the flash memory, and continue to download other un-downloaded sub-firmware after the RAM space is empty.
By way of example, assume that the firmware to be downloaded is split into 3 sub-firmware, sub-firmware a, sub-firmware B, and sub-firmware C, respectively.
After downloading the sub-firmware a (downloading into the RAM of the mobile terminal), signature verification may be performed on the downloaded sub-firmware a, and if the signature verification passes, the sub-firmware a in the RAM is written into the flash memory, and the sub-firmware a in the RAM is deleted.
And continuously downloading the sub-firmware B, continuously performing signature verification on the sub-firmware B after the sub-firmware B is downloaded, and writing the sub-firmware B in the RAM into the flash memory if the signature verification is passed, and deleting the sub-firmware B in the RAM.
……
And step S104, if the current sub-firmware fails to verify the signature, prohibiting the sub-firmware with the current signature verification failure from burning, and stopping downloading other sub-firmware in the firmware to be downloaded.
In the embodiment of the application, if the current sub-firmware fails to verify the signature, it indicates that the current sub-firmware is an illegal signature, and the illegally signed sub-firmware may cause potential safety hazards to the system, and at this time, it is necessary to prohibit the sub-firmware that fails to verify the signature from being burned, that is, prohibit the sub-firmware that fails to verify the signature from being written into the flash memory, and stop the downloading operation of other sub-firmware that is not downloaded in the firmware to be downloaded.
Still by way of example, if the result of the verification signature performed by the sub-firmware B is that the verification fails, the sub-firmware B is prohibited from being written into the flash memory, the sub-firmware B in the RAM is deleted, and the subsequent downloading of the sub-firmware is stopped, that is, the downloading operation of the remaining sub-firmware (sub-firmware C) is stopped.
The method comprises the steps of splitting a firmware to be downloaded into a plurality of sub-firmware, downloading the sub-firmware into the random storage memory, verifying and signing the sub-firmware after downloading one sub-firmware, burning the sub-firmware in the random storage memory if the verification and signing are successful, and continuously downloading other sub-firmware, so that the sub-firmware is downloaded into the random storage memory firstly, and burning is carried out after the verification and signing pass, and the safety verification of the firmware is ensured.
The embodiment shown in fig. 1 is described from a mobile terminal side, and the sub-firmware of the firmware to be downloaded may be stored in a server after being split in advance, or in practical application, the server may be split according to a random storage memory of the mobile terminal to download the firmware, and the embodiments shown in fig. 2 and fig. 3 respectively describe the embodiment of the present application from the server side and the mobile terminal side.
Fig. 2 is a schematic implementation flow diagram of a firmware publishing method provided in an embodiment of the present application, and is applied to a server side, where as shown in the figure, the method may include the following steps:
step S201, receiving a downloading request of a firmware sent by a mobile terminal, where the downloading request includes a maximum random access memory of the mobile terminal.
In this embodiment of the application, the firmware stored at the server side may be an undetached firmware package, and after the server receives a request for downloading the firmware sent by the mobile terminal, the request for downloading the firmware sent by the mobile terminal includes a name of the firmware to be downloaded and a maximum random access memory (a current maximum available space of the RAM) of the mobile terminal.
Step S202, judging whether the maximum random access memory is smaller than the size of the firmware.
In the embodiment of the application, whether the maximum random access memory of the mobile terminal is smaller than the size of the firmware to be downloaded can be judged. Namely, whether the mobile terminal can download the firmware to be downloaded to the current available space of the random storage space at one time is judged.
Step S203, if the maximum ram is smaller than the size of the firmware, splitting the firmware into at least two sub-firmware not larger than the maximum ram, and sending the sub-firmware to the mobile terminal.
In this embodiment of the application, if the maximum ram is smaller than the size of the firmware, it indicates that the mobile terminal cannot download the firmware to be downloaded to the current available space of the ram at one time, and the firmware to be downloaded needs to be split into at least two sub-firmware that is not larger than the maximum ram.
The split sub-firmware contains header information, which includes: the size of the sub-firmware, the serial number of the sub-firmware and the download address of the sub-firmware; the download address may download an offset. The server can send the sub-firmware to the mobile terminal according to the serial number of the split sub-firmware. Or waiting for the mobile terminal to download the split sub-firmware in sequence according to the serial number of the split sub-firmware.
It should be noted that, in order to ensure system security of the mobile terminal, after the firmware to be downloaded is split into a plurality of sub-firmware, each sub-firmware needs to be signed independently. I.e. each sub-firmware is signed separately.
Step S204, if the maximum random access memory is larger than or equal to the size of the firmware, the firmware is sent to the mobile terminal.
In this embodiment of the application, if the maximum ram is greater than or equal to the size of the firmware, it indicates that the mobile terminal may download the firmware to be downloaded to the current available space of the ram space at one time, and at this time, the server side may not split the firmware to be downloaded.
Fig. 3 is a schematic implementation flow diagram of a method for verifying firmware download provided in an embodiment of the present application, and is applied to a mobile terminal, where as shown in the figure, the method may include the following steps:
step S301, sending a download request of the firmware to be downloaded to a preset server, where the download request includes: and the maximum random access memory supported by the mobile terminal.
In this embodiment of the application, when a mobile terminal needs to download a firmware, a download request of the firmware to be downloaded is first sent to a preset server, and in order to ensure that when the firmware to be downloaded is split into a plurality of sub-firmware by one side of the server, the size of each sub-firmware is smaller than the maximum capacity allowed to be used in a random access memory of the mobile terminal, the maximum random access memory supported by the mobile terminal may be sent while the download request is sent.
After receiving the download request, the server may split the firmware to be downloaded into at least two sub-firmware, and sign each sub-firmware respectively. Therefore, the download request is used to instruct the server to split the stored firmware into at least two sub-firmware, and then to sign each sub-firmware.
In order to ensure that the sub-firmware split by the server can be downloaded to the random storage memory of the mobile terminal at one time, the process of splitting the sub-firmware by the server is as follows: and splitting the firmware to be downloaded into at least two sub-firmware which is not more than the maximum random access memory according to the maximum random access memory supported by the mobile terminal. Therefore, the download request is further used to instruct the server to split the firmware to be downloaded into at least two sub-firmware not greater than the maximum random access memory according to the maximum random access memory supported by the mobile terminal.
The sub-firmware contains header information including: the size of the sub-firmware, the serial number of the sub-firmware and the download address of the sub-firmware.
And step S302, downloading the sub-firmware of the firmware to be downloaded to the random storage memory of the mobile terminal from the download address of the sub-firmware in sequence according to the serial number of the sub-firmware from a preset server.
In this embodiment of the application, after the server is split, the mobile terminal may download the split sub-firmware from the server, and the downloading process needs to download the sub-firmware in sequence according to the serial number of the sub-firmware, for example, the serial number is 1 to 5, and then needs to download the sub-firmware from low to high according to the serial number of the sub-firmware, and since the header information of each sub-firmware further includes the download address of the sub-firmware, the sub-firmware of the firmware to be downloaded is downloaded to the random storage memory of the mobile terminal from the download address of the sub-firmware in sequence according to the serial number of the sub-firmware.
In step S303, after each sub-firmware is downloaded, the verification signature is performed on the currently downloaded sub-firmware.
In step S304, if the current sub-firmware successfully verifies the signature, the sub-firmware successfully verified and signed currently is burned.
Step S305, if the current sub-firmware fails to verify the signature, the sub-firmware that fails to verify the signature is prohibited from being burned, and the downloading of other sub-firmware in the firmware to be downloaded is stopped.
Step S303 to step S305 can refer to the description of step S102 to step S104, and are not described herein again.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
Fig. 4 is a schematic block diagram of a mobile terminal according to an embodiment of the present application, and only a portion related to the embodiment of the present application is shown for convenience of description.
The mobile terminal 4 may be a software unit, a hardware unit or a combination of software and hardware unit built in a mobile terminal such as a mobile phone and a tablet computer, or may be integrated into the mobile terminal such as the mobile phone and the tablet computer as an independent pendant.
The mobile terminal 4 includes:
a downloading module 41, configured to download a sub-firmware of a firmware to be downloaded from a preset server, where the sub-firmware is obtained after splitting the firmware to be downloaded;
the signature verification module 42 is configured to verify and sign the sub-firmware that is downloaded currently after each sub-firmware is downloaded;
the burning module 43 is configured to burn the sub-firmware with the successfully verified signature if the signature of the current sub-firmware is successfully verified;
and the prohibiting module 44 is configured to prohibit the sub-firmware with the current signature verification failure from being burned and stop downloading of other sub-firmware in the firmware to be downloaded, if the current sub-firmware fails to verify the signature.
Optionally, the sub-firmware of the firmware to be downloaded is an independent signature.
Optionally, the sub-firmware includes header information, where the header information includes: the size of the sub-firmware, the serial number of the sub-firmware and the download address of the sub-firmware;
correspondingly, the downloading module 41 is further configured to:
and downloading the sub-firmware of the firmware to be downloaded to a random storage memory of the mobile terminal from the download address of the sub-firmware in sequence from a preset server according to the serial number of the sub-firmware.
Optionally, the mobile terminal 4 further includes:
the request module 45 is configured to send a downloading request of the firmware to be downloaded to a preset server before downloading the sub-firmware of the firmware to be downloaded from the preset server, where the downloading request is used to instruct the server to split the stored firmware into at least two sub-firmware, and then sign each sub-firmware.
Optionally, the download request includes: the maximum random access memory supported by the mobile terminal;
the downloading request is used for indicating the server to split the firmware to be downloaded into at least two sub-firmware which are not larger than the maximum random access memory according to the maximum random access memory supported by the mobile terminal.
Fig. 5 is a schematic block diagram of a server provided in an embodiment of the present application, and only a part related to the embodiment of the present application is shown for convenience of explanation.
The server 5 may be a software unit, a hardware unit, or a combination of software and hardware unit built in a server such as a server, or may be integrated as a separate pendant into the server such as the server.
The server 5 includes:
a receiving module 51, configured to receive a downloading request of a firmware sent by a mobile terminal, where the downloading request includes a maximum random access memory of the mobile terminal;
a determining module 52, configured to determine whether the maximum random access memory is smaller than the size of the firmware;
a splitting module 53, configured to split the firmware into at least two sub-firmware that are not greater than the maximum ram if the maximum ram is smaller than the size of the firmware, and send the sub-firmware to the mobile terminal;
a sending module 54, configured to send the firmware to the mobile terminal if the maximum random access memory is greater than or equal to the size of the firmware.
Optionally, the server 5 further includes:
the signature module is used for respectively signing each sub-firmware of the firmware before sending the sub-firmware to the mobile terminal;
optionally, the sub-firmware includes header information, where the header information includes: the size of the sub-firmware, the serial number of the sub-firmware and the download address of the sub-firmware.
It will be apparent to those skilled in the art that, for convenience and simplicity of description, the foregoing functional units and modules are merely illustrated in terms of division, and in practical applications, the foregoing functional allocation may be performed by different functional units and modules as needed, that is, the internal structure of the mobile terminal or the server is divided into different functional units or modules to perform all or part of the above described functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the mobile terminal or the server may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
Fig. 6 is a schematic block diagram of a mobile terminal according to another embodiment of the present application. As shown in fig. 6, the mobile terminal 6 of this embodiment includes: one or more processors 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processors 60. The processor 60, when executing the computer program 62, implements the steps in the above-described respective camera control method embodiments, such as steps S101 to S104 shown in fig. 1. Alternatively, the processor 60, when executing the computer program 62, implements the functions of the modules/units in the above-described mobile terminal embodiments, such as the functions of the modules 41 to 44 shown in fig. 4.
Illustratively, the computer program 62 may be partitioned into one or more modules/units that are stored in the memory 61 and executed by the processor 60 to accomplish the present application. The one or more modules/units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution of the computer program 62 in the mobile terminal 6. For example, the computer program 62 may be divided into a download module, a signature verification module, a burn module, and a disable module.
The downloading module is used for downloading the sub-firmware of the firmware to be downloaded from a preset server, wherein the sub-firmware is obtained after the firmware to be downloaded is split;
the signature verification module is used for verifying and signing the sub-firmware which is downloaded currently after the downloading of each sub-firmware is finished;
the burning module is used for burning the sub-firmware with the signature successfully verified at present if the signature successfully verified at present;
and the forbidding module is used for forbidding the sub-firmware with the current signature verification failure to be burned and stopping downloading of other sub-firmware in the firmware to be downloaded if the current sub-firmware fails to verify the signature.
Other modules or units can refer to the description of the embodiment shown in fig. 4, and are not described again here.
The mobile terminal includes, but is not limited to, a processor 60, a memory 61. Those skilled in the art will appreciate that fig. 6 is only one example of a mobile terminal 6 and does not constitute a limitation of the mobile terminal 6 and may include more or less components than those shown, or some components may be combined, or different components, e.g., the mobile terminal may also include input devices, output devices, network access devices, buses, etc.
The Processor 60 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 61 may be an internal storage unit of the mobile terminal 6, such as a hard disk or a memory of the mobile terminal 6. The memory 61 may also be an external storage device of the mobile terminal 6, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) and the like provided on the mobile terminal 6. Further, the memory 61 may also include both an internal storage unit and an external storage device of the mobile terminal 6. The memory 61 is used for storing the computer program and other programs and data required by the mobile terminal. The memory 61 may also be used to temporarily store data that has been output or is to be output.
Fig. 7 is a schematic block diagram of a server provided in another embodiment of the present application. As shown in fig. 7, the server 7 of this embodiment includes: one or more processors 70, a memory 71, and a computer program 72 stored in the memory 71 and executable on the processors 70. The processor 70, when executing the computer program 72, implements the steps in the above-described respective camera control method embodiments, such as the steps S201 to S204 shown in fig. 1. Alternatively, the processor 70, when executing the computer program 72, implements the functions of the modules/units in the server embodiment described above, such as the functions of the modules 51 to 54 shown in fig. 5.
Illustratively, the computer program 72 may be partitioned into one or more modules/units that are stored in the memory 71 and executed by the processor 70 to accomplish the present application. The one or more modules/units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution of the computer program 72 in the server 7. For example, the computer program 72 may be divided into a receiving module, a determining module, a splitting module, and a sending module.
The receiving module is used for receiving a downloading request of the firmware sent by the mobile terminal, wherein the downloading request comprises a maximum random access memory of the mobile terminal;
the judging module is used for judging whether the maximum random access memory is smaller than the size of the firmware;
the splitting module is configured to split the firmware into at least two sub-firmware not greater than the maximum random access memory if the maximum random access memory is smaller than the size of the firmware, and send the sub-firmware to the mobile terminal;
the sending module is configured to send the firmware to the mobile terminal if the maximum random access memory is greater than or equal to the size of the firmware.
Other modules or units can refer to the description of the embodiment shown in fig. 5, and are not described again here.
The server 7 may also include, but is not limited to, a processor and a memory, as in the mobile terminal 6 shown in fig. 6. It will be appreciated by those skilled in the art that fig. 7 is only one example of a server and does not constitute a limitation of the server 7, and that it may comprise more or less components than those shown, or some components may be combined, or different components, e.g. the mobile terminal may further comprise input devices, output devices, network access devices, buses, etc.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed mobile terminal, server and method may be implemented in other ways. For example, the above-described embodiments of a mobile terminal or server are merely illustrative, and for example, the division of the modules or units is only one logical division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain other components which may be suitably increased or decreased as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media which may not include electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims (8)

1. A method for downloading and verifying firmware is applied to a mobile terminal and comprises the following steps:
downloading a sub-firmware of a firmware to be downloaded from a preset server, wherein the sub-firmware is obtained after the firmware to be downloaded is split;
after downloading of each sub-firmware is finished, verifying and signing the sub-firmware which is downloaded at present;
if the current sub-firmware successfully verifies the signature, burning the sub-firmware successfully verified and signed currently;
if the current sub-firmware fails to verify the signature, the sub-firmware failing to verify the signature is prohibited from burning, and downloading of other sub-firmware in the firmware to be downloaded is stopped;
before downloading the sub-firmware of the firmware to be downloaded from the preset server, the method further comprises the following steps:
sending a downloading request of the firmware to be downloaded to the preset server, wherein the downloading request is used for instructing the server to split the stored firmware into at least two sub-firmware and then respectively signing each sub-firmware;
the download request further comprises: the maximum random access memory supported by the mobile terminal;
the downloading request is also used for indicating the server to split the firmware to be downloaded into at least two sub-firmware which are not larger than the maximum random access memory when the size of the maximum random access memory supported by the mobile terminal is judged to be smaller than that of the firmware by the server; the size of the sub-firmware can be set arbitrarily.
2. The method for verifying the firmware downloading as claimed in claim 1, wherein the sub-firmware of the firmware to be downloaded is independently signed.
3. The method for downloading a signature for firmware of claim 2, wherein said sub-firmware comprises header information comprising: the size of the sub-firmware, the serial number of the sub-firmware and the download address of the sub-firmware;
correspondingly, the downloading of the sub-firmware of the firmware to be downloaded from the preset server includes:
and downloading the sub-firmware of the firmware to be downloaded to a random storage memory of the mobile terminal from the download address of the sub-firmware in sequence from a preset server according to the serial number of the sub-firmware.
4. A firmware publishing method is applied to a server, and comprises the following steps:
receiving a downloading request of a firmware sent by a mobile terminal, wherein the downloading request comprises a maximum random access memory of the mobile terminal;
judging whether the maximum random access memory is smaller than the size of the firmware;
if the maximum random access memory is smaller than the size of the firmware, splitting the firmware into at least two sub-firmware which are not larger than the maximum random access memory, and sending the sub-firmware to the mobile terminal;
and if the maximum random access memory is larger than or equal to the size of the firmware, sending the firmware to the mobile terminal.
5. The firmware distribution method according to claim 4, wherein before sending the sub-firmware to the mobile terminal, the method further comprises:
signing each sub-firmware of the firmware respectively;
the sub-firmware includes header information including: the size of the sub-firmware, the serial number of the sub-firmware and the download address of the sub-firmware.
6. A mobile terminal, characterized in that it comprises a memory, a processor and a computer program stored in said memory and executable on said processor, characterized in that said processor, when executing said computer program, implements the steps of the method according to any one of claims 1 to 3.
7. A server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 4 to 5 when executing the computer program.
8. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by one or more processors, implements the steps of the method according to any one of claims 1 to 3 or the steps of the method according to any one of claims 4 to 5.
CN201810671878.6A 2018-06-26 2018-06-26 Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server Active CN108920962B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201810671878.6A CN108920962B (en) 2018-06-26 2018-06-26 Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server
PCT/CN2019/081043 WO2020001111A1 (en) 2018-06-26 2019-04-02 Signature verification method for downloading firmware, firmware release method, mobile terminal and server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810671878.6A CN108920962B (en) 2018-06-26 2018-06-26 Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server

Publications (2)

Publication Number Publication Date
CN108920962A CN108920962A (en) 2018-11-30
CN108920962B true CN108920962B (en) 2020-06-26

Family

ID=64422617

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810671878.6A Active CN108920962B (en) 2018-06-26 2018-06-26 Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server

Country Status (2)

Country Link
CN (1) CN108920962B (en)
WO (1) WO2020001111A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108920962B (en) * 2018-06-26 2020-06-26 百富计算机技术(深圳)有限公司 Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server
CN113239361A (en) * 2021-05-06 2021-08-10 国家计算机网络与信息安全管理中心 Firmware safety detection method, device, equipment and storage medium
CN114726884B (en) * 2022-06-06 2022-09-27 深圳市佑荣信息科技有限公司 Financial-grade file safe storage method and system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101373440A (en) * 2008-10-09 2009-02-25 北京飞天诚信科技有限公司 Method and device for processing firmware upgrading data
CN101515967A (en) * 2009-03-18 2009-08-26 中兴通讯股份有限公司 Over-the-air downloader of terminal firmware and method thereof
CN107194242A (en) * 2017-03-30 2017-09-22 百富计算机技术(深圳)有限公司 Firmware upgrade method and device
CN108108193A (en) * 2016-11-24 2018-06-01 厦门脉视数字技术有限公司 A kind of easy-to-use firmware upgrade method of safety and system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101694622A (en) * 2009-09-29 2010-04-14 中兴通讯股份有限公司 Remote firmware upgrading method of multi-device combination equipment and system thereof
US8856536B2 (en) * 2011-12-15 2014-10-07 GM Global Technology Operations LLC Method and apparatus for secure firmware download using diagnostic link connector (DLC) and OnStar system
US9418229B2 (en) * 2013-10-28 2016-08-16 Disney Enterprises, Inc. Firmware security
CN104506515A (en) * 2014-12-17 2015-04-08 北京极科极客科技有限公司 Firmware protection method and firmware protection device
CN108021410A (en) * 2017-12-06 2018-05-11 九阳股份有限公司 A kind of firmware upgrade method and system of intelligent appliance equipment
CN108196863A (en) * 2018-01-15 2018-06-22 深圳市共进电子股份有限公司 A kind of upgrade method of firmware, device, terminal and storage medium
CN108920962B (en) * 2018-06-26 2020-06-26 百富计算机技术(深圳)有限公司 Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101373440A (en) * 2008-10-09 2009-02-25 北京飞天诚信科技有限公司 Method and device for processing firmware upgrading data
CN101515967A (en) * 2009-03-18 2009-08-26 中兴通讯股份有限公司 Over-the-air downloader of terminal firmware and method thereof
CN108108193A (en) * 2016-11-24 2018-06-01 厦门脉视数字技术有限公司 A kind of easy-to-use firmware upgrade method of safety and system
CN107194242A (en) * 2017-03-30 2017-09-22 百富计算机技术(深圳)有限公司 Firmware upgrade method and device

Also Published As

Publication number Publication date
WO2020001111A1 (en) 2020-01-02
CN108920962A (en) 2018-11-30

Similar Documents

Publication Publication Date Title
US11221838B2 (en) Hot update method, operating system, terminal device, system, and computer-readable storage medium for a system process
CN108920962B (en) Firmware downloading and signing checking method, firmware publishing method, mobile terminal and server
US20190205539A1 (en) Method and device for verifying upgrade of diagnosis connector of diagnostic equipment, and diagnosis connector
CN112000382B (en) Linux system starting method and device and readable storage medium
CN112231702A (en) Application protection method, device, equipment and medium
CN105468401A (en) Nfc device, software installation method and software uninstallation method
US8874927B2 (en) Application execution system and method of terminal
CN111176685A (en) Upgrading method and device
US20070288664A1 (en) Apparatus and method of securely moving security data
CN111046377B (en) Method and device for loading dynamic link library, electronic equipment and storage medium
CN107528713B (en) A kind of upgrade method and device of data transfer SDK
CN107368337B (en) Application downloading method and device and terminal equipment
CN115688120A (en) Secure chip firmware importing method, secure chip and computer readable storage medium
US20150113284A1 (en) Method and apparatus for protecting application program
CN106569841A (en) File loading method and device
CN109472148B (en) Method, device and storage medium for loading hot patch
CN111026609B (en) Information auditing method, system, equipment and computer readable storage medium
CN112035127B (en) Method and device for installing application, vehicle, storage medium and electronic equipment
CN107274589B (en) Access method and system of financial self-service terminal hardware equipment and terminal equipment
CN111338674A (en) Instruction processing method, device and equipment
CN107295177B (en) Application disabling method and device and terminal equipment
CN111198723B (en) Process injection method, terminal equipment and computer readable storage medium
CN110941835B (en) Data processing method and electronic equipment
CN113934453B (en) Risk detection method, risk detection device and storage medium
CN113867826A (en) Extended package access control method and device, Java smart card and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant