A memory leakage vulnerability detection method based on instruction translation and insertion
By building a lightweight simulation environment in QEMU and performing instruction translation and instrumentation, the function call stack is dynamically reconstructed, which solves the shortcomings of existing tools in detecting memory leaks in closed-source firmware of ARM architecture, and achieves efficient and accurate memory leak location and diagnosis.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING INST OF TECH
- Filing Date
- 2026-03-16
- Publication Date
- 2026-06-19
Smart Images
Figure CN122241714A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer security technology, and in particular to a memory leak vulnerability detection method based on instruction translation instrumentation, applicable to dynamic security analysis of embedded closed-source firmware programs. Background Technology
[0002] Memory leaks are a common and serious type of dynamic memory management defect in software systems. They are characterized by the failure to properly release allocated heap memory due to design oversights, resulting in the permanent loss of that memory resource during the program's lifecycle. This problem is particularly prominent in embedded devices and firmware environments where long-term stable operation is extremely demanding. Even a small, imperceptible leak can accumulate over time, eventually exhausting limited system memory resources and causing severe consequences such as drastic performance degradation, slow service response, or even complete system crashes, directly impacting the reliability and availability of the underlying hardware.
[0003] Firmware, as the core foundational software embedded in hardware devices, is responsible for implementing low-level control and basic function scheduling of the hardware. However, due to considerations of intellectual property protection and trade secrets, the vast majority of commercial firmware is released in closed-source binary form. This closed-source characteristic makes it difficult to directly apply traditionally efficient memory leak detection methods that rely on source code, such as static code scanning and compile-time instrumentation, thus creating a very high technical barrier for firmware security analysis.
[0004] In the field of dynamic analysis, some mature tools for binary programs, such as Valgrind and its Memcheck based on the Dynamic Binary Instrumentation (DBI) framework, perform excellently in x86 / 64 desktop and server environments. However, when facing the ARM architecture widely used in the embedded field, especially the ARM32 instruction set, these tools often suffer from incomplete support, insufficient simulation accuracy, or excessive performance overhead. More importantly, such tools typically rely heavily on the target program having a symbol table or debug information to accurately locate vulnerabilities. When analyzing closed-source firmware extracted from real devices and completely stripped of symbol information, the analysis report often only provides the leaked memory address, but cannot reconstruct the function call path that led to the leak. This makes it difficult for analysts to quickly locate and understand the root cause of the vulnerability, resulting in low diagnostic efficiency.
[0005] There is an urgent need in this field for an innovative technical solution that can overcome the above-mentioned limitations and perform efficient and accurate memory leak detection and location on closed-source firmware of ARM architecture without the need for source code and symbol information, so as to make up for the deficiencies of existing toolchains and improve the overall security and reliability of firmware. Summary of the Invention
[0006] In view of this, the present invention provides a memory leak vulnerability detection method based on instruction translation instrumentation, which solves the problems of insufficient support for ARM architecture binary firmware and difficulty in obtaining runtime function call stacks in existing instrumentation-based memory leak analysis tools.
[0007] To achieve the above objectives, the technical solution of the present invention includes the following steps:
[0008] Step 1: Construct a simulation execution environment for closed-source firmware and maintain a function call stack to record the function call relationships during program execution; Step 2: Perform function call behavior tracing and function call stack restoration.
[0009] Step 3: Track heap memory allocation and deallocation based on preloading. For each memory allocation and deallocation operation, record the location and length of the allocated memory block and the current function call stack as context information.
[0010] Step 4: Memory leak detection before the target program exits. At the end of the simulation, the recorded memory allocation information is traversed to determine if there is a memory leak.
[0011] Further, step one: Construct a simulation execution environment for closed-source firmware, the steps are as follows: A simulation runtime environment for the target closed-source firmware is built using QEMU user mode.
[0012] Extract the file system and the target program to be analyzed from the target closed-source firmware.
[0013] Static analysis is used to extract the dynamic link libraries and loader paths that the target program depends on.
[0014] The root directory that the target program depends on is specified by setting the QEMU_LD_PREFIX environment variable.
[0015] Compile QEMU using a cross-compilation toolchain compatible with the target closed-source firmware.
[0016] Furthermore, a simulation runtime environment for the target closed-source firmware is constructed using QEMU user mode. The constructed simulation runtime environment is a lightweight simulation environment, which refers to a simulation environment based on dynamic binary translation technology that only simulates the process-level instruction stream of the target program, without simulating the complete hardware peripherals and operating system kernel execution environment of the target architecture. This environment uses the QEMU user mode simulator to translate the binary instructions of the target architecture into the instructions of the host architecture in real time, and transparently forwards the system call requests issued by the target program for the target architecture kernel to the host kernel for execution through the system call mapping mechanism Syscall Mapping.
[0017] Further, in step two, the TCG front-end of the micro code generator is completed. The TCG front-end refers to the execution stage that dynamically translates and semantically parses the native Guest Instructions of the target architecture. Before the instructions enter the host instruction generation process, the TCG front-end decodes, classifies, and converts them into intermediate representations (TCG IR) processing components. In this stage, instrumentation logic is implemented on instructions with control flow change semantics to record function call return addresses and approximate function return behavior, thereby realizing the dynamic construction and restoration of the call stack.
[0018] Furthermore, step two specifically involves the following process: Step S201: Obtain the binary firmware application for the ARM architecture under test. QEMU obtains the application from the closed-source binary firmware of the ARM architecture under test. In step S202, when the TCG translation front end parses control flow related instructions and translates the target ARM32 instructions, instrumentation is performed on specific function call instructions at the intermediate representation level of the TCG to identify function call instructions in the ARM instruction set.
[0019] Step S203, the specific instrumentation operation process is as follows: Instrument the function call stack push logic before the function call instruction. When the function call instruction described in step S202 is translated, a custom helper function call is inserted into the generated TCG intermediate representation. The core operation of this helper function is to obtain the address of the next instruction of the current instruction, i.e., s->base.pc_next. This address is the return address after the function call.
[0020] Step S204: Construct a chained function call stack data structure and maintain a dedicated function call stack. Push the return address after the function call obtained in step S203 as the position information of the function call into the function call stack. The function call stack is allocated in the thread context of QEMU and is a last-in-first-out (LIFO) stack structure used to dynamically record the function call relationship during the simulation.
[0021] Step S205: Instrument function return approximation logic uniformly before writing all PC class instructions. Since function return instructions are not uniform under the ARM architecture, this step instrumentes all instructions that may modify the program counter uniformly at the TCG front end.
[0022] Step S206, the execution flow of the instrumentation function return approximation logic is as follows: function return control flow determination and function call stack popping logic. After the unified instrumentation in step S205, when a control flow jump to write PC is about to occur, the target address to be written to PC in the instruction is obtained as a candidate return address. Then, the top element of the function call stack is read. The top element of the stack stores the original return address of the corresponding function call. The original return address and the top return address of the stack are interpolated and compared. If the distance between the two is within a preset threshold range, the jump is considered a valid function return operation, and the top element of the function call stack is popped at this time. If the difference exceeds the threshold, the jump is considered not to be a function return, and no popping operation is performed.
[0023] Step S207, the function call stack snapshot maintenance step, combines the function call stack information maintained in step S206, and uses the application's heap memory allocation and release behavior as the trigger condition to collect the current function call stack snapshot information in real time, and stores it together with the heap memory allocation and release information in the memory allocation record. This is used to quickly locate the source of the relevant function call when detecting memory leaks, and improve the efficiency of vulnerability analysis.
[0024] Furthermore, in step S205, all instructions that may modify the program counter include BX, POP, LDR, and MOV.
[0025] BX is a jump instruction implemented through register addressing, usually LR, and is the most commonly used instruction for function return.
[0026] POP is a stack operation instruction that pops the return address stored on the stack directly into the PC register to return the function.
[0027] LDR is a load instruction that loads the address value from memory space into the PC register and updates the stack pointer.
[0028] MOV is a register transfer instruction that directly assigns the value of the specified register to the PC register.
[0029] Further, step three involves the following process: Step S301: The target program under test triggers a heap memory allocation operation. When the target program under test calls the standard library's heap memory allocation function and executes the actual heap memory allocation process during the simulation, the allocation pointer returned by the allocation and the corresponding memory allocation size are recorded.
[0030] Step S302: After successfully returning the allocation pointer, read the function call information in the function call stack, obtain the current call stack snapshot, and then save the allocation pointer, the corresponding memory allocation size, and the function call stack snapshot data in the constructed heap block metadata.
[0031] In step S303, the target program under test triggers a heap memory release operation. When the application under test calls free or when realloc causes the memory block to be reclaimed, an index match is performed in the global heap memory record structure based on the pointer passed when the target program under test calls the release function. If the match fails, the behavior is marked as "abnormal release" to assist in subsequent error location; if the match is successful, S304 is executed.
[0032] Step S304: Record the function call stack snapshot corresponding to the release context and update the heap block metadata. After finding the corresponding heap block metadata in step S303, this step immediately obtains the current function call stack snapshot to represent the call path information of the release behavior, and updates the release call stack in the heap block metadata.
[0033] Further, in step four, the following process will be executed: Step S401: Traverse the global heap memory allocation record linked list maintained during runtime, and read the metadata information of each heap block in turn. The metadata includes the starting address of the heap block, the allocation size, the allocation context function call stack snapshot, and the release context function call stack snapshot.
[0034] Step S402: For each heap block metadata, determine whether it contains valid release context function call stack snapshot information; if the call stack snapshot exists, it indicates that the corresponding heap block has been released normally, and skip directly; otherwise, proceed to step S403.
[0035] Step S403: For heap block metadata that does not have a release context call stack snapshot, determine that the heap block metadata is in an unreleased state, read the function call stack snapshot information saved when the heap block metadata was allocated, in order to restore the allocation context of the heap block in the program execution path, thereby providing a basis for leak location.
[0036] Step S404: Classify and aggregate the unreleased heap blocks according to the call stack snapshot of the allocation context, allocation size, and the module or thread identifier to which they belong, and count the number of leaks in each category and the total size in bytes.
[0037] Step S405: For each unreleased heap block metadata, record its leakage information in the memory leak report; the output information includes the heap block address, allocation size, and allocation context function call stack; the report is output to standard output, log file, or other persistent storage media for subsequent manual analysis or toolchain processing.
[0038] Beneficial effects: This paper presents a memory leak vulnerability detection method based on instruction translation instrumentation. By deeply integrating instruction translation layer instrumentation, dynamic call stack reconstruction, and memory operation tracing, a complete closed-source firmware memory leak detection solution is constructed. This method is highly versatile, independent of specific firmware or source code; it provides precise location, directly identifying the code path leading to the leak; and it is highly practical, seamlessly integrating into existing fuzzing processes, significantly improving the efficiency and depth of memory leak vulnerability discovery and diagnosis in closed-source firmware security analysis. Attached Figure Description
[0039] Figure 1 A flowchart of a memory leak vulnerability detection method based on instruction translation instrumentation provided in this embodiment of the invention; Figure 2 This is a flowchart illustrating the steps of function call behavior tracing and function call stack recovery in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the heap memory allocation and release tracking steps based on a preloading method, as described in an embodiment of the present invention. Figure 4 This is a flowchart of the memory leak detection steps before program exit in an embodiment of the present invention. Detailed Implementation
[0040] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0041] One embodiment of this disclosure provides a memory leak vulnerability detection method based on instruction instrumentation, the overall process of which is as follows: Figure 1 As shown. This method is mainly aimed at embedded closed-source firmware based on the ARM architecture. The following uses a CGI program in the firmware of a specific ARM32 architecture BMC (Baseboard Management Controller) as an example. The implementation steps of this method are described in detail below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the invention.
[0042] Step 1: Construct a simulation execution environment for closed-source firmware and maintain a function call stack to record the function call relationships during program execution; In this embodiment, the complete file system contained in the closed-source firmware is extracted using the unpacking tool binwalk. The target CGI program is analyzed using the static analysis tool readelf to analyze the list of dynamic link libraries that the target CGI program depends on and the path of the program interpreter. Based on the program interpreter version, a compilation toolchain is selected, and the QEMU user-mode emulator is compiled as the simulation execution engine. When running QEMU in a Linux environment, the environment variable QEMU_LD_PREFIX is set to make the file system extracted from the firmware the root file system of QEMU, providing dynamic link libraries for the target CGI program, constructing a complete runtime environment, enabling the target CGI program to start and execute normally, and ensuring that the target contains the dynamic link libraries used by the target CGI program in the closed-source firmware environment. In this embodiment of the invention, a lightweight simulation environment is constructed based on the QEMU user-mode simulator. The lightweight simulation environment refers to a simulation environment that, based on dynamic binary translation technology, only simulates the process-level instruction flow of the target program, without simulating the complete hardware peripherals and operating system kernel execution environment of the target architecture. This environment uses the QEMU user-mode simulator to translate the binary instructions of the target architecture (such as ARM32 architecture or ARM64 architecture) into the instructions of the host architecture in real time, and transparently forwards the system call requests issued by the target program for the target architecture kernel to the host kernel for execution through the system call mapping mechanism.
[0043] Step 2: Perform function call behavior tracing and function call stack restoration.
[0044] This step is completed in the front end of QEMU's Tiny Code Generator (TCG). The TCG front end refers to the execution phase that dynamically translates and semantically parses the native instructions of the target architecture (Guest Instructions). This phase is a processing component that decodes, classifies, and converts instructions into intermediate representations (TCGIR) before they enter the host instruction generation process. At this stage, instrumentation logic can be implemented on instructions with control flow change semantics to record function call return addresses and approximate function return behavior, enabling dynamic construction and restoration of the call stack.
[0045] The specific process of function call behavior tracing and function call stack restoration steps is as follows: Figure 2 As shown: Step S201: Obtain the binary firmware application for the ARM architecture under test. QEMU obtains the application from the closed-source binary firmware of the ARM architecture under test. In step S202, when the TCG translation front end parses control flow-related instructions and translates the target ARM32 instructions, it instrumentes specific function call instructions at the intermediate representation level of the TCG to identify function call instructions in the ARM instruction set, mainly BL, BLX instructions, and other implicit call instructions. Among them, BL is a jump instruction with link register update, used for subroutine calls in the same instruction set state; BLX is a jump instruction with link register update and state switching, used for switching between ARM state and Thumb state; other implicit call instructions are equivalent call sequences implemented by directly modifying the link register $LR$ and combining it with jump instructions under specific compilation optimization conditions.
[0046] Step S203, the specific instrumentation operation process is as follows: Instrument the function call stack push logic before the function call instruction. When the function call instruction described in step S202 is translated, a custom helper function call is inserted into the generated TCG intermediate representation. The core operation of this helper function is to obtain the address of the next instruction after the current instruction, i.e., s->base.pc_next, which is the return address after the function call.
[0047] Step S204: Construct a chained function call stack data structure and maintain a dedicated function call stack. Push the return address obtained in step S203 after the function call into this function call stack as the function call location information. This function call stack is allocated in the QEMU thread context and is a Last-In-First-Out (LIFO) stack structure used to dynamically record function call relationships during simulation.
[0048] Step S205: Instrument approximate function return logic before all write PC-type instructions. In this embodiment, write PC-type instructions refer to instructions that modify the control flow. Since function return instructions are not uniform under the ARM architecture, this step instrumentes all instructions that may modify the program counter (PC) at the TCG front end. Instructions that may modify the program counter include BX, POP, LDR, and MOV. BX is a jump instruction implemented through register addressing, usually LR, and is the most commonly used instruction for function returns. POP is a stack operation instruction that pops the return address stored on the stack directly into the PC register to achieve function return. LDR is a load instruction that loads the address value from memory space into the PC register and updates the stack pointer. MOV is a register transfer instruction that directly assigns the value of the specified register to the PC register.
[0049] Step S206, the execution flow of the instrumentation function return approximation logic is as follows: function return control flow determination and function call stack pop logic. After the unified instrumentation in step S205, when a control flow jump to write PC is about to occur, the target address to be written to PC in the instruction is obtained as a candidate return address. Then, the top element of the function call stack is read. This top element stores the original return address of the corresponding function call. The original return address and the top return address are interpolated and compared. If the distance between the two is within a preset threshold range (this threshold is set to a small value, such as within 4 bytes), the jump is considered a valid function return operation, and the top element of the function call stack is popped at this time. If the difference exceeds the threshold, the jump is considered not a function return, and no pop operation is performed. Through step S206, under the conditions of no unified return instruction encoding, Thumb / ARM state switching, and alignment optimization, the function return behavior can be approximately inferred, thereby maintaining the consistency of the function call stack and improving the robustness of function call path recovery.
[0050] Step S207, the function call stack snapshot maintenance step, combines the function call stack information maintained in step S206, and uses the application's heap memory allocation and release behavior as the trigger condition to collect the current function call stack snapshot information in real time, and stores it together with the heap memory allocation and release information in the memory allocation record. This is used to quickly locate the source of the relevant function call when detecting memory leaks, and improve the efficiency of vulnerability analysis.
[0051] Step 3: Track heap memory allocation and deallocation based on preloading. For each memory allocation and deallocation operation, record the location and length of the allocated memory block and the current function call stack as context information.
[0052] This step intercepts standard library memory management functions through preloading. These functions, including `malloc`, `calloc`, `realloc`, and `free`, are used to perform heap memory allocation and deallocation. At runtime, these preloaded functions are replaced with custom wrapper functions. These custom wrapper functions record heap memory allocation and deallocation behavior in a custom implementation, including allocation size, return address, and function call stack snapshots during allocation and deallocation. Based on this information, a mapping between heap memory objects and function call contexts can be constructed, thus supporting memory leak detection and location.
[0053] Write a custom dynamic link library (the relationship between the custom wrapper functions and the custom dynamic link library). This custom dynamic link library serves as both a logical carrier and a deployment unit, internally encapsulating multiple custom wrapper functions with the same names as those in the standard library. These custom wrapper functions act as the exported symbolic interfaces of the dynamic link library. After the library is loaded into the target program's process space, the dynamic linker's symbol priority mechanism overrides the original symbolic entries such as malloc and free. The two constitute a "container" and "logical implementation" relationship, ensuring that the monitoring code can intercept every heap memory operation of the target program. For example, build the libmem_trace.so library. In this library, use the dlsym function to obtain the original addresses of memory management functions in the standard library and implement their wrapper functions. Compile this library, ensuring its compatibility with the target program's architecture (ARM32 in this example). Then, when starting QEMU simulation, preload the library via the LD_PRELOAD environment variable.
[0054] When the target program calls the memory allocation function malloc or calloc: control flow is hijacked to a custom wrapper function. The wrapper function calls the original allocation function, obtains the memory block address ptr and size size, and immediately acquires a complete snapshot of the current function call stack, which contains the complete call chain tracing back from the current allocation point. Subsequently, ptr, size, the call stack snapshot, and other metadata (such as allocation sequence number and timestamp) are inserted as a node into a global, thread-safe memory allocation hash table and linked list.
[0055] When the target program calls the memory release function free(ptr): the control flow is hijacked to the custom free wrapper function. The wrapper function searches for the node with address ptr in the global linked list. If found, the node is marked as "released" or removed from the linked list to avoid dangling pointers.
[0056] The specific process of heap memory allocation and deallocation tracing based on the preloading method is as follows: Figure 3 As shown: In step S301, the application under test triggers a heap memory allocation operation. When the application under test calls the heap memory allocation functions such as malloc, calloc, and realloc in the standard library during the simulation, since the custom dynamic link library is preloaded in this embodiment using the LD_PRELOAD method, the control flow first enters the corresponding wrapper function in the dynamic link library. The wrapper function uses the dlsym function to obtain the real entry point of the original memory management function. After calling the original heap memory allocation function to execute the actual heap memory allocation process, it records the pointer returned by the allocation and the corresponding memory allocation size.
[0057] Step S302 involves acquiring a snapshot of the function call stack at the heap memory allocation site and establishing a heap block record. After successfully returning the allocation pointer, this step reads the function call information from the function call stack to obtain the current call stack snapshot. This snapshot completely represents which function allocated the corresponding memory block and which specific function called the heap memory allocation function to allocate this heap memory. Subsequently, the memory pointer returned by allocation, the memory allocation size, and the function call stack snapshot recorded in step S301 are saved in the constructed heap block metadata. To support efficient querying and concurrent thread access, this embodiment uses a globally maintained thread-safe linked list structure to maintain the heap block metadata and establish a mapping relationship between heap memory objects and function call paths.
[0058] In step S303, the application under test triggers a heap memory release operation. When the application under test calls free or realloc causes the memory block to be reclaimed, since the control flow is also intercepted by the encapsulation function, this step performs an index matching in the global heap memory record structure based on the pointer passed when the application under test calls the release function. If the query fails, the behavior is marked as "abnormal release" to assist in subsequent error location; if the query succeeds, the release processing logic of the corresponding node is executed.
[0059] Step S304: Record the function call stack snapshot corresponding to the release context and update the heap block metadata. After finding the corresponding heap block metadata in step S303, this step immediately obtains the current function call stack snapshot to represent the call path information of the release behavior. Update the release call stack in the heap block metadata. This can be extended to detect dangling pointers and their usage after release using a "released" status flag.
[0060] Step 4: Memory leak detection before the target program exits. At the end of the simulation, the recorded memory allocation information is traversed to determine if there is a memory leak.
[0061] During the QEMU emulator's operation, the exit events of the target program (i.e., the target program's termination) are monitored, including normal and abnormal exits (e.g., by intercepting the `exit_group` system call). When an impending normal or abnormal termination is detected, a memory leak detection process is automatically triggered. The detection logic is as follows: traverse the global memory allocation list and check the status of each node in the list. Any node not marked as "freed" is considered a potential memory leak, and a detailed report is output for each leaking node.
[0062] The specific process for detecting and locating memory leaks when the program exits is as follows: Figure 4 As shown: Step S401 involves traversing and reading the heap block metadata of the application under test. The system first traverses the global heap memory allocation record linked list maintained during runtime, and reads the metadata information of each heap block in turn. This metadata includes, but is not limited to, the starting address of the heap block, the allocation size, the allocation context function call stack snapshot, and the release context function call stack snapshot.
[0063] Step S402, the heap block release detection step, involves the system determining whether each heap block's metadata contains a valid function call stack snapshot of the release context. If the call stack snapshot exists, it indicates that the corresponding heap block has been released normally and can be skipped directly to avoid misjudgment.
[0064] Step S403 involves obtaining the allocation context information of unreleased heap blocks. When the system detects that a heap block's metadata lacks a release context call stack snapshot, it determines that the heap block's metadata is in an unreleased state. At this time, the system reads the function call stack snapshot information saved during the allocation of the heap block's metadata to restore the allocation context of the heap block's metadata in the program execution path, thereby providing a basis for leak location. Optionally, the system can further parse the source file path, symbol names, and line number information corresponding to the call stack to improve location efficiency.
[0065] Step S404, the leak aggregation and classification analysis step, classifies and aggregates unreleased heap blocks based on the allocation context call stack snapshot, allocation size, and the identifier of the module or thread to which they belong, and counts the number and total byte size of each type of leak. This aggregation process identifies batch leaks caused by the same call path, helping to quickly locate weak points in memory management.
[0066] Step S405 involves generating a memory leak report. For each unreleased heap block metadata, the system records its leak information in the memory leak report. The output information includes the heap block address, allocation size, allocation context function call stack, etc. This report can be output to standard output, a log file, or other persistent storage media for subsequent manual analysis or toolchain processing.
[0067] In summary, the above are merely preferred embodiments of the present invention and are 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 within the scope of protection of the present invention.
Claims
1. A memory leak vulnerability detection method based on instruction translation instrumentation, characterized in that, Includes the following steps: Step 1: Construct a simulation execution environment for closed-source firmware and maintain a function call stack to record the function call relationships during program execution; Step 2: Perform function call behavior tracing and function call stack restoration; Step 3: Track heap memory allocation and deallocation based on preloading. For each memory allocation and deallocation operation, record the location and length of the allocated memory block and the current function call stack as context information. Step 4: Memory leak detection before the target program exits. At the end of the simulation, the recorded memory allocation information is traversed to determine if there is a memory leak.
2. The memory leak vulnerability detection method based on instruction translation instrumentation according to claim 1, characterized in that, Step one: Constructing a simulation execution environment for closed-source firmware, the steps are as follows: Use QEMU user mode to build a simulation runtime environment for the target closed-source firmware; Extract the file system and the target program to be analyzed from the target closed-source firmware; Static analysis is used to extract the dynamic link libraries and loader paths that the target program depends on. The root directory that the target program depends on is specified by setting the QEMU_LD_PREFIX environment variable; Compile QEMU using a cross-compilation toolchain compatible with the target closed-source firmware.
3. A memory leak vulnerability detection method based on instruction translation instrumentation according to claim 1 or 2, characterized in that, The simulation runtime environment for the target closed-source firmware constructed using QEMU user mode is a lightweight simulation environment. This lightweight simulation environment refers to an environment that, based on dynamic binary translation technology, only simulates the process-level instruction flow of the target program, without simulating the complete hardware peripherals and operating system kernel execution environment of the target architecture. This environment uses the QEMU user-mode simulator to translate the binary instructions of the target architecture into the instructions of the host architecture in real time, and transparently forwards the system call requests issued by the target program for the target architecture kernel to the host kernel for execution through the Syscall Mapping mechanism.
4. The memory leak vulnerability detection method based on instruction translation instrumentation according to claim 1, characterized in that, Step two involves completing the TCG front-end in the micro code generator. The TCG front-end refers to the execution stage that dynamically translates and semantically parses the native Guest Instructions of the target architecture. Before the instructions enter the host instruction generation process, this stage decodes, classifies, and converts them into intermediate representations (TCG IR) processing components. In this stage, instrumentation logic is implemented on instructions with control flow change semantics to record function call return addresses and approximate function return behavior, thereby realizing the dynamic construction and restoration of the call stack.
5. The memory leak vulnerability detection method based on instruction translation instrumentation according to claim 4, characterized in that, Step two is specifically executed as follows: Step S201: Obtain the binary firmware application for the ARM architecture under test. QEMU obtains the application from the closed-source binary firmware of the ARM architecture under test. Step S202: When parsing control flow related instructions at the TCG translation front end and translating the target ARM32 instructions, instrumentation is performed on specific function call instructions at the TCG middle representation layer to identify function call instructions in the ARM instruction set. Step S203, the specific instrumentation operation process is as follows: Instrument the function call stack push logic before the function call instruction. When the function call instruction described in step S202 is translated, a custom helper function call is inserted into the generated TCG intermediate representation. The core operation of this helper function is to obtain the address of the next instruction of the current instruction, i.e., s->base.pc_next. This address is the return address after the function call. Step S204: Construct a chained function call stack data structure, maintain a dedicated function call stack, and push the return address after the function call obtained in step S203 as the position information of the function call into the function call stack; The function call stack is allocated in the thread context of QEMU and is a last-in-first-out (LIFO) stack structure used to dynamically record the function call relationship during simulation. Step S205: Instrument function return approximation logic uniformly before writing all PC class instructions. Since function return instructions are not uniform under the ARM architecture, this step instrumentes all instructions that may modify the program counter uniformly at the TCG front end. Step S206, the execution flow of the instrumentation function return approximation logic is as follows: function return control flow determination and function call stack pop logic. After the unified instrumentation in step S205, when a control flow jump to write PC is about to occur, the target address to be written to PC in the instruction is obtained as a candidate return address. Then, the top element of the function call stack is read. The top element of the stack stores the original return address of the corresponding function call. The original return address and the top return address of the stack are compared by interpolation. If the distance between the two is within a preset threshold range, the jump is considered a valid function return operation, and the top element of the function call stack is popped at this time. If the difference exceeds the threshold, the jump is considered not to be a function return, and no pop operation is performed. Step S207, the function call stack snapshot maintenance step, combines the function call stack information maintained in step S206, and uses the application's heap memory allocation and release behavior as the trigger condition to collect the current function call stack snapshot information in real time, and stores it together with the heap memory allocation and release information in the memory allocation record. This is used to quickly locate the source of the relevant function call when detecting memory leaks, and improve the efficiency of vulnerability analysis.
6. The memory leak vulnerability detection method based on instruction translation instrumentation according to claim 4, characterized in that, In step S205, all instructions that may modify the program counter include BX, POP, LDR, and MOV. BX is a jump instruction implemented through register addressing, usually LR, and is the most commonly used instruction for function return. POP is a stack operation instruction that pops the return address stored in the stack directly into the PC register to return the function. LDR is a load instruction that loads the address value from memory space into the PC register and updates the stack pointer. MOV is a register transfer instruction that directly assigns the value of the specified register to the PC register.
7. The memory leak vulnerability detection method based on instruction translation instrumentation according to claim 1, characterized in that, Step three is specifically executed as follows: Step S301: The target program under test triggers a heap memory allocation operation. When the target program under test calls the standard library's heap memory allocation function and executes the actual heap memory allocation process during the simulation, the allocation pointer returned by the allocation and the corresponding memory allocation size are recorded. Step S302: After successfully returning the allocation pointer, read the function call information in the function call stack, obtain the current call stack snapshot, and then save the allocation pointer, the corresponding memory allocation size, and the function call stack snapshot data in the constructed heap block metadata. Step S303: The target program under test triggers a heap memory release operation. When the application under test calls free or when realloc causes the memory block to be reclaimed, an index match is performed in the global heap memory record structure based on the pointer passed when the target program under test calls the release function. If the match fails, the behavior is marked as "abnormal release" to assist in subsequent error location. If the match is successful, execute S304; Step S304: Record the function call stack snapshot corresponding to the release context and update the heap block metadata. After finding the corresponding heap block metadata in step S303, this step immediately obtains the current function call stack snapshot to represent the call path information of the release behavior, and updates the release call stack in the heap block metadata.
8. The memory leak vulnerability detection method based on instruction translation instrumentation according to claim 1, characterized in that, Step four is specifically executed as follows: Step S401: Traverse the global heap memory allocation record linked list maintained during runtime, and read the metadata information of each heap block in turn. The metadata includes the starting address of the heap block, the allocation size, the allocation context function call stack snapshot, and the release context function call stack snapshot. Step S402: For each heap block metadata, determine whether it contains valid release context function call stack snapshot information; If the call stack snapshot exists, it indicates that the corresponding heap block has been released normally, so skip directly; otherwise, proceed to step S403. Step S403: For heap block metadata that does not have a release context call stack snapshot, determine that the heap block metadata is in an unreleased state, read the function call stack snapshot information saved when the heap block metadata was allocated, in order to restore the allocation context of the heap block in the program execution path, thereby providing a basis for leak location; Step S404: Classify and aggregate the unreleased heap blocks according to the call stack snapshot of the allocation context, allocation size, and the module or thread identifier to which they belong, and count the number of leaks in each category and the total size in bytes; Step S405: For each unreleased heap block metadata, record its leakage information in the memory leak report; the output information includes the heap block address, allocation size, and allocation context function call stack; the report is output to standard output, log file, or other persistent storage media for subsequent manual analysis or toolchain processing.