Firmware processing method, device and electronic equipment

Abstract

Embodiments of the present invention provide a firmware processing method, apparatus, and electronic device, applicable to the field of computer technology. The method comprises: obtaining a firmware file to be verified; the firmware file includes firmware data and signature data; parsing the signature data and the firmware data from the firmware file when the current version information of the firmware file matches the target version information to be updated; and performing a security verification on the firmware file based on the verification values corresponding to the signature data and the firmware data. Embodiments of the present invention improve the accuracy and efficiency of firmware verification.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a firmware processing method, device, and electronic equipment. Background Art

[0002] The Basic Input / Output System (BIOS) is a set of program firmware embedded in the motherboard's Read-Only Memory (ROM) chip. It stores the computer's basic input / output programs, the power-on self-test program, and the system startup program. The BIOS firmware provides the lowest-level and most direct hardware settings and control for the computer.

[0003] With the continuous development of information technology and the internet, BIOS firmware versions are increasing. However, during the BIOS firmware update process, firmware data may be corrupted due to transmission errors or malicious tampering, resulting in inconsistencies between the firmware data received by the device and the original firmware data, thus affecting the firmware update. Furthermore, firmware data may be forged or tampered with, posing a security threat to the device.

[0004] In order to ensure the data integrity and security of firmware updates, an effective verification method is needed to identify possible risks during the firmware update process. Summary of the Invention

[0005] Embodiments of the present invention provide a firmware processing method, device, and electronic device, which can solve the problem of security risks in the firmware update process in related technologies.

[0006] In one aspect, an embodiment of the present invention discloses a firmware processing method, the method comprising:

[0007] Obtaining a firmware file to be verified; the firmware file includes firmware data and signature data; the signature data is obtained by signing the firmware data during the firmware file generation phase;

[0008] parsing the signature data and the firmware data from the firmware file when the current version information of the firmware file matches the target version information to be updated;

[0009] A security check is performed on the firmware file according to the check values corresponding to the signature data and the firmware data.

[0010] On the other hand, an embodiment of the present invention discloses a firmware processing device, comprising:

[0011] A first acquisition module is configured to acquire a firmware file to be verified; the firmware file includes firmware data and signature data; the signature data is obtained by signing the firmware data during the firmware file generation phase;

[0012] a parsing module, configured to parse the signature data and the firmware data from the firmware file if the current version information of the firmware file matches the target version information to be updated;

[0013] The verification module is used to perform security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data.

[0014] On the other hand, an embodiment of the present invention further discloses an electronic device, which includes a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by one or more processors to execute the aforementioned firmware processing method.

[0015] An embodiment of the present invention further discloses a readable storage medium. When instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the aforementioned firmware processing method.

[0016] The embodiments of the present invention include the following advantages:

[0017] An embodiment of the present invention provides a firmware processing method, which first compares the version information of the firmware file with the target version information to detect whether there is a rollback attack. When the version information of the firmware file matches the target version information, it is determined that there is no rollback attack, and the firmware file is further parsed to read the firmware data and signature data, and the firmware file is security-checked based on the check values corresponding to the signature data and the firmware data. The embodiment of the present invention can effectively prevent rollback attacks and detect the data integrity of the firmware file, making it easier to identify data tampering in the firmware file and improving the accuracy of firmware verification. In addition, the embodiment of the present invention does not require additional hardware resource support, nor does it require the configuration of a special trusted environment, which reduces the complexity and verification overhead of firmware verification and is conducive to improving the efficiency of firmware verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0019] Figure 1is a flowchart of steps of an embodiment of a firmware processing method of the present invention;

[0020] Figure 2 is a structural block diagram of an embodiment of a firmware processing device of the present invention;

[0021] Figure 3 This is a structural block diagram of an electronic device for firmware processing provided by an example of the present invention. DETAILED DESCRIPTION

[0022] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0023] Method Example

[0024] Reference Figure 1 , shows a flowchart of a firmware processing method embodiment of the present invention, the method may specifically include the following steps:

[0025] Step 101: Obtain a firmware file to be verified; the firmware file includes firmware data and signature data; the signature data is obtained by signing the firmware data during the firmware file generation phase;

[0026] Step 102: If the current version information of the firmware file matches the target version information to be updated, parse the signature data and the firmware data from the firmware file;

[0027] Step 103: Perform security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data.

[0028] The firmware processing method provided in an embodiment of the present invention can verify BIOS firmware. In this embodiment of the present invention, the firmware file to be verified is generated based on BIOS firmware data. For example, during the firmware generation phase, the firmware source code can be compiled and converted into binary code to generate firmware data. The firmware data is then digitally signed to obtain signature data. The firmware data and signature data are then combined to obtain the firmware file to be verified.

[0029] In one possible application scenario, an attacker may downgrade the current firmware to an older version of firmware, thereby exploiting the known vulnerabilities of the older version to tamper with the firmware data. In an embodiment of the present invention, the current version information of the firmware file can be compared with the target version information to be updated to determine whether a rollback attack exists. The target version information is generally the latest version information of the firmware, which can be determined based on the product information released by the firmware manufacturer. If the version information corresponding to the firmware file is inconsistent with the target version information, it can be determined that a rollback attack currently exists. In this case, there is no need to continue with the subsequent verification steps. It can be directly determined that the firmware file has failed the security verification and a corresponding alarm message can be generated.

[0030] The embodiment of the present invention compares the version information of the firmware file with the target version information during the firmware processing process, thereby quickly identifying whether there is a rollback attack caused by the firmware version, thereby effectively avoiding security issues caused by the rollback attack.

[0031] If the current version information of the firmware file matches the target version information, for example, the current version information of the firmware file is the same as the target version information, it can be determined that there is no rollback attack at present, and the subsequent verification steps are continued: the signature data and firmware data are parsed from the firmware file, and the firmware file is security verified based on the corresponding verification values of the signature data and firmware data.

[0032] Optionally, performing security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data, respectively, includes:

[0033] Step S11: performing an inference operation based on the signature data to generate a first check value corresponding to the signature data;

[0034] Step S12: performing integrity check on the firmware data to generate a second check value corresponding to the firmware data;

[0035] Step S13: Perform a security check on the firmware file according to the first check value and the second check value.

[0036] In an embodiment of the present invention, signature data and firmware data can be parsed from a firmware file, and then an inference operation is performed based on the signature data to generate a first check value, and an integrity check is performed on the firmware data to generate a second check value. Based on the first check value and the second check value, a security check is performed on the firmware file. Specifically, if the first check value is the same as the second check value, it can be considered that the firmware file has passed the security check. If the first check value is different from the second check value, it can be considered that the firmware file has failed the security check, and a corresponding alarm message can be further generated to prompt the user that the firmware file has been tampered with, and it is recommended to stop the subsequent firmware burning process.

[0037] It should be noted that the firmware data and signature data can be integrated according to preset rules to form a firmware file in a unified format. For example, the firmware data can be written into the firmware file according to a first offset value, and the signature data can be written into the firmware file according to a second offset value. The first offset value can be the offset value of the first byte in the firmware data relative to the start position of the firmware file; the second offset value can be the offset value of the first byte in the signature data relative to the start position of the firmware file. When parsing the firmware file, the firmware data can be read from the firmware file or the storage address of the firmware file based on the first offset value; and the signature data can be read from the firmware file or the storage address of the firmware file based on the second offset value. Alternatively, the signature data can be directly concatenated after the firmware data in a binary overlay manner, and a flag bit can be set in the firmware file to indicate the size and starting position of the firmware data. When parsing the firmware file, the starting position of the firmware data can be determined based on the information in the flag bit, and the firmware data can be read from the starting position. The starting position of the signature data can be determined based on the starting position and size of the firmware data, and the signature data can be read.

[0038] As an example, assume the firmware file is structured as follows:

[0039] 0x0000 ~ 0x00FF: File header

[0040] 0x0100 ~ 0x10FF: Firmware data

[0041] 0x1100 ~ 0x11FF: Signature data

[0042] The file header can contain a version number, checksum, and other information, which is unrelated to the offset value. The firmware data is 4096 bytes long, so the first offset value is 0x100. Since the signature data is 256 bytes long, the second offset value is 0x1100.

[0043] When parsing the firmware file using the offset value, 4096 bytes of data can be read starting from the position corresponding to the first offset value, and the data read is the firmware data. Similarly, 256 bytes of data can be read starting from the position corresponding to the second offset value, and the data read is the signature data.

[0044] Alternatively, the size and starting position of the firmware data can be indicated in the firmware file through a flag bit. The structure of the firmware file can be as follows:

[0045] 0x0000 ~ 0x000F: Flag bits

[0046] 0x0010 ~ 0x00FF: Reserved fields (such as checksum, version number)

[0047] 0x0100 ~ 0x10FF: Firmware data (0x1000 bytes, dynamically determined by the flag bit)

[0048] 0x1100 ~ 0x11FF: Signature data (immediately following the firmware data, starting offset = firmware start + firmware size = 0x100 + 0x1000 = 0x1100)

[0049] The flag bit size is 16 bytes, and the format of the flag bit can be "[4-byte firmware start offset][4-byte firmware size][4-byte signature start offset][4-byte reserved]". The first offset value corresponding to the firmware data is determined by bytes 0 to 3 of the flag bit, and the data size of the firmware data is determined by bytes 4 to 7 of the flag bit. In the above example, the first offset value of the firmware data is 0x100, the size of the firmware data is 0x1000, and the second offset value corresponding to the signature data is 0x1100.

[0050] When parsing a firmware file, the file can be opened in binary mode. Starting at the starting address 0x0000 of the flag bit, the flag bit is read and verified for legitimacy according to the established flag bit format. For example, the first offset value of the firmware data cannot be less than the flag bit length. If the first offset value of the firmware data is less than the flag bit length, the flag bit is determined to be invalid. Conversely, if the first offset value of the firmware data is greater than or equal to the flag bit length, the flag bit is determined to be valid. For example, the first 16 bytes (flag bits) of the firmware file are read and parsed field by field to obtain the first offset value (firmware_offset) of the firmware data, the firmware size (firmware_size), and the second offset (signature_offset) of the signature data. The verification checks whether firmware_offset is greater than or equal to 0x0100 (to avoid overlap with flag bits or reserved fields), whether firmware_size is greater than 0, and whether signature_offset is equal to firmware_offset + firmware_size (to ensure that the signature closely follows the firmware data). If not, an alarm is generated, such as "Invalid flag bit."

[0051] Read the reserved fields from 0x0010 to 0x00FF to extract the version number, checksum, etc. For example, the 4-byte version number is 0x0010 to 0x0013. Starting at the first offset value, position 0x0100, read 0x1000 bytes of data to obtain the firmware data. Starting at the second offset value, position 0x1100, read the remaining data in the firmware file to obtain the signature data.

[0052] It is understood that the signature data can be obtained by signing the firmware data. For example, the firmware data can be hashed using a hash algorithm, such as Message Digest Algorithm 5 (MD5), Secure Hash Algorithm 256 (SHA256), or another hash algorithm, to compress the firmware data into a fixed-length digest, or hash value. The hash value is then encrypted using a private key to obtain the signature data. When verifying the firmware file, the corresponding public key can be used to perform an inference operation on the signature data to determine a first checksum corresponding to the signature data.

[0053] In an embodiment of the present invention, the integrity of the firmware data can be checked. For example, a hash algorithm such as MD5 or SH256 can be used to perform a hash operation on the firmware data to generate a second check value corresponding to the firmware data. By comparing the first check value with the second check value, it is determined whether the firmware file has been tampered with. If the first check value is different from the second check value, it can be determined that the firmware file has not passed the security check, and a corresponding alarm message needs to be generated to prompt the user that the firmware file has been tampered with. On the contrary, if the first check value is the same as the second check value, it can be determined that the firmware file has passed the security check, and the firmware data in the firmware file can be burned into the chip to provide startup boot services for the hardware components on the mainboard.

[0054] As an example, Python's cryptography library is used to demonstrate key steps, including hash calculation, signature generation, signature verification, and tamper detection.

[0055] 1. Generate an RSA key pair.

[0056] Python

[0057] from cryptography.hazmat.primitives.asymmetric import rsa

[0058] from cryptography.hazmat.primitives import serialization

[0059] # Generate a 2048-bit RSA private key

[0060] private_key = rsa.generate_private_key(

[0061] public_exponent=65537,# Fixed value, commonly used 65537

[0062] key_size=2048 )

[0064] # Extract the public key

[0065] public_key = private_key.public_key()

[0066] # Save the private key (PEM format, actual scenario requires secure storage)

[0067] private_pem = private_key.private_bytes(

[0068] encoding=serialization.Encoding.PEM,

[0069] format=serialization.PrivateFormat.PKCS8,

[0070] encryption_algorithm=serialization.NoEncryption() )

[0072] with open("private_key.pem", "wb") as f:

[0073] f.write(private_pem)

[0074] # Save the public key (PEM format, can be publicly distributed)

[0075] public_pem = public_key.public_bytes(

[0076] encoding=serialization.Encoding.PEM,

[0077] format=serialization.PublicFormat.SubjectPublicKeyInfo )

[0079] with open("public_key.pem", "wb") as f:

[0080] f.write(public_pem)

[0081] 2. Generate signature data.

[0082] Python

[0083] from cryptography.hazmat.primitives import hashes

[0084] from cryptography.hazmat.primitives.asymmetric import padding

[0085] # Firmware data (example)

[0086] firmware_data = b"FirmwareUpdate_v1.0_20250430"

[0087] # Step 1: Calculate the SHA256 hash value (digest)

[0088] digest = hashes.Hash(hashes.SHA256())

[0089] digest.update(firmware_data)

[0090] hash_value = digest.finalize() # 32-byte SHA256 digest

[0091] # Step 2: Encrypt the hash value with the private key to generate a signature

[0092] signature = private_key.sign(

[0093] hash_value,

[0094] padding.PKCS1v15(), #Padding method (same as when verifying the signature)

[0095] hashes.SHA256()# Need to match the hash algorithm (the hash has been calculated in advance and will be verified internally by the library) )

[0097] # The signature data is "signature" (256 bytes, 2048-bit RSA), which needs to be stored / transmitted together with the firmware data

[0098] 3. Verify firmware integrity.

[0099] Python

[0100] def verify_firmware(firmware_data, signature, public_key):

[0101] try:

[0102] # Step 3: Decrypt the signature with the public key to obtain the first checksum

[0103] public_key.verify(

[0104] signature,

[0105] firmware_data,# Directly pass in the original data, the library will automatically calculate the hash and compare it with the signature

[0106] padding.PKCS1v15(),

[0107] hashes.SHA256() )

[0109] return True# Verification successful, no tampering

[0110] except Exception as e:

[0111] print(f"Verification failed, reason: {str(e)}")

[0112] return False

[0113] Tamper Detection# Loading the public key (actual scenario reads from the file)

[0114] with open("public_key.pem", "rb") as f:

[0115] public_key = serialization.load_pem_public_key(f.read())

[0116] # Simulate received firmware data and signature (untampered scenario)

[0117] is_valid = verify_firmware(firmware_data, signature, public_key)

[0118] print(f"Firmware has not been tampered with: {is_valid}")# Output: True (verification successful)

[0119] #Simulate firmware tampering (modify one byte)

[0120] tampered_data = firmware_data + b"X" # add a byte

[0121] is_valid_tampered = verify_firmware(tampered_data, signature, public_key)

[0122] print(f"Verification result after firmware tampering: {is_valid_tampered}")

[0123] # Output: False (verification failed)

[0124] In this embodiment, during the firmware file verification process, the signature data is subjected to "inference operation", i.e., the public key signature verification process. The specific steps are as follows:

[0125] 1. Use the public key to decrypt the signed data (based on the mathematical principle of RSA, the content encrypted by the private key can only be decrypted by the public key).

[0126] 2. After decryption, the original hash value (first check value) is obtained.

[0127] 3. Recalculate the hash value (second check value) of the current firmware data.

[0128] 4. Compare the two to see if they are consistent (this is done automatically within the library, no manual operation is required).

[0129] In the above processing, the external interface calls involved are mainly:

[0130] Hash calculation: Call the cryptography.hazmat.primitives.hashes.Hash interface, supporting algorithms such as SHA256 and MD5.

[0131] Signature generation: Call the sign method of the private key and specify the padding method (such as PKCS1v15) and hash algorithm.

[0132] Signature verification: Call the verify method of the public key, passing in the firmware data, signature, padding method, and hash algorithm. If verification fails, an exception such as InvalidSignature will be thrown.

[0133] If the first checksum and the second checksum are consistent, it indicates that the firmware file has not been tampered with. In other words, the recalculated hash value (second checksum) = the hash value after signature decryption (first checksum). The verify method returns True without any exception.

[0134] If the first checksum and the second checksum are inconsistent, it indicates that the firmware file has been tampered with. After the firmware data is modified, the recalculated hash value is different from the first checksum. The verify method throws an InvalidSignature exception and returns False.

[0135] The firmware processing method provided by the embodiment of the present invention can first compare the version information of the firmware file with the target version information to detect whether there is a rollback attack. When the current version information of the firmware file is consistent with the target version information, it is determined that there is no rollback attack, and the firmware file is further parsed to read the firmware data and signature data. According to the verification values corresponding to the signature data and the firmware data, the firmware file is security verified. The embodiment of the present invention can effectively prevent rollback attacks and detect the data integrity of the firmware file, making it easier to identify data tampering in the firmware file and improving the accuracy of firmware verification. In addition, the embodiment of the present invention does not require additional hardware resource support, nor does it require the configuration of a special trusted environment, which reduces the complexity and verification overhead of firmware verification and is conducive to improving the efficiency of firmware verification.

[0136] Optionally, the method further includes:

[0137] Step S21: Obtain firmware source code, and add current version information to the firmware source code to generate first firmware data;

[0138] Step S22: performing binary compilation on the first firmware data to generate second firmware data, performing integrity verification on the second firmware data, and generating the signature data according to the verification result;

[0139] Step S23: Add the signature data to the second firmware data to generate the firmware file.

[0140] In an embodiment of the present invention, during the firmware file generation phase, current version information can be added to the firmware source code to generate first firmware data. For example, version number information, such as "Machine_FirmwareVersion: Loongson_v1.0," can be added to the valid firmware source code SourceCode. Exemplarily, macros related to version information can be defined in a header file (.h) of the firmware source code, such as version.h. Alternatively, global variables can be used in a source file of the firmware source code, such as version.c, to define the current version information of the firmware data. Alternatively, the version information can be stored in a specific memory area of the firmware, such as at the end of a data segment, so that the version information can be read during subsequent processing.

[0141] It is understood that firmware source code is typically the underlying software code running in an embedded device, used to control basic hardware device functions such as startup, peripheral driver development, and system initialization. For example, the firmware source code may be written in C, C++, assembly language, or similar. During firmware processing, the firmware source code needs to be compiled into a binary machine language format that is more easily processed by computers. Specifically, a compiler or compilation tool can be used to perform binary compilation (or binary translation) on the first firmware data with added version information to generate second firmware data in binary code format.

[0142] Taking the binary compilation of the first firmware data using the GCC tool chain as an example, assuming the target chip is STM32F103C8T6 (Cortex-M3 core) and the compilation tool chain is arm-none-eabi-gcc, the compilation steps are as follows:

[0143] 1. Preprocessing: Expand the header file and macro definition of the firmware source code in the first firmware data, delete the comments, and generate pure C code.

[0144] 2. Compilation: Convert the preprocessed C code into assembly language. The converted assembly language is related to the CPU architecture. In other words, convert the C code into the assembly language of the instruction set corresponding to the CPU architecture.

[0145] 3. Assembly: Convert assembly language into binary target files, such as ".o" files. The binary target files contain machine code but do not link library functions.

[0146] 4. Linking: Merge binary target files and library files (such as standard libraries and startup codes) into executable binary files and resolve symbolic addresses (such as function calls and global variables).

[0147] Among them, the startup code (startup_stm32f10x_md.s) is provided by the manufacturer and is responsible for initializing the CPU registers, heap / stack, calling the main function, etc.

[0148] In an embodiment of the present invention, a link script can be used to link binary target files. The link script (such as linker.ld) is used to specify the addresses of code (.text), data (.data), and constants (.rodata) in memory, such as the Flash starting address 0x08000000.

[0149] 5. Generate the second firmware data (binary file). The final generated second firmware data is a continuous binary code that can be directly burned into the chip's Flash.

[0150] In an embodiment of the present invention, to ensure data security, after the second firmware data is generated, an integrity check can be performed on the second firmware data to generate a check result. For example, a hash algorithm such as MD5 or SH256 can be used to perform a hash operation on the second firmware data to generate a check result.

[0151] Taking the SH256 algorithm as an example, assuming the firmware data path is "firmware.signed", the starting offset of the second firmware data is 0x100, the data length is 0x100000 (1MB), and the verification result format is a 64-byte hexadecimal string. The verification code example is as follows:

[0152] import hashlib

[0153] def calculate_sha256(firmware_path, start_offset, data_size):

[0154] sha256 = hashlib.sha256()

[0155] with open(firmware_path, 'rb') as f:

[0156] f.seek(start_offset)# Locate the starting position of the firmware data

[0157] firmware_data = f.read(data_size)# Read firmware data of specified length

[0158] sha256.update(firmware_data)# Calculate the hash value

[0159] return sha256.hexdigest()# Returns a 64-byte hexadecimal string

[0160] # Calling example (assuming starting from offset 0x100 and reading 0x100000 bytes)

[0161] sha256_result = calculate_sha256("firmware.signed", 0x100, 0x100000)

[0162] print(f"SHA-256 verification result: {sha256_result}")

[0163] In the above example, the second firmware data to be verified is accurately read by reading metadata from the firmware header (such as the starting offset and data length), avoiding the inclusion of signatures or other irrelevant data. If the firmware data length is not fixed, the header must be parsed to obtain the actual length. For example, in the example, data_size is obtained from the header.

[0164] The SHA256 algorithm is used to perform integrity check on the second firmware data. The generated check result is the hash value obtained by performing a SHA-256 hash operation on the second firmware data, specifically a 64-byte hexadecimal string.

[0165] In an embodiment of the present invention, the generated verification result can be compared with a pre-stored correct hash value. The correct hash value refers to the SHA-256 value of the untampered second firmware data, pre-calculated and stored by the manufacturer or developer when the firmware is released. This value may be stored, for example, in the firmware header, signature data, or provided to the verifier via a secure channel. The result sha256_result returned by the calculate_sha256 function in the above code is compared character by character with the pre-stored value. If they are identical, the verification is considered passed, indicating that the second firmware data has not been tampered with.

[0166] In an embodiment of the present invention, the verification result can be further digitally signed to generate signature data, and the signature data can be added to the second firmware data to generate a firmware file, so that the firmware file can be security verified according to the signature data in the firmware file during the subsequent burning stage.

[0167] For example, the first firmware data can be compiled using the GCC / Clang compiler to generate the second firmware data, Firmware. The second firmware data, Firmware, is then stored in a designated area in the flash memory, named Data A. A hash algorithm is then applied to perform an integrity check on the second firmware data, generating a verification result, recorded as y1. Next, OpenSSL or an encryption tool can be used to generate a public key m and a private key n, where m = p(n). The data hash value y1 is then signed using the private key n to generate signature data SIG = q(n, y1). A Shell / Python script is used to append the signature data to the binary file of the second firmware data to obtain a firmware file, for example, a ".ENC" file.

[0168] If the result sha256_result returned by the calculate_sha256 function in the code differs from the stored value by at least one character, the verification is considered to have failed. In this case, the specific cause needs to be analyzed and addressed accordingly.

[0169] Generally speaking, the main reasons for verification failure are:

[0170] 1. The firmware data has been tampered with, such as malicious modification, virus injection, etc. In this case, it is necessary to analyze from a secure source and re-obtain the firmware data from a legitimate supplier or manufacturer.

[0171] 2. The firmware data is damaged during storage or transmission, such as disk errors, network transmission errors, etc. In this case, you can try to recover the data.

[0172] 3. The starting offset or data length obtained when parsing the firmware header is incorrect, resulting in reading the wrong byte range, such as including signature data or other irrelevant data. In this case, you can debug the code, re-read the firmware data and verify it.

[0173] Optionally, generating the signature data according to the verification result includes:

[0174] Step S31: Generate a key pair using a predetermined encryption algorithm; the key pair includes a public key and a private key;

[0175] Step S32: Encrypt the verification result based on the private key to generate signature data.

[0176] In this embodiment of the present invention, a key pair can be generated based on an encryption algorithm. The private key in the key pair can be used to encrypt the firmware file generation node and the verification result y1 of the second firmware data to generate signature data. For example, OpenSSL or an encryption tool can generate a public key m and a private key n, where m = p(n). The private key n is then used to sign the data hash value y1, generating signature data SIG = q(n, y1).

[0177] Optionally, performing an inference operation based on the signature data to generate a first check value corresponding to the signature data includes:

[0178] The signature data is decrypted based on the public key to generate the first verification value.

[0179] During the firmware verification phase, the signature data can be decrypted using the public key to generate a first verification value. For example, the first verification value y1_ can be derived by inversely deriving the inverse function y = q^-1(SIG, m).

[0180] As an example, assuming that the second firmware data content is: b"SecondFirmware_v2.0_20250430", using the SHA-256 hash algorithm and asymmetric encryption, the specific processing steps are as follows:

[0181] 1. Generate an RSA key pair. Execute the following OpenSSL command in the terminal to generate the private key and public key:

[0182] bash

[0183] # Generate a 2048-bit RSA private key (n)

[0184] openssl genrsa -out private_key.pem 2048

[0185] # Extract the public key from the private key (m)

[0186] openssl rsa -in private_key.pem -pubout -out public_key.pem

[0187] An example of the generated private key n (private_key.pem) (truncated):

[0188] pem

[0189] -----BEGIN RSA PRIVATE KEY-----

[0190] MIIEowIBAAKCAQEAxyz... (2048-bit random number)...

[0191] -----END RSA PRIVATE KEY-----

[0192] Example of the generated public key m (public_key.pem) (truncated):

[0193] pem

[0194] -----BEGIN PUBLIC KEY-----

[0195] MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxyz... (the public key that matches the private key)...

[0196] -----END PUBLIC KEY-----

[0197] 2. Calculate the hash value y1 of the second firmware data (Python code):

[0198] Python

[0199] import hashlib

[0200] # Second firmware data (sample content)

[0201] second_firmware_data = b"SecondFirmware_v2.0_20250430"

[0202] # Calculate the SHA-256 hash value y1 (32 bytes)

[0203] sha256 = hashlib.sha256()

[0204] sha256.update(second_firmware_data)

[0205] y1 = sha256.digest() # Original hash value (byte string)

[0206] y1_hex = sha256.hexdigest() # Hexadecimal string (64 bytes)

[0207] print(f"SHA-256 hash value y1 (hexadecimal) of the second firmware data: {y1_hex}")

[0208] # Example output (actual values may vary depending on data):

[0209] SHA-256 hash value y1 of the second firmware data (hexadecimal): a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f01234.

[0210] 3. Sign y1 with the private key n to generate the signature data SIG (Python code).

[0211] Use the cryptography library to implement RSA signature:

[0212] Python

[0213] from cryptography.hazmat.primitives.asymmetric import rsa, padding

[0214] from cryptography.hazmat.primitives import hashes

[0215] from cryptography.hazmat.primitives.serialization import load_pem_private_key

[0216] # Step 1: Load private key n (read from file)

[0217] with open("private_key.pem", "rb") as f:

[0218] private_key = load_pem_private_key(f.read(), password=None)

[0219] # Step 2: Sign y1 with private key n (PKCS#1 v1.5 padding)

[0220] signature = private_key.sign(

[0221] y1,# Original hash value (32 bytes)

[0222] padding.PKCS1v15(), #Padding method (same as when verifying the signature)

[0223] hashes.SHA256()# Need to match the hash algorithm (checked during verification) )

[0225] # Signature data SIG (256 bytes, 2048-bit RSA)

[0226] print(f"Signature data SIG (hexadecimal): {signature.hex()}")

[0227] # Output example (randomly generated 256-byte signature):

[0228] Signature data SIG (hexadecimal): 5f4dcc3b900187118d589229bb769371936f60546a0d2a5f4dcc3b900187118d589229bb769371936f60546a0d2a... (512 characters in total).

[0229] 4. Use the public key m to verify the signature and generate the first check value y1. The Python code is as follows:

[0230] Python

[0231] from cryptography.hazmat.primitives.serialization import load_pem_public_key

[0232] from cryptography.exceptions import InvalidSignature

[0233] # Step 1: Load the public key m (read from file)

[0234] with open("public_key.pem", "rb") as f:

[0235] public_key = load_pem_public_key(f.read())

[0236] # Step 2: Use public key m to verify the signature and generate y1_

[0237] try:

[0238] # Verification process: decrypt the signature with the public key, get y1_, and compare it with the original y1

[0239] public_key.verify(

[0240] signature,#Signature data SIG

[0241] y1,# Original hash value y1 (for comparison)

[0242] padding.PKCS1v15(),

[0243] hashes.SHA256() )

[0245] print("Signature verification successful, y1_ == y1, the second firmware data has not been tampered with!")

[0246] except InvalidSignature:

[0247] print("Signature verification failed, y1_!= y1, the second firmware data has been tampered with or the signature is invalid!")

[0248] If the second firmware data has not been tampered with (verification passed), the input and output are as follows:

[0249] enter:

[0250] Second firmware data: b"SecondFirmware_v2.0_20250430" (unmodified).

[0251] Signature data SIG: generated by the private key n and its hash value y1.

[0252] Verification result: y1_ obtained after decrypting the signature with public key m is exactly the same as the original y1, and there is no exception in the verify method.

[0253] Output: Signature verification successful, y1_ == y1, the second firmware data has not been tampered with!

[0254] If the second firmware data is tampered with (verification fails), the input and output are as follows:

[0255] enter:

[0256] Second firmware data: b"SecondFirmware_v2.0_20250430_TAMPERED" (modified data).

[0257] Signature data SIG: Still the signature of the original unmodified data.

[0258] Verification result: The hash value y1_new of the modified data is different from the original y1, and the y1_ (original y1) obtained by public key decryption signature is inconsistent with y1_new. The verify method throws an InvalidSignature exception.

[0259] Output: Signature verification failed, y1_ != y1, the second firmware data has been tampered with or the signature is invalid!

[0260] It should be noted that in embodiments of the present invention, if a hash algorithm is used to perform a hash operation on the second firmware data during the firmware file generation phase, the same hash algorithm must be used to perform an integrity check on the firmware data in the firmware file during the firmware verification phase to ensure the accuracy of the verification results. For example, if the SH256 algorithm is used to perform a hash operation on the second firmware data during the firmware file generation phase, then the SH256 algorithm must also be used to perform an integrity check on the firmware data in the firmware file during the firmware verification phase.

[0261] Optionally, performing security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data, respectively, includes:

[0262] Step S41: Compare a first check value corresponding to the signature data with a second check value corresponding to the firmware data;

[0263] Step S42: If the first check value is the same as the second check value, it is determined that the firmware file passes the security check, and the firmware data is burned into a predetermined chip.

[0264] The first check value and the second check value are checked for consistency by comparing them character by character. If at least one character in the first check value and the second check value is different, it indicates that the first check value and the second check value are different, and it can be determined that the firmware file has failed the security check, and a corresponding warning message needs to be generated to prompt the user that the firmware file has been tampered with. Conversely, if the first check value and the second check value are the same, it can be determined that the firmware file has passed the security check, and the firmware data in the firmware file can be burned into the chip to provide boot services for the hardware components on the motherboard.

[0265] For example, before firmware is burned, the current version information of the firmware file is read by loading a header file or global variable. The latest target version information is determined based on the product information released by the supplier or manufacturer. The firmware file's corresponding version information is checked to see if it is consistent with the target version information. If not, the firmware update is blocked. If they are consistent, the firmware data is located in Flash memory using the first offset value Offset1 corresponding to the firmware data, and the signature data SIG is located in Flash memory using the second offset value Offset2 corresponding to the signature data.

[0266] Load the SIG data from the Flash into the memory or processor cache area, and use the inverse function y = q^-1(SIG, m) to infer the first data integrity check value y1_.

[0267] The firmware data A is loaded from the Flash into the memory or the cache area of the processor, and a second check value y2_ is generated using the function y2=f(x) (where x is the firmware data loaded into the memory or the cache area).

[0268] Compare y1_ and y2_. If they are equal, the data integrity verification has passed. Next, use the SPI protocol to burn the verified firmware data x = Firmware into the Flash chip to implement the firmware update, ensuring that the CPU can load and execute instructions from the updated firmware.

[0269] The firmware processing method provided by the embodiment of the present invention is explained below with reference to a specific example.

[0270] In this embodiment of the present invention, the current version information, for example, "Machine_FirmwareVersion: Loongson_v1.0," is first added to the firmware source code SourceCode to generate the first firmware data. Then, the first firmware data with the added version information is binary compiled to generate the second firmware data.

[0271] The binary second firmware data is recorded as FirmwareData. Assume that the firmware data has a length of 0x1000 bytes, or 4KB. For example, the SHA256 algorithm is used as the hash algorithm. Assume that asymmetric encryption is used to generate a key pair, where the private key is RSA-2048, recorded as PrivateKey, and the public key is recorded as PublicKey.

[0272] Use the SHA256 algorithm to calculate the hash digest of the second firmware data, thereby performing an integrity check on the second firmware data. Specifically, perform a SHA-256 hash operation on FirmwareData to obtain the digest, HashDigest = SHA256(FirmwareData), which is 32 bytes long (0x20). Assume that the checksum value is 0xA1B2C3D4... (32-byte hexadecimal).

[0273] Next, the verification result is signed with the private key to generate signature data. For example, using the RSA algorithm, the HashDigest is encrypted with the PrivateKey to generate signature data (SignatureData). The length is 256 bytes (the fixed length for RSA-2048 signatures). Assume that the signature data value is 0x0102...FEFF (256 bytes). The second firmware data is concatenated with the signature data to generate the firmware file.

[0274] For example, the second firmware data and signature data can be concatenated according to the preset first and second offset values. The total length of the firmware file is: FirmwareData length (0x1000) + SignatureData length (0x100), which should actually be: 0x1000 + 0x100 = 0x1100 bytes. It should be noted that the RSA-2048 signature is actually 256 bytes, but for simplicity, it is set to 0x100 bytes here, i.e., 256 bytes.

[0275] The starting offset of the firmware data, i.e. the first offset value, is 0x0000 (from the beginning of the file). The starting offset of the signature data, i.e. the second offset value, is 0x1000 (immediately after the end of the firmware data).

[0276] During the splicing process, the firmware file Firmware.bin is first created with a size of 0x1100 bytes. Then, FirmwareData is written to the file at offset 0x0000 (covering 0x0000 to 0x0FFF, a total of 0x1000 bytes). SignatureData is written to the file at offset 0x1000 (covering 0x1000 to 0x10FF, a total of 0x100 bytes).

[0277] Alternatively, dynamic concatenation can be used, using a flag to indicate the firmware data size and signature data offset. Assume the flag is 8 bytes long, containing the firmware data size and signature data offset, and is located at the beginning of the firmware file. Firmware data size (4 bytes): 0x00001000 (0x1000 bytes). Signature data offset (4 bytes): 0x00001000 (immediately after the firmware data). The total length of the firmware file is: flag length (0x0008) + firmware data length (0x1000) + signature data length (0x100) = 0x1108 bytes.

[0278] During the splicing process, first create an empty firmware file, Firmware.bin, and write the flags. Specifically, offsets 0x0000 to 0x0003 contain the firmware data size (0x00001000, 4 bytes, consistent with little-endian or big-endian format; big-endian is assumed). Offsets 0x0004 to 0x0007 contain the signature data (0x00001000, 4 bytes).

[0279] Then, FirmwareData is written to offset 0x0008 (after the flag bit, 0x0008 to 0x1007, a total of 0x1000 bytes). SignatureData is written to offset 0x1000 (according to the signature offset 0x1000 in the flag bit).

[0280] It should be noted that the offset in the flag bit is relative to the starting position of the firmware data, that is, 0x1000 corresponds to the firmware data. Assuming that the flag bit occupies 0x0008 bytes, the firmware data starts at 0x0008 and has a length of 0x1000, the firmware data ends at 0x1007 and the signature data starts at 0x1008.

[0281] As an example, the process of combining signature data and firmware data may specifically include the following steps:

[0282] 1. Create an empty file and write the flag.

[0283] Write an 8-byte flag at the beginning of the file, including the firmware data size (4 bytes, big endian) and signature offset (4 bytes, big endian).

[0284] Specifically, you can use file operation functions such as open() (Python) or fopen() (C) to create a file in binary write mode (wb). Use struct.pack() (Python) or htonl() (C) to convert integers to big-endian byte order.

[0285] 2. Write firmware data.

[0286] Write the firmware data to the position after the flag bit (offset 0x0008), with a length of 0x1000 bytes.

[0287] Specifically, you can use file positioning functions such as seek() (Python) or fseek() (C) to move the file pointer to 0x0008. Use data writing functions such as write() (Python) or fwrite() (C) to write the firmware data bytes.

[0288] 3. Write signature data.

[0289] Write the signature data to the offset specified by the flag bit (0x1000), with a length of 0x100 bytes.

[0290] Specifically, a file positioning function, such as seek() / fseek(), can be used to move the file pointer to 0x1000, and a data writing function, such as write() / fwrite(), can be used to write the signature data bytes.

[0291] 4. Verify the total length of the file.

[0292] The total file length must be: flag bit length + firmware data length + signature data length (0x1108 bytes).

[0293] Specifically, you can use functions such as os.path.getsize() (Python) or ftell() (C) to obtain the file length and verify whether the final file size meets the expected value. The following is the complete code for dynamic splicing using Python, including the flag bit, firmware data, signature data writing, and length verification:

[0294] Python

[0295] import struct

[0296] import os

[0297] def build_firmware(firmware_data_path, signature_data_path, output_path):

[0298] # 1. Define parameters (example values)

[0299] firmware_size = 0x1000 # Firmware data length (4 bytes, big endian)

[0300] signature_offset = 0x1000 # Signature data offset (4 bytes, big endian)

[0301] signature_size = 0x100# Signature data length (example)

[0302] # 2. Read firmware data and signature data

[0303] with open(firmware_data_path, 'rb') as f:

[0304] firmware_data = f.read()

[0305] if len(firmware_data) != firmware_size:

[0306] raise ValueError(f"Firmware data length error (expected {firmware_size} bytes, actual {len(firmware_data)} bytes)")

[0307] with open(signature_data_path, 'rb') as f:

[0308] signature_data = f.read()

[0309] if len(signature_data) != signature_size:

[0310] raise ValueError(f"Signature data length error (expected {signature_size} bytes, actual {len(signature_data)} bytes)")

[0311] # 3. Create and write firmware files

[0312] with open(output_path, 'wb') as f:

[0313] # Write flag (8 bytes: 4 bytes firmware size + 4 bytes signature offset, big endian)

[0314] flag_bytes = struct.pack('>II', firmware_size, signature_offset)# '>' indicates big endian byte order

[0315] f.write(flag_bytes)

[0316] # Write firmware data (offset 0x0008)

[0317] f.seek(0x0008)# Move to the end of the flag

[0318] f.write(firmware_data)

[0319] # Write signature data (offset 0x1000)

[0320] f.seek(signature_offset)# Move to the signature offset specified by the flag

[0321] f.write(signature_data)

[0322] # 4. Verify the total length of the file

[0323] total_size = os.path.getsize(output_path)

[0324] expected_size = 0x08 + firmware_size + signature_size # 0x1108 bytes

[0325] if total_size != expected_size:

[0326] raise ValueError(f"The total length of the file is wrong (expected {expected_size} bytes, actual {total_size} bytes)")

[0327] print(f"Firmware file construction completed: {output_path}")

[0328] # Call example

[0329] build_firmware(

[0330] firmware_data_path="firmware_data.bin",# Actual firmware data file (0x1000 bytes)

[0331] signature_data_path="signature.bin",# Signature data file (0x100 bytes)

[0332] output_path="Firmware.bin" )

[0334] Through the above process, the process of dynamically splicing firmware files can be clearly realized. The core relies on file operation functions, byte order conversion and length verification to ensure that each part of the data is accurately spliced according to the flag definition.

[0335] During the firmware burning phase, the firmware file to be burned is verified. Specifically, the version information corresponding to the firmware file is compared with the target version information to determine whether a rollback attack exists. If the firmware file's version information matches the target version information, the firmware data and signature data are read from the firmware file for security verification. Specifically, 0x1000 bytes are read from offset 0x0000 to obtain the firmware data FirmwareData. 0x100 bytes are read from offset 0x1000 to obtain the signature data SignatureData.

[0336] The signature data SignatureData is decrypted using the public key PublicKey corresponding to the private key to generate a first check value DecryptedHash. The firmware data FirmwareData is re-integrity checked using a hash algorithm, for example, by calculating a SHA-256 hash to obtain a second check value NewHashDigest.

[0337] Compare the second verification value NewHashDigest with the first verification value DecryptedHash. If they are consistent, the signature is valid, indicating that the firmware file has not been tampered with and comes from a legitimate publisher. In other words, the firmware file has passed the security verification and the firmware data in the firmware file can be burned into the chip to provide startup boot services for the hardware components on the motherboard. If they are inconsistent, it means that the firmware data has been tampered with and needs to be re-obtained from the supplier or manufacturer and verified.

[0338] In summary, an embodiment of the present invention provides a firmware processing method, which first compares the version information of the firmware file with the target version information to detect whether there is a rollback attack. When the version information of the firmware file is consistent with the target version information, it is determined that there is no rollback attack, and the firmware file is further parsed to read the firmware data and signature data, and the firmware file is security verified based on the verification values corresponding to the signature data and the firmware data. The embodiment of the present invention can effectively prevent rollback attacks and detect the data integrity of the firmware file, making it easier to identify data tampering in the firmware file, thereby improving the accuracy of firmware verification. In addition, the embodiment of the present invention does not require additional hardware resource support, nor does it require the configuration of a special trusted environment, which reduces the complexity and verification overhead of firmware verification, and is conducive to improving the efficiency of firmware verification.

[0339] Device embodiment

[0340] Reference Figure 2 , shows a structural block diagram of an embodiment of a firmware processing device of the present invention, the device may specifically include:

[0341] The first acquisition module 201 is used to acquire a firmware file to be verified; the firmware file includes firmware data and signature data; the signature data is obtained after the firmware data is signed during the firmware file generation phase;

[0342] A parsing module 202, configured to parse the signature data and the firmware data from the firmware file if the current version information of the firmware file matches the target version information to be updated;

[0343] The verification module 203 is configured to perform a security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data.

[0344] Optionally, the device further comprises:

[0345] a second acquisition module, configured to acquire a firmware source code, and add current version information to the firmware source code to generate first firmware data;

[0346] a data processing module, configured to perform binary compilation on the first firmware data to generate second firmware data, and generate the signature data according to the integrity check result after performing integrity check on the second firmware data;

[0347] A splicing module is used to add the signature data to the second firmware data to generate the firmware file.

[0348] Optionally, the data processing module includes:

[0349] A key generation unit, configured to generate a key pair using a predetermined encryption algorithm; the key pair includes a public key and a private key;

[0350] An encryption unit is used to encrypt the verification result based on the private key to generate the signature data.

[0351] Optionally, the verification module includes:

[0352] a first processing submodule, configured to perform an inference operation based on the signature data to generate a first check value corresponding to the signature data;

[0353] a second processing submodule, configured to perform integrity check on the firmware data and generate a second check value corresponding to the firmware data;

[0354] A check submodule is configured to perform a security check on the firmware file according to the first check value and the second check value.

[0355] Optionally, the first processing submodule includes:

[0356] A decryption unit is used to decrypt the signature data based on the public key to generate the first check value.

[0357] Optionally, the verification module includes:

[0358] a comparing unit, configured to compare a first check value corresponding to the signature data with a second check value corresponding to the firmware data;

[0359] The burning unit is configured to determine that the firmware file passes the security check if the first check value is the same as the second check value, and burn the firmware data into a predetermined chip.

[0360] In summary, an embodiment of the present invention provides a firmware processing device, which first compares the version information of the firmware file with the target version information to detect whether there is a rollback attack. When the version information of the firmware file is consistent with the target version information, it is determined that there is no rollback attack, and the firmware file is further parsed, the firmware data and signature data are read, and the firmware file is security verified according to the verification values corresponding to the signature data and the firmware data. The embodiment of the present invention can effectively prevent rollback attacks and detect the data integrity of the firmware file, making it easier to identify data tampering in the firmware file, thereby improving the accuracy of firmware verification. In addition, the embodiment of the present invention does not require additional hardware resource support, nor does it require the configuration of a special trusted environment, which reduces the complexity and verification overhead of firmware verification, and is conducive to improving the efficiency of firmware verification.

[0361] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0362] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0363] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0364] Figure 3 FIG1 is a block diagram of an electronic device 600 for firmware processing according to an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0365] Reference Figure 3 , the electronic device 600 may include one or more of the following components: a processing component 602 , a memory 604 , a power component 606 , a multimedia component 608 , an audio component 610 , an input / output (I / O) interface 612 , a sensor component 614 , and a communication component 616 .

[0366] The processing component 602 generally controls the overall operation of the electronic device 600, such as operations associated with display, phone calls, data communications, camera operation, and recording operations. The processing component 602 may include one or more processors 620 to execute instructions to perform all or part of the steps of the above-described method. In addition, the processing component 602 may include one or more modules to facilitate interaction between the processing component 602 and other components. For example, the processing component 602 may include a multimedia module to facilitate interaction between the multimedia component 608 and the processing component 602.

[0367] The memory 604 is configured to store various types of data to support operations on the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 600, contact data, phone book data, messages, pictures, videos, etc. The memory 604 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0368] The power supply assembly 606 provides power to the various components of the electronic device 600. The power supply assembly 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 600.

[0369] The multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action. In some embodiments, the multimedia component 608 includes a front-facing camera and / or a rear-facing camera. When the electronic device 600 is in an operating mode, such as a capture mode or a video mode, the front-facing camera and / or the rear-facing camera can receive external multimedia data. Each front-facing camera and the rear-facing camera can have a fixed optical lens system or have focal length and optical zoom capabilities.

[0370] The audio component 610 is configured to output and / or input audio signals. For example, the audio component 610 includes a microphone (MIC) that is configured to receive external audio signals when the electronic device 600 is in an operating mode, such as a call mode, a recording mode, or a voice information processing mode. The received audio signals may be further stored in the memory 604 or transmitted via the communication component 616. In some embodiments, the audio component 610 also includes a speaker for outputting audio signals.

[0371] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as a keyboard, click wheel, buttons, etc. These buttons may include but are not limited to: a home button, volume buttons, a start button, and a lock button.

[0372] The sensor assembly 614 includes one or more sensors for providing various aspects of status assessment for the electronic device 600. For example, the sensor assembly 614 can detect the open / closed state of the electronic device 600, the relative positioning of components, such as the display and keypad of the device 600. The sensor assembly 614 can also detect changes in the position of the electronic device 600 or a component of the electronic device 600, the presence or absence of user contact with the electronic device 600, the orientation or acceleration / deceleration of the electronic device 600, and temperature changes of the electronic device 600. The sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 614 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 614 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0373] The communication component 616 is configured to facilitate wired or wireless communication between the electronic device 600 and other devices. The electronic device 600 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 616 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency information processing (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0374] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0375] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions. The instructions can be executed by the processor 620 of the electronic device 600 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0376] A readable storage medium, when the instructions in the storage medium are executed by the processor of an electronic device (server or terminal), enables the processor to perform Figure 1 The firmware processing method shown.

[0377] The above is a detailed introduction to a firmware processing method, device, and electronic device provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only intended to help understand the method and core concept of the present invention. At the same time, for those skilled in the art, according to the concept of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the contents of this specification should not be understood as limiting the present invention.

Claims

1. A firmware processing method, characterized in that: The method comprises: Obtaining a firmware file to be verified; the firmware file includes firmware data and signature data; the signature data is obtained by signing the firmware data during the firmware file generation phase; parsing the signature data and the firmware data from the firmware file when the current version information of the firmware file matches the target version information to be updated; Performing a security check on the firmware file according to the check values corresponding to the signature data and the firmware data; The method also includes: obtaining firmware source code and adding current version information to the firmware source code to generate first firmware data; performing binary compilation on the first firmware data to generate second firmware data, and after integrity verification, generating the signature data based on the verification result; and adding the signature data to the second firmware data to generate the firmware file.

2. The method according to claim 1, characterized in that Generating the signature data according to the verification result includes: Generate a key pair using a predetermined encryption algorithm; the key pair includes a public key and a private key; The verification result is encrypted based on the private key to generate the signature data.

3. The method according to any one of claims 1 to 2, characterized in that The performing security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data, includes: Performing an inference operation based on the signature data to generate a first check value corresponding to the signature data; Performing an integrity check on the firmware data to generate a second check value corresponding to the firmware data; Perform a security check on the firmware file according to the first check value and the second check value.

4. The method according to claim 3, characterized in that The performing an inference operation based on the signature data to generate a first check value corresponding to the signature data includes: The signature data is decrypted based on the public key to generate the first verification value.

5. The method according to any one of claims 1 to 2, characterized in that The performing security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data, includes: Comparing a first check value corresponding to the signature data with a second check value corresponding to the firmware data; If the first check value is the same as the second check value, it is determined that the firmware file passes the security check, and the firmware data is burned into a predetermined chip.

6. A firmware processing device, characterized in that: The device comprises: A first acquisition module is configured to acquire a firmware file to be verified; the firmware file includes firmware data and signature data; the signature data is obtained by signing the firmware data during the firmware file generation phase; a parsing module, configured to parse the signature data and the firmware data from the firmware file if the current version information of the firmware file matches the target version information to be updated; A verification module, configured to perform a security verification on the firmware file according to the verification values corresponding to the signature data and the firmware data; The device further comprises: a second acquisition module, configured to acquire a firmware source code, and add current version information to the firmware source code to generate first firmware data; a data processing module, configured to perform binary compilation on the first firmware data to generate second firmware data, and generate the signature data according to the integrity check result after performing integrity check on the second firmware data; A splicing module is used to add the signature data to the second firmware data to generate the firmware file.

7. An electronic device, characterized in that: The electronic device includes a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to execute the firmware processing method according to any one of claims 1 to 5 by one or more processors.

8. A readable storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the processor is enabled to execute the firmware processing method according to any one of claims 1 to 5.

Images