Method, System, Readable Storage Medium and Computer Device for Modifying Firmware File

By modifying the firmware file kernel section in the Internet of Things device, the problems of firmware file system corruption and inode confusion in the existing technology are solved, and a complete and unprotected shell is achieved under protection, which is of good versatility.

CN113961236BActive Publication Date: 2025-06-24HANGZHOU DBAPPSECURITY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202111205222.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-10-15
Publication Date
2025-06-24
Estimated Expiration
2041-10-15

AI Technical Summary

Technical Problem

When the existing technology breaks through the obstacles of restricted serial ports in IoT devices, it encounters problems such as algorithm version problems, file system corruption and inode confusion in squashfs and jffs2 systems, resulting in the inability to stable acquisition of a complete and unprotected shell.

Method used

By obtaining the firmware files in the device memory, extracting the kernel files, decompressing and modifying the contents of the kernel section, forming a compressed file, and synthesizing a new firmware file with the mirror header file, avoiding the parts of the boot system and file system, the kernel starts a semi-initialized shell.

Benefits of technology

It realizes stable acquisition of complete and unprotected shells under the protection set by the manufacturer, avoids the differences between multiple boot systems and file systems, and has good versatility.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113961236B_ABST
    Figure CN113961236B_ABST
Patent Text Reader

Abstract

The present invention provides a method, system, readable storage medium and computer device for modifying a firmware file. The method includes: obtaining the firmware file in the device memory and extracting the kernel file from the firmware file; decompressing the kernel file to obtain a first decompressed file; modifying the content of the kernel section in the first decompressed file to obtain a modified first decompressed file; compressing the modified first decompressed file to form a compressed file; obtaining a mirror header file and synthesizing a new firmware file with the compressed file. By modifying the kernel section of the firmware file in the kernel startup program, the present invention enables the kernel to start a semi-initialized Shell, avoiding parts of the various and greatly version-differentiated boot systems and file systems, enabling security researchers to obtain a complete and unprotected Shell; on the other hand, a method for modifying the kernel section and locating features independent of the instruction set is used, which has good versatility.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method, system, readable storage medium, and computer device for modifying firmware files. Background Art

[0002] With the improvement of manufacturers' security awareness, or merely for the purpose of code protection, the scenario of directly starting an unprotected shell on the serial port is becoming less and less common. Ways to set obstacles include not limited to setting strong password protection, starting a customized restricted shell, and directly closing the serial port. How to efficiently break through these obstacles is a problem that Internet of Things security researchers face daily.

[0003] There are now various methods to crack or bypass these restricted serial ports. The preferred solution for many researchers is to modify the shadow file. However, the complexity of the embedded system always brings some problems: The squashfs system often encounters algorithm version problems, resulting in the inability to decompress and run the internal firmware file after modification, and the generated image is larger than the original space, causing damage to the firmware file system. The jffs2 system often encounters problems with language conversion and partition alignment, often resulting in confusion in the inode of the repackaged firmware file. This also leads to the inability to stably obtain a complete unprotected shell under various protections set by manufacturers. Summary of the Invention

[0004] Embodiments of this application provide a method, system, readable storage medium, and computer device for modifying firmware files to at least solve the deficiencies in the above related technologies.

[0005] In a first aspect, embodiments of this application provide a method for modifying a firmware file, including:

[0006] Obtain the firmware file in the device memory and extract the kernel file from the firmware file;

[0007] Decompress the kernel file to obtain a first decompressed file;

[0008] Modify the content of the kernel section in the first decompressed file to obtain a modified first decompressed file;

[0009] Compress the modified first decompressed file to form a compressed file;

[0010] Obtain the image header file and synthesize it with the compressed file to form a new firmware file.

[0011] In some of these embodiments, the step of modifying the content of the kernel section in the first decompressed file to obtain a modified first decompressed file includes:

[0012] Locate the string of the kernel section in the first decompressed file;

[0013] Modify the program header of the string of the kernel section to obtain a modified first decompressed file.

[0014] In some embodiments, before the step of compressing the modified first decompressed file to form a compressed file, the method includes:

[0015] Determine whether there are initialization parameters in the modified first decompressed file;

[0016] When there are initialization parameters in the first decompressed file, mask the initialization parameters.

[0017] In some embodiments, before the step of obtaining a mirror header file and synthesizing it with the compressed file to form a new firmware file, the method further includes:

[0018] Determine the compression type of the compressed file;

[0019] When the compression type of the compressed file is the Gzip type, delete the last four bytes of the compressed file.

[0020] In some embodiments, the step of obtaining a mirror header file and synthesizing it with the compressed file to form a new firmware file includes:

[0021] Determine the mirror type of the mirror header file;

[0022] When the mirror type of the mirror header file is the compressed file type dedicated to the bootloader, add the file header dedicated to the bootloader to the compressed file to form a new compressed file;

[0023] Input the new compressed file into the mirror header file to synthesize a new firmware file.

[0024] In a second aspect, an embodiment of the present application provides a firmware file modification system, including:

[0025] An acquisition module, configured to acquire a firmware file in a device memory and extract a kernel file from the firmware file;

[0026] A decompression module, configured to decompress the kernel file to obtain a first decompressed file;

[0027] A modification module, configured to modify the content of the kernel section in the first decompressed file to obtain a modified first decompressed file;

[0028] A compression module, configured to compress the modified first decompressed file to form a compressed file;

[0029] A processing module, configured to obtain a mirror header file and synthesize a new firmware file with the compressed file.

[0030] In some embodiments, the modification module is specifically configured to:

[0031] Locate the string of the kernel section in the first decompressed file;

[0032] Modify the program header of the string of the kernel section to obtain a modified first decompressed file.

[0033] In some embodiments, the system further includes:

[0034] A first determination module, configured to determine whether there are initialization parameters in the modified first decompressed file;

[0035] A shielding module, configured to shield the initialization parameters when there are initialization parameters in the first decompressed file.

[0036] In a third aspect, an embodiment of the present application provides a readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the method for modifying a firmware file as described in the first aspect above.

[0037] In a fourth aspect, an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the computer program, it implements the method for modifying a firmware file as described in the first aspect above.

[0038] Compared with the related art, the method, system, readable storage medium, and computer device for modifying a firmware file provided by the embodiments of the present application modify the kernel section of the firmware file in the kernel startup program, so that the kernel starts a semi-initialized Shell, avoiding parts of the various and greatly version-differentiated boot systems and file systems, enabling security researchers to obtain a complete and unprotected Shell; on the other hand, a method for modifying the kernel section and locating features independent of the instruction set is used, which has good generality.

[0039] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more concise and understandable. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments and descriptions thereof of the present application are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0041] Figure 1 Flow chart of the method for modifying the firmware file in the first embodiment of the present invention;

[0042] Figure 2 Flow chart of the method for modifying the firmware file in the second embodiment of the present invention;

[0043] Figure 3 Block diagram of the structure of the system for modifying the firmware file in the third embodiment of the present invention;

[0044] Figure 4 Block diagram of the structure of the computer device in the fourth embodiment of the present invention.

[0045] Description of main component symbols:

[0046] Memory 10 Decompression module 12 Processor 20 Modification module 13 Computer program 30 Compression module 14 Acquisition module 11 Processing module 15

[0047] The following specific embodiments will further illustrate the present invention in conjunction with the above-mentioned drawings. Specific embodiments

[0048] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be described and explained below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments provided in the present application without creative efforts belong to the scope of protection of the present application.

[0049] Obviously, the drawings in the following description are only some examples or embodiments of the present application. For those of ordinary skill in the art, without creative efforts, the present application can also be applied to other similar scenarios based on these drawings. In addition, it can also be understood that although the efforts made in this development process may be complex and lengthy, for those of ordinary skill in the art related to the content disclosed in the present application, some design, manufacturing or production changes based on the technical content disclosed in the present application are only conventional technical means and should not be understood that the content disclosed in the present application is insufficient.

[0050] Referring to "embodiments" in the present application means that the specific features, structures or characteristics described in conjunction with the embodiments can be included in at least one embodiment of the present application. The phrase appears in various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those of ordinary skill in the art explicitly and implicitly understand that the embodiments described in the present application can be combined with other embodiments without conflict.

[0051] Unless otherwise defined, the technical terms or scientific terms involved in this application shall have the ordinary meanings understood by those of ordinary skill in the technical field to which this application belongs. The words such as "a", "an", "one kind", "the" and the like involved in this application do not indicate a limitation in quantity and may represent a singular or plural number. The terms "include", "comprise", "have" and any variations thereof involved in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may further include unlisted steps or units, or may further include other steps or units inherent to these processes, methods, products or devices. The similar words such as "connect", "be connected", "couple" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships may exist. For example, "A and / or B" may represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the front and rear associated objects. The terms "first", "second", "third" and the like involved in this application are only used to distinguish similar objects and do not represent a specific order for the objects.

[0052] First of all, it should be noted that:

[0053] Shell, commonly known as the shell (used to distinguish from the core), refers to the software (command interpreter) that "provides an operation interface for users". It is similar to COMMAND.COM under DOS and later cmd.exe. It receives user commands and then calls the corresponding application programs. It is relative to the kernel because it is a form presented to users based on the kernel. For example, when we see a ball, what we see is its shell, not the core. The shell in Linux refers to a command interface for users, and its manifestation is an interface that can be entered by users, and this interface can also feedback operation information.

[0054] Linux separates the kernel from the interface. It can run independently without a graphical interface and can also run a graphical desktop based on the kernel. In this way, in the Linux system, there are two forms of shell manifestation. One is the shell in the terminal running environment without a graphical interface, and the other is the MS-DOS running window similar to Windows running on the desktop. The former is generally habitually abbreviated as the terminal, and the latter is generally directly called the shell.

[0055] The shadow file refers to the shadow password file. In the Linux operating system, there is a file responsible for the passwords of all users. That is the shadow file. In Linux, the shadow file is a file that only system administrators have the right to view and modify.

[0056] The SquashFS system is a compressed read-only file system based on the Linux kernel. This file system can compress the documents, inodes, and directories within the system, and the maximum file size supported is 2^64 bytes.

[0057] The JFFS2 system is a flash memory log-based file system, and its function is to manage the log-based file system implemented on MTD devices.

[0058] The init process, with PID = 1, is the first user-level process started by the kernel and is the parent process of all subsequent processes (except for PID = 0 and PID = 2). It will complete the initialization of the system. All processes in Linux are created and run by the init process. First, the Linux kernel starts, then the init process is started in user space, and then other system processes are started. After the system startup is completed, init will become a daemon process to monitor other system processes.

[0059] For manufacturers, enabling a customized init process is a good way to protect device security. The customized init process can meet any requirements of the manufacturer, such as closing the serial port, setting only a small part of commands, etc. Even without a customized init process, modifying some content in the original init process can also achieve very effective protection.

[0060] If the init process can be modified to make Linux start a specified init process, all the protection measures taken by the manufacturer in the init process will become invalid. Therefore, based on this idea, the present invention obtains a privilege by modifying part of the kernel source code.

[0061] Embodiment 1

[0062] Please refer to Figure 1 , which shows the modification method of the firmware file in the first embodiment of the present invention. The method specifically includes steps S101 to S105:

[0063] S101, obtain the firmware file in the device memory and extract the kernel file from the firmware file;

[0064] In specific implementation, obtain the firmware file from the device memory and extract the kernel file in the firmware file. Generally, the obtained firmware file is a.bin file, so the first step is to extract its kernel file. The prerequisite for the.bin file to contain the kernel file is that the firmware must be extracted from a memory such as flash. Generally, the firmware downloaded from the manufacturer's official website does not contain the uboot and kernel files.

[0065] It can be understood that uboot is a bootloader mainly used for embedded systems and can support various different computer system architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and MicroBlaze. This is also a free software released under the GNU General Public License.

[0066] S102, decompress the kernel file to obtain a first decompressed file;

[0067] Generally, the extracted kernel file is compressed, usually in compression types such as gzip, xz, or lzma. Therefore, in specific implementation, it is necessary to determine the compression type of the kernel file. Different compression types use different compression algorithms. When the kernel file belongs to the Gzip type, it is necessary to call the Gzip compression algorithm to decompress the kernel file. When the kernel file does not belong to the Gzip type, it is necessary to call the compression algorithm corresponding to the compression type of the kernel file for decompression.

[0068] It should be noted that in this application, the compression algorithm is determined by the file header. For example, "\x1F\x8B\x08" is gzip compression, and "\x5D" is lzma compression. Then execute the gzip–cd or unlzma command (compression algorithm) for decompression.

[0069] S103, modify the content of the kernel section in the first decompressed file to obtain a modified first decompressed file;

[0070] It should be noted that through the analysis of the Linux kernel startup process, it can be found that the init process finally started by the kernel is determined by three parts.

[0071] In this application, it is necessary to directly let the kernel start / bin / sh because / bin / sh starts a relatively pure shell. In specific implementation, modify the program header " / sbin / init" in the try_to_run_init_process(" / sbin / init") parameter content of the kernel section in the first decompressed file to " / bin / sh", so that a very pure and interference-free shell can be started.

[0072] It is understandable that init is one of the indispensable programs in Linux system operations. The so-called init process is a user-level process started by the kernel. After the kernel starts itself (has been loaded into memory, starts running, and initializes all device drivers and data structures, etc.), it completes the boot process by starting a user-level program init. Therefore, init is always the first process (its process ID is always 1).

[0073] In this application, the specific location to be modified can be achieved through a location string. For example, locate "Try passing init=option to kernel". So, it only needs to locate this string in the kernel section and then find the program header at the very front of this section. Here, it may not necessarily be / sbin / init, but may also be other files written by the manufacturer. Therefore, it is necessary to locate to the very front instead of going to / sbin / init. It can be observed that these all use strings of the Linux directory structure, so regular matching can be used as the search method.

[0074] S104, compress the modified first decompressed file to form a compressed file;

[0075] In specific implementation, use the same compression algorithm as in step S102 to compress the modified first decompressed file to form a compressed file. The specific compression algorithm command can be found in the Linux kernel source code.

[0076] It should be noted that after compression through the gzip–cd command (compression algorithm), the compressed file has identification bytes of the Gzip type. Therefore, when the compression type of the kernel file in step S102 is of the Gzip type, the last 4 bytes of the compressed file need to be deleted in this step.

[0077] S105, obtain the image header file and combine it with the compressed file to form a new firmware file.

[0078] It should be noted that in this application, it is necessary to judge the image header type of the image header file. When the image header type belongs to the compression file type (UImage) dedicated to the boot loader, directly add the file header dedicated to the boot loader to the compressed file to form a new compressed file; input the new compressed file into the image header file to synthesize a new firmware file.

[0079] When the image header type belongs to the ordinary compressed kernel image file type (zImage), directly input the compressed file into the image header file to synthesize a new firmware file.

[0080] It is understandable that the zImage is the default compressed kernel image file under normal circumstances, which is obtained by compressing the kernel file and adding a section of decompression startup code. The uImage is obtained by processing the ordinary compressed kernel image file (zImage) using the tool mkimage. It is a dedicated image file for U-Boot. It adds a "header" with a length of 64 bytes before the zImage to describe information such as the version, loading location, generation time, and size of this kernel; after 0x40, it is no different from the zImage. It is necessary to add the file header of the uImage to the compressed file to achieve automated operation.

[0081] In summary, the method for modifying the firmware file in the above embodiments of the present invention, by modifying the kernel section of the firmware file in the kernel startup program, enables the kernel to start a semi-initialized Shell, avoiding parts of the boot system and file system with various types and huge version differences, enabling security researchers to obtain a complete and unprotected Shell; on the other hand, it uses a method for modifying the kernel section and locating features that is independent of the instruction set, and has good versatility.

[0082] Embodiment 2

[0083] Please refer to Figure 2 , which shows the method for modifying the firmware file in the second embodiment of the present invention. The method specifically includes steps S201 to S212:

[0084] S201, obtain the firmware file in the device memory, and extract the kernel file from the firmware file;

[0085] In specific implementation, obtain the firmware file from the device memory and extract the kernel file from the firmware file. Generally, the obtained firmware file is a.bin file, so the first step is to extract its kernel file. The prerequisite for the.bin to contain the kernel file is that the firmware must be extracted from a memory such as flash. Generally, the firmware downloaded from the manufacturer's official website does not contain U-Boot and kernel files.

[0086] It is understandable that U-Boot is a bootloader mainly used for embedded systems, which can support a variety of different computer system architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and MicroBlaze. This is also a free software released under the GNU General Public License.

[0087] S202, decompress the kernel file to obtain a first decompressed file;

[0088] The usually extracted kernel file is compressed, generally in the compression types of gzip, xz or lzma. Therefore, during specific implementation, it is necessary to determine the compression type of the kernel file. Different compression types use different compression algorithms. When the kernel file belongs to the Gzip type, it is necessary to call the Gzip compression algorithm to decompress the kernel file. When the kernel file does not belong to the Gzip type, it is necessary to call the compression algorithm corresponding to the compression type of the kernel file to decompress it.

[0089] It should be noted that in this application, the compression algorithm is determined through the file header. For example, "\x1F\x8B\x08" is gzip compression, and "\x5D" is lzma compression. Then the gzip–cd or unlzma command (compression algorithm) is executed for decompression.

[0090] S203, locate the string of the kernel section in the first decompressed file;

[0091] It should be noted that through the analysis of the Linux kernel startup process, it can be found that the finally started init process of the kernel is determined by three parts.

[0092] This application needs to directly let the kernel start / bin / sh because the shell started by / bin / sh is a relatively pure one. During specific implementation, modify the program header " / sbin / init" in the try_to_run_init_process(" / sbin / init") parameter content of the kernel section in the first decompressed file to " / bin / sh", so that a very pure and interference-free shell can be started.

[0093] It can be understood that init is one of the indispensable programs in Linux system operations. The so-called init process is a user-level process started by the kernel. After the kernel starts itself (has been loaded into memory, starts running, and has initialized all device drivers and data structures, etc.), it completes the boot process by starting a user-level program init. Therefore, init is always the first process (its process number is always 1).

[0094] In this application, the specific location to be modified can be achieved through a location string. For example, to locate "Try passing init=option to kernel", it is only necessary to locate this string in the kernel section and then find the program header at the very front of this section. Here, it is not necessarily / sbin / init, and it may also be other files written by the manufacturer. Therefore, it is necessary to locate to the very front instead of / sbin / init. It can be observed that the strings used here are all from the Linux directory structure, so regular matching can be used as the search method.

[0095] S204. Modify the program header of the string in the kernel section to obtain a modified first decompressed file.

[0096] S205. Determine whether there are initialization parameters in the modified first decompressed file.

[0097] It should be noted that in addition to modifying the parameter value of try_to_run_init_process, since it is not known whether the startup parameters passed from U-Boot have the two parameters rdinit and init, these two parameters will be executed first in the kernel. If these two parameters exist, the content we modified will not be executed. Therefore, it is also necessary to shield the influence of rdinit and init. Since in fact, the code segments after each kernel compilation are different; and through re-analysis of the source code, it can be learned that "rdinit=" and "init=" will be placed in a section called ".init.setup". Then, perform a matching search in the ".init.setup" section. If a certain value in the ".init.setup" section is erased or replaced with other values, then this value cannot be matched later. Through this method, we can shield rdinit and init. Even if the parameters passed from U-Boot have these two values, but if they cannot be matched, it will not affect the subsequent operation.

[0098] S206. When there are initialization parameters in the first decompressed file, shield the initialization parameters.

[0099] S207. Compress the modified first decompressed file to form a compressed file.

[0100] In specific implementation, the modified first decompressed file is compressed to form a compressed file using the same compression algorithm as in step S102. The specific compression algorithm command can be found in the Linux kernel source code.

[0101] S208. Determine the compression type of the compressed file.

[0102] S209. When the compression type of the compressed file is Gzip, delete the last four bytes of the compressed file.

[0103] It should be noted that after compression by the gzip–cd command (compression algorithm), the compressed file has identification bytes of the Gzip type. Therefore, when the compression type of the kernel file in step S102 is Gzip, the last 4 bytes of the compressed file need to be deleted in this step.

[0104] S210. Determine the image type of the image header file.

[0105] S211. When the image type of the image header file is the compressed file type dedicated to the bootloader, add the file header dedicated to the bootloader to the compressed file to form a new compressed file.

[0106] It should be noted that in this application, it is necessary to determine the image header type of the image header file. When the image type belongs to the compressed file type (UImage) dedicated to the bootloader, directly add the file header dedicated to the bootloader to the compressed file to form a new compressed file; input the new compressed file into the image header file to synthesize a new firmware file.

[0107] When the image type belongs to the ordinary compressed kernel image file type (zImage), directly input the compressed file into the image header file to synthesize a new firmware file.

[0108] It can be understood that zImage is the default compressed kernel image file in general, obtained by compressing the kernel file and adding a section of decompression startup code. And uImage is obtained by processing the ordinary compressed kernel image file (zImage) with the tool mkimage. It is an image file dedicated to uboot. It adds a "header" with a length of 64 bytes before zImage to describe information such as the version, loading location, generation time, and size of this kernel; after 0x40, it is no different from zImage. It is necessary to add the file header of uImage to the compressed file to achieve automated operation.

[0109] S212. Input the new compressed file into the image header file to synthesize a new firmware file.

[0110] In summary, in the above-described embodiments of the present invention, the method for modifying the firmware file modifies the kernel section of the firmware file in the kernel startup program, enabling the kernel to start a semi-initialized Shell, avoiding parts of the diverse and highly version-differentiated boot systems and file systems, and enabling security researchers to obtain a completely unprotected Shell. On the other hand, a method for modifying the kernel section and locating features that is independent of the instruction set is used, which has good generality.

[0111] Embodiment 3

[0112] On the other hand, the present invention also proposes a system for modifying a firmware file. Please refer to Figure 3 , which shows the system for modifying the firmware file in the third embodiment of the present invention. The system includes:

[0113] An acquisition module 11, configured to acquire the firmware file in the device memory and extract the kernel file from the firmware file;

[0114] An extraction module 12, configured to extract the kernel file to obtain a first extracted file;

[0115] A modification module 13, configured to modify the content of the kernel section in the first extracted file to obtain a modified first extracted file;

[0116] Further, the modification module 13 is specifically configured to:

[0117] Locate the string of the kernel section in the first extracted file;

[0118] Modify the program header of the string of the kernel section to obtain a modified first extracted file.

[0119] A compression module 14, configured to compress the modified first extracted file to form a compressed file;

[0120] A processing module 15, configured to obtain the mirror header file and synthesize a new firmware file with the compressed file.

[0121] Further, the processing module 15 is specifically configured to:

[0122] Judge the mirror type of the mirror header file;

[0123] When the mirror type of the mirror header file is the compressed file type dedicated to the boot loader, add the file header dedicated to the boot loader to the compressed file to form a new compressed file;

[0124] Input the new compressed file into the mirror header file to synthesize a new firmware file.

[0125] Further, the system further includes:

[0126] A first judgment module, configured to judge whether there are initialization parameters in the modified first decompressed file;

[0127] A shielding module, configured to shield the initialization parameters when there are initialization parameters in the first decompressed file.

[0128] A second judgment module, configured to judge the compression type of the compressed file;

[0129] A control module, configured to delete the last four bytes of the compressed file when the compression type of the compressed file is Gzip type.

[0130] The functions or operation steps implemented when the above modules are executed are substantially the same as those in the foregoing method embodiments, and will not be described herein again.

[0131] The firmware file modification system provided by the embodiments of the present invention has the same implementation principle and technical effects as those in the foregoing method embodiments. For a brief description, for the parts not mentioned in the system embodiments, reference may be made to the corresponding content in the foregoing method embodiments.

[0132] Embodiment 4

[0133] The present invention further provides a computer device. Please refer to Figure 4 , which shows the computer device in the fourth embodiment of the present invention, including a memory 10, a processor 20, and a computer program 30 stored on the memory 10 and executable on the processor 20. When the processor 20 executes the computer program 30, the above-mentioned firmware file modification method is implemented.

[0134] In specific implementation, the processor 20 obtains the firmware file in the device memory and extracts the kernel file from the firmware file;

[0135] The processor 20 decompresses the kernel file to obtain a first decompressed file;

[0136] The processor 20 modifies the content of the kernel section in the first decompressed file to obtain a modified first decompressed file;

[0137] The processor 20 compresses the modified first decompressed file to form a compressed file;

[0138] The processor 20 obtains the image header file and combines it with the compressed file to form a new firmware file.

[0139] Among them, the memory 10 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (such as SD or DX memory, etc.), magnetic memory, magnetic disk, optical disc, etc. The memory 10 can be an internal storage unit of the vehicle in some embodiments, such as the hard disk of the vehicle. The memory 10 can also be an external storage device in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Further, the memory 10 can also include both the internal storage unit of the vehicle and the external storage device. The memory 10 can be used not only to store application software and various types of data installed in the vehicle, but also to temporarily store data that has been output or will be output.

[0140] Among them, the processor 20 can be an Electronic Control Unit (ECU, also known as the vehicle computer), a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips in some embodiments, and is used to run the program code stored in the memory 10 or process data, such as executing an access restriction program, etc.

[0141] It should be noted that Figure 4 The structure shown does not constitute a limitation on the computer device. In other embodiments, the computer device may include fewer or more components than shown, or combine certain components, or have a different component arrangement.

[0142] In the computer device of the present invention, the processor 20 modifies the kernel section of the firmware file in the kernel startup program, enabling the kernel to start a semi-initialized Shell, avoiding parts of the diverse and highly version-differentiated boot systems and file systems, so that security researchers can obtain a completely unprotected Shell; on the other hand, a method of modifying the kernel section and positioning features independent of the instruction set is used, which has good versatility.

[0143] The embodiment of the present invention also proposes a readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the method for modifying the firmware file as described above.

[0144] Those skilled in the art will understand that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a definite sequence list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus or device), or in combination with these instruction execution systems, apparatus or devices. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate or transport a program for use by or in combination with an instruction execution system, apparatus or device.

[0145] More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection portion (electronic device) having one or more wirings, a portable computer disk cartridge (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpretation or other suitable processing as necessary, and then stored in a computer memory.

[0146] It should be understood that various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0147] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0148] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A method for modifying a firmware file, characterized in that, including: Obtain the firmware file in the device memory and extract the kernel file from the firmware file; Decompress the kernel file to obtain a first decompressed file; Modify the program header in the content of the kernel section in the first decompressed file to start a shell without interference, obtaining a modified first decompressed file; Determine whether there is an initialization parameter in the modified first decompressed file; when there is an initialization parameter in the first decompressed file, mask the initialization parameter; Compress the modified first decompressed file to form a compressed file; Obtain the image header file and synthesize a new firmware file with the compressed file.

2. The method for modifying a firmware file according to claim 1, wherein The step of modifying the program header in the content of the kernel section in the first decompressed file to obtain a modified first decompressed file includes: Locate the string of the kernel section in the first decompressed file; Modify the program header of the string of the kernel section to obtain a modified first decompressed file.

3. The method for modifying a firmware file according to claim 1, wherein Before the step of obtaining the image header file and synthesizing a new firmware file with the compressed file, the method further includes: Determine the compression type of the compressed file; When the compression type of the compressed file is the Gzip type, delete the last four bytes of the compressed file.

4. The method for modifying a firmware file according to claim 1, wherein The step of obtaining the image header file and synthesizing a new firmware file with the compressed file includes: Determine the image type of the image header file; When the image type of the image header file is the compressed file type dedicated to the boot loader, add the file header dedicated to the boot loader to the compressed file to form a new compressed file; Input the new compressed file into the image header file to synthesize a new firmware file.

5. A modification system for firmware files, characterized in that, including: An obtaining module, configured to obtain the firmware file in the device memory and extract the kernel file from the firmware file; A decompression module, configured to decompress the kernel file to obtain a first decompressed file; A modification module, configured to modify the program header in the content of the kernel section in the first decompressed file to start a shell without interference, obtaining a modified first decompressed file; A first judgment module, configured to determine whether there is an initialization parameter in the modified first decompressed file; A masking module, configured to mask the initialization parameter when there is an initialization parameter in the first decompressed file; A compression module, configured to compress the modified first decompressed file to form a compressed file; A processing module, configured to obtain the image header file and synthesize a new firmware file with the compressed file.

6. The firmware file modification system according to claim 5, characterized in that, The modification module is specifically configured to: Locate the string of the kernel section in the first decompressed file; Modify the program header of the string of the kernel section to obtain a modified first decompressed file.

7. A readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the method for modifying the firmware file according to any one of claims 1 to 4.

8. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for modifying the firmware file according to any one of claims 1 to 4.

Citation Information

Patent Citations

  • Kernel file acquisition method, apparatus and device, and storage medium

    CN110647753A

  • Method and equipment for realizing memory operating system

    CN111966423A