Debugging method and device of embedded device, electronic device and storage medium

Abstract

The application relates to a debugging method and device of an embedded device, an electronic device and a storage medium, wherein the debugging method of the embedded device comprises the following steps: acquiring instruction set information of the embedded device through a UART interface; configuring corresponding cross-compilation components based on the instruction set information; compiling preset probe source code into an executable file by using the cross-compilation components; extracting a minimum code subset in the executable file, and determining a code probe according to the minimum code subset; injecting the code probe into idle memory space on the embedded device through the UART interface, and debugging the embedded device. Through the application, the problem of low flexibility of embedded device debugging is solved.

Description

Technical Field

[0001] This application relates to the field of embedded systems, and in particular to debugging methods, apparatus, electronic devices, and storage media for embedded devices. Background Technology

[0002] The Internet of Things (IoT) connects any object to the internet through information sensing devices and according to agreed protocols, enabling intelligent identification, location, tracking, monitoring, and management. Debugging IoT devices typically relies on embedded device debugging tools and techniques. Among 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 embedded device debugging. These interfaces interact with dedicated hardware devices and development tools, allowing reverse engineers to directly observe and manipulate the status of embedded devices. However, the use of these hardware debugging interfaces is subject to certain limitations: some devices may disable these interfaces for security or commercial protection reasons, or the interfaces themselves may not be configured in the hardware design, thus limiting the scope and flexibility of embedded device debugging.

[0003] Currently, no effective solution has been proposed to address the issue of low flexibility in debugging embedded devices in related technologies. Summary of the Invention

[0004] This application provides a debugging method, apparatus, electronic device, and storage medium for embedded devices, to at least address the problem of low flexibility in debugging embedded devices in related technologies.

[0005] In a first aspect, embodiments of this application provide a debugging method for an embedded device, the method comprising:

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

[0007] 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;

[0008] Extract the minimum code subset from the executable file, and determine the code probe based on the minimum code subset;

[0009] The code probe is injected into the free memory space of 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; the step of using the cross-compilation component to compile the preset probe source code into an executable file includes:

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

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

[0013] During the linking process using the linker, unused code segments in the intermediate object files are identified and removed to obtain the executable file.

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

[0015] The symbol information in the executable file is identified and removed 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 of the embedded device via the UART interface includes:

[0018] The memory usage information of the embedded device is obtained through the UART interface;

[0019] Based on the memory usage information, the free memory space is determined, and the code probe is injected into the free memory space.

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

[0021] By utilizing hardware-in-the-loop technology, the embedded software on the embedded device is integrated into the simulation device;

[0022] When the simulation device runs the code probe and triggers the Memory Mapped Input / Output (MMIO) operation, 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 of the embedded device via the UART interface and debugging the embedded device includes:

[0025] The code probe is injected into the free memory space of the embedded device through the UART interface, and the register address pointer of the embedded device is modified 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] Secondly, embodiments of this application provide a debugging apparatus for an embedded device, comprising:

[0028] The instruction set acquisition module is used to acquire the instruction set information of the embedded device through the UART interface;

[0029] The compilation module is used to configure the corresponding cross-compilation component based on the instruction set information; and to use the cross-compilation component to compile the preset probe source code into an executable file.

[0030] A minimum code extraction module is used to extract the 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 of the embedded device through the UART interface and debug the embedded device.

[0032] Thirdly, embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the debugging method for the embedded device as described in the first aspect above.

[0033] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the debugging method for the embedded device as described in the first aspect above.

[0034] Compared to related technologies, the debugging method, apparatus, electronic device, and storage medium for embedded devices provided in this application obtain the instruction set information of the embedded device through a UART interface; configure the corresponding cross-compilation component based on the instruction set information; compile the preset probe source code into an executable file using the cross-compilation component; extract the minimum code subset from the executable file and determine the code probe based on the minimum code subset; inject the code probe into the free memory space of 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. This allows for the dynamic injection of code probes into the memory space of the embedded device being debugged at runtime using the UART interface's memory read / write functionality. This enables real-time monitoring and modification of the embedded device's behavior, allowing debugging and control tasks to be completed even if the embedded device does not have a dedicated hardware debugging interface, effectively improving the flexibility of embedded device debugging. Furthermore, by dynamically injecting a small-volume probe with a minimal code subset into the code, debugging can be performed without relying on an interface, and it has a small memory footprint. This is suitable for the debugging needs of embedded devices in resource-constrained environments, avoiding the problem that existing memory-based embedded gdb debuggers, while partially replacing hardware debugging interfaces, are difficult to adapt to the low memory requirements of embedded devices, especially in resource-constrained environments, due to their large memory consumption.

[0036] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

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

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

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

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

[0041] Figure 4 This is a structural block diagram of a debugging device for an embedded device according to an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application. Furthermore, it is understood that although the efforts made in such a development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, modifications to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0043] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0044] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The terms “first,” “second,” “third,” etc., used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0045] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. Taking running on a terminal as an example, Figure 1 This is a hardware structure block diagram of a terminal for a debugging method of an embedded device according to an embodiment of this application. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

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

[0047] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

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

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

[0050] UART interfaces are commonly used for serial communication on embedded devices. Through the UART interface, commands can be sent to the embedded device and responses can be received. Before compiling code, it's necessary 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 methods:

[0051] Device information is obtained through the UART interface. Specifically, developers can typically communicate with the target device via the UART interface and run commands such as `uname -a` or ` / proc / cpuinfo` to obtain the device's hardware information and instruction set architecture. This information is crucial for selecting the correct compiler and target platform during cross-compilation.

[0052] Alternatively, device information can be obtained through embedded device documentation. That is, if the device's system documentation or specifications are available, it will usually clearly list the supported instruction sets such as ARMv7, ARM64, Microprocessor without Interlocked Pipeline Stages (MIPS), and Reduced Instruction Set Computer (RISC-V), as well as the operating system such as Linux or Real-Time Operating System (RTOS).

[0053] Step S220: 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.

[0054] The aforementioned probe source code refers to a specific piece of code used in fields such as embedded systems, software development, or network monitoring to perform specific detection, monitoring, or debugging tasks. The writing of the source code depends 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 code efficiency and portability.

[0055] To meet the requirements for running on a specific target platform, the generated probe source code needs to be cross-compiled. Cross-compilation specifically refers to compiling code on one platform into executable code for another. Since embedded devices typically use processor architectures different from the host machine, a cross-compilation toolchain is required. The core of cross-compilation lies in generating the corresponding executable file based on the embedded device's hardware architecture; based on this, once the instruction set information of the embedded device is obtained, a suitable cross-compilation toolchain can be installed on the host machine for that embedded device.

[0056] Cross-compilation allows reverse engineers to generate software adapted for various hardware architectures, accelerating multi-platform development, especially when the development environment of the target device (i.e., the embedded device to be debugged) cannot be directly accessed.

[0057] Specifically, based on the obtained instruction set information, a suitable cross-compilation toolchain is selected. For example, if the device uses an Advanced RISC Machine (ARM) architecture, a cross-compilation toolchain for ARM (such as arm-none-eabi-gcc) is selected. Next, the cross-compilation environment is configured, including setting environment variables and paths, and the preset probe source code is compiled using the cross-compilation toolchain to generate an executable file suitable for the embedded device. The executable file can be an Executable and Linkable Format (ELF) file; ELF is the standard format for executable files in Linux systems. An ELF file contains the program code, data segments, symbol tables, and debugging information required by the embedded device to be debugged.

[0058] Step S230: Extract the minimum code subset from the executable file and determine the code probe based on the minimum code subset.

[0059] A code probe is a code snippet used to monitor and analyze program behavior. Specifically, it involves extracting a minimal subset of code from a compiled executable file, which is then injected as a probe into an embedded device.

[0060] In embedded device development, especially when debugging or simulating embedded devices via the UART interface, the generated binary executable files (such as ELF files) are often very large, containing a large number of unnecessary symbols, debugging information, and unused code segments. To address this issue, this step proposes a minimal subset extraction technique. The core idea is to extract the smallest binary subset from the generated ELF file, containing only the code and data required for actual operation, thereby reducing file size and improving the efficiency of device debugging and simulation.

[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 subset of code is determined and extracted. This subset typically contains basic initialization, function calls, and return logic. Finally, based on the smallest subset of code, a corresponding code probe is written or generated.

[0062] Step S240: Inject the code probe into the memory space of the embedded device through the UART interface and debug the embedded device.

[0063] To ensure the injected code probe is invoked at runtime, developers can modify the program counter (PC) or function address pointer to force the embedded device to jump to the code probe at a specific point in execution. For example, during a function call, 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 a register or memory address. Changing the value of the PC register to the starting address of the code probe (0x8000) will cause the embedded device to jump directly to the code probe on the next execution.

[0064] The above method enables dynamic injection of code probes. Dynamic code probe injection is a highly efficient debugging and monitoring technique suitable for embedded system and device debugging, especially in scenarios requiring real-time observation and dynamic modification of device behavior. This technique utilizes the memory read / write capabilities provided by the UART interface, allowing reverse engineers to dynamically inject a minimal subset of code as probes into the memory of the embedded device being debugged. These probes are then invoked by modifying the program counter (PC) or function address pointers, thereby enabling monitoring and debugging of device behavior. The core idea of ​​this technique is non-intrusive dynamic insertion and debugging; that is, by inserting lightweight code probes into the device memory, the normal operation of the embedded device is not affected, while still allowing for the tracking of the embedded device's status, memory allocation, and key indicators.

[0065] In the aforementioned embedded device debugging method, efficient debugging of black-box IoT devices is achieved through the UART interface. This allows for the dynamic injection of code probes into the memory space of the embedded device being debugged using the UART interface's memory read / write function at runtime. This enables real-time monitoring and modification of the embedded device's behavior, allowing debugging and control tasks to be completed even if the embedded device does not have a dedicated hardware debugging interface, effectively improving the flexibility of embedded device debugging. Furthermore, by dynamically injecting a small-volume probe with a minimal code subset into the code, debugging can be performed without relying on an interface, and it has a small memory footprint. This is suitable for the debugging needs of embedded devices in resource-constrained environments, avoiding the problem that existing memory-based embedded GNU symbolic debuggers (GDB), while partially replacing hardware debugging interfaces, are difficult to adapt to the low memory requirements of embedded devices, especially in resource-constrained environments, due to their large memory consumption.

[0066] In some embodiments, the aforementioned cross-compilation components include a compiler and a linker; more specifically, a cross-compilation toolchain (i.e., a cross-compilation component) consists of a compiler, a linker, a standard library, and debugging tools. Common cross-compilation toolchains include the GNU Compiler Collection (GCC) and Clang (a lightweight compiler), both of which support compilation for multiple architectures. The following are the steps for installing and configuring a cross-compilation toolchain:

[0067] For the GCC toolchain, a cross-compiler can be installed using a package manager on a Linux system. For Clang, the target architecture can be specified using compilation parameters (e.g., the `--target=" parameter). For the Linaro toolchain (a cross-compilation toolchain that provides high-quality development tools and software stacks specifically for ARM architecture devices), Linaro provides an optimized GCC cross-compilation toolchain for ARM architecture. The Linaro toolchain is often used to develop high-performance embedded applications.

[0068] The above-mentioned use of cross-compilation components to compile the preset probe source code into an executable file may also include the following steps:

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

[0070] The key steps of cross-compilation are explained below. First, the source code is compiled; the probe source code is compiled into machine code for the embedded device to be debugged. Then, assembly code is inserted during the inline assembly stage. That is, when developing embedded devices, it is usually necessary to insert the target architecture's assembly code into the C language code, and both GCC and Clang support inline assembly syntax. During cross-compilation, the compiler generates the corresponding machine code based on the target architecture's assembly instruction set; for example, when compiling for ARM, the generated machine code will use the ARM instruction set.

[0071] After the compiler generates intermediate object files (usually in ELF format), the linker needs to link all intermediate object files and library files into the final executable file during the linking stage. The cross-compiler component includes a linker suitable for the embedded device architecture being debugged. During the linking stage, the -L and -I parameters can be used to specify the library paths and header file paths for the embedded device being debugged.

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

[0073] In some embodiments, the above-described method of using a linker to link intermediate object files into an executable file may further include the following steps:

[0074] During the linking process, unused code segments in intermediate object files are identified and removed to obtain the executable file.

[0075] First, regarding the basic cross-compilation process, the compilation rule file (Makefile) uses Clang, and the generated object files are linked into ELF files. The compilation process is as follows: Compilation parameters are specified using C compiler flags (CFLAGS) to ensure that the generated code is operating system independent (-ffreestanding) and does not contain standard library implementations (-fno-builtin). Next, linking is performed using linker flags (LDFLAGS); a specific linker script, link.ld, is used during the linking process, and the --gc-sections parameter (a linker-related option) is used to remove unused code segments. These configurations ensure that the generated ELF file contains only the actually needed code and data.

[0076] Secondly, during the generation of ELF files, the compilation and linking process mainly generates intermediate object files (.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 ELF file can be further simplified by using the strip tool (a tool under the Linux system that can remove the symbol table of the executable file), removing the symbol table and debugging information to generate the minimum executable file; in this step, arm-none-eabi-strip is a tool specifically used to remove unnecessary symbols in ARM architecture binary files. By strip, debugging symbols, symbol tables and other information in the ELF file can be removed, significantly reducing the file size and keeping only the code and data segments required for execution.

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

[0078] In some embodiments, the above-described extraction of the minimum code subset from the executable file may further include the following steps:

[0079] The symbol information in the executable file is identified and removed 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.

[0080] The next step is to further streamline the ELF file using the strip tool, removing symbol tables and debugging information to generate a minimal executable file. The strip tool removes debugging symbols, symbol tables, and other information from the ELF file, significantly reducing its size and leaving only the necessary code and data segments for execution.

[0081] After obtaining the streamlined ELF file, the objcopy tool (a command-line tool primarily used for copying and converting the contents of target files) is used to convert it into a raw binary file. objcopy allows extracting the necessary data from the ELF file, generating a minimal subset of the binary file. This step uses arm-none-eabi-objcopy to convert the ELF file to a minimal binary format. The -O binary option indicates that the output is a raw binary file, containing only the most basic code and data segments, further reducing the file size.

[0082] In addition to generating bin files, Makefiles also support generating Intel HEX format files (a file format used for storing and transferring data to embedded devices); for example, using the `-Oihex` option of `objcopy` can convert ELF files to Intel HEX format files. Intel HEX format is a commonly used embedded system firmware format, facilitating firmware burning to devices.

[0083] Through the above embodiments, the executable file is further simplified by automatically removing the symbol table and debugging information.

[0084] In some embodiments, the above-described injection of code probes into the free memory space of the embedded device via the UART interface may further include the following steps:

[0085] The system obtains the memory usage information of the embedded device through the UART interface; based on the memory usage information, it determines the free memory space and injects the code probe into the free memory space.

[0086] The working principle of Shellcode dynamic injection technology can be divided into the following key steps:

[0087] Identify the target memory region. 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 / write capabilities of the UART interface, developers can determine which memory addresses on the device are not currently occupied by the application or operating system, ensuring that probe code is injected into unused memory space.

[0088] Shellcode injection (a piece of code executed to exploit software vulnerabilities). Developers write shellcode for monitoring or debugging and inject it into unused memory on a device. This shellcode may contain monitoring logic for specific system resources (such as memory, registers, etc.) or code that captures the parameters and return values ​​of certain functions.

[0089] Modifying the program counter or function address pointer. To trigger these shellcode probes at runtime, developers modify the device's PC register or function address pointer via the UART interface, changing the target code it originally pointed to to the injected shellcode probe. This modification method allows debugging logic to be inserted without interrupting or affecting the normal execution of the program.

[0090] Real-time monitoring and behavior modification. Once the probe is executed, the shellcode monitors the device's operational status in real time (such as memory read / write, register operations, function call activity, etc.) and feeds this information back to the developer. Developers can use the shellcode to modify certain behaviors of the device, such as changing function return values ​​or modifying the value of a global variable.

[0091] Through the above embodiments, the Shellcode Minimum Subset Extraction technique is used to ensure that only the minimum binary file required for device execution is generated by progressively removing redundant information and unused code segments after compilation. This technique not only significantly reduces the size of the binary file and improves debugging efficiency on embedded devices, but also reduces memory consumption, playing an important role in resource-constrained environments. Furthermore, by integrating an automated toolchain, it automates and accurately extracts the minimum executable code and data, effectively simplifying the binary simplification process in embedded development.

[0092] In some embodiments, the above-described method of injecting code probes into the free memory space of the embedded device via the UART interface and debugging the embedded device may further include the following steps:

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

[0094] Hardware-in-the-Loop (HIL) simulation is a key technology in embedded system development. It integrates physical hardware devices with a simulation environment to achieve near-real-world testing of device code execution. The core advantage of this technology lies in providing a controlled and repeatable testing environment, allowing developers to run software in a simulated device while interacting with real hardware. By simulating the states of inputs, outputs, and the external environment, software development, debugging, and testing become more accurate and efficient.

[0095] When using emulation devices such as QEMU (an open-source machine simulator and virtualizer) to simulate devices, the devices may need to access the hardware via memory-mapped I / O (MMIO). The behavior of these hardware parts can be obtained from the physical hardware devices by interacting with the UART through pre-embedded probes, and then synchronized to the emulation device, thereby realizing the collaborative work of software and hardware.

[0096] The basic principles of hardware-in-the-loop (HIL) simulation are explained below. HIL technology integrates physical hardware devices into a simulation system, allowing developers to interact with real hardware while running embedded software in a simulation environment. Specifically, the software runs within the simulation device, and when it encounters hardware-related operations (such as MMIO access), it interacts with the physical hardware in real time. This allows the simulation device to mimic real hardware behavior and obtain more accurate results.

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

[0098] Simulation equipment; embedded software runs in a virtual environment. Simulation equipment 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; used to provide a real-world state of the external environment or the behavior of specific hardware (such as sensors or peripherals).

[0101] Probe Shellcode: Lightweight debugging code injected into the device to pass information between the emulation device and the hardware, enabling synchronization of MMIO operations.

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

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

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

[0105] Probe and UART Interaction: In the simulation environment, probes (shellcode) are pre-embedded in the target code. When the simulated device executes a hardware-related MMIO operation, the probe is triggered. The simulated device then sends a request to the physical hardware device via the UART interface to obtain the actual device status or result. The physical hardware device returns the corresponding data based on the request, and the simulated device synchronizes this data to the simulator's virtual memory, thereby simulating hardware behavior. For example, when QEMU simulates an embedded device, if the running software attempts to read a register of the device (such as a sensor status register), the simulated device sends a read request to the real hardware device via UART. The hardware device returns the current sensor status, and the simulated device continues execution after receiving the status.

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

[0107] Pre-implanting probes (shellcode). Before debugging with HIL, probes need to be implanted in the target code or emulation device. These probes are lightweight shellcode that can monitor critical memory operations or MMIO access points. Once triggered, the probe sends a signal to the real hardware device via UART, requesting it to return relevant status or data. Below is a simple example of probe shellcode that monitors MMIO access and requests hardware status via UART:

[0108]

[0109] In the example above, when the emulation device runs the code that accesses mmio_address, the shellcode is triggered and the contents of that address are sent to the hardware device via UART.

[0110] Afterwards, UART interaction is synchronized with the hardware. When the emulation device accesses MMIO, it first invokes the probe shellcode, which sends a request to the physical hardware device via UART. Upon receiving the request, the hardware device returns status information or data according to the probe's needs. For example, if the probe requests to read the current state of the sensor, the hardware device will return the actual state of the sensor to the emulation device via UART.

[0111] After receiving data from the hardware, the simulation device writes it to the MMIO virtual memory area, allowing subsequent code to continue execution. This process is performed in real time, ensuring that the simulation device can accurately simulate hardware behavior.

[0112] After obtaining the relevant status data from the physical hardware, the simulation device continues to execute the code in the simulation environment. This combination of virtual and real methods ensures that during software debugging, even when specific hardware operations are involved, results can be fed back from the real hardware device.

[0113] Through the above process, developers can run embedded software in a simulation device while simultaneously acquiring real-time operational data from the physical hardware, enabling precise code testing and verification. Due to the high flexibility of hardware-in-the-loop simulation systems, developers can also modify probe logic or virtual environment parameters to simulate different device states and inputs, further accelerating the debugging process.

[0114] In some embodiments, the above-described method of injecting code probes into the free memory space of the embedded device via the UART interface and debugging the embedded device may further include the following steps:

[0115] The code probe is injected into the free memory space of the embedded device via the UART interface, 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] To trigger these shellcode probes at runtime, developers modify the device's PC register address pointer or function address pointer via the UART interface, changing the target code it originally pointed to to the injected shellcode probe. This modification method allows debugging logic to be inserted without interrupting or affecting the normal execution of the program.

[0117] Specifically, the UART interface is used as the communication method to send pre-prepared code probe data to the embedded device. These code probes are designed to execute in the specific environment of the embedded device to collect debugging information or perform debugging operations. Within the embedded device, key registers controlling the program execution flow (such as the program counter or instruction pointer) are located. The values ​​of these registers are modified to point to the target address of the code probe in the embedded device's free memory space; the purpose of this step is to allow the embedded device to jump to the code probe during execution, thereby initiating the debugging task.

[0118] Once the embedded device's execution flow jumps to the code probe, the probe will begin executing its pre-defined debugging tasks. These tasks may include collecting system status information, checking variable values, triggering breakpoints, and recording the execution path. Using this debugging information, developers can analyze the embedded device's operational status and locate and resolve problems.

[0119] The present application will now be described with reference to specific embodiments. Taking the debugging and cracking process of a UART-based solid-state drive (SSD) controller as an example, the process includes the following steps:

[0120] Step S301, Accurate Operation and Target Selection. This involves determining the SSD controller model and checking if it has a UART interface. Since many SSD controllers have a reserved UART interface for factory testing and debugging, but this interface may be disabled or hidden during final shipment, if the UART interface is detected as disabled, its location needs to be located and activated.

[0121] Step S302: Debug the code through cross-compilation. To communicate and operate with the SSD controller, a program for debugging and control can be written using a high-level programming language. This program is then compiled into a binary file executable by the target controller using cross-compilation technology, adapting it to the hardware architecture of the SSD controller. Since SSD controllers may be based on different hardware platforms (such as ARM, MIPS, etc.), cross-compilation generates binary files suitable for different platforms, ensuring the code runs correctly on the controller.

[0122] Step S303: Extract the minimum shellcode subset. Specifically, based on the requirements of SSD controller debugging, a minimum shellcode subset extraction technique is used to automatically generate shellcode containing only key instructions to implement basic operations on the SSD controller (such as data read / write and status monitoring). This step can significantly reduce the memory usage of the code, thereby adapting to the resource limitations of the SSD controller and reducing the performance impact during debugging.

[0123] Step S304, Dynamic Injection of Code Probe. Connect to the SSD controller using the UART interface and utilize shellcode dynamic injection technology to embed the debug probe into the target code by reading and writing to the SSD controller's memory via UART. This probe can monitor the SSD controller's operating status and memory allocation in real time without affecting normal operation. For example, when executing data read / write commands, we can dynamically obtain the current data location and content being written to further analyze the SSD's encryption and compression algorithms.

[0124] Step S305, Hardware-in-the-Loop (HIL) Simulation Testing. During debugging, the SSD controller is integrated into a virtual simulation environment using Hardware-in-the-Loop (HIL) simulation technology. In the simulation environment, the UART interface is used to simulate external inputs and data flows (such as simulating read data streams or write commands), thereby testing the operational effects on the SSD controller and the progress of any attempts to crack it in a controlled environment. This allows us to simulate various attack methods in a secure environment, such as data reading and decryption operations.

[0125] Step S306: Analyze and verify the cracking effect. After the entire debugging and cracking process is completed, export the operation records and data content of the SSD controller through the UART interface to verify whether the data obtained by the debugging probe is accurate and whether the cracking operation has achieved the expected results. Finally, based on the data obtained from the analysis, reverse engineer and crack the controller's firmware algorithm (such as encryption mechanism and compression scheme) to further understand its internal operating mechanism.

[0126] The above embodiments enable the debugging and cracking of SSD controllers without the need for hardware debugging interfaces, effectively identifying their firmware algorithms and data storage methods. This UART interface-based debugging and cracking method greatly improves work efficiency and is also applicable to debugging and reverse engineering scenarios for other types of embedded devices.

[0127] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures 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.

[0128] This embodiment also provides a debugging apparatus for an embedded device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

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

[0130] The instruction set acquisition module 41 is used to acquire 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; and to compile the preset probe source code into an executable file using the cross-compilation component; the minimum code extraction module 43 is used to extract the minimum code subset from the executable file and determine the code probe based on the minimum code subset; and the debugging module 44 is used to inject the code probe into the free memory space of the embedded device through the UART interface and debug the embedded device.

[0131] In some embodiments, the cross-compilation components include a compiler and a linker; the compilation module 42 is further configured to use the compiler to cross-compile the probe source code into intermediate object files, and use the linker to link the intermediate object files into executable files.

[0132] In some embodiments, the compilation module 42 is further configured to identify and remove unused code segments in intermediate object files during the linking process using a linker, thereby obtaining an executable file.

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

[0134] In some embodiments, the debugging module 44 is further configured to obtain memory usage information of the embedded device through the UART interface; the debugging module 44 is further configured to determine free memory space based on the memory usage information and inject code probes into the free memory space.

[0135] In some embodiments, the debugging module 44 is further configured to integrate embedded software on the embedded device into the simulation device using hardware-in-the-loop technology; the debugging module 44 is further configured to run code probes on the simulation device and, when triggering Memory Mapped Input / Output (MMIO) operation, have the simulation device obtain device status data from the embedded device through the UART interface; the debugging module 44 is further configured to debug the embedded device based on the device status data.

[0136] In some embodiments, the debugging module 44 is further configured to inject a code probe into the free memory space of the embedded device via 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 further configured 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 through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0138] This embodiment also 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 perform the steps in any 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 can be configured to perform the following steps via a computer program:

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

[0142] S2 configures the corresponding cross-compilation components based on instruction set information; using the cross-compilation components, the preset probe source code is compiled into an executable file.

[0143] S3 extracts the minimum code subset from the executable file and determines the code probe based on the minimum code subset.

[0144] S4 injects code probes into the free memory space of the embedded device via 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 implementations, and will not be repeated here.

[0146] Furthermore, in conjunction with the embedded device debugging methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the embedded device debugging methods in the above embodiments.

[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, data stored, data displayed, 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 will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this 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), magnetic 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0149] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A debugging method for an embedded device, characterized in that, The method includes: The instruction set information of the embedded device is obtained through the Universal Asynchronous Receiver / Transmitter (UART) interface; 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; Extract the minimum code subset from the executable file, and determine the code probe based on the minimum code subset; The code probe is injected into the free memory space of 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; the step of using the cross-compilation component to compile the preset probe source code into an executable file includes: Using the compiler, the probe source code is cross-compiled into an intermediate object file, and using the linker, the intermediate object file is linked into the executable file.

3. The debugging method according to claim 2, characterized in that, The step of using the linker to link the intermediate object files into the executable file includes: During the linking process using the linker, unused code segments in the intermediate object files are identified and removed to obtain the executable file.

4. The debugging method according to claim 1, characterized in that, Extracting the minimum subset of code from the executable file includes: The symbol information in the executable file is identified and removed 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 of the embedded device through the UART interface includes: The memory usage information of the embedded device is obtained through the UART interface; Based on the memory usage information, the free memory space is determined, and the code probe is injected into the free memory space.

6. The debugging method according to claim 1, characterized in that, The step of injecting the code probe into the free memory space of the embedded device through the UART interface and debugging the embedded device includes: By utilizing hardware-in-the-loop technology, the embedded software on the embedded device is integrated into the simulation device; When the simulation device runs the code probe and triggers the Memory Mapped Input / Output (MMIO) operation, 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 step of injecting the code probe into the free memory space of the embedded device through the UART interface and debugging the embedded device includes: The code probe is injected into the free memory space of the embedded device through the UART interface, 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.

8. A debugging device for an embedded device, characterized in that, include: The instruction set acquisition module is used to acquire the instruction set information of the embedded device through the UART interface; The compilation module is used to configure the corresponding cross-compilation component based on the instruction set information; and to use the cross-compilation component to compile the preset probe source code into an executable file. A minimum code extraction module is used to extract the 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 of 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, The memory stores a computer program, and the processor is configured to run the computer program to perform the debugging method of the 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 of the embedded device according to any one of claims 1 to 7 when it is run.

Images