Compression of firmware updates

Abstract

Compression of firmware updates. A system and method for creating firmware patch files is disclosed. The method utilizes the executable linkable format files created when the firmware image is created. By analyzing the ELF files, the patch creation software is able to identify functions and other data in the new firmware image. The patch creation software then compares these functions to the corresponding functions in the old firmware image. The method then creates an edit sequence that can be used to transform the old firmware image into the new firmware image. The edit sequence is then converted into a series of opcodes, where each opcode is followed by at least one parameter. The patch program deployed on the network device is able to apply the patch file to update its firmware. The method creates patch files that are smaller than other popular tools.

Description

[0001] This disclosure describes systems and methods for compressing firmware updates, particularly for devices communicating using low-bandwidth networks. Background Technology

[0002] Many devices, including those with programmable processors, benefit from software or firmware updates. Updates are useful, for example, when developing new features or fixing issues in the current revision. These updates were initially targeted at computers such as servers, desktop computers, and laptops. However, over time, more devices are taking advantage of these upgrades. For example, the operating system used in mobile phones, and the applications residing on those phones, are typically updated.

[0003] In some embodiments, the device being updated communicates over a low-bandwidth network. In these embodiments, the size of the firmware or software update is critical, as large updates may utilize unacceptable amounts of network bandwidth.

[0004] Many programs only transmit the differences between previous and newer versions, rather than the entire software image. The idea is that, for updates, the software doesn't change much between versions compared to a new major release, so the increment is small compared to a full image. It's then advantageous to transmit only that increment and construct the new image on the receiving end by applying that increment to the old image. This allows for compression of an order of magnitude (i.e., 10% of the full binary size). The file containing the differences, along with any processing instructions needed to generate the new binary from the old binary and the differences, is often called a patch file, and the action of constructing the new binary is often called applying the patch.

[0005] Several software programs exist that are commonly used to create these firmware patch files. For example, bsdiff is a program commonly used to create patches and apply them to binary files. Google has also created a compression algorithm called Courgette, which reduces the size of Google Chrome updates.

[0006] Despite the existence of these compression algorithms, there remains an unmet need for new methods for creating and applying firmware patches.

[0007] For example, Bluetooth defines a mesh protocol with a sustained bandwidth of less than 10 kilobytes per second. At these bandwidths, reducing the size of firmware patch files is crucial. Furthermore, in the case of embedded systems, available resources such as computing speed and available memory are far scarcer compared to other devices such as personal computers.

[0008] Therefore, it would be beneficial if there were a system and method for compressing and applying patches to remote devices, especially those remote devices including embedded systems wirelessly connected via low-bandwidth networks. Summary of the Invention

[0009] A system and method for creating firmware patch files are disclosed. The method utilizes an executable, linkable format file (ELF file) created during firmware image creation. By analyzing the ELF file, patch creation software can identify functions and other data in the new firmware image. The patch creation software then compares these functions with corresponding functions in the old firmware image. The method then creates an edit sequence that can be used to transform the old firmware image into the new firmware image. The edit sequence is then converted into a series of opcodes, each followed by at least one parameter. Patchers deployed on network devices can apply the patch file to update their firmware. This method creates patch files that are smaller than those created by other popular tools.

[0010] According to one embodiment, a method for creating a patch file that transforms an old firmware image into a new firmware image is disclosed. The method includes analyzing an ELF (Executable Linkable Format) file associated with the new firmware image to identify functions within the new firmware image; matching the functions in the new firmware image with corresponding functions in the old firmware image; identifying differences between the functions in the new firmware image and their corresponding functions in the old firmware image; creating an edit sequence based on the differences; converting the edit sequence into a set of opcodes, each opcode including at least one parameter; and repeating the matching, identifying, creating, and transforming steps for each function in the new firmware image. In some embodiments, the matching function includes: identifying the name of a function from the ELF file and searching for the same name in the ELF file associated with the old firmware image. In some embodiments, the matching function includes: finding the Levenshtein edit distance between each function in the new firmware image and each function in the old firmware image; and selecting the function with the shortest Levenshtein edit distance in the old firmware image. In some embodiments, the matching function includes: determining the Hamming distance between functions in the new firmware image and all functions of the same length in the old firmware image; and selecting the function with the shortest Hamming distance in the old firmware image. In some embodiments, creating an edit sequence includes: calculating a Wagner-Fischer matrix between functions in the new firmware image and their corresponding functions in the old firmware image; and creating a sequence of edit steps based on this matrix. In some embodiments, the edit steps are selected from a group consisting of no change, addition, replacement, and deletion. In some embodiments, the opcode set is selected from a group consisting of replacement (SUB), addition (ADD), skip (SKIP), deletion (DEL), set (SET), distinguish (DIFF), and copy (COPY). In some embodiments, the DIFF opcode replaces a data entity in the old firmware image with a new value defined relative to the data entity in the old firmware image. In some embodiments, the opcode length is determined based on its frequency of occurrence in the patch file. In some embodiments, the method further includes locating inactive regions in the new firmware image, including padding characters, object symbols, read-only data, and other binary data. In some embodiments, an ELF file is used to locate object symbols in the new firmware image and their corresponding object symbols in the old firmware image, and the object symbols and their corresponding object symbols are compared to identify differences, which are used to create the edit sequence. In some embodiments, similarity is located by comparing read-only data with other binary data by finding the longest common substring (LCS), and the longest common substring is used to create an edit sequence, which is then converted into a set of opcodes.In some embodiments, the lengths of read-only data and other binary data in the new firmware image are compared with the lengths of read-only data and other binary data in the old firmware image. If the lengths are the same, a Hamming edit distance is determined, and if the Hamming edit distance is small, an edit sequence is generated. In some embodiments, if the Hamming edit distance is large, the entire read-only data and other binary data is replaced in the patch file. In some embodiments, the patch file further includes a dictionary comprising multiple entries, and at least one parameter following one or more opcodes in the opcode set for accessing entries in the dictionary. In some embodiments, the at least one parameter includes a pointer for indexing into a list of addresses, and the addresses are used to identify a location within the dictionary. In some embodiments, the dictionary is organized according to the length of each entry, such that a first number of entries are reserved for values ​​of a first length, and a second number of entries are reserved for values ​​of a second length. Attached Figure Description

[0011] For a better understanding of this disclosure, reference is made to the accompanying drawings, wherein like elements are designated by like numbers, and wherein: Figure 1 This is a block diagram of a network device that can be used to apply firmware patches; Figure 2 This diagram illustrates the distribution of firmware patch files to multiple network devices. Figure 3 The process sequence for creating a firmware patch file according to one embodiment is shown; Figure 4A Representative functions are shown; Figure 4B The binary representation of this function in the old firmware image is shown; Figure 4C The binary representation of this function in the new firmware image is shown; and Figure 5 The process sequence for applying firmware patch files according to one embodiment is shown. Detailed Implementation

[0012] Figure 1 A network device that can be used to apply firmware patch files is shown. These firmware patch files can be transmitted via a wireless network.

[0013] Network device 10 has a processing unit 20 and an associated memory device 25. The processing unit 20 can be any suitable component, such as a microprocessor, embedded processor, application-specific circuitry, programmable circuitry, microcontroller, or other similar device. The memory device 25 contains instructions that, when executed by the processing unit 20, enable the network device 10 to perform the functions described herein. The memory device 25 can be non-volatile memory, such as flash ROM, electrically erasable ROM, or other suitable devices. In other embodiments, the memory device 25 can be volatile memory, such as RAM or DRAM. The instructions contained within the memory device 25 can be referred to as software programs and are set on a non-transitory storage medium.

[0014] Network device 10 also includes a network interface 30, which may be a wireless network interface including an antenna 37. Network interface 30 may support any wireless network protocol that supports firmware update protocols, such as Bluetooth and Bluetooth mesh. Network interface 30 is used to allow network device 10 to communicate with other devices configured on network 39.

[0015] Network device 10 may include a second memory device 40. Data received from or to be transmitted via network interface 30 may also be stored in the second memory device 40. The second memory device 40 is conventionally volatile memory.

[0016] Although memory device 25 is disclosed, these instructions can be stored on any computer-readable medium. For example, read-only memory (ROM), random access memory (RAM), magnetic storage devices such as hard disk drives, or optical storage devices such as CDs or DVDs can be used. Furthermore, these instructions can be downloaded to memory device 25, for example, via a network connection, via a CD-ROM, or via another mechanism. These instructions can be written in any programming language, which is not limited to this disclosure. Therefore, in some embodiments, multiple computer-readable non-transitory media containing the instructions described herein may be present. Figure 1 As shown, the first computer-readable non-transitory medium can communicate with the processing unit 20. The second computer-readable non-transitory medium can be a CD-ROM or a different memory device located remotely from the network device 10. Instructions contained on the second computer-readable non-transitory medium can be downloaded to the memory device 25 to allow the network device 10 to execute the instructions.

[0017] Although the processing unit 20, memory device 25, network interface 30 and second memory device 40 are in Figure 1 These are shown as separate components, but it should be understood that some or all of these components can be integrated into a single electronic component. Conversely, Figure 1This is used to illustrate the functionality of network device 10, not its physical configuration.

[0018] Although not shown, the network device 10 also has a power source, which may be a battery or a connection to a permanent power source such as a wall power outlet.

[0019] Figure 2 A network including one or more network devices 10 is shown, such as in Figure 1 The network shown is a Bluetooth mesh network. In this embodiment, the network protocol allows multicast message delivery. Essentially, network device 10 can transmit messages to a specific address. This action can be called publishing. Additionally, network device 10 can optionally receive messages transmitted to a specific address. This action is called subscribing. Thus, multiple network devices 10 can subscribe to a specific address and simultaneously receive packets sent to that address.

[0020] Additionally, in some embodiments, a special protocol can be used to push firmware updates to network devices 10 in the network via multicast over an existing Bluetooth mesh network. In other words, several identical network devices can be updated in a single transaction. Therefore, multicast firmware update utilities can be used more efficiently for updating large networks of identical network devices compared to updating devices individually.

[0021] Therefore, a network device can transmit firmware updates to an address. All network devices 10 eligible to perform this update can subscribe to that address.

[0022] While the Bluetooth mesh protocol has been described above, other wireless network protocols can benefit from the systems and methods described herein.

[0023] The system and method for compressing firmware updates take advantage of the fact that new updates and previous versions are often very similar. Therefore, this system and method analyze the differences between the two versions and create patch files that describe these differences.

[0024] The mechanism for creating patch files involves multiple processes. The sequence of these processes is as follows: Figure 3 The mechanism for applying this patch file is shown in the diagram and described below. The specific mechanism will be described later.

[0025] Software that creates patch files can be called patch creation software. This software can reside on one of the network devices, such as... Figure 2 The network device is shown in the diagram. In other embodiments, the patch creation software may reside on another device, such as a server or personal computer. In all these embodiments, the patch creation software includes instructions exposed on a non-transitory storage medium that allow a processing unit on the device to execute them. Figure 3The process is illustrated. The patch creation software operates on two revisions of the firmware image—the old firmware image and the new firmware image.

[0026] First, it's important to note that firmware images typically include the actual firmware code as well as other constant values. The terms "firmware image," "binary," and "binary file" are synonyms.

[0027] Firmware code is typically divided into multiple functions, each performing a specific operation. When the code is compiled, an ELF (Executable and Linkable Format) file is created. An ELF file includes a header, a program header table, a section header table, the actual code, and any symbols. An ELF file can include function names and locations, symbol names and locations, and attributes for all information.

[0028] In many cases, functions do not change significantly between revisions. For example, in some embodiments, the jump position within a function may change due to the addition or removal of instructions elsewhere in the firmware image. Furthermore, in some embodiments, one or more instructions may be added to or removed from a function. Therefore, in many scenarios, the differences in functions between two firmware revisions may be relatively small.

[0029] like Figure 3 As shown in box 300, in some embodiments, ELF sections in both files are enumerated, and sections that contribute to the construction of the firmware image are read by the patch creation software. These ELF sections are typically text sections (program code) and data sections (program data), but other sections, such as bootloader sections or firmware signature sections, may also be present. Additionally, sections that do not contribute to the construction of the firmware image but can provide data for analysis are read in. These typically include symbol tables and any debug sections.

[0030] The primary method is to use symbol table information to partition sections containing program code into ranges. Debugging information can also be used. Control flow and data flow analysis of the program code can also be used to provide further information. The purpose of partitioning is to determine which parts of a section are the actual program code, which parts are read-only data, which parts are meaningless padding characters, and which parts are other data that need to be retained, as well as to prepare a mapping between ranges in the old firmware and ranges in the new firmware that represent the same entities (such as specific program functions).

[0031] Once the segment is partitioned into ranges and the role of each range is determined, the similarity between the old and new firmware images is analyzed. This analysis can be performed using several methods, including but not limited to: • Symbol table information (such as symbol name and symbol length, which is the number of bytes a symbol spans in the firmware image) Hamming distance between regions of equal length in the old and new firmware • Levenshtein distance or some other edit distance between the old and new firmware regions The longest common substring between the old and new firmware regions • Code structure analysis (basic block comparison) and data flow analysis of program functions in old and new firmware. If two functions that take the same input produce the same output, they are identical regardless of whether the instruction sequences used to make them are the same.

[0032] These technologies are described in more detail below.

[0033] like Figure 3 As shown in box 310, one procedure is to identify common functions between two firmware revisions. This can be performed in several ways. In some embodiments, the patch creation software identifies function names in the ELF file of the new firmware image. The patch creation software then attempts to find the same function names in the ELF file of the older firmware image. This procedure can be used when the function names do not change between successive revisions of the firmware image.

[0034] In another embodiment, the patch creation software can use an ELF file to identify the location of functions within the image. The patch creation software can then attempt to identify functions in the new firmware image. The patch creation software then analyzes all functions in the old firmware image, searching for the function most similar to a function in the new firmware image. In some embodiments, the patch creation software calculates the Levenshtein edit distance between each function in the new firmware image and each function in the old firmware image. It is assumed that a function in the old firmware image with a smaller Levenshtein edit distance is the same as a function in the new firmware image. In another embodiment, if the function lengths are the same, Hamming distance can be used to determine the function in the old firmware image that corresponds to a function in the new firmware image.

[0035] Regarding the technology used, repeat this process for all functions in the new firmware image (box 310).

[0036] Note that if a new function has already been added to the new firmware image, the above process may incorrectly identify a function in the old firmware image as the same function because it has the smallest Levenshtein edit distance. However, this may be acceptable because it still allows the creation of compressed patch files.

[0037] Once each function in the new firmware image matches a function in the old firmware image, the differences between the functions can be identified, such as... Figure 3As shown in box 320. First, the Wagner-Fischer matrix can be calculated between functions in the two firmware images. Once the matrix is ​​created, the sequence of individual editing steps can be determined. These editing steps are as follows: - No changes were made to the data entity; - Add new data entities; - Delete data entities; and - Replacement of data entities.

[0038] Data entities can be of any desired size, such as bytes (8 bits); 16-bit words; or 32-bit words. In some embodiments, data entities may be assumed to be 16-bit words.

[0039] As a simple example, the edit sequence to transform the word "lemons" into the word "lemonade" would be as follows: (The "l" remains unchanged) The "e" remains unchanged. The "m" remains unchanged. The "o" remains unchanged. For "n" there is no change, Replace "s" with "a". Add "d", Add "e").

[0040] The edit sequence can then be compressed to group consecutive similar edits together. For example, the edit sequence above can be compressed as follows: (No change was made to "lemon") Replace "s" with "a". Add "de").

[0041] Therefore, in the best-case scenario where the function remains unchanged in the new firmware image, the edit sequence is simply a non-modifying edit that spans the entire function.

[0042] In the worst-case scenario, the function may not exist in the old firmware image. In this case, the edit sequence will be an add-in edit sequence that includes the entire new function.

[0043] In other embodiments, new functions are generated using replacement, addition, and / or deletion edit sequences.

[0044] As noted above, in some embodiments, the only change to a function might be the jump destination address. In these embodiments, the edit sequence may include a set of unchanged edits interleaved with replacement edits.

[0045] More complex changes could lead to all four types of editing.

[0046] Then, the patch creation software can save all the edit sequences that have been created, such as... Figure 3 As shown in box 330.

[0047] Next, as Figure 3 As shown in box 340, the patch creation software may attempt to identify differences in non-function regions of the firmware image. For example, the firmware image may include regions containing padding characters, object symbols, read-only data, and other binary data. Each of these types of information will be described below.

[0048] Padding bytes can be easily handled by recording edit sequences used to add multiple empty (zero-value) bytes, or, in cases where both the old and new versions of the padded symbol have the same amount of padding bytes, they can be treated as part of the symbol content, even if they are not technically. If the number of padding bytes differs between two firmware images, edit sequences including "add" or "delete" can be used.

[0049] Symbolic objects can be processed as follows. First, as mentioned above, the ELF file can include links to all symbols in the firmware image. Therefore, patch creation software can analyze the ELF files of both the new and old firmware images to locate each symbol. These symbols can then be compared, for example, using the techniques described above. Thus, a Wagner / Fisher matrix can be created, and edit sequences can be created from this matrix.

[0050] Read-only data and other binary data can be handled in a similar way. Read-only data and other binary data typically represent regions within the firmware image that are not referenced by the symbol table. This data, lacking any symbol information, will likely have a large area that perfectly matches similar data in older firmware images.

[0051] Finding substring matches using any known method for finding the longest common substring (LCS) between new and old firmware images can be used to locate similarities.

[0052] In one embodiment, finding these similarities follows a divide-and-conquer pattern. Assume the old firmware image string is named O, and the binary data region considered in the new firmware image can be named N. The patch creation software can then proceed as follows: First, find the LCS between O and N; L = LCS(O, N) If L does not exist, the process is complete; (N needs to be added as new data). • If L == N, then the process is complete; (N can be a sequence of copy-edited data from the old data) Otherwise, remove L from N. This falls into one of three possible situations: If N begins with L, then N becomes the part remaining after removing the prefix L. If N ends with L, then N becomes the part remaining after removing the suffix L. Otherwise, if L is in the middle of N, the patch creation software needs to consider two substrings of N: the part before L and the part after N. Repeat this process for one or two substrings of N.

[0053] Because of LCS matching, edit sequences will always exist. For example, LCS matching may not be ideal for all cases because LCS does not handle substitutions in otherwise identical data. For instance, LCS matching inefficiently handles scenarios where "abcdeFgHijkl" is replaced by "abcdefghijkl". In such scenarios, LCS matching will identify "abcde" but will look further into the text to match "F", thus creating complex patch files. Edit sequences from such cases can easily become unnecessarily complex chains of fragments.

[0054] Alternatively, it can be determined that the data blocks in the old firmware image are the same length as the corresponding data blocks in the new firmware image. This can be done by checking for segments of matching size in the two ELF files. If the blocks are the same length, the patch creation software can alternatively determine whether the Hamming edit distance between the two blocks is small. If so, it can be very beneficial to record the differences as an edit sequence containing changes to the same parts and replacements of unchanged edit steps. In other embodiments, this is not performed. If the Hamming edit distance is large, the patch creation software may choose to simply replace the entire data block.

[0055] Furthermore, if LCS matching of a data block does not produce sufficient results—for example, if there is no substring long enough to generate a meaningful compressed substring—the patch creation software may choose to simply replace the entire data block.

[0056] Therefore, using these techniques, patch creation software can determine the editing sequence of all non-functional data, such as Figure 3 As shown in box 350.

[0057] The previous description disclosed a system and method for detecting differences between two firmware images and creating an edit sequence that fully describes these differences.

[0058] Next, as Figure 3As shown in box 360, the patch creation software uses the edit sequence created as described above to create a patch file to be applied. The patch file includes multiple opcodes, each with associated parameters. Several observations were made during the creation of these opcodes. These observations are noted below: The program code constitutes the main body of the firmware binary file. Within program code, functions that allow changing jump destinations are the most common. Functions that remain unchanged except for possible relocations are also common. o Any other changes are very rare The program data constitutes a small portion, but it may be worth optimizing. The unchanged parts constitute the main body of the program data.

[0059] Based on these observations, the opcodes used in the patch file can be optimized.

[0060] Furthermore, it's worth noting that functions with changed jump destinations are very common. For example, functions in... Figure 4A As shown in the diagram. This function is used to initialize the application. It loads values ​​into the selection register and then jumps twice to another function called GPIO_PinModeSet. This function also jumps to a function called configEnablePti.

[0061] Figure 4B The binary representation of this function in the old firmware image is shown. Figure 4C The binary representation of this function in the new firmware image is shown.

[0062] Note that, apart from the jump positions, these two functions are very similar. Specifically, position 0x00bab8 changes from 0xfdbd to 0xfda7; position 0x00bac4 changes from 0xf949 to 0xf937; and position 0x00bad4 changes from 0xb941 to 0xb92f.

[0063] This type of modification is common, and therefore, the opcodes used for patch files can be optimized for these types of modifications. For example, when the value at position 0x00bab8 is changed to fda7 (a 16-bit entity), it is very similar to the previous value (i.e., 0xfdbd - 0xfda7 = 0x16). Note that the difference lies only in the 8-bit entity. Therefore, in some embodiments, in addition to the substitution (or replacement) edit sequence, there may be a difference edit sequence where the new value is equal to the old value plus (or minus) the offset.

[0064] The following is a list of opcodes that can be used to create patch files. These can include: - SUBST (replace) -DIFF (Difference) -ADD (Add) -COPY (copy) -DEL (Delete) -SKIP (skip); and -SET (Settings).

[0065] These opcodes, or subsets of them, can be used to create patch files. Each is described in more detail below.

[0066] SUBST is used to replace one or more data entities from an older firmware image with new values. These new values ​​can be included as parameters immediately following the opcode. In another embodiment, the patch file may include a dictionary storing various entries that the opcode can use. For example, the parameter associated with the SUBST opcode may be a pointer to the dictionary. The entry at that position in the dictionary is a string of values ​​that should be used to replace the values ​​in the older firmware image. The length of the strings in the dictionary can be determined using various methods, as described in more detail below. In yet another embodiment, all the data to be replaced is stored in a contiguous region of data. In this embodiment, the parameter following the opcode may indicate the number of data entities from the data region to be replaced. The system may also maintain a pointer to the next data entity to be used in that region. Thus, after the SUBST opcode is executed, the system moves the pointer to different data entities in the region. Optionally, the contiguous region of data may be compressed.

[0067] DIFF is a variant of SUBST. However, instead of replacing the value in the old firmware image with the new value, it replaces the value with a value defined relative to the old value. For example, suppose the value in the old firmware image is 0x20, and the new value is 0x36. Using the SUBST opcode, the parameter following the opcode would be 0x36 (i.e., the new value). Using the DIFF opcode, the parameter following the opcode would be 0x16 (i.e., the difference between the old and new values). This opcode can be useful for jump instructions where the jump destination address has been modified, as the difference between the two jump destination addresses is often smaller than the actual value of the jump destination address. Additionally, if a function has multiple jump instructions, the probability that the differences between the old and new destinations of these jump instructions are the same is much higher than when absolute addresses are used. This allows a single dictionary entry to be used for multiple instances.

[0068] ADD is used to insert one or more data entities into a new firmware image. These new data entities can be included as parameters immediately following the opcode. In another embodiment, the patch file may include a dictionary storing various entries that the opcode can use. For example, the parameter associated with the ADD opcode may be a pointer to the dictionary. The entry at that position in the dictionary is a string of values ​​that should be added to the new firmware image. In yet another embodiment, as described above, all the data to be added can be stored in a contiguous region of data. In this embodiment, the parameter following the opcode may indicate the number of data entities to be added from the data region. The system may also maintain a pointer to the next data entity to be used in that region. Optionally, the contiguous region of data can be compressed. In some embodiments, the data used for replacement and the data used for addition can be stored in the same contiguous data region.

[0069] COPY is used to copy one or more data entities from an old firmware image to a new firmware image. The number of data entities to be copied can be a parameter that follows the opcode.

[0070] DEL is used to remove one or more data entities from an old firmware image. The number of data entities to be deleted can be a parameter that follows the opcode.

[0071] SKIP can be a special variant of ADD, where the value to be added is zero. In this case, the parameter following the opcode can indicate the number of data entities to be added. This can be helpful for populating a new firmware image.

[0072] SET can be used to manipulate pointers associated with older firmware images. For example, when creating a new firmware image, there are two pointers: one associated with the new firmware image (i.e., a pointer to where new data will be written) and one associated with the older firmware image (i.e., a pointer to where old data will be read). Each of the above opcodes manipulates at least one of these pointers.

[0073] For example, the SUBST opcode advances both pointers by a value equal to the number of data entities to be replaced. Similarly, the DIFF and COPY opcodes advance both pointers by the same value. The ADD opcode increments the pointer associated with the new firmware image but does not affect the pointer associated with the old firmware image. Similarly, SKIP increments the pointer associated with the new firmware image but does not affect the pointer associated with the old firmware image. Conversely, the DEL opcode increments the pointer associated with the old firmware image but does not affect the pointer associated with the new firmware image. The SET opcode manipulates the pointer associated with the old firmware image without affecting the pointer associated with the new firmware image.

[0074] For example, when data has been deleted, the SET opcode can be used to avoid copying data from the old firmware image by simply moving the pointer over the data entity to be deleted. For instance, suppose the old firmware image contains the string "the quickbrown fox" and the new firmware image will contain "the quick fox". The SET opcode can be used as follows: COPY(9) (i.e., "the quick"); SET (+6) (i.e., skip "brown"); COPY(3) (i.e., "fox").

[0075] Therefore, in some embodiments, the use of the SET opcode can lead to redundancy of the DEL opcode.

[0076] The SET opcode can also be used when data in a new firmware image is reordered from that in an old firmware image. Using the example above, suppose the new firmware image will include "the brown quick fox". The SET opcode can be used as follows: COPY(4) (i.e., "the"); SET (+6) (i.e., skip "quick"); COPY(6) (i.e., "brown"); SET (-12) (that is, returns a pointer to "quick"); COPY(6) (i.e., “quick”); SET (+6) (i.e., skip "brown"); and COPY(3) (i.e., "fox").

[0077] As previously described, in some embodiments, a dictionary can be used. A dictionary is a list of entries containing values ​​that an opcode can use. For example, if a function has been relocated by N bytes, some or all of its jump destination addresses may have been changed by N bytes. Therefore, instead of using the actual jump destination addresses in multiple SUBST commands, it can be more space-efficient to define dictionary entries that include the new jump destination addresses and have each SUBST opcode reference that dictionary entry.

[0078] A dictionary can be organized in several ways. In one embodiment, each pointer contained in the instructions is used to index a list of addresses, where each address is of fixed length. For example, suppose each address is 4 bytes long. Thus, the pointer in the instructions acts as an index to that list. For example, the value of the pointer could be multiplied by 4 (since each address is 4 bytes long) and added to the starting address of the dictionary. The 4-byte value at that location is the address of the entry in the dictionary.

[0079] In another embodiment, the dictionary is organized according to the length of each entry. For example, a first number of entries can be reserved for values ​​that are 2 bytes long. A second number of entries can be reserved for values ​​that are 4 bytes long. If the first and second numbers are known, the software can easily convert the entry numbers into actual addresses.

[0080] Return to reference Figure 4B and Figure 4C This shows two versions of the function. Creating a patch file for this new version from an older version might look like this: COPY(2) <<Copy two data entities (4 bytes)>> DIFF (-0x016) << Replace 0xfdbd with 0xfda7 >> COPY (5) <<Copy five data entities>> DIFF (-0x012) << Replace 0xf949 with 0xf937 >> COPY (7) <<Copy five data entities>> DIFF(-0x012) << Replace 0xb941 with 0xb92f >>.

[0081] Note that in this example, both replacements require the same difference value (i.e., -0x012). Therefore, in some embodiments, it may be advantageous to create a dictionary entry with this value and have the DIFF opcode point to that entry. For example, if the dictionary entry is used for the DIFF opcode, the patch file above could be rewritten as: COPY(2) <<Copy two data entities (4 bytes)>> DIFF(@1) << Replace 0xfdbd with 0xfda7 >> COPY (5) <<Copy five data entities>> DIFF(@2) <<Replace 0xf949 with 0xf937>> COPY (7) <<Copy five data entities>> DIFF(@2) << Replace 0xb941 with 0xb92f>>.

[0082] In this example, the first entry in the dictionary (i.e., @1) is -0x016, and the second entry (i.e., @2) is -0x012. Assuming each dictionary entry is used more than once, this technique may be more space-efficient than using the actual value as the parameter.

[0083] Several opcodes that can be used to create patch files have already been defined; the next step is to create encodings for these opcodes. Specifically, it may be beneficial to encode some of the most frequently used opcodes as 1-byte instructions. Less frequently used opcodes can be encoded as two-byte or more instructions.

[0084] Research on several firmware versions has led to the empirical finding that copying and replacing (in the form of differences) is likely the most commonly used editing sequence.

[0085] Therefore, in one embodiment, the patch creation software utilizes two variants of the COPY and DIFF opcodes. For example, one variant of the COPY instruction can be one byte in length and can be used to copy up to 64 data entities. A second variant of the COPY instruction can be more bytes in length and can be used to copy more than 1000 data entities.

[0086] Similarly, there might be a 1-byte variant of the DIFF instruction that can index into the first 64 or 128 entries of the dictionary. A second variant of the DIFF instruction could be two bytes in length and index into the first 2048 entries of the dictionary.

[0087] In one embodiment, the following opcode can be used: - COPY (short variant) - COPY (long variant) - DIFF (short variant) - DIFF (long variant) - ADD - SUBST - SET -SKIP.

[0088] In some embodiments, the length of each opcode is determined based on its frequency of occurrence in the patch file. For example, the COPY and DIFF opcodes may be very common and therefore may have the shortest opcode length. In some embodiments, the shortest opcode length may be one byte. However, if desired, it may have a shorter opcode length, such as a fraction of bytes.

[0089] Therefore, once the patch creation software is complete, the result will be the patch files needed to transform the old firmware image into the new firmware image.

[0090] The patch file includes an instruction set, which consists of opcodes and associated parameters. The patch file may also include a dictionary. In some embodiments, as described above, the patch file may include contiguous regions of data.

[0091] In some embodiments, patch files can be compressed using a general compression algorithm to further reduce their size. Once the patch file is created and optionally compressed, it can be transmitted to other network devices. In one embodiment, the patch is created on a computer, unlike... Figure 2 The computer can be a personal computer, laptop computer, server, or any other suitable device, as shown in the diagram. Furthermore, the computer may include a processing unit and associated memory, where instructions for creating the patch are set. Once the computer has created the patch file, it is delivered to a network device within the network. The network device then uses a firmware update utility to multicast the new patch file to other network devices.

[0092] Each network device includes a software program called a patch. Patches use patch files transferred along with the current firmware image to create new firmware images.

[0093] Figure 5 The process of applying a patch file is described below. First, as shown in box 500, the patcher receives the patch file. If the computer previously compressed the patch file, it is decompressed first.

[0094] As shown in box 510, the patch reserves a memory segment large enough to hold the new firmware image. The starting address of this memory segment is saved as a new pointer.

[0095] The patcher then looks up a dictionary of common values ​​from the patch file and stores it in memory, as shown in box 520.

[0096] In another embodiment, the patch can locate contiguous regions of data and save them to memory.

[0097] The patch then sets a second pointer, referred to as the old pointer pointing to the starting point of the current firmware image, as shown in box 530.

[0098] Then, the patcher begins the process of creating a new firmware image, as shown in box 540.

[0099] If the opcode is the COPY opcode (short or long variant), the patch determines the number of data entities to be copied. The patch then copies that number of data entities, starting from the address pointed to by the old pointer, and stores them at the address pointed to by the new pointer. The patch then advances both pointers by that number.

[0100] If the opcode is DELETE, the patch determines the number of data entities to be deleted. The patch then increments the old pointer by that value. No changes are made to the new pointer.

[0101] If the opcode is an ADD opcode, the patcher determines the number and value of the data entities to be added. The patcher then adds these new data entities to the memory pointed to by the new pointer. The new pointer increments by the number, while the old pointer remains unaffected. In some embodiments, the data entities to be added may be listed immediately following the opcode. In another embodiment, the data entities to be added may be included in a dictionary, and the parameter following the opcode represents a pointer to that entry in the dictionary. In yet another embodiment, the data entities to be added may be stored in a contiguous region of data, and the parameter following the opcode may be an indication of the number of data entities to be added.

[0102] If the opcode is a SKIP opcode, the patch determines the number of zeros to be added. This number of zeros can be included as a parameter following the opcode. The patch then adds these zeros to the memory pointed to by the new pointer. The new pointer is incremented by this number, while the old pointer remains unaffected.

[0103] If the opcode is SET, the patch sets the old pointer to the value indicated by the instruction. No changes are made to the new pointer.

[0104] If the opcode is SUBST or DIFF, the patch determines the number of data entities to be replaced or superseded. It then writes the new data to the memory indicated by the new pointer, advancing the old pointer the same number of times. In some embodiments, the new data may be stored in a dictionary at the location indicated by the parameter following the opcode in the SUBST or DIFF instruction. In other embodiments, the new data is stored in a contiguous region of data, and the parameter following the opcode indicates the number of data entities to be superseded.

[0105] Repeat this process until the entire patch file has been processed.

[0106] The new firmware image is now ready for use, as shown in box 550.

[0107] This system and method have many advantages. As mentioned above, the purpose of this process is to create smaller patch files. To test the efficiency of this new system and method, several tests were performed. Specifically, four versions of firmware images operable on network devices were considered. The table below shows the size of the patches generated when converting older firmware images to newer firmware images. For comparison, the size of the patch files generated by bsdiff is also shown.

[0108] The specific embodiments described herein are not intended to limit the scope of the invention. In fact, various other embodiments and modifications of this disclosure will be apparent to those skilled in the art, in addition to those described herein, based on the foregoing description and drawings. Therefore, such other embodiments and modifications are intended to fall within the scope of this disclosure. Furthermore, although this disclosure has been described herein in the context of a specific implementation in a specific environment for a specific purpose, those skilled in the art will recognize that its usefulness is not limited thereto, and that this disclosure can be advantageously implemented in any number of environments for any number of purposes. Therefore, the claims set forth below should be interpreted in light of the full scope and spirit of this disclosure as described herein.

Claims

1. A method for creating a patch file that transforms an old firmware image into a new firmware image, comprising: Analyze the executable and linkable format files associated with the new firmware image to identify functions within the new firmware image; Match the functions in the new firmware image with the corresponding functions in the old firmware image; Identify the differences between functions in the new firmware image and their corresponding functions in the old firmware image; An edit sequence is created based on the differences; Convert the edit sequence into a set of opcodes, each opcode including at least one parameter; and For each function in the new firmware image, repeat the matching, identifying, creating, and transforming steps. The set of operation codes includes one or more of the following: replace, add, skip, delete, set, differentiate, and copy.

2. The method according to claim 1, wherein, Matching functions include: Identify the function name from the executable linker file and look for the same name in the executable linker file associated with the old firmware image.

3. The method according to claim 1, wherein, Matching functions include: Find the Levenshtein edit distance between each function in the new firmware image and each function in the old firmware image; and Select the function with the shortest Levenshtein edit distance from the old firmware image.

4. The method according to claim 1, wherein, Matching functions include: Determine the Hamming distance between functions in the new firmware image and all functions of the same length in the old firmware image; and Select the function with the shortest Hamming distance from the old firmware image.

5. The method according to claim 1, wherein, Creating an edit sequence includes: Calculate the Wagner-Fischer matrix between the functions in the new firmware image and their corresponding functions in the old firmware image; and Create an editing step sequence based on the matrix.

6. The method according to claim 5, wherein, Editing steps include one or more of the following: no change, addition, replacement, and deletion.

7. The method according to claim 1, wherein, The distinguishing opcode replaces the data entity in the old firmware image with a new value defined relative to the data entity in the old firmware image.

8. The method according to claim 1, wherein, The opcode length is determined based on its frequency of occurrence in the patch file.

9. The method of claim 1, further comprising locating non-functional regions in the new firmware image, said regions including padding characters, object symbols, read-only data, and other binary data.

10. The method according to claim 9, wherein, An executable linkable format file is used to locate object symbols in a new firmware image and corresponding object symbols in an old firmware image, wherein the object symbols and corresponding object symbols are compared to identify differences, and the differences are used to create an edit sequence.

11. The method according to claim 9, wherein, Similarity is determined by comparing read-only data with other binary data by finding the longest common substring, and the longest common substring is used to create an edit sequence, which is then converted into a set of opcodes.

12. The method according to claim 9, wherein, The lengths of read-only data and other binary data in the new firmware image are compared with the lengths of read-only data and other binary data in the old firmware image. If the lengths are the same, the Hamming edit distance is determined, and if the Hamming edit distance is smaller, an edit sequence is generated.

13. The method according to claim 12, wherein, If the Hamming edit distance is large, replace the entire read-only data and other binary data in the patch file.

14. The method according to claim 1, wherein, The patch file further includes a dictionary comprising multiple entries, wherein at least one parameter following one or more opcodes in the opcode set is used to access entries in the dictionary.

15. The method according to claim 14, wherein, The at least one parameter includes a pointer for indexing into a list of addresses, wherein the address is used to identify a location within the dictionary.

16. The method of claim 14, wherein, The dictionary is organized according to the length of each entry, such that a first number of entries are reserved for values ​​of a first length, and a second number of entries are reserved for values ​​of a second length.

Images