Method for embedded device firmware segmentation randomization and upgrade

Abstract

This invention provides a method for segmented random encryption and upgrade of embedded device firmware. The method includes: generating overall firmware segmentation rules based on function entry address offsets; generating data segments based on data structure boundary identifiers; segmenting the firmware and recording the segment index and segment index offset of each segment; randomly assigning encryption algorithms to each segment using a pre-set multi-type encryption algorithm pool; obtaining the actual independent key for each segment through hash operation by concatenating dynamic factors; independently encrypting each segment and storing the encryption algorithm pool index and encryption key metadata corresponding to each segment; reassembling the encrypted segments in their original order into complete ciphertext firmware, and attaching the encryption algorithm pool index and encryption key metadata to generate encrypted firmware ciphertext. This invention ensures that each segment key is unique and unpredictable through dynamic random segmentation and random allocation of algorithm pools, completely avoiding the defects of static keys and blocking firmware imitation paths at the source.

Description

Technical Field

[0001] This invention relates to the field of embedded device firmware security protection technology, and in particular to a method for segmented random encryption and upgrade of embedded device firmware. Background Technology

[0002] Embedded firmware, as the core software carrier of embedded systems, is directly related to the functional integrity and data confidentiality of the device. With the widespread adoption of the Internet of Things (IoT) and smart devices, attacks targeting firmware, such as reverse engineering, unauthorized copying, and tampering, are increasingly common. Therefore, firmware encryption technology has become a crucial protective measure to prevent code leakage and logical cracking. Currently, the industry generally adopts encryption schemes based on hardware binding or parameterized generation, aiming to bind firmware to specific devices, thereby resisting unauthorized access and use.

[0003] However, existing firmware protection technologies still have significant security shortcomings in their design and implementation. For example, some schemes employ selective encryption strategies, encrypting only the code segments running in RAM, while leaving the read-only segments stored in Flash in plaintext. This allows attackers to extract the unencrypted segments and reverse engineer the system's core logic and process structure. Regarding key management, although unique device identifiers (such as serial numbers) are introduced to generate unique encryption keys for each device, this reliance on a fixed root key and static generation algorithm results in identical encryption results for the same device. This static characteristic allows attackers to deduce universal decryption rules after obtaining the encrypted firmware once, thus weakening the actual protective effect of encryption.

[0004] Furthermore, existing methods fall short in terms of key dynamism and randomness. Some technologies attempt to generate dynamic keys by combining hardware-unique encoding with time parameters, but because the encryption algorithm itself is fixed and relies on a pre-built key store or key generator, a single point of security risk exists if related components are leaked. Meanwhile, the unified firmware encryption approach lacks a segmented encryption mechanism, making it particularly vulnerable to mass cracking attacks. In addition, although existing solutions employ hybrid encryption systems to improve efficiency, their root keys still need to be pre-installed in the device, and multiple encryptions of the same plaintext firmware produce consistent outputs, failing to effectively defend against replay attacks and firmware cloning.

[0005] Comprehensive analysis reveals that existing firmware encryption technologies generally suffer from fundamental flaws such as static encryption modes, predictable keys, and weak anti-cloning capabilities. Attackers can use differential analysis, pattern recognition, and other methods to locate encryption modules and reverse-engineer the encryption and decryption logic, thereby enabling unauthorized copying and counterfeiting during firmware distribution and deployment. These limitations make current technologies ill-equipped to cope with increasingly complex attack methods, necessitating the introduction of dynamic and randomized mechanisms in key generation and encryption processes to enhance the overall security strength and anti-cracking capabilities of firmware. Summary of the Invention

[0006] To address the above issues, this invention employs dynamic random segmentation and random allocation of the algorithm pool, ensuring that the segment positions and algorithm combinations for each encryption of the same firmware are different, thus guaranteeing that each key is unique and unpredictable, completely avoiding the defects of static keys, and blocking firmware imitation paths at the source.

[0007] According to an embodiment of the present invention, a method for segmented random encryption and upgrade of firmware for embedded devices is provided.

[0008] In a first aspect of the present invention, a method for segmented random encryption and upgrade of firmware in an embedded device is provided. The method includes: Step S01: Generate firmware overall segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segment index and segment index offset of each segment. Step S02: A multi-type encryption algorithm pool is pre-set to randomly assign encryption algorithms to each segment. The dynamic factor is concatenated and hashed to obtain the actual independent key for each segment. Each segment is encrypted independently, and the encryption algorithm pool index and encryption key metadata corresponding to each segment are stored. Step S03: Reassemble the encrypted segments into a complete ciphertext firmware in the original order, and attach the encryption algorithm pool index and encryption key metadata to finally generate the encrypted firmware ciphertext.

[0009] Furthermore, the number and boundaries of the segments mentioned in step S01 are dynamically determined by a cryptographically secure random number generator, whose random factor comes from the system entropy source, and the number of segments is adapted to the storage block size of the embedded device.

[0010] Furthermore, the length of the segments mentioned in step S01 is dynamically adjusted using a formula: Segment_Length=Base_Length+Rand()%Max_Variation, Where Base_Length is the preset base length, Max_Variation is the maximum random offset, and Rand() is a cryptographically secure random number generated based on the hardware entropy source.

[0011] Furthermore, the pre-set multi-type encryption algorithm pool mentioned in step S02 randomly assigns encryption algorithms to each segment, and the formula for generating the random factor is: Algorithm_Index= Rand()%Pool_Size, The Rand() function returns a cryptographically secure random number generated based on a hardware entropy source, and Pool_Size represents the number of currently valid algorithms in the algorithm pool.

[0012] Furthermore, the dynamic factors mentioned in step S02 include: random number seed, segment number, segment index offset, and time quantization parameter. Calling Rand() obtains a real-time 32-bit random number. The hardware random number generator RNG generates a 32-bit true random number seed by simulating a noise source. The current segment number Segment_Index of the firmware's random segmentation is passed in as the key parameter; The segment index offset Segment_Offset of the firmware's random segmentation is passed in as a key parameter; Obtain the time quantization parameter Time_Quant, a 64-bit data. The first 32 bits are the number of seconds since 1900, and the last 32 bits are the fractional part of the seconds. The time quantization parameter is split into two 32-bit fields in big-endian order. The higher field represents the integer part of seconds, and the lower field represents the fractional part of microseconds. Both are then cyclically shifted with the base obfuscation value.

[0013] Furthermore, the specific steps of step S03 are as follows: each encrypted segment of ciphertext is concatenated byte-level while maintaining its original order. During the concatenation process, a structured metadata header is inserted. The metadata header adopts a fixed-length design and includes the following key fields: firmware version identifier, global timestamp, total number of segments, algorithm index array for each segment, key checksum for each segment, and integrity check code.

[0014] Furthermore, the method also includes step S04: during the decryption stage, the device reads the metadata header in a fixed format, decrypts it segment by segment according to the segment information, and reassembles the decrypted legitimate data into complete plaintext firmware according to the segment index.

[0015] In a second aspect of the invention, an apparatus for segmented random encryption and upgrading of firmware in embedded devices is provided. The apparatus includes: Firmware segmentation module: used to generate overall firmware segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segment index and segment index offset of each segment; Segmented encryption module: It is used to pre-set multiple types of encryption algorithm pools to randomly assign encryption algorithms to each segment, concatenate dynamic factors and perform hash operation to obtain the actual independent key of each segment, encrypt each segment independently, and store the encryption algorithm pool index and encryption key metadata corresponding to each segment. Encryption integration module: used to reassemble the encrypted segments into a complete ciphertext firmware in the original order, and to attach the encryption algorithm pool index and encryption key metadata, and finally generate the encrypted firmware ciphertext; Decryption module: Used during the decryption phase, the device reads the metadata header in a fixed format, decrypts it segment by segment based on the segment information, and reassembles the decrypted legitimate data into complete plaintext firmware according to the segment index.

[0016] In a third aspect of the invention, an electronic device is provided. The electronic device includes a memory and a processor, the memory storing a computer program, the processor executing the program to implement the method according to a first aspect of the invention.

[0017] In a fourth aspect of the invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method according to a first aspect of the invention.

[0018] This invention uses dynamic random segmentation and random allocation of algorithm pools to ensure that the segment positions and algorithm combinations are different for each encryption of the same firmware, thus ensuring that each key is unique and unpredictable, completely avoiding the defects of static keys and blocking the firmware imitation path from the root.

[0019] It should be understood that the description in the Summary of the Invention is not intended to limit the key or essential features of the embodiments of the present invention, nor is it intended to restrict the scope of the invention. Other features of the invention will become readily apparent from the following description.

[0020] The beneficial effects of this invention are: 1. By using dynamic random segmentation and random allocation of the algorithm pool, the segment positions and algorithm combinations for each encryption of the same firmware are different, thus preventing attackers from reverse-engineering the encryption logic through a fixed pattern. 2. Employ multi-source factor dynamic key splicing, combined with device identifier, random number and time parameters, to ensure that each key segment is unique and unpredictable, completely avoiding the defects of static keys; 3. By using random segmentation and dynamic key mechanisms, the ciphertext structure and content generated by each encryption of the same plaintext firmware are completely different, achieving "one firmware, one ciphertext", thus blocking the firmware imitation path from the root. Attached Figure Description

[0021] The above and other features, advantages, and aspects of the various embodiments of the present invention will become more apparent from the accompanying drawings and the following detailed description. Wherein: Figure 1 A flowchart illustrating a method for segmented random encryption and upgrade of embedded device firmware according to an embodiment of the present invention is shown. Figure 2 A schematic diagram of firmware encryption according to an embodiment of the present invention is shown; Figure 3 A schematic diagram of an encryption algorithm pool according to an embodiment of the present invention is shown; Figure 4 A schematic diagram of firmware decryption according to an embodiment of the present invention is shown; Figure 5 A ciphertext flow diagram according to an embodiment of the present invention is shown; Figure 6 A block diagram of an apparatus for segmented random encryption and upgrade of embedded device firmware according to an embodiment of the present invention is shown; Figure 7 A schematic diagram of an embedded device firmware segmented random encryption and upgrade according to an embodiment of the present invention is shown. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] According to an embodiment of the present invention, a method for segmented random encryption and upgrade of embedded device firmware is proposed. By dynamically randomizing segments and randomly allocating algorithm pools, the segment positions and algorithm combinations for each encryption of the same firmware are different, ensuring that each segment key is unique and unpredictable, completely avoiding the defects of static keys, and blocking the firmware imitation path from the root.

[0024] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0025] Figure 1 This is a schematic flowchart illustrating a method for segmented random encryption and upgrade of embedded device firmware according to an embodiment of the present invention. The method includes: Step S01: Generate firmware overall segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segment index and segment index offset of each segment. Step S02: A multi-type encryption algorithm pool is pre-set to randomly assign encryption algorithms to each segment. The dynamic factor is concatenated and hashed to obtain the actual independent key for each segment. Each segment is encrypted independently, and the encryption algorithm pool index and encryption key metadata corresponding to each segment are stored. Step S03: Reassemble the encrypted segments into a complete ciphertext firmware in the original order, and attach the encryption algorithm pool index and encryption key metadata to finally generate the encrypted firmware ciphertext. Step S04: During the decryption phase, the device reads the metadata header in a fixed format, decrypts it segment by segment according to the segment information, and reassembles the decrypted legitimate data into complete plaintext firmware according to the segment index.

[0026] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0027] To provide a clearer explanation of the above-described method for segmented random encryption and upgrade of embedded device firmware, a specific embodiment will be used for illustration below. However, it is worth noting that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation of the present invention.

[0028] The following example will further illustrate the method of segmented random encryption and upgrade of embedded device firmware in more detail.

[0029] Assume the embedded device is an industrial motion control card, using an STM32F4 series main control chip (with a built-in hardware random number generator RNG), and a Flash sector size of 4KB (4,096 Bytes). The total size of the compiled plaintext firmware is 500KB (512,000 Bytes).

[0030] Step S01: Generate firmware overall segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segment index and segment index offset of each segment.

[0031] like Figure 2 As shown, the number of segments and their boundaries are dynamically determined by a cryptographically secure random number generator. Its random factor comes from system entropy sources (such as memory state values ​​and hardware clock noise), ensuring that the segmentation results of multiple preprocessings of the same firmware are different, and that the number of segments is strictly adapted to the size of the embedded device's storage block (such as the size of the Flash sector), avoiding decryption anomalies caused by cross-block storage.

[0032] The segment length is dynamically adjusted using a formula: Segment_Length=Base_Length+Rand()%Max_Variation, Where Base_Length is the preset baseline length (set according to the average size of firmware functional modules, such as 512 bytes), Max_Variation is the maximum random offset (such as ±128 bytes to limit the length fluctuation range), and Rand() is a cryptographically secure random number generated based on a hardware entropy source (hardware random number generator RNG). This design makes the segment length unpredictable, and the length of the same logical segment varies in different encryption cycles, effectively preventing attackers from locating key modules through fixed-length patterns. The segment index and segment index offset of each segment are calculated and recorded in real time.

[0033] In this embodiment, the total firmware size is 500KB (512,000 bytes). With Base_Length set to 2048 bytes and Max_Variation to 512 bytes, and assuming the current Rand() value generated by the hardware RNG is 386, the global segment length of this firmware is calculated as: Segment_Length = 2048 + 386 % 512 = 2434 bytes. Subsequently, the firmware is segmented into approximately 210 equal-length segments (512000 ÷ 2434 ≈ 210), with the last segment (less than 2434 bytes) serving as a separate tail segment. This mechanism ensures that the segment lengths for each encryption of the same firmware are different, but within each encryption, the segment lengths are consistent and the boundaries are clear.

[0034] Step S02: A multi-type encryption algorithm pool is pre-set to randomly assign encryption algorithms to each segment. The dynamic factors are concatenated and hashed to obtain the actual independent key for each segment. Each segment is encrypted independently, and the encryption algorithm pool index and encryption key metadata corresponding to each segment are stored.

[0035] like Figure 3 As shown, the multi-type encryption algorithm pool includes symmetric algorithms such as AES, 3DES, and ChaCha20, as well as asymmetric algorithms such as RSA and ECC.

[0036] The core of random allocation lies in real-time randomness, and its random factor generation formula is as follows: Algorithm_Index= Rand()%Pool_Size, The Rand() function returns a cryptographically secure random number generated based on a hardware entropy source (such as the STM32F4's built-in hardware random number generator RNG), and Pool_Size is the number of currently valid algorithms in the algorithm pool.

[0037] The modulo operation yields the Algorithm_Index result, and the dynamically generated index number corresponds to different encryption algorithms in the algorithm pool, thus ensuring that the algorithm combination is unique for each encryption. The encryption algorithm pool also supports dynamically adding new algorithms. Dynamic algorithm updates prevent attackers from building long-term effective cracking models.

[0038] Dynamic factors include: random number seed, segment number, segment index offset, and time quantization parameter, specifically: Calling Rand() obtains a real-time 32-bit random number. The hardware random number generator RNG generates a 32-bit true random number seed by simulating a noise source. The current segment number Segment_Index of the firmware's random segmentation is passed in as the key parameter; The segment index offset Segment_Offset of the firmware's random segmentation is passed in as a key parameter; Obtain the time quantization parameter Time_Quant, a 64-bit data. The first 32 bits are the number of seconds since 1900, and the last 32 bits are the fractional part of the seconds. The time quantization parameter is split into two 32-bit fields in big-endian order. The higher field represents the integer part of seconds, and the lower field represents the fractional part of microseconds. Both are then cyclically shifted with the base obfuscation value.

[0039] An independent key is generated for each segment, forming the basic obfuscation value. The actual key is obtained by concatenating the above dynamic factors and performing a hash operation, thereby enhancing the independence between the keys of different segments and ensuring that the key for the same segment is different in different encryption cycles.

[0040] Meanwhile, the actual key for each segment is only valid for the current firmware version, and the firmware version number is embedded as an implicit factor in the initial vector of the hash operation to ensure that historical keys automatically become invalid after the version upgrade.

[0041] In this embodiment, the multi-type encryption algorithm pool is pre-configured with four valid algorithms (Pool_Size=4): index 0 – AES-256, index 1 – 3DES, index 2 – ChaCha20, and index 3 – SM4. Assuming that when encrypting the third segment, the Rand() function generated by the hardware RNG returns 17, then Algorithm_Index = 17%4 = 1, meaning the 3DES algorithm is assigned to the third segment. If Rand() returns 23 when encrypting the fifth segment, then Algorithm_Index = 23%4 = 3, and the SM4 algorithm is assigned. This mechanism ensures a random combination of algorithms for each segment.

[0042] Assuming the current firmware version is V2.1.0, the parameters for the current encrypted second segment are as follows: Rand() generates a 32-bit true random number seed of 0x8A3F5D21; Segment_Index is 2; Segment_Offset is 0x00000982 (decimal 2434, which is the starting offset of the second segment in the entire file); the current time quantization parameter Time_Quant is 0x01F4C8B6A3D20000 (where the high 32 bits of integer seconds are 0x01F4C8B6, and the low 32 bits of microseconds are 0xA3D20000), the high field is circularly shifted left by 3 bits with the basic obfuscation value 0x5A5A5A5A, and the low field is circularly shifted right by 5 bits. After concatenation, input the hash operation: Key_segment=SHA256(0x8A3F5D21+2+0x00000C80||shifted Time_Quant||IV(V2.1.0)). Concatenate the above parameters with the version number initial vector and input the SHA-256 operation to generate a unique 256-bit independent key for this segment. The result is: 0xA3B7D9E2F1C4A8905E6D2B8F4A1C7E3D9B0F5A2E6C8D1F3B5A7E9C0D2F4A6B8.

[0043] Step S03: Reassemble the encrypted segments into a complete ciphertext firmware in the original order, and attach the encryption algorithm pool index and encryption key metadata to finally generate the encrypted firmware ciphertext.

[0044] The segmented encryption process employs a parallel pipeline architecture to improve processing efficiency, with each logical segment encryption task executing independently without blocking others. Specifically, after the firmware completes random segmentation, the encryption scheduler creates an independent encryption context for each segment. This context contains the algorithm identifier, key handle, and original physical address information assigned to that segment. The encryption engine then calls the corresponding software implementation library based on the algorithm type.

[0045] The encrypted ciphertext segments are concatenated byte-by-byte while maintaining their original order, with a structured metadata header inserted during the concatenation process. The metadata header is of fixed length and includes the following key fields: firmware version identifier, global timestamp, total number of segments, algorithm index array for each segment, key checksum for each segment, and integrity checksum. A 32-bit cyclic redundancy checksum covering the entire metadata header and subsequent ciphertext is appended to the end of the metadata header to ensure it is not tampered with during data transmission.

[0046] Key concatenation formula: Key_segment = Hash(random number Rand() + Segment_Index + Segment_Offset || Time_Quant).

[0047] Due to the dynamic and random encryption nature of the ciphertext, each generated ciphertext is different. Calculating the MD5 hash and storing it can also be used to effectively trace the generation time and batch of ciphertexts.

[0048] The encrypted firmware is used for internal circulation among employees, including but not limited to SD cards, USB flash drives, online chat tools, and other means.

[0049] In this embodiment, the metadata header adopts a fixed length of 256 bytes. The specific field allocation is as follows: firmware version identifier occupies 16 bytes (e.g., "GW_V2.1.0"); global timestamp occupies 8 bytes; total number of segments occupies 2 bytes (e.g., 0x0040, indicating 64 segments); segment algorithm index array occupies 256 bytes (1 byte algorithm index per segment); segment key checksum occupies 256 bytes (4 bytes CRC32 per segment); integrity checksum occupies 4 bytes (covering the entire 256-byte header and the subsequent 512KB ciphertext CRC32 checksum), with the remaining space reserved as 0xFF.

[0050] Step S04: During the decryption phase, the device reads the metadata header in a fixed format, decrypts it segment by segment according to the segment information, and reassembles the decrypted legitimate data into complete plaintext firmware according to the segment index.

[0051] The core of the decryption process lies in dynamically restoring the randomization parameters in the encryption process, ensuring that the terminal device can accurately reconstruct the algorithm and key used in each encryption.

[0052] The specific execution steps are as follows: After the terminal device is powered on, it first receives the encrypted firmware data stream through a preset communication interface (including but not limited to USB flash drive, SD card upgrade, serial port upgrade, CAN upgrade, network upgrade, etc. Regardless of the upgrade method, the embedded device can ultimately read the encrypted firmware file in segments). When the firmware transmission start flag (such as a specific magic number 0x68 0x86 0x5A0xA5) is detected, the metadata parsing state machine is started. The receiving module adopts a dual-buffer design: the front buffer is used to receive the original ciphertext, and the back buffer is used to temporarily store the parsed metadata, realizing pipelined processing to reduce memory usage.

[0053] like Figure 4 As shown, during the metadata parsing phase, the device reads the metadata header in a fixed format. The header structure strictly corresponds to the design of the encryption phase, and the device dynamically allocates a decryption context array accordingly. Each element of the array contains a dynamic algorithm index identifier, dynamic key metadata information, and a segment length field. Decryption is performed segment by segment based on the segment information.

[0054] The current decryption segment is mapped to the corresponding dynamic encryption algorithm, and the key for the current decryption segment is regenerated based on the same dynamic factors. Key reconstruction is a crucial step in the decryption process, requiring strict reproduction of the multi-source factor acquisition during the encryption phase. Ciphertext data is received segment by segment, and decryption is performed segment by segment.

[0055] After decryption, the legitimate data can be decrypted segment by segment according to the segment index and then reassembled into complete plaintext firmware. The plaintext reassembly and burning stages are optimized according to the physical characteristics of embedded memory. Since Flash memory typically uses pages (e.g., 2KB) or sectors (e.g., 4KB) as the smallest erase unit, the decrypted plaintext segments are accumulated in memory until the page boundaries are aligned before batch burning. In the specific implementation, the device maintains two memory page buffers that work alternately: buffer A receives decrypted data while buffer B executes Flash programming for the previous batch of data. When the accumulated data reaches the page capacity or encounters the firmware end marker, the burning sequence is initiated: first, a page erase command is sent, then the programming data is written, and finally, read-back verification is performed. The burned page data is immediately overwritten and zeroed out, rather than simply marked as invalid, to prevent physical memory residue. For the last segment of data that is less than the page capacity, random noise is filled into the entire page before burning to ensure that there are no uninitialized areas in the Flash physical space.

[0056] If a metadata CRC check fails during the entire decryption process, it is determined that the transmission is corrupted or tampered with, and a retransmission is requested, limiting the number of retries per firmware to 3.

[0057] like Figure 5 The diagram shown illustrates the encrypted text flow of this embodiment.

[0058] In this embodiment, the R&D engineer sends the generated 500KB encrypted firmware to the production line via USB flash drive. After the industrial motion control card powers on, the bootloader reads the encrypted file, detects the file, parses the metadata, and determines that the global segment length of the firmware is 2434 bytes. Decryption is performed using alternating 4KB buffers for burning. 1. Data Accumulation and Sector Alignment: Buffer A (4KB) receives and decrypts ciphertext. When the decrypted plaintext data accumulates to 4096 bytes (4KB) in A, the Flash erase and burning operation is immediately triggered: first, a sector erase command is sent, then the 4KB of data is written to the corresponding sector of the Flash, and finally, a read-back verification is performed.

[0059] 2. Cross-Segment Continuous Programming: Since the global segment length is 2434 bytes, a 4KB sector typically spans two segments. For example, after buffer A receives the first segment (2434 bytes), it continues to receive the second segment. When the accumulated data reaches 4096 bytes (i.e., the entire first segment plus the first 1662 bytes of the second segment), the first sector programming is triggered. After programming is complete, buffer A continues to receive the remaining 772 bytes of the second segment and subsequent segments.

[0060] 3. Double-buffered pipeline: When buffer A is full (4KB) and programming is performed, the decryption module automatically switches to buffer B (4KB) to continue receiving and decrypting data, realizing parallel pipelined operation of "receiving and decrypting" and "Flash programming", reducing waiting time.

[0061] 4. End-of-page padding and zeroing: For the last segment of firmware data less than 4KB, full-page padding with 0x00010203... incrementing random noise until 4096 bytes are aligned before burning, ensuring no uninitialized areas in the Flash physical space. After each batch of 4KB data is burned, the buffer is immediately overwritten and zeroed to prevent plaintext residue in physical memory.

[0062] Based on the same inventive concept, this invention also proposes a device for segmented random encryption and upgrade of embedded device firmware. The implementation of this device can be found in the implementation of the method described above; repeated details will not be repeated. Figure 6 As shown, the device 100 includes: Firmware segmentation module 101: used to generate overall firmware segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segmentation index and segmentation index offset of each segment; Segmented encryption module 102: It is used to pre-set multiple types of encryption algorithm pools to randomly assign encryption algorithms to each segment, concatenate dynamic factors and perform hash operation to obtain the actual independent key of each segment, encrypt each segment independently, and store the encryption algorithm pool index and encryption key metadata corresponding to each segment. Encryption integration module 103: used to reassemble the encrypted segments into a complete ciphertext firmware in the original order, and to attach the encryption algorithm pool index and encryption key metadata, and finally generate the encrypted firmware ciphertext. Decryption module 104: Used during the decryption phase for the device to read the metadata header in a fixed format, decrypt segment by segment according to the segment information, and reassemble the decrypted legitimate data into complete plaintext firmware according to the segment index.

[0063] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the described module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0064] like Figure 7 As shown, the device includes a central processing unit (CPU), which can perform various appropriate actions and processes based on computer program instructions stored in read-only memory (ROM) or loaded from storage units into random access memory (RAM). The RAM can also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0065] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0066] The processing unit executes the various methods and processes described above, such as method steps S01 to S04. For example, in some embodiments, method steps S01 to S04 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of method steps S01 to S04 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute method steps S01 to S04 by any other suitable means (e.g., by means of firmware).

[0067] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0068] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0069] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0070] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the invention. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0071] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for segmented random encryption and upgrade of firmware in embedded devices, characterized in that, The method includes: Step S01: Generate firmware overall segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segment index and segment index offset of each segment. Step S02: A multi-type encryption algorithm pool is pre-set to randomly assign encryption algorithms to each segment. The dynamic factor is concatenated and hashed to obtain the actual independent key for each segment. Each segment is encrypted independently, and the encryption algorithm pool index and encryption key metadata corresponding to each segment are stored. Step S03: Reassemble the encrypted segments into a complete ciphertext firmware in the original order, and attach the encryption algorithm pool index and encryption key metadata to finally generate the encrypted firmware ciphertext.

2. The method for segmented random encryption and upgrade of embedded device firmware according to claim 1, characterized in that, The number and boundaries of the segments mentioned in step S01 are dynamically determined by a cryptographically secure random number generator, whose random factor comes from the system entropy source, and the number of segments is adapted to the storage block size of the embedded device.

3. The method for segmented random encryption and upgrade of embedded device firmware according to claim 1, characterized in that, The length of the segments mentioned in step S01 is dynamically adjusted using a formula: Segment_Length=Base_Length+Rand()%Max_Variation, Where Base_Length is the preset base length, Max_Variation is the maximum random offset, and Rand() is a cryptographically secure random number generated based on the hardware entropy source.

4. The method for segmented random encryption and upgrade of embedded device firmware according to claim 1, characterized in that, The pre-set multi-type encryption algorithm pool mentioned in step S02 randomly assigns encryption algorithms to each segment, and its random factor generation formula is: Algorithm_Index= Rand()%Pool_Size, The Rand() function returns a cryptographically secure random number generated based on a hardware entropy source, and Pool_Size represents the number of currently valid algorithms in the algorithm pool.

5. The method for segmented random encryption and upgrade of embedded device firmware according to claim 1, characterized in that, The dynamic factors mentioned in step S02 include: random number seed, segment number, segment index offset, and time quantization parameter. Calling Rand() obtains a real-time 32-bit random number. The hardware random number generator RNG generates a 32-bit true random number seed by simulating a noise source. The current segment number Segment_Index of the firmware's random segmentation is passed in as the key parameter; The segment index offset Segment_Offset of the firmware's random segmentation is passed in as a key parameter; Obtain the time quantization parameter Time_Quant, a 64-bit data. The first 32 bits are the number of seconds since 1900, and the last 32 bits are the fractional part of the seconds. The time quantization parameter is split into two 32-bit fields in big-endian order. The higher field represents the integer part of seconds, and the lower field represents the fractional part of microseconds. Both are then cyclically shifted with the base obfuscation value.

6. The method for segmented random encryption and upgrade of embedded device firmware according to claim 1, characterized in that, The specific steps of step S03 are as follows: each encrypted segment of ciphertext is concatenated byte-level while maintaining its original order. During the concatenation process, a structured metadata header is inserted. The metadata header adopts a fixed-length design and includes the following key fields: firmware version identifier, global timestamp, total number of segments, algorithm index array for each segment, key checksum for each segment, and integrity check code.

7. The method for segmented random encryption and upgrade of embedded device firmware according to claim 1, characterized in that, The method also includes step S04: during the decryption phase, the device reads the metadata header in a fixed format, decrypts it segment by segment according to the segment information, and reassembles the decrypted legitimate data into complete plaintext firmware according to the segment index.

8. A device for segmented random encryption and upgrade of firmware for embedded devices, characterized in that, The device implements the method as described in any one of claims 1 to 7, comprising: Firmware segmentation module: used to generate overall firmware segmentation rules based on function entry address offset, generate data segments based on data structure boundary identifiers, segment the firmware, and record the segment index and segment index offset of each segment; Segmented encryption module: It is used to pre-set multiple types of encryption algorithm pools to randomly assign encryption algorithms to each segment, concatenate dynamic factors and perform hash operation to obtain the actual independent key of each segment, encrypt each segment independently, and store the encryption algorithm pool index and encryption key metadata corresponding to each segment. Encryption integration module: used to reassemble the encrypted segments into a complete ciphertext firmware in the original order, and to attach the encryption algorithm pool index and encryption key metadata, and finally generate the encrypted firmware ciphertext; Decryption module: Used during the decryption phase, the device reads the metadata header in a fixed format, decrypts it segment by segment based on the segment information, and reassembles the decrypted legitimate data into complete plaintext firmware according to the segment index.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images