Dynamic analysis and debugging method of plug-in and computer application program

Abstract

Dynamic analysis of the method and computer application program of the debugging method of the debugging method. By analyzing the DWARF debugging information of the binary file to be inserted, the association information of the instruction block and the source code file line number is obtained, the corresponding program counter is matched, the corresponding program counter is collected, the call condition of the function specified line in the source code is collected, and the call condition of the function specified line in the source code is collected. The local variable symbol and the memory address mapping table of the function to be inserted are obtained by the DWARF debugging information of the binary file, and the global variable symbol and the memory address mapping table are obtained. The local variable, global variable information of the current to-be-inserted analysis point is obtained. Thus, dynamic insertion can be performed at any line of the code, and all local variables and global variables saved in the stack of the current function during the execution of the line of code can be collected, and the relevant information of the current program running can be better understood, which is helpful for debugging.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of fault debugging, in particular to a dynamic analysis and a computer application program. BACKGROUND

[0002] Some debugging tools or methods currently available usually modify the source code to add print information. This method can obtain almost any debugging information very conveniently, but it needs to modify the source code and recompile, which is almost impossible to use in the actual production environment. There are also dynamic insertion techniques such as kprobe or eBPF technology to obtain debugging information, but these methods usually collect data at the function entry or exit. These tools are very flexible and can achieve zero-intrusion and dynamic data collection. However, these tools also have obvious limitations, that is, they can usually only collect information at the function entry or exit, and some information during function execution cannot be obtained, such as locating whether some key execution logic is executed, collecting stack variable information during function execution, etc.

[0003] The source code modification method has very large limitations and cannot be used in the production environment. Although the dynamic binary insertion method has high flexibility and zero-intrusion, the current tools can usually only be used to collect function parameter information and function return value information at the function entry and exit, and cannot well collect the function internal call relationship and stack variable information.

[0004] A binary multi-execution body software insertion method based on dynamic insertion (202210428966.X) provides a binary multi-execution body software insertion method based on dynamic insertion. The code segment ended with a branch jump instruction is a translation block, which can accurately track the call chain of each code block and clearly determine the accurate process of function execution. However, it needs to insert probe code in each code block to collect information, which has large performance loss and cannot collect information on the function call stack.

[0005] A source code insertion improvement method for dynamic analysis (202010539967.2) provides a source code insertion improvement method for dynamic analysis. This method mainly aims at the security of software and does not involve software information collection and call relationship acquisition.

[0006] A binary instrumentation method for program dynamic analysis (202110667217.8) discloses a binary instrumentation method for program dynamic analysis, which uses the debugging information of a binary file to calculate basic instruction blocks and obtain the program counter of the corresponding instruction block for instrumentation. This method is basically consistent with the binary multi-executor software instrumentation method based on dynamic instrumentation. Both methods do not collect information about the function call stack. SUMMARY

[0007] To solve the problems in the prior art, the present application provides a dynamic analysis and instrumentation debugging method, which comprises:

[0008] Step S1: Obtain the information identifier of the to-be-instrumented analysis point.

[0009] Step S2: Based on the information identifier of the to-be-instrumented analysis point, analyze the DWARF debugging information of the to-be-instrumented analysis point binary file to obtain runtime information, including the to-be-instrumented function of the to-be-instrumented analysis point, the corresponding instruction block, the local symbol, and the global symbol.

[0010] Step S3: Based on the to-be-instrumented function of the to-be-instrumented analysis point and the corresponding instruction block, obtain the to-be-instrumented function program counter value and the corresponding instruction block first address program counter value, and calculate the difference between the to-be-instrumented function program counter value and the corresponding instruction block first address program counter value.

[0011] Step S4: Based on the local symbol and the global symbol of the to-be-instrumented analysis point, obtain a memory address mapping table, and input the memory address mapping table into the instrumentation execution function.

[0012] Step S5: The instrumentation execution function performs dynamic instrumentation based on the difference between the to-be-instrumented function program counter value and the corresponding instruction block first address program counter value in step S3, and the memory address mapping table in step S4.

[0013] In step S4, the memory address mapping table is obtained by obtaining and saving the mapping relationship between the local symbol and the memory address of the to-be-instrumented analysis point in step S2, and the mapping relationship between the global symbol and the memory address of the to-be-instrumented analysis point.

[0014] In step S5, the instrumentation execution function performs dynamic instrumentation through Kprobe or eBPF technology.

[0015] In step S1, the information identifier of the to-be-instrumented analysis point includes the source code file name, the instrumentation source code line number, and the to-be-instrumented function name.

[0016] The step S2 comprises the following steps: determining a binary file generated by a corresponding source code file based on a source code file name of the to-be-instrumented analysis point; parsing DWARF debugging information of the binary file to obtain runtime information, wherein the runtime information comprises a to-be-instrumented function of the to-be-instrumented analysis point, a corresponding instruction block, local symbols and global symbols.

[0017] The step S1 comprises the following steps: obtaining a to-be-instrumented function name of the to-be-instrumented analysis point; and obtaining a to-be-instrumented function of the to-be-instrumented analysis point based on the to-be-instrumented function name.

[0018] The step S5 comprises the following steps: obtaining a difference value between a program counter value of the to-be-instrumented function and a program counter value of a first address of the corresponding instruction block in the step S3; and obtaining a memory address mapping table in the step S4; and collecting, in a dynamic instrumenting process, a calling time of the to-be-instrumented function of the to-be-instrumented analysis point, and corresponding local symbols and global symbols when the to-be-instrumented function is called.

[0019] The step S1 comprises the following steps: obtaining a to-be-instrumented function name of the to-be-instrumented analysis point; and obtaining a to-be-instrumented function of the to-be-instrumented analysis point based on the to-be-instrumented function name.

[0020] The step S6 comprises the following steps: reporting, to a user mode program, the calling time of the to-be-instrumented function of the to-be-instrumented analysis point, the corresponding local symbols and global symbols when the to-be-instrumented function is called, and the information identifier of the to-be-instrumented analysis point in the step S1.

[0021] The step S7 comprises the following steps: understanding, by the user mode program, a running condition of the to-be-instrumented function based on the reported information, and assisting in analyzing a problem.

[0022] The step S6 comprises the following steps: reporting, to a user mode program, the calling time of the to-be-instrumented function of the to-be-instrumented analysis point, the corresponding local symbols and global symbols when the to-be-instrumented function is called, and the information identifier of the to-be-instrumented analysis point in the step S1.

[0023] The application further provides a computer application program for executing the dynamic instrumenting debugging method.

[0024] The application can perform dynamic instrumenting at any line of code, and can collect information of all local variables and global variables saved in a stack of a current function when the line of code is executed, so that relevant information of a current program running can be better understood, and debugging is greatly assisted. DETAILED DESCRIPTION

[0025] In order to have a further understanding of the technical solutions and beneficial effects of the present application, the technical solutions of the present application and the beneficial effects thereof are described in detail below.

[0026] The present application aims to provide a dynamic analysis and plug-in debugging method. The method analyzes the DWARF debugging information of a binary file to obtain the specified line of the corresponding source code specified file for dynamic plug-in, and can analyze the local variable information saved in the stack in the calling function through the DWARF debugging information and collect the information. Thus, the dynamic plug-in can be performed at any line of the code, and all local variables and global variables saved in the stack of the current function during the execution of the line of code can be collected, so that the relevant information of the current program running can be better understood, which greatly helps the debugging.

[0027] One specific implementation of the present application is as follows:

[0028] 1. Determine the information identifier of the to-be-plugged analysis point, which includes the source code file name, the plug-in source code line number, the to-be-plugged function name and the offset value, and the to-be-collected local symbol, the to-be-collected global symbol and other information to be collected.

[0029] The offset value is the line number offset of the to-be-plugged analysis point in the to-be-plugged function, for example, if Func_a is taken as the to-be-plugged function and xxx is taken as the plug-in source code line number, then:

[0030] xxx: Func_a(void) { / / xxx is the source code line number

[0031] xxx+1: int a = 0, b = 1, c = 2;

[0032] xxx+n: a = b + c;

[0033] xxx+n+1: return a;

[0034] }

[0035] When the to-be-plugged analysis point is specified, if the input parameter needs to be captured during the running of Func_a, the function name of the to-be-plugged analysis point is Func_a and the offset is 0, and if the information of the corresponding local variable needs to be obtained during the running of xxx+n, the function name of the to-be-plugged analysis point is Func_a and the offset is n.

[0036] The to-be-patched function and the offset value are the required information of the specific runtime obtained when the specific binary file is parsed in step 2, and the specific runtime patching address is obtained from the DWARF information through the information. The difference lies in that: the information of the to-be-patched analysis point in the source code file in step 1 is confirmed by humans in the source file, such as the xxx+n position in Func_a in the foregoing; and in step 2, the actual to-be-patched point position of the to-be-patched analysis point in the binary runtime memory is parsed from the DWARF.

[0037] 2. Based on the source code file name of the to-be-patched analysis point, determine the binary file generated by the corresponding source code file, parse the DWARF debugging information of the binary file, and obtain the information of the to-be-patched analysis point in the actual runtime of the binary file confirmed in step 1 from the DWARF debugging information. The information includes the to-be-patched function, the corresponding runtime information of the instruction block, the file, the local symbol and the global symbol of the to-be-patched analysis point.

[0038] The local symbol and the global symbol collected in this step are compared with the to-be-collected local symbol and the to-be-collected global symbol in step 1 respectively, and the local symbol and the global symbol in step 2 should be consistent with the to-be-collected local symbol and the to-be-collected global symbol in step 1 respectively.

[0039] The to-be-patched function collected in this step is compared with the to-be-patched function in step 1, and the to-be-patched function collected in this step should be consistent with the to-be-patched function in step 1: if it is determined in step 1 that the xxx+n line in the function Func_a is patched, then in step 2, the function name parsed from the DWARF information through the xxx+n line information of the Func_a function must also be Func_a, so as to ensure the accuracy of the parsing.

[0040] In the present application, the file belongs to the file containing the to-be-patched function, such as the function Func_a in the aaa.c file, and the function Func_a may also exist in the bbb.c file, and the present application needs to patch the Func_a function in the aaa.c file, so we must parse the aaa.c file when parsing the DWARF information, and if the bbb.c file is parsed, it means that the parsing is wrong.

[0041] 3. Obtain the to-be-patched function program counter value from the to-be-patched analysis point to-be-patched function in step 2, obtain the instruction block first address program counter value from the instruction block to which the to-be-patched analysis point belongs, and calculate the difference between the to-be-patched function program counter value and the instruction block first address program counter value.

[0042] 4. Obtain the mapping relationship between the local symbol and the memory address of the to-be-instrumented analysis point in step 2 and the mapping relationship between the global symbol and the memory address of the to-be-instrumented analysis point in step 2, save the mapping relationship between the local symbol and the memory address of the to-be-instrumented analysis point and the mapping relationship between the global symbol and the memory address of the to-be-instrumented analysis point in the memory address mapping table, and pass them to the instrumented execution function.

[0043] 5. The instrumented execution function uses Kprobe or eBPF technology or other related dynamic instrumenting technology to perform dynamic instrumenting based on the difference between the program counter value of the to-be-instrumented function and the program counter value of the first address of the instruction block in step 3 and the memory address mapping table passed in step 4.

[0044] Specifically, between performing dynamic instrumenting, based on the to-be-instrumented function name of the to-be-instrumented analysis point obtained in step 1, the to-be-instrumented function of the to-be-instrumented analysis point is obtained, and the instrumented execution function is hooked to the to-be-instrumented function of the to-be-instrumented analysis point. Thus, when the to-be-instrumented function runs to the hook point, the instrumented execution function is called, and the information collection of the to-be-instrumented analysis point is performed in the instrumented execution function. The collected information includes the time when the to-be-instrumented function is called and the corresponding local symbol and global symbol when the to-be-instrumented function is called.

[0045] Specifically, the instrumented execution function analyzes the passed-in memory address mapping table to obtain the local symbol and the global symbol, and performs the information collection of the to-be-instrumented analysis point based on the local symbol and the global symbol.

[0046] In the present application, the local symbol and the global symbol refer to the local variable value and the global variable value of the to-be-instrumented analysis point.

[0047] Symbol A represents the to-be-instrumented function, and symbol B represents the instrumented execution function. Their calling relationship is as follows:

[0048] Function A:

[0049] A (parameter) {

[0050] Variable 1 = xxx;

[0051] Variable 2 = parameter;

[0052] Abd = variable 1 + variable 2;

[0053] }

[0054] The original running process of function A is as follows:

[0055] Variable 1 = xxx; first step

[0056] Variable 2 = xxx; second step

[0057] Abd = variable1 + variable2; third step

[0058] Subsequent steps

[0059] It can be necessary to know the value of variable Abd due to the need to troubleshoot problems, so a function B for collecting information can be inserted at the line of code after Abd = variable1 + variable2; third step, and the B function needs to do is to parse the symbolic information and memory address information of variable1 and variable2, so as to obtain the values of variable1 and variable2 by reading the memory values, and thus the value of Abd can be obtained by calculation.

[0060] 6. The information collected in step 5 and the information obtained in step 1 is reported to the user state program through kernel memory mapping, BPF map, netlink, etc.

[0061] 7. The user state program understands the running situation of the to-be-stubbed analysis point and the relevant information collected in the to-be-stubbed function according to the collected information reported in step 6, so as to understand the running situation of the to-be-stubbed function and assist in analyzing problems.

[0062] Therefore, the present application can obtain the association information of the instruction block and the source code file line number by parsing the DWARF debugging information of the binary file, match the source code for the stubbed code line, collect the corresponding program counter for accurate dynamic stubbing, and collect the calling situation of the specified line of the to-be-stubbed function in the source code by observing the calling situation of the to-be-stubbed analysis point. The local symbol and memory address mapping table and the global symbol and memory address mapping table of the to-be-stubbed function are obtained through the DWARF debugging information of the binary file, and the local variable and global variable information of the to-be-stubbed analysis point is obtained. In this way, dynamic stubbing can be performed at any line of code, and all local variables and global variables saved in the stack of the current function during the execution of the line of code can be collected, so that the relevant information of the current program running can be better understood, which greatly helps debugging.

[0063] In the present application, the terms are agreed and explained as follows:

[0064] kprobe: is a dynamic probing mechanism in the Linux kernel. It allows users to insert probing points into kernel code at runtime, and these probing points are essentially a special set of instructions. When the kernel executes to the function inserted with the probing point (including function entry, return point, etc.), a predefined handler is triggered.

[0065] DWARF: (Debugging With Attributed Record Formats) is a standard data format for debugging information. It is mainly used to store debugging-related information of a program, such as the type, scope, location of variables, and parameters, local variables, and many other details of functions.

[0066] eBPF: (Extended Berkeley Packet Filter) is a kernel technology that originated from the Berkeley Packet Filter (BPF). eBPF allows users to safely run custom programs in the kernel space, which can be loaded into the Linux kernel and executed when certain kernel events (such as system calls, network packet transmission and reception, process scheduling, etc.) are triggered.

[0067] Although the present application has been described with reference to the preferred embodiments thereof, it is not intended to limit the protection scope of the present application, and various changes and modifications can be made to the above-described embodiments without departing from the spirit and scope of the present application. Therefore, the protection scope of the present application is defined by the claims.

Claims

1. A method of dynamically analyzing a debugged program, characterized by, The method comprises the following steps: Step S1: obtaining the information identifier of the to-be-instrumented analysis point; the information identifier of the to-be-instrumented analysis point comprises a source code file name, an instrumented source code line number and a to-be-instrumented function name; Step S2: based on the source code file name of the to-be-instrumented analysis point, determining a binary file generated by compiling a corresponding source code file, parsing the DWARF debugging information of the to-be-instrumented analysis point binary file, and obtaining runtime information therefrom; the runtime information comprises a to-be-instrumented function of the to-be-instrumented analysis point, a corresponding instruction block, local symbols and global symbols; Step S3: based on the to-be-instrumented function of the to-be-instrumented analysis point and the corresponding instruction block, obtaining a to-be-instrumented function program counter value and a corresponding instruction block first address program counter value respectively, and calculating the difference between the to-be-instrumented function program counter value and the corresponding instruction block first address program counter value; Step S4: based on the local symbols and the global symbols of the to-be-instrumented analysis point, obtaining a memory address mapping table, and inputting the memory address mapping table into an instrumented execution function; based on the to-be-instrumented function name obtained in step S1, obtaining the to-be-instrumented function of the to-be-instrumented analysis point, associating the instrumented execution function with the to-be-instrumented function of the to-be-instrumented analysis point, so that the instrumented execution function is called when the to-be-instrumented function runs to a hook point, thereby performing dynamic instrumentation in the to-be-instrumented function; Step S5: the instrumented execution function performs dynamic instrumentation based on the difference between the to-be-instrumented function program counter value and the corresponding instruction block first address program counter value in step S3, and the memory address mapping table in step S4.

2. The dynamically analyzed instrumented debugging method of claim 1, wherein, In step S4, the memory address mapping table is obtained by obtaining and saving the mapping relationship between the local symbols and the memory addresses of the to-be-instrumented analysis point in step S2, and the mapping relationship between the global symbols and the memory addresses of the to-be-instrumented analysis point.

3. The dynamically analyzed instrumented debugging method of claim 1, wherein, In step S5, the instrumented execution function performs dynamic instrumentation through Kprobe or eBPF technology.

4. The dynamically analyzed instrumented debugging method of claim 1, wherein, In step S5, during the dynamic instrumentation process based on the difference between the to-be-instrumented function program counter value and the corresponding instruction block first address program counter value in step S3, and the memory address mapping table in step S4, the instrumented execution function collects the time when the to-be-instrumented function of the to-be-instrumented analysis point is called, and the local symbols and global symbols corresponding to the time when the to-be-instrumented function is called.

5. The dynamically analyzed instrumented debugging method of claim 4, wherein, Further comprising: Step S6: reporting the time when the to-be-instrumented function of the to-be-instrumented analysis point is called, the local symbols and global symbols corresponding to the time when the to-be-instrumented function is called in step S5, and the information identifier of the to-be-instrumented analysis point in step S1 to a user mode program; Step S7: based on the reported information, the user mode program understands the running situation of the to-be-instrumented function, and assists in analyzing problems.

6. The dynamically analyzed instrumented debugging method of claim 5, wherein: In step S6, the time when the to-be-instrumented function of the to-be-instrumented analysis point is called, the local symbols and global symbols corresponding to the time when the to-be-instrumented function is called in step S5, and the information identifier of the to-be-instrumented analysis point in step S1 are reported to the user mode program through kernel memory mapping, BPF map or netlink.

7. A computer application program, characterized by: The method is used for performing the dynamic analysis of the instrumented debugging method.