A memory defect static detection method based on type region model

Abstract

The application provides a memory defect static detection method based on a type region model, first, function call graphs and control flow graphs of a program to be detected are obtained through front-end processing; then, a type region model is constructed based on the function call graphs and the control flow graphs, static analysis is carried out, and the model and the program state are updated after the analysis; and then, according to defect behaviors that can occur at a current program point and program state information carried by the static analysis, a detection process of a certain defect type is entered. Through the memory defect detection method based on the type region model, the application can accurately describe the state of the program, ensure the correctness of data flow information at most program points, can analyze deeper reasons for the occurrence of memory defects in detail, and designs corresponding defect detection rules to ensure sufficient detection of the defects and reduce false negatives and false positives.

Description

Technical Field

[0001] This invention relates to the field of software security and static program detection technology, specifically to a static memory defect detection method based on a type region model. Background Technology

[0002] Software defects are primarily introduced by human factors such as lax programming standards and lack of experience. If these defects are not identified in a timely manner, they will significantly increase maintenance costs as software development progresses. Some defects may lead to resource waste, system crashes, or even become entry points for hackers. In the information age, the scope and severity of software defects are unprecedented, with memory-related defects seriously jeopardizing the security and reliability of current software engineering. Memory-related defects mainly include: double-freeing, reuse after freeing, and memory leaks. These defects are the main causes affecting the stability, reliability, and security of current software. They not only cause serious economic losses to development companies but also threaten users' personal privacy and property security.

[0003] For different types of programs, current defect detection methods proposed by scholars can be mainly divided into two categories: dynamic detection methods and static detection methods. The main distinction lies in whether the program is run during detection. Dynamic detection methods are currently widely used software defect detection techniques in industry. This technique uses specific test cases to run the program and focuses on whether there are any anomalies during program execution or in the output results to determine if defects exist in the program. Dynamic detection methods rely on high-quality test cases to achieve high program path coverage. However, when the quality of test cases is insufficient, coverage is often low, resulting in too many missed detections. Static detection methods do not require running the program. Instead, they analyze the intermediate representation products of compilation, model the products, and interpret program behavior based on the operational semantics or syntax rules of the model, simulating the program's runtime state. Finally, the attributes of the program state are verified through designed rules to determine whether the program has related defects. Because static detection methods do not depend on the quality of test cases but analyze program control information and data information, they generally have relatively high coverage and a low missed detection rate.

[0004] Symbolic execution, a popular static analysis technique, emerged in the 1970s to detect unmet security properties in programs. This technique uses symbols to abstractly represent external input values ​​to the current program and begins program analysis based on this symbolic representation of the initial program state. The program state maintained during symbolic execution primarily consists of symbolic storage and path constraints obtained from program analysis. Symbolic execution can simultaneously explore different paths in the program, provide test cases for each path after analysis, and construct instances that lead to property conflicts using constraint solvers to detect related defects.

[0005] However, under current technology, static detection methods, especially symbolic execution-based static analysis techniques, suffer a sharp decline in analysis efficiency and accuracy due to program complexity, leading to missed or false positives in the detection results. Factors affecting program complexity mainly include variable types and operations. The former varies depending on the characteristics of different variable types, requiring careful consideration of information changes during analysis to ensure accuracy. The latter introduces complex variable relationships and some difficult-to-analyze operations, such as type conversions. Furthermore, the completeness of defect detection rules also affects defect detection performance. Summary of the Invention

[0006] The purpose of this invention is to provide a static memory defect detection method based on a type region model, which aims to address the shortcomings of current static detection methods mentioned in the background art, especially in terms of program state description and defect detection scheme design.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A static memory defect detection method based on a type region model includes the following steps:

[0009] S1. Obtain the preprocessing products of the program to be tested through front-end processing: function call graph and control flow graph;

[0010] S2. Construct a type region model based on the preprocessing products, perform static analysis, and update the model and program status after the analysis;

[0011] The program statements are analyzed sequentially based on the control structure in the control flow diagram.

[0012] S3. Memory defect detection based on type region model: Based on the possible defect behaviors of the current program point and the program state information carried by static analysis, the detection process of a certain defect type is entered.

[0013] Furthermore, the preprocessing output of the program is generated through the following front-end processing method:

[0014] S11. Scan the source code of the program to be tested, perform lexical analysis, syntax analysis and semantic analysis during the compilation stage, conduct a preliminary check on the program to determine whether there are lexical, syntactic or semantic errors, and at the same time perform macro expansion and conditional compilation to build an abstract syntax tree.

[0015] S12. Based on the structure of the abstract syntax tree, search for function declarations and function call statements to generate a function call graph; and encapsulate the control flow structure of the abstract syntax tree according to the control flow structure statement to construct a control flow graph.

[0016] Furthermore, it includes further processing of the preprocessed products: based on the control flow graph of the current program, each function declaration is recorded, and each function call statement is explored sequentially. When a function has a statement that jumps to the called function, the caller is taken as the predecessor node of the called function; this process is repeated to construct a topological sorting graph; at the same time, based on the cause and form of memory defects, each statement is classified in the control flow graph: assignment statements, function call statements, loop statements, and type conversion statements, and suspected points that may cause defects are marked; and the corresponding defect detection rules are registered in the analysis interface of the statements or positions where these suspected points are located. When the statement needs to be analyzed, the defect detection process will be entered at the same time as the interface is called to perform defect detection analysis.

[0017] Furthermore, the construction and static analysis of the type region model specifically include the following steps:

[0018] S21. Based on the control flow graph information, model each initially declared function variable and allocate a region: the region retains the type and value information of the current variable, and additionally records the state of the current variable for pointers and heap memory, while also recording the address of the variable during analysis;

[0019] S22. Initialize the state pool to be empty, and add the program state at the analysis entry point to the state pool;

[0020] S23. If the state pool is empty, the analysis ends; if the state pool is not empty, the analysis continues according to different selection strategies, with the default being breadth-first traversal, selecting a state from the state pool and continuing the program analysis.

[0021] S24. Based on the different types of statements in the control flow diagram, call the corresponding analysis interface to perform program analysis, and after updating the model and program state after analysis, end the current analysis stage and jump to step S25.

[0022] S25. For suspected points, call the corresponding defect detection rules for analysis; if there may be multiple suspected points with different defects, enter different defect detection rule processes respectively; after the detection is completed, if the analysis continues, jump to step S26, otherwise jump to step S23.

[0023] S26. After adding the current state to the state pool, proceed to step S23.

[0024] Furthermore, during the program analysis process:

[0025] For assignment statements, the analysis interface for different assignment statements is called directly to perform program analysis and update the model and program state.

[0026] For a function call statement, the function definition corresponding to the statement is invoked, and the contents of the function are inlined into the current analysis point; the statement is invoked to bind the actual and formal parameters and establish the context environment; the current function analysis depth is initialized, and the analysis begins after setting the depth limit, collecting path information, updating the model and state; at the same time, after the function exits, the constraint information and regions related to the end of the lifecycle variables are deleted, and information with side effects is recorded, and the information in the current context is updated;

[0027] For loop statements, check if the current loop condition is met. If not, skip the loop; otherwise, proceed to the loop body for analysis. Treat the path in the loop body as a conditional branch, select the current executable path as the analysis path, and update the model and program state. If the loop analysis exceeds four times, force exit the loop to prevent the analysis cost from increasing dramatically.

[0028] For type conversion statements, the converted expression value is described based on the constraints related to the expression value of the current constraint space and the constraint transitivity rules: the description of the constraints on the valid range of the expression value or symbol and the new value after conversion, especially the constraint description on the integer part after the forced truncation of symbolic floating-point numbers.

[0029] Furthermore, the memory defect detection specifically includes the following steps:

[0030] S31. Select a defect rule based on the defect type, convert the rule into a Boolean expression, and combine it into the path constraints of the current program state to form a set of verification conditions for detecting violations of a certain attribute.

[0031] S32. The verification condition is solved by the constraint solver. If the verification condition can be satisfied, jump to step S33; otherwise, jump to step S34.

[0032] S33. Generate warning information for defect points with current defective behavior: Record the defect type and the location of the current detection point and add it to the defect warning table. Generate program warning information after the analysis is completed. If the current defect is a critical defect, end the analysis; otherwise, jump to step S34.

[0033] S34. Update the status information and return to continue analysis.

[0034] As can be seen from the above technical solutions, the present invention, through a memory defect detection method based on a type region model, can accurately describe the state of the program with the help of the type region model, ensuring the correctness of data flow information at most program points, especially in the modeling of complex variables and type conversion operations, which is helpful for subsequent defect detection. At the same time, the present invention analyzes in detail the deeper causes of memory defects and designs corresponding defect detection rules to ensure the full detection of these defects and reduce false negatives and false negatives. Attached Figure Description

[0035] Figure 1 This is a flowchart of the steps of the static detection method for memory defects of the present invention;

[0036] Figure 2 This is a flowchart illustrating the static analysis of the present invention.

[0037] Figure 3 This is a flowchart illustrating the defect detection process of the present invention. Detailed Implementation

[0038] A preferred embodiment of the present invention will now be described in detail with reference to the accompanying drawings.

[0039] like Figure 1 The static memory defect detection method based on the type region model shown includes the following steps:

[0040] S1. Obtain the preprocessed product of the program to be tested through front-end processing.

[0041] This preferred embodiment performs front-end processing on the program to be tested using the following method: scanning the source code of the program to be tested, performing lexical analysis, syntax analysis, and semantic analysis during the compilation stage to conduct a preliminary check on the program and determine whether there are lexical, syntactic, or semantic errors; simultaneously performing macro expansion and conditional compilation, and building an abstract syntax tree; based on the structure of the abstract syntax tree, searching for function declarations and function call statements to generate a function call graph; and encapsulating the control flow structure statements of the abstract syntax tree to construct a control flow graph.

[0042] The control flow diagram described in this preferred embodiment is composed of basic blocks and connections between them. Each basic block records a series of statements, and there is only one entry point for any jump to the target basic block, and only one exit point for that basic block. When the control flow enters a basic block, a jump or exit will only occur when the end position of the basic block is reached.

[0043] S2. Construct a type region model based on the preprocessing products, perform static analysis, and update the model and program status after the analysis;

[0044] In practical operation, before constructing the type region model and performing static analysis, further processing of the preprocessing products is required: Based on the control flow diagram of the current program, record each function declaration and explore each function call statement in turn. When a function has a statement that jumps to the called function, the caller is taken as the predecessor node of the called function; the graph is constructed repeatedly to build a topological sorting graph; at the same time, based on the common causes and forms of memory defects, each statement is classified in the control flow diagram: assignment statements, function call statements, loop statements, and type conversion statements, and suspected points that may cause defects are marked; and the corresponding defect detection rules are registered in the analysis interface of the statements or positions where these suspected points are located. When the statement needs to be analyzed, the defect detection process will be entered at the same time as the interface is called to perform defect detection analysis.

[0045] The type region model described in this preferred embodiment is an abstract memory model. It analyzes the program based on the preprocessing product and accurately describes the program state during the analysis, especially the descriptions related to type conversion. Then, based on the control flow diagram and function call diagram, the program analysis start position is selected according to the function call diagram. This function is the first node in the topological sorting established by the function call diagram. After that, the program statements are analyzed sequentially according to the control structure in the control flow diagram.

[0046] Specifically, the construction of this type of region model involves establishing four mapping relationships and maintaining two sets of information to describe the program's state. The four mapping relationships include variable-to-region mapping, address-to-region mapping, region-to-region mapping, and region-to-stored-value mapping. These mappings provide information on the pointer relationships and values ​​between variables at any given time. The two sets of information include symbolic variable binding information and path constraint information. Maintaining these two sets of information describes the current program state. Variable binding information stores the values ​​of current variables, while path constraint information describes the conditions for reaching the current path. The information maintained by the program state is obtained based on the four mapping relationships of the model.

[0047] like Figure 2As shown, during program statement analysis, a type region model with rich expressive capabilities is used to characterize the program. Based on the control flow and data flow information provided by the control flow graph, the model information is updated for different program statements, or path conditions on basic block edges are collected and added to the current symbolic constraints. Specifically, the construction and static analysis of the type region model include the following steps:

[0048] S21. Based on the control flow graph information, model each initially declared function variable and allocate a region: the region retains the type and value information of the current variable, and additionally records the state of the current variable for pointers and heap memory, while also recording the address of the variable during analysis;

[0049] S22. Initialize the state pool to be empty, and add the program state at the analysis entry point to the state pool;

[0050] S23. If the state pool is empty, the analysis ends; if the state pool is not empty, the analysis continues according to different selection strategies, with the default being breadth-first traversal, selecting a state from the state pool.

[0051] S24. Based on the different types of statements in the control flow diagram, call the corresponding analysis interface to perform program analysis, and after updating the model and program state, end the current analysis stage and jump to step S25:

[0052] For assignment statements, the analysis interface for different assignment statements is called directly to perform program analysis and update the model and program state.

[0053] For function call statements, the function definition corresponding to the statement is invoked, and the contents of that function are inlined into the current analysis point. The statement binds the actual and formal parameters and establishes the context. The current function analysis depth is initialized, and an upper limit is set before analysis begins, collecting path information, updating the model and state. Simultaneously, after the function exits, constraint information and regions related to variables ending their lifecycle are deleted, and information with side effects is recorded, updating the information in the current context. In specific operations, when a function call statement is encountered, the function is first inlined and expanded, the current function access level is initialized to 0, and the upper limit is temporarily set to 4. This prevents overly complex functions (such as deeply recursive functions) from causing the analysis to get bogged down in the function for too long, consuming excessive time and resulting in reduced coverage.

[0054] For loop statements, check if the current loop condition is met. If not, skip the loop; otherwise, proceed to the loop body for analysis. Treat the path within the loop body as a conditional branch, select the currently executable path as the analysis path, and update the model and program state. Force the loop to exit after more than four iterations to prevent a significant increase in analysis cost. Treat loop statements as conditional statements for analysis, with a maximum number of iterations set to four. Similar to function call handling, this prevents loop analysis from taking too long or the loop from not terminating.

[0055] For type conversion statements, the converted expression value is described based on the constraints related to the expression value of the current constraint space and the constraint transit rules: the description of the constraints on the valid range of the expression value or symbol and the new value after conversion, especially the constraint description on the integer part after the forced truncation of the symbolic floating-point number; in specific operations, type conversion mainly occurs in the form of explicit (forced) and implicit (automatic) type conversion. When encountering an operation that will result in type conversion, this preferred embodiment uses constraint transit rules to describe the constraint information of the value after type conversion, so as to accurately track the data flow information after type conversion.

[0056] S25. For suspected points, call the corresponding defect detection rules for analysis; if there may be multiple suspected points with different defects, enter different defect detection rule processes respectively; after the detection is completed, if the analysis continues, jump to step S26, otherwise jump to step S23.

[0057] S26. After adding the current state to the state pool, proceed to step S23.

[0058] Memory defect detection based on type region model: Based on the possible defect behaviors of the current program point, static analysis is performed to carry program state information and enter the detection process of a certain defect type.

[0059] Specifically, such as Figure 3 As shown, the memory defect detection described in this preferred embodiment includes the following process:

[0060] S31. Select a defect rule based on the defect type, convert the rule into a Boolean expression, and combine it into the path constraints of the current program state to form a set of verification conditions for detecting violations of a certain attribute.

[0061] S32. The verification condition is solved by the constraint solver. If the verification condition can be satisfied, jump to step S33; otherwise, jump to step S34.

[0062] S33. Generate warning information for defect points with current defective behavior: Record the defect type and the location of the current detection point and add it to the defect warning table. Generate program warning information after the analysis is completed. If the current defect is a critical defect, end the analysis; otherwise, jump to step S34.

[0063] S34. Update the status information and return to continue analysis.

[0064] In practical operation, based on the three main types of memory defect causes and forms pointed out in the background technology, relevant occurrence point types can be defined. Specifically, relevant occurrence points are a type of suspected point considered as potentially containing defects, mainly including: initialization statement program points, assignment statement program points, program points where the scope is about to exit, and program points after function calls. These occurrence points are considered suspected points of memory defects. When the model carrying program state information reaches a suspected point, its attributes or conditions are added to the constraints maintained by the current program state according to the designed relevant defect detection rules, constructing verification conditions that violate program attributes, and then submitted to the constraint solver for judgment. If the condition is satisfyable, it means that a test case exists, which triggers the defect upon arrival. Otherwise, if the condition is unsatisfactory, the suspected point is safe.

[0065] The above-described embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A static detection method for memory defects based on a type region model, characterized in that, Specifically, the following steps are included: S1. Obtain the preprocessing products of the program to be tested through front-end processing: function call graph and control flow graph; Step S1 further includes further processing of the preprocessed product: according to the control flow diagram of the current program, record each function declaration and explore each function call statement in turn. When a function declaration has a statement that jumps to the called function, the caller is taken as the predecessor node of the callee. This process is repeated to construct a topological sorting graph; At the same time, based on the causes and forms of memory defects, each statement is classified in the control flow diagram: assignment statements, function call statements, loop statements, and type conversion statements, and suspected points that may cause defects are marked. And register the corresponding defect detection rules in the analysis interface of the statements or locations where these suspected points are located. When the statement needs to be analyzed, the defect detection process will be entered at the same time as the interface is called to perform defect detection analysis. S2. Construct a type region model based on the preprocessing products, perform static analysis, and update the model and program status after the analysis; Step S2 specifically includes the following steps: S21. Based on the control flow graph information, model each initially declared function variable and allocate a region: the region retains the type and value information of the current variable, and additionally records the state of the current variable for pointers and heap memory, while also recording the address of the variable during analysis; S22. Initialize the state pool to be empty, and add the program state at the analysis entry point to the state pool; S23. If the state pool is empty, the analysis ends; if the state pool is not empty, the analysis continues according to different selection strategies, with the default being breadth-first traversal, selecting a state from the state pool and continuing the program analysis. S24. Based on the different types of statements in the control flow diagram, call the corresponding analysis interface to perform program analysis, and after updating the model and program state after analysis, end the current analysis stage and jump to step S25. S25. For suspected points, call the corresponding defect detection rules for analysis; if there may be multiple suspected points with different defects, enter different defect detection rule processes respectively; after the detection is completed, if the analysis continues, jump to step S26, otherwise jump to step S23. S26. After adding the current state to the state pool, proceed to step S23. S3. Memory defect detection based on type region model: Based on the possible defect behaviors of the current program point and the program state information carried by static analysis, the detection process of a certain defect type is entered.

2. The static memory defect detection method based on a type region model according to claim 1, characterized in that, The preprocessing output of the program is generated through the following front-end processing method: S11. Scan the source code of the program to be tested, perform lexical analysis, syntax analysis and semantic analysis during the compilation stage, conduct a preliminary check on the program to determine whether there are lexical, syntactic or semantic errors, and at the same time perform macro expansion and conditional compilation to build an abstract syntax tree. S12. Based on the structure of the abstract syntax tree, search for function declarations and function call statements to generate a function call graph; Furthermore, the abstract syntax tree is encapsulated for control based on the control flow structure statements of the abstract syntax tree, and a control flow diagram is constructed.

3. The static memory defect detection method based on a type region model according to claim 1, characterized in that, During program analysis: For assignment statements, the analysis interface for different assignment statements is called directly to perform program analysis and update the model and program state. For a function call statement, the function definition corresponding to the statement is invoked, and the contents of that function are inlined into the current analysis point. This statement binds the actual and formal parameters and establishes the context environment; it initializes the current function's analysis depth, sets the upper limit of the depth, and then begins analysis, collecting path information, updating the model and state; simultaneously, after the function exits, it deletes constraint information and regions related to variables at the end of their lifecycle, records information with side effects, and updates the information in the current context. For loop statements, check if the current loop condition is met. If not, skip the loop; otherwise, proceed to the loop body for analysis. Treat the path in the loop body as a conditional branch, select the current executable path as the analysis path, and update the model and program state. If the loop analysis exceeds four times, force exit the loop to prevent the analysis cost from increasing dramatically. For type conversion statements, the converted expression value is described based on the constraints related to the expression value of the current constraint space and the constraint transitivity rules: regarding the valid range of the expression value or symbol and the constraints of the new value after conversion, the constraint description for the integer part after the forced truncation of the symbolic floating-point number.

4. The static memory defect detection method based on a type region model according to claim 1, characterized in that, The memory defect detection specifically includes the following steps: S31. Select a defect rule based on the defect type, convert the rule into a Boolean expression, and combine it into the path constraints of the current program state to form a set of verification conditions for detecting violations of a certain attribute. S32. The verification condition is solved by the constraint solver. If the verification condition can be satisfied, jump to step S33; otherwise, jump to step S34. S33. Generate warning information for defect points with existing defective behavior: Record the defect type and the location of the current detection point and add it to the defect warning table. Generate program warning information after the analysis is completed. If the current defect is a critical defect, end the analysis; otherwise, jump to step S34. S34. Update the status information and return to continue analysis.

Images