A monolithic firmware debugging method based on dynamic patching

Abstract

The application discloses a monomer firmware debugging method based on dynamic repair, the method replaces the original instruction at the target memory address with a stub, inserts a custom callback function when the firmware runs to the target memory address, and thus realizes the debugging or custom processing of a specific memory address access event, solves the shortcomings that the traditional firmware debugging mode needs hardware interface support and is difficult to reflect the actual execution of the firmware, and the repair operation on the target memory address is completed in the dynamic running stage of the program, not directly static repair on the target memory address, so that the risk of device damage is significantly reduced, the work efficiency is greatly improved, and the input cost is reduced.

Description

Technical Field

[0001] The present invention relates to the field of single-body firmware vulnerability mining and utilization, and specifically to a single-body firmware debugging method based on dynamic patching. Background Art

[0002] Monolithic firmware is an integrated firmware design that's independent of the operating system, in which all functions and modules are tightly integrated into a single firmware image. This design approach is often used in resource-constrained embedded systems to simplify management, reduce overhead, and improve performance. Monolithic firmware is commonly found in STM32 and ARM embedded systems and is widely used in simple controllers and devices. In particular, a large number of devices in the air traffic control field use a monolithic firmware design.

[0003] In the field of single-unit firmware vulnerability discovery and exploitation, many application scenarios require monitoring and debugging the execution process of the single-unit firmware. Traditional solutions require support for hardware debugging interfaces such as JATG and SWD interfaces. However, manufacturers generally block these hardware debugging interfaces in finished devices. Another traditional solution is to simulate the firmware. However, the simulation environment configuration is complex and it is difficult to reflect the actual execution status of the firmware device.

[0004] Traditional static patching solutions, which directly patch monitoring addresses, can easily damage firmware devices. If too many locations require debugging, the probability of damage is even greater.

[0005] Therefore, developing a technical solution that does not require hardware support and can provide dynamic patching and debugging capabilities at the firmware execution level is of great significance for improving firmware security and accelerating the progress of security research.

[0006] Therefore, a single firmware debugging method based on dynamic patching is proposed to solve the above problems. Summary of the Invention

[0007] The purpose of the present invention is to provide a single firmware debugging method based on dynamic patching, and the technical solution adopted is:

[0008] A single firmware debugging method based on dynamic patching includes the following steps:

[0009] S1. Find the firmware code location corresponding to the front-end upload logic;

[0010] S2. Analyze the firmware verification algorithm;

[0011] S3. Compile the debug payload and convert the compiled executable file into a plain binary debug payload.

[0012] S4. Recalculate the checksum of the unformatted binary debug payload according to the firmware checksum algorithm obtained in step S2;

[0013] S5. Embed the plain binary debug payload into the firmware code location corresponding to the front-end upload logic obtained in step S1;

[0014] S6. Run the firmware device, dynamically patch the target memory address of the firmware device, and debug the firmware device; specifically, the following steps are included:

[0015] S61, determining the pre-input target memory address and callback function address;

[0016] S62. Find an empty entry in the slot / stub space reserved for the debug payload, create a variable slot and a stub in the empty entry; the stub stores fixed code data;

[0017] S63, write the callback function address and the target memory address into the corresponding addresses in the variable slot;

[0018] S64, read the original instruction at the target memory address, and write the original instruction to the corresponding address in the variable slot;

[0019] S65. Generate a jump instruction according to the next address of the target memory address, and write the jump instruction to the corresponding address in the variable slot;

[0020] S66. When the firmware program runs to the target memory address, a new jump instruction newbytes is generated according to the stub address in the slot / stub space, and the new jump instruction newbytes is written to the target memory address.

[0021] S67, refresh instruction cache;

[0022] S68, execute the new jump instruction newbytes, and the program jumps to the stub in the slot / stub space;

[0023] The stub execution process includes the following steps:

[0024] S681. Save the context information of the current execution environment of the firmware instruction sequence;

[0025] S682. Read the callback function address stored in the variable slot, call the callback function through the callback function address, execute the user-defined function code in the callback function, and debug the firmware device;

[0026] S683, restoring context information of the original execution environment of the firmware instruction sequence;

[0027] S684, read the original instruction stored in the variable slot, and execute the original instruction;

[0028] S685, read the jump instruction in the variable slot, execute the jump instruction, and the program jumps to the next address of the target memory address;

[0029] S69: Execute the firmware program according to the original execution flow.

[0030] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0031] 1. The present invention replaces the original instruction at the target memory address with a stub and inserts a user-defined callback function when the firmware runs to the target memory address, thereby realizing debugging or custom processing of specific memory address access events, and solving the shortcomings of traditional firmware debugging methods that require hardware interface support and are difficult to reflect the actual execution status of the firmware.

[0032] 2. The present invention completes the patching operation of the target memory address during the dynamic operation phase of the program, rather than directly performing static patching on the target memory address, which significantly reduces the risk of equipment damage, greatly improves operating efficiency, and reduces investment costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is a dynamic patching flow chart of the present invention.

[0034] Figure 2 This is a dynamic repair effect diagram of the present invention. DETAILED DESCRIPTION

[0035] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention, so as to have a further understanding of the concept of the present invention, the technical problems solved, the technical features constituting the technical solution and the technical effects brought about.

[0036] A single firmware debugging method based on dynamic patching includes the following steps:

[0037] S1. Find the firmware code location corresponding to the front-end upload logic;

[0038] For example, the management page of most embedded devices has a firmware update function. The present invention needs to obtain the firmware code location corresponding to the front-end upload logic as the entry point for debugging the payload.

[0039] S2. Analyze the firmware verification algorithm;

[0040] Typically, firmware updates require verification of the received firmware program; if verification fails, the update is rejected. When compiling and embedding the debug payload into the original firmware, the checksum value changes, requiring recalculation. Analyzing the firmware verification algorithm allows recalculation of the debug payload's checksum, ensuring successful embedding. Asymmetric signature algorithms are not applicable to this invention.

[0041] S3. Compile the debug payload and convert the compiled executable file into a plain binary debug payload. The specific steps include:

[0042] S31. Write a linker script (lds file) to merge the code segment and the data segment to facilitate subsequent unformatted payload extraction.

[0043] S32. Write and name the payload C program, and perform necessary initialization and resource allocation.

[0044] Example: The payload body C program is named main.c.

[0045] S33, calling the gcc compiler to compile the payload C program;

[0046] Specific command example: gcc -march=armv6-fomit-frame-pointer-co main.o main.c.

[0047] S34, calling the ld program linker;

[0048] Specific command example: ld -static -T main.lds -o exp main.o.

[0049] S35. Call objdump to extract debug payload binary data.

[0050] Specific command example: objdump -O binary exp exp.bin.

[0051] After completing the above steps, a plain binary debug payload is obtained, which can be easily embedded into the target firmware device.

[0052] S4. Recalculate the checksum of the unformatted binary debug payload according to the firmware checksum algorithm obtained in step S2.

[0053] S5. Embed the plain binary debug payload into the firmware code location corresponding to the front-end upload logic obtained in step S1;

[0054] Security researchers need to accurately embed the unformatted binary debugging payload into the firmware code location corresponding to the front-end upload logic and ensure the integrity of the original firmware functions.

[0055] S6. Run the firmware device, dynamically patch the target memory address of the firmware device, and debug the firmware device, specifically including the following steps:

[0056] S61, determining the pre-input target memory address and callback function address;

[0057] The callback function is called when the instruction at the target memory address is about to be executed but is not. Security researchers can write custom debugging code in the callback function, such as outputting register information, memory information, or tampering with register information, memory information, etc., to debug or customize specific memory addresses in the firmware.

[0058] S62. Find an empty entry in the slot / stub space reserved for the debug payload, create a variable slot and a stub in the empty entry; the stub stores fixed code data;

[0059] The relationship between the stub and the variable slot is closely related. The stub stores static fixed code data, while the variable slot stores dynamic data that needs to be configured during the dynamic patching process. The two together form the instruction data area of ​​the slot / stub space.

[0060] S63. Write the callback function address and the target memory address into the corresponding addresses in the variable slot.

[0061] S64, read the original instruction at the target memory address, and write the original instruction to the corresponding address in the variable slot;

[0062] The reading methods include pointer dereference or memcpy reading.

[0063] S65. Generate a jump instruction according to the next address of the target memory address, and write the jump instruction to the corresponding address in the variable slot.

[0064] S66. When the firmware program runs to the target memory address, a new jump instruction newbytes is generated according to the stub address in the slot / stub space, and the new jump instruction newbytes is written to the target memory address.

[0065] Writing methods include pointer dereference or memcpy reading.

[0066] S67, refresh instruction cache;

[0067] In order to ensure that the new instructions take effect and the processor does not execute old instructions already in the instruction cache, an instruction cache refresh operation is performed. The specific implementation of the instruction refresh operation depends on different architectures.

[0068] S68. Execute the new jump instruction newbytes, and the program jumps to the stub in the slot / stub space.

[0069] like Figure 1 As shown, through steps S61 to S68, the original instruction at the target memory address is replaced with a stub, inserting a debug point at the target memory address. This enables debugging and customized handling of specific memory address access events. This method dynamically adapts to code changes and, without hardware interface support, provides a more flexible and effective firmware debugging method that can reflect the actual execution status of the firmware, greatly facilitating security researchers in discovering vulnerabilities in embedded single-body firmware.

[0070] The stub execution process includes the following steps:

[0071] S681. Save the context information of the current execution environment of the firmware instruction sequence, such as register information, memory information, etc.

[0072] S682. Read the callback function address stored in the variable slot, call the callback function through the callback function address, execute the user-defined function code in the callback function, and debug the firmware device;

[0073] Security researchers pre-write custom debugging code in callback functions based on debugging needs. For example, they can monitor and output register or memory information, tamper with register or memory information, and perform other custom processing to achieve debugging purposes. An example of a callback function is as follows:

[0074] void watch_point_c(struct regs*reg){

[0075] printf("PC:%x\n",reg->pc);

[0076] for(int i=0;i <REG_NUM;i++){

[0077] printf("R%d:%x\n",i,reg->regs[i]);

[0078] }

[0079] }

[0080] add_watch_point1(0x38268,watch_point_c);

[0081] The function of this example is to print the register information of the call point (target memory address).

[0082] Here, watch_point_c is a user-defined callback function, and add_watch_point1 embodies the dynamic patching details of the present invention. After calling add_watch_point1, whenever the program reaches address 0x38268 (the target memory address), watch_point_c is executed (calling the callback function) to output register information (callback function functionality), and then normal execution is resumed (executing the original instructions and restoring the original execution flow). This allows the register value at address 0x38268 (the target memory address) to be viewed without the support of a physical debugger.

[0083] S683: Restore the context information of the original execution environment of the firmware instruction sequence.

[0084] S684. Read the original instruction stored in the variable slot and execute the original instruction.

[0085] S685. Read the jump instruction in the variable slot, execute the jump instruction, and the program jumps to the next address of the target memory address.

[0086] S69: Execute the firmware program according to the original execution flow.

[0087] like Figure 2 As shown in the figure, the dynamic patching effect of the target memory address is shown. The original instruction (MOV R4, R0) at the target memory address is replaced with a stub, and the program jumps to the stub in the slot / stub space. The callback function is called and executed in the stub, and the access event of the target memory address is debugged or customized. After the callback function is executed, the original instruction (MOV R4, R0) at the target memory address is executed, and the program jumps back to the next address of the target monitoring address (LDR R1, [R0, #0xFC]), restoring the original execution flow and achieving seamless access. In this method, the patching operation of the target memory address is completed during the dynamic operation phase of the program (stub), rather than directly performing static patching on the target memory address. This significantly reduces the risk of equipment damage, greatly improves work efficiency, and reduces investment costs.

[0088] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A single firmware debugging method based on dynamic patching, characterized in that: The following steps are involved: S1. Find the firmware code location corresponding to the front-end upload logic; S2. Analyze the firmware verification algorithm to obtain a verification value that can be used to recalculate the debug payload, ensuring that the debug payload can be successfully embedded in the firmware device's firmware verification algorithm. S3. Compile the debug payload and convert the compiled executable file into a plain binary debug payload. S4. Recalculate the checksum of the unformatted binary debug payload according to the firmware checksum algorithm obtained in step S2; S5. Embed the plain binary debug payload into the firmware code location corresponding to the front-end upload logic obtained in step S1; S6. Run the firmware device, dynamically patch the target memory address of the firmware device, and debug the firmware device; The specific steps include: S61, determining the pre-input target memory address and callback function address; S62. Find an empty entry in the slot / stub space reserved for the debug payload, create a variable slot and a stub in the empty entry; the stub stores fixed code data; S63, write the callback function address and the target memory address into the corresponding addresses in the variable slot; S64, read the original instruction at the target memory address, and write the original instruction to the corresponding address in the variable slot; S65. Generate a jump instruction according to the next address of the target memory address, and write the jump instruction to the corresponding address in the variable slot; S66. When the firmware program runs to the target memory address, a new jump instruction newbytes is generated according to the stub address in the slot / stub space, and the new jump instruction newbytes is written to the target memory address. S67, refresh instruction cache; S68, execute the new jump instruction newbytes, and the program jumps to the stub in the slot / stub space; The stub execution process includes the following steps: S681. Save the context information of the current execution environment of the firmware instruction sequence; S682. Read the callback function address stored in the variable slot, call the callback function through the callback function address, execute the user-defined function code in the callback function, and debug the firmware device; S683, restoring context information of the original execution environment of the firmware instruction sequence; S684, read the original instruction stored in the variable slot, and execute the original instruction; S685, read the jump instruction in the variable slot, execute the jump instruction, and the program jumps to the next address of the target memory address; S69: Execute the firmware program according to the original execution flow.

Images