SPI Flash firmware extraction method and system based on Raspberry Pi

Abstract

The invention discloses an SPI Flash firmware extraction method and system based on Raspberry Pi, and belongs to the technical field of data recovery and extraction, and the method comprises the following steps: establishing physical connection between an SPI interface of the Raspberry Pi and an SPI Flash chip in a welding state on a PCB (Printed Circuit Board); starting an SPI drive on the raspberry Pi, and configuring the raspberry Pi as an SPI master device; an identification command is sent to the SPI Flash chip through the SPI interface, returned chip identification information is received and analyzed, and chip parameters are determined; according to the chip parameters, a reading command and an initial address are sent to the SPI Flash chip through the SPI interface, and data are read from the initial address; and storing the read data as a firmware file. According to the method and the device, non-destructive firmware extraction of the target chip is realized, the stored data can be directly read without performing desoldering operation, and the success rate and the overall efficiency of firmware extraction are improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of data recovery and extraction, and particularly relates to a Raspberry Pi-based SPI Flash firmware extraction method and system. BACKGROUND

[0002] The core functions of modern electronic devices all depend on the firmware stored in the non-volatile memory, and the firmware extraction technology is of great significance for device debugging, fault diagnosis, security analysis and intellectual property research. At present, there are three types of technical solutions for PCB board Flash firmware extraction: the first type is to use a special Flash programmer for off-chip reading, that is, the chip is disassembled by a hot air gun and placed in the programmer socket to complete data extraction; the second type is to use the reserved on-board debugging interface (such as JTAG) for online reading, and directly access the Flash memory using debugging commands; the third type is to use a logic analyzer or oscilloscope to passively monitor and decode the SPI bus communication. These technical solutions have their own implementation paths in different application scenarios, and constitute the technical foundation of the current firmware extraction field.

[0003] However, the above-mentioned prior art still has significant defects: the special programmer solution must physically disassemble the Flash chip from the PCB board, which depends on the high-temperature soldering process and is extremely prone to thermal damage and physical damage to the chip body, pins or PCB pads, and the required equipment is bulky and difficult to meet the needs of on-site rapid response; the JTAG debugging solution can be operated online, but mass-produced devices usually remove the debugging interface or disable the debugging function, and this method requires the operator to have deep knowledge of embedded systems and complex software configuration capabilities, which has a high technical threshold; as a passive monitoring tool, the logic analyzer solution cannot actively initiate a complete firmware reading operation, and has extremely low practicality, while high-performance analysis equipment is costly and the data analysis process is tedious and inefficient. These technical problems are rooted in the excessive dependence on special hardware, the complex and invasive nature of the operation process, and the passive limitations of the methodology, making it difficult to balance safety, cost-effectiveness and universality. SUMMARY

[0004] The present application aims to solve the problem of strong dependence on professional equipment, complex operation, high cost and risk of hardware damage when extracting firmware from the Flash memory on the PCB board.

[0005] To solve the above technical problems, the present application provides a Raspberry Pi-based SPI Flash firmware extraction method and system. The purpose is to provide a brand-new solution to achieve a better balance between operation safety, equipment cost, ease of use and technical universality.

[0006] A Raspberry Pi-based SPI Flash firmware extraction method comprises: physically connecting the SPI interface of the Raspberry Pi to the SPI Flash chip on the PCB in a soldered state; enabling the SPI driver on the Raspberry Pi and configuring the Raspberry Pi as an SPI master device; sending an identification command to the SPI Flash chip through the SPI interface, receiving and parsing the returned chip identification information, and determining the chip parameters; sending a read command and a starting address to the SPI Flash chip through the SPI interface according to the chip parameters, and reading data from the starting address; saving the read data as a firmware file.

[0007] Preferably, the process of physically connecting the SPI interface of the Raspberry Pi to the SPI Flash chip on the PCB in a soldered state comprises: determining the pin test point position of the SPI Flash chip on the PCB; directly connecting the SPI function pin of the Raspberry Pi GPIO interface to the test point through a wire to form an electrical connection path.

[0008] Preferably, the process of sending an identification command to the SPI Flash chip through the SPI interface, receiving and parsing the returned chip identification information comprises: sending a JEDEC ID read command to the SPI Flash chip through the SPI device node of the Raspberry Pi; receiving the JEDEC ID data returned by the SPI Flash chip; parsing the JEDEC ID data to obtain the manufacturer ID and device ID; querying a chip database according to the manufacturer ID and device ID to determine the model and capacity parameters of the SPI Flash chip.

[0009] Preferably, the process of sending a read command and a starting address to the SPI Flash chip through the SPI interface according to the chip parameters comprises: sending a read command to the SPI Flash chip; sending a 24-bit starting address to the SPI Flash chip; establishing a continuous reading timing to make the SPI Flash chip output data in address order.

[0010] Preferably, the process of reading data from the starting address comprises: initializing a data buffer; The read operation is performed repeatedly, reading a data block of a preset length each time. Each read data block is sequentially stored into the data buffer; Monitor the amount of data read, and terminate reading when the capacity indicated by the chip parameters is reached.

[0011] Preferably, after saving the read data as a firmware file, the method further includes: Perform the read operation again to obtain the second read data; Calculate the first hash value of the firmware file saved for the first time; Calculate the second hash value of the second read data; Compare the first hash value with the second hash value; if they match, the data integrity is confirmed.

[0012] This invention also provides a Raspberry Pi-based SPI Flash firmware extraction system, comprising: The Raspberry Pi hardware platform features SPI and GPIO interfaces. The physical connection module is used to electrically connect the Raspberry Pi's SPI interface to the SPI Flash chip that is soldered on the PCB board. The software control module runs on the Raspberry Pi platform and includes an SPI driver unit, a chip identification unit, a data reading unit, and a file saving unit. The SPI driver unit is used to configure the Raspberry Pi as an SPI master device. The chip identification unit is used to obtain the identification information of the SPI Flash chip through the SPI interface; The data reading unit reads chip data based on the identification information; The file storage unit stores the read data as a firmware file.

[0013] Preferably, the SPI interface of the Raspberry Pi hardware platform is implemented through GPIO pins, including: The MOSI pin is used to send commands and addresses to the SPI Flash chip; The MISO pin is used to receive data returned by the SPI Flash chip. The SCLK pin is used to provide the clock signal; The CE0 or CE1 pin is used to provide the chip select signal.

[0014] Preferably, the physical connection module includes a DuPont harness, the first end of which is connected to the SPI function pin of the Raspberry Pi GPIO interface, and the second end of which is connected to the test point of the SPI Flash chip on the PCB board. The DuPont wire harness is used to provide electrical path for the MOSI, MISO, SCLK, and CS signal lines of the SPI bus.

[0015] Preferably, the software control module further includes: The chip identification algorithm unit is used to parse the JEDEC ID data received through the SPI interface and determine the chip parameters; The data verification unit is used to perform a second reading and hash value comparison on the read data.

[0016] Compared with the prior art, the present invention has the following advantages and technical effects: This invention achieves non-invasive online firmware extraction, completely avoiding the risks of chip disassembly; it uses a general-purpose Raspberry Pi platform instead of dedicated equipment, reducing implementation costs by two orders of magnitude; through end-to-end software automation packaging, it simplifies the operation process to a level that ordinary technicians can master; the system is highly integrated and lightweight and portable, and can be quickly deployed in various field environments, effectively solving the technical problems of poor security, high cost, high threshold, and insufficient portability in existing technologies. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention; Figure 2 This is a hardware connection diagram according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the system structure according to an embodiment of the present invention. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] 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, and 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.

[0020] Example 1 like Figure 1 As shown, this embodiment provides a method for extracting SPI Flash firmware based on Raspberry Pi, including: Establish a physical connection between the Raspberry Pi's SPI interface and the SPI Flash chip that is soldered on the PCB board; Enable the SPI driver on the Raspberry Pi and configure the Raspberry Pi as an SPI master device; The chip identification command is sent to the SPI Flash chip via the SPI interface, and the returned chip identification information is received and parsed to determine the chip parameters. Based on the chip parameters, a read command and a start address are sent to the SPI Flash chip via the SPI interface, and data is read starting from the start address. Save the read data as a firmware file.

[0021] This embodiment creatively utilizes a general-purpose embedded computing platform to replace traditional dedicated hardware devices. In practice, a physical layer connection is first established. The phrase "in soldered state" means that the target SPI Flash chip remains in its original mounting position on the PCB board, without undergoing any thermal disassembly process. In actual operation, technicians need to use precision probes or miniature test hooks to contact the chip pins, or preferably connect them to pre-reserved test pads on the PCB.

[0022] The Raspberry Pi's SPI interface serves as the hardware foundation, implemented using the SPI controller integrated into the BCM2835 / BCM2837 series chips. This controller supports clock frequencies up to 10MHz, fully meeting the read speed requirements of mainstream SPI Flash chips.

[0023] Enabling the SPI driver involves configuring Linux kernel modules, specifically by activating the SPI0 or SPI1 interface using the raspi-config tool or by manually modifying the / boot / config.txt file, and loading the spidev driver to generate device nodes such as / dev / spidev0.0.

[0024] The chip identification command follows the JEDEC standard protocol, obtaining the manufacturer ID, memory type, and capacity information by sending the 0x9F instruction. This identification process requires precise timing control, including pulling the chip select signal low, serially sending the command byte, and receiving the subsequent 3-4 bytes of ID data.

[0025] The read command is sent in standard SPI mode 0 (CPOL=0, CPHA=0). The command byte 0x03 followed by a 24-bit address constitutes a complete read command sequence.

[0026] In the data storage process, the file system's write buffer mechanism is taken into consideration. In this embodiment, the Linux sync command is used to ensure that the data is completely written to the SD card storage medium.

[0027] The entire process is automated using Python scripts or C programs. The spidev library or py-spi module provides the necessary API interfaces, enabling upper-layer applications to complete complex low-level hardware interactions with concise code.

[0028] The method in this embodiment is particularly suitable for scenarios where destructive operations are not permitted, such as firmware backup of devices during the warranty period, file preservation of rare devices, or evidence preservation in security analysis.

[0029] Due to the openness and scalability of the Raspberry Pi platform, this method can also integrate network functionality for remote firmware extraction, or support parallel reading of multiple chips by adding a GPIO expansion board, significantly improving work efficiency. In industrial environments, this method can be deployed on a Raspberry Pi Compute Module, achieving more reliable industrial-grade connectivity through a customized carrier board, meeting the stability requirements for 24 / 7 operation.

[0030] For high-capacity NAND Flash chips, this method can be adaptively extended through segmented reading and bad block management algorithms. Although this increases software complexity, it maintains the non-intrusive advantage of the core architecture. In power-sensitive applications, energy consumption can be optimized by dynamically adjusting the SPI clock frequency and Raspberry Pi CPU frequency, enabling the system to complete the extraction task on battery power.

[0031] This embodiment enables non-destructive firmware extraction from the target chip, allowing direct reading of stored data without desoldering operations. This significantly reduces the difficulty of hardware operations and the risk of physical damage to the PCB board and chip, thereby improving the success rate and overall efficiency of firmware extraction.

[0032] Furthermore, the process of establishing a physical connection between the Raspberry Pi's SPI interface and the SPI Flash chip that is soldered on the PCB board includes: Determine the pin test point locations of the SPI Flash chip on the PCB board; Connect the SPI function pins of the Raspberry Pi's GPIO interface directly to the test point using wires to form an electrical connection path.

[0033] Furthermore, in this embodiment, when determining the test point location, a visual inspection is first performed to identify the pin 1 location of the SPI Flash chip, determined by the dots or notches marked on the chip surface. Then, the diode mode or continuity test function of a multimeter is used to trace the traces of each pin to find easily accessible test points on the PCB. These test points may be vias, test pads, or pathways connecting to other ICs.

[0034] For high-density packages such as WSON or USON, directly solder fine wires (e.g., 30AWG enameled wire) to the pins using a miniature soldering iron tip and flux, keeping the operation time under 2 seconds to avoid overheating. Figure 2 As shown, the SPI function pin assignments of the Raspberry Pi GPIO interface follow the BCM numbering standard, where GPIO10 (pin 19) is MOSI, GPIO9 (pin 21) is MISO, GPIO11 (pin 23) is SCLK, and GPIO8 (pin 24) is CE0.

[0035] In this embodiment, the length of the connecting cable is controlled within 30 cm to reduce signal reflection and crosstalk. For higher frequency operation (>5MHz), a 100Ω series resistor can be added to the cable for impedance matching. The reliability of the electrical connection is verified using an oscilloscope to check whether the signal edges are steep and whether there is ringing. In complex electromagnetic environments, shielded twisted-pair cables are used and the shielding layer is grounded at a single point.

[0036] For scenarios requiring simultaneous extraction of multiple chips, a daisy-chain topology is used to connect the MOSI-MISO pins of multiple Flash chips in series, controlling them individually via independent chip select lines. The Raspberry Pi device tree configuration is modified to enable multiple CS pins. Level compatibility must also be considered during the connection process. Most Raspberry Pi GPIOs are 3.3V, while some older Flash chips may support 5V; direct connection could cause damage. In such cases, a level converter chip like the TXB0108 is required. In industrial applications, the physical connection module can be encapsulated within a 3D-printed housing, integrating spring probes and magnetic adsorption mechanisms for fast and reliable temporary connections.

[0037] For PCBs without test points, a PCB fixture with a pogo pin array can be used to establish contact through mechanical pressure. This approach has been used in mass production testing. After connection, it is recommended to run the SPI bus test program, send pseudo-random data and read it back for verification, reducing the physical layer error rate. This is a prerequisite for reliable firmware reading later. In extreme environments (such as humidity or vibration), connection points should be coated with conformal coating or protected with heat shrink tubing.

[0038] This embodiment establishes a non-intrusive signal access method, making full use of existing test points on the PCB to achieve electrical connection, avoiding thermal or mechanical damage to the chip body and circuit board, fully maintaining the circuit continuity and functionality of the target device, and supporting the normal operation of the extracted device.

[0039] Furthermore, the process of sending an identification command to the SPI Flash chip via the SPI interface and receiving and parsing the returned chip identification information includes: Send a JEDEC ID read command to the SPI Flash chip via the Raspberry Pi's SPI device node; Receive JEDEC ID data returned by the SPI Flash chip; Parse the JEDEC ID data to obtain the manufacturer ID and device ID; The model and capacity parameters of the SPI Flash chip are determined by querying the chip database using the manufacturer ID and device ID.

[0040] Furthermore, this embodiment specifically includes the following regarding the chip identification mechanism: In a Raspberry Pi Linux environment, implementing SPI communication via the spidev device node requires opening a file descriptor, configuring the transfer mode, setting the word length (usually 8 bits), and the maximum speed. Commands are sent using the ioctl system call or read / write operations, depending on the chosen programming interface.

[0041] After sending the 0x9F command, the timing specified in the chip manual must be strictly followed: wait at least 5ns (tCSS) after the chip select is pulled low before sending the command. After the command is sent, the chip will start returning data after 8 clock cycles.

[0042] The returned JEDEC ID typically contains a 1-byte manufacturer ID (e.g., 0xEF for Winbond, 0xC2 for Macronix), a 1-byte memory type, and a 1-byte capacity code (0x17 for 8MB, 0x18 for 16MB). For modern chips with capacities exceeding 16MB, there may also be a 4th byte extended ID.

[0043] The parsing algorithm establishes a lookup table or database that maps the original ID to the complete chip specification. This database can be stored in JSON or SQLite format for easy querying and updating.

[0044] In practical implementation, the identification process may encounter challenges: some security chips return all zeros or fixed values ​​as a protection mechanism, requiring attempts to send a deprotection command (such as the 0x66+0x99 write enable sequence); some chips support the SFDP (Serial Flash Discoverable Parameters) table, allowing more detailed configuration information to be read via the 0x5A command. The chip identification unit should be fault-tolerant, automatically reducing the SPI clock rate for retrying when the initial identification fails, as some older chips may respond abnormally at the default high speed. After successful identification, the system should automatically configure read parameters, including page size (typically 256 bytes), sector size (4KB or 64KB), and total chip capacity. For hybrid memory architecture chips (such as NOR+NAND hybrid), the identification process also needs to distinguish between different memory regions.

[0045] In terms of software architecture, the recognition function is encapsulated as an independent module, supporting plug-in expansion to new chip models, with each chip type corresponding to a driver class. The recognition phase logs fully record the original ID value, parsing results, and the command sequence used, facilitating subsequent troubleshooting. For batch processing scenarios, the recognition process can be parallelized, using multi-threading to send recognition commands to multiple chips simultaneously, improving efficiency.

[0046] In extreme cases, if the chip does not respond at all, the system will attempt all combinations of standard SPI modes 0-3, as some chips power on in a non-standard mode. The robustness of the identification algorithm directly affects the compatibility of the entire system; therefore, this embodiment has undergone extensive field testing, covering at least 50 chip models from mainstream manufacturers. After identification, the system automatically verifies the results, confirming that the chip is working properly by reading the chip status register (0x05 command) and checking whether the write-protect bit has been correctly cleared.

[0047] This embodiment achieves automatic identification of chip specifications and intelligent parameter matching, enabling rapid acquisition of chip attributes without the need for manual consultation of technical manuals. It enhances the method's universal adaptability to different chip models and improves the accuracy and automation of the identification process.

[0048] Furthermore, based on the chip parameters, the process of sending a read command and starting address to the SPI Flash chip via the SPI interface includes: Send a read command to the SPI Flash chip; Send the 24-bit start address to the SPI Flash chip; Establish a continuous read timing sequence so that the SPI Flash chip outputs data in address order.

[0049] Furthermore, this embodiment includes the following steps for constructing and sending the read command: In this embodiment, for managing the chip select signal (CS#), it is necessary to ensure that CS# is high for at least tCSH time (typically 50ns) before sending the command, and then pull CS# low to start transmission. The transmission order of the 24-bit start address follows big-endian mode, that is, first send the most significant byte (bits 23-16 of the address), then send the middle byte (bits 15-8), and finally send the least significant byte (bits 7-0). A continuous SCLK clock is required between each address byte, and no additional CS# switching is needed.

[0050] To understand the chip's output behavior, establish a continuous read timing sequence: After the 8th falling clock edge of the last byte of the address, the chip's internal address pointer automatically increments, and data bytes begin to be output on the next rising clock edge. Data output timing parameters include tV (output valid time, typically <10ns) and tHO (output hold time), which determine when the Raspberry Pi samples the MISO line.

[0051] For high-speed reading, the clock frequency is adjusted to the maximum value allowed by the chip, such as 104MHz. However, due to the 10MHz limit of the Raspberry Pi SPI controller, the actual operating frequency is usually set to 5-8MHz.

[0052] The read command sequence is implemented through synchronous or asynchronous transmission via spidev. The asynchronous mode allows other tasks to be performed while waiting for the chip to respond, thus improving efficiency.

[0053] The address range handling takes into account the chip's boundary behavior: when the last address 0xFFFFFF is read, the chip automatically wraps back to 0x000000, which can be used to verify the integrity of the read.

[0054] For modern high-capacity chips (>16MB) that support 4-byte address mode, 32-bit address is used for reading after entering 4-byte mode (sending the 0xB7 command).

[0055] The command transmission fault tolerance mechanism includes timeout detection. If no data is returned within 500ms after chip select, communication should be considered a failure and retried. In level conversion scenarios, the level conversion of the command byte is performed synchronously on all signal lines to avoid timing deviations.

[0056] Command read tests are performed using loopback mode: MOSI and MISO are shorted, a known command sequence is sent, and the readback data is confirmed to be consistent. In multi-chip systems, the CS# signal needs to be controlled independently. The Raspberry Pi can increase the number of chip select lines using a GPIO expansion chip (such as the MCP23S17). The software implementation for command sending should use memory-mapped I / O to directly manipulate the SPI registers to achieve the lowest possible latency, rather than through the spidev kernel module. This is especially important in scenarios with extremely high performance requirements.

[0057] Optimizations to read commands also include batch transmission, packaging multiple commands and addresses into a single system call to reduce context switching overhead. For chips requiring security authentication (such as certain secure Flash memory), an authentication command sequence is sent before reading, and the command transmission log records the timing parameters of each byte, facilitating comparison and verification with waveforms captured by a logic analyzer.

[0058] This embodiment constructs an efficient data stream transmission mechanism, which maximizes the SPI bus data throughput through a continuous address auto-increment read mode, reduces instruction interaction overhead, and significantly improves the speed and efficiency of firmware data extraction.

[0059] Furthermore, the process of reading data starting from the beginning address includes: Initialize the data buffer; The read operation is performed repeatedly, reading a data block of a preset length each time. Each read data block is sequentially stored into the data buffer; Monitor the amount of data read, and terminate reading when the capacity indicated by the chip parameters is reached.

[0060] Furthermore, this embodiment addresses the implementation of the data read loop by dynamically allocating memory based on the chip capacity during data buffer initialization. For large-capacity chips (e.g., 128MB), memory-mapped file technology is used to map the buffer to the disk, preventing RAM exhaustion. The predetermined length (block size) for each read needs to balance efficiency and reliability. For example, in this embodiment, it can be set to 4096 bytes (one page) or 8192 bytes, which corresponds to the block size of the file system, optimizing IO performance.

[0061] The termination condition for loop reads needs to be precisely calculated: for an 8MB chip (0x800000 bytes), the loop terminates when the address counter increments from 0x000000 to 0x7FFFFF. The address increment algorithm updates the pointer after each block read: address += block_size. Data block storage operations should consider byte alignment; the buffer should use 64-bit aligned memory addresses to improve DMA transfer efficiency.

[0062] Error detection during the read process is achieved by checking the validity of each byte: if a large number of 0xFF or 0x00 appear, it may indicate that the chip is not responding or is in a write-protected state.

[0063] Monitoring the amount of data read is implemented through a progress bar or percentage display, improving the user experience. For scenarios with uneven reading (such as skipping bad blocks), the buffer supports sparse storage, using a marker bitmap to record the location of valid data.

[0064] Concurrency optimization for loop reads employs a double-buffering technique: one buffer is used for the current read, and the other for background writes to storage devices; these two are used alternately to hide I / O latency. In a real-time operating system (RTOS) environment, read tasks should be set to high priority to avoid preemption by other tasks and subsequent timing disruptions.

[0065] Data integrity verification is performed at the block level: after each read, the CRC16 of the block is calculated and compared with the chip's internal ECC (if supported). For chips that support high-throughput reads (such as QSPI mode), the loop is extended to 4-bit parallel reads, which is based on the BIOS configuration support of the Raspberry Pi GPIO. In the power-loss protection design, after each block read is completed, it is immediately flushed to non-volatile memory, and the breakpoint address is recorded to support breakpoint resumption.

[0066] Boundary case handling for loop reads includes: when the chip capacity is not an integer multiple of the block size, the last read should be adjusted to the remaining number of bytes; for chips with address wraparound, the wraparound flag is detected to prevent infinite loops. In a multi-threaded environment, buffer access is protected by locking to avoid race conditions. Read speed optimization is achieved by adjusting the SPI clock divider and the Raspberry Pi core frequency. Power management in the loop involves briefly shutting down the SPI controller clock after each block read to reduce dynamic power consumption, suitable for battery-powered scenarios. The read log should record the start address, length, time, and status code of each block in detail for performance analysis and fault location.

[0067] This embodiment ensures the complete acquisition of firmware data. Through block reading and capacity threshold monitoring mechanisms, it effectively avoids data loss caused by incomplete or out-of-bounds reading, and ensures the consistency between the extracted data and the original storage content of the chip.

[0068] Furthermore, after saving the read data as a firmware file, it also includes: Perform the read operation again to obtain the second read data; Calculate the first hash value of the firmware file saved for the first time; Calculate the second hash value of the data read twice; Compare the first hash value with the second hash value; if they match, the data integrity is confirmed.

[0069] Furthermore, this embodiment also introduces a data integrity verification mechanism, which is a necessary guarantee for ensuring firmware reliability.

[0070] Specifically, the second read operation strictly follows all parameters of the first read, including clock frequency, block size, and latency settings, ensuring that the conditions for the two reads are completely consistent. Hash value calculation uses either the MD5 or SHA-256 algorithm. On the Raspberry Pi, hash calculation is implemented using the openssl library or the hashlib module.

[0071] The initial hash calculation for the firmware file is performed after the file is closed, ensuring that all cached data has been written to disk. Subsequent hash calculations for data reads are performed incrementally during the read process, avoiding the storage of intermediate data and saving space.

[0072] Hash value comparison employs a constant-time comparison function to prevent timing attacks from leaking hash information. After integrity verification, the system generates a verification report containing both hash values, along with a timestamp and operator information, meeting forensic requirements. If the hashes do not match, the system enters diagnostic mode: first, it verifies the physical connection of the read circuit; then, it reduces the SPI rate and retryes; finally, it compares the specific byte differences between the two read results to pinpoint the error location. Error injection testing shows that the detection probability of a single-bit error in hash comparison is 99.9999%, meeting reliability requirements.

[0073] In industrial applications, the verification mechanism can be expanded to a triple-redundant read: three independent reads, with at least two consistent results considered correct. Resource optimization of hash calculations leverages the Raspberry Pi's NEON coprocessor for parallel acceleration, improving efficiency.

[0074] For extremely large files, a block hashing strategy is adopted: the file is divided into 1MB blocks, hashes are calculated for each block, and a Merkle tree is constructed to quickly locate corrupted areas.

[0075] Emergency procedures for verification failures include: automatically switching to a backup SPI controller (e.g., using SPI1 instead of SPI0), increasing the pull-up resistor strength of the signal lines, or enabling hardware CRC verification (if the SPI controller supports it).

[0076] In security-critical scenarios, the hash value is calculated using the HMAC algorithm in conjunction with the key to prevent malicious tampering. The verification process is visualized using LED indicators connected to the Raspberry Pi GPIO: green indicates success, red indicates failure, and yellow indicates retrying. The verification log should record the time consumption, memory usage, and result status of each comparison for system performance evaluation.

[0077] Multi-chip batch verification employs parallel computing, utilizing the four cores of the Raspberry Pi to simultaneously calculate multiple hashes, thereby improving throughput. In the cloud computing integration solution, verification results can be uploaded to a cloud database in real time, enabling centralized monitoring and auditing.

[0078] A complete implementation of the verification mechanism also includes precondition checks: verifying sufficient storage space, correct file permissions, and no error state in the SPI driver. In the fault-tolerant design, a certain percentage of bit errors (such as ECC-correctable errors) are allowed to still be considered as passing the verification, improving system usability.

[0079] This embodiment establishes a reliable data integrity verification mechanism. Through dual reading and hash verification, it can effectively detect and identify bit errors or transmission anomalies that may occur during the reading process, significantly improving the reliability, accuracy, and traceability of firmware extraction results.

[0080] As a preferred implementation, this embodiment describes in detail a method for extracting PCB board Flash firmware using the Raspberry Pi's SPI interface, the steps of which are as follows: Step S1, Hardware Connection: Prepare a Raspberry Pi single-board computer, ensuring it has an operating system installed. Identify the pin definitions of the SPI interface in the Raspberry Pi's GPIO interface. In this embodiment, the SPI0 interface pins of the Raspberry Pi are: SCLK, MOSI, MISO, and CS. Identify the pins of the SPI Flash chip on the target PCB board. The SPI Flash chip typically has the following pins: VCC (power supply), GND (ground), SCLK (serial clock), MOSI (master output, slave input), MISO (master input, slave output), and CS# (chip select, active low). Some chips may also have WP# (write protection) and HOLD# (hold) pins. For read-only operations, these can be left floating or connected to a high level according to the chip datasheet. Use DuPont wires to connect the Raspberry Pi's SPI interface pins to the corresponding pins of the SPI Flash chip. Raspberry Pi SPI SCLK pin → Flash chip SCLK pin Raspberry Pi SPI MOSI pin → Flash chip MOSI pin Raspberry Pi SPI MISO pin → Flash chip MISO pin Raspberry Pi SPI CS0 pin → Flash chip CS# pin.

[0081] If the Flash chip power supply on the target board is compatible with the Raspberry Pi's GPIO levels, a stable 3.3V power supply and GND can be provided via the Raspberry Pi. Otherwise, ensure that the target board is powered off during connection or that its Flash chip power supply is normal and does not conflict with the Raspberry Pi's power supply to avoid damaging the device. Throughout this process, the SPI Flash chip remains on the target PCB and is not removed.

[0082] Step S2, Enable SPI Driver: On the Raspberry Pi, enable the SPI interface via command line or graphical interface tool, and restart the Raspberry Pi for the configuration to take effect; after the SPI driver is enabled, the system will create an SPI device node in the / dev / directory; install the necessary SPI communication library or tools so that subsequent software can communicate with the SPI peripheral through this device node.

[0083] Step S3, Chip Identification: Run the firmware extraction program on the Raspberry Pi; the program first initializes the SPI device node and configures the communication parameters; the chip identification module of the software control layer sends a chip identification command to the SPI Flash chip.

[0084] Furthermore, a JEDEC ID read command (instruction code 0x9F) is sent. The timing of this command is typically as follows: pull the CS# pin low to select the chip, send instruction 0x9F via the MOSI line, and the chip will then return its JEDEC ID via the MISO line, which usually includes a 1-byte manufacturer ID and a 1-2 byte device ID. The chip identification module receives and parses the returned JEDEC ID data. The parsed ID combination is compared with a preset chip database (containing information such as the JEDEC ID, model, capacity, and page size of known SPI Flash chips) to automatically identify the specific model and storage capacity of the currently connected SPI Flash chip.

[0085] Step S4, Data Reading and Saving: Based on the chip model and storage capacity identified in step S3, the data reading module of the software control layer determines the reading parameters; the data reading module sends a read data command to the SPI Flash chip.

[0086] Furthermore, the commonly used "Read Data Bytes" command (instruction code 0x03) is sent. The timing sequence is as follows: pull CS# low; send instruction 0x03; then send a 24-bit start address (e.g., 0x000000). After that, the chip will continuously output data starting from this start address from the MISO line. The system starts from the start address 0x000000 and performs read data operations in a loop. Each time, a certain length of data block is read, and the read data is written to the Raspberry Pi's local storage medium through the storage module. This continues until the entire storage capacity of the chip is covered, that is, from the start address to the end address (e.g., 0x0FFFFF), completing the reading of the complete firmware data.

[0087] Step S5, Data Verification: The verification module of the software control layer initiates the data integrity verification process.

[0088] Method 1 (Two-way reading and comparison): 1. The verification module controls the data reading module to read the complete data from the SPI Flash chip again using the same parameters (command, address, block size) as in step S4, and obtain the second set of data; 2. Start byte-by-byte comparison: Starting from address 0x000000, compare every byte of the first data (original firmware) and the second data (verification data); 3. Termination condition: If any byte is found to be inconsistent, the comparison will stop immediately, and the error message "Data inconsistent, address: 0xXXXXXX (address of inconsistent byte)" will be output, prompting the user to check the hardware connection or reread; if all bytes are consistent, the message "Second read comparison passed, data complete" will be output.

[0089] Method 2 (Hash Value Verification): 1. The verification module calls a hash algorithm library (such as Python's hashlib library) to calculate the hash value of the first piece of raw firmware data, supporting both MD5 and SHA-256 algorithms (MD5 is used by default). 2. Perform the same hash calculation on the second set of verification data; 3. Compare the hash values ​​obtained from the two calculations: If they match, output "Hash verification passed, MD5 value", and write the hash value to the verification log in the same directory as the firmware file. If they do not match, output "Hash check failed, data may be corrupted"; 4. If the user only selects hash verification (without performing a second read), then only the hash value of the original firmware will be calculated and displayed for the user to compare with firmware obtained from other channels later.

[0090] Example 2 like Figure 3 As shown, based on the same inventive concept, this embodiment also provides a Raspberry Pi-based SPIFlash firmware extraction system, including: The Raspberry Pi hardware platform features SPI and GPIO interfaces. The physical connection module is used to electrically connect the Raspberry Pi's SPI interface to the SPI Flash chip that is soldered on the PCB board. The software control module runs on the Raspberry Pi platform and includes an SPI driver unit, a chip identification unit, a data reading unit, and a file saving unit. The SPI driver unit is used to configure the Raspberry Pi as an SPI master device. The chip identification unit is used to obtain the identification information of the SPI Flash chip through the SPI interface; The data reading unit reads chip data based on the identification information; The file storage unit stores the read data as a firmware file.

[0091] Furthermore, the Raspberry Pi hardware platform's SPI interface is implemented through GPIO pins, including: The MOSI pin is used to send commands and addresses to the SPI Flash chip; The MISO pin is used to receive data returned by the SPI Flash chip. The SCLK pin is used to provide the clock signal; The CE0 or CE1 pin is used to provide the chip select signal.

[0092] Furthermore, the physical connection module includes a DuPont harness, with the first end of the DuPont harness connected to the SPI function pin of the Raspberry Pi GPIO interface and the second end of the DuPont harness connected to the test point of the SPI Flash chip on the PCB board. DuPont wire harnesses are used to provide electrical pathways for the MOSI, MISO, SCLK, and CS signal lines of the SPI bus.

[0093] Furthermore, the software control module also includes: The chip identification algorithm unit is used to parse the JEDEC ID data received through the SPI interface and determine the chip parameters; The data verification unit is used to perform a second reading and hash value comparison on the read data.

[0094] The Raspberry Pi-based SPI Flash firmware extraction system provided in this embodiment has all the advantages of the Raspberry Pi-based SPI Flash firmware extraction method provided in Embodiment 1.

[0095] Furthermore, for example, the Raspberry Pi hardware platform in this embodiment can use a Raspberry Pi 3B+ or later, which has more stable power management and better thermal design.

[0096] The electrical characteristics of the SPI interface must meet the following requirements: output high level ≥ 2.4V, low level ≤ 0.4V, and input threshold conforming to the 3.3V CMOS standard.

[0097] The GPIO interface current is limited to 16mA per pin, with a total current not exceeding 50mA, to ensure that the IO load of the Flash chip does not exceed this limit.

[0098] The mechanical design of the physical connection module takes stress relief into account to avoid damage to the GPIO pins from repeated plugging and unplugging.

[0099] The software control module adopts a layered architecture: the bottom layer is the SPIdev driver, the middle layer is the protocol processing library, and the top layer is the application logic. The SPI driver unit is configured in SPI master mode, and the clock polarity (CPOL) and phase (CPHA) are selected according to the target chip, usually set to (0, 0).

[0100] Enabling the DMA transfer mode of the driver unit can free the CPU from data movement and improve system response speed.

[0101] The chip identification unit is implemented as an independent service, supporting RESTful API calls, which makes it easy to integrate into a web interface.

[0102] The data read unit can handle timing anomalies. When the MISO line is detected to be continuously high or low for more than 10ms, the watchdog mechanism is triggered to reset the SPI controller.

[0103] The file storage unit's write strategy uses direct I / O (with the O_DIRECT flag) to bypass the kernel cache, reducing the number of copies and implementing access control to prevent unauthorized reading of sensitive firmware.

[0104] As an alternative implementation, the system’s modular design allows for the replacement of core components: for example, replacing the Raspberry Pi with a compatible board such as Rock64 only requires modifying the driver unit; or upgrading the physical connection module to a wireless one (such as a Wi-Fi module extended via GPIO) without changing the rest of the units.

[0105] The system's resource configuration prioritizes SPI interrupts to prevent data loss; software modules are locked to run on specific CPU cores to improve cache hit rate. For power management, GPIO pull-ups are disabled and CPU frequency is reduced during idle periods, while full-speed operation is maintained during read operations.

[0106] System observability is revealed through Prometheus metrics, including read speed, error rate, and chip recognition success rate, facilitating operation and maintenance monitoring. Fault injection tests demonstrate that the system can recover or gracefully degrade even under conditions such as a single signal line disconnection, clock jitter ±10%, and power supply fluctuation ±5%.

[0107] System security hardening includes: storing firmware files with AES-256 encryption, enabling Secure Boot on the Raspberry Pi to prevent unauthorized code execution, and using SELinux to restrict software module permissions. In containerized deployment, each unit can be packaged as an independent Docker image and communicate via message queues, improving deployment flexibility.

[0108] As an optional implementation, the system's scalability is also reflected in: it can support up to 8 SPI Flash connections simultaneously via an I2C expansion chip; and it can power multiple target boards simultaneously using the Raspberry Pi's PoE+ power supply, simplifying wiring.

[0109] The system's electromagnetic compatibility design follows these principles: a 33Ω resistor in series with the clock line, matched signal line lengths, and complete copper plating on the ground plane. Mass production deployment of the system can utilize a Raspberry Pi Compute Module 4, integrated onto a custom carrier board, to achieve industrial-grade reliability.

[0110] This embodiment achieves "online reading," meaning that the SPI Flash chip does not need to be removed from the target PCB board. Instead, it is directly connected to the chip pins or test points on the PCB board via DuPont wires. This fundamentally avoids the risk of hardware damage such as chip damage or PCB board pad detachment that may be caused by soldering and disassembly operations, and achieves non-destructive operation on the target device.

[0111] The core hardware platform of this embodiment is a Raspberry Pi single-board computer, which is much cheaper than traditional dedicated programmers, especially high-end programmers. The Raspberry Pi itself is a general-purpose computing platform. In addition to being used for firmware extraction in this embodiment, it can also be used for many other purposes. It has a high hardware cost utilization rate, and the physical connection only requires inexpensive DuPont wires. The overall hardware investment of the solution is extremely low and easy to popularize.

[0112] This embodiment integrates and automates the software process, encapsulating complex SPI protocol communication details, chip model identification, data reading and verification tasks into a software module. Users only need to perform simple hardware connections and execute preset scripts or program commands to complete the entire firmware extraction process. Users do not need to have an in-depth understanding of SPI protocol details or master complex programmer operation skills, which greatly reduces the technical threshold.

[0113] The entire system in this embodiment consists of a compact Raspberry Pi and a few DuPont wires. It is lightweight and easy to carry. The Raspberry Pi has a built-in power management and storage system and can work independently without the need to connect to a bulky computer host. This makes the system very suitable for rapid firmware diagnosis and data extraction of devices in the field, improving work efficiency and emergency response capabilities.

[0114] This embodiment implements an automatic firmware data verification mechanism through a verification module in the software control layer. By performing secondary reading comparisons and hash value verification, the accuracy and integrity of the extracted firmware data can be effectively ensured, avoiding invalid data caused by transmission errors or storage problems.

[0115] Example 3 This embodiment also discloses a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described in Embodiment 1.

[0116] Example 4 This embodiment also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in Embodiment 1.

[0117] Example 5 This embodiment also discloses a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in Embodiment 1.

[0118] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for extracting SPI Flash firmware based on Raspberry Pi, characterized in that, include: Establish a physical connection between the Raspberry Pi's SPI interface and the SPI Flash chip that is soldered on the PCB board; Enable the SPI driver on the Raspberry Pi and configure the Raspberry Pi as an SPI master device; The system sends an identification command to the SPI Flash chip via the SPI interface, receives and parses the returned chip identification information, and determines the chip parameters. Based on the chip parameters, a read command and a start address are sent to the SPI Flash chip via the SPI interface, and data is read starting from the start address. Save the read data as a firmware file.

2. The method according to claim 1, characterized in that, The process of establishing a physical connection between the Raspberry Pi's SPI interface and the SPI Flash chip that is soldered on the PCB board includes: Determine the pin test point locations of the SPI Flash chip on the PCB board; Connect the SPI function pins of the Raspberry Pi's GPIO interface directly to the test point using wires to form an electrical connection path.

3. The method according to claim 1, characterized in that, The process of sending an identification command to the SPI Flash chip via the SPI interface and receiving and parsing the returned chip identification information includes: Send a JEDEC ID read command to the SPI Flash chip via the Raspberry Pi's SPI device node; Receive the JEDEC ID data returned by the SPI Flash chip; Parse the JEDEC ID data to obtain the manufacturer ID and device ID; The chip database is queried based on the manufacturer ID and device ID to determine the model and capacity parameters of the SPI Flash chip.

4. The method according to claim 1, characterized in that, The process of sending a read command and starting address to the SPI Flash chip via the SPI interface according to the chip parameters includes: Send a read command to the SPI Flash chip; Send a 24-bit start address to the SPI Flash chip; Establish a continuous read timing sequence so that the SPI Flash chip outputs data in address order.

5. The method according to claim 1, characterized in that, The process of reading data starting from the aforementioned address includes: Initialize the data buffer; The read operation is performed repeatedly, reading a data block of a preset length each time. Each read data block is sequentially stored into the data buffer; Monitor the amount of data read, and terminate reading when the capacity indicated by the chip parameters is reached.

6. The method according to claim 1, characterized in that, After saving the read data as a firmware file, the following is also included: Perform the read operation again to obtain the second read data; Calculate the first hash value of the firmware file saved for the first time; Calculate the second hash value of the second read data; Compare the first hash value with the second hash value; if they match, the data integrity is confirmed.

7. A Raspberry Pi-based SPI Flash firmware extraction system, characterized in that, include: The Raspberry Pi hardware platform features SPI and GPIO interfaces. The physical connection module is used to electrically connect the Raspberry Pi's SPI interface to the SPI Flash chip that is soldered on the PCB board. The software control module runs on the Raspberry Pi platform and includes an SPI driver unit, a chip identification unit, a data reading unit, and a file saving unit. The SPI driver unit is used to configure the Raspberry Pi as an SPI master device. The chip identification unit is used to obtain the identification information of the SPI Flash chip through the SPI interface; The data reading unit reads chip data based on the identification information; The file storage unit stores the read data as a firmware file.

8. The system according to claim 7, characterized in that, The SPI interface of the Raspberry Pi hardware platform is implemented through GPIO pins, including: The MOSI pin is used to send commands and addresses to the SPI Flash chip; The MISO pin is used to receive data returned by the SPI Flash chip. The SCLK pin is used to provide the clock signal; The CE0 or CE1 pin is used to provide the chip select signal.

9. The system according to claim 7, characterized in that, The physical connection module includes a DuPont harness, with the first end of the DuPont harness connected to the SPI function pin of the Raspberry Pi GPIO interface and the second end of the DuPont harness connected to the test point of the SPI Flash chip on the PCB board. The DuPont wire harness is used to provide electrical path for the MOSI, MISO, SCLK, and CS signal lines of the SPI bus.

10. The system according to claim 7, characterized in that, The software control module also includes: The chip identification algorithm unit is used to parse the JEDEC ID data received through the SPI interface and determine the chip parameters; The data verification unit is used to perform a second reading and hash value comparison on the read data.

Images