A method for determining function call information and related apparatus

Abstract

The embodiment of the application discloses a function call information determination method and related device, wherein the method comprises the following steps: obtaining a source file; performing multi-layer type analysis (MLTA) on the source file to obtain a function call relationship; performing string pointer analysis on the source file to obtain a string transmission relationship; and combining the function call relationship and the string transmission relationship to obtain function call information. The method compensates for the defect that the MLTA can only identify the function type but cannot identify the string, and can improve the precision of the function call information on the premise of maintaining low time and memory overhead, because the code is limited to string pointer analysis and does not need to analyze the variable transmission condition of the entire program.

Description

Technical Field

[0001] This application relates to the field of computer software, and in particular to a method and related apparatus for determining function call information. Background Technology

[0002] In the field of computer software, function call information is widely used in code measurement, security checks, and compiler optimization, playing a crucial role in ensuring product code quality, improving product security and performance, and reducing product costs. For actual business applications, as business code becomes increasingly complex, the number of technical personnel involved in development increases, and the complexity of the architecture also rises. Accurate function call information can help developers avoid using incorrect function calls and prevent code corruption, circular calls, and other issues. In C / C++ programs, Multi-Layer Type Analysis (MLTA) can quickly obtain the function pointer pointing to the calling function. However, MLTA relies on structure types for addressing, so for different instances of the same type, the function pointer obtained through MLTA may be difficult to determine, making it difficult to guarantee the accuracy of function call information. Therefore, how to improve the accuracy of function call analysis brought about by introducing MLTA is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0003] This application provides a method and related apparatus for determining function call information, which solves the problem of decreased accuracy in function call analysis caused by the introduction of MLTA.

[0004] The first aspect of this application provides a method for determining function call information, including:

[0005] Get the source file;

[0006] Perform multi-level type analysis on the source file to obtain the function call relationships;

[0007] Perform string pointer analysis on the source file to obtain the string passing relationships;

[0008] By combining the function call relationship and the string passing relationship, the function call information can be obtained.

[0009] The method provided in this application combines the results obtained from MLTA and string pointer analysis. String pointer analysis overcomes the limitation of MLTA, which can only identify function types but not strings. Furthermore, since the code analysis is limited to string pointer analysis and does not require analysis of the variable passing situation of the entire program, the accuracy of function call information can be improved while maintaining low time and memory overhead.

[0010] In one possible implementation, multi-level type analysis (MLTA) is performed on the source file to obtain function call relationships, specifically including:

[0011] By performing a value usage analysis on the source file, the call relationship of the first sub-function is obtained;

[0012] Perform MLTA on the source file to obtain the second sub-function call relationship;

[0013] By combining the first sub-function call relationship and the second sub-function call relationship, we obtain the function call relationship.

[0014] In another possible implementation, multi-level type analysis (MLTA) is performed on the source file to obtain the first call information, specifically including:

[0015] By performing a value usage analysis on the source file, the call relationship of the third sub-function is obtained;

[0016] Based on the third sub-function call relationship, identify the functions to be analyzed in the source file that do not have explicit call characteristics;

[0017] Perform MLTA on the function to be analyzed to obtain the fourth sub-function call relationship;

[0018] By combining the third and fourth sub-function call relationships, we obtain the function call relationships.

[0019] In another possible implementation, multi-level type analysis (MLTA) is performed on the source file to obtain the first call information, specifically including:

[0020] Perform MLTA on the source file to obtain the fifth sub-function call relationship;

[0021] Based on the fifth sub-function call relationship, identify the functions to be analyzed in the source file that do not have explicit call information;

[0022] By performing constant-value usage analysis on the function fragment to be analyzed, the call relationship of the sixth sub-function is obtained;

[0023] By combining the fifth and sixth sub-function call relationships, we obtain the function call relationships.

[0024] Among the three possible implementation methods mentioned above, the acquisition of function call relationships uses a combination of MLTA and string pointer analysis, aiming to improve the accuracy of function call relationships.

[0025] In one possible implementation, string pointer parsing is performed on the source file to obtain the string passing relationships, including:

[0026] Perform string pointer analysis on the source file to determine the information passed by the string pointers;

[0027] The calculation process of strings is modeled based on the information transmitted;

[0028] Based on the modeling results, the string transmission relationship is determined.

[0029] In this embodiment of the application, by modeling the string calculation process, the problem of string pointers being processed into new strings by string functions, resulting in incorrect string passing relationships, is solved.

[0030] In one possible implementation, string pointer parsing is performed on the source file to obtain the string passing relationships, specifically including:

[0031] Perform association analysis on the source files based on the nearest common ancestor;

[0032] Based on the correlation analysis results, the source file was split into multiple code snippets;

[0033] String pointer analysis is performed on multiple code snippets to obtain the string passing relationships.

[0034] In this embodiment of the application, by dividing the source file into code fragments and performing string pointer analysis on multiple code fragments, the input size of string pointer analysis can be effectively reduced.

[0035] In one possible implementation, after combining the function call relationship and the string passing relationship to obtain the function call information, the following is also included:

[0036] Rendering a function call graph based on function call information.

[0037] In this embodiment, the inter-function call relationship is rendered into a function call graph for visualization, which helps programmers clearly understand the specific structure of the program, locate errors in the program more quickly, and optimize the code.

[0038] In one possible implementation, the source file is an intermediate representation.

[0039] A second aspect of this application provides a device for determining function call information, comprising:

[0040] The acquisition module is used to acquire the source file, which can be in an intermediate representation format.

[0041] The first analysis module is used to perform MLTA on the source file to obtain the function call relationship;

[0042] The second analysis module is used to perform pointer analysis on the source file to obtain the string passing relationships;

[0043] The summary module is used to combine function call relationships and string passing relationships to obtain function call information.

[0044] In one possible implementation, the first analysis module is specifically used to perform value usage analysis on the source file to obtain the first sub-function call relationship; perform MLTA on the source file to obtain the second sub-function call relationship; and combine the first sub-function call relationship and the second sub-function call relationship to obtain the function call relationship.

[0045] In another possible implementation, the first analysis module is specifically used to perform fixed-value usage analysis on the source file to obtain the third sub-function call relationship; based on the sub-function call relationship, the functions to be analyzed in the source file that do not have explicit call characteristics are identified; MLTA is performed on the functions to be analyzed to obtain the fourth sub-function call relationship; the third sub-function call relationship and the fourth sub-function call relationship are combined to obtain the function call relationship.

[0046] In another possible implementation, the first analysis module is specifically used to perform MLTA on the source file to obtain the fifth sub-function call relationship; based on the fifth sub-function call relationship, the functions to be analyzed in the source file that do not have explicit call information are identified; the function fragments to be analyzed are subjected to fixed-value usage analysis to obtain the sixth sub-function call relationship; and the fifth and sixth sub-function call relationships are combined to obtain the function call relationship.

[0047] In one possible implementation, the second analysis module is specifically used to perform string pointer analysis on the source file to determine the information passed by the string pointers; based on the information passed, to model the string calculation process; and based on the modeling results, to determine the string passing relationship.

[0048] In one possible implementation, the second analysis module is specifically used to perform association analysis on the source file based on the Lowest Common Ancestor (LCA); based on the association analysis results, the source file is split into multiple code segments; and string pointer analysis is performed on the multiple code segments to obtain the string passing relationships.

[0049] One possible implementation also includes:

[0050] The rendering module is used to render a function call graph based on function call information.

[0051] A third aspect of this application provides a computing device, including a processor;

[0052] The processor is used to execute computer programs or computer instructions in memory to perform the methods described in the first aspect above.

[0053] In one possible implementation, memory is also included.

[0054] The fourth aspect of this application provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the implementation as described in the first aspect.

[0055] The fifth aspect of this application provides a computer-readable storage medium including computer instructions that, when executed on a computer, cause the computer to perform the implementation as described in the first aspect.

[0056] The beneficial effects of the technical solutions provided in the second to fifth aspects above can be referred to the beneficial effects of the technical solutions in the first aspect, and will not be repeated here. Attached Figure Description

[0057] Figure 1 This is a code snippet from an embodiment of this application;

[0058] Figure 2 This is a code snippet from an embodiment of this application;

[0059] Figure 3 This is a diagram of a programmable pipeline system architecture provided in an embodiment of this application;

[0060] Figure 4 This is a flowchart illustrating the method for determining function call information provided in an embodiment of this application.

[0061] Figure 5 This is a code snippet from an embodiment of this application;

[0062] Figure 6 This is a flowchart illustrating the method for determining function call information provided in an embodiment of this application.

[0063] Figure 7 This is a flowchart illustrating the method for determining function call information provided in an embodiment of this application.

[0064] Figure 8 This is a flowchart illustrating the method for determining function call information provided in an embodiment of this application.

[0065] Figure 9 This is a flowchart illustrating the method for determining function call information provided in an embodiment of this application.

[0066] Figure 10 This is a schematic diagram of the structure of the device for determining function call information provided in the embodiments of this application;

[0067] Figure 11 This is a schematic diagram of the structure of the computing device provided in the embodiments of this application. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0069] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved. The division of units in this application is a logical division. In practical applications, there may be other division methods. For example, multiple units may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the shown or discussed mutual coupling, direct coupling, or communication connection may be through some interface, and the indirect coupling or communication connection between units may be electrical or other similar forms, none of which are limited in this application. Furthermore, the units or sub-units described as separate components may or may not be physically separated, may or may not be physical units, or may be distributed among multiple circuit units. Some or all of the units can be selected to achieve the purpose of the solution in this application according to actual needs.

[0070] In the field of computer software, function call information is widely used in code measurement, security checks, compilation optimization, and other scenarios, playing an important role in ensuring product code quality, improving product security and performance, and reducing product costs. In practical business scenarios, as business code becomes increasingly complex and the number of technical personnel involved in development grows, the complexity of the architecture also increases. Accurate function call information can help developers avoid using incorrect function calls, preventing code corruption, circular calls, and other issues. In security scenarios, malicious attacks can modify the original call relationships of a victim program by changing the values ​​of function pointers, turning normal control flow into malicious control flow. Therefore, accurate function call graphs can help the system find these indirectly called target functions, thereby improving the accuracy of static analysis and system hardening techniques. In code miniaturization scenarios, redundant code affects the size of the program's binary, making it essential to keep the code concise. Redundant functions are functions that are not called in the program. These redundant functions can be easily found through function call graphs, allowing for code reduction. In compiler optimization scenarios, indirect function calls have higher overhead than direct calls. If the range of possible target functions for indirect calls can be calculated through function call graphs, they can be replaced with direct call instructions, thus reducing program runtime overhead.

[0071] In C / C++ programs, accurate function call graph construction relies on traditional pointer analysis. However, this analysis is slow and memory-intensive, making it unsuitable for large-scale pipelined applications. Multi-Layer Type Analysis (MLTA), on the other hand, can quickly identify the calling function pointed to by a function pointer. MLTA relies on the observation that function pointers are typically stored in objects with a multi-layered type hierarchy; before indirect calls, function pointers are loaded "layer by layer" from objects with the same type hierarchy. By matching function pointers with the multi-layered types of functions, MLTA can significantly refine the indirect call target. MLTA is effective because multi-layered types offer more constraints than single-layered types. It avoids introducing false positives by conservatively tracking target propagation between multi-layered types, and the layered design allows MLTA to safely fall back if analysis at a certain layer becomes infeasible.

[0072] like Figure 1 As shown, Figure 1The following is a code snippet from an embodiment of this application. a, b, c, and d represent different structure types, while a->b->c and d->b->c are two multi-level structure addressing operations. In line 4, MLTA can use the structure types (a, b, c) to distinguish that the function pointer fptr originates from line 1, not line 2 (d, b, c), thus accurately determining that the function pointer called in line 4 actually points to the foo function, not the bar function.

[0073] However, MLTA relies on the structure type for addressing. Therefore, for different instances of the same type, the function pointer obtained through MLTA may be difficult to determine, making it difficult to guarantee the accuracy of function call information.

[0074] like Figure 2 As shown, Figure 2 The following is a code snippet from an embodiment of this application. In line 3, sdNotify is a function pointer. MLTA can analyze that it propagates a function of type PluginSystemdNotify, but it cannot detect that the function name is sd_notify. This is because it can only detect that the function type is PluginSystemdNotify. It lacks modeling of dynamic calls like dlsym and awareness of string values. Therefore, when the code includes other functions of type PluginSystemdNotify, MLTA may have false alarms.

[0075] Therefore, how to improve the accuracy of function call analysis brought about by the introduction of MLTA is a technical problem that urgently needs to be solved by those skilled in the art.

[0076] To address the aforementioned problems, embodiments of this application provide a method for determining function call information. This method performs MLTA on the code to obtain function call relationships and performs string pointer analysis on the code to obtain string passing relationships. By combining the function call relationships and string passing relationships, the final function call information is obtained. This method overcomes the limitation of MLTA, which can only identify function types but not strings, through string pointer analysis. Furthermore, because the analysis is limited to string pointers and does not require analysis of the entire program's variable passing behavior, the accuracy of function call information can be improved while maintaining low time and memory overhead.

[0077] The method for determining function call information provided in this application embodiment will be described in detail below. First, the application scenario of the method for determining function call information provided in this application embodiment will be introduced. This method can be applied to a programmable pipeline system; please refer to [link to relevant documentation]. Figure 3 , Figure 3The programmable pipeline system architecture diagram provided in this application embodiment illustrates that large code repositories require continuous integration for continuous release during updates. This process is accomplished by a programmable pipeline. Programmable pipeline systems typically run on servers and define how the code repository is compiled, inspected, and packaged during the pipeline process.

[0078] like Figure 3 As shown, the method for determining function call information provided in this application embodiment can construct a function call graph for a programming language-based program. This process can be deployed on a static pipeline or integrated as a plugin into a code editor or integrated development environment (IDE). After providing the source file, it can be converted into an intermediate representation (IR) format. This source file can be used as input to the method provided in this application embodiment for analysis to obtain the corresponding function call information. The analysis result is stored in a data format file and can be used as input for downstream user-defined checkers.

[0079] Figure 3 The architecture diagram shown is mainly divided into a pipeline (①), a central server (④), a user server (⑦), and a custom checker (⑧). In the pipeline, a code analysis plugin (②) carrying the method corresponding to the embodiment of this application is deployed on a node of the pipeline system. The code analysis plugin can generate corresponding compilation commands when compiling user source code (usually a code repository). These compilation commands can be compiled into an IR file by Clang, which can be used as the input (③) of the method corresponding to the embodiment of this application. The data produced by the method corresponding to the embodiment of this application is then stored in an index database. This data can coexist with other analysis results (such as other symbol dependencies shown in the figure) in the index database. The pipeline will transmit the index database to the central server (④). The server interacts with the central database (⑤) to obtain summary information of other pipeline nodes. The central server can also add business attributes, cross-repository functions, and other information to obtain a full function call graph. Users cache data from the central server to the user server using a RESTful interface or by installing the Wheel package (⑥), and then check the user's code by writing a custom Checker (⑧).

[0080] Please see Figure 4 , Figure 4 A flowchart of the method for determining function call information provided in this application embodiment includes:

[0081] 401. Obtain the source file;

[0082] Understandably, to determine function call information in code, the source file of that code is first needed. This source file can be in Intermediate Representation (IR) format. IR refers to compiling or interpreting a high-level programming language (such as C, C++, Java, Python, etc.) into a lower-level but more general representation for optimization and execution. Different compilers and interpreters have their own IR formats. LLVM is a compiler framework that can be used to provide intermediate representations (LLVM IR), supporting various front-ends and back-ends.

[0083] 402. Perform MLTA on the source file to obtain the function call relationships.

[0084] In this embodiment, after obtaining the source file, MLTA is used to analyze the source file to obtain the function call relationship. It is understandable that in this step, since MLTA determines the call relationship based on structure addressing and lacks the ability to detect string pointer passing, MLTA cannot distinguish between two functions of the same type with inconsistent function names. Therefore, in this case, the function call relationship obtained in this step may have low accuracy.

[0085] 403. Perform string pointer analysis on the source file to obtain the string passing relationships.

[0086] Regarding the problem in step 402, this embodiment of the application, after obtaining the source file, also performs string pointer analysis on the source file to trace the transmission of key strings in the program. For example, in hook functions, dlopen / dlsym is used to load functions from other dynamic link libraries. In this process, the transmission of string pointers becomes particularly important because library paths and function names are usually provided in string form. By performing string pointer analysis on the source file, the transmission path of key strings in the program can be traced. These key strings are often a path to a dynamic link library, a function name, or a character substring that makes up a file and a function. The path to the dynamic link library is used by the dlopen function to load the library file, the function name is used by the dlsym function to find functions in the library, and the character substring that makes up the file and function may be used for other purposes, such as matching, searching, or constructing more complex strings. All of the above key strings, whether they are library paths, function names, or character substrings, will ultimately be used by the dlopen and dlsym functions.

[0087] Therefore, by analyzing string pointers in the source file, especially in scenarios involving dynamic link library loading and hook functions, the string passing relationships in the source file can be determined effectively.

[0088] 404. Combine the function call relationship and the string passing relationship to obtain the function call information.

[0089] In this embodiment, the results obtained from MLTA and string pointer analysis are combined. String pointer analysis makes up for the deficiency of MLTA, which can only identify function types but cannot identify strings. Furthermore, since the code analysis is limited to string pointer analysis and does not need to analyze the variable passing situation of the entire program, the accuracy of function call information can be improved while maintaining low time and memory overhead.

[0090] In one possible implementation, considering that MLTA still lacks awareness of variable instances and their passing, the following embodiments of this application will... Figure 4 The methods in the corresponding embodiments are further supplemented.

[0091] First, we will explain the reason why MLTA lacks awareness of variable instances and their propagation. Please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a code snippet from an embodiment of this application. When a structure address comes from different instances of the same type (e.g., p and q are both structure A), MLTA will assume that the function pointer fptr may point to both the foo and bar functions, thus generating a false alarm.

[0092] To resolve the above issues, please refer to Figure 6 , Figure 6 A flowchart of the method for determining function call information provided in this application embodiment includes:

[0093] 601. Obtain the source file.

[0094] It is understandable that step 601 is related to the above. Figure 4 Step 401 in the illustrated embodiment corresponds to the relevant description above, which will not be repeated here. Specifically, the source file can be a source file in IR format.

[0095] 602. Perform a value usage analysis on the source file to obtain the call relationship of the first sub-function;

[0096] 603. Perform MLTA on the source file to obtain the second sub-function call relationship;

[0097] 604. Combine the first sub-function call relationship and the second sub-function call relationship to obtain the function call relationship.

[0098] In this embodiment, two analysis methods are used to obtain function call relationships in the source file. One method is to perform value usage analysis on the source file. Value usage analysis is used to analyze the value (definition) and usage of relevant variables before and after the execution of each instruction in the program. It aims to determine the value point (i.e., the point where the variable is assigned a new value) and usage point (i.e., the point where the variable is read or used) of each variable in the program. By analyzing these points, the compiler can establish the dependency relationship between variable values ​​between instructions, facilitating the understanding of data flow and control flow in the program, thereby determining the instructions for function calls and thus the function call relationship. This function call relationship reflects the direct call relationship between functions in the source file. To distinguish it from the function call relationship obtained by MLTA, the function call relationship obtained based on value usage analysis is called the first sub-function call relationship. Furthermore, in this embodiment, MLTA is also performed on the source file, and the analysis result is used as the second sub-function call relationship. The second sub-function call relationship includes not only direct call relationships but also indirect call relationships obtained through type analysis.

[0099] After obtaining the first and second call relationships, they are merged to obtain a more precise function call relationship. For example, ... Figure 5 As shown, MLTA alone suggests that the function pointer fptr might point to both the foo and bar functions. While usage analysis alone clarifies that fptr points to foo, it doesn't determine indirect function calls. Combining the results of both analyses clarifies the exact function pointer and the indirect function calls, leading to a more precise function call relationship.

[0100] 605. Perform string pointer analysis on the source file to obtain the string passing relationships;

[0101] 606. Combine the function call relationship and the string passing relationship to obtain the function call information.

[0102] It is understandable that steps 605 and 606 are the same as those described above. Figure 4 Steps 403 and 404 in the illustrated embodiment correspond to each other, and the relevant descriptions are described above and will not be repeated here.

[0103] This application also provides a method for determining function call information. Please refer to [link to relevant documentation]. Figure 7 , Figure 7 A flowchart of the method for determining function call information provided in this application embodiment includes:

[0104] 701. Obtain the source file.

[0105] It is understandable that step 701 is related to the above. Figure 4Step 401 in the illustrated embodiment and Figure 6 Step 601 in the illustrated embodiment corresponds to the relevant description above, which will not be repeated here. Specifically, the source file can be a source file in IR format.

[0106] In this embodiment, two analysis methods are also used to obtain the function call relationships in the source file. However, the two analysis methods are used in a specific order. If one analysis method cannot accurately obtain the function call relationships, the other method is used to supplement and obtain the function call relationships. Specifically:

[0107] In one possible implementation, the steps for determining function call relationships include:

[0108] 7021. Perform a fixed-value usage analysis on the source file to obtain the call relationship of the third sub-function;

[0109] 7031. Based on the call relationship of the third sub-function, identify the functions to be analyzed in the source file that do not have explicit call characteristics;

[0110] 7041. Perform MLTA on the function to be analyzed to obtain the fourth sub-function call relationship;

[0111] 7051. Combine the third sub-function call relationship and the fourth sub-function call relationship to obtain the function call relationship.

[0112] It is understood that, as can be seen from steps 7021 to 7051, the embodiments of this application first perform a fixed-value usage analysis on the source file. If the fixed-value usage analysis cannot accurately solve the indirect function call, the MLTA method is then used for analysis.

[0113] After performing a value-based analysis on the source file, the third sub-function call relationship is obtained. Based on this relationship, it is recorded which indirect call functions lack clear call characteristics, meaning their function calls are not accurately analyzed. Functions that are not accurately analyzed are then selected from the source file and identified as functions to be analyzed. MLTA is then used to analyze these selected functions, yielding the fourth sub-function call relationship. Combining the third and fourth sub-function call relationships results in a more precise function call relationship.

[0114] In another possible implementation, the steps for determining function call relationships include:

[0115] 7022. Perform MLTA on the source file to obtain the fifth sub-function call relationship;

[0116] 7032. Based on the fifth sub-function call relationship, identify the functions to be analyzed in the source file whose call information is not explicitly stated;

[0117] 7042. Perform constant value usage analysis on the function fragment to be analyzed to obtain the call relationship of the sixth sub-function;

[0118] 7052. Combine the fifth sub-function call relationship and the sixth sub-function call relationship to obtain the function call relationship.

[0119] It is understood that, according to steps 7022 to 7052, the embodiments of this application first perform MLTA on the source file, and then use fixed value analysis when the function pointer cannot be clearly defined by solving MLTA.

[0120] After performing MLTA on the source file, the fifth sub-function call relationship is obtained. Based on this relationship, it records which function pointers point to functions that are not unique, indicating inaccurate function call analysis. Functions that are not accurately analyzed are then selected from the source file and identified as functions to be analyzed. These selected functions are then analyzed using constant-valued analysis to obtain the sixth sub-function call relationship. Combining the fifth and sixth sub-function call relationships yields a more precise function call relationship.

[0121] 706. Perform string pointer analysis on the source file to obtain the string passing relationships;

[0122] 707. Combine the function call relationship and the string passing relationship to obtain the function call information.

[0123] It is understandable that steps 706 and 707 are related to the above. Figure 4 Steps 403 and 404 in the illustrated embodiment and Figure 6 Steps 605 and 606 in the illustrated embodiment correspond to each other, and the relevant descriptions are described above and will not be repeated here.

[0124] In one possible implementation, as described above Figure 4 , Figure 6 and Figure 7 Based on the embodiments shown, this application further describes the string pointer analysis steps of the source file.

[0125] Please see Figure 8 , Figure 8 A flowchart of the method for determining function call information provided in this application embodiment includes:

[0126] 801. Obtain the source file.

[0127] It is understandable that step 801 is related to the above. Figure 4 Step 401 in the illustrated embodiment Figure 6 Step 601 in the illustrated embodiment and Figure 7 Step 701 in the illustrated embodiment corresponds to this and will not be repeated here. Specifically, the source file can be a source file in IR format.

[0128] 802. Perform Multi-Level Type Analysis (MLTA) on the source file to obtain the function call relationships.

[0129] It is understandable that step 802 is related to the above. Figure 4 Step 402 in the illustrated embodiment corresponds to step 802, and this step can be replaced with... Figure 6 Steps 602 to 604 in the illustrated embodiment can also be replaced with... Figure 7 For the descriptions of steps 7021 to 7051 or steps 7022 to 7052 in the illustrated embodiment, please refer to the above text, and they will not be repeated here.

[0130] 803. Perform string pointer analysis on the source file to determine the information passed by the string pointers;

[0131] 804. Model the string calculation process based on the transmitted information;

[0132] 805. Based on the modeling results, determine the string transmission relationship.

[0133] In this embodiment of the application, when performing string pointer analysis on the source file, considering that strings are represented by character arrays and pointers to these arrays in languages ​​such as C / C++, and that string functions (such as strcpy, strcat, strlen, etc.) operate on these pointers, which may change the content, length, or even storage location of the string, leading to errors in the string passing relationship, this embodiment of the application further models the string calculation process in determining the string passing relationship.

[0134] First, determine the passing information of all string pointers in the program, including identifying the declaration points of all string pointers and the strings they initially point to; trace all string-related function calls, especially those that accept string pointers as parameters, and understand how these functions use these pointers (i.e., whether they read string content or modify string content or their pointers); record all assignment operations on string pointers, including changes to pointer pointers (e.g., str = newStr;) and modifications to the content pointed to by pointers (e.g., strcpy(str,"new content");). Then, based on this information, build a model to simulate the behavior of strings and their pointers during program execution, including simulating the state of program memory, tracing the storage location and content of strings; simulating the operations on strings and pointers based on the semantics of string functions; and identifying which pointers might point to the same string. Based on this model, we can describe how strings and their pointers change in the program, thus obtaining the final string passing relationships. In the context of hook functions, the call information of hook functions can be summarized from the string passing relationships.

[0135] 806. Combine the function call relationship and the string passing relationship to obtain the function call information.

[0136] Step 806 and the above Figure 4 Step 404 in the illustrated embodiment Figure 6 Step 606 and in the embodiment Figure 7 Step 707 in the illustrated embodiment corresponds to the relevant description above, which will not be repeated here.

[0137] This application also provides a method for determining function call information. Please refer to [link to relevant documentation]. Figure 9 , Figure 9 A flowchart of the method for determining function call information provided in this application embodiment includes:

[0138] 901. Obtain the source file.

[0139] It is understandable that step 901 is related to the above. Figure 4 , Figure 6 , Figure 7 and Figure 8 The relevant steps in the illustrated embodiments are as described above and will not be repeated here. Specifically, the source file can be a source file in IR format.

[0140] 902. Perform Multi-Level Type Analysis (MLTA) on the source file to obtain the function call relationships.

[0141] It is understandable that step 902 and Figure 8 Similar to 802 in the illustrated embodiment, it can be used in conjunction with the above. Figure 4 Step 402 in the illustrated embodiment corresponds to, and can be replaced with, Figure 6 Steps 602 to 604 in the illustrated embodiment can also be replaced with... Figure 7 For the descriptions of steps 7021 to 7051 or steps 7022 to 7052 in the illustrated embodiment, please refer to the above text, and they will not be repeated here.

[0142] 903. Perform association analysis on the source files based on the nearest common ancestor;

[0143] 904. Based on the correlation analysis results, the source file is split into multiple code snippets;

[0144] 905. Perform string pointer analysis on multiple code snippets to obtain the string passing relationships.

[0145] In this embodiment, the source file is pre-splitted before string pointer analysis. This splitting method is based on the Lowest Common Ancestor (LCA) association analysis method. LCA is a static analysis technique used to find the lowest common ancestor node of two or more nodes (such as function call points) in the control flow graph of a program. LCA analysis can be used to identify strings that may be passed to the dlopen and dlsym functions; these strings are typically dynamically loaded library names or symbol names. For each found string, LCA analysis searches for the lowest common ancestor node of the string's definition or first assignment point. This node represents a potentially security or logical critical point in the program, because from this point, the values ​​of these strings can be accessed or modified by different parts of the program.

[0146] Once the call points of dlopen and dlsym and the associated strings are identified, the program can be divided into different subroutines or logical units based on these call points. In this embodiment, the subroutine or logical unit is defined as a code fragment, which includes tightly coupled local program information. It is understood that when the source file is in IR format, these code fragments are specifically IR fragments.

[0147] By analyzing string pointers in multiple code snippets, it is possible to calculate the information passed by the string pointers, i.e., the string passing relationship.

[0148] In this embodiment of the application, by dividing the source file into code fragments and performing string pointer analysis on multiple code fragments, the input size of string pointer analysis can be effectively reduced.

[0149] In one possible implementation, step 905 specifically includes:

[0150] 9051. Perform string pointer analysis on multiple code snippets to determine the information passed by the string pointers;

[0151] 9052. Model the string calculation process based on the transmitted information;

[0152] 9053. Based on the modeling results, determine the string transmission relationship.

[0153] In this embodiment of the application, after splitting the source file into multiple code segments, the problem of string pointers being processed into new strings by string functions, leading to incorrect string passing relationships, can also be considered, thereby modeling the string calculation process. It is understood that steps 9051 to 9053 are similar to... Figure 8 Steps 803 to 805 in the corresponding embodiment are similar, except that the source code is split into code fragments. For details, please refer to the above text, and will not be repeated here.

[0154] 906. Combine the function call relationship and the string passing relationship to obtain the function call information.

[0155] It is understandable that step 906 is related to the above. Figure 4 , Figure 6 , Figure 7 and Figure 8 The relevant steps in the illustrated embodiments are described in detail above and will not be repeated here.

[0156] 907. Render function call graph based on function call information.

[0157] Understandably, function call information can be stored as formatted data. Based on this data, a function call graph can be rendered to visualize the inter-function call relationships, helping programmers clearly understand the specific structure of the program, locate errors in the program more quickly, and optimize the code.

[0158] In summary, the method for determining function call information provided in this application combines the results of fixed-value analysis and multi-level type analysis when constructing the function call graph. It considers both function pointer types and data flow transmission, thus increasing the accuracy of the function call graph. Furthermore, it considers function calls passed via strings, using pointer analysis to analyze local parts of the program, balancing the tool's analysis accuracy and performance overhead. Additionally, it considers the string calculation process, incorporating modeling of string manipulation functions to analyze formatted, modified, and concatenated string content. Compared to traditional methods for determining function call information, the method provided in this application balances performance and accuracy, demonstrating significant application value.

[0159] This application also provides a device for determining function call information; please refer to [link to relevant documentation]. Figure 10 , Figure 10 A schematic diagram of the structure of the device for determining function call information provided in the embodiments of this application includes:

[0160] The acquisition module 1001 is used to acquire a source file, which can be in intermediate representation (IR) format.

[0161] The first analysis module 1002 is used to perform MLTA on the source file to obtain the function call relationship;

[0162] The second analysis module 1003 is used to perform pointer analysis on the source file to obtain the string passing relationship;

[0163] The summary module 1004 is used to combine function call relationships and string passing relationships to obtain function call information.

[0164] The function call information determination device provided in this application combines the results obtained from MLTA and string pointer analysis. By using string pointer analysis, it overcomes the limitation of MLTA, which can only identify function types but not strings. Furthermore, since the analysis of the code is limited to string pointer analysis and does not require analysis of the variable passing situation of the entire program, the accuracy of function call information can be improved while maintaining low time and memory overhead.

[0165] In one possible implementation, the first analysis module 1002 is specifically used to perform fixed-value usage analysis on the source file to obtain the first sub-function call relationship; perform MLTA on the source file to obtain the second sub-function call relationship; and combine the first sub-function call relationship and the second sub-function call relationship to obtain the function call relationship.

[0166] In another possible implementation, the first analysis module 1002 is specifically used to perform fixed-value usage analysis on the source file to obtain the third sub-function call relationship; based on the sub-function call relationship, identify the functions to be analyzed in the source file that do not have explicit call characteristics; perform MLTA on the functions to be analyzed to obtain the fourth sub-function call relationship; and combine the third and fourth sub-function call relationships to obtain the function call relationship.

[0167] In another possible implementation, the first analysis module 1002 is specifically used to perform MLTA on the source file to obtain the fifth sub-function call relationship; based on the fifth sub-function call relationship, determine the functions to be analyzed in the source file that do not have explicit call information; perform fixed-value usage analysis on the function fragments to be analyzed to obtain the sixth sub-function call relationship; and combine the fifth sub-function call relationship and the sixth sub-function call relationship to obtain the function call relationship.

[0168] Among the three possible implementation methods mentioned above, the acquisition of function call relationships uses a combination of MLTA and string pointer analysis, aiming to improve the accuracy of function call relationships.

[0169] In one possible implementation, the second analysis module 1003 is specifically used to perform string pointer analysis on the source file to determine the information passed by the string pointers; based on the information passed, to model the string calculation process; and based on the modeling results, to determine the string passing relationship.

[0170] In this embodiment of the application, by modeling the string calculation process, the problem of string pointers being processed into new strings by string functions, resulting in incorrect string passing relationships, is solved.

[0171] In one possible implementation, the second analysis module 1003 is specifically used to perform association analysis on the source file based on the Lowest Common Ancestor (LCA); based on the association analysis results, the source file is split into multiple code segments; and string pointer analysis is performed on the multiple code segments to obtain the string passing relationships.

[0172] In this embodiment of the application, by dividing the source file into code fragments and performing string pointer analysis on multiple code fragments, the input size of string pointer analysis can be effectively reduced.

[0173] One possible implementation also includes:

[0174] Rendering module 1005 is used to render a function call graph based on function call information.

[0175] In this embodiment, the inter-function call relationship is rendered into a function call graph for visualization, which helps programmers clearly understand the specific structure of the program, locate errors in the program more quickly, and optimize the code.

[0176] This application also provides a computing device; please refer to [link / reference]. Figure 11 , Figure 11 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. The computing device can be used to execute computer programs or computer instructions stored in memory to perform... Figure 4 , Figures 6 to 9 The methods in any of the embodiments shown can be referred to the relevant descriptions in the above method embodiments.

[0177] The communication device includes a processor 1101. Optionally, the communication device may also include a memory 1102 and a transceiver 1103.

[0178] This application also provides a computer program product including instructions that, when run on a computer, cause the computer to perform the above-described actions. Figure 4 , Figures 6 to 9 The method of any of the embodiments shown in the figures.

[0179] This application also provides a computer-readable storage medium, including computer instructions that, when executed on a computer, cause the computer to perform the actions described above. Figure 4 , Figures 6 to 9 The method of any of the embodiments shown in the figures.

[0180] This application also provides a chip device, including a processor for connecting to a memory and calling a program stored in the memory, so that the processor executes the above-described... Figure 4 , Figures 6 to 9 The method of any of the embodiments shown in the figures.

[0181] The processor mentioned above can be a general-purpose central processing unit, a microprocessor, an application-specific integrated circuit (ASIC), or one or more devices used to control the above. Figure 4 , Figures 6 to 9 An integrated circuit that executes the method of any of the embodiments shown above. The memory mentioned above may be read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions, such as random access memory (RAM).

[0182] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0183] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0184] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0185] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0186] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for determining function call information, characterized in that, include: Get the source file; Multi-level type analysis (MLTA) was performed on the source file to obtain the function call relationships; Perform string pointer analysis on the source file to obtain the string passing relationships; The function call relationship and the string transmission relationship are combined to obtain the function call information.

2. The method according to claim 1, characterized in that, The step of performing multi-level type analysis (MLTA) on the source file to obtain function call relationships specifically includes: The source file is analyzed for fixed-value usage to obtain the first sub-function call relationship; Perform MLTA on the source file to obtain the second sub-function call relationship; The function call relationship is obtained by combining the first sub-function call relationship and the second sub-function call relationship.

3. The method according to claim 1, characterized in that, The step of performing multi-level type analysis (MLTA) on the source file to obtain the first calling information specifically includes: The source file is analyzed for fixed-value usage to obtain the call relationship of the third sub-function; Based on the aforementioned third sub-function call relationship, identify the functions in the source file that do not have explicit call characteristics to be analyzed; Perform MLTA on the function to be analyzed to obtain the fourth sub-function call relationship; The function call relationship is obtained by combining the third sub-function call relationship and the fourth sub-function call relationship.

4. The method according to claim 1, characterized in that, The step of performing multi-level type analysis (MLTA) on the source file to obtain the first calling information specifically includes: Perform MLTA on the source file to obtain the fifth sub-function call relationship; Based on the aforementioned fifth sub-function call relationship, identify the functions to be analyzed in the source file for which call information is not explicitly provided; The function segment to be analyzed is subjected to a fixed-value usage analysis to obtain the call relationship of the sixth sub-function; The function call relationship is obtained by combining the fifth sub-function call relationship and the sixth sub-function call relationship.

5. The method according to any one of claims 1 to 4, characterized in that, The step of performing string pointer analysis on the source file to obtain the string passing relationship includes: Perform string pointer analysis on the source file to determine the information passed by the string pointers; Based on the transmitted information, the calculation process of the string is modeled; Based on the modeling results, the string transmission relationship is determined.

6. The method according to any one of claims 1 to 5, characterized in that, The step of performing string pointer analysis on the source file to obtain the string passing relationship specifically includes: Perform association analysis on the source files based on the Least Common Ancestor (LCA); Based on the correlation analysis results, the source file is split into multiple code snippets; String pointer analysis is performed on the multiple code snippets to obtain the string passing relationships.

7. The method according to any one of claims 1 to 6, characterized in that, After combining the function call relationship and the string transmission relationship to obtain the function call information, the method further includes: Render a function call graph based on the function call information.

8. The method according to any one of claims 1 to 7, characterized in that, The source file is in intermediate representation (IR) format.

9. A device for determining function call information, characterized in that, include: The acquisition module is used to acquire source files; The first analysis module is used to perform multi-level type analysis (MLTA) on the source file to obtain function call relationships; The second analysis module is used to perform pointer analysis on the source file to obtain the string passing relationship; The summary module is used to combine the function call relationship and the string transmission relationship to obtain function call information.

10. A computing device, characterized in that, Including the processor; The processor is configured to execute computer programs or computer instructions stored in memory to perform the method as described in any one of claims 1 to 8.

11. The computing device according to claim 10, characterized in that, It also includes the memory.

12. A computer program product containing instructions, characterized in that, When the instructions are executed by the computing device, the computing device performs the method as described in any one of claims 1 to 8.

13. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a computing device, cause the computing device to perform the method as described in any one of claims 1 to 8.

Images