Method for updating controller firmware, electronic device, and storage medium

Abstract

The application discloses a controller firmware updating method, an electronic device and a storage medium, and relates to the technical field of servers. The method comprises the following steps: receiving an updating request; detecting a first attribute of first updating data of a target controller firmware indicated by the updating request, and detecting a second attribute of a reference controller firmware used by a server controller. The first attribute can indicate an encryption state of the first updating data, and the second attribute can indicate the support of the reference controller firmware for an encryption updating mode. Second updating data matched with the server controller is generated by using the first updating data according to the first attribute and the second attribute. The second updating data is sent to the server controller, and is used for updating the controller firmware of the server controller to the target controller firmware. The technical problems of low controller firmware updating efficiency are solved, and the technical effect of improving the controller firmware updating efficiency is achieved.

Description

Technical Field

[0001] This application relates to the field of server technology, and more specifically, to a method for updating controller firmware, an electronic device, and a storage medium. Background Technology

[0002] In related technologies, controller firmware updates typically involve directly downloading and flashing the target controller firmware onto the server controller. For security reasons, the target controller firmware is usually pre-encrypted upon release. However, if the server controller's current firmware does not support encrypted updates, decryption of the target controller firmware becomes impossible, leading to flashing failure. In severe cases, this can cause server controller malfunction or even system boot failure. To avoid update failures due to encryption mismatches, traditional operations and maintenance often require maintaining both encrypted and plaintext update data for the same firmware version. This not only increases the complexity of firmware management but also makes update operations highly dependent on manual judgment and selection, making it difficult to guarantee firmware update efficiency.

[0003] No effective solution has yet been proposed to address the technical issues of low efficiency in controller firmware updates in related technologies. Summary of the Invention

[0004] This application provides a method for updating controller firmware, an electronic device, and a storage medium to at least solve the technical problem of low efficiency in updating controller firmware in related technologies.

[0005] According to one embodiment of this application, a method for updating controller firmware is provided, comprising:

[0006] Receive an update request, wherein the update request is used to request that the server controller's firmware be updated to the target controller firmware;

[0007] The system detects a first attribute of the first update data of the target controller firmware indicated by the update request, and detects a second attribute of the reference controller firmware used by the server controller, wherein the first attribute is used to indicate the encryption status of the first update data, and the second attribute is used to indicate the support of the reference controller firmware for the encryption update method.

[0008] Based on the first attribute and the second attribute, use the first update data to generate second update data that matches the server controller;

[0009] The second update data is sent to the server controller, wherein the second update data is used to update the server controller firmware to the target controller firmware.

[0010] According to another embodiment of the present application, a controller firmware update apparatus is also provided, comprising:

[0011] The first receiving module is used to receive update requests, wherein the update request is used to request that the controller firmware of the server controller be updated to the target controller firmware;

[0012] The first detection module is used to detect the first attribute of the first update data of the target controller firmware indicated by the update request, and to detect the second attribute of the reference controller firmware used by the server controller, wherein the first attribute is used to indicate the encryption status of the first update data, and the second attribute is used to indicate the support of the reference controller firmware for the encryption update method.

[0013] A generation module is used to generate second update data that matches the server controller based on the first update data and the second attribute;

[0014] The first sending module is used to send the second update data to the server controller, wherein the second update data is used to update the server controller firmware to the target controller firmware.

[0015] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described controller firmware update methods when executing the computer program.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described controller firmware update methods.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described controller firmware update methods.

[0018] This application addresses the issue that, upon receiving an update request to update the server controller's firmware to the target controller's firmware, instead of directly sending the first update data of the target controller firmware to the server controller, it first checks the encryption status of the first update data and the support for encrypted update methods by the reference controller firmware used by the server controller. Then, based on the encryption status of the first update data and the support for encrypted update methods by the reference controller firmware, it generates second update data matching the server controller and sends this second update data to the server controller. In other words, by using the first update data to generate second update data matching the server controller based on the first and second attributes, it ensures that the update data sent to the server controller matches the server controller, thus avoiding the flashing failure problem caused by directly sending encrypted update data of the target controller firmware to a server controller that does not support encrypted update methods, as seen in related technologies. It also eliminates the need to maintain both encrypted and plaintext update data simultaneously, reducing the complexity of firmware management and reliance on manual judgment, and achieving efficient controller firmware updates. Therefore, it solves the technical problem of low controller firmware update efficiency in related technologies, achieving the technical effect of improving controller firmware update efficiency. Attached Figure Description

[0019] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a hardware structure block diagram of a computer device for a controller firmware update method according to an embodiment of this application.

[0021] Figure 2 This is a flowchart of a controller firmware update method according to an embodiment of this application;

[0022] Figure 3 This is a flowchart of a method for detecting a feature string according to an embodiment of this application;

[0023] Figure 4 This is a flowchart of a memory matching algorithm according to an embodiment of this application;

[0024] Figure 5 This is a flowchart illustrating the processing of update requests according to an embodiment of this application;

[0025] Figure 6 This is a flowchart of the firmware decryption processing function according to an embodiment of this application;

[0026] Figure 7 This is a flowchart of a key decryption function according to an embodiment of this application;

[0027] Figure 8 This is a structural block diagram of a controller firmware update device according to an embodiment of this application;

[0028] Figure 9 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0030] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0031] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a computer device for a controller firmware update method according to an embodiment of this application. Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a central processing unit (CPU), microprocessor (MCU), or field-programmable gate array (FPGA)) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0033] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the controller firmware update method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0034] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0035] This application proposes a method for updating controller firmware. Before describing the optional embodiments of this application, to better understand the inventive concept and the originality of this solution, related technologies are first described: In related technologies, the controller firmware is usually updated by directly sending the target controller firmware to the server controller and flashing it. To ensure the security of the firmware during transmission and storage, the target controller firmware is usually provided in encrypted form when released. However, this method has limitations in practical applications: if the firmware version currently running on the server controller is low and does not support the encrypted update mechanism, directly sending the encrypted target controller firmware will lead to verification failure, loading anomalies, or even cause the server controller to malfunction or the system to fail to start. To avoid update failures caused by mismatched encryption states, traditional maintenance often requires maintaining two sets of image files, one encrypted and one plaintext, for the same firmware version. This not only greatly increases the complexity of firmware management but also makes the controller firmware update process highly dependent on manual judgment and image selection, which reduces update efficiency and introduces the risk of human error.

[0036] To address the aforementioned issues, this embodiment provides a method for updating controller firmware. Figure 2 This is a flowchart of a controller firmware update method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0037] Step S12, receive an update request, wherein the update request is used to request that the server controller's controller firmware be updated to the target controller firmware;

[0038] Step S14: Detect the first attribute of the first update data of the target controller firmware indicated by the update request, and detect the second attribute of the reference controller firmware used by the server controller, wherein the first attribute is used to indicate the encryption status of the first update data, and the second attribute is used to indicate the support of the reference controller firmware for the encryption update method.

[0039] Step S16: Generate second update data that matches the server controller using the first update data based on the first attribute and the second attribute;

[0040] Step S18: Send the second update data to the server controller, wherein the second update data is used to update the server controller firmware to the target controller firmware.

[0041] Optionally, in this embodiment, the server controller may be, but is not limited to, a hardware device with independent processing capabilities and running a firmware system. The server controller may be, but is not limited to, responsible for monitoring the server's hardware status (such as temperature, voltage, fan speed), remote management (such as remote control, remote power on / off / reboot), and low-level logic control. The server controller may be, but is not limited to, powered by an independent auxiliary power supply. Even if the server's main system is powered off, in standby, or in an operating system crash state, as long as the power cord is properly connected, the server controller can still maintain full functionality, continuously respond to external management requests, and maintain the stability of the low-level hardware logic.

[0042] Optionally, in this embodiment, the hardware device with independent processing capabilities and running a firmware system may be, but is not limited to, a Baseboard Management Controller (BMC) or a Complex Programmable Logic Device (CPLD).

[0043] Optionally, in this embodiment, the controller firmware is a collection of underlying software and configuration data embedded in the internal storage of the server controller, enabling its specific hardware management and control functions. When the server controller is a BMC, the controller firmware can perform functions such as hardware status acquisition and reporting, Intelligent Platform Management Interface (IPMI) protocol parsing and response; when the server controller is a CPLD, the controller firmware can perform functions such as hardware startup timing control, signal routing scheduling, and fault emergency protection.

[0044] Optionally, in this embodiment, the target controller firmware is the firmware that this update request expects to flash to the server controller (e.g., BMC_V3.0 or CPLD_V2.0). The reference controller firmware refers to the firmware currently running on the server controller (e.g., BMC_V1.0 or CPLD_V1.0).

[0045] Optionally, in this embodiment, the carrier form and storage medium of the controller firmware are determined by the type of server controller. When the server controller is a BMC, the carrier form of the controller firmware may be, but is not limited to, a BMC image file with the suffix ".hpm" or ".ima". The BMC image file may include, but is not limited to, a basic bootloader module (such as a Universal Boot Loader (U-Boot)), a system kernel module (such as a Linux kernel), an application layer service module, a hardware driver module, a security authentication module, and a configuration parameter storage area. The storage medium of the BMC image file may be, but is not limited to, a flash memory storage area associated with the BMC (such as a serial peripheral interface flash memory). When the server controller is a CPLD, the carrier form of the controller firmware may be, but is not limited to, a CPLD logical configuration file with the suffix ".jic" or ".svf". The CPLD logical configuration file may include, but is not limited to, a low-level logic driver unit, a hardware timing control unit, a signal routing unit, a fault detection and fault tolerance unit, and a configuration interface unit. Furthermore, the storage medium of the CPLD logical configuration file may be, but is not limited to, a non-volatile configuration memory chip associated with the CPLD.

[0046] Optionally, in this embodiment, the update request may be, but is not limited to, an instruction or signal that triggers a firmware version update operation. This instruction or signal may be, but is not limited to, initiated by maintenance personnel through client tools, or automatically issued by the cloud management platform. The firmware version update operation is the operation of updating the server controller's firmware to the target controller firmware. The update request may, but is not limited to, carrying a data packet or download address of the target controller firmware. The firmware version update operation may, but is not limited to, include firmware version upgrade operations and firmware version rollback operations to adapt to different maintenance needs and fault recovery scenarios. When the target controller firmware version is higher than the current server controller firmware version, the firmware version update operation is a firmware version upgrade operation; when the target controller firmware version is lower than the current server controller firmware version, the firmware version update operation is a firmware version rollback operation.

[0047] In the embodiment provided in step S12 above, the entity receiving the update request may be, but is not limited to, an upgrade tool. The upgrade tool may be, but is not limited to, a firmware update application running on a maintenance terminal (such as a personal computer (PC)) or a centralized management server, such as the yafuflash tool for BMC firmware updates, or a burning tool for CPLD firmware updates. The upgrade tool can receive update instructions based on different interaction modes, including but not limited to command line interface (CLI) mode and graphical user interface (GUI) mode.

[0048] In the embodiment provided in step S12 above, for the update scenario of a single server controller, the upgrade tool can, but is not limited to, receive update requests directly through operation and maintenance personnel. For example, when the server controller to be updated is a BMC, the operation and maintenance personnel issue a command carrying the target device identifier and firmware path through a terminal input tool, for example, the command format is ". / yafuflash -i 192.168.1.100 -f . / BMC_V3.0.hpm". Here, "192.168.1.100" is the network IP (Internet Protocol) address of the BMC to be updated (used to establish remote communication), and ". / BMC_V3.0.hpm" is the local storage path of the target controller firmware; after the background processing process of the upgrade tool captures and parses this command, it is considered that the update request for the BMC has been successfully received. When the server controller to be updated is a CPLD, the operation and maintenance personnel can import the CPLD logic configuration file through the GUI interface of the flashing tool and click the "Start Update" button. When the upgrade tool receives and recognizes the operation instruction, it is considered to have successfully received the update request for the CPLD.

[0049] Optionally, in a single server controller update scenario, after receiving an update request, the upgrade tool may also perform, but is not limited to, a security verification process, including: verifying the validity of the update request timestamp, verifying the integrity of the checksum (such as SHA-256 (Secure Hash Algorithm 256-bit) verification), and matching the controller identifier carried in the update request with the locally pre-stored device information. After all verification items pass, the upgrade tool completes the reception and parsing of the update request and generates a receipt to send back to the operations and maintenance platform.

[0050] In the embodiment provided in step S12 above, for batch update scenarios of multiple server controllers, the upgrade tool can, but is not limited to, receive update requests automatically issued by the cloud management platform through the batch management interface of the operation and maintenance platform. For example, the operation and maintenance platform generates multiple update requests corresponding one-to-one with multiple server controllers according to the batch update requirements. Each update request contains at least core information such as controller identifier, target controller firmware storage path, update priority, and digital signature. The operation and maintenance platform encapsulates all update requests into encrypted data packets and sends them to the upgrade tool through the cloud batch management interface. For example, it uses SSL (Secure Sockets Layer) / TLS (Transport Layer Security) protocols to encapsulate all update requests into encrypted data packets. After receiving the data packets, the upgrade tool first performs security verification (verifying the validity of the timestamp, the legality of the digital signature, and the integrity of the checksum). After the verification is passed, it locates the target controller firmware according to the controller identifier and target controller firmware path of each update request, and sorts and marks the tasks according to the update priority (such as marking core business servers as high priority) to ensure the orderliness of batch updates.

[0051] Optionally, in this embodiment, the first update data may be, but is not limited to, the original data carrier of the target controller firmware specified in the update request. The original data carrier may be, but is not limited to, a ".hpm" image file of the BMC, a ".jic" configuration file of the CPLD, or a binary data stream. The content format of the first update data depends on the type of server controller: when the server controller is a BMC, the first update data is BMC image file data; when the server controller is a CPLD, the first update data is CPLD logical configuration file data.

[0052] Optionally, in this embodiment, the first attribute may be used, but is not limited to, to indicate the encryption state of the first updated data. The encryption state may include, but is not limited to, an unencrypted state, an encrypted state, and a pseudo-encrypted state. Specifically, an unencrypted state may, but is not limited to, mean that the content of the first updated data has not undergone any encryption algorithm processing, maintaining the original binary format of the firmware compilation output; an encrypted state may, but is not limited to, mean that the content of the first updated data has undergone complete and valid encryption algorithm processing, with the data byte distribution exhibiting high randomness and conforming to the statistical characteristics of cryptographic ciphertext; a pseudo-encrypted state may, but is not limited to, mean that the content of the first updated data appears to be in an encrypted state (e.g., feature information is not visible), but in reality, it neither conforms to an unencrypted state nor an encrypted state, or the content of the first updated data is corrupted (e.g., file header is missing, data is truncated), belonging to an abnormal state.

[0053] Optionally, in this embodiment, the second attribute may, but is not limited to, indicating the reference controller firmware's support for encrypted update methods. Support may, but is not limited to, whether the reference controller firmware integrates a key management module and decryption algorithm library for decrypting ciphertext update data. The second attribute may, but is not limited to, a functional identifier reflecting the reference controller firmware's compatibility with encrypted update methods. For example, the controller firmware may be divided into "supported versions" and "unsupported versions." "Unsupported versions" only have the ability to load plaintext update data; directly receiving ciphertext update data will result in verification failure or system startup failure. "Supported versions" have a built-in private key and decryption logic, enabling them to identify and decrypt incoming ciphertext update data.

[0054] In the embodiment provided in step S14, the first attribute of the first update data and the second attribute of the reference controller firmware can be detected by the upgrade tool, but are not limited to the detection of the first attribute of the first update data.

[0055] Optionally, in this embodiment, the upgrade tool may, but is not limited to, using a metadata parsing method to detect the first attribute of the first update data. The detection steps may, but are not limited to, reading the metadata area or firmware header information of the first update data and determining the encryption status by specifying a flag bit. If the specified flag bit indicates that the first update data is ciphertext update data (i.e., the encryption status of the first update data is encrypted), then encrypted metadata is extracted from the first update data. The encrypted metadata includes, but is not limited to, at least one of encryption algorithm type, key identifier, key storage path, initialization vector, integrity check value, and digital signature. If the specified flag bit indicates that the first update data is plaintext update data (i.e., the encryption status of the first update data is unencrypted), then the firmware version identifier and plaintext check value are extracted from the first update data for subsequent update verification.

[0056] In another implementation, the upgrade tool may, but is not limited to, employ a policy configuration and signature verification method to detect the first attribute of the first update data. The detection steps may include, but are not limited to, querying the policy configuration library for the preset encryption state of the first update data based on its firmware file path, naming rules, or associated hardware identifier. If the policy configuration library records the preset encryption state of the first update data as encrypted firmware, then the tool further detects whether the first update data contains a valid digital signature or certificate chain. If a valid digital signature or certificate chain is detected, the tool determines that the first attribute indicates the encryption state of the first update data as encrypted; if no valid digital signature or certificate chain is detected, the tool determines that the first attribute indicates the encryption state of the first update data as pseudo-encrypted. If the policy configuration library records the preset encryption state of the first update data as unencrypted, the tool determines that the first attribute indicates the encryption state of the first update data as unencrypted.

[0057] Optionally, in this embodiment, the detection of the second attribute of the reference controller firmware can be, but is not limited to, a detection method based on version threshold comparison. This detection method can include, but is not limited to, establishing a communication connection with the server controller via a network communication protocol or a local hardware interface. The network communication protocol can be, but is not limited to, Transmission Control Protocol (TCP) or Internet Protocol. Subsequently, a version query command is sent to the server controller to request the version identification information of the reference controller firmware currently running on the server controller. Upon receiving the version identification information returned by the server controller (such as the version number string "3.02.05" or version code), the version identification information is compared with a locally preset encryption support baseline threshold. The encryption support baseline threshold can be, but is not limited to, a version number (such as V3.0), which defines the firmware version boundary at which the server controller begins to support encryption update functionality. If the version identification information of the reference controller firmware is less than the encryption support baseline threshold, the upgrade tool determines that the second attribute indicates that the reference controller firmware does not support encryption update methods. This indicates that the current reference controller firmware has not yet integrated a decryption module and cannot directly process encrypted firmware images. If the version identifier information of the reference controller firmware is greater than or equal to the encryption support baseline threshold, the upgrade tool determines that the second attribute is used to indicate that the reference controller firmware supports encrypted update methods. This indicates that the current reference controller firmware has built-in decryption logic and keys, and has the ability to directly receive and decrypt encrypted firmware images.

[0058] In another implementation, detecting the second attribute of the reference controller firmware can also, but is not limited to, employ a detection method based on capability negotiation. This detection method can, but is not limited to, sending a capability query command to the server controller, the capability query command being used to request a list of features or a feature bitmap supported by the server controller. Upon receiving the capability query command, the server controller returns a response message, which records the list of features or a feature bitmap currently supported by the server controller. The upgrade tool parses the received response message and checks whether it contains a specific flag bit or field indicating "support for encrypted update methods." For example, in the feature bitmap of the response message, if the Nth bit is set (e.g., set to 1), it indicates that the server controller has firmware decryption capability (i.e., supports encrypted update methods); if the Nth bit is not set (e.g., set to 0), it indicates that the server controller does not have firmware decryption capability (i.e., does not support encrypted update methods). Alternatively, an encrypted handshake probe message can be sent to the server controller. If the server controller responds to the encrypted handshake probe message and returns the expected handshake confirmation signal, the second attribute is determined to indicate that the reference controller firmware supports the encrypted update method. If the server controller returns an "unsupported command" error code or a timeout occurs, the second attribute is determined to indicate that the reference controller firmware does not support the encrypted update method. This method does not rely on a hard comparison of version numbers and can more flexibly adapt to the firmware version detection needs of different manufacturers or different customized branches.

[0059] Optionally, in this embodiment, the second update data may refer to, but is not limited to, firmware data that can be directly received, parsed, and flashed by the server controller currently running the reference controller firmware. The content of the second update data depends on the matching result of the first attribute and the second attribute.

[0060] In the embodiment provided in step S16, the generation of second update data matching the server controller using the first update data based on the first attribute and the second attribute can be, but is not limited to, performed by the upgrade tool. The upgrade tool generates the second update data based on the first attribute and the second attribute, using a preset adaptation strategy.

[0061] Optionally, in this embodiment, when it is detected that the second attribute indicates that the reference controller firmware does not support encrypted updates, and the first attribute indicates that the first update data is in an encrypted state, the step of generating the second update data may include, but is not limited to: the upgrade tool starts the decryption process, extracts the locally obfuscated password and restores it to a plaintext key, uses the restored plaintext key to perform a decryption operation on the first update data, and obtains plaintext data as the second update data to adapt to the server controller that does not support the encrypted update method.

[0062] In another implementation, when it is detected that the reference controller firmware does not support encrypted updates, the step of the upgrade tool generating second update data may include, but is not limited to, generating transitional update data. This transitional update data is an intermediate version of firmware in an unencrypted state, adapted to the server controller that does not support encrypted updates. The firmware version corresponding to the transitional update data is typically between the reference controller firmware and the target controller firmware, and it integrates a security module containing a key and decryption algorithm for decrypting the first update data. The combined data including the first update data and the transitional update data is used as the second update data. That is, the server controller is first upgraded to an intermediate state with decryption capabilities using the transitional update data in the second update data, and then the first update data in the second update data is used to complete the final update of the target controller firmware. This method ensures that the first update data remains encrypted throughout the transmission process and is not restored to plaintext update data at the upgrade tool end.

[0063] In the embodiment provided in step S16, when the second attribute is detected to indicate that the reference controller firmware supports encrypted update mode, or the first attribute is detected to indicate that the encryption state of the first update data is unencrypted, the upgrade tool may, but is not limited to, directly use a copy of the first update data as the second update data. In this case, the reference controller firmware supporting encrypted update mode can directly process ciphertext update data, while plaintext update data can be directly recognized by the reference controller firmware, both of which meet the adaptation requirements.

[0064] In the embodiment provided in step S16, when it is detected that the encryption state of the first updated data is a pseudo-encryption state, an error message is generated and the process is terminated.

[0065] In the embodiment provided in step S18, sending the second update data to the server controller can be, but is not limited to, performed by the upgrade tool. The upgrade tool can, but is not limited to, sending the second update data to the server controller through a corresponding communication channel according to the format of the second update data.

[0066] Optionally, in this embodiment, when the second update data is plaintext data, a memory-level secure transmission mode can be used to send the second update data to the server controller, but is not limited to. This method includes: establishing an encrypted transmission channel (such as an SSL / TLS connection) with the server controller; then reading the second update data from local volatile memory and sending the second update data in packets to the server controller. Throughout the entire transmission process, the upgrade tool is strictly prohibited from writing the second update data to the local disk or any non-volatile storage medium to prevent firmware code leakage. After the second update data transmission is complete and the server controller confirms receipt, the upgrade tool immediately calls a memory cleanup function (e.g., the memset function, used to zero out memory) to overwrite the memory area storing the second update data with "0" or a random number, thoroughly removing any remaining traces.

[0067] Optionally, in this embodiment, when the second update data is a combination of the first update data and the transitional update data, a phased timing transmission mode can be used to send the second update data to the server controller. This method includes: sending the transitional update data included in the second update data to the server controller, and sending a command to trigger the server controller to perform an update and restart operation for the transitional update data. After the upgrade tool completes the transmission, it enters a polling waiting state, continuously checking the online status or version information of the server controller to confirm whether it has completed a restart and successfully runs on the intermediate firmware version. After confirming that the server controller has decryption capabilities (i.e., detecting a version number change or capability bit update), the upgrade tool initiates the transmission process again, sending the first update data from the second update data to the server controller. At this time, the server controller uses the newly acquired decryption capabilities to process the encrypted update data, completing the firmware update.

[0068] Optionally, in this embodiment, when the second updated data is a copy of the first updated data, the second updated data can be sent to the server controller using a standard transport verification mode, but is not limited to this. The method includes: calculating an integrity check value (such as a SHA-256 value) for the second updated data before sending it. The second updated data is then sent to the server controller, and the integrity check value is sent at the end of the transmission. The server controller recalculates and verifies the second updated data in its receive buffer, and only writes the second updated data to flash memory after the verification passes, ensuring that the transmission process is error-free or tamper-proof.

[0069] This application addresses the issue that, upon receiving an update request to update the server controller's firmware to the target controller's firmware, instead of directly sending the first update data of the target controller firmware to the server controller, it first checks the encryption status of the first update data and the support for encrypted update methods by the reference controller firmware used by the server controller. Then, based on the encryption status of the first update data and the support for encrypted update methods by the reference controller firmware, it generates second update data matching the server controller and sends this second update data to the server controller. In other words, by using the first update data to generate second update data matching the server controller based on the first and second attributes, it ensures that the update data sent to the server controller matches the server controller, thus avoiding the flashing failure problem caused by directly sending encrypted update data of the target controller firmware to a server controller that does not support encrypted update methods, as seen in related technologies. It also eliminates the need to maintain both encrypted and plaintext update data simultaneously, reducing the complexity of firmware management and reliance on manual judgment, and achieving efficient controller firmware updates. Therefore, it solves the technical problem of low controller firmware update efficiency in related technologies, achieving the technical effect of improving controller firmware update efficiency.

[0070] As an optional approach, a first attribute of the first update data of the target controller firmware indicated by the update request is detected, and a second attribute of the reference controller firmware used by the server controller is detected, including:

[0071] S21, detect the first attribute of the first updated data; if the first attribute is used to indicate that the encryption state of the first updated data is encrypted, detect the second attribute of the reference controller firmware used by the server controller.

[0072] Alternatively, S22, detect the second attribute of the reference controller firmware used by the server controller; if the second attribute is used to indicate that the reference controller firmware does not support encrypted update methods, detect the first attribute of the first update data.

[0073] Optionally, in this embodiment, the first attribute of the first update data of the target controller firmware indicated by the update request, and the second attribute of the reference controller firmware used by the server controller, can be detected through various detection logics. These logics include: first detecting the first attribute, and then detecting the second attribute based on the detection result of the first attribute; or, first detecting the second attribute, and then detecting the first attribute based on the detection result of the second attribute. Furthermore, in another implementation, a parallel detection method can be used to simultaneously detect the first and second attributes. In practical applications, any of the above detection logics can be flexibly selected based on the application scenario, network environment, or policy configuration to optimize detection efficiency.

[0074] Optionally, in this embodiment, the detection method for the first attribute can refer to the metadata parsing method or the policy configuration and signature verification method mentioned in the previous embodiments, and the detection method for the second attribute can refer to, but is not limited to, the detection method based on version threshold comparison or the detection method based on functional capability negotiation mentioned in the previous embodiments, which will not be elaborated here.

[0075] In the embodiment provided in step S21, a detection logic is adopted that first detects a first attribute, and then detects a second attribute based on the detection result of the first attribute. This detection logic includes:

[0076] If the first attribute indicating that the first update data is encrypted is detected, the subsequent process depends on the support of the reference controller firmware used by the server controller for the encryption update method, and the second attribute of the reference controller firmware used by the server controller is detected. If the second attribute indicating that the reference controller firmware supports the encryption update method is detected (e.g., the version of the reference controller firmware is greater than or equal to the encryption support baseline threshold), it indicates that the first update data matches the server controller, and no processing is required; the first update data is directly sent to the server controller. If the second attribute indicating that the reference controller firmware does not support the encryption update method is detected (e.g., the version of the reference controller firmware is less than the version threshold supporting encryption), it indicates that the first update data does not match the server controller. The first update data is used to generate second update data that matches the server controller, and then the second update data is sent to the server controller.

[0077] If the first attribute used to indicate that the first updated data has an unencrypted state is detected, the detection of the second attribute may be skipped and the first updated data may be sent directly to the server controller.

[0078] If the first attribute used to indicate that the encryption state of the first updated data is a pseudo-encryption state is detected, an error message is generated and the process is terminated.

[0079] Optionally, in this embodiment, if the first attribute used to indicate that the encryption state of the first update data is unencrypted is detected, the detection of the second attribute can be skipped, but is not limited to. This is because regardless of whether the reference controller firmware supports encrypted updates, it matches plaintext update data, thus eliminating the need to detect the second attribute of the reference controller firmware, reducing the number of interactions with the server controller, and improving response speed.

[0080] In the embodiment provided in step S22, a detection logic is used to first detect the second attribute, and then a detection logic is used to detect the first attribute based on the detection result of the second attribute. This detection logic includes:

[0081] If a second attribute is detected indicating that the reference controller firmware does not support encrypted update methods, it is determined that the server controller cannot directly process the encrypted update data, and the first attribute of the first update data of the target controller firmware indicated by the update request is detected; if a first attribute is detected indicating that the encryption state of the first update data is encrypted, it indicates that the first update data does not match the server controller, and a second update data matching the server controller is generated using the first update data (e.g., decrypting the first update data to obtain plaintext update data), and then the second update data is sent to the server controller; if a first attribute is detected indicating that the encryption state of the first update data is unencrypted, it indicates that the first update data matches the server controller, and no processing of the first update data is required, and the first update data is directly sent to the server controller.

[0082] If a second attribute is detected indicating that the reference controller firmware supports encrypted update, the detection of the first attribute can be skipped and the first update data can be sent directly to the server controller.

[0083] If the first attribute used to indicate that the encryption state of the first updated data is a pseudo-encryption state is detected, an error message is generated and the process is terminated.

[0084] Optionally, in this embodiment, when the second attribute is detected to indicate that the reference controller firmware supports encrypted update mode, the detection of the first attribute can be skipped, but is not limited to. This is because the reference controller firmware that supports encrypted update mode can identify and process the received ciphertext update data or plaintext update data on its own, so there is no need to detect the first attribute of the first update data, which simplifies the processing logic of the upgrade tool and improves the processing efficiency.

[0085] Optionally, in this embodiment, the detection order of the first attribute and the second attribute can be set according to a preset detection priority, but is not limited to. The preset detection priority can be stored in the configuration file of the upgrade tool, or it can be a command-line parameter entered by the maintenance personnel when starting the upgrade tool.

[0086] Optionally, in this embodiment, for remote maintenance scenarios with limited network bandwidth and high network latency, the preset detection priority can be, but is not limited to, setting it to prioritize detecting the first attribute of the first updated data. Since the first attribute detection is a local process, while the second attribute detection requires network communication with the server controller, prioritizing the detection of the first attribute of the first updated data can avoid frequently initiating network requests before the encryption status of the first updated data is clearly defined, thus effectively reducing network overhead.

[0087] Optionally, in this embodiment, for local batch maintenance or production line programming scenarios with stable network connections and high transmission rates, the preset detection priority can be, but is not limited to, setting it to prioritize detecting the second attribute of the reference controller firmware. In batch update scenarios, there are likely to be a large number of server controllers that support encrypted updates. Prioritizing the detection of the second attribute can quickly filter out server controllers that support encrypted update methods, so as to apply compatibility strategies in a targeted manner and avoid unnecessary first attribute detection for all first update data.

[0088] In the above embodiments, by employing the steps of first detecting the first attribute and skipping the second attribute detection when it indicates an unencrypted state, or first detecting the second attribute and skipping the first attribute detection when it indicates support for encrypted update methods, the upgrade tool can dynamically skip subsequent detection operations based on the detection result of the previous attribute. This reduces invalid network interactions with the server controller when the first update data is plaintext update data, or simplifies the local data parsing logic when the reference controller firmware supports encrypted update methods. This avoids the defects of high network resource consumption and large response latency caused by the rigid fixed full detection process in related technologies, and achieves the technical effect of flexibly optimizing the detection path for different network environments and further improving the efficiency and response speed of controller firmware update detection.

[0089] As an alternative approach, after detecting the first attribute of the first updated data, the method further includes:

[0090] S31, if the first attribute is used to indicate that the encryption state of the first updated data is unencrypted, the first updated data is determined to be the second updated data.

[0091] Optionally, in this embodiment, the unencrypted state may refer to, but is not limited to, the content of the first update data not being processed by any encryption algorithm, maintaining the original binary format of the firmware compilation output. The first update data in the unencrypted state typically possesses at least one of the following characteristics: Visibility of feature information, meaning that at a specific offset address (e.g., 0x3FF0000) of the first update data, a preset feature string (e.g., firmware version number "UFW_VERSION" or compilation date "FW_DATE") can be directly read without any decoding operation. Regularity of instruction logic, meaning that the code segment of the first update data contains a large number of legal instructions, and the continuous length or proportion of legal instructions exceeds a preset plaintext judgment threshold. Legal instructions may include, but are not limited to, MOV (Move), LDR (Load Register), STR (Store Register), and ADD (Add) operations in Advanced RISC Machine (ARM) architectures. Low data entropy, meaning that the data disorder level of the first update data is lower than a preset disorder level, indicating that the data has a high degree of order.

[0092] Optionally, in this embodiment, if the first attribute is detected to indicate that the encryption state of the first updated data is unencrypted, the upgrade tool determines that there is no need to perform adaptation processing such as decryption, repackaging, or format conversion on the first updated data, and identifies the first updated data as the second updated data.

[0093] Optionally, in this embodiment, determining the first update data as the second update data can be understood, but is not limited to, as follows: the upgrade tool directly uses the originally received first update data as the final data carrier to be sent to the server controller.

[0094] Optionally, in this embodiment, determining the first updated data as the second updated data can be achieved, but is not limited to, through data reference passing or memory mapping. For example, if the upgrade tool determines that the first updated data does not need to be processed, the upgrade tool does not perform data transfer or format conversion operations, but directly passes the memory starting address, file path pointer, or loaded buffer handle storing the first updated data as parameters to the communication interface or transmission module responsible for performing the sending task.

[0095] In another implementation, identifying the first updated data as the second updated data can also be achieved, but is not limited to, through a complete data stream copy. For example, the upgrade tool allocates a dedicated transmission buffer in memory and copies the binary content of the first updated data bit-by-bit from the source storage location (such as a disk file or source memory block) into the transmission buffer. During this process, the upgrade tool does not decrypt, re-encode, or modify the content of the first updated data, ensuring that the second updated data stored in the transmission buffer is completely identical to the first updated data at the binary level.

[0096] Optionally, in this embodiment, since both server controllers running controller firmware that supports encrypted updates (e.g., firmware version V3.0 and above) and server controllers running controller firmware that does not support encrypted updates (e.g., firmware version V1.0) retain the ability to load and parse plaintext update data, the server controller has universal adaptability when the first update data is in an unencrypted state. It can directly determine the first update data as the second update data without considering the second attribute of the reference controller firmware, thereby simplifying intermediate processing steps and improving the efficiency of controller firmware updates.

[0097] As an alternative approach, after detecting the second attribute of the reference controller firmware used by the server controller, the method further includes:

[0098] S32, if the second attribute is used to indicate that the reference controller firmware supports encrypted update methods, the first update data is determined as the second update data.

[0099] Optionally, in this embodiment, supporting encrypted update methods may refer to, but is not limited to, the reference controller firmware currently running on the server controller integrating a decryption function module for parsing encrypted data or storing key data for decryption. When the reference controller firmware supports encrypted update methods, the server controller, upon receiving ciphertext update data, can decrypt and restore the update data using pre-set security credentials, thereby correctly processing the ciphertext update data.

[0100] Optionally, in this embodiment, not supporting encrypted update methods may refer to, but is not limited to, the fact that the reference controller firmware currently running on the server controller does not integrate a decryption function module for parsing encrypted data or does not store key data for decryption. If the reference controller firmware does not support encrypted update methods, and the server controller directly receives encrypted update data, it will fail the firmware integrity check (e.g., checksum mismatch) or fail to load the bootloader correctly, resulting in update failure. Therefore, a server controller that does not support encrypted update methods can only recognize and load plaintext update data.

[0101] Optionally, in this embodiment, when the second attribute is detected to indicate that the reference controller firmware supports encrypted update, the upgrade tool determines that there is no need to perform adaptation processing such as decryption or format conversion on the first update data, and identifies the first update data as the second update data.

[0102] Optionally, in this embodiment, since the server controller running controller firmware that supports encrypted update methods (e.g., firmware version V3.0 and above) typically integrates a security function module and key for decrypting data, it has the ability to autonomously decrypt and load encrypted update data. Therefore, when the reference controller firmware supports encrypted update methods, the server controller has the ability to directly process the first update data regardless of whether it is encrypted or unencrypted. The upgrade tool does not need to perform decryption operations locally and can directly identify the first update data as the second update data. This not only simplifies the intermediate processing steps and improves the efficiency of controller firmware updates, but also ensures that the first update data remains encrypted during transmission, avoiding the exposure of plaintext update data in the transmission link, thereby significantly improving the security of controller firmware updates.

[0103] In the above embodiments, by directly determining the first update data as the second update data when the first update data is detected to be unencrypted, or when the reference controller firmware used by the server controller is detected to support encrypted update methods, the upgrade tool can skip unnecessary adaptation processing operations such as local decryption, repackaging, or format conversion. Furthermore, when the reference controller firmware supports encrypted update methods, it ensures that the encrypted firmware data remains encrypted throughout the transmission link. In both cases, this effectively simplifies the pre-update processing steps and significantly enhances the security of firmware updates. It avoids the efficiency loss caused by redundant processing steps in related technologies and the security risks of plaintext data being exposed in the transmission link due to local decryption before transmission. This achieves the technical effects of simplifying the update process, improving the efficiency of controller firmware update processing, and enhancing firmware update security.

[0104] As an optional approach, detecting a first attribute of the first update data of the target controller firmware indicated by the update request includes:

[0105] S41, detect a feature string from the first updated data; if a feature string is detected, determine that the first attribute used to indicate the encryption state of the first updated data is an unencrypted state; if no feature string is detected, determine that the first attribute used to indicate the encryption state of the first updated data is an encrypted state.

[0106] Alternatively, in step S42, a feature string is detected from the first updated data; the relationship between the proportion of legitimate instructions in the first updated data and the proportion threshold is detected; and the relationship between the disorder level of the first updated data and the disorder threshold is detected. If a feature string is detected, the proportion of legitimate instructions is detected to be greater than or equal to the proportion threshold, and the disorder level is detected to be less than or equal to the disorder threshold, the first attribute used to indicate the encryption state of the first updated data is determined to be an unencrypted state. If no feature string is detected, the proportion of legitimate instructions is detected to be less than the proportion threshold, and the disorder level is detected to be greater than the disorder threshold, the first attribute used to indicate the encryption state of the first updated data is determined to be an encrypted state. If the proportion of legitimate instructions is detected to be greater than or equal to the proportion threshold and the disorder level is detected to be greater than the disorder threshold, or if the proportion of legitimate instructions is detected to be less than the proportion threshold and the disorder level is detected to be less than or equal to the disorder threshold, the first attribute used to indicate the encryption state of the first updated data is determined to be a pseudo-encrypted state.

[0107] Optionally, in this embodiment, the feature string may refer to, but is not limited to, a readable text identifier with specific semantics that is written to a fixed storage area during the compilation or packaging of update data. For example, the feature string may include, but is not limited to, firmware version identifiers (such as "UFW_VERSION") or firmware compilation dates (such as "FW_DATE"), or other specific identifier strings defined by the manufacturer. In plaintext update data, the aforementioned feature string is usually stored in plaintext form in a specific address segment of the plaintext update data; while in encrypted update data, due to the obfuscation effect of the encryption algorithm, the data in the specific address segment will present as a random byte sequence without specific semantics.

[0108] Optionally, in this embodiment, the step of detecting the feature string from the first updated data may include, but is not limited to, the following: the upgrade tool opens the first updated data in read-only binary mode and jumps the file pointer to a preset feature offset address (e.g., 0x3FF0000). Then, it reads data of a preset length (e.g., 1024 bytes) from this feature offset address into a memory buffer and matches the read data with a preset list of feature strings. If a feature string is detected (e.g., "UFW_VERSION" is successfully matched in the buffer), the upgrade tool determines that the data structure of the first updated data is complete and unobfuscated, and thus determines that the encryption state of the first updated data indicated by the first attribute is unencrypted. If no feature string is detected (e.g., the data at the feature offset address is garbled or cannot match any preset string), the upgrade tool determines that the critical information area of ​​the first updated data has been encrypted or obfuscated, and thus determines that the encryption state indicated by the first attribute of the first updated data is encrypted.

[0109] In the embodiment provided in step S41 above, a fast detection mechanism based on feature strings can be used to detect the first attribute. For example, the upgrade tool searches for known feature strings, such as firmware version identifiers, compilation timestamps, or vendor identifiers, in a predefined metadata area of ​​the first updated data (such as a specific offset address in the firmware header). The detection logic of the above fast detection mechanism is as follows: if a complete feature string is found at the specific offset address, it is determined that the first attribute is used to indicate the encryption state of the first updated data as an unencrypted state; if no complete feature string is found at the specific offset address, it is determined that the first attribute is used to indicate the encryption state of the first updated data as an encrypted state. The above fast detection mechanism is suitable for scenarios with high real-time detection requirements and highly standardized firmware formats.

[0110] Optionally, in this embodiment, the proportion of valid instructions may refer to, but is not limited to, the proportion of bytes occupied by valid machine instructions that conform to the encoding rules of the target processor architecture instruction set in the boot code region or core code segment of the first updated data. For example, high-frequency opcodes such as MOV, LDR, and STR that conform to the Thumb-2 instruction set of the ARMv7-M (Advanced RISC Machine v7-M) architecture can all be considered valid instructions.

[0111] Optionally, in this embodiment, the percentage threshold may be, but is not limited to, an empirical critical value determined by statistical analysis of a large number of known plaintext update data samples, for example, it may be set to 30%. For example, when the number of legal instruction bytes in the first update data boot code region or core code segment accounts for more than or equal to 30% of the total number of bytes in that segment, it can be preliminarily determined that the encryption state of the first update data is unencrypted.

[0112] Optionally, in this embodiment, the disorder level can be, but is not limited to, a statistical indicator reflecting the randomness or disorder of the first updated data content, and can be obtained through calculation methods such as information entropy or correlation between adjacent bytes. In an 8-bit byte system, the theoretical range of disorder level is 0 to 8. The higher the disorder level, the stronger the randomness of the first updated data, and the greater the amount of information or uncertainty contained in the first updated data.

[0113] Optionally, in this embodiment, the disorder threshold can be, but is not limited to, the entropy threshold used to distinguish between regular machine language text and encrypted ciphertext, for example, it can be set to 7.5. Generally, plaintext update data has a low disorder (typically less than 7.5) because it contains a large number of repetitive instruction patterns or fixed padding patterns; while update data processed by strong encryption algorithms such as Advanced Encryption Standard (AES) has a byte distribution that tends to be uniform, resulting in a high disorder (typically greater than 7.5).

[0114] Optionally, in this embodiment, the step of detecting the proportion of legitimate instructions in the first updated data may include, but is not limited to, selecting the header boot sector data (e.g., the first 4KB of data) of the first updated data and traversing it with a preset byte step size (e.g., 2 bytes). Counting the number of legitimate opcodes in the header boot sector data of the first updated data that conform to the instruction set specification of the target processor architecture (e.g., ARM architecture). Legitimate opcodes may include, but are not limited to, high-frequency instructions such as MOV, LDR, STR, and ADD. The proportion of legitimate instructions is the ratio of the counted number of legitimate opcodes to the total instruction capacity of the detection area.

[0115] Optionally, in this embodiment, the step of detecting the disorder of the first updated data may include, but is not limited to, randomly selecting a data block (e.g., randomly selecting 1KB of data) from the first updated data and calculating the entropy value of the data block using an information entropy algorithm. A higher entropy value indicates a higher disorder of the first updated data (closer to random noise), while a lower entropy value indicates a lower disorder of the first updated data (more regular).

[0116] Optionally, in this embodiment, a multi-dimensional detection mechanism that integrates feature string detection, legal instruction ratio detection, and disorder detection can also be used to detect the first attribute. In the above multi-dimensional detection mechanism, the detection logic is as follows:

[0117] If a characteristic string is detected, the proportion of legal instructions is greater than or equal to the proportion threshold, and the disorder level is less than or equal to the disorder threshold, the first attribute used to indicate the encryption state of the first updated data is determined to be an unencrypted state.

[0118] If no characteristic string is detected, the proportion of detected legitimate instructions is less than the proportion threshold, and the detected disorder level is greater than the disorder level threshold, the first attribute used to indicate the encryption state of the first updated data is determined to be an encrypted state.

[0119] If the proportion of legitimate instructions is greater than or equal to the proportion threshold and the disorder level is greater than the disorder level threshold, or if the proportion of legitimate instructions is less than the proportion threshold and the disorder level is less than or equal to the disorder level threshold, the first attribute used to indicate the encryption state of the first updated data is determined to be a pseudo-encryption state.

[0120] If a characteristic string is detected, but the proportion of legal instructions is less than the proportion threshold and the disorder level is greater than the disorder threshold, the encryption state of the first attribute used to indicate the encryption state of the first updated data is determined to be a pseudo-encryption state.

[0121] If no characteristic string is detected, but the proportion of detected legitimate instructions is greater than or equal to the proportion threshold and the detected disorder level is less than or equal to the disorder level threshold, the encryption state of the first attribute used to indicate the first updated data is determined to be a pseudo-encryption state.

[0122] The aforementioned multi-dimensional detection mechanism significantly improves the accuracy of the first attribute detection through multi-feature cross-validation. It can effectively identify pseudo-encrypted update data that appears encrypted but does not conform to cryptographic statistical laws, and can also exclude plaintext update data that appears chaotic due to special encoding but is actually a valid instruction sequence. It is suitable for firmware update scenarios with stringent security and reliability requirements.

[0123] In the above embodiments, by employing a fast detection based on feature strings, or a multi-dimensional detection mechanism that combines feature strings, the proportion of legitimate instructions, and disorder for cross-validation, the encryption status (first attribute) of the first updated data can be quickly and accurately determined. In particular, it can accurately identify abnormal pseudo-encryption statuses. This allows for the selection of fast detection based on different scenarios to suit situations with high real-time requirements, or the timely detection and termination of update processes targeting pseudo-encrypted or maliciously tampered data using multi-dimensional detection. This avoids the shortcomings of related technologies, such as insufficient detection accuracy and inability to effectively identify abnormal firmware data, leading to flashing failures or system crashes. It significantly improves the flexibility, accuracy, and reliability of firmware encryption status detection.

[0124] As an optional approach, feature strings are detected from the first updated data, including:

[0125] S51, Obtain the first data in the first updated data that is in the first address range, wherein the first address range is an address range that starts at a preset offset address and has a first preset length;

[0126] S52, Detect whether a feature string exists in the first data;

[0127] S53, if a feature string is detected in the first data, it is determined that a feature string has been detected;

[0128] S54, if the feature string is not detected in the first data, it is determined that no feature string was detected.

[0129] Optionally, in this embodiment, the preset offset address may refer to, but is not limited to, the starting byte position of the firmware information header in the image file as defined in the target controller firmware specification. For example, in some BMC firmware structures, the above-mentioned preset offset address is the hexadecimal value 0x3FF0000 (corresponding to the starting point of the last 64KB area at the 64MB position).

[0130] Optionally, in this embodiment, the first preset length is a preset reading length that is sufficient to cover the feature string and its terminator. For example, to fully read feature strings such as version number and date, the first preset length can be set to 1024 bytes (1KB).

[0131] Optionally, in this embodiment, the first data is a binary byte stream read from the first updated data and located within the first address range corresponding to the preset offset address. The steps for obtaining the first data may include, but are not limited to: the upgrade tool calling a file positioning function (such as the fseek function) to jump the read pointer to the preset offset address of the first updated data, such as executing "fseek(file_pointer, 0x3FF0000, 0)", where "0" indicates the offset from the beginning of the file; then calling a file reading function (such as the fread function) to read the first data, such as executing "fread(buffer, 1, 1024, file_pointer)" to read the binary data of the first preset length and load it into a memory buffer, such as char buffer

[1024] , the data in this buffer is the first data; if the total length of the first updated data is less than the preset offset address, the read operation will return an error, directly determining that the first updated data is incomplete or has an incorrect format.

[0132] Optionally, in this embodiment, the step of detecting whether a feature string exists in the first data can be implemented using, but is not limited to, a string matching algorithm. For example, the upgrade tool traverses the first data in the memory buffer, comparing the traversal results byte-by-byte with known feature strings (such as "UFW_VERSION") preset in the feature library. If a feature string is matched in the first data (such as "UFW_VERSION" matched at the Nth byte and subsequent characters conform to the version number format), a matching success signal is output, indicating that a feature string has been detected, and that the first data has not been encrypted or obfuscated; if no feature string is matched after the traversal is completed, a matching failure signal is output, indicating that no feature string has been detected, and that the first data has been encrypted into random ciphertext.

[0133] In another embodiment, the presence of a characteristic string in the first data can be detected by regular expression matching, but is not limited to that used. For example, a regular expression pattern, such as "UFW_VERSION=[\d.]+", can be defined to search for characteristic strings in the first data that conform to a version number or similar format.

[0134] In another embodiment, the memory substring search function (memmem) algorithm can also be used. The memmem algorithm supports processing binary data containing null characters ("\0") to avoid truncation. It searches a set of preset characteristic strings in the memory buffer, such as {"UFW_VERSION", "FW_DATE"}.

[0135] Optionally, in this embodiment, the core process of detecting whether a feature string exists in the first data is as follows: the upgrade tool opens the first update data file in read-only binary mode, jumps to a preset offset address through the file pointer positioning function, and reads data of a first preset length into the memory buffer; then, it searches for feature strings through any of the above matching methods. If the matching result returns a non-null pointer, it is determined that a feature string has been detected. If no match is found after traversing the feature string set, it is determined that no match has been detected.

[0136] Optionally, this embodiment also provides a method for detecting feature strings. Figure 3 This is a flowchart of a method for detecting feature strings according to an embodiment of this application, such as... Figure 3 As shown, the testing process includes the following steps:

[0137] Call the image encryption detection function to open the first updated data in read-only mode;

[0138] Determine if the file corresponding to the first updated data was opened successfully: If the file corresponding to the first updated data failed to open, the process ends directly and -1 is returned (representing that the feature string detection failed); if the file corresponding to the first updated data was opened successfully, the file positioning function (fseek function) is called to jump the read pointer to the preset feature offset address (e.g., 0x3FF0000).

[0139] Determine if the pointer jump was successful: If the jump failed, print the error log "Failed to jump to the characteristic offset address", close the file handle and end the process, returning -1 (indicating that the characteristic string detection failed); if the jump was successful, call the file reading function (fread function) to read the first data of the first preset length (e.g., 1023 bytes) from the characteristic offset address into the memory buffer.

[0140] Determine if the first data was successfully read: If reading fails, print the error log "Read file content recognition", end the process and return -1 (indicating feature string detection failure); if the first data was successfully read, proceed to the feature string matching stage.

[0141] Check if the pre-defined feature string list is NULL (empty): If the feature string list is empty, proceed directly to the feature existence flag check; if the feature string list is not empty, iterate through the list. For each feature string in the list, first calculate its length, then call the memory matching function to search for the feature string in the memory buffer: if the search result is not NULL (i.e., a matching feature string is found), set the feature existence flag to 1 (has_feature=1) and exit the current iteration loop; if not found, continue iterating through the next feature string.

[0142] After traversal, check if the feature existence flag is 1: if the feature existence flag is 1, return 0 (meaning the first updated data is in an unencrypted state); if the feature existence flag is not 1, return 1 (meaning the first updated data is in an encrypted state).

[0143] Optionally, this embodiment also provides a memory matching algorithm. Figure 4 This is a flowchart of a memory matching algorithm according to an embodiment of this application, such as... Figure 4 As shown, the memory matching algorithm is used to locate the feature string (i.e., tar) in the first piece of data read (i.e., src). The detection process includes the following steps:

[0144] First, perform a boundary condition check to determine whether the length of the feature string (tar_len) is 0, or whether the length of the feature string is greater than the length of the first data (src_len).

[0145] If any boundary exception condition is met, a null value (NULL) is returned directly, indicating that no characteristic string was found.

[0146] If none of the boundary exception conditions are met, the maximum starting index (max_start) of the outer loop is calculated. This index is equal to the length of the first data minus the length of the feature string. Then, the outer loop is entered, and the index variable i is used to traverse from 0 to the maximum starting index. In each iteration of the outer loop, the memory matching algorithm enters the inner loop, using the index variable j to traverse from 0 to the end of the feature string. In the inner loop, the byte content at the current offset position (i+j) in the first data is compared byte-by-byte with the corresponding byte content at position (j) in the feature string. If a mismatch is detected, the inner loop is exited, and the next iteration of the outer loop is executed (i.e., i is incremented by 1, and the next starting position is tried). If the inner loop completes its execution (i.e., j reaches the length of the feature string), it indicates that a complete match of the feature string has been successfully found at the current starting position i. At this point, the memory matching algorithm returns a pointer to the successfully matched position (source+i), which the upgrade tool uses to determine that the feature string has been detected.

[0147] If no match is found after the outer loop finishes executing, an empty value is returned, and the upgrade tool determines that no characteristic string has been detected. This double traversal mechanism ensures that any characteristic identifier can be accurately located in the binary data stream.

[0148] In the above embodiments, by adopting the steps of obtaining the first data in the first updated data according to the preset offset address and the first preset length, and detecting whether there is a feature string in the first data based on the string matching algorithm, the determination of the firmware encryption status can be carried out without traversing or decrypting the entire firmware file, but instead focusing on the fixed and small range of address space where the firmware information header is located. This greatly reduces the amount of data reading and matching calculation, further realizing the fast and accurate determination of the firmware encryption status and improving the efficiency of the first attribute detection.

[0149] As an optional approach, the relationship between the proportion of legitimate instructions and a proportion threshold in the first updated data is detected, including:

[0150] S61, Obtain the second data in the first updated data that is in the second address range, wherein the second address range is an address range with the starting address of the first updated data as the starting address and having a second preset length;

[0151] S62, detect the number of valid instructions included in the second data to obtain valid instruction parameters, and detect the number of instructions included in the second data to obtain reference instruction parameters, wherein a valid instruction is an instruction that conforms to the characteristics of the target opcode;

[0152] S63, calculate the ratio of legal instruction parameters to reference instruction parameters to obtain the percentage of legal instructions;

[0153] S64 compares the percentage of valid instructions with the percentage threshold;

[0154] S65, if the proportion of legitimate instructions is greater than or equal to the proportion threshold, it is determined that the proportion of legitimate instructions is greater than or equal to the proportion threshold.

[0155] S66, if the percentage of legitimate instructions is less than the percentage threshold, determine that the percentage of legitimate instructions is less than the percentage threshold.

[0156] Optionally, in this embodiment, the second address range typically refers to the bootloader region or interrupt vector table region in the first update data. The bootloader region or interrupt vector table region is usually located at the beginning of the update data, and its instruction characteristics are stable but easily corrupted after encryption.

[0157] Optionally, in this embodiment, the second preset length is a preset reading length sufficient to reflect the statistical regularity of the code. To balance detection speed and statistical accuracy, the second preset length can be set to 4096 bytes (i.e., 4KB). If the second preset length is set too short, it may lead to statistical deviation; if it is set too long, it will increase the detection time.

[0158] Optionally, in this embodiment, the second data is a binary instruction stream read from the starting position of the first updated data. The steps for obtaining the second data may include, but are not limited to, the following: the upgrade tool calls the file system application programming interface (API) to reset the read pointer to the beginning of the first updated data file, such as by executing "fseek(file_pointer, 0, SEEK_SET)", and then reads data of a second preset length and loads it into a memory buffer, where the data in the buffer is the second data.

[0159] Optionally, in this embodiment, the target opcode feature may refer to, but is not limited to, the binary encoding pattern of high-frequency instructions in the instruction set. Taking the Thumb-2 instruction set as an example, data transfer instructions (such as MOV / LDR), arithmetic instructions (such as ADD), and jump instructions have fixed high-order byte features. For example, the opcode range of MOV / LDR instruction is 0x4000~0x4FFF, and the jump instruction is 0xE000.

[0160] Optionally, in this embodiment, a valid instruction refers to a 2-byte (Thumb instruction) or 4-byte (Thumb-2 extended instruction) sequence in the second data that conforms to the characteristics of the target opcode described above. For example, if the two bytes read conform to the range of 0x4000~0x4FFF after masking, they are considered valid MOV-type instructions.

[0161] Optionally, in this embodiment, the step of detecting the proportion of legitimate instructions in the first updated data may include, but is not limited to:

[0162] The first 4KB of data from the first update is extracted as the detection sample.

[0163] The second data in the memory buffer is traversed in steps of instruction alignment length (2 bytes for the ARM Thumb-2 instruction set). Each traversal reads the instruction word at the current position and performs a bitwise AND operation with a preset opcode mask (e.g., for MOV / LDR instructions, the high 4 bits are extracted from the mask 0xF000). If the result matches the target feature value (e.g., 0x4000), it is considered a valid instruction, and the valid instruction counter is incremented by 1. Regardless of whether a match occurs, the total number of detected instructions is incremented by 1 (e.g., 2048 instructions are detected when traversing 4KB of data in 2-byte steps). Then, the percentage of valid instructions is calculated relative to the total number of reference instruction parameters (i.e., the total number of detected instructions).

[0164] The percentage of legitimate instructions is compared with a threshold percentage. If the calculated percentage of legitimate instructions is 35% and the preset threshold percentage is 30%, then the percentage of legitimate instructions detected is determined to be greater than the threshold percentage. If the calculated percentage of legitimate instructions is 25% and the preset threshold percentage is 30%, then the percentage of legitimate instructions detected is determined to be less than the threshold percentage.

[0165] In another embodiment, to reduce the probability of false positives, the maximum length of consecutively occurring legitimate instructions is additionally counted. Only when the proportion of legitimate instructions is greater than or equal to a threshold and there is at least one consecutive legitimate instruction sequence of 16 bytes or more is the proportion of legitimate instructions ultimately determined to be greater than or equal to the threshold.

[0166] Optionally, in this embodiment, to further improve the detection accuracy for ARM architecture firmware, the target opcode features may also include the binary encoding features of control flow instructions. When detecting the number of legitimate instructions included in the second data, a combined mask matching strategy can be employed. Specific steps include: defining a combined feature mask for branch jump instructions and stack operation instructions (PUSH / POP). For example, for the Thumb-2 instruction set, the opcode range of its branch jump instructions or stack operation instructions typically has specific high-order characteristics (such as being concentrated in the 0xE000 or 0x0700 to 0x07FF range). When traversing the second data, the upgrade tool performs multiple feature matching in parallel: it not only determines whether the bitwise AND operation result of the current instruction word and the first mask (e.g., 0xF000) conforms to the characteristics of data transfer instructions (e.g., 0x4000, corresponding to MOV / LDR), but also determines whether the operation result with the second mask (e.g., 0xF800) conforms to the characteristics of unconditional jumps (e.g., 0xE000), or whether the operation result with the third mask (e.g., 0xFF00) conforms to the characteristics of small-range jumps or stack operations (e.g., 0x0700). As long as the current instruction word matches any of the above target opcode characteristics, it is determined to be a valid instruction, and the valid instruction parameter is incremented by 1. By extending the recognition of control flow instructions, it can cover more than 90% of the valid instruction characteristics in the boot sector, thereby reducing the false negative rate.

[0167] In the above embodiments, by acquiring second data (such as the bootloader area) at the beginning of the firmware, calculating the proportion of legal instructions that conform to the target opcode characteristics in the second data, and comparing the proportion with a proportion threshold, it is possible to perform objective, fast, and highly accurate quantitative analysis of the encryption status of the firmware core code segment based on the statistical characteristics of the executable code. In particular, by extending the recognition of control flow instructions, the false negative rate for specific architectures (such as ARM) is reduced, thereby providing another reliable judgment basis besides feature string detection. This further achieves the technical effect of significantly improving the reliability of firmware core code segment encryption status detection and adaptability to specific processor architectures while ensuring real-time performance.

[0168] As an optional approach, detecting the relationship between the disorder level of the first updated data and a disorder level threshold includes:

[0169] S71, Obtain the third data in the third address range from the first updated data, wherein the third address range is an address range randomly selected from the address space of the first updated data that satisfies a third preset length;

[0170] S72, detect the information entropy value of the third data to obtain the disorder level, where the information entropy value is used to indicate the degree of randomness in the distribution of bytes included in the third data;

[0171] S73, compare the disorder level with the disorder level threshold;

[0172] S74, if the disorder level is greater than the disorder level threshold, determine that the disorder level is greater than the disorder level threshold;

[0173] S75, if the disorder level is less than or equal to the disorder level threshold, determine that the disorder level is less than or equal to the disorder level threshold.

[0174] Optionally, in this embodiment, the third address range typically refers to a randomly selected sampling segment within the data body region of the first updated data. Compared to a fixed-position guide region, the randomly selected third address range can avoid statistical biases caused by special file header formats (such as all-zero padding and fixed identifiers), thereby more accurately reflecting the encryption status of the first updated data.

[0175] Optionally, in this embodiment, the third preset length is a preset sample length sufficient to reflect the statistical distribution pattern of the data. To balance detection speed and statistical accuracy, while meeting the low resource consumption requirements of the embedded environment, the third preset length can be set to 1024 bytes (i.e., 1KB). If the third preset length is set too short, the statistical fluctuation of the samples will be large, making it difficult to reflect the overall disorder; if the third preset length is set too long, it will involve a large number of floating-point operations, which will significantly increase the CPU load.

[0176] Optionally, in this embodiment, the third data is a binary byte stream randomly read from the first updated data. The steps for obtaining the third data may include, but are not limited to: the upgrade tool using a random number generation function (such as the rand function) to calculate a valid random offset, which must ensure that subsequent reads do not exceed the bounds. For example, executing "chaos_offset = rand() % (first_update_data_length - 1024)", where first_update_data_length is the total length of the first updated data. Subsequently, the file system API is called to jump the read pointer to this random offset, such as executing "fseek(file_pointer, chaos_offset, SEEK_SET)", and then the third preset length of data is read and loaded into a memory buffer. The data in this buffer is the third data.

[0177] Optionally, in this embodiment, the step of detecting the information entropy value (i.e., disorder) of the third data may include, but is not limited to: initializing a frequency statistics array of size 256 (e.g., count

[256] ); traversing the third data (1KB) in the memory buffer, counting the occurrence count of each byte value from 0x00 to 0xFF, and filling it into the frequency statistics array; calculating the information entropy value according to the Shannon entropy formula, the calculation formula being: ,in, For the first The probability of the nth byte value appearing in the third data (i.e., the probability of the nth byte value appearing in the third data) The ratio of the number of occurrences of a single byte value to the total number of bytes. This is the final calculated value. The value is the information entropy value (i.e., disorder) of the third data.

[0178] Optionally, in this embodiment, the judgment logic for comparing the disorder level and the disorder level threshold is as follows: if the calculated disorder level is 7.8, and the preset disorder level threshold is 7.5, then it is determined that the disorder level is greater than the disorder level threshold. This indicates that the byte distribution of the third data is extremely uniform and disordered, which conforms to the characteristics of encrypted data. If the calculated disorder level is 4.5, and the disorder level threshold is 7.5, then it is determined that the disorder level is less than or equal to the disorder level threshold. This indicates that the third data has obvious statistical regularity or repetition pattern (such as repeated instruction sequences or padding characters), which conforms to the characteristics of unencrypted data.

[0179] In another embodiment, to optimize computational efficiency in an embedded environment, integer arithmetic and table lookup methods can be used instead of floating-point logarithmic arithmetic. For example, pre-constructing a table corresponding to frequencies from 0 to 100... The value mapping table is used, and the probability calculation is converted into an integer weighted sum. In addition, the correlation calculation of adjacent bytes can be introduced as an auxiliary verification: when the disorder is greater than 7.5 and the correlation of adjacent bytes is less than 0.15, the disorder is determined to be greater than or equal to the disorder threshold.

[0180] In the above embodiments, by randomly selecting third data that meets a third preset length (e.g., 1KB) in the updated data address space, and calculating its disorder degree based on the information entropy formula and comparing it with the disorder degree threshold, the randomness or disorder of the updated data content can be objectively and accurately quantified using the principles of data statistics. This greatly improves the accuracy of distinguishing between highly random ciphertext and low-random plaintext. Furthermore, random sampling avoids statistical bias caused by fixed file header format, further significantly improving the reliability, anti-interference ability, and statistical accuracy of the updated data encryption status detection.

[0181] As an alternative approach, after determining that the encryption state of the first attribute used to indicate that the first updated data has a pseudo-encryption state, the method further includes:

[0182] S81, it is determined that the second update data has not been obtained, and a first prompt message is sent to the initiator of the update request, wherein the first prompt message is used to indicate that the controller firmware of the server controller cannot be updated using the first update data indicated by the update request.

[0183] Optionally, in this embodiment, the initiator may refer to, but is not limited to, the entity that triggers the update request. This application does not limit the type of initiator, which may include the terminal of the operation and maintenance personnel that executes the update script, the task scheduling module of the cloud management platform, or the user who uploads the first update data through the Web interface.

[0184] Optionally, in this embodiment, the first prompt information may refer to, but is not limited to, the notification data fed back to the initiator when it is determined that the first update data is detected as fake encrypted data. The first prompt information may include, but is not limited to, an error code, an error description string, and suggested follow-up steps, used to prompt the initiator that the server controller firmware cannot be updated using the first update data.

[0185] Optionally, in this embodiment, when the first attribute is detected to indicate that the encryption state of the first update data is a pseudo-encryption state, the internal state machine of the upgrade tool will automatically transition to the abort state and no longer perform subsequent operations, thereby ensuring that no invalid second update data is generated and avoiding additional interference to the firmware update process.

[0186] Optionally, in this embodiment, the first prompt message can be sent through a combination of log recording and interface pop-up windows, but is not limited to this. For example, in a command-line interface scenario, the upgrade tool prints error messages in a specified format to the standard error output (stderr), such as "Error: Firmware Image Corrupted or FakeEncryption Detected"; in a graphical user interface scenario, a modal dialog box pops up, displaying intuitive error prompts, such as "Firmware file error: Fake encryption detected, please check file integrity or re-download".

[0187] In another embodiment, the first notification message can also be sent via, but is not limited to, API callbacks or status code responses to adapt to remote update scenarios. For example, when an update is triggered via a Representational State Transfer (REST) ​​application interface, the microservice hosting the upgrade tool will return an "HTTP 400 Bad Request" status code and carry structured information {"status":"failed", "reason":"pseudo-encrypted image"} in the JSON (JavaScript Object Notation) response body. This mechanism for sending the first notification message enables the cloud management platform to automatically capture update errors, mark the update task of the corresponding node as failed, and trigger an alarm process to notify the operations and maintenance administrator to intervene.

[0188] In the above embodiments, after determining that the encryption state of the first update data is a pseudo-encryption state, it is determined that the second update data has not been obtained, and a first prompt message indicating update failure is sent to the initiator of the update request. This enables the upgrade tool to immediately terminate the update process, avoiding the generation of invalid update data locally or the sending of invalid update data to the server. This effectively prevents the writing of damaged, pseudo-encrypted, or potentially maliciously tampered firmware data to the server controller, and promptly provides clear feedback on the error cause to the operation and maintenance personnel or management platform. This avoids the defects in related technologies, such as the lack of identification and processing mechanisms for pseudo-encryption states, which leads to invalid data transmission and waste of resources, or ultimately, failure to write and cause the server controller system to crash. It achieves rapid response, secure isolation, and efficient alarm for abnormal firmware file states.

[0189] As an optional approach, detecting a second attribute of the reference controller firmware used by the server controller includes:

[0190] S91 sends a firmware version query request to the server controller;

[0191] S92, receive firmware version information returned by the server controller in response to the firmware version query request;

[0192] S93, extract the reference firmware version of the reference controller firmware from the firmware version information;

[0193] S94 compares the reference firmware version with a preset version threshold.

[0194] S95, if the reference firmware version is less than a preset version threshold, determine the second attribute to indicate that the reference controller firmware does not support encrypted update method;

[0195] S96, if the reference firmware version is greater than or equal to a preset version threshold, determine the second attribute to indicate that the reference controller firmware supports encrypted update method.

[0196] Optionally, in this embodiment, the firmware version query request is used to request and obtain the firmware version information of the controller firmware currently running on the server controller. The firmware version query request may be, but is not limited to, the "Get Device ID" command defined by the IPMI protocol (command code: Network Function: 0x06, Command: 0x01), or it may be an HTTP (Hypertext Transfer Protocol) GET request based on the Redfish specification, such as a request URI (Uniform Resource Identifier) ​​of " / redfish / v1 / Managers / {ManagerId}".

[0197] Optionally, in this embodiment, the step of sending a firmware version query request to the server controller can be, but is not limited to, performed by the upgrade tool through an out-of-band management network or an in-band system interface. For example, the upgrade tool establishes an RMCP (Remote Management Control Protocol) session with the BMC via an Ethernet interface and sends the encapsulated "Get DeviceID" command to the BMC's IP address (e.g., 192.168.1.100). Alternatively, the upgrade tool running inside the operating system can directly write the firmware version query request to the BMC's registers via a keyboard controller-style interface or a block transfer interface.

[0198] Optionally, in this embodiment, the firmware version information may be, but is not limited to, a binary message or formatted string (such as "Firmware Revision: 3.02") that includes fields such as server controller ID (Identifier), firmware major version number, firmware minor version number and vendor ID.

[0199] Optionally, in this embodiment, the reference firmware version can be, but is not limited to, a value or string that can uniquely identify the firmware iteration stage of the reference controller, parsed from the firmware version information. The reference firmware version can be, but is not limited to, expressed in the form of "major version.minor version.revision number" (such as "3.2.0").

[0200] Optionally, in this embodiment, the step of extracting the reference firmware version may include, but is not limited to, the following: for the IPMI response message, the upgrade tool locates a specified byte segment (e.g., the 3rd byte is the major version and the 4th byte is the minor version). If the major version byte is 0x03 and the minor version byte is 0x10, then the segments are concatenated and parsed to obtain the reference firmware version "3.10". For the JSON string returned by Redfish (e.g., {"FirmwareVersion":"3.10.05"}), the upgrade tool directly extracts the "FirmwareVersion" field value as the reference firmware version using a JSON parser.

[0201] Optionally, in this embodiment, the preset version threshold may be, but is not limited to, the firmware version number when the controller firmware first integrates the key management module and decryption algorithm library for decrypting ciphertext update data. For example, if the manufacturer first integrates the key management module and decryption algorithm library for decrypting ciphertext update data in BMC firmware version V3.0, then the preset version threshold is set to 3.00.

[0202] Optionally, in this embodiment, the comparison between the reference firmware version and the preset version threshold can be implemented using a version number segment comparison algorithm, but is not limited to. Assuming the extracted reference firmware version is "2.50" and the preset version threshold is "3.00", the upgrade tool will segment and compare the extracted reference firmware version "2.50" with the preset version threshold "3.00". First, the major version number is compared: 2 < 3, the comparison ends, and it is determined that the reference firmware version is less than the threshold. At this time, the upgrade tool determines that the second attribute is used to indicate that the reference controller firmware does not support encrypted update methods, and sets the internal status flag "support_encryption = false", indicating that the server controller does not support directly receiving encrypted update data, and the upgrade tool needs to generate second update data that matches the server controller.

[0203] In another embodiment, assume the extracted reference firmware version is "3.05". First, compare the major version number: 3 = 3; then compare the minor version number: 05 > 00. It is determined that the reference firmware version is greater than a preset version threshold. At this point, the second attribute is used to indicate that the reference controller firmware supports encrypted update methods, and the internal status flag "support_encryption=true" is set, indicating that the server controller supports directly receiving encrypted update data.

[0204] In the above embodiments, by sending a firmware version query request to the server controller and extracting the reference firmware version, and comparing the version with a preset version threshold to determine whether the reference controller firmware supports encrypted updates, the upgrade tool can quickly determine the encryption and decryption capabilities of the server controller simply by comparing the version number, a standard and easily accessible metadata, without performing complex communication negotiations or function probes. This reduces the complexity of the second attribute detection and clearly defines the boundary line for supporting encrypted updates using the version threshold, further improving the efficiency of judging the server controller's support for encrypted updates.

[0205] As an optional approach, a first attribute of the first update data of the target controller firmware indicated by the update request is detected, and a second attribute of the reference controller firmware used by the server controller is detected, including:

[0206] S101, Obtain the target controller identifier of the server controller;

[0207] S102, Detect whether the target controller identifier exists in the controller identifier set, wherein the controller identifier set records the controller identifiers of legitimate server controllers that are allowed to update the controller firmware;

[0208] S103, if a target controller identifier exists in the controller identifier set, detect the first attribute of the first update data of the target controller firmware indicated by the update request, and detect the second attribute of the reference controller firmware used by the server controller.

[0209] S104, if the target controller identifier does not exist in the controller identifier set, it is determined that the server controller's validity check has failed, and a third prompt message is sent to the initiator of the update request. The third prompt message is used to indicate that the server controller where the controller firmware requested to be updated by the update request is located has failed the validity check.

[0210] Optionally, in this embodiment, the target controller identifier may refer to, but is not limited to, a hardware signature that uniquely identifies the server controller to be updated. The target controller identifier may take the form of, but is not limited to, a serial number (SN) pre-programmed at the hardware factory, a globally unique identifier (UUID), a media access control (MAC) address, or an asset management tag. The target controller identifier is used to locate the server controller indicated by this update request within the device.

[0211] Optionally, in this embodiment, the step of obtaining the target controller identifier may include, but is not limited to, the following: the upgrade tool sends an identity query command to the server controller. The identity query command may be the "Get SystemGUID" command (to obtain the UUID), the "Get LAN Configuration Parameters" command (to obtain the MAC address), or the "Read FRU Data" command (to obtain the board serial number) in the IPMI protocol. The server controller is used to respond to the identity query command upon receiving it and return its own stored hardware signature. After receiving the hardware signature, the upgrade tool parses the hardware signature to obtain the target controller identifier.

[0212] Optionally, in this embodiment, the controller identifier set may refer to, but is not limited to, a pre-stored whitelist of authorized legitimate server controllers, which records all server controller identifiers allowed to perform firmware update operations. Its storage format and acquisition method are not limited. The controller identifier set may be, but is not limited to, a locally encrypted license file of the upgrade tool, a hard-coded hash table within the executable file, or a JSON array dynamically obtained from the vendor's verification server via an SSL connection.

[0213] Optionally, in this embodiment, the matching detection between the target controller identifier and the controller identifier set can be achieved through a lookup table method or a hash matching method. For example, the upgrade tool loads the local encrypted database file "device_whitelist.db", decrypts it using a specified key, and constructs a hash set in memory; then, it uses the target controller identifier as a key to search in the hash set. If the search returns "True", it is determined that the target controller identifier exists in the controller identifier set; if the search returns "False", it is determined that the target controller identifier does not exist in the controller identifier set.

[0214] Optionally, in this embodiment, legitimacy verification may refer to, but is not limited to, a security audit process used to verify whether the server controller currently to be updated falls within the licensed scope or is compatible with the upgrade tool. The verification dimensions of legitimacy verification may include, but are not limited to, one or more of controller identifier matching verification, vendor signature verification, and authorization period verification.

[0215] Optionally, in this embodiment, the third prompt information may, but is not limited to, notification data sent to the initiator when the validity check fails. The third prompt information may, but is not limited to, a data structure including an error code (such as "Error: 0x05") and an error description string (such as "Device Not Authorized"), or a signal that triggers a red warning box to pop up in the user interface (UI). The third prompt information is used to notify the initiator that the server controller containing the controller firmware requested for the update request has failed the validity check.

[0216] Optionally, in this embodiment, if the target controller identifier is detected in the controller identifier set, the server controller's legitimacy verification is deemed successful, and subsequent checks on the first and second attributes are initiated. This pre-verification mechanism effectively avoids the risk of sending update data to unauthorized or incorrect model devices, preventing device damage due to hardware incompatibility.

[0217] Optionally, in this embodiment, if the target controller identifier is not found in the controller identifier set, and the server controller's validity verification fails, the current update task thread is immediately terminated, and a log record containing a timestamp, the target controller identifier, and the reason for failure ("Illegal Target ID") is generated. Simultaneously, the upgrade tool sends a message to the initiator, displaying a pop-up window on the interface stating "Error: Illegal device; this upgrade tool is not authorized to perform firmware updates on the current device," and suggesting that the operator contact the manufacturer for authorization.

[0218] In another embodiment, in a batch automated operation and maintenance scenario, the upgrade tool will not interrupt the overall process, but will mark the update status of the server controller as "Skipped_Unauthorized" and continue to process the remaining devices in the list; after all server controllers have been processed, a unified update report containing all failed nodes will be generated and sent to the operation and maintenance administrator.

[0219] In the above embodiments, by obtaining the target controller identifier of the server controller before detecting the first and second attributes, and checking whether the identifier is in the set of valid controller identifiers, and sending a third prompt message if it is invalid, the server controller is pre-verified for legality or authorization whitelist before the subsequent time-consuming detection and data processing processes are executed. This effectively prevents the risk of sending update data to unauthorized devices, incorrect model devices, or illegal targets, avoids device damage or security violations caused by compatibility issues or unauthorized operations, and saves resources for firmware adaptation processing of illegal devices, further enhancing the security of the firmware update process.

[0220] As an optional approach, generating second update data matching the server controller using the first update data based on the first and second attributes includes:

[0221] S111, adjust the first attribute of the first updated data to a third attribute that matches the second attribute based on the first attribute and the second attribute to obtain the second updated data;

[0222] Alternatively, in step S112, third update data is generated based on the first attribute and the second attribute, wherein the third update data is used to control the server controller to update the second attribute of the reference controller firmware to a fourth attribute that matches the first attribute to obtain a candidate controller firmware, and the candidate controller firmware is used to use the first update data; the third update data and the first update data are determined as the second update data.

[0223] Optionally, in this embodiment, the third attribute may be, but is not limited to, used to indicate the new encryption state of the first updated data after adjustment. This new encryption state is an encryption state that matches the second attribute of the server controller's current reference controller firmware. For example, if the second attribute of the reference controller firmware indicates that the reference controller firmware does not support encrypted update methods, the third attribute is used to indicate that the first updated data has an unencrypted encryption state.

[0224] Optionally, in this embodiment, the third update data may refer to, but is not limited to, transitional update data used to update the reference controller firmware currently running on the server controller to the candidate controller firmware. The third update data is typically an intermediate version firmware in an unencrypted state, and this intermediate version firmware integrates a key management module or decryption algorithm library for decrypting the first update data.

[0225] Optionally, in this embodiment, the candidate controller firmware may refer to, but is not limited to, the controller firmware that runs after the server controller completes the update operation using the third update data. As the execution environment for processing the first update data, the candidate controller firmware can ultimately update the server controller firmware to the target controller firmware using the first update data.

[0226] Optionally, in this embodiment, the fourth attribute may, but is not limited to, indicating the support of the candidate controller firmware for encrypted update methods after the server controller updates the reference controller firmware using the third update data. After the third update data is applied to the server controller, the reference controller firmware is updated to the candidate controller firmware, which has the ability to process encrypted update data. Therefore, the fourth attribute is used to indicate that the candidate controller firmware supports encrypted update methods.

[0227] In the embodiment provided in step S111, the step of adjusting the first attribute of the first update data to a third attribute that matches the second attribute to obtain the second update data may include, but is not limited to, the following: when it is detected that the first attribute indicates that the encryption state of the first update data is encrypted, and it is detected that the second attribute indicates that the reference controller firmware does not support the encrypted update method, it is determined that the first update data does not match the server controller, and the first update data in the encrypted state is decrypted using the decryption key and decryption algorithm preset locally by the upgrade tool to obtain the second update data. After the decryption operation, the encryption state of the first update data changes from the first attribute (encrypted state) to the third attribute (unencrypted state). Since the reference controller firmware can recognize and load plaintext update data, the adjusted first update data (i.e., the second update data) matches the second attribute of the reference controller firmware.

[0228] The above embodiments enable server controllers that do not support encrypted update methods to complete firmware updates by receiving second update data in plaintext.

[0229] In the embodiment provided in step S112, the step of generating third update data based on the first attribute and the second attribute, and determining the third update data and the first update data as the second update data, may include, but is not limited to: when it is detected that the first attribute indicates that the encryption state of the first update data is encrypted, and it is detected that the second attribute indicates that the reference controller firmware does not support the encryption update method, in order to avoid decrypting the first update data into plaintext transmission, the third update data (i.e., transitional update data) is first retrieved and generated in the local firmware library based on the version information of the target controller firmware. Subsequently, the third update data is combined with the first update data in the encrypted state to obtain the second update data. The third update data in the second update data is used to update the server controller's firmware to the candidate controller firmware, that is, to update the second attribute (not supporting the encryption update method) of the reference controller firmware currently used by the server controller to the fourth attribute (supporting the encryption update method) to obtain the candidate controller firmware. Since the candidate controller firmware has the ability to process encrypted data, it can directly use the first update data in the encrypted state to complete the final firmware update. The candidate controller firmware is used to use the first update data, and the first update data matching the server controller is used to update the server controller's firmware to the target controller firmware.

[0230] Sending the second update data to the server controller may include, but is not limited to, the following: The server controller first performs a pre-update using the third update data in the second update data, updating the second attribute (which does not support encrypted update) of the reference controller firmware to the fourth attribute (which supports encrypted update), thereby running the candidate controller firmware. Subsequently, the server controller running the candidate controller firmware receives the first update data in the second update data. Because the candidate controller firmware has the ability to process encrypted update data, it can directly use the first update data in an encrypted state for firmware update.

[0231] The above embodiments ensure that the first update data remains encrypted throughout the transmission process, achieving a highly secure firmware update.

[0232] In the above embodiments, by providing two optional schemes for generating the second update data—directly adjusting the encryption state of the first update data, or generating transitional update data and combining the transitional data with the first update data as the second update data—the upgrade scheme has a flexible adaptation strategy. Different paths can be selected according to security requirements (such as choosing transitional updates) or compatibility requirements (such as choosing direct decryption). This ensures that controller firmware that does not support encrypted update methods can also be updated, while providing an update method that maintains encrypted transmission throughout the process, further realizing the flexibility and security optimization of the firmware update method.

[0233] As an optional approach, the first attribute of the first updated data is adjusted to a third attribute that matches the second attribute based on the first attribute and the second attribute to obtain the second updated data, including:

[0234] S121, when the second attribute is used to indicate that the reference controller firmware does not support the encrypted update method, and the first attribute is used to indicate that the encryption state of the first update data is an encrypted state, the reference encryption key corresponding to the first update data is obtained.

[0235] S122, use the reference encryption key to decrypt the first update data to obtain the fourth update data;

[0236] S123, Detect the third attribute of the fourth updated data, wherein the third attribute is used to indicate the encryption state of the fourth updated data;

[0237] S124, where the third attribute indicates that the encryption state of the fourth update data is unencrypted, the fourth update data is determined to be the second update data;

[0238] S125, if the third attribute indicates that the encryption state of the fourth update data is a pseudo-encryption state, it is determined that the second update data has not been obtained, and a second prompt message is sent to the initiator of the update request, wherein the second prompt message is used to indicate that the update of the server controller firmware using the first update data indicated by the update request has failed.

[0239] In the embodiment provided in step S121, the upgrade tool first confirms the prerequisite for triggering the decryption process: that is, the reference controller firmware does not support the encrypted update method, and the first update data has an encrypted state.

[0240] Optionally, in this embodiment, the reference encryption key may be, but is not limited to, a symmetric key or an asymmetric private key used to decrypt the first updated data. For example, the reference encryption key may be a 256-bit AES key string.

[0241] Optionally, in this embodiment, the step of obtaining the reference encryption key corresponding to the first updated data may include, but is not limited to, reading the obfuscated key ciphertext (such as a string encoded in hexadecimal multiple times) stored locally. Then, a preset key decryption function is called to perform multiple rounds of iterative decoding operations on the key ciphertext, ultimately restoring the original plaintext reference encryption key, effectively preventing the key from being leaked during static analysis.

[0242] Optionally, in this embodiment, the fourth update data may refer to, but is not limited to, a temporary data object or a memory data block generated after performing a decryption operation on the first update data.

[0243] Optionally, in this embodiment, the step of decrypting the first update data using the reference encryption key to obtain the fourth update data may include, but is not limited to, the following:

[0244] First, construct the decryption command. To enhance the key's resistance to attack, a password-based key derivation function (PBKDF2) and a salting mechanism can be used when constructing the decryption command. For example, the constructed decryption command includes the "-salt" parameter to introduce a random salt value to prevent rainbow table attacks; it also includes the "-pbkdf2" parameter to derive the actual decryption key from the reference encryption key through multiple iterative hash calculations. The specific command format can be "openssl enc -d -aes-256-cbc -pbkdf2 -salt -inencrypted.img -out decrypted_tmp.img -pass pass:recovered_key", where "-d" represents decryption, "-aes-256-cbc" represents the specified algorithm, and "-pass" passes the recovered plaintext reference encryption key.

[0245] Subsequently, the decryption command is executed. To prevent command injection attacks, the upgrade tool can, but is not limited to, run the command through a secure execution interface. Before invoking the system shell, the secure execution interface performs a validity check on the constructed command string, filtering out illegal characters (such as the pipe symbol "|", redirection symbol ">", or semicolon ";") to ensure that only the expected decryption operation is performed, thus obtaining the fourth updated data output.

[0246] In addition, during the process of decrypting the first updated data using the reference encryption key, the first updated data can also be renamed (e.g., by adding the "_tmp" suffix) to protect the source file from being corrupted.

[0247] In the embodiment provided in step S123, to prevent the generation of erroneous update data due to key errors, algorithm mismatches, or file corruption, the encryption status of the fourth update data can be checked again. The step of detecting the third attribute of the fourth update data can, but is not limited to, reusing the method used to detect the first attribute in the aforementioned embodiments. For example, the upgrade tool can detect whether a characteristic string (such as "UFW_VERSION") exists in the fourth update data, or detect the proportion of legitimate instructions and the proportion of disorder in the fourth update data; specific detection methods will not be elaborated here.

[0248] Optionally, in this embodiment, when it is detected that the third attribute indicates that the fourth update data has become unencrypted, the decryption operation is determined to be successful, and the verified fourth update data is determined as the final second update data to be sent, ensuring that the data sent to the server controller is legitimate and identifiable update data.

[0249] Optionally, in this embodiment, if it is detected that the third attribute indicates that the fourth update data is still in a pseudo-encrypted state, it is determined that valid second update data has not been generated, and the update process is immediately terminated to prevent corrupted update data from being written to the device. Simultaneously, a second prompt message is generated and sent to the initiator of the update request.

[0250] Optionally, in this embodiment, the second prompt information may be, but is not limited to, notification data fed back to the initiator when it is determined that the third attribute indicates that the fourth update data is still in a pseudo-encrypted state. The second prompt information may include, but is not limited to, an error code, an error description string (such as "Error: Decryption Failed" or "FirmwareCorrupted"), and suggested follow-up steps, to prompt the initiator that updating the server controller firmware using the first update data indicated by the update request has failed.

[0251] Optionally, before detecting the first attribute of the first update data, the update method further includes: identifying the target firmware type indicated by the update request. The upgrade tool detects whether the update request carries an identifier indicating the firmware type (e.g., the bios_update flag), or determines whether it is Basic Input / Output System (BIOS) firmware by parsing the header characteristics of the first update data. If the target firmware type is identified as BIOS firmware, or if the update request carries an exemption flag indicating that decryption processing is not required, the upgrade tool skips the subsequent detection and decryption process for the first attribute and directly executes the standard pass-through update logic. This differentiation mechanism can prevent data corruption caused by the upgrade tool mistakenly including non-BMC firmware (such as BIOS firmware) in the decryption process, ensuring the compatibility of the same tool for multiple types of firmware update tasks.

[0252] Optionally, Figure 5 This is a flowchart illustrating the processing of an update request according to an embodiment of this application. Figure 5 As shown, when the upgrade tool receives the uploaded image file (i.e., the first update data) through the firmware update function (FirmwareUpdate function), it first determines whether there is a specific skip condition (such as the bios_update flag, which indicates that the decryption process described in this embodiment does not need to be executed); if there is no skip condition, the decryption process is entered. Subsequently, the system determines whether the decryption process returns successfully; if the decryption is successful, the server controller firmware update process is triggered, that is, the fourth update data obtained after decryption is sent to the server controller as the second update data; if the decryption fails, the error reporting process is executed, and a second prompt message indicating that the update failed is sent to the initiator.

[0253] Optionally, Figure 6 This is a flowchart of the firmware decryption processing function according to an embodiment of this application. Figure 6 As shown, when a decryption operation needs to be performed on the first updated data, the processing flow is as follows:

[0254] First, to prevent file read / write conflicts or original file corruption during decryption, the upgrade tool renames the first updated data to a temporary filename. If renaming fails (e.g., insufficient file permissions or file being occupied), it returns error code "-1" and terminates the process. If renaming succeeds, it calls the preset key decryption function to restore the locally stored obfuscated key and obtain the reference encryption key for the plaintext.

[0255] The system then checks whether key restoration was successful. If restoration fails (e.g., due to a corrupted key file or incorrect iteration count), decryption fails and an error code is returned. After successfully obtaining the reference encryption key, a decryption command (e.g., a decryption command line based on the OpenSSL standard) is constructed, taking the renamed first update data as input and the restored reference encryption key as a parameter, and then executing the decryption command. The execution status of the decryption command is monitored; if the decryption command returns an error signal, decryption fails. If the decryption command executes successfully, the system enters a waiting state until the fourth update data after decryption is generated.

[0256] Subsequently, the generated fourth update data is verified (e.g., checking the integrity of the file header or the size of the decrypted data). If the verification passes, the decryption is considered successful (returning 0), and the fourth update data is identified as the second update data; if the verification fails (e.g., the decrypted data is still unrecognizable), the decryption is considered incomplete or failed (returning -1).

[0257] Optionally, to prevent the decrypted fourth update data (i.e., plaintext update data) from being illegally obtained or leaked through side channels during its memory residency, the upgrade tool can also perform memory-level security isolation operations when generating the fourth update data. This operation may include, but is not limited to: performing memory locking. The upgrade tool calls system kernel interfaces (such as the `mlock` or `mlockall` functions in Linux) to lock the memory buffer storing the fourth update data in physical memory, preventing the operating system from swapping it to a disk virtual memory partition, thus avoiding plaintext firmware data being written to the hard drive and leaving residue, thereby preventing data leakage. Alternatively, configuring a process dump policy. The upgrade tool calls process control interfaces (such as the `prctl` function) to set the current process to a non-dumpable state (`PR_SET_DUMPABLE=0`) to prevent the generation of a kernel dump file containing plaintext data when the process crashes abnormally or receives a specific signal. Alternatively, enabling anti-debugging tracing protection. Configure the tracking permissions of the upgrade tool process (such as setting the PR_SET_PTRACER parameter) to prevent other non-privileged processes or debuggers (such as gdb, strace) from mounting or reading memory from the current upgrade process, ensuring the privacy of the decryption process and data in memory.

[0258] Optionally, before obtaining the reference encryption key corresponding to the first update data or performing decryption, the upgrade tool can also perform process legitimacy and environment integrity checks. The permission check steps include: detecting the user identifier (UID) of the currently running upgrade tool process and determining whether it matches the identifier of the preset dedicated upgrade account; if they do not match, insufficient permissions are determined, and the decryption process is refused. The integrity check steps include: calculating the hash value of the current upgrade tool executable file itself (such as MD5 (Message-Digest Algorithm 5) or SHA-256 digest) and comparing it with a preset valid hash value. Subsequent key extraction and firmware decryption operations are only allowed if the hash value matches (indicating the tool has not been tampered with) and the permission check passes.

[0259] In the above embodiments, after decryption (adjusting the first attribute to the third attribute), a step is added to detect the third attribute (encryption state) of the fourth updated data (decrypted data), and a second prompt message is sent when a false encryption state is detected. This enables a secondary security verification of the decryption operation result, ensuring that the decrypted data is complete and valid plaintext updated data. This effectively prevents decryption failure or the generation of garbled data due to incorrect decryption keys, algorithm mismatch, or damage to the original ciphertext data itself, and timely detection of anomalies, avoiding the writing of damaged firmware to the device. This further enhances the robustness and high security of the firmware decryption process.

[0260] As an optional approach, obtaining the reference encryption key corresponding to the first updated data includes:

[0261] S131, Detect the reference data version of the first updated data;

[0262] S132, extract the reference encryption key corresponding to the reference data version from the target storage location, wherein the target storage location stores the data version and encryption key with a corresponding relationship.

[0263] In the embodiment provided in step S131, the step of detecting the reference data version of the first update data is intended to determine the firmware version of the target controller firmware corresponding to the first update data to be decrypted, so as to prevent decryption errors when ciphertext update data corresponding to different firmware versions use different keys.

[0264] Optionally, in this embodiment, the reference data version may refer to, but is not limited to, the firmware version number of the first update data (such as "V3.0") or a security generation identifier. The reference data version may be, but is not limited to, used to distinguish different encryption key strategies used by firmware released at different time periods. For example, the reference data version may be the major version number of the firmware (such as "V3.x"), or it may be a specific key index number (such as "KID_2025").

[0265] Optionally, in this embodiment, since the main content of the first update data may be in an encrypted state (resulting in the internal version information not being visible), the method of detecting the reference data version may include, but is not limited to: parsing the filename of the first update data, for example, extracting "V3.0" from "BMC_V3.0_Encrypted.ima", or reading the plaintext description file issued along with the first update data and obtaining the reference data version from the plaintext description file.

[0266] In the embodiment provided in step S132, the upgrade tool searches for the corresponding decryption credential in a local or remote secure storage area based on the obtained reference data version.

[0267] Optionally, in this embodiment, the target storage location may be, but is not limited to, an encrypted database or security configuration file inside the upgrade tool, or an obfuscated code segment.

[0268] Optionally, in this embodiment, the target storage location may, but is not limited to, maintain a mapping table, which records data versions and encryption keys with corresponding relationships.

[0269] Optionally, in this embodiment, the step of extracting the reference encryption key corresponding to the reference data version from the target storage location may include, but is not limited to, using the reference data version as an index key to search in the mapping table of the target storage location. If the search is successful, the corresponding reference encryption key is extracted; if the search fails, a message is displayed indicating that decryption of this reference data version is not supported.

[0270] Optionally, in this embodiment, to prevent key leakage, the process of extracting the reference encryption key from the target storage location typically involves "deobfuscation" or "decryption" operations. For example, the target storage location may not store the plaintext key, but rather ciphertext obfuscated by a specific algorithm. When extracting, the upgrade tool needs to call its internal key decryption function to restore the retrieved ciphertext to a plaintext reference encryption key that can be used to decrypt the first updated data. This mechanism ensures that even if the target storage location is illegally accessed, attackers cannot directly obtain a valid decryption key.

[0271] Optionally, to further enhance the security of key storage, embodiments of this application propose a key decryption function. Figure 7 This is a flowchart of a key decryption function according to an embodiment of this application. For example... Figure 7 As shown, the key decryption function (e.g., named decode_password) is used to restore the ciphertext (i.e., plaintext) read from the storage location back to the plaintext key (i.e., plaintext). The restoration process includes the following steps:

[0272] First, the key decryption function performs initialization operations, clearing the plaintext buffer to avoid interference from dirty data, and creating a temporary buffer (tmp). The input ciphertext is copied into the temporary buffer as the initial data to be processed. At the same time, the iteration counter (i) is initialized to 0.

[0273] Then, the iterative decryption loop begins, checking if the current iteration count is less than the preset total number of iterations (let's say "iterations"). If the loop condition is met, a single iteration begins: first, the length of the data in the current temporary buffer is calculated, and then it is checked whether this length is even (because in hexadecimal encoding, every two characters correspond to one byte, so the length must be even). If the length is odd, a format error is determined, and a failure signal (returning 0) is returned.

[0274] If the length check passes, the string conversion counter (j) is initialized, and the data in the temporary buffer is iterated. During the iteration, two characters are extracted each time to form a hexadecimal string (hex), which is then converted to the corresponding unsigned integer value (c) using the sscanf function, and this value is stored as a character in the output buffer (decoded) of the current iteration. In this way, a hexadecimal string of length N is restored to a character sequence of length N / 2.

[0275] After each iteration, the contents of the output buffer generated this time are copied back to the temporary buffer (tmp) as the input data for the next iteration, and the iteration counter is incremented by 1. This process enables multiple reverse reconstructions of the key.

[0276] The loop ends when the iteration counter reaches the preset number of iterations. At this point, the data stored in the temporary buffer is the final restored plaintext key. The function copies it to the output parameter (plaintext) and returns a success signal (returns 1). This multi-round iterative encoding and conversion mechanism greatly increases the difficulty for attackers to reverse engineer the key through static analysis.

[0277] In the above embodiments, by detecting the reference data version of the first updated data and extracting the corresponding reference encryption key from the target storage location that stores the correspondence between the data version and the encryption key, the key management strategy can be precisely bound to the firmware version or security generation. This ensures that the correct key matching the encryption of the firmware file is used during decryption, thus solving the problem of key mixing and decryption failure when different firmware versions use different key strategies. Furthermore, the extraction method based on version index simplifies the key search process and avoids the defects in related technologies where the use of static or globally unified keys leads to all firmware versions being affected if the key is leaked, or decryption failure due to version key mismatch.

[0278] As an optional approach, third updated data is generated based on the first and second attributes, including:

[0279] S141, when the second attribute is used to indicate that the reference controller firmware does not support the encrypted update method, and the first attribute is used to indicate that the encryption state of the first update data is encrypted, the fifth update data that conforms to the reference firmware version of the reference controller firmware is obtained.

[0280] S142, add the sixth update data to the fifth update data to obtain the third update data, wherein the sixth update data is used to implement the function of decrypting the first update data.

[0281] Optionally, in this embodiment, the fifth update data may, but is not limited to, the base firmware code or image template used to construct the transition update data. The fifth update data is typically unencrypted (or uses an encoding format recognizable by the reference controller firmware), therefore it can be directly verified and passed by a server controller running reference controller firmware that does not support encrypted update methods. The fifth update data may, but is not limited to, include the basic operating environment of the firmware, drivers, and operating system kernel, but does not include (or has not yet been activated) a key management module and decryption algorithm library for decrypting encrypted update data.

[0282] Optionally, in this embodiment, the sixth update data may, but is not limited to, refer to an incremental function component or security configuration package used to endow the firmware with decryption capabilities. The sixth update data encapsulates a decryption algorithm library (such as AES-256 decryption algorithm implementation code) for parsing the first update data and a corresponding decryption credential (such as a decryption key or private key).

[0283] Optionally, in this embodiment, the third update data (i.e., the aforementioned transitional update data) is update data obtained by combining the fifth update data and the sixth update data. The third update data retains the compatibility characteristics of the fifth update data (i.e., it can be loaded by server controllers that do not support encrypted update methods), and also possesses the functional characteristics of the sixth update data (i.e., after installation, it can give the server controller the ability to decrypt encrypted update data).

[0284] In the embodiment provided in step S141, the upgrade tool first confirms the scenario where transitional update data needs to be generated, namely, the reference controller firmware does not support encrypted update methods, and the first update data has an encrypted state. Subsequently, the upgrade tool retrieves the fifth update data from the local firmware library or cloud repository based on the version information of the reference controller firmware (reference firmware version).

[0285] Optionally, in this embodiment, the fifth update data conforming to the reference firmware version is update data that meets the compatibility verification conditions. The compatibility verification conditions include: the encryption state of the fifth update data matches the second attribute of the reference controller firmware (i.e., it is unencrypted), and the version identifier of the fifth update data is equal to or higher than the reference firmware version. For example, if the reference firmware is V1.0 (which does not support encryption), the upgrade tool obtains an unencrypted V2.0 base image as the fifth update data. This V2.0 base image itself does not have decryption capabilities, but it can be recognized and flashed by the V1.0 firmware.

[0286] Optionally, in this embodiment, the step of adding the sixth update data to the fifth update data can be implemented, but is not limited to, through static linking compilation. For example, during the build phase of generating transition firmware, the sixth update data is linked with the fifth update data to generate a single image file containing decryption functionality as the third update data, wherein the sixth update data can be a code object of a decryption algorithm library.

[0287] Optionally, in this embodiment, it can also be implemented through configuration file injection, but is not limited to. For example, the fifth update data is a general intermediate version image. The upgrade tool writes the specific decryption key (part of the sixth update data) corresponding to the first update data into a specific configuration partition of the image, thereby activating its ability to decrypt the first update data.

[0288] Optionally, in this embodiment, the third update data can also be obtained through firmware packaging and reassembly, but is not limited to. For example, the upgrade tool injects the sixth update data (i.e., the compiled decryption module binary file, such as decryptor.bin) into a specific reserved area of ​​the fifth update data or an extended partition of the file system. Then, the upgrade tool modifies the startup script of the fifth update data (such as rc.local or init.d script) to add instructions to load and initialize decryptor.bin when the system starts. The final modified image file is the third update data.

[0289] Optionally, in this embodiment, after the server controller flashes the third update data and restarts, the server controller appears to be running an intermediate version based on the fifth update data (such as V1.5 or V2.0), but in reality, it has already loaded the decryption function provided by the sixth update data. This enables the server controller to complete the capability leap from "not supporting encrypted update methods" to "supporting encrypted update methods" (i.e., updating to the aforementioned candidate controller firmware), thereby possessing the ability to receive and decrypt subsequent V3.0 encrypted update data (first update data), and successfully completing the final update.

[0290] In the above embodiments, by obtaining the fifth update data that conforms to the reference controller firmware version when a transitional update is needed, and adding the sixth update data to it to obtain the third update data, a transitional image that can be recognized and accepted by the current controller firmware that does not support encryption, and which integrates firmware decryption capabilities, is constructed. This achieves a two-stage progressive update of the server controller capabilities, ensuring that the first update data remains encrypted during transmission. This avoids the defects in related technologies where the ciphertext must be completely decrypted into plaintext locally in order to adapt to older firmware versions that do not support encryption, thus exposing the plaintext firmware to security risks on the upgrade tool or transmission link.

[0291] As an optional approach, a sixth update is added to the fifth update, including:

[0292] S151, add seventh and eighth update data to the fifth update data, wherein the sixth update data includes the seventh and eighth update data. The seventh update data is used to implement the function of detecting the first attribute, and the eighth update data is used to implement the function of decrypting the first update data when the first attribute indicates that the encryption state of the first update data is encrypted.

[0293] Optionally, in this embodiment, the seventh update data may refer to, but is not limited to, a detection function module or detection algorithm code used to detect the encryption state of the update data. The seventh update data is configured to run first when the server controller receives new update data to detect the first attribute of the update data.

[0294] Optionally, in this embodiment, the eighth update data may refer to, but is not limited to, a decryption function module or decryption execution environment used to perform data restoration operations. The eighth update data encapsulates key management logic and a decryption algorithm library (such as AES-256-CBC (Advanced Encryption Standard with 256-bit Key in Cipher BlockChaining Mode)) to restore the ciphertext update data into plaintext update data that the reference controller firmware can recognize.

[0295] Optionally, in this embodiment, the steps of adding the seventh and eighth update data to the fifth update data can be implemented, but are not limited to, through firmware unpacking and modular injection. For example, the upgrade tool pre-obtains two pre-compiled binary functional modules: a detection module (corresponding to the seventh update data, such as a kernel module or executable file named "detector.ko") and a decryption engine module (corresponding to the eighth update data, such as a dynamic link library named "crypto_engine.so"). The injection process includes: First, the upgrade tool uses a firmware editing tool (such as "binwalk" or a vendor-specific firmware packager) to unpack the fifth update data and extract the file system image. Second, the detection module and decryption engine module are copied to a specific system directory of the file system (such as " / usr / local / bin / " or " / lib / modules / "). Third, the execution script of the firmware update management program or upgrade service daemon is modified. The modified logic configuration is: when new update data is received, the detection module (seventh update data) is first called to detect the first attribute of the update data. If the detection module returns a signal indicating an "encrypted state" (such as the return code "Encrypted"), the decryption engine module (eighth update data) is called to decrypt the update data, and the decrypted data stream is written to non-volatile memory. If the detection module returns a signal indicating an "unencrypted state" (such as the return code "Plaintext"), the decryption step is skipped, and the update data is directly written to non-volatile memory. Finally, the upgrade tool repackages and signs the modified update data to generate the final third update data.

[0296] In another embodiment, the seventh and eighth update data may also be, but are not limited to, compiled into a single executable file. This single executable file is configured to replace the simple copy command in the original firmware system as the default tool for performing firmware write operations, thereby transparently achieving automatic identification and decryption of encrypted data at the underlying input / output (I / O) level.

[0297] Optionally, in this embodiment, after the server controller runs the candidate controller firmware containing the seventh and eighth update data, its processing logic for the first update data is as follows: First, the seventh update data is called to detect the first attribute of the first update data. If the detection result of the seventh update data indicates that the first attribute is encrypted, the server controller calls the eighth update data to decrypt the first update data and generate plaintext update data; if the detection result of the seventh update data indicates that the first attribute is unencrypted (i.e., plaintext), the server controller skips the decryption operation of the eighth update data and directly loads the unencrypted update data.

[0298] In the above embodiments, by further defining the sixth update data as including the seventh update data (detection function) and the eighth update data (decryption function), and by adding both to the fifth update data to obtain the third update data, the server controller, after being updated to the candidate firmware, not only gains the ability to decrypt ciphertext (eighth update data), but also the ability to detect the encryption status of subsequent update data (seventh update data). This avoids the candidate firmware from performing unnecessary or erroneous forced decryption operations on plaintext data when receiving the next stage of update data, ensuring the robustness of the update process.

[0299] As an optional approach, sending the second update data to the server controller includes:

[0300] S161, the third update data is sent to the server controller, wherein the third update data is used to update the server controller firmware to the candidate controller firmware.

[0301] S162, when the server controller updates the reference controller firmware to the candidate controller firmware, the first update data is sent to the server controller, wherein the first update data is used to update the server controller firmware to the target controller firmware.

[0302] Optionally, in this embodiment, when the second update data is a combination of the first update data and the third update data, a phased timing transmission mode can be used to send the second update data to the server controller. This method includes: sending the third update data included in the second update data to the server controller, and sending a command to trigger the server controller to perform an update and restart operation for the third update data. The third update data can update the server controller's firmware to the candidate controller firmware. After the upgrade tool completes the transmission, it enters a polling waiting state, continuously checking the server controller's online status or version information to confirm whether it has completed a restart and successfully runs on the candidate controller firmware (i.e., intermediate version firmware). After confirming that the server controller has decryption capabilities (i.e., detecting a version number change or capability bit update), the upgrade tool initiates the transmission process again, sending the first update data from the second update data to the server controller. The first update data can update the server controller's firmware to the target controller firmware, thus completing the firmware update.

[0303] Optionally, to prevent man-in-the-middle attacks and data tampering during the transmission of the second update data to the server controller, an encrypted transmission mechanism based on two-way authentication can be employed. This mechanism includes: when the upgrade tool establishes a connection with the server controller, disabling weak password authentication and enabling only two-way key authentication based on Public Key Infrastructure (PKI), whereby the upgrade tool verifies the server controller's public key, and the server controller also verifies the upgrade tool's public key. Secondly, before transmitting the data stream, the upgrade tool calculates an integrity digest (such as a SHA-256 hash value) of the second update data and sends this digest to the server controller. Upon receiving the second update data, the server controller temporarily suspends writing to non-volatile memory, instead calculating the hash value of the received data in a memory buffer and comparing it with the previously received digest. Only if the two match perfectly will the server controller perform the firmware flashing operation; otherwise, it discards the data and returns a transmission error signal to the upgrade tool.

[0304] In the above embodiments, by adopting a phased timing transmission mode, the third update data is first sent to the server controller, and the first update data is sent after the server controller firmware is updated to the candidate controller firmware. This ensures the reliability of the update process and avoids the defect that the server controller receives the ciphertext update data when it does not have decryption capability due to timing errors, thus causing the update to fail. This achieves process control and timing reliability in a high-security transition update mode.

[0305] As an alternative, after sending the second update data to the server controller, the method further includes:

[0306] S171, send a firmware version query request to the server controller;

[0307] S172, Receive firmware version information returned by the server controller in response to the firmware version query request;

[0308] S173, Extract the target firmware version of the server controller's firmware from the firmware version information;

[0309] S174, Detect whether the target firmware version is consistent with the firmware version of the target controller firmware;

[0310] S175, if the target firmware version is consistent with the firmware version of the target controller firmware, send a fourth prompt message to the initiator of the update request, wherein the fourth prompt message is used to indicate that the controller firmware of the server controller was successfully updated using the second update data.

[0311] S176, if the target firmware version is inconsistent with the firmware version of the target controller firmware, a fifth prompt message is sent to the initiator of the update request, wherein the fifth prompt message is used to indicate that the update of the server controller's controller firmware using the second update data has failed.

[0312] Optionally, in this embodiment, considering that the server controller typically needs to perform operations such as writing, verification, and restart loading after receiving the second update data, these operations consume a certain amount of time (e.g., 1-5 minutes). Therefore, the step of sending a firmware version query request to the server controller may include, but is not limited to, a polling waiting mechanism. For example, after sending the second update data, the upgrade tool starts a status polling timer. The upgrade tool periodically (e.g., every 10 seconds) sends network probe packets or connection requests to the server controller. When the server controller's network connectivity is detected to be restored (indicating that the restart is complete), the upgrade tool immediately sends a firmware version query request (e.g., a "Get Device ID" command) to the server controller through an out-of-band management interface or an in-band interface. Subsequently, the upgrade tool receives the response message returned by the server controller, parses the version field in the message, extracts the firmware version currently running on the server controller, and obtains the target firmware version. If the upgrade tool does not detect that the server controller's network connectivity has been restored within a preset timeout period (e.g., 10 minutes), it determines that the update has timed out and failed.

[0313] Optionally, in this embodiment, the step of detecting whether the target firmware version is consistent with the firmware version of the target controller firmware may include, but is not limited to, the following: the upgrade tool obtains the firmware version of the target controller firmware specified in the update request (i.e., the expected version, such as "V3.0"), and performs a consistency comparison between the firmware version of the target controller firmware and the target firmware version (i.e., the actual version). If the target firmware version is consistent with the firmware version of the target controller firmware (e.g., the actual version has changed to V3.0), the upgrade tool determines that the firmware version update operation is successful, generates a fourth prompt message, and sends it to the initiator of the update request. If the target firmware version is inconsistent with the firmware version of the target controller firmware (e.g., the actual version is still V1.0, or has become an abnormal version number), the upgrade tool determines that the firmware version update operation has failed, generates a fifth prompt message, and sends it to the initiator of the update request.

[0314] Optionally, in this embodiment, the fourth prompt message may be, but is not limited to, the "Success:Firmware Updated to V3.0" log output by the console, the "Update successful" dialog box that pops up on the graphical interface, or a task completion callback signal sent to the cloud management platform API.

[0315] Optionally, in this embodiment, the fourth notification information may be, but is not limited to, notification data fed back to the initiator of the update request when it is determined that the target firmware version is consistent with the firmware version of the target controller firmware. The fourth notification information may include, but is not limited to, a success status code (such as "Update Success"), an identifier of the current firmware version after the update, and a timestamp indicating that the initiator has successfully updated the server controller's firmware to the target controller firmware using the second update data.

[0316] Optionally, in this embodiment, the fifth prompt information may, but is not limited to, notification data fed back to the initiator of the update request when it is determined that the target firmware version is inconsistent with the firmware version of the target controller firmware. The fifth prompt information may, but is not limited to, include a failure error code, a comparison result between the current firmware version and the expected version, and an update log summary, used to prompt the initiator that the server controller's controller firmware was not successfully updated to the target controller firmware using the second update data.

[0317] In the above embodiments, after sending the second update data to the server controller, the upgrade tool sends a firmware version query request to the server controller through polling, extracts the target firmware version and performs a consistency check with the firmware version of the target controller firmware, and sends a fourth or fifth prompt message based on the result. This enables the upgrade tool to perform automated final verification of the final result of the entire update process, thereby confirming that the server controller firmware has accurately and error-free reached the target controller firmware. This achieves closed-loop management of the update task and accurate status reporting, further realizing closed-loop control of the entire firmware update process and automated, highly reliable verification of the results.

[0318] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0319] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0320] This embodiment also provides a controller firmware update device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0321] Figure 8 This is a structural block diagram of a controller firmware update device according to an embodiment of this application, such as... Figure 8 As shown, it includes:

[0322] The first receiving module 802 is used to receive an update request, wherein the update request is used to request that the controller firmware of the server controller be updated to the target controller firmware;

[0323] The first detection module 804 is used to detect the first attribute of the first update data of the target controller firmware indicated by the update request, and to detect the second attribute of the reference controller firmware used by the server controller, wherein the first attribute is used to indicate the encryption status of the first update data, and the second attribute is used to indicate the support of the reference controller firmware for the encryption update method.

[0324] The generation module 806 is used to generate second update data that matches the server controller based on the first update data using the first update data and the second attribute.

[0325] The first sending module 808 is used to send the second update data to the server controller, wherein the second update data is used to update the server controller firmware to the target controller firmware.

[0326] In one exemplary embodiment, the first detection module includes:

[0327] The first detection unit is used to detect a first attribute of the first updated data; and when the first attribute indicates that the first updated data has an encrypted state, it detects a second attribute of the reference controller firmware used by the server controller.

[0328] Alternatively, the second detection unit is used to detect a second attribute of the reference controller firmware used by the server controller; and when the second attribute indicates that the reference controller firmware does not support the encrypted update method, it detects a first attribute of the first update data.

[0329] In one exemplary embodiment, the apparatus further includes: a first determining module, configured to determine the first update data as second update data after detecting a first attribute of the first update data, wherein the first attribute indicates that the encryption state of the first update data is an unencrypted state; or, the apparatus further includes: a second determining module, configured to determine the first update data as second update data after detecting a second attribute of the reference controller firmware used by the server controller, wherein the second attribute indicates that the reference controller firmware supports an encrypted update method.

[0330] In one exemplary embodiment, the first detection module further includes:

[0331] The third detection unit is used to detect a feature string from the first updated data; the first determination unit is used to determine, when the feature string is detected, that the first attribute used to indicate the encryption state of the first updated data is an unencrypted state; the second determination unit is used to determine, when the feature string is not detected, that the first attribute used to indicate the encryption state of the first updated data is an encrypted state.

[0332] Alternatively, the fourth detection unit is configured to detect feature strings from the first updated data, detect the relationship between the proportion of legitimate instructions in the first updated data and the proportion threshold, and detect the relationship between the disorder level of the first updated data and the disorder level threshold; the third determination unit is configured to determine that the first attribute indicating the encryption state of the first updated data is an unencrypted state when a feature string is detected, the proportion of legitimate instructions is detected to be greater than or equal to the proportion threshold, and the disorder level is detected to be less than or equal to the disorder level threshold; the fourth determination unit is configured to determine that the first attribute indicating the encryption state of the first updated data is an encrypted state when no feature string is detected, the proportion of legitimate instructions is detected to be less than the proportion threshold, and the disorder level is detected to be greater than the disorder level threshold; the fifth determination unit is configured to determine that the first attribute indicating the encryption state of the first updated data is a pseudo-encrypted state when the proportion of legitimate instructions is detected to be greater than or equal to the proportion threshold and the disorder level is detected to be greater than the disorder level threshold, or when the proportion of legitimate instructions is detected to be less than the proportion threshold and the disorder level is detected to be less than or equal to the disorder level threshold.

[0333] In one exemplary embodiment, the fourth detection unit is further configured to:

[0334] Obtain the first data in the first updated data that is within the first address range, wherein the first address range is an address range that starts at a preset offset address and has a first preset length;

[0335] Detect whether a characteristic string exists in the first set of data;

[0336] If a characteristic string is detected in the first data, it is determined that a characteristic string has been detected;

[0337] If the feature string is not detected in the first data, it is determined that no feature string was detected.

[0338] In one exemplary embodiment, the fourth detection unit is further configured to:

[0339] Obtain the second data in the first updated data that is within the second address range, wherein the second address range is an address range with the starting address of the first updated data as the starting address and having a second preset length;

[0340] The number of valid instructions included in the second data is detected to obtain valid instruction parameters, and the number of instructions included in the second data is detected to obtain reference instruction parameters, wherein a valid instruction is an instruction that conforms to the characteristics of the target opcode;

[0341] Calculate the ratio of valid instruction parameters to reference instruction parameters to obtain the percentage of valid instructions;

[0342] Compare the percentage of legitimate instructions with the percentage threshold;

[0343] If the percentage of legitimate instructions is greater than or equal to the percentage threshold, it is determined that the percentage of legitimate instructions is greater than or equal to the percentage threshold.

[0344] If the percentage of legitimate instructions is less than the percentage threshold, it is determined that the percentage of legitimate instructions is less than the percentage threshold.

[0345] In one exemplary embodiment, the fourth detection unit is further configured to:

[0346] Obtain the third data in the third address range from the first updated data, wherein the third address range is an address range that is randomly selected from the address space of the first updated data and satisfies a third preset length;

[0347] The information entropy value of the third data is detected to obtain the disorder level, where the information entropy value is used to indicate the degree of randomness in the distribution of bytes included in the third data;

[0348] Compare the degree of disorder with a disorder threshold;

[0349] If the disorder level is greater than the disorder level threshold, it is determined that the disorder level is greater than the disorder level threshold.

[0350] If the disorder level is less than or equal to the disorder level threshold, it is determined that the disorder level is less than or equal to the disorder level threshold.

[0351] In one exemplary embodiment, the apparatus further includes:

[0352] The third determining module is used to determine that the second update data has not been obtained after determining that the encryption state of the first attribute used to indicate the first update data is a pseudo-encryption state, and to send a first prompt message to the initiator of the update request. The first prompt message is used to indicate that the controller firmware of the server controller cannot be updated using the first update data indicated by the update request.

[0353] In one exemplary embodiment, the second determining module includes:

[0354] The first sending unit is used to send a firmware version query request to the server controller;

[0355] The receiving unit is used to receive the firmware version information returned by the server controller in response to the firmware version query request;

[0356] The extraction unit is used to extract the reference firmware version of the reference controller firmware from the firmware version information.

[0357] The comparison unit is used to compare the reference firmware version with a preset version threshold.

[0358] The sixth determining unit is used to determine the second attribute to indicate that the reference controller firmware does not support the encrypted update method when the reference firmware version is less than a preset version threshold.

[0359] The seventh determining unit is used to determine the second attribute to indicate that the reference controller firmware supports encrypted update methods when the reference firmware version is greater than or equal to a preset version threshold.

[0360] In one exemplary embodiment, the first detection module includes:

[0361] The acquisition unit is used to acquire the target controller identifier of the server controller.

[0362] The fifth detection unit is used to detect whether a target controller identifier exists in the controller identifier set, wherein the controller identifier set records the controller identifiers of legitimate server controllers that are allowed to update the controller firmware;

[0363] The sixth detection unit is used to detect the first attribute of the first update data of the target controller firmware indicated by the update request, and to detect the second attribute of the reference controller firmware used by the server controller, when the target controller identifier exists in the controller identifier set.

[0364] The eighth determining unit is used to determine that the legality verification of the server controller has failed if the target controller identifier does not exist in the controller identifier set, and to send a third prompt message to the initiator of the update request. The third prompt message is used to indicate that the server controller where the controller firmware requested to be updated by the update request is located has failed the legality verification.

[0365] In one exemplary embodiment, the generation module includes:

[0366] An adjustment unit is used to adjust the first attribute of the first updated data to a third attribute that matches the second attribute based on the first attribute and the second attribute, thereby obtaining the second updated data;

[0367] Alternatively, the generation unit is configured to generate third update data based on the first attribute and the second attribute, wherein the third update data is used to control the server controller to update the second attribute of the reference controller firmware to a fourth attribute that matches the first attribute to obtain candidate controller firmware, the candidate controller firmware being used to utilize the first update data; and the third update data and the first update data are determined as the second update data.

[0368] In one exemplary embodiment, the adjusting unit is further configured to:

[0369] When the second attribute indicates that the reference controller firmware does not support encrypted update, and the first attribute indicates that the first update data has an encrypted state, the reference encryption key corresponding to the first update data is obtained.

[0370] The first update data is decrypted using the reference encryption key to obtain the fourth update data;

[0371] Detect the third attribute of the fourth updated data, where the third attribute is used to indicate the encryption state of the fourth updated data;

[0372] If the third attribute indicates that the fourth updated data has an unencrypted state, the fourth updated data is identified as the second updated data;

[0373] If the third attribute indicates that the encryption state of the fourth update data is a pseudo-encryption state, it is determined that the second update data has not been obtained, and a second prompt message is sent to the initiator of the update request. The second prompt message is used to indicate that the update of the server controller firmware using the first update data indicated by the update request has failed.

[0374] In one exemplary embodiment, the adjusting unit is further configured to:

[0375] Detect the reference data version for the first updated data;

[0376] Extract the reference encryption key corresponding to the reference data version from the target storage location, where the target storage location stores the corresponding data versions and encryption keys.

[0377] In one exemplary embodiment, the generating unit is further configured to:

[0378] When the second attribute indicates that the reference controller firmware does not support encrypted update, and the first attribute indicates that the first update data has an encrypted state, the fifth update data that conforms to the reference firmware version of the reference controller firmware is obtained.

[0379] Add the sixth update data to the fifth update data to obtain the third update data. The sixth update data is used to decrypt the first update data.

[0380] In one exemplary embodiment, the generating unit is further configured to:

[0381] Add seventh and eighth update data to the fifth update data. The sixth update data includes the seventh and eighth update data. The seventh update data is used to detect the first attribute. The eighth update data is used to decrypt the first update data when the first attribute indicates that the first update data has an encrypted state.

[0382] In one exemplary embodiment, the first transmitting module further includes:

[0383] The second sending unit is used to send the third update data to the server controller, wherein the third update data is used to update the server controller firmware to the candidate controller firmware.

[0384] The third sending unit is used to send first update data to the server controller when the server controller updates the reference controller firmware to the candidate controller firmware, wherein the first update data is used to update the server controller firmware to the target controller firmware.

[0385] In one exemplary embodiment, the apparatus further includes:

[0386] The second sending module is used to send a firmware version query request to the server controller after sending the second update data to the server controller;

[0387] The second receiving module is used to receive the firmware version information returned by the server controller in response to the firmware version query request;

[0388] The extraction module is used to extract the target firmware version of the server controller's controller firmware from the firmware version information.

[0389] The second detection module is used to detect whether the target firmware version is consistent with the firmware version of the target controller firmware.

[0390] The third sending module is used to send a fourth prompt message to the initiator of the update request when the target firmware version is consistent with the firmware version of the target controller firmware. The fourth prompt message is used to indicate that the controller firmware of the server controller has been successfully updated using the second update data.

[0391] The fourth sending module is used to send a fifth prompt message to the initiator of the update request when the target firmware version is inconsistent with the firmware version of the target controller firmware. The fifth prompt message is used to indicate that the update of the controller firmware of the server controller using the second update data has failed.

[0392] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0393] For a description of the features in the embodiment corresponding to the controller firmware update device, please refer to the relevant description in the embodiment corresponding to the controller firmware update method, which will not be repeated here.

[0394] Embodiments of this application also provide an electronic device. Figure 9 This is a schematic diagram of an electronic device according to an embodiment of this application, such as... Figure 9 As shown, the electronic device includes a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in any of the above-described embodiments of the controller firmware update method.

[0395] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0396] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0397] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described controller firmware update method embodiments when running.

[0398] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0399] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described in various embodiments of this application; the computer program product further includes a non-volatile computer-readable storage medium storing the computer program that, when executed by a processor, implements the steps of the controller firmware update method described in various embodiments of this application.

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

[0401] The present application provides a detailed description of a controller firmware update method. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of these embodiments are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A method for updating controller firmware, characterized in that, include: Receive an update request, wherein the update request is used to request that the server controller's controller firmware be updated to the target controller firmware; The system detects a first attribute of the first update data of the target controller firmware indicated by the update request, and detects a second attribute of the reference controller firmware used by the server controller, wherein the first attribute is used to indicate the encryption status of the first update data, and the second attribute is used to indicate the support of the reference controller firmware for encrypted update methods. Based on the first attribute and the second attribute, the first update data is used to generate second update data that matches the server controller; The second update data is sent to the server controller, wherein the second update data is used to update the controller firmware of the server controller to the target controller firmware; The step of generating second update data matching the server controller using the first update data based on the first attribute and the second attribute includes: Generate third update data based on the first attribute and the second attribute; determine the third update data and the first update data as the second update data, wherein the third update data is used to control the server controller to update the second attribute of the reference controller firmware to a fourth attribute that matches the first attribute to obtain a candidate controller firmware, the candidate controller firmware is used to use the first update data, and the fourth attribute is used to indicate that the candidate controller firmware supports encrypted update methods; The step of generating third update data based on the first attribute and the second attribute includes: When the second attribute indicates that the reference controller firmware does not support encrypted update, and the first attribute indicates that the first update data has an encrypted state, the fifth update data that conforms to the reference firmware version of the reference controller firmware is obtained; a sixth update data is added to the fifth update data to obtain the third update data, wherein the sixth update data is used to implement the function of decrypting the first update data; The step of adding the sixth update data to the fifth update data includes: Add seventh and eighth update data to the fifth update data, wherein the sixth update data includes the seventh and eighth update data, the seventh update data is used to detect the first attribute, and the eighth update data is used to decrypt the first update data when the first attribute indicates that the encryption state of the first update data is encrypted.

2. The method according to claim 1, characterized in that, The detection of a first attribute of the first update data of the target controller firmware indicated by the update request, and the detection of a second attribute of the reference controller firmware used by the server controller, include: Detect a first attribute of the first updated data; if the first attribute indicates that the first updated data has an encrypted state, detect a second attribute of the reference controller firmware used by the server controller. Alternatively, detect a second attribute of the reference controller firmware used by the server controller; if the second attribute indicates that the reference controller firmware does not support encrypted update methods, detect a first attribute of the first update data.

3. The method according to claim 2, characterized in that, After detecting the first attribute of the first updated data, the method further includes: determining the first updated data as the second updated data when the first attribute indicates that the encryption state of the first updated data is an unencrypted state; Alternatively, after detecting the second attribute of the reference controller firmware used by the server controller, the method further includes: determining the first update data as the second update data if the second attribute indicates that the reference controller firmware supports encrypted update methods.

4. The method according to claim 1, characterized in that, The first attribute of detecting the first update data of the target controller firmware indicated by the update request includes: Detect a feature string from the first updated data; if the feature string is detected, determine that the first attribute is used to indicate that the first updated data has an unencrypted state; if the feature string is not detected, determine that the first attribute is used to indicate that the first updated data has an encrypted state. Alternatively, a feature string can be detected from the first updated data, the relationship between the proportion of legitimate instructions and a proportion threshold in the first updated data can be detected, and the relationship between the disorder level of the first updated data and a disorder threshold can be detected. If the feature string is detected, the proportion of legitimate instructions is detected to be greater than or equal to the proportion threshold, and the disorder level is detected to be less than or equal to the disorder threshold, the first attribute is determined to indicate that the first updated data has an unencrypted state. If the feature string is not detected, the proportion of legitimate instructions is detected to be less than the proportion threshold, and the disorder level is detected to be greater than the disorder threshold, the first attribute is determined to indicate that the first updated data has an encrypted state. If the proportion of legitimate instructions is detected to be greater than or equal to the proportion threshold and the disorder level is detected to be greater than the disorder threshold, or if the proportion of legitimate instructions is detected to be less than the proportion threshold and the disorder level is detected to be less than or equal to the disorder threshold, the first attribute is determined to indicate that the first updated data has a pseudo-encrypted state.

5. The method according to claim 4, characterized in that, The step of detecting feature strings from the first updated data includes: Obtain the first data in the first updated data that is within the first address range, wherein the first address range is an address range that starts at a preset offset address and has a first preset length; Detect whether the feature string exists in the first data; If the feature string is detected in the first data, it is determined that the feature string has been detected; If the feature string is not detected in the first data, it is determined that the feature string has not been detected.

6. The method according to claim 4, characterized in that, The detection of the relationship between the proportion of legitimate instructions and the proportion threshold in the first updated data includes: Obtain the second data in the first updated data that is within the second address range, wherein the second address range is an address range with the starting address of the first updated data as the starting address and having a second preset length; The number of valid instructions included in the second data is detected to obtain valid instruction parameters, and the number of instructions included in the second data is detected to obtain reference instruction parameters, wherein the valid instructions are instructions that conform to the characteristics of the target opcode; Calculate the ratio of the legal instruction parameters to the reference instruction parameters to obtain the proportion of legal instructions; Compare the percentage of legal instructions with the percentage threshold; If the proportion of legitimate instructions is greater than or equal to the proportion threshold, it is determined that the proportion of legitimate instructions is greater than or equal to the proportion threshold. If the percentage of legitimate instructions is less than the percentage threshold, it is determined that the percentage of legitimate instructions is less than the percentage threshold.

7. The method according to claim 4, characterized in that, The detection of the relationship between the disorder level of the first updated data and the disorder level threshold includes: Obtain the third data in the first updated data that is within the third address range, wherein the third address range is an address range randomly selected in the address space of the first updated data that satisfies a third preset length; The information entropy value of the third data is detected to obtain the disorder degree, wherein the information entropy value is used to indicate the degree of randomness in the distribution of bytes included in the third data; Compare the degree of disorder with the degree of disorder threshold; If the disorder level is greater than the disorder level threshold, it is determined that the disorder level is greater than the disorder level threshold. If the disorder level is less than or equal to the disorder level threshold, it is determined that the disorder level is less than or equal to the disorder level threshold.

8. The method according to claim 4, characterized in that, After determining that the first attribute indicating the encryption state of the first updated data is a pseudo-encryption state, the method further includes: If it is determined that the second update data has not been obtained, a first prompt message is sent to the initiator of the update request, wherein the first prompt message is used to indicate that the controller firmware of the server controller cannot be updated using the first update data indicated by the update request.

9. The method according to claim 1, characterized in that, The second attribute of detecting the reference controller firmware used by the server controller includes: Send a firmware version query request to the server controller; Receive the firmware version information returned by the server controller in response to the firmware version query request; Extract the reference firmware version of the reference controller firmware from the firmware version information; Compare the reference firmware version with a preset version threshold; If the reference firmware version is less than the preset version threshold, the second attribute is determined to indicate that the reference controller firmware does not support encrypted update methods. If the reference firmware version is greater than or equal to the preset version threshold, the second attribute is determined to indicate that the reference controller firmware supports encrypted update methods.

10. The method according to claim 1, characterized in that, The detection of a first attribute of the first update data of the target controller firmware indicated by the update request, and the detection of a second attribute of the reference controller firmware used by the server controller, include: Obtain the target controller identifier of the server controller; The system detects whether the target controller identifier exists in the controller identifier set, wherein the controller identifier set records the controller identifiers of legitimate server controllers that are allowed to update the controller firmware; If the target controller identifier exists in the controller identifier set, detect the first attribute of the first update data of the target controller firmware indicated by the update request, and detect the second attribute of the reference controller firmware used by the server controller; If the target controller identifier is not found in the set of controller identifiers, the validity check of the server controller is determined to have failed, and a third prompt message is sent to the initiator of the update request. The third prompt message is used to indicate that the server controller where the controller firmware requested to be updated by the update request is located has failed the validity check.

11. The method according to claim 1, characterized in that, The step of generating second update data matching the server controller using the first update data based on the first attribute and the second attribute includes: Based on the first attribute and the second attribute, the first attribute of the first updated data is adjusted to a third attribute that matches the second attribute to obtain the second updated data.

12. The method according to claim 11, characterized in that, The step of adjusting the first attribute of the first updated data to a third attribute that matches the second attribute based on the first attribute and the second attribute to obtain the second updated data includes: When the second attribute indicates that the reference controller firmware does not support encrypted update, and the first attribute indicates that the first update data has an encrypted state, the reference encryption key corresponding to the first update data is obtained. The first updated data is decrypted using the reference encryption key to obtain the fourth updated data; Detect the third attribute of the fourth updated data, wherein the third attribute is used to indicate the encryption state of the fourth updated data; If the third attribute indicates that the fourth updated data has an unencrypted state, the fourth updated data is identified as the second updated data; If the third attribute indicates that the encryption state of the fourth update data is a pseudo-encryption state, it is determined that the second update data has not been obtained, and a second prompt message is sent to the initiator of the update request, wherein the second prompt message is used to indicate that the update of the server controller firmware using the first update data indicated by the update request has failed.

13. The method according to claim 12, characterized in that, Obtaining the reference encryption key corresponding to the first updated data includes: Detect the reference data version of the first updated data; Extract the reference encryption key corresponding to the reference data version from the target storage location, wherein the target storage location stores data versions and encryption keys with a corresponding relationship.

14. The method according to claim 1, characterized in that, Sending the second update data to the server controller includes: The third update data is sent to the server controller, wherein the third update data is used to update the server controller firmware to the candidate controller firmware; When the server controller updates the reference controller firmware to the candidate controller firmware, the first update data is sent to the server controller, wherein the first update data is used to update the server controller firmware to the target controller firmware.

15. The method according to claim 1, characterized in that, After sending the second update data to the server controller, the method further includes: Send a firmware version query request to the server controller; Receive the firmware version information returned by the server controller in response to the firmware version query request; Extract the target firmware version of the server controller's firmware from the firmware version information; Detect whether the target firmware version is consistent with the firmware version of the target controller firmware; If the target firmware version is consistent with the firmware version of the target controller firmware, a fourth prompt message is sent to the initiator of the update request, wherein the fourth prompt message is used to indicate that the controller firmware of the server controller has been successfully updated using the second update data; If the target firmware version is inconsistent with the firmware version of the target controller firmware, a fifth prompt message is sent to the initiator of the update request, wherein the fifth prompt message is used to indicate that the update of the controller firmware of the server controller using the second update data has failed.

16. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the controller firmware update method as described in any one of claims 1 to 15 when executing the computer program.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the controller firmware update method as described in any one of claims 1 to 15.

18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the controller firmware update method as described in any one of claims 1 to 15.

Images