Program execution path recording method and device

Abstract

The invention provides a method and a device for recording a program execution path. The method comprises the following steps of: recording the program execution path through / proc / lt in a Unix / Linux-like operating system; pidgt, pidgt; the / maps file reads memory mapping information of a running target process in the target program; disassembling the memory mapping information, identifying all function call instructions from the memory mapping information, and obtaining addresses of the function call instructions in a process virtual address space of the Unix / Linux-like operating system; adding a ptrace in the Unix-like / Linux operating system to the target process, and writing a breakpoint instruction in the address of the function call instruction by adopting the ptrace; and when the target process is executed to the breakpoint instruction, triggering a breakpoint event, recording an address corresponding to the breakpoint event, and segmenting the address corresponding to the breakpoint event into different paths based on the key address. The actual execution path of the program can be completely and accurately recorded, and the recording integrity of the program execution path is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer software testing and debugging technology, and in particular to a method for recording program execution paths, a device for recording program execution paths, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] The execution path of a program reflects the control flow under specific inputs and is an important basis for evaluating code coverage, locating performance bottlenecks, reproducing software vulnerabilities, and verifying program behavior. Recording the program's execution path is crucial for applications such as software testing, debugging, performance analysis, fuzzing, and security auditing.

[0003] Currently, one of the main methods for recording program execution paths is to use a debugger (such as the GNU Debugger (GDB)) to set breakpoints and single-step through the code to trace the execution path. Specifically, the user pre-analyzes the target program, identifying function entry points or critical branch points to be traced through source code review or experience, and uses these as breakpoint locations. Then, the user manually sets breakpoints one by one using GDB commands. When the target program starts and reaches any breakpoint, the debugger immediately pauses the entire process and outputs the interrupt information to the console. At this point, the user needs to enter the next command. For example, entering `continue` continues execution until the next breakpoint. Another example is entering `step` or `next` to single-step through the code and simultaneously print context information. By repeating the "execute-interrupt-record-continue" loop, the debugger records fragment information such as the program counter address and stack frame at each interruption. Finally, the user manually integrates this information from the scattered recorded points and combines it with the instruction stream captured during single-step execution to piece together the program execution path.

[0004] Because breakpoint settings rely entirely on the user's prior understanding of the program logic and manual selection, the user cannot predict all potential function call locations in the program. For example, the user cannot predict the call entry point through indirect jumps, function pointers, or runtime resolution. As a result, a large number of function call behaviors that occur during actual execution cannot be captured by preset breakpoints, making the recorded execution path only a subset of the entire program control flow, thus reducing the completeness of the program execution path record. Summary of the Invention

[0005] The purpose of this application is to provide a method for recording program execution paths, a device for recording program execution paths, a computer device, a computer-readable storage medium, and a computer program product, so as to improve the integrity of program execution path recording.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a method for recording the program execution path. This method is applied to a Unix / Linux operating system, where a target program is running. The method includes: recording the execution path via / proc / in the Unix / Linux operating system. <pid>The ` / maps` file reads the memory mapping information of the target process running in the target program; the memory mapping information is disassembled to identify all function call instructions and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system; ptrace from the Unix / Linux operating system is attached to the target process, and breakpoint instructions are written at the addresses of the function call instructions using ptrace; a key address in the main loop of each thread in the target process is obtained, and the key address is used as the boundary between different complete paths; when the target process executes to the breakpoint instruction, the breakpoint event is triggered, the address corresponding to the breakpoint event is recorded, and the address corresponding to the breakpoint event is divided into different paths based on the key address.

[0007] Compared to existing technologies, the method for recording the program execution path provided in the first aspect of this application dynamically reads the target process's / proc / ... <pid>The ` / maps` file obtains real-time memory mapping information, and based on this, code segments are disassembled to accurately identify the addresses of all function call instructions in the process, including those in dynamic libraries. Breakpoints are set at all identified addresses using the `ptrace` system call, eliminating the need for pre-analysis of program logic or manual intervention. This achieves automated capture of all function call nodes during program execution, fundamentally overcoming the limitations of traditional debuggers that rely on manual experience for breakpoint setting and cannot cover indirect calls and dynamically loaded code. It ensures that even in complex multi-threaded environments and dynamically linked scenarios, the actual execution path of the program can be recorded completely and accurately, significantly improving the completeness of the program execution path recording.

[0008] In other embodiments provided in this application, the number of breakpoint events triggered is multiple; obtaining a key address in the main loop of each thread in the target process includes: triggering breakpoint events multiple times and obtaining call stack information when multiple breakpoint events are triggered; searching for the first changed stack frame address from the bottom of the stack in the multiple call stack information; determining the address above the first changed stack frame address as the key address; when the target process executes to the breakpoint instruction, triggering the breakpoint event, recording the address corresponding to the breakpoint event, and dividing the address corresponding to the breakpoint event into different paths based on the key address, including: when the target process executes to the breakpoint instruction, triggering a new breakpoint event, determining whether the address corresponding to the new breakpoint event is the same as the key address; if they are the same, recording the address corresponding to the new breakpoint event and inserting a separator, the separator being used to indicate the end of an execution path; if they are different, recording the address corresponding to the new breakpoint event.

[0009] By analyzing the call stacks triggered by multiple breakpoints, the system automatically locates the critical address of the main loop in the program. This address is then used as a logical boundary to insert separators during subsequent path recording, enabling automatic segmentation and independent recording of execution paths corresponding to different requests in service programs or long-running processes. Without prior knowledge of the target program's source code or processing logic, it intelligently identifies and separates repeatedly executed logical units, effectively solving the problems of mixed paths and difficulty in distinguishing individual processing steps in continuous execution scenarios using traditional path recording methods. This further improves the structured integrity of program execution path recording and the usability of subsequent analysis.

[0010] In other embodiments provided in this application, the number of first changed stack frame addresses is multiple; determining the address above the first changed stack frame address as the key address includes: determining the number of call stack information corresponding to each first changed stack frame address; selecting the address above the first changed stack frame address with the largest number as the key address.

[0011] By statistically analyzing multiple possible first change stack frame addresses and selecting the address with the highest frequency to determine the final critical address, it is possible to effectively filter out accidental stack frame changes caused by program branches, conditional execution, or noisy calls. This ensures that the identified critical address represents the most stable and core repetitive execution logic of the program, thereby making subsequent path cutting based on this address more accurate and reliable. This further improves the adaptability and stability of the automated path recording method under different program behaviors and inputs.

[0012] In other embodiments provided in this application, the target process includes multiple threads; the method further includes: obtaining the identifier (ID) of the thread corresponding to the multiple breakpoint events, so as to find the address of the first changed stack frame starting from the bottom of the stack in the call stack information corresponding to the same ID, and obtain the correspondence between different thread IDs and their corresponding key addresses; obtaining the thread ID corresponding to the new breakpoint event, and determining the key address corresponding to the thread ID corresponding to the new breakpoint event from the correspondence; determining whether the address corresponding to the new breakpoint event is the same as the key address, including: determining whether the address corresponding to the new breakpoint event is the same as the key address determined from the correspondence.

[0013] By establishing and maintaining the corresponding key addresses for each thread based on its thread ID, independent and accurate recording of the execution path of each thread in a multi-threaded environment is achieved. This effectively distinguishes and processes the control flow loops of different threads, ensuring that the path recording logic of each thread is clear and does not interfere with each other. This allows for the complete capture of the actual execution trajectory of each thread in a concurrent program, significantly enhancing the applicability and recording accuracy in complex multi-threaded scenarios.

[0014] In other embodiments provided in this application, disassembling memory mapping information includes: extracting code segments with executable permissions from the memory mapping information; and disassembling the code segments.

[0015] By precisely filtering the code segments with executable permissions in the memory mapping information for disassembly, interference from non-instruction memory areas such as data segments and read-only segments is effectively eliminated, greatly improving the accuracy and processing efficiency of function call instruction identification, thus laying a solid foundation for efficient and reliable recording of program execution paths in the future.

[0016] In other embodiments provided in this application, before disassembling the code segment, the method further includes: excluding code in the code segment that matches the code features of a target dynamic library that is not of interest, to obtain a target code segment, wherein the target dynamic library includes a basic runtime library, a system service library, and a dynamic linker component; and / or, extracting the code segment corresponding to the list of libraries of interest from the code segment to obtain a target code segment; and disassembling the code segment, including: disassembling the target code segment.

[0017] By filtering code segments before disassembly, excluding irrelevant system libraries or focusing only on target libraries of interest, the range of instructions requiring analysis and breakpoint setting is significantly reduced. This greatly reduces the runtime overhead of the path recording tool itself and avoids generating a large number of irrelevant records on common, high-frequency system function calls. Thus, while ensuring that the core business logic path is completely captured, the performance and efficiency of the overall recording process are effectively improved.

[0018] A second aspect of this application provides a device for recording program execution paths. The device is applied to a Unix / Linux operating system, in which a target program runs. The device includes a memory mapping acquisition module for accessing the / proc / directory within the Unix / Linux operating system. <pid>The ` / maps` file reads the memory mapping information of the target process running in the target program; the identification module disassembles the memory mapping information to identify all function call instructions and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system; the breakpoint setting module attaches ptrace from the Unix / Linux operating system to the target process and uses ptrace to write breakpoint instructions at the addresses of function call instructions; the critical address acquisition module obtains a critical address in the main loop of each thread in the target process, and the critical address is used as the boundary between different complete paths; the recording module triggers breakpoint events when the target process executes to the breakpoint instruction, records the address corresponding to the breakpoint event, and divides the address corresponding to the breakpoint event into different paths based on the critical address.

[0019] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of the first aspect.

[0020] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of the first aspect.

[0021] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of the first aspect.

[0022] The program execution path recording device provided in the second aspect of this application, the computer device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect have the same or similar beneficial effects as the program execution path recording method provided in the first aspect. Attached Figure Description

[0023] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 This is a schematic diagram illustrating an application scenario of the method for recording the program execution path in this application embodiment; Figure 2 This is a flowchart illustrating the method for recording the program execution path in an embodiment of this application. Figure 1 ; Figure 3 This is a flowchart illustrating the method for recording the program execution path in an embodiment of this application. Figure 2 ; Figure 4 This is a schematic diagram illustrating the contents of the maps file corresponding to a process in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the service program in the embodiments of this application. Figure 1 ; Figure 6 This is a schematic diagram of the structure of the service program in the embodiments of this application. Figure 2 ; Figure 7 This is a schematic diagram of the structure of the recording device for the program execution path in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the computer device in the embodiments of this application. Detailed Implementation

[0024] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0025] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0026] Currently, recording the execution path of a program relies on manually preset breakpoints, which cannot fully capture all potential function calls during program execution (especially indirect calls and dynamically loaded code), resulting in incomplete recording of the execution path.

[0027] The root cause is that existing methods cannot dynamically and automatically identify the exact location of all function call instructions (including calls in dynamically loaded libraries) during program runtime, resulting in inherent blind spots in breakpoint settings, relying on manual prediction and incomplete coverage.

[0028] In view of this, embodiments of this application provide a method for recording program execution paths, a device for recording program execution paths, a computer device, a computer-readable storage medium, and a computer program product, which dynamically reads and analyzes the real-time memory mapping information ( / proc / ) of a target process. <pid>The ` / maps` file automatically disassembles all executable code segments, accurately identifying the actual address of every function call instruction in the process, including calls from dynamically loaded libraries. Then, using the ptrace mechanism, breakpoints are set at these addresses to automatically capture and record all function calls during program execution. In this way, without relying on any manual presets or source code knowledge, the entire execution path of the program in a real-world environment can be completely and accurately reconstructed.

[0029] It should be noted that all components, data, and related processing methods involved in this application are authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0030] First, the application scenarios of the method for recording the program execution path provided in the embodiments of this application will be explained.

[0031] Figure 1 This is a schematic diagram illustrating an application scenario of the method for recording the program execution path in this application embodiment. See [link / reference] Figure 1 As shown, this scenario can include: a Unix / Linux operating system.

[0032] The Unix / Linux operating system mentioned here provides core mechanisms such as the / proc virtual file system and the ptrace system call, enabling external tools to dynamically explore and manipulate the address space and execution flow of processes without modifying the target program's source code. Examples include: Ubuntu, CentOS / RHEL, Debian, Fedora, openSUSE, embedded Linux systems, Android, FreeBSD, OpenBSD, NetBSD, macOS, iOS, Solaris, AIX, HP-UX, and so on.

[0033] In a Unix / Linux operating system, the target program is included.

[0034] Target program 111 refers to an executable software entity that needs to run in a Unix / Linux operating system environment, and whose execution path needs to be recorded and analyzed non-intrusively and automatically. It includes various forms, ranging from simple command-line tools to complex, long-running server applications. Examples include: industrial control software (such as PLC runtime environments), network service processes (such as Nginx, MySQL, and SSH daemons), security testing objects (such as custom protocol parsers), and so on.

[0035] The number of target programs 111 can be one or more.

[0036] In actual operation, the Unix / Linux operating system provides a basic operating environment and monitoring interface ( / proc file system and ptrace). The target program is a static executable file to be analyzed in this environment, while the target process is a dynamic instance of the program at runtime.

[0037] Next, the method for recording the program execution path provided in the embodiments of this application will be described in detail.

[0038] Figure 2 This is a flowchart illustrating the method for recording the program execution path in an embodiment of this application. Figure 1 See Figure 2 As shown, the method may include: S21: Via / proc / in Unix / Linux operating systems <pid>The / maps file reads memory mapping information of the target process running in the target program.

[0039] / proc / <pid>The ` / maps` file is a virtual interface provided by the Unix / Linux operating system kernel, reflecting the complete virtual memory layout of a specified process in real time. Here, ` / proc / ` <pid>The core function of the / maps file is to serve as the entry point for dynamic exploration. By reading this file, path recording tools can accurately obtain the actual start and end addresses and permission attributes of all loaded code segments (including the main program and dynamic libraries) in memory in the target process without relying on any pre-compiled information or symbol tables. This provides a unique, accurate, and real-time address basis for subsequent disassembly of all executable code, identification of function call instructions, and setting breakpoints. It is the foundation for achieving source code-free, fully dynamic path recording.

[0040] Path logging tools query the / proc / directory generated in real time by the operating system kernel for the target process. <pid>The virtual file / maps obtains a complete snapshot of the current virtual address space layout of the process, i.e., memory mapping information.

[0041] The memory mapping information includes not only the executable code segments loaded from the target program and all its dependent dynamic libraries (.so files), but also the locations and permissions of areas such as the data segment, heap, stack, and memory-mapped files. It can dynamically and accurately locate the memory range of all CPU-executable machine instructions within a process, thus laying the foundation for subsequent fully automated instruction-level analysis and breakpoint setting.

[0042] This process occurs entirely at runtime, without any compile-time coordination with the target program.

[0043] S22: Disassemble the memory mapping information to identify all function call instructions and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system.

[0044] During disassembly, a disassembly engine (such as Capstone, Udis86, etc.) is used to sequentially read the original machine instruction byte stream of memory mapping information and parse it into assembly instructions one by one.

[0045] When identifying function call instructions, pattern matching is performed on each generated assembly instruction. Based on the instruction set specifications of different Central Processing Unit (CPU) architectures (such as CALL for x86 / x86-64, BL / BLX for Advanced RISC Machines (ARM), and JAL / JALR for Microprocessors without Interlocked Pipeline Stages (MIPS), all instructions whose opcodes belong to the function call type are filtered out. This process is typically accomplished through the disassembler engine's Application Programming Interface (API) or predefined instruction type classifications, ensuring that no direct calls, indirect calls (via register or memory addressing), or other forms are missed. This process can obtain the addresses of all function call instructions.

[0046] S23: Attach ptrace from a Unix / Linux operating system to the target process and use ptrace to write breakpoint instructions at the address of function call instructions.

[0047] Specifically, the path recording tool first attaches itself to the target process as a tracer using the PTRACE_ATTACH command, thereby gaining control over its execution flow. Then, for each calculated function call instruction address, it sequentially uses PTRACE_PEEKTEXT to read the original instruction, saves its original machine code, and then uses PTRACE_POKETEXT to write a software breakpoint instruction to that address (such as writing the INT 3 opcode 0xCC on the x86 architecture).

[0048] This process implants dense monitoring points in the process's code space, causing the target process to pause when it reaches any function call location due to the triggering of breakpoints, thus providing a precise triggering time for path recording tools to capture the execution flow.

[0049] S24: Obtain a key address from the main loop of each thread in the target process. The key address is used as the boundary between different complete paths.

[0050] Each thread refers to one or more concurrently executing threads within the target process. Each thread has its own independent thread ID, register state, and call stack, but shares the process's address space and resources.

[0051] The main loop refers to a loop structure in a service program or long-running program that continuously runs, waits for and processes requests. It is usually located in the thread entry function or scheduling logic and is the logical core of the program's repeated execution.

[0052] A critical address is a representative instruction address (usually the address of a function call instruction) inside the main loop. This address is repeatedly executed during program execution and can be used as a logical marker.

[0053] Different complete paths refer to independent execution trajectories corresponding to a single request, transaction, or business process. They consist of a series of instruction addresses recorded in chronological order, reflecting the control flow from the start of processing to its completion.

[0054] Boundaries are logical markers or separators used to separate different complete paths in a recorded execution path sequence. They are usually achieved by identifying key addresses and inserting special markers.

[0055] When obtaining critical addresses, a statistical location method based on call stack analysis can be used. Specifically, in the early stages of program execution, breakpoints are set and triggered multiple times to capture and save the complete call stack information at each trigger, along with the corresponding thread ID. For multiple call stacks corresponding to the same thread ID, the return address is compared layer by layer upwards from the bottom of the stack (usually the main function) to locate the first changed stack frame address. The address of the layer above the first changed stack frame is used as a candidate critical address. A mapping table between each thread ID and its critical address is established for use in subsequent path recording stages.

[0056] S25: When the target process executes to the breakpoint instruction, a breakpoint event is triggered, the address corresponding to the breakpoint event is recorded, and the address corresponding to the breakpoint event is divided into different paths based on the key address.

[0057] In other words, when the target process executes to the address that has been replaced by a breakpoint instruction, the CPU generates a debug exception, which is caught by the kernel. The path logging tool, acting as the tracer, becomes aware of this breakpoint event. Then, the tool uses PTRACE_GETREGS to obtain the current thread's register state, thereby accurately reading the address that triggered the breakpoint (i.e., the value of the program counter PC / EIP / RIP). This address is immediately logged to the path log file associated with that thread, becoming a node in the program execution path.

[0058] When the address corresponding to the breakpoint event is the same as the key address, a path separator is inserted when the address is recorded, thereby dividing the recorded address sequence into several independent execution path segments. When the address corresponding to the breakpoint event is different from the key address, the address is directly recorded as a node in the current execution path segment.

[0059] Afterward, the tool needs to restore the instruction at the address to its original machine code using PTRACE_POKETEXT, and then single-step through the instruction (PTRACE_SINGLESTEP). Once the instruction completes, it writes back the breakpoint instruction to ensure that the program continues to execute and that the location can still be captured by subsequent calls. This "pause-record-resume-continue" loop achieves complete tracking of the execution flow.

[0060] A complete execution path is obtained by concatenating the addresses corresponding to all recorded breakpoint events in chronological order.

[0061] As can be seen from the above, the method for recording the program execution path provided in this application embodiment dynamically reads the target process's / proc / ... <pid>The ` / maps` file obtains real-time memory mapping information, and based on this, code segments are disassembled to accurately identify the addresses of all function call instructions in the process, including those in dynamic libraries. Breakpoints are set at all identified addresses using the `ptrace` system call, eliminating the need for pre-analysis of program logic or manual intervention. This achieves automated capture of all function call nodes during program execution, fundamentally overcoming the limitations of traditional debuggers that rely on manual experience for breakpoint setting and cannot cover indirect calls and dynamically loaded code. It ensures that even in complex multi-threaded environments and dynamically linked scenarios, the actual execution path of the program can be recorded completely and accurately, significantly improving the completeness of the program execution path recording.

[0062] Furthermore, as a response to Figure 2 In a refinement and extension of the method shown, this application embodiment also provides a method for recording program execution paths.

[0063] Figure 3 This is a flowchart illustrating the method for recording the program execution path in an embodiment of this application. Figure 2 See Figure 3 As shown, the method may include: S31: Via / proc / in Unix / Linux operating systems <pid>The / maps file reads memory mapping information of the target process running in the target program.

[0064] In order to accurately focus the analysis on the machine instruction area that the CPU actually executes, disassembling the code segment with executable permissions can effectively eliminate interference from non-instruction memory such as data segments, and can significantly improve the accuracy and processing efficiency of function call instruction identification.

[0065] S32: Extract the code segment with executable permissions from the memory mapping information.

[0066] An executable code segment is a memory region marked as "executable (x)" in the process memory mapping. These regions typically contain machine instructions loaded by the operating system that the CPU can directly execute (such as the .text segment of the main program and the code segment of dynamic libraries).

[0067] During the extraction process, the description information of each memory mapping is parsed line by line, and lines containing the character 'x' in the permission field are selected. Then, the start and end addresses (in hexadecimal) of the memory region are extracted from these lines, thereby determining all executable memory ranges, i.e., code segments, that need to be analyzed.

[0068] S33: Disassemble the code segment.

[0069] The specific method for disassembling the code segment is the same as the specific method for disassembling the memory mapping information in step S22 of the aforementioned embodiment. Please refer to the relevant descriptions in the aforementioned embodiments, which will not be repeated here.

[0070] When recording service-oriented or library-dependent programs, there is a problem that calls to general system libraries (such as libc) can generate a large number of interfering path records. In order to concentrate recording resources on core business logic and improve analysis efficiency, the disassembly scope can be narrowed by filtering non-target dynamic libraries or extracting only the code segments corresponding to the libraries of interest, so as to achieve targeted capture of key execution paths.

[0071] Specifically, prior to step S33 above, the method may further include: S330: Exclude code segments in the code segment that match the code characteristics of the target dynamic library that is not of interest, to obtain the target code segment, wherein the target dynamic library includes the basic runtime library, system service library and dynamic linker component; and / or, extract the code segment corresponding to the list of libraries of interest from the code segment to obtain the target code segment.

[0072] The basic runtime library is a dynamic library that provides programs with the most basic and general-purpose language-level runtime support and services (such as memory management, string manipulation, mathematical functions, etc.). Examples include libc.so and libstdc++.so.

[0073] System service libraries are shared libraries that provide interfaces for programs to access core operating system services (such as processes, threads, network, and file systems). Examples include libpthread.so and libdl.so.

[0074] The dynamic linker component is a core system component responsible for loading, linking, and relocating other dynamic libraries during program startup and runtime. Examples include ld-linux.so and ld.so.

[0075] The code characteristics of a target dynamic library are mainly reflected in its file paths and naming patterns. Basic runtime libraries and system service libraries are typically located in system library directories (such as / lib, / usr / lib) and follow specific naming conventions (such as libc.so*, libpthread.so*). Dynamic linker components, on the other hand, have explicit, fixed names (such as ld-linux.so*).

[0076] The code feature matching here does not involve analyzing the instruction content, but rather refers to parsing / proc / <pid>The memory mapping path information in the / maps file is used to identify executable memory regions mapped from these specific library files using string matching or regular expressions, and then exclude them from the set of target code segments to be analyzed.

[0077] An interest library list is a collection of dynamic library names or paths that are user-defined or preset by the tool to meet specific analysis needs. For example, when performing a security audit on industrial control software, the interest library list may include the software's custom core component libraries (such as libics_protocol.so and libplc_runtime.so).

[0078] After obtaining the executable code segment, each mapped path (e.g., / usr / lib / libxxx.so) is matched against a predefined list of interest libraries (e.g., by exact string matching or containment matching). Only the code segments whose mapped paths match successfully (i.e., code segments from the dynamic libraries listed in the interest library list) are retained, and their start and end addresses, etc., are reassembled into the target code segment.

[0079] In practical applications, after obtaining the code segments, an exclusion strategy can be applied first to exclude code segments that match the characteristics of irrelevant target dynamic libraries (such as the libc basic runtime library) to filter out general noise. Then, an inclusion strategy is applied to extract only code segments that match the list of libraries of interest from the remaining code segments, thus obtaining the final highly focused target code segments. In this way, the advantages of both exclusion and inclusion strategies can be utilized simultaneously to efficiently remove a large number of known general system library interferences first, and then accurately lock onto a few core business libraries, thereby achieving optimal filtering efficiency and resource utilization while ensuring a high degree of focus on the records.

[0080] Accordingly, step S33 above may include: disassembling the target code segment.

[0081] The specific method for disassembling the target code segment is the same as the specific method for disassembling the memory mapping information in step S22 of the aforementioned embodiment. Please refer to the relevant descriptions in the aforementioned embodiments, which will not be repeated here.

[0082] S34: Identify all function call instructions from the disassembled code and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system.

[0083] S35: Attach ptrace from a Unix / Linux operating system to the target process and use ptrace to write breakpoint instructions at the address of function call instructions.

[0084] Figure 4 This is a schematic diagram illustrating the contents of the maps file corresponding to a process in an embodiment of this application. See also... Figure 4 As shown, by reading / proc / <pid>The ` / maps` file is used to obtain the complete virtual memory layout of the target process. This file lists all loaded memory regions, where lines marked with `r-xp` permissions (readable, executable, and private) represent executable code segments, including the main program (address range 00400000-00401000 in the first line of the image) and all dynamic libraries (7ffff7a00000-7ffff7bcc000 in libc-2.31.so, etc.). By parsing these lines, the start and end addresses of each code segment are extracted. Next, the raw machine code within these address ranges is read sequentially, and the disassembler engine is used to identify the addresses of all function call instructions (such as `call`). Finally, these addresses are used to write breakpoint instructions (such as `int 3`) via `ptrace`, thereby completing the monitoring and deployment of all function call points throughout the entire process, laying the foundation for subsequent execution path capture.

[0085] When recording the execution path of service-oriented or long-running programs, there is a problem where the recorded address sequence extends indefinitely due to continuous program execution, making it impossible to distinguish the independent paths corresponding to different requests or transactions. To segment the continuous execution flow into independent path segments with clear semantics, the call stacks of multiple breakpoints can be captured in the initial stage. By analyzing the stack frame change patterns, the key addresses that are repeatedly executed in the program can be automatically located. Subsequently, when formally recording the path, a separator is inserted whenever the address is encountered again. In this way, the address sequence between adjacent separators naturally corresponds to a complete business process, thereby achieving intelligent and automated segmentation of continuous execution paths.

[0086] To capture the call stacks of multiple breakpoints, the breakpoint events can be triggered multiple times. That is, during path recording, the target process will repeatedly pause execution due to encountering numerous pre-set function call breakpoints.

[0087] S36: Trigger breakpoint events multiple times and obtain call stack information when multiple breakpoint events are triggered; search for the first changed stack frame address starting from the bottom of the stack in the multiple call stack information; determine the address above the first changed stack frame address as the critical address.

[0088] The call stack information refers to the sequence of all function call frames traversed from the current execution point (top of the stack) back to the program entry point (bottom of the stack) when program execution is paused due to a breakpoint.

[0089] The stack frame address refers to the location of the return address (i.e., the address of the instruction following the function call instruction) in the process's virtual address space within each call frame.

[0090] By analyzing the stack frame address sequence of the call stack at different breakpoints, stable and repetitive execution structures (such as the main loop) in the program can be identified, thus providing a key structured basis for automatically segmenting continuous execution paths and locating logical boundaries.

[0091] During the initial analysis phase, the path recording tool collects and stores the complete call stacks corresponding to a series of breakpoint events triggered when the program processes different requests or inputs. Then, the tool compares these stacks pairwise. Starting from the bottom layer of each stack (usually the main function), it compares the return addresses of the corresponding stack frames layer by layer upwards. When a discrepancy is first found between different stacks in the return address of a certain layer, the address of the first changed stack frame is located. The address of the layer above this (i.e., the return address of its caller) is then identified as a candidate critical address.

[0092] Figure 5 This is a schematic diagram of the structure of the service program in the embodiments of this application. Figure 1 See Figure 5 As shown, after the program starts, it enters a main loop that waits for requests. When a request arrives, the corresponding processing function (such as func1 or func3) will be executed. After processing, the program returns to the main loop.

[0093] Figure 6 This is a schematic diagram of the structure of the service program in the embodiments of this application. Figure 2 See Figure 6 As shown, a single request may call func1 and func3 sequentially. If we select any two sufficiently far positions in the main loop (such as positions 3 and 4), the execution path between them must encompass the entire request processing flow. Therefore, the goal is to find a representative address (i.e., milestone_addr) in the main loop.

[0094] Positions 3 and 4 above must be any two distinct execution points within the main loop, and the logical distance between them must be large enough to ensure that there is at least one complete request processing process from leaving to returning to the main loop.

[0095] For example, suppose we capture the call stacks of two requests by triggering breakpoints multiple times. The first stack is [main, execute_loop@addr_A, func1, ...], and the second stack is [main, execute_loop@addr_B, func3, ...]. Starting from the bottom of the stack (main), the first stack frame address that changes is the two different addresses addr_A and addr_B inside the execute_loop function. These two addresses are identical at the next higher level in the call stack (i.e., the return address of the execute_loop call in the main function). This identical address can be identified as the milestone address.

[0096] In some cases, during the call stack analysis phase, different branches or conditional paths in program execution can lead to multiple different "first changing stack frame addresses" within the same function, which can introduce ambiguity in determining critical addresses. To select the most stable and representative address from these candidate addresses and ensure the accuracy of subsequent path segmentation, each candidate address (i.e., the address of the first changing stack frame) can be statistically analyzed, calculating its frequency of occurrence across the entire collected call stack sample. Ultimately, the address one level above the candidate address with the highest frequency is determined as the final critical address. This approach, based on statistical regularity, selects the most frequently traversed path point during program execution, thereby improving the robustness of critical address identification.

[0097] Specifically, step S36 above may include: S361: Determine the number of call stack information corresponding to the first stack frame address that changes.

[0098] S362: Select the address above the first stack frame address that has changed the most times as the critical address.

[0099] After collecting all call stacks during the analysis phase, the first step is to identify the "first changed stack frame address" for each stack. Next, an address-to-count mapping table is created, and all stacks are traversed, incrementing the count whenever an address is identified as the "first changed address." After all stacks have been processed, the address with the largest count in this mapping table is found. Finally, the address of the next higher stack frame (i.e., the one closer to the bottom of the stack) within the call stack containing that address is taken, and this higher-level address is formally designated as the critical address.

[0100] For example, suppose the analysis phase collects 10 call stacks. Seven of these stacks have a first change address of 0x400500, and the other three have a first change address of 0x400520. After counting, 0x400500, which appears seven times, is selected. Then, the address immediately following the bottom of the stack (e.g., 0x400800) is extracted from the stack containing 0x400500. 0x400800 is then identified as the critical address.

[0101] In other cases, within a multi-threaded target process, each thread typically has its own independent execution flow and main loop. Using the same critical address for all threads can lead to chaotic path recording logic and an inability to correctly segment the independent execution paths of each thread. Therefore, during the analysis phase, collecting and analyzing call stacks grouped by thread ID, and independently determining the critical address for each thread, ensures that in a multi-threaded concurrent environment, the execution path of each thread can be independently and accurately segmented and recorded. This allows for the complete capture of the complex execution trajectory of concurrent programs, significantly improving applicability and recording accuracy in multi-threaded scenarios.

[0102] Specifically, the method may also include: S36a: Obtain the identifier ID of the thread corresponding to multiple breakpoint events, and search for the first changed stack frame address from the bottom of the stack in the call stack information corresponding to the same ID, so as to obtain the correspondence between different thread IDs and their corresponding key addresses.

[0103] In other words, during the initial analysis phase, whenever the target process pauses due to a breakpoint, the specific thread ID (TID) that triggered the breakpoint is first obtained via ptrace or the operating system interface. Then, the complete call stack information at that moment is obtained and stored in a separate container with the thread ID as the key (e.g., maintaining a separate stack list for each thread ID). After collecting sufficient samples, for each thread ID's corresponding stack set, the "find the first changed address from the bottom of the stack" process and subsequent statistical and selection logic are executed independently. Finally, a mapping table is generated, with entries for "thread ID -> the thread's unique key address".

[0104] S37: When the target process executes to the breakpoint instruction, a new breakpoint event is triggered. It is determined whether the address corresponding to the new breakpoint event is the same as the critical address. If they are the same, the address corresponding to the new breakpoint event is recorded and a separator is inserted. The separator is used to indicate the end of an execution path. If they are different, the address corresponding to the new breakpoint event is recorded.

[0105] A new breakpoint event refers to a breakpoint event triggered during the path recording phase (i.e., the `get_process_execute_path` phase). This differs from breakpoint events triggered during the analysis phase (i.e., the `get_main_loop_addr` phase) to collect call stack information. The "new" aspect doesn't refer to the nature of the event itself, but rather to the different processing stage and purpose. During the path recording phase, the core purpose of triggering a breakpoint event is no longer analyzing the stack to find critical addresses, but rather recording addresses to construct the execution path. In this process, it determines whether to insert a path separator based on whether the current address equals the determined critical address (`milestone_addr`).

[0106] For example, after determining the critical address to be 0x00000000004054d7, the system enters the path recording phase. Assume the target process continues running and triggers a new breakpoint event with a corresponding address of 0x00007ffff7146c17 (e.g., located in func2). Since this address is different from the critical address, the system only records it in the path log. Subsequently, when program execution returns to the main loop and triggers the breakpoint again, its address is exactly 0x00000000004054d7, the same as the critical address. At this time, the system not only records this address but also inserts a separator (such as a blank line or a special marker "---") into the log. This separator marks all records from the previous separator (or the start of the log) to the current address, constituting the execution path of a complete request processing.

[0107] Corresponding to step S36a above, step S37 may further include: S37a: Obtain the thread ID corresponding to the new breakpoint event, and determine the key address corresponding to the thread ID of the new breakpoint event from the correspondence.

[0108] S37b: Determine whether the address corresponding to the new breakpoint event is the same as the key address determined from the correspondence.

[0109] For example, suppose a thread with thread ID 12345 triggers a new breakpoint event. First, obtain the current thread ID 12345. Then, query the "thread ID-key address" mapping table established during the analysis phase to find the key address corresponding to this thread (let's say 0x400800). Next, read the address corresponding to the current breakpoint event (let's say 0x7fffe0001234). Finally, compare the current address 0x7fffe0001234 with the thread-specific key address 0x400800 found in the mapping table. Since they are different, only the path from address 0x7fffe0001234 to thread 12345 is recorded in the log, without inserting a separator.

[0110] This concludes the explanation of the method for recording the program execution path provided in the embodiments of this application.

[0111] Based on the same inventive concept, embodiments of this application also provide a device for recording program execution paths.

[0112] The program execution path recording device is used in Unix-like / Linux operating systems, where the target program runs.

[0113] Figure 7 This is a schematic diagram of the structure of the recording device for the program execution path in an embodiment of this application. See also... Figure 7 As shown, the device may include: Memory mapping acquisition module 71 is used to obtain memory maps via / proc / in Unix / Linux operating systems. <pid>The / maps file reads memory mapping information of the target process running in the target program.

[0114] The identification module 72 is used to disassemble the memory mapping information, identify all function call instructions, and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system.

[0115] The breakpoint setting module 73 is used to attach ptrace from a Unix / Linux operating system to the target process and use ptrace to write breakpoint instructions at the address of function call instructions.

[0116] The key address acquisition module 74 is used to acquire a key address in the main loop of each thread in the target process, and the key address is used as the boundary between different complete paths.

[0117] The recording module 75 is used to trigger a breakpoint event when the target process executes to the breakpoint instruction, record the address corresponding to the breakpoint event, and divide the address corresponding to the breakpoint event into different paths based on the key address.

[0118] Furthermore, as a response to Figure 7 In a refinement and extension of the illustrated device, embodiments of this application also provide a device for recording program execution paths. This device may include: Memory mapping acquisition module 71 is used to obtain memory maps via / proc / in Unix / Linux operating systems. <pid>The / maps file reads memory mapping information of the target process running in the target program.

[0119] The identification module 72 is used to disassemble the memory mapping information, identify all function call instructions, and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system.

[0120] The identification module 72 is specifically used to extract code segments with executable permissions from memory mapping information and to disassemble the code segments.

[0121] The identification module 72 is specifically used to exclude code segments that match the code features of target dynamic libraries that are not of interest, thereby obtaining target code segments, wherein target dynamic libraries include basic runtime libraries, system service libraries, and dynamic linker components; and / or, to extract code segments corresponding to the list of libraries of interest from the code segments, thereby obtaining target code segments; and to disassemble the target code segments.

[0122] The breakpoint setting module 73 is used to attach ptrace from a Unix / Linux operating system to the target process and use ptrace to write breakpoint instructions at the address of function call instructions.

[0123] When the breakpoint event is triggered multiple times, the critical address acquisition module 74 is used to obtain the call stack information when the breakpoint event is triggered multiple times; in the multiple call stack information, the first stack frame address that changes is found from the bottom of the stack; and the address above the first stack frame address that changes is determined as the critical address.

[0124] When there are multiple instances of the first changed stack frame address, the key address acquisition module 74 is specifically used to determine the number of call stack information corresponding to each first changed stack frame address; and selects the address above the first changed stack frame address with the largest number of instances as the key address.

[0125] The recording module 75 is used to trigger a new breakpoint event when the target process executes to the breakpoint instruction, and to determine whether the address corresponding to the new breakpoint event is the same as the key address; if they are the same, the address corresponding to the new breakpoint event is recorded and a separator is inserted, which is used to indicate the end of an execution path; if they are different, the address corresponding to the new breakpoint event is recorded.

[0126] When the target process includes multiple threads, the memory mapping acquisition module 71 is also used to acquire the identifier ID of the thread corresponding to the multiple breakpoint events, so as to find the address of the first changed stack frame starting from the bottom of the stack in the call stack information corresponding to the same ID, and obtain the correspondence between different thread IDs and their corresponding key addresses. The recording module 75 is specifically used to obtain the thread ID corresponding to the new breakpoint event, and determine the key address corresponding to the thread ID of the new breakpoint event from the correspondence; and to determine whether the address corresponding to the new breakpoint event is the same as the key address determined from the correspondence.

[0127] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0128] Based on the same inventive concept, this application also provides a computer device.

[0129] Figure 8 This is a schematic diagram of the structure of the computer device in an embodiment of this application. See also... Figure 8 As shown, the computer device may include: a memory 81, a processor 82, and a computer program stored on the memory 81, wherein the processor 82 executes the computer program to implement the methods described in the foregoing embodiments.

[0130] It should be noted that the description of the above computer device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0131] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the methods described in the foregoing embodiments.

[0132] It should be noted that the description of the above computer-readable storage medium embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0133] Based on the same inventive concept, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described in the foregoing embodiments.

[0134] It should be noted that the descriptions of the above computer program product embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the computer program product embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid>

Claims

1. A method for recording program execution paths, characterized in that, The method is applied to a Unix / Linux operating system, in which a target program runs. The method includes: Through / proc / in the aforementioned Unix / Linux operating system <pid> The / maps file reads the memory mapping information of the target process running in the target program;< / pid> The memory mapping information is disassembled to identify all function call instructions and obtain the addresses of the function call instructions in the process virtual address space of the Unix / Linux operating system. The ptrace tool from the Unix / Linux operating system is attached to the target process, and breakpoint instructions are written using the address in the function call instruction from the ptrace tool. Obtain a key address from the main loop of each thread in the target process; the key address is used as the boundary between different complete paths. When the target process executes to the breakpoint instruction, a breakpoint event is triggered, the address corresponding to the breakpoint event is recorded, and the address corresponding to the breakpoint event is divided into different paths based on the key address.

2. The method according to claim 1, characterized in that, The number of breakpoint events triggered is multiple; obtaining a key address in the main loop of each thread in the target process includes: Trigger breakpoint events multiple times to obtain call stack information when each breakpoint event is triggered. Search for the address of the first changed stack frame in multiple call stack information, starting from the bottom of the stack; The address above the first stack frame address that changed is identified as the critical address; When the target process executes to the breakpoint instruction, a breakpoint event is triggered, the address corresponding to the breakpoint event is recorded, and the address corresponding to the breakpoint event is segmented into different paths based on the key address, including: When the target process executes to the breakpoint instruction, a new breakpoint event is triggered, and it is determined whether the address corresponding to the new breakpoint event is the same as the critical address. If they are the same, record the address corresponding to the new breakpoint event and insert a separator, which is used to indicate the end of an execution path; If they are different, record the address corresponding to the new breakpoint event.

3. The method according to claim 2, characterized in that, The number of the first changed stack frame addresses is multiple; determining the address above the first changed stack frame address as the critical address includes: Determine the number of call stack information corresponding to the first stack frame address that changes; The key address is the address above the first stack frame address that has changed the most.

4. The method according to claim 2, characterized in that, The target process includes multiple threads; the method further includes: Obtain the thread identifier ID corresponding to multiple breakpoint events, and search for the first changed stack frame address from the bottom of the stack in the call stack information corresponding to the same ID to obtain the correspondence between different thread IDs and their corresponding key addresses. Obtain the thread ID corresponding to the new breakpoint event, and determine the key address corresponding to the thread ID corresponding to the new breakpoint event from the correspondence; The step of determining whether the address corresponding to the new breakpoint event is the same as the critical address includes: Determine whether the address corresponding to the new breakpoint event is the same as the key address determined from the correspondence.

5. The method according to any one of claims 1 to 4, characterized in that, The disassembly of the memory mapping information includes: Extract the code segment with executable permissions from the memory mapping information; The code segment is disassembled.

6. The method according to claim 5, characterized in that, Before disassembling the code segment, the method further includes: The code segment matching the code characteristics of the target dynamic library that is not of interest is excluded to obtain the target code segment, wherein the target dynamic library includes the basic runtime library, system service library and dynamic linker component; and / or, the code segment corresponding to the list of interest libraries is extracted from the code segment to obtain the target code segment; The disassembly of the code segment includes: The target code segment is disassembled.

7. A device for recording program execution paths, characterized in that, The device is applied to a Unix / Linux operating system, in which a target program runs. The device includes: The memory mapping acquisition module is used to obtain memory maps through / proc / in the Unix / Linux operating system. <pid> The / maps file reads the memory mapping information of the target process running in the target program;< / pid> The identification module is used to disassemble the memory mapping information, identify all function call instructions from it, and obtain the address of the function call instruction in the process virtual address space of the Unix / Linux operating system. The breakpoint setting module is used to attach ptrace from the Unix / Linux operating system to the target process and use ptrace to write breakpoint instructions at the address of the function call instruction. The key address acquisition module is used to acquire a key address in the main loop of each thread in the target process, and the key address is used as the boundary between different complete paths. The recording module is used to trigger a breakpoint event when the target process executes to the breakpoint instruction, record the address corresponding to the breakpoint event, and segment the address corresponding to the breakpoint event into different paths based on the key address.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images