Embedded equipment debugging method and device, electronic device and storage medium

Abstract

The invention relates to a debugging method and device of embedded equipment, an electronic device and a storage medium, and the debugging method of the embedded equipment comprises the steps: obtaining instruction set information of the embedded equipment through a UART (Universal Asynchronous Receiver / Transmitter) interface; configuring a corresponding cross compiling component based on the instruction set information; compiling a preset probe source code into an executable file by utilizing a cross compiling component; extracting a minimum code subset in the executable file, and determining a code probe according to the minimum code subset; and injecting the code probe into the free memory space on the embedded device through the UART interface, and debugging the embedded device. According to the method and the device, the problem of low debugging flexibility of the embedded equipment is solved.

Description

Technical Field

[0001] The present application relates to the embedded field, and in particular to a debugging method, device, electronic device and storage medium for embedded devices. Background Art

[0002] The Internet of Things (IoT) connects any object to the Internet through information sensing devices and agreed protocols to achieve intelligent identification, positioning, tracking, monitoring and management. The debugging of IoT devices usually relies on embedded device debugging tools and technologies. In related technologies, hardware debugging interfaces such as the Joint Test Action Group (JTAG) interface and the Serial Wire Debug (SWD) port are widely used in the debugging of embedded devices; these interfaces interact with dedicated hardware devices and development tools, allowing reverse engineers to directly observe and operate the status of embedded devices. However, the use of these hardware debugging interfaces is subject to certain restrictions: some devices may disable these interfaces for security or commercial protection considerations, or the interfaces themselves are not configured during hardware design, thereby limiting the scope and flexibility of embedded device debugging.

[0003] Currently, no effective solution has been proposed for the problem of low flexibility in debugging embedded devices in related technologies. Summary of the invention

[0004] Embodiments of the present application provide a debugging method, apparatus, electronic device, and storage medium for an embedded device, so as to at least solve the problem of low flexibility in debugging of embedded devices in the related art.

[0005] In a first aspect, an embodiment of the present application provides a debugging method for an embedded device, the method comprising:

[0006] Obtaining instruction set information of the embedded device through a Universal Asynchronous Receiver / Transmitter (UART) interface;

[0007] Based on the instruction set information, a corresponding cross-compilation component is configured; using the cross-compilation component, a preset probe source code is compiled into an executable file;

[0008] Extracting a minimum code subset from the executable file, and determining a code probe based on the minimum code subset;

[0009] The code probe is injected into the free memory space on the embedded device through the UART interface, and the embedded device is debugged.

[0010] In some embodiments, the cross-compilation component includes a compiler and a linker; using the cross-compilation component to compile the preset probe source code into an executable file includes:

[0011] The compiler is used to cross-compile the probe source code into an intermediate target file, and the linker is used to link the intermediate target file into the executable file.

[0012] In some embodiments, linking the intermediate target file into the executable file using the linker includes:

[0013] In the process of linking by using the linker, unused code segments in the intermediate target file are determined and removed to obtain the executable file.

[0014] In some embodiments, extracting the minimum code subset in the executable file includes:

[0015] Determine and remove the symbol information in the executable file to obtain a new executable file;

[0016] The new executable file is converted into a binary file, and the minimum code subset is obtained based on the binary file.

[0017] In some embodiments, injecting the code probe into the free memory space on the embedded device through the UART interface includes:

[0018] Obtaining memory usage information of the embedded device through the UART interface;

[0019] The free memory space is determined according to the memory usage information, and the code probe is injected into the free memory space.

[0020] In some embodiments, injecting the code probe into the free memory space on the embedded device through the UART interface and debugging the embedded device includes:

[0021] Integrate the embedded software on the embedded device into the simulation device by using hardware-in-the-loop technology;

[0022] The code probe is run on the simulation device, and when a memory mapped input / output (MMIO) operation is triggered, the simulation device obtains device status data from the embedded device through the UART interface;

[0023] The embedded device is debugged based on the device status data.

[0024] In some embodiments, injecting the code probe into the free memory space on the embedded device through the UART interface and debugging the embedded device includes:

[0025] Injecting the code probe into the free memory space on the embedded device through the UART interface, and modifying the register address pointer of the embedded device to point to the target address pointer of the code probe;

[0026] Based on the target address pointer, the code probe is run and the embedded device is debugged.

[0027] In a second aspect, an embodiment of the present application provides a debugging device for an embedded device, comprising:

[0028] An instruction set acquisition module, used to acquire instruction set information of the embedded device through a UART interface;

[0029] A compiling module, configured to configure a corresponding cross-compilation component based on the instruction set information; and compile a preset probe source code into an executable file using the cross-compilation component;

[0030] A minimum code extraction module, used to extract a minimum code subset from the executable file and determine a code probe based on the minimum code subset;

[0031] The debugging module is used to inject the code probe into the free memory space on the embedded device through the UART interface and debug the embedded device.

[0032] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the debugging method for the embedded device as described in the first aspect above is implemented.

[0033] In a fourth aspect, an embodiment of the present application provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the debugging method of the embedded device as described in the first aspect above is implemented.

[0034] Compared with the related art, the debugging method, device, electronic device and storage medium of the embedded device provided in the embodiments of the present application obtain the instruction set information of the embedded device through the UART interface; configure the corresponding cross-compilation component based on the instruction set information; use the cross-compilation component to compile the preset probe source code into an executable file; extract the minimum code subset in the executable file, and determine the code probe based on the minimum code subset; inject the code probe into the free memory space on the embedded device through the UART interface, and debug the embedded device.

[0035] Based on this, efficient debugging of black box IoT devices is achieved through the UART interface, allowing the use of the UART interface memory read and write function to dynamically inject code probes into the memory space of the embedded device to be debugged at runtime, thereby achieving real-time monitoring and modification of embedded device behavior, so that even if the embedded device does not open a dedicated hardware debugging interface, debugging and control tasks can be completed, effectively improving the flexibility of debugging embedded devices. In addition, by dynamically injecting a small volume probe of a minimum code subset into the code, debugging can be performed without relying on an interface, and the memory occupancy is small, which is suitable for the debugging needs of embedded devices in a limited resource environment, avoiding the problem that the existing memory embedded gdb debugger, although it can partially replace the hardware debugging interface, is difficult to adapt to the low memory requirements of embedded devices due to the large memory occupation, especially in a resource-limited environment.

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

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

[0038] Figure 1 It is a hardware structure block diagram of a terminal of a debugging method for an embedded device according to an embodiment of the present application;

[0039] Figure 2 is a flowchart of a debugging method for an embedded device according to an embodiment of the present application;

[0040] Figure 3 is a flowchart of another method for debugging an embedded device according to an embodiment of the present application;

[0041] Figure 4 It is a structural block diagram of a debugging device for an embedded device according to an embodiment of the present application. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application. In addition, it can also be understood that although the efforts made in this development process may be complex and lengthy, for ordinary technicians in the field related to the contents disclosed in the present application, some changes such as design, manufacturing or production based on the technical contents disclosed in the present application are only conventional technical means, and should not be understood as insufficient contents disclosed in the present application.

[0043] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0044] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantitative limitation, and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to greater than or equal to two. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships, for example, "A and / or B" can represent: A exists alone, A and B exist at the same time, and B exists alone. The terms "first", "second", "third" and the like involved in the present application are merely used to distinguish similar objects and do not represent a specific ordering of the objects.

[0045] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. Taking running on a terminal as an example, Figure 1 1 is a hardware structure block diagram of a terminal of a debugging method for an embedded device according to an embodiment of the present application. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Optionally, the terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0046] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the debugging method of the embedded device in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a 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 a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0047] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0048] This embodiment provides a debugging method for an embedded device. Figure 2 is a flowchart of a debugging method for an embedded device according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0049] Step S210, obtaining instruction set information of the embedded device through the UART interface.

[0050] UART interface is often used for serial communication on embedded devices. Through the UART interface, you can send commands to the embedded device and receive its response. Before starting to compile the code, you need to obtain the instruction set architecture, operating system version and other hardware information of the embedded device to be debugged. This information can be obtained through the following ways:

[0051] Get device information through the UART interface. Specifically, developers can usually communicate with the target device through the UART interface and run commands such as uname -a or / proc / cpuinfo to get the device's hardware information and instruction set architecture. This information is very important for choosing the correct compiler and target platform when cross-compiling.

[0052] Or you can get device information from embedded device documentation. That is, if the system documentation or specification of the device is available, it usually clearly lists the supported instruction sets such as ARMv7, ARM64, Microprocessor without Interlocked Pipeline Stages (MIPS), and Reduced Instruction Set Computer-Version Five (RISC-V), as well as the operating systems such as Linux and Real-Time Operating System (RTOS).

[0053] Step S220: configuring a corresponding cross-compilation component based on the instruction set information; and compiling the preset probe source code into an executable file using the cross-compilation component.

[0054] The probe source code is a specific piece of code used in embedded systems, software development, or network monitoring to perform specific detection, monitoring, or debugging tasks. The source code is written depending on the specific application scenario and the target device to be debugged; for example, for embedded systems, programming languages ​​such as C or C++ may be needed to ensure the efficiency and portability of the code.

[0055] In order to meet the requirements of running on a specific target platform, the probe source code generated above needs to be cross-compiled. Cross-compilation specifically refers to compiling on one platform to generate executable code for another platform. Since embedded devices usually use a processor architecture different from that of the host, a cross-compilation tool chain is required. The core of cross-compilation is to generate corresponding executable files according to the hardware architecture of the embedded device; based on this, once the instruction set information of the embedded device is obtained, a suitable cross-compilation tool chain can be installed on the host for the embedded device.

[0056] Through cross-compilation, reverse engineers can generate adaptive software for multiple hardware architectures, which speeds up the multi-platform development process, especially when they cannot directly access the development environment of the target device (i.e., the embedded device to be debugged).

[0057] Specifically, according to the instruction set information obtained, select a suitable cross-compilation tool chain. For example, if the device uses the Advanced RISC Machine (ARM) architecture, select a cross-compilation tool chain for ARM (such as arm-none-eabi-gcc). Next, configure the cross-compilation environment, including setting environment variables and paths, and use the cross-compilation tool chain to compile the preset probe source code to generate an executable file suitable for the embedded device. Among them, the executable file can be an executable and linkable format (ELF) file; ELF is the standard format of executable files in Linux systems. The ELF file contains the program code, data segment, symbol table, debugging information, etc. required for the embedded device to be debugged.

[0058] Step S230 , extracting a minimum code subset from the executable file, and determining a code probe according to the minimum code subset.

[0059] A code probe is a code snippet used to monitor and analyze program behavior. A minimal code subset can be extracted from a compiled executable file and injected into an embedded device as a probe.

[0060] In the development of embedded devices, especially when debugging or simulating embedded devices through the UART interface, the generated binary executable files (such as ELF files) are usually very large, containing a large number of unnecessary symbols, debugging information and unused code segments. In order to solve this problem, in this step, a minimum subset extraction technology is proposed. The core idea is to extract the minimum binary subset containing only the code and data required for actual operation from the generated ELF file, so as to reduce the file size and improve the debugging and simulation efficiency of the device.

[0061] Specifically, binary analysis tools (such as objdump, readelf, etc.) can be used to analyze executable files and extract their code segments; based on the analysis results, the smallest code subset is determined and extracted, which usually contains basic initialization, function call and return logic. Finally, the corresponding code probe is written or generated based on the smallest code subset.

[0062] Step S240, injecting the code probe into the spatial memory space on the embedded device through the UART interface, and debugging the embedded device.

[0063] In order to enable the injected code probe to be called at runtime, the developer can modify the PC or function address pointer to force the embedded device to jump to the code probe when executing to a specific location. For example, during the function call process, the function pointer can be modified to point to the starting address of the code probe. This modification can be done by directly writing to the register or memory address; modifying the value of the PC register to the starting address of the code probe 0x8000 will make the embedded device jump directly to the code probe at the next execution.

[0064] Through the above method, the dynamic injection of code probes is realized. Among them, the dynamic injection technology through code probes is an efficient debugging and monitoring technology, which is suitable for embedded system and device debugging, especially in scenarios where device behavior needs to be observed in real time and dynamically modified. This technology allows reverse engineers to dynamically inject a minimum code subset as a probe into the memory of the embedded device to be debugged through the memory read and write function provided by the UART interface, and call these probes by modifying the program counter (PC) or function address pointer, thereby realizing the monitoring and debugging of device behavior. The core idea of ​​this technology is non-invasive dynamic insertion and debugging, that is, by inserting lightweight code probes into the device memory, it does not affect the normal operation of the embedded device, and can also track the embedded device status, memory allocation and key indicators.

[0065] In the above-mentioned debugging method for embedded devices, efficient debugging of black box IoT devices is achieved through the UART interface, and the UART interface memory read and write function is allowed to be used at runtime to dynamically inject code probes into the memory space of the embedded device to be debugged, thereby achieving real-time monitoring and modification of embedded device behavior, so that even if the embedded device does not open a dedicated hardware debugging interface, debugging and control tasks can be completed, effectively improving the flexibility of debugging embedded devices. In addition, by dynamically injecting a small volume probe of a minimum code subset into the code, debugging can be performed without relying on an interface, and the memory occupancy is small, which is suitable for the debugging needs of embedded devices in a limited resource environment, avoiding the existing memory embedded GNU debugger (GNU symbolic debugger, GDB) Although it can partially replace the hardware debugging interface, it is difficult to adapt to the low memory requirements of embedded devices due to the large memory occupation, especially the problem of limited resource environments.

[0066] In some embodiments, the cross-compilation component includes a compiler and a linker; more specifically, the cross-compilation tool chain (i.e., the cross-compilation component) consists of a compiler, a linker, a standard library, and a debugging tool. Common cross-compilation tool chains include the GNU Compiler Collection (GCC) and Clang (a lightweight compiler), both of which support compilation for multiple architectures. The following are the steps to install and configure the cross-compilation tool chain:

[0067] For the GCC toolchain, you can use the package manager to install the cross compiler on a Linux system. For Clang, you can specify the target architecture through compilation parameters (such as the parameter --target=). For the Linaro toolchain (a cross-compilation toolchain that provides high-quality development tools and software stacks for ARM architecture devices), Linaro provides an optimized GCC cross-compilation toolchain for the ARM architecture. The Linaro toolchain is often used to develop embedded applications with high performance requirements.

[0068] The above-mentioned cross-compilation component is used to compile the preset probe source code into an executable file, and the following steps may also be included:

[0069] The probe source code is cross-compiled into an intermediate object file using a compiler, and the intermediate object file is linked into an executable file using a linker.

[0070] The key process of cross-compilation is described below. First, compile the source code; compile the probe source code into the machine code of the embedded device to be debugged. Then insert the assembly code in the embedded assembly stage. That is, when developing embedded devices, it is usually necessary to insert the assembly code of the target architecture into the C language code, and both GCC and Clang support the syntax of embedded assembly. When cross-compiling, the compiler will generate the corresponding machine code according to the assembly instruction set of the target architecture; for example, when compiling for ARM, the generated machine code will use the ARM instruction set.

[0071] After the compiler generates the intermediate target file (usually in ELF format), in the linking stage, all the intermediate target files and library files need to be linked into the final executable file through the connector; among them, the cross compiler component comes with a linker suitable for the embedded device architecture to be debugged. In the linking stage, you can use the -L and -I parameters to specify the library path and header file path of the embedded device to be debugged.

[0072] Through the above embodiments, cross-compilation of the probe source code is achieved. When cross-compiling, the compiler can take into account the processor architecture, memory size, instruction set and other characteristics of the target platform to generate more efficient code; the linker can further optimize the code during the linking process, such as removing unused code segments, merging identical code segments, etc., thereby reducing the size of the executable file and improving operating efficiency.

[0073] In some embodiments, the above-mentioned linking of the intermediate target file into an executable file using a linker may further include the following steps:

[0074] In the process of linking using the linker, unused code segments in the intermediate target file are determined and removed to obtain an executable file.

[0075] First, for the basic process of cross-compilation, in the compilation rule file (Makefile), it is performed through Clang, and the generated target file is linked as an ELF file. The compilation process is as follows: specify the compilation parameters through the C compiler flag (CFLAGS) to ensure that the generated code is independent of the operating system (-ffreestanding) and does not contain the implementation of the standard library (-fno-builtin). Next, link through the linker flag (LDFLAGS); a specific linker script link.ld is used during the linking process, and the --gc-sections (a linker option related to the linker) parameter is used to delete unused code segments. These configurations ensure that the generated ELF file only contains the code and data sections that are actually required.

[0076] Secondly, in the process of generating ELF files, the compilation and linking process mainly generates the intermediate target file ($.o) and the final symbol file ($(TARGET).sym) through the following steps: (1) Use the arm-none-eabi-ld linker to link the compiled object file ($(OBJ)) into a symbol file. It should be noted that the symbol file also contains some unnecessary symbols and debugging information, and does not fully meet the requirements of minimum subset extraction. (2) Remove symbol information; Among them, the strip tool (a tool under the Linux system that can remove the symbol table of the executable file) can be used to further streamline the ELF file, remove the symbol table and debugging information, and generate the smallest executable file; in this step, arm-none-eabi-strip is a tool specifically used to remove unnecessary symbols in ARM architecture binary files. Through strip, the debugging symbols, symbol table and other information in the ELF file can be removed, significantly reducing the size of the file so that it only retains the code and data segments required for execution.

[0077] Through the above embodiment, unused code and data segments can be automatically removed by using the --gc-sections option during linking; this is one of the key technologies for extracting the minimum subset, which ensures that the generated ELF file only contains the code and data parts that are actually referenced.

[0078] In some embodiments, the above-mentioned extraction of the minimum code subset in the executable file may also include the following steps:

[0079] The symbol information in the executable file is determined and removed to obtain a new executable file; the new executable file is converted into a binary file, and a minimum code subset is obtained based on the binary file.

[0080] The next step is to further streamline the ELF file through the strip tool, remove the symbol table and debugging information, and generate the smallest executable file. Among them, the strip tool can remove the debugging symbols, symbol table and other information in the ELF file, significantly reducing the file size, so that it only retains the code and data segments required for execution.

[0081] After obtaining the streamlined ELF file, use the objcopy tool (a command line tool that is mainly used to copy and convert the contents of the target file) to convert it to the original binary file. objcopy allows you to extract the required data from the ELF file and generate a binary file with the smallest subset. This step uses arm-none-eabi-objcopy to convert the ELF file to the smallest binary format. -O binary means that it will be output as a bare binary file, containing only the most basic code and data segments, further reducing the file size.

[0082] In addition to generating bin files, Makefile also supports generating files in Intel HEX format (a file format used to store and transmit data to embedded devices); for example, using the -Oihex option of objcopy, you can convert ELF files to Intel HEX format files. Intel HEX format is a commonly used embedded system firmware format, which is convenient for burning firmware into devices.

[0083] Through the above embodiment, further streamlining of the executable file is achieved by automatically removing the symbol table and debugging information of the executable file.

[0084] In some embodiments, the above-mentioned step of injecting the code probe into the free memory space on the embedded device through the UART interface may also include the following steps:

[0085] The memory usage information of the embedded device is obtained through the UART interface; the free memory space is determined according to the memory usage information, and the code probe is injected into the free memory space.

[0086] Among them, the working principle of the code probe Shellcode dynamic injection technology is divided into the following key steps:

[0087] Identify the target memory area. The device's memory space needs to be divided into allocated areas for programs and data, and unused or dynamically allocated areas. Through the read and write functions of the UART interface, developers can find out which memory addresses on the device are not occupied by the current application or operating system, ensuring that the probe code is injected into the unused memory space.

[0088] Injecting Shellcode (a piece of code that is executed to exploit a software vulnerability). The developer writes a piece of Shellcode for monitoring or debugging and injects it into the unused memory of the device. The Shellcode may contain monitoring logic for specific system resources (such as memory, registers, etc.), or code to capture the parameters and return values ​​of certain functions.

[0089] Modify the program counter or function address pointer. In order to trigger these Shellcode probes at runtime, developers modify the device's PC register or function address pointer through the UART interface, changing the target code originally pointed to to point to the injected Shellcode probe. This modification method can insert debugging logic without interrupting or affecting the normal execution of the program.

[0090] Real-time monitoring and behavior modification. Once the probe is executed, Shellcode will monitor the device's operating status in real time (such as memory read and write, register operation, function call status, etc.) and feedback this information to the developer. Developers can modify certain behaviors of the device through Shellcode, such as changing the function return value, modifying the value of a global variable, etc.

[0091] Through the above embodiment, the Shellcode minimum subset extraction technology is used to gradually remove the redundant information and unused code segments after compilation, so as to ensure that only the minimum binary file required for device execution is generated. This technology can not only significantly reduce the size of the binary file and improve the debugging efficiency on the embedded device, but also reduce the memory usage, which plays an important role in the resource-constrained environment, thereby automatically and accurately extracting the minimum executable code and data part through the integration of the automated tool chain, effectively simplifying the binary reduction process in embedded development.

[0092] In some embodiments, the method of injecting the code probe into the free memory space on the embedded device through the UART interface and debugging the embedded device may also include the following steps:

[0093] The embedded software on the embedded device is integrated into the simulation device by using the hardware-in-the-loop technology. The code probe is run on the simulation device, and when the memory-mapped input and output (MMIO) operation is triggered, the simulation device obtains the device status data from the embedded device through the UART interface. The embedded device is debugged based on the device status data.

[0094] Hardware-in-the-Loop (HIL) simulation technology is a key technology in embedded system development. It integrates physical hardware devices with the simulation environment to achieve near-real-time testing of device code execution. The core advantage of this technology is that it provides a controlled and repeatable test environment, allowing developers to interact with real hardware while running software in a simulation device. By simulating the state of input, output, and external environment, software development, debugging, and testing are more accurate and efficient.

[0095] When using an emulation device such as QEMU (an open source machine emulator and virtualizer) to emulate a device, the device may need to perform memory-mapped I / O (MMIO) access to the hardware, and the behavior of these hardware parts can interact with the UART through pre-implanted probes, obtain the status from the physical hardware device, and then synchronize it to the emulation device, thereby achieving collaborative work between software and hardware.

[0096] The following is an explanation of the basic principles of hardware-in-the-loop simulation. Hardware-in-the-loop (HIL) technology integrates physical hardware devices into the simulation system, allowing developers to interact with real hardware when running embedded software in a simulation environment. Specifically, the software runs in the simulation device, and when encountering hardware-related operations (such as MMIO access), the simulation device can simulate the real hardware behavior through real-time interaction with the physical hardware to obtain more accurate operation results.

[0097] The core components of hardware-in-the-loop simulation include:

[0098] Emulation device: runs embedded software in a virtual environment. The emulation device includes core components such as CPU and memory.

[0099] UART interface: Through the UART interface, the simulation device can interact with the physical hardware device to simulate real input and output scenarios.

[0100] Hardware devices are used to provide real external environment status or specific hardware behaviors (such as sensors and peripheral status).

[0101] Probe Shellcode: Lightweight debugging code injected into the device to pass information between the emulated device and the hardware to synchronize MMIO operations.

[0102] The key advantage of HIL lies in the collaborative work between the virtual environment and physical hardware. In embedded system development, simulation devices (such as QEMU) can simulate most of the functions of the device, but when it comes to hardware-related operations (such as device register access and peripheral status monitoring), simulation devices cannot completely replace real hardware.

[0103] Therefore, hardware-in-the-loop technology allows developers to achieve virtual-real integration in the following ways:

[0104] MMIO access: When the code running on the emulated device needs to access the hardware device (such as reading registers or accessing external devices), these operations are usually implemented through MMIO. MMIO is a mechanism that maps the registers or buffers of the hardware device into the memory space, allowing the CPU to read or write the hardware device directly through the memory address.

[0105] Interaction between probe and UART: In the simulation environment, the probe (Shellcode) is implanted in the target code in advance. When the simulation device executes the MMIO operation related to the hardware, the probe will be triggered, and the simulation device will send a request to the physical hardware device through the UART interface to obtain the actual device status or results. The physical hardware device returns the corresponding data according to the request, and the simulation device synchronizes this data to the virtual memory of the simulator, thereby simulating the hardware behavior. For example, when QEMU simulates an embedded device, when the running software attempts to read a register of the device (such as the sensor status register), the simulation device will send a read request to the real hardware device through UART, and the hardware device will return the current sensor status. After receiving the status, the simulation device continues to execute.

[0106] The process of hardware-in-the-loop simulation mainly includes the following steps:

[0107] Pre-implant probes (Shellcode). Before debugging with HIL, you first need to implant probes in the target code or emulated device. These probes are lightweight shellcodes that can monitor key memory operations or MMIO access points. Once the probe is triggered, it sends a signal to the real hardware device via UART, asking it to return relevant status or data. The following is a simple probe shellcode example that monitors MMIO access and requests hardware status via UART:

[0108]

[0109] In the above example, when the emulated device runs to the code that accesses mmio_address, the shellcode is triggered and sends the content of this address to the hardware device via UART.

[0110] After that, the UART interaction is synchronized with the hardware. When the simulated device accesses MMIO, it first calls the probe Shellcode, and the probe sends a request to the physical hardware device through UART. After receiving the request, the hardware device returns status information or data according to the probe's requirements. For example, if the probe requests to read the current status of the sensor, the hardware device will return the actual status of the sensor to the simulated device through UART.

[0111] After receiving the data returned by the hardware, the simulation device writes it to the virtual memory area of ​​MMIO so that the subsequent code can continue to execute. This process is carried out in real time, ensuring that the simulation device can accurately simulate the hardware behavior.

[0112] After obtaining the corresponding status data from the physical hardware, the simulation device continues to execute the code in the simulation environment. This combination of virtual and real ensures that during the software debugging process, even if it involves specific hardware operations, the results can be fed back through the real hardware device.

[0113] Through the above process, developers can obtain real-time operation data of physical hardware while running embedded software in the simulation device, so as to conduct accurate code testing and verification. Due to the high flexibility of the hardware-in-the-loop simulation system, developers can also modify the probe logic or virtual environment parameters to simulate different device states and inputs, further speeding up the debugging process.

[0114] In some embodiments, the method of injecting the code probe into the free memory space on the embedded device through the UART interface and debugging the embedded device may also include the following steps:

[0115] Through the UART interface, the code probe is injected into the free memory space on the embedded device, and the register address pointer of the embedded device is modified to point to the target address pointer of the code probe; based on the target address pointer, the code probe is run and the embedded device is debugged.

[0116] In order to trigger these Shellcode probes at runtime, developers modify the device's PC register address pointer or function address pointer through the UART interface, changing the original target code to point to the injected Shellcode probe. This modification method can insert debugging logic without interrupting or affecting the normal execution of the program.

[0117] Specifically, the UART interface is used as a communication means to send the pre-prepared code probe data to the embedded device. These code probes are designed to be executed in the specific environment of the embedded device to collect debugging information or perform debugging operations. In the embedded device, find the key registers (such as the program counter or instruction pointer) that control the execution flow of the program. Modify the values ​​of these registers to point to the target address of the code probe in the free memory space of the embedded device; the purpose of this step is to allow the embedded device to jump to the code probe during execution, thereby starting to execute the debugging task.

[0118] Once the execution flow of the embedded device jumps to the code probe, the probe will start to perform its predetermined debugging tasks. These tasks may include collecting system status information, checking variable values, triggering breakpoints, recording execution paths, etc. Through this debugging information, developers can analyze the running status of the embedded device and locate and solve problems.

[0119] The present application is described below in conjunction with specific embodiments. Taking the debugging and cracking process of a solid-state hard disk (SSD) controller based on a UART interface as an example, the process includes the following steps:

[0120] Step S301, accurate work and target selection. Among them, determine the controller model of the SSD solid state drive and check whether it has a UART interface. Since many SSD controllers reserve a UART interface for factory testing and debugging, but it may be disabled or hidden when officially shipped from the factory, if it is detected that the UART interface of the device is disabled, it is necessary to find the location of the UART interface and activate it.

[0121] Step S302, debug the code by cross-compiling. In order to communicate and operate with the SSD controller, a debugging and control program can be written in a high-level programming language. The program is compiled into a binary file executable by the target controller using cross-compilation technology to adapt to the hardware architecture of the SSD controller. Since the SSD controller may be based on different hardware platforms (such as ARM, MIPS, etc.), binary files suitable for different platforms can be generated by cross-compilation to ensure that the code runs correctly on the controller.

[0122] Step S303, extracting the minimum Shellcode subset. Specifically, according to the requirements of SSD controller debugging, the Shellcode minimum subset extraction technology is used to automatically generate Shellcode containing only key instructions to implement basic operations on the SSD controller (such as data reading and writing and status monitoring). This step can greatly reduce the memory occupied by the code, thereby adapting to the resource limitations of the SSD controller and reducing the performance impact during the debugging process.

[0123] Step S304, dynamic injection of code probe. Use the UART interface to connect to the SSD controller, and use the code probe Shellcode dynamic injection technology to read and write the memory of the SSD controller through the UART, and embed the debug probe into the target code. This probe can monitor the operating status and memory allocation of the SSD controller in real time without affecting normal operation. For example, when executing data read and write commands, we can dynamically obtain the location and content of the currently written data to further analyze the encryption and compression algorithms of the SSD.

[0124] Step S305, hardware-in-the-loop (HIL) simulation test. During the debugging process, the SSD controller is integrated into a virtual simulation environment through hardware-in-the-loop (HIL) simulation technology. In the simulation environment, the UART interface is used to simulate external input and data flow (such as simulating read data flow or write instructions), so as to test the operation effect and cracking progress of the SSD controller in a controllable environment. This allows us to simulate multiple attack methods in a secure environment, such as data reading, decryption operations, etc.

[0125] Step S306, analyze and verify the cracking effect. After the entire debugging and cracking process is completed, the operation records and data content of the SSD controller are exported through the UART interface to verify whether the data obtained by the debugging probe is accurate and whether the cracking operation achieves the expected effect. Finally, based on the analyzed data, the controller's firmware algorithm (such as encryption mechanism, compression scheme) is reversed and cracked to further understand its internal operating mechanism.

[0126] Through the above embodiments, it is possible to debug and crack the SSD controller without the need for a hardware debugging interface, and effectively identify its firmware algorithm and data storage method. This debugging and cracking method based on the UART interface greatly improves work efficiency and is also applicable to other types of embedded device debugging and reverse engineering scenarios.

[0127] It should be noted that the steps shown in the above process or 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 can be executed in an order different from that shown here.

[0128] This embodiment also provides a debugging device for an embedded device, which is used to implement the above-mentioned embodiments and preferred implementation modes, and will not be repeated hereafter. As used below, the terms "module", "unit", "subunit", etc. may be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0129] Figure 4 is a structural block diagram of a debugging device for an embedded device according to an embodiment of the present application, such as Figure 4 As shown, the device comprises:

[0130] The instruction set acquisition module 41 is used to obtain the instruction set information of the embedded device through the UART interface; the compilation module 42 is used to configure the corresponding cross-compilation component based on the instruction set information; the preset probe source code is compiled into an executable file using the cross-compilation component; the minimum code extraction module 43 is used to extract the minimum code subset in the executable file and determine the code probe based on the minimum code subset; the debugging module 44 is used to inject the code probe into the free memory space on the embedded device through the UART interface and debug the embedded device.

[0131] In some embodiments, the cross-compilation component includes a compiler and a linker; the compilation module 42 is also used to cross-compile the probe source code into an intermediate target file using the compiler, and to link the intermediate target file into an executable file using the linker.

[0132] In some of the embodiments, the compiling module 42 is further used to determine and remove unused code segments in the intermediate target file during the linking process using the linker to obtain an executable file.

[0133] In some embodiments, the minimum code extraction module 43 is also used to determine and remove symbol information in the executable file to obtain a new executable file; the minimum code extraction module 43 is also used to convert the new executable file into a binary file and obtain a minimum code subset based on the binary file.

[0134] In some of the embodiments, the debugging module 44 is also used to obtain memory usage information of the embedded device through the UART interface; the debugging module 44 is also used to determine the free memory space according to the memory usage information, and inject the code probe into the free memory space.

[0135] In some of the embodiments, the above-mentioned debugging module 44 is also used to integrate the embedded software on the embedded device into the simulation device by using hardware-in-the-loop technology; the debugging module 44 is also used to run code probes on the simulation device, and when the memory mapped input and output MMIO operation is triggered, the simulation device obtains device status data from the embedded device through the UART interface; the debugging module 44 is also used to debug the embedded device based on the device status data.

[0136] In some of the embodiments, the above-mentioned debugging module 44 is also used to inject the code probe into the free memory space on the embedded device through the UART interface, and modify the register address pointer of the embedded device to point to the target address pointer of the code probe; the debugging module 44 is also used to run the code probe based on the target address pointer and debug the embedded device.

[0137] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0138] This embodiment further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0139] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0140] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0141] S1, obtains the instruction set information of the embedded device through the UART interface.

[0142] S2, based on the instruction set information, configure the corresponding cross-compilation component; use the cross-compilation component to compile the preset probe source code into an executable file.

[0143] S3, extracting a minimum code subset from the executable file, and determining a code probe based on the minimum code subset.

[0144] S4, injects the code probe into the free memory space on the embedded device through the UART interface and debugs the embedded device.

[0145] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0146] In addition, in combination with the debugging method of the embedded device in the above embodiment, the embodiment of the present application can provide a storage medium for implementation. The storage medium stores a computer program; when the computer program is executed by the processor, any one of the debugging methods of the embedded device in the above embodiment is implemented.

[0147] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0148] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0149] Those skilled in the art should understand that the technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0150] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A debugging method for an embedded device, characterized in that: The method comprises: Obtaining instruction set information of the embedded device through a universal asynchronous receiver / transmitter (UART) interface; Based on the instruction set information, a corresponding cross-compilation component is configured; using the cross-compilation component, a preset probe source code is compiled into an executable file; Extracting a minimum code subset from the executable file, and determining a code probe based on the minimum code subset; The code probe is injected into the free memory space on the embedded device through the UART interface, and the embedded device is debugged.

2. The debugging method according to claim 1, characterized in that: The cross-compilation component includes a compiler and a linker; using the cross-compilation component to compile the preset probe source code into an executable file includes: The compiler is used to cross-compile the probe source code into an intermediate target file, and the linker is used to link the intermediate target file into the executable file.

3. The debugging method according to claim 2, characterized in that: The linker is used to link the intermediate target file into the executable file, comprising: In the process of linking by using the linker, unused code segments in the intermediate target file are determined and removed to obtain the executable file.

4. The debugging method according to claim 1, characterized in that: The extracting the minimum code subset in the executable file comprises: Determine and remove the symbol information in the executable file to obtain a new executable file; The new executable file is converted into a binary file, and the minimum code subset is obtained based on the binary file.

5. The debugging method according to claim 1, characterized in that: The step of injecting the code probe into the free memory space on the embedded device through the UART interface includes: Obtaining memory usage information of the embedded device through the UART interface; The free memory space is determined according to the memory usage information, and the code probe is injected into the free memory space.

6. The debugging method according to claim 1, characterized in that: The method of injecting the code probe into the free memory space on the embedded device through the UART interface and debugging the embedded device includes: Integrate the embedded software on the embedded device into the simulation device by using hardware-in-the-loop technology; The code probe is run on the simulation device, and when a memory mapped input / output (MMIO) operation is triggered, the simulation device obtains device status data from the embedded device through the UART interface; The embedded device is debugged based on the device status data.

7. The debugging method according to any one of claims 1 to 6, characterized in that: The method of injecting the code probe into the free memory space on the embedded device through the UART interface and debugging the embedded device includes: Injecting the code probe into the free memory space on the embedded device through the UART interface, and modifying the register address pointer of the embedded device to point to the target address pointer of the code probe; Based on the target address pointer, the code probe is run and the embedded device is debugged.

8. A debugging device for an embedded device, characterized in that: include: An instruction set acquisition module, used to acquire instruction set information of the embedded device through a UART interface; A compiling module, configured to configure a corresponding cross-compilation component based on the instruction set information; and compile a preset probe source code into an executable file using the cross-compilation component; A minimum code extraction module, used to extract a minimum code subset from the executable file and determine a code probe based on the minimum code subset; The debugging module is used to inject the code probe into the free memory space on the embedded device through the UART interface and debug the embedded device.

9. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the debugging method for an embedded device according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the debugging method for an embedded device according to any one of claims 1 to 7 when running.

Images