A Sign-Dependency-Free Memory Manager Identification Method and System

Abstract

This invention discloses a method and system for identifying unsigned dependency memory managers and data structures, belonging to the field of reverse engineering. To address the problems of inaccurate identification of binary program memory managers, difficulty in constructing verification environments, and inability to parse the semantics of heap memory data structure fields in unsigned and nondeterministic environments, this invention dynamically captures portable operating system interface instructions and constructs a call stack queue by loading the program into a virtualization framework. It analyzes pointers to generate a memory operation function event flow matrix to automatically identify and pair allocation and release functions. It reconstructs the initial analysis environment using address hooks, process copying, and instruction injection, and executes verification transactions in a targeted manner. Micro-behavioral analysis is performed through memory instrumentation and byte-level modification of non-load fields, combined with heuristic rule inference of field functions. This invention enables unsigned, automated, deep identification of heap memory managers and hidden metadata structures in cross-architecture binary programs.

Description

Technical Field

[0001] This invention belongs to the field of reverse engineering technology, specifically relating to a method and system for identifying memory managers without symbolic dependencies. Background Technology

[0002] Modern operating systems divide memory into stack memory, managed by the compiler, and heap memory, managed by programmers through a memory management interface provided by the memory manager. The memory management interface is a set of functions for managing heap memory space, typically including allocation and deallocation capabilities. It abstracts the operating system's memory operation-related system calls and accelerates and optimizes the performance of users acquiring heap memory through memory management algorithms. Built-in memory managers provided by the operating system's standard library are usually called standard memory managers, such as ptmalloc commonly used on Linux, NT Heap commonly used on Windows, and libmalloc commonly used on macOS. To support as many use cases as possible, standard memory managers need to balance security, performance, and auditability. However, many software programs, to meet specific memory requirements, use non-standard memory managers with memory management algorithms and interfaces that differ from the standard memory manager. Furthermore, during the linking phase of the compilation process, the process of directly merging the code of library functions and variables referenced by the target program into the final executable file is called static linking. The resulting build target is often a single executable file that can run independently and does not depend on external library files. The process of building the library functions referenced by the target program as independent files with file extensions like .so, .dylib, or .dll is called dynamic linking. For dynamically linked executable programs, during actual program loading, the operating system's dynamic linker dynamically looks up and loads relevant code or variables through mapping records in the symbol table. During compilation, writing additional information without code functionality into specific code segments in the executable program is called debugging symbols. Debugging symbols provide debuggers or decompilers with mapping information of source code such as function names, variable names, file names, and line numbers, facilitating debugging and analysis of the build artifacts. However, because they are unrelated to program execution, debugging symbols are often not included in the official release version of the software.

[0003] At the technical level, the first type is a symbol-based identification technique. This technique primarily relies on function signature information and variable information contained in debugging symbols or dynamic linking symbols within the program to distinguish whether a function is a heap memory management function. For example, in a Linux system, when an executable program starts, the dynamic linker uses the `_dl_runtime_resolve` function to relocate the function using its symbolic name and constructs and initializes the Procedure Linking Table (PLT) and the Global Offset Map (GOT). Figure 1 As shown. Since memory managers typically exist independently as dynamic link libraries, the relocation process can use the system's dynamic linker to record and block the process of finding external functions using symbols. Then, by matching symbol information with signature information, heap manager functions can be identified. Memory analysis tools such as AddressSanitizer use this principle. However, this technique often focuses on matching the signature patterns of standard functions in the standard library during reverse engineering. It is prone to false positives for functions with the same signature pattern and may miss detections for functions in non-standard memory managers. Furthermore, debugging symbols are often unavailable in real release software.

[0004] The second type is based on system call identification techniques, which rely primarily on identifying the characteristics of system calls at the system level. When the heap manager attempts to acquire new memory, it must explicitly invoke special system calls to request new virtual memory space from the operating system. For example, in Linux systems, this typically involves calling the brk, sbrk, and mmap system calls. Early static analysis methods could directly filter, judge, and locate the issue by finding functions that called the brk or sbrk system calls or by tracing the program's execution process and diagnosing virtual memory allocation and deallocation behavior through privileged system calls such as ptrace. IBM's Purify used this method. However, brk and sbrk are not POSIX standards and have serious performance issues. They have gradually been replaced by mmap, which is mainly used for zero-copy file I / O and is widely used in regular file operations. As a result, this technique is rarely used and is almost unusable in modern operating systems.

[0005] The third type is a data flow analysis-based identification technique. This technique mainly relies on analyzing key data flows in the program. It uses dynamic analysis tools such as Intel Pintool to trace the dynamic execution process of the program, dividing different regions in memory into stack, global or static variable areas, code segments, and heap areas. By tracing the creation and destruction of pointers and the reading and writing of data in the heap area, it reverse-tracks the related operation functions to find the heap memory manager related functions. This method usually needs to combine symbol-based and system call-based identification techniques for multi-dimensional analysis. There are few existing solutions that use only data flow analysis.

[0006] The two closest prior art solutions to this invention are as follows.

[0007] The “MemBrush” scheme (see Chen, Xi, Asia Slowinska, and Herbert Bos. "MemBrush: A practical tool to detect custom memory allocators in C binaries." 2013 20th Working Conference on Reverse Engineering (WCRE). IEEE, 2013.) defines a set of generic heap memory manager characteristics, abstracting memory allocation, deallocation, and reallocation behaviors into function behavioral characteristics. It then uses dynamic taint analysis techniques to filter the set of memory manager functions through a five-stage pipeline. However, this scheme relies on multiple deterministic executions of the program, making it unable to analyze programs that change with each restart. It has poor reproducibility in large programs and always assumes that the function prototypes are patterns from the standard library, resulting in poor ability to identify heap memory managers with different prototypes.

[0008] The “HeapHopper” scheme (see Eckert, Moritz, et al. "{HeapHopper}: Bringingbounded model checking to heap implementation security." 27th USENIX SecuritySymposium (USENIX Security 18). 2018.) is based on model checking and symbolic execution technology. It focuses on the Linux standard library libc and uses symbolic execution technology to set a fine-grained bounded model for heap memory boundary to accurately identify it. Furthermore, it performs secondary modeling of the memory in libc to more thoroughly test existing libraries.

[0009] Current heap memory manager identification techniques, especially existing dynamic data flow analysis techniques, still have the following technical problems that need to be addressed.

[0010] First, existing technologies have deterministic execution dependencies. Analysis solutions often require the program to be executed multiple times, and the sequence of function calls triggered in each execution must be exactly the same. However, in real-world scenarios, many programs that use custom heap memory managers heavily rely on elements such as clocks and networks, and their operation is often full of uncertainty, making it difficult to apply solutions that require repeated analysis in real-world scenarios.

[0011] Secondly, existing analysis solutions often rely excessively on interface abstraction and modeling of standard library-style memory managers. This directly results in these solutions having severely insufficient analytical capabilities when facing memory managers with non-standard interfaces, often failing to accurately identify functions or understand the semantics of related fields.

[0012] Finally, existing solutions often focus too much on identifying interface functions, while lacking the ability to analyze data structures in memory managers, or their analysis is limited to detecting overflow types. The understanding of heap memory data structures and their semantics remains a blank in current technology. Summary of the Invention

[0013] The purpose of this invention is to solve the problems of inaccurate identification of binary program memory managers, difficulty in building verification environments, and inability to parse the semantics of heap memory data structure fields in unsigned and nondeterministic environments. It proposes a memory manager identification method and system without sign-dependent dependencies, which can achieve the effects of accurately identifying memory interfaces, reproducing analysis environments with low overhead, and deeply parsing the functional semantics of heap block fields under unsigned dependencies.

[0014] To achieve the above objectives, the present invention adopts the following technical solution.

[0015] A sign-independent memory manager identification method includes the following steps: The binary executable program to be analyzed is loaded into the virtualization framework and run. The allocatable heap memory space is determined by excluding non-heap memory segments. Capture instructions in the form of portable operating system interfaces during runtime and intercept function calls in real time; Based on the intercepted function calls, the call stack sequence is dynamically restored, and a call stack queue is constructed. When popping from the stack, identify the input parameters and return values ​​of functions in the call stack queue, mark the pointer source of functions whose parameters contain heap memory pointers, and track their lifecycle; After the binary executable program finishes execution, the creation and destruction process of the traced pointers is analyzed to generate a memory operation function event flow matrix; Based on the event flow matrix of memory operation functions, data flow association is constructed, behavior similarity analysis and functional semantic verification are performed to identify memory allocation and release function pairs and obtain a function pairing mapping table; The binary executable program is executed a second time based on the function pairing mapping table. The initial state is established by using address hooks and forced execution, and the initial analysis environment is set up. In the initial analysis environment, the process state is copied by process duplication, and bytecode sequences are injected into the copied child process to execute a preset memory operation transaction sequence in a targeted manner, thereby verifying whether the memory operation behavior meets expectations. For memory allocation and deallocation functions that meet the expectations, memory instrumentation is performed to obtain the heap block size and number of fields. The values ​​of non-load fields are modified at the byte level and the verification is repeated. The functional semantics of each offset field are also identified. Integrate the functional semantics and spatial layout information of each offset field to output the heap memory data structure identification results.

[0016] Furthermore, determining the allocatable heap memory space by excluding non-heap memory segments includes: Identify the static loading segment, high-address stack memory segment, and kernel state segment during the execution of a binary executable program; Excluding the static loading segment, the high-address stack memory segment, and the kernel state segment from the runtime space, the remaining virtual memory space is determined as allocatable heap memory space.

[0017] Furthermore, based on the intercepted function calls, the call stack sequence is dynamically reconstructed, and a call stack queue is constructed, including: The current call stack sequence is restored based on the intercepted function calls, and dynamically inserted into the call stack constructor in the form of a singly linked list to establish a call stack queue. When a pop event is detected, a pop signal is sent to subsequent modules using the call stack queue and a callback event is triggered.

[0018] Furthermore, the current call stack sequence is reconstructed based on the intercepted function calls and dynamically inserted into the call stack constructor in the form of a singly linked list, including: The control flow data corresponding to the function call is directed to the call stack reconstruction module through control flow branches; The call stack reconstruction module is used to identify the interface parameters of the portable operating system, and the identification results are fed back to the virtualization layer to perform dynamic analysis framework initialization.

[0019] Furthermore, based on the event flow matrix of memory operation functions, data flow association is constructed, behavioral similarity analysis is performed, and functional semantic verification is conducted to identify memory allocation and deallocation function pairs, including: Based on the event flow matrix of memory operation functions, the life cycle of pointers is traced, and a data flow association is constructed and the degree of association is quantified between the producer function identified as the pointer creator and the consumer function activated by the pointer user. Based on the assumption that the statistical characteristics of the call frequency of paired resource allocation and release operations during the runtime are similar, similarity screening is performed on function pairs with data flow association to determine candidate function pairs; Perform semantic function verification on the candidate function pairs and lock the memory allocation and deallocation function pairs.

[0020] Furthermore, semantic functional verification is performed on the candidate function pairs to lock the memory allocation and deallocation function pairs, including: The candidate function is stimulated by an active interactive probing mechanism. By probing stimuli, the resource allocation semantics of the producer function and the resource release semantics of the consumer function in the candidate function pair are verified, and the locked memory allocation and release function pairs are output.

[0021] Furthermore, a bytecode sequence is injected into the copied child process to execute a pre-defined sequence of memory operation transactions, including: The allocation operation is executed twice in sequence to obtain the allocation transaction sequence; The allocation, release, and usage operations are executed sequentially to obtain the allocation, release, and usage transaction sequence. The allocation, release, and overflow operations are executed sequentially to obtain the allocation, release, and overflow transaction sequence. The allocation, release, and error address release operations are executed sequentially to obtain the allocation, release, and error address release transaction sequence. The allocation, overflow, use, and release operations are executed sequentially to obtain the allocation, overflow, use, and release transaction sequence. The allocation and two release operations are executed sequentially to obtain the allocation-release-release transaction sequence.

[0022] Furthermore, memory instrumentation is performed on the memory allocation and deallocation functions that verify compliance with expectations to obtain the heap block size and number of fields. The values ​​of non-load fields are modified at the byte level and verified repeatedly. The functional semantics of each offset field are also identified, including: Memory instrumentation is performed during the execution of memory operation transactions to obtain the memory access range corresponding to allocation and deallocation operations. The relative offset of the allocated heap block to the target pointer is determined based on the memory access range, and the number of fields is calculated. The values ​​of non-load fields are modified at the byte level and repeated verification is performed. Heuristic rules are used to identify the functional semantics of each offset field.

[0023] Furthermore, heuristic rules are used to identify the functional semantics of each offset field, including: If log output and assertion exit are triggered after corrupting data and performing memory loading and register comparison, the current offset field is determined to be the overflow value verification check field. If a subsequent pointer dereference exception occurs after data is obtained and corrupted through pointer dereference, the current offset field is determined to be a linked list field. If a program crashes while releasing a physically adjacent subsequent heap block after the field is destroyed and the current heap block is released, then the current offset field is determined to be the heap block size field. If a field is modified on a block in use, the program calls to release the block. If a duplicate release or invalid operation assertion is triggered, the current offset field is determined to be an occupied or free status flag field. The field is destroyed and the current block is freed. If the freeing function crashes immediately due to an illegal memory read, the current offset field is determined to be a pointer to the previous block or an offset field. The field is destroyed and the current block is released. If the program crashes during subsequent unrelated memory allocation or release, the current offset field is determined to be the free list partition index field. The field is destroyed and the current block is released. If the release function reads multiple other metadata, compares them, and triggers an assertion, then the current offset field is determined to be a metadata checksum or a secure cookie field.

[0024] A sign-independent memory manager identification system, comprising: The dynamic data flow tracing module loads the binary executable program to be analyzed into a virtualization framework for execution. It determines the allocatable heap memory space by excluding non-heap memory segments. During execution, it captures instructions in the form of portable operating system interfaces and intercepts function calls in real time. Based on the intercepted function calls, it dynamically reconstructs the call stack sequence and constructs a call stack queue. Upon popping from the stack, it identifies the input parameters and return values ​​of functions in the call stack queue, marks the pointer source of functions whose parameters contain heap memory pointers, and tracks their lifecycle. After the binary executable program finishes execution, it analyzes the creation and destruction process of the traced pointers, generating a memory operation function event flow matrix. Based on the memory operation function event flow matrix, it performs data flow association construction, behavioral similarity analysis, and functional semantic verification, identifying memory allocation and deallocation function pairs to obtain a function pairing mapping table. The forced execution module is used to execute the binary executable program a second time according to the function pairing mapping table. It establishes the initial state and sets up the initial analysis environment by using address hooks and forced execution. In the initial analysis environment, the process state is copied through process duplication. Bytecode sequences are injected into the copied child process to execute a preset memory operation transaction sequence in a directed manner, verifying whether the memory operation behavior meets expectations. For the memory allocation and deallocation function pairs that meet the verification, memory instrumentation is performed to obtain the heap block size and the number of fields. The values ​​of non-load fields are modified at the byte level and verified repeatedly, and the functional semantics of each offset field are identified. The functional semantics and spatial layout information of each offset field are integrated to output the heap memory data structure identification results.

[0025] The present invention has achieved the following beneficial effects.

[0026] 1. This invention designs a purely dynamic heap memory analysis framework that does not rely on any binary symbol information or source code, effectively avoiding the path explosion and high analysis overhead problems faced by traditional symbol execution schemes. It can be widely adapted and applied to the identification of unsigned dependencies in programs of various general-purpose hardware architectures, including x86, MIPS, ARM, and RISC-V, and has strong versatility and cross-platform capabilities.

[0027] 2. This invention employs function-level pointer data flow propagation technology for control flow capture and lifetime tracking, avoiding the enormous hardware overhead caused by instruction-level fine-grained propagation. It precisely isolates non-heap memory segments through an exclusion method to lock allocatable heap space, and outputs a high-precision memory operation function event flow matrix after program execution, providing complete and quantitative data support for subsequent automated identification.

[0028] 3. In the processing stage, this invention introduces a program data behavior layer, namely the PDB layer. By constructing data flow associations, analyzing dynamic behavior characteristics with highly similar call frequencies, and performing proactive interactive probing function verification, it can achieve automated and accurate matching of memory allocation and release function pairs, significantly eliminating the analysis false alarms and false negatives caused by the lack of symbolic information.

[0029] 4. In the data structure identification stage, this invention introduces address hooks, a forkserver mechanism, and instruction injection technology to quickly reconstruct a stable and legitimate initial operating environment for the memory manager within the same memory context. This not only eliminates analysis errors caused by non-deterministic execution factors such as network and clock, but also provides comprehensive robustness and security verification of memory management behavior through a preset memory operation transaction sequence.

[0030] 5. This invention utilizes fine-grained memory instrumentation technology to determine the physical extent of heap blocks, and performs micro-behavioral analysis of crash modes and log behavior by modifying non-load fields at the byte level and combining seven heuristic rules. It successfully achieves deep semantic understanding and automatic classification of hidden metadata fields such as idle status flags, idle linked list partition indexes, and security cookies, filling the gap in traditional solutions that cannot identify and understand the internal semantic functions of heap memory data structures. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating the principle of dynamic link symbol lookup in a program. Figure 2 This is a simplified flowchart of a sign-free memory manager identification method in this embodiment.

[0032] Figure 3 This is a framework diagram of a sign-free memory manager identification method in one embodiment; Figure 4 This is a flowchart illustrating a sign-free memory manager identification method in this embodiment. Detailed Implementation

[0033] To make the various technical features, advantages, or effects of the present invention more apparent and understandable, detailed descriptions are provided below through embodiments.

[0034] This invention provides a sign-dependent memory manager identification method, such as... Figures 2 to 4 As shown, the method specifically includes steps S1 to S10; wherein, steps S1 to S5 belong to the first stage of heap memory manager analysis, step S6 belongs to the PDB algorithm layer, and steps S7 to S10 belong to the second stage of heap memory data structure identification.

[0035] Step S1: Load the binary executable program to be analyzed into the virtualization framework for execution, and determine the allocatable heap memory space by excluding non-heap memory segments.

[0036] Specifically, after the binary executable program to be analyzed is input into the system, it directly enters the heap memory manager analysis process in stage one. The virtualization framework is started and executed in the virtualization layer, and the initialization of the dynamic analysis framework is completed simultaneously. The entire loading and running process does not require symbol information or complex reverse analysis.

[0037] In an optional embodiment of the present invention, step S1 may include: Step S11: Identify the static loading segment, high-address stack memory segment, and kernel state segment during the execution of the binary executable program.

[0038] Step S12: Exclude the static loading segment, the high address stack memory segment, and the kernel state segment from the running space, and determine the remaining virtual memory space as allocatable heap memory space.

[0039] Specifically, regarding heap memory identification, since this invention does not rely on system call features such as brk or sbrk as basic identification features, it uses an exclusion method to make a judgment during virtualization execution. By excluding the above-mentioned non-heap memory segments, all remaining memory locations are regarded as allocable heap memory space, thereby providing a basic and stable underlying operating environment for subsequent data flow tracing, control flow capture, and instruction-level monitoring.

[0040] Step S2: During operation, capture instructions in the form of a portable operating system interface and intercept function calls in real time.

[0041] Specifically, the call stack recovery and identification process described in this invention mainly relies on the instruction parameter passing conventions agreed upon by the POSIX standard of the portable operating system interface. During program execution, the central processing unit or virtual central processing unit saves the function parameters and return values ​​to registers or stack memory.

[0042] In an optional embodiment of the present invention, step S2 may include: Step S21: Capture the push and pop instructions of the instruction register in the form of a portable operating system interface, and monitor the function call behavior in real time.

[0043] Step S22: Intercept each function call through the instruction capture engine and obtain the specific parameter values ​​by reading the virtual central processing unit register values.

[0044] Specifically, in the x86-64 architecture, registers are typically used as the parameter passing method. In this case, the analysis system can obtain the specific parameter values ​​by reading the values ​​of the virtual CPU registers. The instruction capture engine is not limited to fully virtualized technologies such as QEMU; for CPU-based debug modes, such as Intel PT, the principle is the same as the instruction tracing principle of this technology, allowing for multiple implementation methods to ensure accurate interception of every function call under unsigned conditions.

[0045] Step S3: Dynamically recover the call stack sequence based on the intercepted function calls and construct a call stack queue.

[0046] Specifically, through an efficient singly linked list structure and dynamic recovery mechanism, the system can maintain and update the current function call context in real time, providing accurate call stack path information for subsequent fine-grained parameter analysis and memory pointer tracing.

[0047] In an optional embodiment of the present invention, step S3 may include: Step S31: Restore the current call stack sequence based on the intercepted function calls, and dynamically insert it into the call stack constructor in the form of a singly linked list to establish a call stack queue.

[0048] Specifically, the call stack queue construction module is an efficient singly linked list. During the operation and monitoring of the virtualization framework, the system obtains a real-time call stack sequence through the call stack dynamic recovery technology of the virtualization layer and dynamically inserts it into the call stack constructor.

[0049] In an optional embodiment of the present invention, step S31 may include: Step S311: Guide the control flow data corresponding to the function call to the call stack reconstruction module through the control flow branch.

[0050] Step S312: Use the call stack reconstruction module to identify the interface parameters of the portable operating system and feed the identification results back to the virtualization layer to perform dynamic analysis framework initialization.

[0051] Step S32: When a pop event is detected, a pop signal is sent to the subsequent modules using the call stack queue and a callback event is triggered.

[0052] Specifically, when the system captures a function call and constructs the call stack, the module will send a pop signal to the next module when popping from the stack and trigger the corresponding callback event.

[0053] Step S4: When popping from the stack, identify the input parameters and return values ​​of functions in the call stack queue, mark the pointer source of functions whose parameters contain heap memory pointers, and track their lifecycle.

[0054] In an optional embodiment of the present invention, step S4 may include: Step S41: When the portable operating system interface is popped from the stack and a pop signal is triggered, parameter identification is performed to accurately obtain the function's input parameters and return value parameters, and the recorded parameter values ​​are updated to the call stack queue in real time.

[0055] Step S42: Mark the functions whose parameters contain heap memory pointers and trace the source of their pointers by constructing a lifecycle stream.

[0056] Specifically, to minimize system overhead, the pointer creation, use, and destruction flow constructed in this invention adopts a function-level propagation relationship, avoiding the high performance overhead caused by fine-grained instruction-level propagation. Simply using the passing relationship between function parameters and return values ​​greatly simplifies the granularity of memory tracing and recording, thereby significantly reducing hardware overhead and improving overall analysis efficiency. Memory operation monitoring can be implemented using virtualized memory access events or the memory management unit's memory page access permission change monitoring mechanism. Memory change tracking can be achieved by using a binary differential algorithm between consecutive snapshots to identify memory allocation and release operations.

[0057] Step S5: After the binary executable program finishes execution, analyze the creation and destruction process of the traced pointers and generate a memory operation function event flow matrix.

[0058] Specifically, after the program finishes execution, the analysis system sends an end signal to the analyzer. Upon receiving the signal, the analyzer performs a comprehensive and systematic analysis of the creation and destruction processes of all traced pointers recorded in the call stack queue.

[0059] In an optional embodiment of the present invention, step S5 may include: Step S51: Receive the end signal sent by the analysis system after the binary executable program has finished executing.

[0060] Step S52: Generate a memory operation function event flow matrix by traversing and statistically analyzing the creation and destruction processes of all traced pointers recorded in the call stack queue.

[0061] Specifically, the memory operation function event flow matrix precisely records the number of times the mapping relationship between the creation and use of all pointers is recorded. Structure inference can deduce the organization of data structures based on statistical analysis of memory layout change patterns, thereby providing complete input features for the subsequent automated identification of memory allocation and deallocation function pairs through quantitative and qualitative matrix data.

[0062] Step S6: Based on the memory operation function event flow matrix, data flow association is constructed, behavior similarity analysis is performed, and functional semantic verification is performed to identify memory allocation and release function pairs and obtain a function pairing mapping table.

[0063] Specifically, before proceeding to Phase Two, this invention establishes a Program Data Behavior (PDB) layer for compatibility. This layer aims to automatically identify memory allocation and deallocation function pairs in the program through dynamic behavior analysis, converting function-level pointer streams into a heap memory production and consumption relationship table. The core technical principle of the PDB layer algorithm does not rely on any known function symbols or source code.

[0064] In an optional embodiment of the present invention, step S6 may include: Step S61: Track the lifecycle of pointers according to the memory operation function event flow matrix, build a data flow association between the producer function identified as the pointer creator and the consumer function activated by the pointer user, and quantify the degree of association.

[0065] Specifically, by monitoring the dynamic execution of the program to track the lifecycle of memory pointers, when one function is identified as the creator (producer) of a pointer and another function is identified as the user (consumer) of that pointer, this method establishes a data flow association between the two functions and quantifies the tightness of this association.

[0066] Step S62: Based on the assumption that the statistical characteristics of the call frequency of paired resource allocation and release operations within the runtime are similar, similarity screening is performed on function pairs with data flow association to determine candidate function pairs.

[0067] Specifically, the analysis of behavioral similarity is based on the core technical assumption that any pair of resource allocation and release operations should exhibit a high degree of similarity in their key dynamic behavioral statistical characteristics, especially their call frequency, throughout the complete program runtime. This assumption is used to filter the function pairs that were previously associated to find the candidate pairs with the best matching behavioral characteristics.

[0068] Step S63: Perform semantic function verification on the candidate function pairs and lock the memory allocation and deallocation function pairs.

[0069] In an optional embodiment of the present invention, step S63 may include: Step S631: The candidate function is stimulated by an active interactive probing mechanism.

[0070] Step S632: Verify the resource allocation semantics of the producer function and the resource release semantics of the consumer function in the candidate function pair by probing stimuli, and output the locked memory allocation and release function pair.

[0071] Specifically, semantic function verification is performed to ensure the accuracy of the matching. An active interactive detection mechanism is used to perform semantic function verification on the selected candidate function pairs to confirm that the producer function has indeed executed the semantics of resource allocation and the consumer function has executed the corresponding release semantics. This ultimately locks down the function pairing relationship and obtains a high-probability mapping table.

[0072] Step S7: Execute the binary executable program a second time according to the function pairing mapping table, and establish the initial state and initial analysis environment by using address hooks and forced execution.

[0073] Specifically, in order to fully enter the heap memory data structure identification stage of stage two, this invention will execute the target analysis program for the second time.

[0074] In an optional embodiment of the present invention, step S7 may include: Step S71: When re-executing the target binary executable program, the moment when the candidate allocator finishes its first execution is taken as the initial state through address hooking technology and forced execution technology.

[0075] Step S72: Establish the initial analysis environment based on the initial state.

[0076] Specifically, this mechanism ensures a dual state: first, that all relevant initialization functions have been executed; and second, that the target program can perform at least one memory creation operation normally under the current analysis environment. Through this dual-state assurance mechanism, the system can successfully obtain a highly stable initial analysis environment, laying a solid foundation for subsequent refined memory operation transaction verification and multi-dimensional field functional semantic inference.

[0077] Step S8: In the initial analysis environment, the process state is copied by process duplication. Bytecode sequences are injected into the copied child process to execute a preset memory operation transaction sequence in a targeted manner, and the memory operation behavior is verified to meet expectations.

[0078] Specifically, in the acquired stable initial analysis environment, the system completely copies the current process state through a process replication mechanism. Simultaneously, a forkserver (a creation server awaiting forking) is built at the original process location, allowing users to quickly and in real-time rebuild the initial analysis environment in subsequent analyses. In the forked child process environment, the system dynamically injects the bytecode sequence to be executed into memory via instruction injection, ensuring that subsequent CPU execution is completely directed to the inserted code segment. By executing a series of memory operation transactions, the system can determine whether the memory operation behavior meets expectations. The memory operation transaction designed in this invention is a carefully constructed sequence used to fully verify legal and illegal memory operation behaviors.

[0079] In an optional embodiment of the present invention, step S8 may include: (1) Perform two allocation operations in sequence to obtain the allocation transaction sequence; (2) Perform the allocation, release, and usage operations sequentially to obtain the allocation, release, and usage transaction sequence; (3) Perform allocation, release, and overflow operations in sequence to obtain the allocation, release, and overflow transaction sequence; (4) Perform allocation, release, and error address release operations in sequence to obtain the allocation, release, and error address release transaction sequence; (5) Perform allocation, overflow, use and release operations in sequence to obtain the allocation overflow use release transaction sequence; (6) Perform the allocation and two release operations in sequence to obtain the allocation-release-release transaction sequence.

[0080] Step S9 involves instrumenting the memory allocation and deallocation functions that meet the expectations to obtain the heap block size and number of fields. The values ​​of non-load fields are modified at the byte level and the verification is repeated. The functional semantics of each offset field are also identified.

[0081] In an optional embodiment of the present invention, step S9 may include: Step S91: Memory instrumentation is performed during the execution of the memory operation transaction to obtain the memory access range corresponding to the allocation and release operations.

[0082] Specifically, once the candidate allocation function, reallocation function, and deallocation function are paired and verified, the system can obtain the memory range accessed during allocation and deallocation operations in real time by performing fine-grained memory instrumentation on the above memory operation transaction process.

[0083] Step S92: Determine the relative offset of the allocated heap block to the target pointer based on the memory access range and calculate the number of fields. Modify the values ​​of non-load fields at the byte level and perform duplicate verification. Use heuristic rules to identify the functional semantics of each offset field.

[0084] Specifically, based on the memory range accessed during real-time allocation and deallocation operations, the relative offset of the allocated heap block relative to the target pointer is precisely obtained, allowing the calculation of the number of fields contained in that heap block. The value of each non-load field is then modified at a byte-level resolution, and verification is repeatedly performed. By closely observing program crash behavior and log output, it is determined whether the current offset field belongs to the same field and what the specific function of that field is. This analytical inference process heavily relies on heuristic rules.

[0085] In an optional embodiment of the invention, the heuristic rule further includes the following entries: (1) If log output and assertion exit are triggered after corrupting the data and performing memory loading and register comparison, the current offset field is determined to be the overflow value verification check field. (2) If a subsequent pointer dereference exception occurs after the data is obtained and corrupted through pointer dereference, the current offset field is determined to be a linked list field. (3) If the program crashes when releasing a physically adjacent subsequent heap block after the field is destroyed and the current heap block is released, then the current offset field is determined to be the heap block size field. (4) Modify the field of the block in use, and the program calls to release the block. If the duplicate release or invalid operation assertion is triggered, the current offset field is determined to be the occupied or free status flag field. (5) Destroy the field and release the current block. If the release function crashes immediately due to an illegal memory read, then determine that the current offset field is a pointer to the previous block or an offset field. (6) Destroy the field and release the current block. If the program crashes during subsequent unrelated memory allocation or release, determine that the current offset field is the free list partition index field. (7) Destroy the field and release the current block. If the release function reads multiple other metadata, compares them and triggers an assertion, then the current offset field is determined to be a metadata checksum or a security cookie field.

[0086] Step S10: Integrate the functional semantics and spatial layout information of each offset field, and output the heap memory data structure identification result.

[0087] Specifically, by conducting multiple rounds of byte-level destructive testing and heuristic rule matching at each offset position in fine-grained field analysis, the system can completely collect and parse the boundaries, attributes, and inherent logical relationships of all non-load fields in the target heap memory block. Finally, the system performs multi-dimensional semantic aggregation and structural reorganization on these scattered judgment results, generating the final heap memory data structure mapping output. This output presents the functional definitions and precise spatial layout information of each field in a clear, written technical format, thereby achieving comprehensive visualization and deep semantic understanding of the hidden data structures within the binary program heap memory manager.

[0088] This invention also provides a sign-independent memory manager identification system, comprising: The dynamic data flow tracing module loads the binary executable program to be analyzed into a virtualization framework for execution. It determines the allocatable heap memory space by excluding non-heap memory segments. During execution, it captures instructions in the form of portable operating system interfaces and intercepts function calls in real time. Based on the intercepted function calls, it dynamically reconstructs the call stack sequence and constructs a call stack queue. Upon popping from the stack, it identifies the input parameters and return values ​​of functions in the call stack queue, marks the pointer source of functions whose parameters contain heap memory pointers, and tracks their lifecycle. After the binary executable program finishes execution, it analyzes the creation and destruction process of the traced pointers, generating a memory operation function event flow matrix. Based on the memory operation function event flow matrix, it performs data flow association construction, behavioral similarity analysis, and functional semantic verification, identifying memory allocation and deallocation function pairs to obtain a function pairing mapping table. The forced execution module is used to execute the binary executable program a second time according to the function pairing mapping table. It establishes the initial state and sets up the initial analysis environment by using address hooks and forced execution. In the initial analysis environment, the process state is copied through process duplication. Bytecode sequences are injected into the copied child process to execute a preset memory operation transaction sequence in a directed manner, verifying whether the memory operation behavior meets expectations. For the memory allocation and deallocation function pairs that meet the verification, memory instrumentation is performed to obtain the heap block size and the number of fields. The values ​​of non-load fields are modified at the byte level and verified repeatedly, and the functional semantics of each offset field are identified. The functional semantics and spatial layout information of each offset field are integrated to output the heap memory data structure identification results.

[0089] In summary, the technical solution provided by this invention integrates function-level pointer data flow tracing technology with forced execution technology under specific environments by constructing a two-stage dynamic analysis architecture. During the analysis process, the system achieves efficient verification of memory operation transactions by building a rapidly reconfigurable analysis environment. This invention is designed entirely based on the underlying virtualization architecture, and in specific adaptation and implementation, it can be widely compatible and deployed in various virtualization systems that provide corresponding control flow and memory flow interception interfaces.

[0090] Although the present invention has been disclosed above with reference to embodiments, it is not intended to limit the present invention. Appropriate modifications or equivalent substitutions made by those skilled in the art to the technical solutions of the present invention should be covered within the protection scope of the present invention, which is defined by the claims.

Claims

1. A method for identifying a memory manager without symbolic dependencies, characterized in that, Includes the following steps: The binary executable program to be analyzed is loaded into the virtualization framework and run. The allocatable heap memory space is determined by excluding non-heap memory segments. Capture instructions in the form of portable operating system interfaces during runtime and intercept function calls in real time; Based on the intercepted function calls, the call stack sequence is dynamically restored, and a call stack queue is constructed. When popping from the stack, identify the input parameters and return values ​​of functions in the call stack queue, mark the pointer source of functions whose parameters contain heap memory pointers, and track their lifecycle; After the binary executable program finishes execution, the creation and destruction process of the traced pointers is analyzed to generate a memory operation function event flow matrix; Based on the event flow matrix of memory operation functions, data flow association is constructed, behavior similarity analysis and functional semantic verification are performed to identify memory allocation and release function pairs and obtain a function pairing mapping table; The binary executable program is executed a second time based on the function pairing mapping table. The initial state is established by using address hooks and forced execution, and the initial analysis environment is set up. In the initial analysis environment, the process state is copied by process duplication, and bytecode sequences are injected into the copied child process to execute a preset memory operation transaction sequence in a targeted manner, thereby verifying whether the memory operation behavior meets expectations. For memory allocation and deallocation functions that meet the expectations, memory instrumentation is performed to obtain the heap block size and number of fields. The values ​​of non-load fields are modified at the byte level and the verification is repeated. The functional semantics of each offset field are also identified. Integrate the functional semantics and spatial layout information of each offset field to output the heap memory data structure identification results.

2. The method as described in claim 1, characterized in that, Determining allocatable heap memory space by excluding non-heap memory segments includes: Identify the static loading segment, high-address stack memory segment, and kernel state segment during the execution of a binary executable program; Excluding the static loading segment, the high-address stack memory segment, and the kernel state segment from the runtime space, the remaining virtual memory space is determined as allocatable heap memory space.

3. The method as described in claim 1, characterized in that, Based on the intercepted function calls, the call stack sequence is dynamically reconstructed, and a call stack queue is constructed, including: The current call stack sequence is restored based on the intercepted function calls, and dynamically inserted into the call stack constructor in the form of a singly linked list to establish a call stack queue. When a pop event is detected, a pop signal is sent to subsequent modules using the call stack queue and a callback event is triggered.

4. The method as described in claim 3, characterized in that, Reconstruct the current call stack sequence based on the intercepted function calls, and dynamically insert it into the call stack constructor in the form of a singly linked list, including: The control flow data corresponding to the function call is directed to the call stack reconstruction module through control flow branches; The call stack reconstruction module is used to identify the interface parameters of the portable operating system, and the identification results are fed back to the virtualization layer to perform dynamic analysis framework initialization.

5. The method as described in claim 1, characterized in that, Based on the event flow matrix of memory operation functions, data flow association is constructed, behavioral similarity analysis is performed, and functional semantic verification is conducted to identify memory allocation and deallocation function pairs, including: Based on the event flow matrix of memory operation functions, the life cycle of pointers is traced, and a data flow association is constructed and the degree of association is quantified between the producer function identified as the pointer creator and the consumer function activated by the pointer user. Based on the assumption that the statistical characteristics of the call frequency of paired resource allocation and release operations during the runtime are similar, similarity screening is performed on function pairs with data flow correlation to determine candidate function pairs; Perform semantic function verification on the candidate function pairs and lock the memory allocation and deallocation function pairs.

6. The method as described in claim 5, characterized in that, Perform semantic function verification on the candidate function pairs and lock the memory allocation and deallocation function pairs, including: The candidate function is stimulated by an active interactive probing mechanism. By probing stimuli, the resource allocation semantics of the producer function and the resource release semantics of the consumer function in the candidate function pair are verified, and the locked memory allocation and release function pairs are output.

7. The method as described in claim 1, characterized in that, Inject bytecode sequences into the copied child process to execute a pre-defined sequence of memory operation transactions, including: The allocation operation is executed twice in sequence to obtain the allocation transaction sequence; The allocation, release, and usage operations are executed sequentially to obtain the allocation, release, and usage transaction sequence. The allocation, release, and overflow operations are executed sequentially to obtain the allocation, release, and overflow transaction sequence. The allocation, release, and error address release operations are executed sequentially to obtain the allocation, release, and error address release transaction sequence. The allocation, overflow, use, and release operations are executed sequentially to obtain the allocation, overflow, use, and release transaction sequence. The allocation and two release operations are executed sequentially to obtain the allocation-release-release transaction sequence.

8. The method as described in claim 1, characterized in that, For memory allocation and deallocation functions that meet expectations, memory instrumentation is performed to obtain the heap block size and number of fields. The values ​​of non-load fields are modified at the byte level and verified repeatedly. The functional semantics of each offset field are identified, including: Memory instrumentation is performed during the execution of memory operation transactions to obtain the memory access range corresponding to allocation and deallocation operations. The relative offset of the allocated heap block to the target pointer is determined based on the memory access range, and the number of fields is calculated. The values ​​of non-load fields are modified at the byte level and repeated verification is performed. Heuristic rules are used to identify the functional semantics of each offset field.

9. The method as described in claim 8, characterized in that, Heuristic rules are used to identify the functional semantics of each offset field, including: If log output and assertion exit are triggered after corrupting data and performing memory loading and register comparison, the current offset field is determined to be the overflow value verification check field. If a subsequent pointer dereference exception occurs after data is obtained and corrupted through pointer dereference, the current offset field is determined to be a linked list field. If a program crashes while releasing a physically adjacent subsequent heap block after the field is destroyed and the current heap block is released, then the current offset field is determined to be the heap block size field. If a field is modified on a block in use, the program calls to release the block. If a duplicate release or invalid operation assertion is triggered, the current offset field is determined to be an occupied or free status flag field. The field is destroyed and the current block is freed. If the freeing function crashes immediately due to an illegal memory read, the current offset field is determined to be a pointer to the previous block or an offset field. The field is destroyed and the current block is released. If the program crashes during subsequent unrelated memory allocation or release, the current offset field is determined to be the free list partition index field. The field is destroyed and the current block is released. If the release function reads multiple other metadata, compares them, and triggers an assertion, then the current offset field is determined to be a metadata checksum or a secure cookie field.

10. A sign-independent memory manager identification system, characterized in that, include: The dynamic data flow tracing module loads the binary executable program to be analyzed into a virtualization framework for execution, determines the allocatable heap memory space by excluding non-heap memory segments, captures instructions in the form of portable operating system interfaces during execution, and intercepts function calls in real time. Based on the intercepted function calls, it dynamically reconstructs the call stack sequence and constructs a call stack queue. When popping functions from the stack, it identifies the input parameters and return values ​​of functions in the call stack queue, marks the pointer source of functions whose parameters contain heap memory pointers, and tracks their lifecycle. After the binary executable program finishes execution, it analyzes the creation and destruction process of the traced pointers and generates a memory operation function event flow matrix. Based on the event flow matrix of memory operation functions, data flow association is constructed, behavior similarity analysis and functional semantic verification are performed to identify memory allocation and release function pairs and obtain a function pairing mapping table; The forced execution module is used to execute the binary executable program a second time according to the function pairing mapping table. It establishes the initial state and sets up the initial analysis environment by using address hooks and forced execution. In the initial analysis environment, the process state is copied through process duplication. Bytecode sequences are injected into the copied child process to execute a preset memory operation transaction sequence in a directed manner, verifying whether the memory operation behavior meets expectations. For the memory allocation and deallocation function pairs that meet the verification, memory instrumentation is performed to obtain the heap block size and the number of fields. The values ​​of non-load fields are modified at the byte level and verified repeatedly, and the functional semantics of each offset field are identified. The functional semantics and spatial layout information of each offset field are integrated to output the heap memory data structure identification results.

Images