Firmware extraction method and device and electronic equipment

Abstract

The invention discloses a firmware extraction method and device and electronic equipment. The method comprises the following steps: acquiring firmware data in a physical chip of the embedded equipment; determining a virtual flash memory device having the same hardware characteristics as the physical chip; error correction processing is carried out on the firmware data, target firmware data obtained after error correction processing is written into the virtual flash memory device, and the error correction processing comprises the steps that error check codes in the firmware data are automatically removed through a kernel driver and the data layout of the firmware data is optimized; and determining a file system layer corresponding to the target firmware data in the virtual flash memory device, and exporting the target firmware data according to the file system layer. According to the method and the device, the technical problem that the firmware of the embedded equipment is difficult to extract and analyze due to complex physical characteristics (including ECC (Error Correction Code) and special data layout) of the NAND Flash is solved.

Description

Technical Field

[0001] This application relates to the field of network security, and more specifically, to a firmware extraction method, apparatus, and electronic device. Background Technology

[0002] In the fields of security research and digital forensics for IoT devices and embedded systems, extracting firmware data from physical storage chips is the first step in security auditing and data analysis. This is especially true for embedded devices that use NAND Flash Memory (NAND Flash Memory) as the primary storage medium, where firmware extraction and analysis present unprecedented challenges.

[0003] Due to the complex storage characteristics of NAND Flash, including ECC (Error Correction Code) mechanisms, proprietary data layouts, and physical limitations of page / block erasure, firmware extraction is a technically demanding, time-consuming, and error-prone process. In related technologies, NAND Flash firmware extraction and analysis primarily rely on the following two methods:

[0004] 1. Manual Script Analysis Method: This method involves physically removing the NAND chip, using a programmer to read its entire contents, and then having researchers manually extract OOB (Out-of-Band Data) data, correct data errors, and restructure the file system using Python scripts and other tools, based on the chip's datasheet and ECC algorithm. While this method offers customized analysis capabilities, it is inefficient, requiring independent reverse engineering for each new chip or controller, and is prone to data recovery failures due to human error or insufficient understanding of specific hardware characteristics.

[0005] 2. Dedicated Tool Analysis Method: This method utilizes pre-packaged firmware analysis tools, such as binwalk, ubireader, and firmwalker, to directly scan and analyze the raw NAND dump file. These tools are designed to handle firmware images with clearly formatted images that have had ECC and OOB data removed. However, when faced with raw NAND data containing complex ECC and proprietary layouts, they often fail to accurately identify the file system structure, leading to false positives or false negatives, making it difficult to guarantee the reliability and integrity of data recovery.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This application provides a firmware extraction method, apparatus, and electronic device to at least solve the technical problem of difficulty in firmware extraction and analysis of embedded devices caused by the complex physical characteristics of NAND Flash (including ECC and proprietary data layout).

[0008] According to one aspect of the embodiments of this application, a firmware extraction method is provided, comprising: acquiring firmware data in the physical chip of an embedded device; determining a virtual flash memory device having the same hardware characteristics as the physical chip; performing error correction processing on the firmware data, and writing the error-corrected target firmware data into the virtual flash memory device, wherein the error correction processing includes automatically removing error check codes in the firmware data and optimizing the data layout of the firmware data through a kernel driver; determining a file system layer corresponding to the target firmware data in the virtual flash memory device, and exporting the target firmware data based on the file system layer.

[0009] Optionally, obtaining firmware data from the physical chip of the embedded device includes: determining the adapter corresponding to the physical chip; repeatedly reading the physical chip using a general-purpose programmer and the adapter to obtain first firmware data and second firmware data; performing byte comparison of the first firmware data and second firmware data in a Linux environment according to a preset comparison instruction to obtain a comparison result; and confirming the first firmware data or the second firmware data as the firmware data of the physical chip if the comparison result indicates that the first firmware data and the second firmware data are consistent.

[0010] Optionally, determining a virtual flash memory device with the same hardware characteristics as the physical chip includes: obtaining the official datasheet of the physical chip, wherein the official datasheet stores the physical parameters of the physical chip; determining the simulation kernel module corresponding to the physical chip in the Linux environment; analyzing the official datasheet through the simulation kernel module, and generating a virtual flash memory device corresponding to the physical chip.

[0011] Optionally, error correction processing of the firmware data includes: processing the third firmware data according to a preset error correction instruction to obtain a processing result, wherein the third firmware data is any page of data in the firmware data; if the processing result indicates that there is an error verification code or an error layout pattern in the third firmware data, removing the error verification code or optimizing the error layout pattern of the third firmware data to obtain the fourth firmware data; and writing the fourth firmware data into the page data area in the virtual flash memory device, wherein the page data area includes a main data area and a backup data area for storing the fourth firmware data.

[0012] Optionally, writing the error-corrected target firmware data into a virtual flash memory device includes: obtaining a file system identifier for the target firmware data, wherein the file system identifier reflects the file system type of the target firmware data; determining the starting offset address of the file system, wherein the starting offset address indicates the starting position of the file system in the target firmware data; and after obtaining the file system identifier and the starting offset address, writing the target firmware data into the virtual flash memory device according to a preset write instruction, wherein the preset write instruction includes a first parameter and a second parameter, the first parameter indicating that the firmware data contains backup data, and the second parameter indicating that the firmware data is written starting from the starting offset address.

[0013] Optionally, the file system layer corresponding to the target firmware data is determined in the virtual flash device, and the target firmware data is exported based on the file system layer, including: determining the file system type of the target firmware data based on the file system identifier; determining the file system layer corresponding to the file system type; adding the file system layer to the virtual flash device according to a preset add instruction; and identifying the logical volume in the file system layer, wherein the file system layer is used to represent the emulated file system management layer on the virtual flash device, and the logical volume is used to represent the basic logical unit for storing firmware data in the file system layer; mounting the logical volume to the local directory according to a preset mount instruction; and retrieving the target firmware data after successful mounting.

[0014] Optionally, identifying logical volumes in the file system layer includes: scanning the virtual flash device and obtaining the erase / write counter information and volume identifier information in the virtual flash device header; after the firmware data is successfully written, determining the logical volume in the file system layer based on the volume identifier information, and determining the running status of the logical volume based on the erase / write counter information.

[0015] According to another aspect of the embodiments of this application, a firmware extraction apparatus is also provided, comprising: an acquisition module for acquiring firmware data in the physical chip of an embedded device; a determination module for determining a virtual flash memory device having the same hardware characteristics as the physical chip; an error correction module for performing error correction processing on the firmware data and writing the error-corrected target firmware data into the virtual flash memory device, wherein the error correction processing includes automatically removing error check codes from the firmware data and optimizing the data layout of the firmware data through a kernel driver; and an extraction module for determining the file system layer corresponding to the target firmware data in the virtual flash memory device and exporting the target firmware data based on the file system layer.

[0016] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor is connected to the memory and used to execute the firmware extraction method described above.

[0017] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-described firmware extraction method by running the computer program.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described firmware extraction method.

[0019] In this embodiment, firmware data from the physical chip of the embedded device is obtained; a virtual flash memory device with the same hardware characteristics as the physical chip is identified; error correction processing is performed on the firmware data, and the error-corrected target firmware data is written into the virtual flash memory device. The error correction processing includes automatically removing error check codes from the firmware data and optimizing the data layout of the firmware data through the kernel driver; the file system layer corresponding to the target firmware data is determined in the virtual flash memory device, and the target firmware data is exported based on the file system layer. This achieves the goal of extracting and accessing clean firmware data in the virtual flash memory without loss and with high efficiency, thereby improving the extraction efficiency of firmware data and accelerating firmware reverse engineering and security analysis. This solves the technical problem of difficulty in firmware extraction and analysis of embedded devices caused by the complex physical characteristics of NAND Flash (including ECC and proprietary data layout). Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a hardware structure diagram of a computer terminal for implementing a firmware extraction method according to an embodiment of this application;

[0022] Figure 2 This is a flowchart of a firmware extraction method according to an embodiment of this application;

[0023] Figure 3 This is a flowchart of an ECC automatic removal and data extraction method based on kernel simulation according to an embodiment of this application;

[0024] Figure 4 This is a flowchart of a method for direct extraction and analysis of a firmware file system based on virtual mounting, according to an embodiment of this application.

[0025] Figure 5 This is a structural diagram of a firmware extraction device according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] First, some nouns or terms that appear in the explanation of the embodiments of this application shall be interpreted as follows:

[0029] NAND Flash (NAND Flash Memory): A type of non-volatile computer storage device. Its basic unit for reading and writing data is a "page," and the basic unit for erasing is a "block." The physical characteristics of NAND Flash inevitably lead to bit errors during read and write operations, thus requiring additional mechanisms to ensure data reliability.

[0030] Out-of-Band Data (OOB): Additional storage space in NAND Flash used to store metadata such as error check codes and bad block markers. It does not contain user data, but it is crucial for data reliability and storage management.

[0031] ECC (Error Correction Code): An encoding technique used to detect and correct data errors during storage or transmission. It is a key mechanism for ensuring data integrity during NAND Flash data read and write processes.

[0032] MTD (Memory Technology Device): A set of drivers in the Linux kernel used to manage and access various non-volatile storage devices, such as NAND Flash and Nor Flash, providing a unified interface to shield the differences in underlying hardware.

[0033] Nandsim (NAND Simulation Module): A module in the Linux kernel used to simulate the physical characteristics of NAND Flash devices in the host's physical memory, such as page size and block size, providing a virtual hardware environment for firmware analysis.

[0034] UBI (Unsorted Block Images): A logical layer built on top of MTD, primarily responsible for bad block management and wear leveling on NAND devices, providing logical block devices to the upper-layer file system.

[0035] UBIFS (UBI File System): A file system based on the UBI layer, specifically designed to work efficiently and reliably on NAND Flash, supporting dynamic volume management and data recovery.

[0036] Magic Number: A specific sequence of bytes in a file or data structure that identifies its type or version, allowing programs or tools to quickly recognize its format.

[0037] VID (Volume Identifier): In a UBI system, a unique identifier is used to distinguish different logical volumes, enabling storage devices to manage multiple independent logical partitions.

[0038] EC (Erase Counter): Records the number of times each physical block in NAND flash memory is erased. It is used in wear leveling algorithms to determine which blocks need to be erased first to extend the device's lifespan.

[0039] To address the difficulty of firmware extraction from embedded devices in related technologies, this application provides a firmware extraction method that can be run on... Figure 1 The computer terminal shown is described below.

[0040] The firmware extraction method embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing a firmware extraction method is shown. Figure 1As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0041] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

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

[0043] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0044] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0045] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0046] In the above operating environment, this application provides a firmware extraction method embodiment. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0047] Figure 2 This is a flowchart of a firmware extraction method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0048] Step S202: Obtain firmware data from the physical chip of the embedded device.

[0049] Step S204: Identify a virtual flash memory device that has the same hardware characteristics as the physical chip.

[0050] Step S206: Perform error correction processing on the firmware data and write the error-corrected target firmware data into the virtual flash memory device. The error correction processing includes automatically removing error check codes from the firmware data and optimizing the data layout of the firmware data through the kernel driver.

[0051] Step S208: Determine the file system layer corresponding to the target firmware data in the virtual flash device, and export the target firmware data based on the file system layer.

[0052] Through steps S202 to S208, the goal of extracting and accessing clean firmware data in virtual flash memory without loss is achieved. This improves the efficiency of firmware data extraction and accelerates firmware reverse engineering and security analysis, thereby solving the technical problem of difficulty in firmware extraction and analysis of embedded devices caused by the complex physical characteristics of NAND Flash (including ECC and proprietary data layout). The following is a detailed explanation.

[0053] In this application embodiment, taking an embedded device using NAND Flash as the storage medium as an example, a kernel-emulated ECC automatic removal and data extraction method is proposed, namely the above-mentioned method. Figure 2 The firmware extraction method shown is analyzed in detail below:

[0054] In step S202 above, the main responsibility is to obtain physical firmware and verify its integrity.

[0055] Optionally, obtaining firmware data from the physical chip of the embedded device includes: determining the adapter corresponding to the physical chip; repeatedly reading the physical chip using a general-purpose programmer and the adapter to obtain first firmware data and second firmware data; performing byte comparison of the first firmware data and second firmware data in a Linux environment according to a preset comparison instruction to obtain a comparison result; and confirming the first firmware data or the second firmware data as the firmware data of the physical chip if the comparison result indicates that the first firmware data and the second firmware data are consistent.

[0056] Specifically, when acquiring firmware data, a professional general-purpose programmer (such as RT809H) and an adapter corresponding to the NAND Flash physical chip (hereinafter referred to as NAND chip) (depending on the specific package type of the chip, such as TSOP-48) can be used to directly perform read operations on the NAND chip through physical contact, generating the initial binary data file, i.e. firmware data, thereby obtaining an accurate image of the original storage state of the embedded device, providing a foundation for all subsequent firmware analysis and data extraction.

[0057] Furthermore, to eliminate read errors caused by poor contact or NAND chip aging, and to ensure the accuracy and availability of firmware data, strict verification measures must be taken. The specific procedure is as follows: Perform at least two independent read operations on the same NAND chip, generating two image files, such as firmware_dump1.bin (the first firmware data) and firmware_dump2.bin (the second firmware data). Then, in a Linux environment, use preset comparison commands (such as cmp -l or diff) to compare the two image files byte-by-byte, checking for any differences. If the two image files are completely identical, with no byte-level differences, it can be determined that no errors were introduced during the data read process, and the firmware dump is accurate and reliable. At this point, either image file can be confirmed as the firmware data of the NAND chip.

[0058] In step S204 above, the main responsibility is to build the virtual NAND environment.

[0059] Optionally, determining a virtual flash memory device with the same hardware characteristics as the physical chip includes: obtaining the official datasheet of the physical chip, wherein the official datasheet stores the physical parameters of the physical chip; determining the simulation kernel module corresponding to the physical chip in the Linux environment; analyzing the official datasheet through the simulation kernel module, and generating a virtual flash memory device corresponding to the physical chip.

[0060] Specifically, after successfully acquiring and verifying the integrity of the firmware data, a virtual environment capable of simulating the behavior of a NAND Flash chip, namely the virtual flash device MTD, needs to be constructed. The construction of this virtual environment mainly relies on Linux kernel module loading and parameter configuration; the specific process is analyzed below:

[0061] 1. Kernel Module Preparation: This aims to ensure that the Linux kernel on the analysis host has the ability to process NAND Flash data, including but not limited to emulating NAND devices, managing MTD devices, and handling UBI volumes and UBIFS file systems. The specific implementation method is as follows:

[0062] By executing the `modprobe` command, a series of kernel modules are loaded, including `nandsim` (the emulation kernel module used to simulate NAND chips), `mtd` (the MTD core support module), `mtdblock` (the module that exposes MTD devices as block devices), `ubi` (the module that handles the UBI format), and `ubifs` (the UBIFS file system driver module). These modules work together to support subsequent NAND data read / write, ECC processing, file system recognition, and other operations.

[0063] 2. NAND Chip Simulation: This aims to create a virtual MTD device using the nandsim module based on the official datasheet of the NAND chip. The specific implementation method is as follows:

[0064] 1) Parameter Acquisition: Consult the official datasheet of the NAND chip to obtain its key physical parameters, including but not limited to: Manufacturer ID, Device ID, Page Size (e.g., 2048 bytes), Erase Block Size (e.g., 128 KiB or 131072 bytes), Out-of-Band Size (e.g., 64 bytes), and total chip capacity. These parameters are the basis for building virtual devices and can ensure that the simulation environment accurately reflects the hardware characteristics of the real chip.

[0065] 2) NAND sim tool application: Use the `modprobe nandsim` command to load the NAND sim kernel module based on the obtained physical parameters, creating a virtual MTD device with the same attributes as the NAND chip. For example: `modprobe nandsim id_bytes=0xEC,0xF1,0x00,0x95 page_size=2048 erase_size=131072`.

[0066] This command creates a virtual MTD device whose ID information, page size, and block size match the NAND chip, typically represented as / dev / mtd0. The purpose of this step is to trick the kernel into thinking it is interacting with a real NAND chip with specific physical properties.

[0067] In step S206 above, the firmware data is mainly written to the constructed virtual MTD device.

[0068] In this embodiment, the preset write instruction `nandwrite` can be used to write the error-corrected target firmware data to the virtual MTD device. It should be noted that during the execution of `nandwrite`, the Linux kernel's MTD driver automatically takes over the entire writing process and performs error correction on the firmware data, including: processing the third firmware data according to the preset error correction instruction to obtain a processing result, wherein the third firmware data is any page of firmware data; if the processing result indicates that there is an error verification code or an incorrect layout pattern in the third firmware data, removing the error verification code or optimizing the incorrect layout pattern of the third firmware data to obtain the fourth firmware data; and writing the fourth firmware data to the page data area in the virtual flash memory device, wherein the page data area includes a main data area and a backup data area for storing the fourth firmware data.

[0069] For example, for any page of firmware data (i.e., the third firmware data), error detection and correction are performed using preset error correction instructions. Specifically, based on the automatic error correction mechanism of the nandwrite command, the kernel driver (such as the MTD's NAND driver) automatically detects and corrects the error check code (ECC) in the page data and handles proprietary data layout patterns. If an error is detected (such as ECC failure or irregular data layout), the kernel will generate the fourth firmware data after automatic error correction and write it to the corresponding page data area (including the main data area and the backup data area) in the virtual MTD device. In terms of processing logic, the kernel will automatically calculate and apply ECC correction based on the chip's physical parameters, such as page size and OOB size. At the same time, for irregular data layouts, the kernel driver will optimize to ensure that the data can be correctly parsed and stored.

[0070] Further, writing the corrected target firmware data into the virtual flash memory device includes: obtaining the file system identifier of the target firmware data, wherein the file system identifier reflects the file system type of the target firmware data; determining the starting offset address of the file system, wherein the starting offset address indicates the starting position of the file system in the target firmware data; after obtaining the file system identifier and the starting offset address, writing the target firmware data into the virtual flash memory device according to a preset write instruction, wherein the preset write instruction includes a first parameter and a second parameter, the first parameter indicating that the firmware data contains backup data, and the second parameter indicating that the firmware data is written starting from the starting offset address. The specific process analysis is as follows:

[0071] 1. File System Identifier Acquisition: First, analyze the firmware data or the target firmware data after error correction to identify the file system type used (such as UBIFS, JFFS2, etc.). For example, search for the "magic number" of a specific file system in the obtained original_firmware.bin file as the file system identifier of the firmware data. For example, the magic number of UBIFS is 0x55424923, and the magic number of JFFS2 is 0x1985.

[0072] 2. Determining the Starting Offset Address: Locate the starting position (offset) of the file system in the firmware data to ensure that write operations can begin from the correct data offset. The script process is as follows:

[0073] for x in range(0, len(rawbin), 0x20000):

[0074] magic = rawbin[x:x+4]

[0075] if magic == FS_header:

[0076] print("FS offset start:", hex(x))

[0077] 3. Preset Write Command Application: After obtaining the file system identifier and determining the starting offset address, the nandwrite command is used to write the target firmware data to the virtual flash device. This preset write command includes:

[0078] 1) First parameter (-o or --oob): indicates that the firmware data includes backup data (OOB), and the kernel driver will perform ECC checksum and error correction accordingly.

[0079] 2) The second parameter (-s or --start): is used to indicate that firmware data writing starts from the starting offset address, ensuring that file system data is written to the correct location.

[0080] For example: nandwrite -o -s 0x600000 / dev / mtd0 original_firmware.bin.

[0081] In step S208 above, the main responsibility is to associate firmware data with the file system.

[0082] Optionally, the file system layer corresponding to the target firmware data is determined in the virtual flash device, and the target firmware data is exported based on the file system layer. This includes: determining the file system type of the target firmware data based on the file system identifier; determining the file system layer corresponding to the file system type; adding the file system layer to the virtual flash device according to a preset add instruction; and identifying logical volumes in the file system layer. The file system layer represents the emulated file system management layer on the virtual flash device, and the logical volume represents the basic logical unit storing firmware data in the file system layer. The logical volume is mounted to a local directory according to a preset mount instruction, and the target firmware data is extracted after successful mounting. Identifying logical volumes in the file system layer includes: scanning the virtual flash device and obtaining the erase / write counter information and volume identifier information from the virtual flash device header; after successful firmware data writing, determining the logical volume in the file system layer based on the volume identifier information, and determining the running status of the logical volume based on the erase / write counter information.

[0083] In this embodiment, the file system identifier (magic number) used by the firmware data of the virtual MTD device can be analyzed to determine its file system type (such as UBIFS, JFFS2, etc.). If the firmware data uses a UBI file system, the corresponding UBI file system layer can be added to the virtual MTD device using a preset add command (such as the ubiattach command).

[0084] Its working principle is as follows: The `ubiattach` command scans each physical block in the virtual MTD device, reads the EC (Erase / Write Counter) and VID (Volume Identifier) ​​information in its header, identifies and activates the UBI volumes (i.e., logical volumes), and establishes a mapping table from logical blocks to physical blocks in memory to prepare for subsequent mounting. The EC records the number of times each physical block has been erased and written, which helps assess the health and wear of the logical volume; while the VID is used to identify data belonging to different logical volumes.

[0085] Furthermore, to verify the success of the automatic removal of firmware data ECC and the identification of the file system structure through the simulated environment and kernel driver, the file system on the virtual MTD device can be mounted for verification. Specifically, after the logical volume is successfully identified, it can be mounted to a local directory (such as / mnt / firmware_rootfs) using a preset mount command (such as the mount command).

[0086] Command examples are as follows:

[0087] mkdir -p / mnt / firmware_rootfs

[0088] mount -t ubifs ubi0_0 / mnt / firmware_rootfs

[0089] Once the mount is successful (i.e., the mount command executes successfully), and files can be listed and read normally using commands such as ls / mnt / firmware_rootfs and cat / mnt / firmware_rootfs / etc / passwd, the target firmware data can be accessed and extracted like a normal folder, thus achieving lossless, transparent processing and efficient extraction of firmware data.

[0090] Overall, the implementation logic of the above-mentioned kernel-simulated ECC automatic removal and data extraction method is as follows: Figure 3As shown, the process begins with extracting the firmware of the NAND Flash device. Then, the `modprobe mtdblock ubi` command loads the key module in the Linux kernel that handles flash memory devices, preparing kernel-level support for building the virtual NAND environment. Next, the `nandsim` module is used to create a virtual MTD device whose parameters (e.g., `id=0xef`, `0xaa`, etc.) are completely identical to the physical parameters of the NAND chip, providing a virtual environment for subsequent data writing. Then, the file system in the firmware data is located, and the `nandwrite -k --input-skip` command is used to write the raw firmware data, including OOB and ECC, to the virtual MTD device. During the writing process, specific parameters are specified to handle OOB data and ECC, ensuring that the kernel automatically removes ECC and retains only clean data. After successful data writing, the `ubiattach` command is used to associate the virtual NAND device with the UBI management layer, identify logical volumes in the file system layer, and mount the identified UBIFS file system logical volume to the local file system directory, enabling direct access and analysis of files within the firmware. Finally, `nanddump` is used... The -o command exports clean file system data from the mounted file system, that is, a firmware image stripped of the OOB area and ECC checksum, to ensure data purity and ease of subsequent reverse engineering analysis.

[0091] This process fully leverages the powerful capabilities of the Linux kernel, achieving a high degree of automation and versatility, greatly improving the efficiency and accuracy of firmware analysis, and opening up new avenues for security research on IoT devices.

[0092] In this application embodiment, a method for direct extraction and analysis of firmware file systems based on virtual mounting is also proposed. The objectives and key operations in each step are described in detail below:

[0093] Step 1: Environment preparation and kernel module loading.

[0094] Objective: To prepare the necessary kernel environment for firmware analysis, enabling it to understand and process the flash device stack.

[0095] Key operation: Loading multiple core modules in the Linux kernel used for handling flash devices, including but not limited to nandsim, mtd, mtdblock, ubi, and ubiFS. Specifically:

[0096] nandsim is a module in the Linux kernel used to simulate NAND chips. It can create a virtual NAND device, or MTD device, in the host's physical memory and accurately mimic the behavior of a real NAND chip by specifying parameters (such as page size, block size, vendor ID, etc.).

[0097] The mtd subsystem is the standard subsystem in the Linux kernel used for managing and accessing flash memory devices (such as NAND and NOR Flash). It provides a common interface and driver framework, allowing upper-layer applications to access underlying flash resources uniformly, regardless of specific hardware differences. The mtd module is also responsible for managing read and write operations on flash memory devices, including bad block management and wear leveling, providing a stable storage abstraction for higher-level file systems.

[0098] mtdblock is used to map devices (such as NAND or NOR Flash) of the MTD subsystem to traditional block devices (such as / dev / mtdblockN).

[0099] UBI is a volume management system built on top of MTD, specifically designed for flash memory devices. Its main tasks are handling bad block management, wear leveling, and the creation and management of logical volumes on flash memory devices. The UBI module is also responsible for mapping physical blocks to logical volumes and handling erase counts and metadata at the physical layer, providing a more reliable and persistent storage space for upper-layer file systems (such as UBIFS).

[0100] UBIFS is a journaling file system within the Linux kernel designed for efficient and reliable operation on raw flash memory (especially NAND flash using UBI). It is responsible for parsing and mounting the UBIFS formatted file system structure, allowing data stored on flash memory to be accessed as files and directories. It utilizes logical block devices provided by UBI to manage file system metadata and provides functions such as file read / write and directory traversal.

[0101] Step 2: Accurate simulation of the target hardware environment.

[0102] Objective: To create a virtual MTD device that perfectly matches the physical characteristics of a NAND chip.

[0103] Key operation: Create a virtual MTD device using the nandsim module based on the official datasheet of the NAND chip.

[0104] For example: modprobe nandsim first_id_byte=0xef second_id_byte=0xaa third_id_byte=0x80 fourth_id_byte=0x95.

[0105] Among them, nandsim is the core technology for achieving "hardware-free analysis". It is a RAM-based NAND flash emulator that, once loaded, creates a virtual MTD device (usually / dev / mtd0) in the kernel (LinuxFlash for Newbies).

[0106] The ID byte parameters, such as first_id_byte, are crucial for simulation. These bytes are the NAND chip's response to the READ_ID command. They are typically derived from the target device's hardware specifications (i.e., official datasheet) or read directly from the NAND chip using physical probing methods such as JTAG or SPI. They uniquely identify key physical characteristics of the chip, such as the manufacturer, device ID, capacity, page size, and block size, providing a reliable data foundation for environmental simulation.

[0107] Step 3: Loading and formatting firmware data.

[0108] Objective: To write the firmware image content to be analyzed into the virtual MTD device created in the previous step.

[0109] Key operation: Use the ubiformat tool to format and write the image.

[0110] For example: sudo ubiformat / dev / mtd0 -s 2048 -f tt1c_noEcc.bin -O 2048.

[0111] Ubiformat is not a simple file copying tool, but a UBI-aware formatting tool. It can not only format the device, but also write the firmware image, process ECC and retain erase counter information at the same time to achieve wear leveling.

[0112] -f tt1c_noEcc.bin: Specifies the firmware image file to be written. Firmware data typically needs to be preprocessed to remove ECC information to avoid conflicts with ECC algorithms in the virtual environment. ECC-free firmware images retain the original data structure but remove ECC checksums specific to the NAND controller hardware, making the data more suitable for general simulation and analysis environments.

[0113] -s 2048: Specifies the minimum I / O unit size, i.e., the sub-page size, in bytes. This parameter must precisely match the physical characteristics of the virtual device and be consistent with the page size configured in the nandsim module to ensure that data is written in the correct format.

[0114] -O 2048: Specifies the offset of the UBI Volume Identifier (VID) header. This parameter is used to adapt to the specific layout requirements of different NAND chips, ensuring that the UBI layer identifies and reads volume information in the correct location, thereby avoiding offset errors during formatting or data reading. This offset is typically an integer multiple of the page size or subpage size.

[0115] Step 4: Association between the UBI layer and the MTD device.

[0116] Objective: To scan, identify, and activate the UBI file system layer on a virtual MTD device that already contains firmware data.

[0117] Key operation: Use the ubiattach command to establish a connection.

[0118] For example: ubiattach / dev / ubi_ctrl -m 0 -O 2048.

[0119] The `ubiattach` command acts as a bridge between the MTD and UBI layers. It scans the MTD device for UBI-specific header information, including EC and VID, to identify which physical blocks are used by UBI. Once valid UBI header information is identified in the MTD device, `ubiattach` creates a new UBI device in the kernel (e.g., ` / dev / ubi0`). This new device is an abstract representation of the UBI logical volume on the physical layer (MTD), mapping physical blocks to logical volumes and providing an entry point for subsequent volume management and file system identification.

[0120] At the same time, parameter consistency is crucial for the success of this step. Parameters such as -O 2048 must be completely consistent with the parameters used in the ubiformat stage to ensure that the UBI layer can correctly parse the location of the VID header.

[0121] After this step is successful, the system has transformed from a "raw" MTD device into an "organized" UBI device, ready to access its internal logical volumes.

[0122] Step 5: Logical volume creation and file system mounting.

[0123] Objective: To create a logical volume on the activated UBI layer and eventually mount the UBIFS file system so that its contents are accessible.

[0124] Key steps: Use the ubimkvol and mount commands sequentially. For example:

[0125] ubimkvol / dev / ubi0 -N ubifs_0 –m

[0126] mount -t ubifs ubi0:ubifs_0 / mnt / loop /

[0127] The `ubimkvol` command is used to create a UBI volume (logical volume) on the UBI device ` / dev / ubi0`. Here, `-N ubifs_0` names the logical volume to be created, and `-m` indicates that all remaining available space should be used to create the logical volume.

[0128] Unlike static MTD partitions, UBI volumes are dynamic. They can be created, resized, or deleted at runtime as needed, providing a more flexible and efficient way to manage data storage on flash memory. Creating a logical volume using ubimkvol essentially partitions the storage space within the UBI device and assigns it specific attributes and uses, preparing it for file system mounting and access.

[0129] The `mount` command is used to map the virtual root directory of a UBIFS file system to a local file system directory. The file system type is explicitly specified using `-t ubifs`, and the special syntax `ubi0:ubifs_0` precisely specifies that the volume named `ubifs_0` on UBI device 0 is to be mounted, with the target mount point being ` / mnt / loop / `.

[0130] Once the mount command is executed successfully, the complete file system of the IoT firmware will be fully visible in the / mnt / loop / directory, and can be browsed, copied, and analyzed just like a normal local folder.

[0131] Step 6: Component system extraction and in-depth analysis.

[0132] Objective: To solidify the analysis results of the mounted UBIFS file system, ensure data security and usability, and make full preparations for subsequent in-depth security audits and reverse engineering analysis.

[0133] Key operation: Copy the mounted file system completely to the local working directory.

[0134] For example: cp -a / mnt / loop / .

[0135] This command recursively copies all files and subdirectories under the mounted UBIFS filesystem directory ( / mnt / loop / ) to the current working directory. The `cp -a` parameter combination ensures a complete copy of the files, including all attributes such as permissions and timestamps, guaranteeing data accuracy and preservation of the original state for further analysis and research.

[0136] Researchers can perform the following tasks based on the extracted file system:

[0137] 1. Analyze startup scripts: Gain a deeper understanding of the device's startup process by examining the scripts in the / etc / init.d / directory. These scripts typically contain information about services that run during device startup and their dependencies. Analyzing them can help trace important information such as the device's initialization order, environment variable settings, and network configuration, providing clues for discovering potential security vulnerabilities.

[0138] 2. Examine critical binary files: Use tools such as `file`, `strings`, and `readelf` to perform deep analysis of binary files in directories such as ` / bin / `, ` / sbin / `, and ` / usr / bin / `. These tools can help identify file types, extract human-readable strings, and view function call tables, thereby discovering hard-coded keys, API addresses, or other sensitive information. This type of information is often a direct indication of firmware security weaknesses; analysis can assess the device's security status and potential threats.

[0139] 3. Core Application Reverse Engineering: This involves analyzing application executables in directories such as / usr / sbin / , using disassemblers and reverse engineering tools (such as IDA Pro and Ghidra) to understand the program's logical structure, functional implementation, and parameter passing flow. This process is crucial for identifying security issues such as logical vulnerabilities, buffer overflows, and privilege escalation in the application. Reverse engineering results can also reveal third-party libraries or open-source code used by the device, providing a basis for further security assessments.

[0140] 4. Web Server Configuration and CGI Script Analysis: For devices with built-in web services, thoroughly examine configuration files and CGI scripts in directories such as / var / www / , / etc / httpd / , or / etc / apache2 / . Improper web server configuration or vulnerabilities in CGI scripts are among the most common security risks for IoT devices. Analyzing this information helps identify remote attack entry points such as open ports, default usernames and passwords, insecure SSL certificates, and unauthorized access interfaces, providing direction for strengthening device security.

[0141] Overall, the implementation logic of the above-mentioned method for direct extraction and analysis of firmware file systems based on virtual mounting is as follows: Figure 4 As shown, the process begins with extracting the firmware from the NAND Flash device. Then, the `modprobe mtdblock ubi` command loads a key module from the Linux kernel that handles flash memory devices, preparing kernel-level support for building a virtual NAND environment. Next, the `nandsim` module creates a virtual MTD device with parameters (e.g., `id=0xef`, `0xaa`, etc.) identical to the physical parameters of the NAND chip, providing a virtual environment for subsequent data writing. Then, the virtual MTD device is associated, and the `nandwrite` command is used to write the firmware data image. During the writing process, specific parameters are specified to handle OOB data and ECC, ensuring the kernel automatically removes ECC and retains only clean data. After successful data writing, the `ubiattach` command is used to associate the virtual NAND device with the UBI management layer, and the `ubimkvol` command is used to create a logical volume on the UBI device. The `mount` command is used to mount the identified UBIFS file system logical volume to the local file system directory, enabling direct access and analysis of files within the firmware. Finally, the `cp -a` command copies all contents of the mounted file system to the local directory, completing the extraction process of firmware data from NAND into an analyzable file system.

[0142] The above process yields clean, structured, and directly analyzable firmware file system data, avoiding the complexity and uncertainty of traditional manual parsing. This significantly improves the efficiency and quality of firmware analysis, representing a major advancement in IoT device security research and digital forensics.

[0143] In this embodiment, a highly realistic virtual NAND environment is constructed using the Linux kernel's nandsim module and drivers such as MTD, UBI, and UBIFS. This enables automatic removal of ECC checksums and lossless extraction of file system structures from complex firmware data. This method breaks down the technical barriers of traditional manual reverse engineering, greatly improving the efficiency and accuracy of firmware analysis, and is particularly revolutionary for security auditing of IoT devices and embedded systems. It not only avoids dependence on specific hardware and proprietary algorithms but also standardizes and automates the firmware extraction process, making large-scale, rapid device firmware analysis possible.

[0144] According to embodiments of this application, a firmware extraction device is provided. It should be noted that the firmware extraction device of this application embodiment can be used to execute the firmware extraction method provided in this application embodiment. The firmware extraction device provided in embodiments of this application is described below.

[0145] Figure 5 This is a structural diagram of a firmware extraction device provided according to an embodiment of this application. Figure 5 As shown, the device includes:

[0146] Acquisition module 50 is used to acquire firmware data from the physical chip of the embedded device;

[0147] The determination module 52 is used to determine a virtual flash memory device that has the same hardware characteristics as the physical chip;

[0148] Error correction module 54 is used to perform error correction processing on firmware data and write the error-corrected target firmware data into a virtual flash memory device. The error correction processing includes automatically removing error check codes from firmware data and optimizing the data layout of firmware data through kernel driver.

[0149] Extraction module 56 is used to determine the file system layer corresponding to the target firmware data in the virtual flash device, and to export the target firmware data based on the file system layer.

[0150] By using the acquisition module, determination module, error correction module, and extraction module in the aforementioned firmware extraction device, the goal of extracting and accessing clean firmware data in virtual flash memory without loss and with high efficiency is achieved. This improves the efficiency of firmware data extraction and accelerates firmware reverse engineering and security analysis, thereby solving the technical problem of difficulty in firmware extraction and analysis of embedded devices caused by the complex physical characteristics of NAND Flash (including ECC and proprietary data layout).

[0151] In the firmware extraction device provided in this application embodiment, the acquisition module is further used to determine the adapter corresponding to the physical chip; repeatedly read the physical chip using a general programmer and the adapter to obtain first firmware data and second firmware data; perform byte comparison of the first firmware data and second firmware data in a Linux environment according to a preset comparison instruction to obtain a comparison result; if the comparison result indicates that the first firmware data and the second firmware data are consistent, confirm the first firmware data or the second firmware data as the firmware data of the physical chip.

[0152] In the firmware extraction device provided in this application embodiment, the determining module is further used to obtain the official datasheet of the physical chip, wherein the official datasheet stores the physical parameters of the physical chip; determine the simulation kernel module corresponding to the physical chip in the Linux environment; analyze the official datasheet through the simulation kernel module, and generate a virtual flash memory device corresponding to the physical chip.

[0153] In the firmware extraction device provided in this application embodiment, the error correction module is further used to process the third firmware data according to the preset error correction instructions to obtain the processing result, wherein the third firmware data is any page of data in the firmware data; if the processing result indicates that there is an error verification code or an error layout pattern in the third firmware data, the error verification code in the third firmware data is removed or the error layout pattern of the third firmware data is optimized to obtain the fourth firmware data; the fourth firmware data is written into the page data area in the virtual flash memory device, wherein the page data area includes a main data area and a backup data area for storing the fourth firmware data.

[0154] In the firmware extraction device provided in this application embodiment, the error correction module is further used to obtain the file system identifier of the target firmware data, wherein the file system identifier is used to reflect the file system type of the target firmware data; determine the starting offset address of the file system, wherein the starting offset address is used to indicate the starting position of the file system in the target firmware data; after obtaining the file system identifier and the starting offset address, write the target firmware data to the virtual flash memory device according to a preset write instruction, wherein the preset write instruction includes a first parameter and a second parameter, the first parameter is used to indicate that the firmware data contains backup data, and the second parameter is used to indicate that the firmware data is written starting from the starting offset address.

[0155] In the firmware extraction device provided in this application embodiment, the extraction module is further configured to determine the file system type of the target firmware data based on the file system identifier; determine the file system layer corresponding to the file system type; add the file system layer to the virtual flash device according to a preset add instruction; and identify the logical volume in the file system layer. The file system layer is used to represent the emulated file system management layer on the virtual flash device, and the logical volume is used to represent the basic logical unit for storing firmware data in the file system layer; mount the logical volume to the local directory according to a preset mount instruction; and extract the target firmware data after successful mounting.

[0156] In the firmware extraction device provided in this application embodiment, the extraction module is further used to scan the virtual flash memory device and obtain the erase / write counter information and volume identifier information of the virtual flash memory device header; after the firmware data is successfully written, the logical volume in the file system layer is determined according to the volume identifier information, and the running status of the logical volume is determined according to the erase / write counter information.

[0157] This application also provides an electronic device, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor is connected to the memory and used to execute the firmware extraction method described above.

[0158] It should be noted that the aforementioned electronic equipment is used to perform Figure 2The firmware extraction method shown above is also applicable to this electronic device, and will not be repeated here.

[0159] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the firmware extraction method described above by running the computer program.

[0160] It should be noted that the aforementioned non-volatile storage media is used for execution. Figure 2 The firmware extraction method shown above is also applicable to this non-volatile storage medium, and will not be repeated here.

[0161] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the above-described firmware extraction method.

[0162] It should be noted that the above-mentioned computer program product is used to execute Figure 2 The firmware extraction method shown above is also applicable to this computer program product, and will not be repeated here.

[0163] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0164] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0165] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0166] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0167] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0168] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0169] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A firmware extraction method, characterized in that, include: Obtain firmware data from the physical chip of an embedded device; Identify a virtual flash memory device that has the same hardware characteristics as the physical chip; The firmware data is subjected to error correction processing, and the target firmware data after error correction processing is written to the virtual flash memory device. The error correction processing includes automatically removing error check codes from the firmware data and optimizing the data layout of the firmware data through the kernel driver. In the virtual flash device, a file system layer corresponding to the target firmware data is determined, and the target firmware data is exported based on the file system layer.

2. The method according to claim 1, characterized in that, Obtain firmware data from the physical chip of the embedded device, including: Determine the adapter corresponding to the physical chip; The physical chip is repeatedly read using a general-purpose programmer and the adapter to obtain first firmware data and second firmware data; In the Linux environment, the first firmware data and the second firmware data are compared byte by byte according to a preset comparison instruction to obtain the comparison result; If the comparison result indicates that the first firmware data and the second firmware data are consistent, the first firmware data or the second firmware data shall be confirmed as the firmware data of the physical chip.

3. The method according to claim 2, characterized in that, Determining a virtual flash memory device having the same hardware characteristics as the physical chip includes: Obtain the official datasheet of the physical chip, wherein the official datasheet stores the physical parameters of the physical chip; In the Linux environment, determine the simulation kernel module corresponding to the physical chip; The simulation kernel module analyzes the official datasheet and generates a virtual flash memory device corresponding to the physical chip.

4. The method according to claim 1, characterized in that, Error correction processing of the firmware data includes: The third firmware data is processed according to the preset error correction instructions to obtain the processing result, wherein the third firmware data is any page of data in the firmware data; If the processing result indicates that there is an incorrect verification code or an incorrect layout pattern in the third firmware data, the incorrect verification code in the third firmware data is removed or the incorrect layout pattern of the third firmware data is optimized to obtain the fourth firmware data. The fourth firmware data is written into the page data area of ​​the virtual flash memory device, wherein the page data area includes a main data area and a backup data area for storing the fourth firmware data.

5. The method according to claim 4, characterized in that, Writing the error-corrected target firmware data into the virtual flash memory device includes: Obtain the file system identifier of the target firmware data, wherein the file system identifier is used to reflect the file system type of the target firmware data; Determine the starting offset address of the file system, wherein the starting offset address is used to represent the starting position of the file system in the target firmware data; After obtaining the file system identifier and the starting offset address, the target firmware data is written to the virtual flash device according to a preset write instruction. The preset write instruction includes a first parameter and a second parameter. The first parameter is used to indicate that the firmware data contains backup data, and the second parameter is used to indicate that the firmware data is written starting from the starting offset address.

6. The method according to claim 5, characterized in that, Determining the file system layer corresponding to the target firmware data in the virtual flash device, and exporting the target firmware data based on the file system layer, includes: The file system type of the target firmware data is determined based on the file system identifier; Determine the file system layer corresponding to the file system type, add the file system layer to the virtual flash device according to the preset add instruction, and identify the logical volume in the file system layer. The file system layer is used to represent the emulated file system management layer on the virtual flash device, and the logical volume is used to represent the basic logical unit in the file system layer that stores the firmware data. The logical volume is mounted to the local directory according to the preset mount command, and the target firmware data is extracted after successful mounting.

7. The method according to claim 6, characterized in that, Identifying logical volumes within the file system layer includes: Scan the virtual flash memory device and obtain the erase / write counter information and volume identifier information from the header of the virtual flash memory device; After the firmware data is successfully written, the logical volume in the file system layer is determined based on the volume identifier information, and the running status of the logical volume is determined based on the erase / write counter information.

8. A firmware extraction device, characterized in that, include: The acquisition module is used to acquire firmware data from the physical chip of the embedded device. A determination module is used to determine a virtual flash memory device that has the same hardware characteristics as the physical chip; An error correction module is used to perform error correction processing on the firmware data and write the error-corrected target firmware data into the virtual flash memory device. The error correction processing includes automatically removing error check codes from the firmware data and optimizing the data layout of the firmware data through a kernel driver. An extraction module is used to determine the file system layer corresponding to the target firmware data in the virtual flash device, and to export the target firmware data based on the file system layer.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; The processor, connected to the memory, is used to execute the firmware extraction method according to any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the firmware extraction method according to any one of claims 1 to 7 by running the computer program.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the firmware extraction method according to any one of claims 1 to 7.

Images