A method for monitoring dynamic link library loading in C or C++ programs

Abstract

This invention provides a dynamic link library loading monitoring method applicable to C or C++ programs, mainly addressing the problems of high permission requirements, timing delays, incomplete information, and cross-platform inconsistencies in existing debugging channels and Hook / preloading schemes. The solution of this invention involves the control end initiating or injecting the method during testing or monitoring scenarios, taking over the execution flow early in the process. Subsequently, the client initializes and registers module loading callbacks, intercepting the loading at the underlying level and obtaining information such as the base address, path, and timestamp of the newly loaded module, and constructing standardized metadata. If a regular loading is detected, relocation is directly completed and a callback is triggered; if abnormal behavior is detected, a compensatory handling mechanism is used to handle it and mark it as a special event. Finally, after initialization, an event is triggered and written to a buffer or reported to the control end. After symbol resolution and path mapping, metadata in a unified format is output, providing high-quality and reproducible support for coverage and analysis engines.

Description

Technical Field

[0001] This invention belongs to the field of computer security technology, and mainly relates to a method for monitoring the loading of dynamic link libraries in C or C++ programs. Background Technology

[0002] C / C++ programs heavily rely on dynamic link libraries (referred to as "modules") for reuse and on-demand loading, and are widely used in multimedia, graphics, networking, security, and database scenarios. Modules can be implicitly loaded by the loader during startup or explicitly loaded at runtime through plugin mechanisms. Coverage testing and dynamic analysis require accurate acquisition of module file location, name, size, mapping base address and address range, and loading time / order as early as possible. This is used to define coverage boundaries, load debug symbols to complete address-to-source code mapping, and control the start and stop of data collection to reduce overhead. In cross-platform testing, the behavior and path resolution of loaders differ significantly across operating systems. The lack of uniform, fine-grained module data affects result reproducibility and consistency comparison. Existing practices such as static import table analysis cannot cover explicit runtime loading and lack timing information; debugger / system auditing (Windows ETW, Linux audit / ptrace) is complex to deploy, has high permission requirements, and high overhead, with poor integration with application-level coverage components; some coverage tools only provide a coarse-grained module list, lacking real paths, sizes, and strict order, making it difficult to support fine-grained attribution and audit reproducibility. Existing technologies include the following solutions: First, debugger callback paths, such as Windows debugging APIs (DebugActiveProcess, WaitForDebugEvent), Linux's ptrace, and macOS's loading notifications combined with dyld. These solutions can directly obtain module loading events, but typically require high privileges and specific system configurations. The target process being in debug mode can cause significant performance and behavioral disturbances, and stability is easily affected by anti-debugging or sandboxing strategies. Furthermore, the precise timing alignment of events generated and transmitted in the debug channel with in-application symbol loading and coverage boundary updates is not easy; common problems include event lag, missing metadata, or inconsistencies between boundary updates and the actual loading order. Second, pure hook / preloading methods, such as intercepting dlopen / LoadLibrary, modifying IAT, or using LD_PRELOAD. These methods are flexible in deployment and have a low implementation threshold, but are highly sensitive to platform and loader details. It lacks sufficient coverage of implicit loading in the early stages of startup, and is prone to failure when encountering custom loaders, static path resolution, or anti-Hook mechanisms. In multi-threaded and reentrant scenarios, it is prone to race conditions, deadlocks, or reentrancy chaos, requiring extensive engineering hardening to maintain availability, and its cross-platform portability is limited. Summary of the Invention

[0003] To overcome the shortcomings of existing technologies and address the issues of high permission requirements, timing delays, incomplete information, and cross-platform inconsistencies in debugging channels and Hook / preloading schemes, this invention proposes a dynamic link library loading monitoring method suitable for C or C++ programs. This method provides a solution for reliably acquiring the entire lifecycle events of module loading within the process early in the program startup without requiring elevated privileges.

[0004] The technical solution adopted by this invention to solve its technical problem includes the following steps: Step 1: Start the control terminal; Start the control terminal and determine the injection method; the control terminal prepares the runtime environment for the target program and injects the DynamoRIO client into the target program to take over the execution flow of the target program; the control terminal configures the DynamoRIO client parameters; Step 2: The DynamoRIO client takes over the execution flow of the target program; establishes a code cache and execution virtualization environment; the code cache adopts hardware page protection to ensure the consistency between the cache and the real memory, and updates the cache content through write failure monitoring; Step 3: Initialize the DynamoRIO client; The initialization process of the DynamoRIO client is as follows: the registration module loads the callback and configures the symbol resolution and path resolution plugins; at the same time, the DynamoRIO client initializes the event buffer and sets the batch reporting threshold. Step 4: The DynamoRIO client intercepts module mapping or loading calls in the target program's execution flow and monitors the loading process of dynamic link library modules during the mapping, relocation, and initialization phases; Step 5: The DynamoRIO client detects dynamic link library modules, shared object modules, or other types of dynamically loaded modules during the target program's execution. The DynamoRIO client extracts the underlying loading information of the detected loaded dynamic link library modules, shared object modules, or other types of dynamically loaded modules. The DynamoRIO client constructs standardized module metadata based on the underlying loading information. The underlying loading information includes at least one of the following: module path, module name, base address, mapping size, address range, loading time, and loading sequence number. Step 6: Based on the module metadata, if there are any abnormal situations or special loading behaviors, the compensation mechanism is activated to perform corrections, supplementary recordings, delayed confirmations, or special markouts, and the corresponding module events are marked as "Special Loading / Requires Further Review"; if there are no abnormal situations or special loading behaviors, the module events are processed as normal loading events. Step 7: Write the module events to the buffer and report them according to the sequential reporting strategy; Once the target program is initialized, the registered callback is triggered, and module events are written to the memory buffer. The module events are then written to the buffer and reported according to the sequential reporting strategy. Step 8: Based on the module metadata, register the address range of each module to the coverage acquisition component, so that the coverage tool can start or update the acquisition immediately after the module is loaded, ensuring that the coverage boundary is strictly aligned with the actual module loading; at the same time, mark the module events of abnormal conditions or special loading behaviors, and the coverage tool selectively starts or stops the acquisition according to the mark, ensuring that the coverage data is complete and accurate.

[0005] Furthermore, the sequential reporting strategy includes one or more of the following: reporting in the order of actual module loading, batch reporting after reaching the buffer threshold, and periodic reporting after reaching the time threshold.

[0006] Furthermore, the buffer is configured for batch reporting or reporting according to time thresholds.

[0007] Furthermore, the DynamoRIO client parameters include buffer size, reporting method, compensation processing strategy, and log recording level.

[0008] Furthermore, the reporting methods include socket-based and shared memory-based methods.

[0009] Furthermore, the injection methods include early injection, LD_PRELOAD injection, or additional injection.

[0010] Furthermore, the module metadata is organized by recording the module's underlying loading information in the following order: module path, module name, base address, mapping size, address range, loading time, and loading sequence number.

[0011] Furthermore, the method for determining abnormal situations or special loading behaviors is as follows: If any one of the following judgment conditions is met, the situation is determined to be abnormal; The judgment condition is: A. Module path resolution failed; B. Module base address information or mapping size information is missing; C. Duplicate mappings occur within the same module and cannot be directly merged; D. The order in which module events are received is inconsistent with the actual loading order; E-symbol information or path information cannot be obtained immediately when the module is loaded.

[0012] The beneficial effects of this invention are as follows: This invention can seamlessly intervene in the dynamic link library loading process early in the program startup, comprehensively monitoring module loading events of C / C++ user-mode programs throughout their entire runtime. Compared to traditional debugger callbacks or Hook / preloading mechanisms, this method does not require elevated system privileges, does not rely on debug mode or special system configurations, has a simple deployment process, and better compatibility with existing environments. Through low-level binary instrumentation, it can accurately obtain key information such as file path, base address, size, address range, and loading order during the actual mapping and relocation phase of modules, outputting structured and standardized metadata. This data is consistent across major operating systems, facilitating the reproduction and comparison of analysis results across different platforms, effectively solving the problems of coarse data granularity, inconsistent formats, and poor cross-platform consistency in existing solutions. Furthermore, the monitoring process of this invention has minimal impact on the normal execution of the target process, offering advantages such as low overhead and high stability. Its event model naturally interfaces with dynamic analysis tools such as coverage acquisition and symbol loading, greatly improving the accuracy and processing efficiency of analysis tasks while reducing manual intervention and adaptation / maintenance costs. Overall, this invention achieves more efficient, accurate, and user-friendly dynamic link library loading monitoring, providing a reliable data foundation for subsequent testing, analysis, and security detection applications. Attached Figure Description

[0013] Figure 1 This is an overall flowchart of the dynamic link library loading monitoring method applicable to C or C++ programs in this invention. Detailed Implementation

[0014] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0015] A method for monitoring dynamic link library loading in C or C++ programs includes the following steps: Step 1: Start the control terminal; Start the control terminal and determine the injection method; the control terminal prepares the runtime environment for the target program and injects the DynamoRIO client into the target program to take over the execution flow of the target program; the control terminal configures the DynamoRIO client parameters; the DynamoRIO client parameters include buffer size, reporting method, compensation processing strategy and logging level; the reporting methods include socket method and shared memory method; The injection methods include early injection, LD_PRELOAD injection, or additional injection. The preferred approach is to use early injection to take over the execution flow of the target program, thereby overriding the implicit module loading process during the program startup phase. On the Linux platform, the LD_PRELOAD method or the method of attaching to an already running process can also be used, but the method of attaching to an already running process is mainly suitable for runtime explicit loading scenarios. When performing fuzz testing on FreeImage, the control terminal is started first. The control terminal is responsible for preparing the runtime environment for the FreeImage program and injecting the DynamoRIO client. It takes over the execution flow of the FreeImage process through early injection to override the DLL loading at the beginning of the program startup. On the Linux platform, LD_PRELOAD or attaching to an already running process can be used.

[0016] The control end also configures client parameters, such as setting the buffer size to 1 MiB, selecting socket or shared memory as the reporting method, specifying the compensation processing strategy, and setting the logging level to ensure that all module events loaded by FreeImage are fully captured during fuzz testing. Step 2: The DynamoRIO client takes over the execution flow of the target program; establishes a code cache and execution virtualization environment; the code cache adopts hardware page protection to ensure the consistency between the cache and the real memory, and updates the cache content through write failure monitoring; it also supports write failure monitoring to update the cache. Step 3: DynamoRIO Client Initialization and Callback Registration During the initialization phase, the DynamoRIO client registers module loading callbacks and configures symbol resolution and path resolution plugins to obtain complete metadata information when modules are loaded. At the same time, the DynamoRIO client initializes the event buffer and sets the batch reporting threshold to ensure that event order and transmission efficiency are maintained even in high-frequency module loading or multi-threaded scenarios.

[0017] Step 4: The DynamoRIO client intercepts module mapping or loading calls in the target program's execution flow and monitors the loading process of dynamic link library modules during the mapping, relocation, and initialization phases; on the Windows platform, the DynamoRIO client intercepts module mapping as low-level system calls or underlying module loading behavior; Step 5: Module identification and metadata collection; When the DynamoRIO client detects a dynamic link library module, shared object module, or other type of dynamically loaded module that is loaded during the execution of the target program, the DynamoRIO client extracts the underlying loading information of the detected loaded dynamic link library module, shared object module, or other type of dynamically loaded module; the underlying loading information includes at least one of the following: module path, module name, base address, mapping size, address range, loading time, and loading sequence number; The DynamoRIO client constructs standardized module metadata based on the module's underlying loading information; the module metadata facilitates unified management and cross-platform use, while also supporting subsequent symbol resolution and coverage analysis; The module metadata is organized by recording the module's underlying loading information in the following order: module path, module name, base address, mapping size, address range, loading time, and loading sequence number. This ensures that the analysis results under different operating system environments are aligned and processed uniformly.

[0018] The module metadata facilitates unified management, cross-platform comparison, and subsequent symbol resolution and coverage analysis. Step 6: Mapping anomaly detection and compensation processing; Based on the module metadata, if there are any abnormal situations or special loading behaviors, a compensation mechanism will be activated to perform corrections, supplementary recordings, delayed confirmations, or special mark outputs, and the corresponding module events will be marked as "special loading / requires further review"; if there are no abnormal situations or special loading behaviors, the module events will be processed as normal loading events. The method for determining abnormal situations or special loading behaviors is as follows: If any one of the following judgment conditions is met, the situation is determined to be abnormal; The judgment condition is: A. Module path resolution failed; B. Module base address information or mapping size information is missing; C. Duplicate mappings occur within the same module and cannot be directly merged; D. The order in which module events are received is inconsistent with the actual loading order; E-symbol information or path information cannot be obtained immediately when the module is loaded; By compensating for abnormal or special loading behaviors, errors caused by missing or out-of-order module metadata in updating coverage acquisition boundaries can be avoided, thereby improving the reproducibility of analysis results. Step 7: Write the module events to the buffer and report them sequentially; Once the target program is initialized, the registered callback is triggered, and the event is written to the memory buffer. The buffer is configured for batch reporting or reporting according to a time threshold. Events are reported according to the sequential reporting strategy. The sequential reporting strategy includes one or more of the following: reporting in the order of actual module loading, batch reporting after reaching the buffer threshold, and periodic reporting after reaching the time threshold. Step 8: Standardize metadata output and link it with coverage Based on the module metadata, the address range of each module is registered to the coverage acquisition component, enabling the coverage tool to start or update acquisition immediately after the module is loaded, ensuring that the coverage boundary is strictly aligned with the actual module loading. At the same time, module events with abnormal conditions or special loading behaviors are marked, and the coverage tool selectively starts or stops acquisition based on the marks, ensuring that the coverage data is complete and accurate.

[0019] The present invention will be further described in detail below with reference to specific embodiments.

[0020] This embodiment provides a method for monitoring the loading of dynamic link libraries in C or C++ programs, including the following steps: Step 1: Start the control terminal; Start the control terminal and determine the injection method; the control terminal prepares the runtime environment for the target program and injects the DynamoRIO client; the control terminal configures the DynamoRIO client parameters; the DynamoRIO client parameters include buffer size, reporting method, compensation processing strategy, and log recording level; the reporting methods include socket mode and shared memory mode; When performing fuzz testing on FreeImage, the control terminal is started first. The control terminal is responsible for preparing the runtime environment for the FreeImage program and injecting the DynamoRIO client. It takes over the execution flow of the FreeImage process through early injection to override the DLL loading at the beginning of the program startup. On the Linux platform, LD_PRELOAD or attaching to an already running process can be used.

[0021] The control end also configures client parameters, such as setting the buffer size to 1 MiB, selecting socket or shared memory as the reporting method, specifying the compensation processing strategy, and setting the logging level to ensure that all module events loaded by FreeImage are fully captured during fuzz testing. Step 2: The DynamoRIO client takes over the execution flow of the target program; establishes a code cache and execution virtualization environment; the code cache adopts hardware page protection to ensure the consistency between the cache and the real memory, and supports write failure monitoring to update the cache; Step 3: DynamoRIO Client Initialization and Callback Registration During the initialization phase, the DynamoRIO client registers module loading callbacks and configures symbol resolution and path resolution plugins to obtain complete metadata information when modules are loaded. At the same time, the DynamoRIO client initializes the event buffer and sets the batch reporting threshold to ensure that event order and transmission efficiency are maintained even in high-frequency module loading or multi-threaded scenarios.

[0022] Step 4: Intercept underlying mapping / loading calls; On the Windows platform, the DynamoRIO client intercepts low-level system calls or underlying loading behavior of module mappings and monitors the module mapping, relocation, and initialization phases. Step 5: Module identification and metadata collection; Once the DynamoRIO client detects a module mapping, it extracts the target program's module base address, mapping size, path information, load time, and sequence number. Based on this information, the DynamoRIO client constructs standardized module metadata. This metadata facilitates unified management and cross-platform use, while also supporting subsequent symbol resolution and coverage analysis. Step 6: Mapping anomaly detection and compensation processing; Determine whether a module is in a normal loading process based on its metadata.

[0023] When a module path resolution fails, the base address or mapping size information is incomplete, the same module is mapped repeatedly and cannot be directly merged, the order of module event reception is inconsistent with the actual loading order, or the complete symbol information cannot be obtained immediately at the time of module loading, it can be judged as an abnormal or special loading behavior, and a compensation mechanism can be enabled for processing.

[0024] The compensation mechanism includes: Delayed parsing and supplementary recording of module paths; Merge or renumber duplicate mapping records; Reorder module events that have been out of order; Output a special flag for module events that cannot be confirmed temporarily.

[0025] Module events that have undergone compensation processing are marked as "Special Loading / Requires Further Review"; module events that do not fall under the above category are processed as normal loading events.

[0026] Step 7: Write the module events to the buffer and report them sequentially; After the target program is initialized, the registered callback is triggered and the event is written to the memory buffer; the buffer is configured to report in batches or according to time thresholds, wherein the events are reported in sequence. Step 8: Standardize metadata output and link it with coverage Based on the module metadata, the address range of each module is registered to the coverage acquisition component, enabling the coverage tool to start or update acquisition immediately after the module is loaded, ensuring that the coverage boundary is strictly aligned with the actual module loading; at the same time, special or abnormal module events are marked, and the coverage tool selectively starts or stops acquisition based on the markings, ensuring that the coverage data is complete and accurate. The embodiment injects the control terminal into the DynamoRIO client through the above steps, takes over the execution flow in the early stage of the target program startup, and monitors the loading process of dynamic link library modules in the mapping, relocation and initialization stages; further, it extracts metadata such as module base address, mapping size, path information, loading time and loading sequence number, and combines anomaly detection, compensation processing, sequential reporting and coverage boundary linkage to achieve stable, low-overhead and visual monitoring of the target program's dynamic link library loading process.

Claims

1. A method for monitoring the loading of dynamic link libraries in C or C++ programs, characterized in that, Includes the following steps: Step 1: Start the control terminal; Start the control terminal and determine the injection method; the control terminal prepares the runtime environment for the target program and injects the DynamoRIO client into the target program to take over the execution flow of the target program; the control terminal configures the DynamoRIO client parameters; Step 2: The DynamoRIO client takes over the execution flow of the target program; establishes a code cache and execution virtualization environment; the code cache adopts hardware page protection to ensure the consistency between the cache and the real memory, and updates the cache content through write failure monitoring; Step 3: Initialize the DynamoRIO client; The initialization process of the DynamoRIO client is as follows: the registration module loads the callback and configures the symbol resolution and path resolution plugins; at the same time, the DynamoRIO client initializes the event buffer and sets the batch reporting threshold. Step 4: The DynamoRIO client intercepts module mapping or loading calls in the target program's execution flow and monitors the loading process of dynamic link library modules during the mapping, relocation, and initialization phases; Step 5: The DynamoRIO client detects dynamic link library modules, shared object modules, or other types of dynamically loaded modules during the target program's execution. The DynamoRIO client extracts the underlying loading information of the detected loaded dynamic link library modules, shared object modules, or other types of dynamically loaded modules. The DynamoRIO client constructs standardized module metadata based on the underlying loading information. The underlying loading information includes at least one of the following: module path, module name, base address, mapping size, address range, loading time, and loading sequence number. Step 6: Based on the module metadata, if there are any abnormal situations or special loading behaviors, the compensation mechanism is activated to perform corrections, supplementary notes, delayed confirmations, or special mark outputs, and the corresponding module events are marked as "Special Loading / Requires Further Review"; if there are no abnormal situations or special loading behaviors, the module events are processed as normal loading events. Step 7: Write the module events to the buffer and report them according to the sequential reporting strategy; Once the target program is initialized, the registered callback is triggered, and module events are written to the memory buffer. The module events are then written to the buffer and reported according to the sequential reporting strategy. Step 8: Based on the module metadata, register the address range of each module to the coverage acquisition component, so that the coverage tool can start or update the acquisition immediately after the module is loaded, ensuring that the coverage boundary is strictly aligned with the actual module loading; at the same time, mark the module events of abnormal conditions or special loading behaviors, and the coverage tool selectively starts or stops the acquisition according to the mark, ensuring that the coverage data is complete and accurate.

2. The method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The method for determining abnormal situations or special loading behaviors is as follows: If any one of the following judgment conditions is met, the situation is determined to be abnormal; The judgment condition is: A. Module path resolution failed; B. Module base address information or mapping size information is missing; C. Duplicate mappings occur within the same module and cannot be directly merged; D. The order in which module events are received is inconsistent with the actual loading order; E-symbol information or path information cannot be obtained immediately when the module is loaded.

3. The method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The buffer is configured for batch reporting or reporting according to time thresholds.

4. The method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The DynamoRIO client parameters include buffer size, reporting method, compensation processing strategy, and log recording level.

5. A method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The reporting methods include socket method and shared memory method.

6. The method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The injection methods include early injection, LD_PRELOAD injection, or additional injection.

7. A method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The module metadata is organized by recording the module's underlying loading information in the following order: module path, module name, base address, mapping size, address range, loading time, and loading sequence number.

8. The method for monitoring dynamic link library loading in C or C++ programs according to claim 1, characterized in that, The sequential reporting strategy includes one or more of the following: reporting in the order of actual module loading, batch reporting after reaching the buffer threshold, and periodic reporting after reaching the time threshold.

9. A computer-readable storage medium storing a computer program; characterized in that, When a computer program is executed by a processor, it implements a dynamic link library loading monitoring method applicable to C or C++ programs according to any one of claims 1-8.

10. A terminal device, comprising a processor, a memory, and a computer program stored in the memory; characterized in that, When the processor executes a computer program, it implements a dynamic link library loading monitoring method applicable to C or C++ programs as described in any one of claims 1-8.

Images