Monomer firmware debugging method based on dynamic repair

Abstract

The invention discloses a single firmware debugging method based on dynamic repair, which comprises the following steps: replacing an original instruction at a target memory address with a stub, and inserting a user-defined callback function when firmware runs to the target memory address, thereby realizing debugging or user-defined processing on a specific memory address access event. The defects that in a traditional firmware debugging mode, hardware interface support is needed, and the real execution condition of firmware is difficult to reflect are overcome. And meanwhile, the repairing operation on the target memory address is completed in the dynamic running stage of the program instead of directly performing static repairing on the target memory address, so that the risk of equipment damage is remarkably reduced, the working efficiency is greatly improved, and the investment 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 is not dependent on the operating system, in which all functions and modules are tightly integrated into the same firmware image. This design approach is often used in resource-constrained embedded systems to simplify management, reduce overhead and improve performance. Monolithic firmware is common in STM32 and ARM embedded systems and is widely used in simple controllers and devices. In particular, a large number of devices in the field of air traffic control use monolithic firmware design.

[0003] In the field of monolithic firmware vulnerability mining and exploitation, many application scenarios require monitoring and debugging of the execution process of monolithic firmware. Traditional solutions require the support of hardware debugging interfaces such as JATG interface and SWD interface, but the finished equipment shipped by manufacturers generally blocks these hardware debugging interfaces. Another traditional solution is to simulate the firmware, but the simulation environment configuration is complex and it is difficult to reflect the actual execution status of the firmware device.

[0004] The traditional static patching solution is to directly patch the monitoring address in a static way, which is easy to cause firmware device damage. If there are too many locations that need to be debugged, 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, analyzing 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, embedding the unformatted binary debugging payload into the firmware code position corresponding to the front-end upload logic obtained in step S1;

[0014] S6, running the firmware device, dynamically patching the target memory address of the firmware device, and debugging the firmware device; specifically comprising the following steps:

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

[0016] S62, searching for an empty item in the slot / stub space reserved for the debug payload, creating a variable slot and a stub in the empty item; the stub stores fixed code data;

[0017] S63, writing 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 into the corresponding address in the variable slot;

[0019] S65, generating a jump instruction according to the next address of the target memory address, and writing 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, saving 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 the 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, thereby solving the shortcomings of the traditional firmware debugging method, which requires hardware interface support and is 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 position corresponding to the front-end upload logic as the entry point for debugging the payload.

[0039] S2, analyzing the firmware verification algorithm;

[0040] Normally, when updating the firmware, the received firmware program needs to be verified. If the verification fails, the update is rejected. When compiling the debug payload and embedding the debug payload into the original firmware, the verification value will change, and the verification value needs to be recalculated. Analyzing the firmware verification algorithm can recalculate the verification value of the debug payload to ensure that the debug payload can be successfully embedded in the firmware device. If the verification algorithm is an asymmetric signature algorithm, it is not applicable to the present 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 main C program;

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

[0047] S34, calling ld program linker;

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

[0049] S35, calling objdump to extract debug payload binary data;

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

[0051] After completing the above steps, an unformatted 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, embedding the unformatted binary debugging payload into the firmware code position 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, running the firmware device, dynamically patching the target memory address of the firmware device, and debugging 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 will be called when the target memory address instruction is about to be executed but is not executed. Security researchers write custom debugging code in the callback function, such as outputting register information, memory information or tampering with register information, memory information, etc., to achieve debugging or custom processing of specific memory addresses of the firmware.

[0058] S62, searching for an empty item in the slot / stub space reserved for the debug payload, creating a variable slot and a stub in the empty item; 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 dynamic patching. 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 into 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 into 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 are effective 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 a 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, that is, a debug point is inserted at the target memory address, thereby realizing the debugging and custom processing of specific memory address access events. Dynamic adaptation to code changes is realized, and a more flexible and effective firmware debugging method that can reflect the actual execution status of the firmware is provided without hardware interface support, which greatly facilitates security researchers in mining embedded single firmware vulnerabilities.

[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 write custom debugging code in the callback function in advance according to debugging requirements. For example, they can monitor and output register information or memory information, tamper with register information or memory information, and 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] Among them, 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 executes to address 0x38268 (target memory address), watch_point_c is first executed (calling the callback function) to output register information (callback function function), and then normal execution is resumed (executing the original instruction and restoring the original execution flow), so that the value of the register at address 0x38268 (target memory address) can 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 diagram 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 then 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 next address of the target monitoring address (LDR R1, [R0, #0xFC]) is jumped back to restore the original execution flow to achieve seamless access. In this method, the patching operation of the target memory address is completed in the dynamic running stage of the program (stub), rather than directly performing static patching on the target memory address, which significantly reduces the risk of equipment damage, greatly improves operation 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, analyzing the 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, embedding the unformatted binary debugging payload into the firmware code position corresponding to the front-end upload logic obtained in step S1; S6. running the firmware device, dynamically patching the target memory address of the firmware device, and debugging the firmware device; The specific steps include: S61, determining the pre-input target memory address and callback function address; S62, searching for an empty item in the slot / stub space reserved for the debug payload, creating a variable slot and a stub in the empty item; the stub stores fixed code data; S63, writing 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 into the corresponding address in the variable slot; S65, generating a jump instruction according to the next address of the target memory address, and writing 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, saving 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 the 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