Demand-driven reusable binary pointer analysis method
By employing a demand-driven, reusable binary pointer analysis method, and by restoring the pointer type and pointer representation, efficient reuse of pointer analysis is achieved, solving the problem of low efficiency in existing technologies and improving analysis accuracy and efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING UNIV
- Filing Date
- 2026-01-19
- Publication Date
- 2026-05-12
AI Technical Summary
In existing technologies, pointer analysis is inefficient and it is difficult to significantly improve it while ensuring high analysis accuracy. Furthermore, downstream tasks rely on frequent calls to pointer analysis results.
A demand-driven, reusable binary pointer analysis method is adopted. The pointer type is restored by the variable usage, the pointer calculation related instructions are extracted, and the abstract interpretation is performed based on the pointer representation. The results are saved to the intermediate library, and the function to be analyzed is determined as needed, so as to realize the reuse of analysis results between processes.
It improves the overall efficiency of pointer analysis, reduces the complexity of subsequent abstract interpretation, reduces the number of functions that need to be analyzed, and maintains the high efficiency of large-scale program analysis.
Smart Images

Figure CN122020650A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of static program analysis and binary analysis, and in particular to a demand-driven, reusable binary pointer analysis method. Background Technology
[0002] Pointer analysis is a crucial foundational technique in binary program analysis. It primarily determines the set of memory objects that register and memory variables may point to at different program locations, enabling the reconstruction of a more complete control and data flow. It is a vital prerequisite for tasks such as control flow recovery, taint analysis, and vulnerability discovery. Many downstream tasks rely on on-demand pointer analysis. Due to its frequent invocation by downstream analysis tasks, the efficiency of pointer analysis is critical. Therefore, implementing demand-driven inter-procedural pointer analysis and effectively reusing the obtained analysis results to significantly improve the overall efficiency of pointer analysis while maintaining high analysis accuracy has become a pressing technical problem in the field of binary program analysis.
[0003] The key technologies used in this invention include reverse engineering and abstract interpretation. Reverse engineering obtains the assembly instructions, function information, and reference information of the binary file, resulting in an architecture-independent intermediate representation. Abstract interpretation models the execution results of instructions, thereby obtaining pointer representations of pointer variables.
[0004] This invention discloses a demand-driven, reusable binary pointer analysis method. First, by analyzing the usage of variables, the pointer type is restored within the procedure, and instructions related to pointer calculations are extracted. Then, based on the pointer representation, the execution results of the instructions are modeled, and an abstract interpretation is performed within the procedure to obtain a set of pointer representations for all pointer variables. The results are saved to an intermediate result library. Finally, based on the results of the in-procedure analysis, the function to be analyzed is determined as needed, obtaining different pointer representations of the target pointer variable in different functions. If a function is not analyzed, in-procedure analysis is triggered for that function first. Summary of the Invention
[0005] To address the problems existing in the prior art, this invention proposes a demand-driven reusable binary pointer analysis method. This method aims to significantly improve the overall efficiency of pointer analysis while maintaining high analysis accuracy by using on-demand analysis and effectively reusing the obtained analysis results. This invention is achieved through the following technical solutions.
[0006] A demand-driven, reusable binary pointer analysis method, characterized in that the method includes the following steps: S1 restores the pointer type within the procedure by analyzing how the variable is used, and extracts the instructions related to pointer calculation. S2, based on pointer representation, models the execution result of instructions, performs abstract interpretation within the process, obtains the pointer representation set of all pointer variables, and saves the result to the intermediate result library; S3, based on the results of the in-process analysis, determine the function to be analyzed as needed, and obtain the different pointer representations of the target pointer variable in different functions; if a function is not analyzed, then trigger the in-process analysis of steps S1 and S2 for that function first.
[0007] Furthermore, step S1 specifically includes the following steps: S11, Initial Classification: Traverse all instructions of the current function, mark the variables representing addresses of CALLIND, BRANCHIND, STORE, and LOAD instructions as pointer types and add them to the pointer variable set; add constants located in the program's legal address space to the pointer variable set; perform a conservative judgment on actual parameters and actual return values. If the judgment passes, mark them as pointer types and add them to the pointer variable set; if the judgment fails, mark them as non-pointer types and add them to the non-pointer variable set. S12, Backpropagation: Iterate through all INT_ADD, LOAD, COPY, and MULTIEQUAL instructions in the current function. If the output operand of an instruction is a pointer type, the input operand is checked. If the check passes, it is marked as a pointer type and added to the pointer variable set; otherwise, it is marked as a non-pointer type and added to the non-pointer variable set. The iteration terminates when the size of the pointer variable set does not increase compared to the previous iteration. S13, Forward Disambiguation: Iterate through all COPY and INT_ADD instructions of the current function. If the input operand is a non-pointer type, mark the output operand as a non-pointer type and remove it from the pointer variable set. The iteration terminates when the size of the non-pointer variable set does not increase compared to the previous iteration. S14, Collect pointer calculation related instructions: Traverse all INT_ADD, LOAD, COPY, MULTIEQUAL instructions in the current function. If the output operand of the instruction is a pointer type, add the instruction to the pointer calculation related instruction set.
[0008] Its beneficial effects are that it recovers the pointer variables in the process with high precision and filters out a large number of non-pointer variables, thereby reducing the complexity of the abstract state in the subsequent abstract interpretation and improving the analysis efficiency.
[0009] Furthermore, the method derives pointer types based on how variables are used, and achieves high-precision pointer type recovery by combining backpropagation and forward disambiguation.
[0010] Furthermore, step S2 specifically includes the following steps: S21, Initialize the pointer representation set: Traverse the set of pointer variables obtained in step S1. If the pointer variable is a stack pointer SP, a function parameter, or a function return value, set its pointer representation set to contain a unique SymbolPR; if the pointer variable is a constant, set its pointer representation set to contain a unique ConstantPR. S22, In-process abstract interpretation: Iterate through all COPY, MULTIEQUAL, LOAD, and INT_ADD instructions of the function. For the COPY instruction, set the pointer representation set of the output operands to the pointer representation set of the input operands. For the MULTIEQUAL instruction, set the pointer representation set of the output operands to the union of the pointer representation sets of the input operands. For the LOAD instruction, set the pointer representation set of the output operands to DerefPR obtained by dereferencing all pointer representations of the input operands. For the INT_ADD instruction, first model the offset based on the def-use chain, then set the pointer representation set of the output operands to PlusPR obtained by adding offset to all pointer representations of the input operands. The iteration terminates when the pointer representation set of all pointer variables has not changed compared to the previous iteration. S23, Scope analysis of STORE instructions: For each STORE instruction; starting from the program location of the STORE instruction, traverse all instructions according to the program's control flow. If another STORE instruction is encountered, and the set of pointer representations of the pointer variables corresponding to the STORE instruction is equal to the set of pointer representations of the pointer variables of the initial STORE instruction, then the initial STORE instruction is killed. If a LOAD instruction is encountered, it is collected. Starting from the output operand of the collected LOAD instruction, based on the def-use chain, obtain the set of all pointer variables that may be affected by the STORE instruction. S24, STORE semantic propagation: Iterate through all STORE instructions in the program. Assume the instruction semantics are *p=q, where the pointer representation of p is pr1 and the pointer representation of q is pr2. Iterate through the pointer representations of pointer variables in the scope of the STORE instruction. If a base such as DerefPR(pr1) is included, replace this base with pr2 and add the new pointer variable obtained after the replacement to the pointer representation set. The iteration terminates when the pointer representation set of all pointer variables has not changed compared to the previous iteration.
[0011] Its beneficial effect is that it obtains a set of pointer representations of all pointer variables within the process, which can be used to recover the control flow and data flow within the process, and can also be used for inter-process analysis to determine the function to be analyzed as needed.
[0012] Furthermore, the method performs pointer analysis within the process based on pointer representation of abstract domain and fixed-point iteration; performs scope analysis on the STORE instruction, improving the flow sensitivity involving memory variables; places the STORE instruction for unified processing at the end, and defines a replacement-based STORE instruction processing rule.
[0013] Furthermore, step S3 specifically includes the following steps: S31, Initialize the search queue: Assume that the target pointer variable is located in the function foo, and all pointers to the target pointer variable are represented by pr. Add the (foo,pr) tuple to the search queue. S32, Traverse the search queue: Traverse each tuple in the queue, process each tuple in the queue in turn, until the queue is empty; S33, determine the function to be analyzed as needed: For the tuple (foo, pr), determine the function to be analyzed based on the lowest-level base of pr; if the lowest-level base of pr is a formal parameter of the foo function, or a pointer to an actual return value of the foo function represents the base of pr, then the function that calls the foo function needs to be analyzed; if the lowest-level base of pr is a formal return value of the foo function, or a pointer to an actual parameter of the foo function represents the base of pr, then the function called by the CALL instruction needs to be analyzed; if the lowest-level base of pr is ConstantPR, then other functions that reference this constant need to be analyzed.
[0014] S34, Obtain the in-process analysis results: For the function to be analyzed determined in step S33, obtain the in-process analysis results of the function to be analyzed determined in step S33 from the intermediate result library. If it does not exist, trigger the in-process analysis. S35, Obtain the new pointer representation of the target pointer variable: For the tuple (foo, pr), obtain the new pointer representation through substitution: If the lowest-level base of pr is a formal parameter of the foo function, then replace the lowest-level base of pr with the pointer representation of the corresponding actual parameter; if the lowest-level base of pr is the formal return value of the foo function, then replace the lowest-level base of pr with the pointer representation of the corresponding actual return value; if the pointer representation of some actual parameter of the foo function is the base of pr, then replace this part of the base of pr with the pointer representation of the corresponding formal parameter in the called function; if the pointer representation of some actual return value of the foo function is the base of pr, then replace this part of the base of pr with the pointer representation of the corresponding formal return value in the called function; if the lowest-level base of pr is ConstantPR, then no substitution is performed. S36, Expand the search queue: Bind the function to be analyzed determined in step S33 with the new pointer representation obtained in step S35 to form a new tuple and add it to the search queue.
[0015] Its advantages are that the function to be analyzed is determined on demand, reducing the number of functions that need to be analyzed; the time complexity of inter-procedural analysis does not increase exponentially with the growth of the call chain, and it can still maintain high analysis efficiency when analyzing large-scale programs.
[0016] Furthermore, the method determines the function to be analyzed on demand based on the base relationship represented by pointers, and supports multi-level function calls through a breadth-first search-based traversal algorithm. Attached Figure Description
[0017] Figure 1 The schematic diagram illustrates the demand-driven reusable binary pointer analysis method described in the specific implementation.
[0018] Figure 2 The flowchart illustrates the requirement-driven reusable binary pointer analysis method described in the specific implementation. Detailed Implementation
[0019] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.
[0020] This embodiment provides a demand-driven, reusable binary pointer analysis method, see reference. Figure 1 , Figure 2 The method includes the following steps: S1, by analyzing the way variables are used, restores the pointer type within the procedure and extracts instructions related to pointer calculation. Step S1 specifically includes the following steps: S11, Initial Classification: Traverse all instructions of the current function and directly mark the following types of variables as pointer types and add them to the pointer variable set: variables used as indirect jump targets in CALLIND and BRANCHIND instructions; variables used to represent memory access addresses in STORE and LOAD instructions; constants located in the program's legal address space (such as global object addresses and string constant addresses). Since the true source of function arguments and the global semantics of the actual function return value (the operand input by the RETURN instruction) cannot be precisely known during the procedural analysis phase, for conservative reasons, pointer checks are also performed on the arguments and the actual return value: if the check passes, they are marked as pointer types and added to the pointer variable set; otherwise, they are marked as non-pointer types and added to the non-pointer variable set.
[0021] The failure to pass the judgment mainly corresponds to the following four typical scenarios: 1) Constants that are not located in the program's valid address space; 2) Output operands calculated using pure integer arithmetic instructions such as INT_MULT and INT_DIV; 3) Variables whose size is smaller than the machine word length and is clearly insufficient to hold an address; 4) Callee-saved register variables other than function parameters. These variables are usually irrelevant to the semantics of the program.
[0022] S12, Backpropagation: Iterates through the INT_ADD, LOAD, COPY, and MULTIEQUAL instructions in the current function. If the output operand of an instruction has already been marked as a pointer type, its input operand is evaluated: if the input operand meets the pointer determination condition, it is marked as a pointer type and added to the pointer variable set; otherwise, it is marked as a non-pointer type and added to the non-pointer variable set. This process continues to iterate until, after a certain iteration, the size of the pointer variable set no longer increases compared to the previous iteration, thus indicating that the pointer information has reached a stable state within the process.
[0023] S13, Forward Disambiguation: To avoid misjudgments due to over-conservatism, forward propagation is used to further eliminate pseudo-pointers. When iterating through the COPY and INT_ADD instructions in the function, if the input operand of an instruction is marked as a non-pointer type, its output operand should also be considered a non-pointer type and removed from the pointer variable set. The forward disambiguation process terminates when the size of the non-pointer variable set no longer increases after one iteration.
[0024] S14, Collect pointer calculation related instructions: Traverse the INT_ADD, LOAD, COPY, MULTIEQUAL instructions in the current function. If the output operand of the instruction belongs to the pointer variable set, it is considered that the instruction has participated in the generation, propagation or transformation of pointers, and it is added to the pointer calculation related instruction set.
[0025] S2, based on pointer representation, models the execution result of instructions, performs abstract interpretation within the process, obtains the pointer representation set of all pointer variables, and saves the result to the intermediate result library. Step S2 specifically includes the following steps: S21: Initialize the pointer representation set: Iterate through the set of pointer variables obtained in step S1: If the pointer variable is a stack pointer SP, a function parameter, or a function's formal return value (the output operand of the CALL instruction), then initialize its pointer representation set to contain only one SymbolPR to represent a symbol address unknown to the current function; if the pointer variable is a constant, then initialize its pointer representation set to contain only one ConstantPR to represent a definite constant address.
[0026] S22, In-process Abstract Interpretation: Iterate through the COPY, MULTIEQUAL, LOAD, and INT_ADD instructions in the function, and update the pointer representation set according to the instruction semantics: For the COPY instruction, directly set the pointer representation set of the output operand to the pointer representation set of the input operand; for the MULTIEQUAL instruction, set the pointer representation set of the output operand to the union of the pointer representation sets of all input operands to characterize the uncertainty of the control flow convergence point; for the LOAD instruction, set the pointer representation set of the output operand to the DerefPR obtained by dereferencing each pointer representation of the input operand; for the INT_ADD instruction, first perform backward analysis based on the def-use chain to model the range and source of the offset value, and then set the pointer representation set of the output operand to the PlusPR obtained by "+ offset" operation for each pointer representation of the input operand. When the pointer representation sets of all pointer variables have not changed after one iteration, the in-process abstract interpretation is considered to have reached a fixed point, and the iteration terminates.
[0027] S23, Scope Analysis of STORE Instructions: For each STORE instruction within a function, analyze the set of pointer variables it may affect. Starting from the program location of the STORE instruction, traverse subsequent instructions along the control flow: if another STORE instruction is encountered, and the pointer representation set of its corresponding pointer variable is the same as the pointer representation set of the starting STORE instruction, then the starting STORE instruction is considered to have been killed; if a LOAD instruction is encountered, record it as a potentially affected read operation. For all collected LOAD instructions, starting from their output operands, perform forward analysis propagation along the def-use chain to obtain the set of all pointer variables that may be affected by the STORE instruction.
[0028] S24, STORE Semantic Propagation: Iterate through all STORE instructions in the program. Assume the semantics of a STORE instruction is *p = q, where p corresponds to pointer representation pr1 and q corresponds to pointer representation pr2. Iterate through the set of pointer representations of pointer variables within the scope of this STORE instruction. If it contains a base of the form DerefPR(pr1), replace that base with pr2 and add the new pointer representation to the set. The process terminates when the set of pointer representations for all pointer variables remains unchanged after one iteration.
[0029] S3, based on the analysis results within the process, determines the function to be analyzed as needed, and obtains the pointer representation of the target pointer variable in different functions. Step S3 specifically includes the following steps: S31, Initialize the search queue. Assume the target pointer variable is located in the function foo, and denote all pointers to the target pointer variable as pr. Construct the tuple (foo, pr) and add it to the search queue.
[0030] S32, Traverse the search queue: Continuously remove tuples from the queue and execute steps S33 to S36 in sequence until the search queue is empty.
[0031] S33, determine the functions to be analyzed as needed. For the tuple (foo, pr), determine the functions that need further analysis based on the source of the lowest-level base of pr: if base is a formal parameter of foo, or a pointer to an actual return value of foo represents the base of pr, then the function calling foo needs to be analyzed; if base is a formal return value of foo, or a pointer to an actual parameter of foo represents the base of pr, then the function called by the corresponding CALL instruction needs to be analyzed; if base is ConstantPR, then all other functions that reference this constant need to be analyzed.
[0032] S34, Obtain the in-process analysis results of the function to be analyzed: For the function to be analyzed determined in step S33, query its in-process analysis results from the intermediate result library; if it does not exist, trigger the analysis process of step S1 and step S2 of the function, and store the results in the intermediate result library.
[0033] S35, Generate a new pointer representation: For the tuple (foo, pr), replace pr according to the function call and return relationship to obtain a new pointer representation: If the lowest base of pr is a formal parameter of foo, then replace it with the pointer representation of the corresponding actual parameter; if the lowest base of pr is the formal return value of foo, then replace it with the pointer representation of the actual return value; if a part of the base of pr corresponds to an actual parameter of foo, then replace it with the pointer representation of the corresponding formal parameter in the called function; if a part of the base of pr corresponds to the actual return value of foo, then replace it with the pointer representation of the corresponding formal return value in the called function; if the lowest base of pr is ConstantPR, then remain unchanged.
[0034] S36, Expand the search queue. Bind the function to be analyzed determined in step S33 with the new pointer representation obtained in step S35, generate a new tuple and add it to the search queue until all relevant paths are exhausted.
[0035] The above description is merely a preferred embodiment of the present invention, but the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention. Any simple modifications, equivalent changes, and alterations made by those skilled in the art to the above embodiments based on the technical essence of the present invention without departing from the principles and spirit of the present invention should be included within the protection scope of the present invention.
Claims
1. A demand-driven, reusable binary pointer analysis method, characterized in that, The method includes the following steps: S1 restores the pointer type within the procedure by analyzing how the variable is used, and extracts the instructions related to pointer calculation. S2, based on pointer representation, models the execution result of instructions, performs abstract interpretation within the process, obtains the pointer representation set of all pointer variables, and saves the result to the intermediate result library; S3, based on the results of the in-process analysis, determine the function to be analyzed as needed, and obtain the different pointer representations of the target pointer variable in different functions; if a function is not analyzed, then trigger the in-process analysis of steps S1 and S2 for that function first.
2. The demand-driven reusable binary pointer analysis method according to claim 1, characterized in that, Step S1 specifically includes the following steps: S11, Initial Classification: Traverse all instructions of the current function, mark the variables representing addresses of CALLIND, BRANCHIND, STORE, and LOAD instructions as pointer types and add them to the pointer variable set; add constants located in the program's legal address space to the pointer variable set; perform a conservative judgment on actual parameters and actual return values. If the judgment passes, mark them as pointer types and add them to the pointer variable set; if the judgment fails, mark them as non-pointer types and add them to the non-pointer variable set. S12, Backpropagation: Iterate through all INT_ADD, LOAD, COPY, and MULTIEQUAL instructions in the current function. If the output operand of an instruction is a pointer type, the input operand is checked. If the check passes, it is marked as a pointer type and added to the pointer variable set; otherwise, it is marked as a non-pointer type and added to the non-pointer variable set. The iteration terminates when the size of the pointer variable set does not increase compared to the previous iteration. S13, Forward Disambiguation: Iterate through all COPY and INT_ADD instructions of the current function. If the input operand is a non-pointer type, mark the output operand as a non-pointer type and remove it from the pointer variable set. The iteration terminates when the size of the non-pointer variable set does not increase compared to the previous iteration. S14, Collect pointer calculation related instructions: Traverse all INT_ADD, LOAD, COPY, MULTIEQUAL instructions in the current function. If the output operand of the instruction is a pointer type, add the instruction to the pointer calculation related instruction set.
3. The demand-driven reusable binary pointer analysis method according to claim 2, characterized in that, The method derives pointer types based on how variables are used, and achieves high-precision pointer type recovery by combining backpropagation and forward disambiguation.
4. The demand-driven reusable binary pointer analysis method according to claim 1, characterized in that, Step S2 specifically includes the following steps: S21, Initialize the pointer representation set: Traverse the set of pointer variables obtained in step S1. If the pointer variable is a stack pointer SP, a function parameter, or a function return value, set its pointer representation set to contain a unique SymbolPR; if the pointer variable is a constant, set its pointer representation set to contain a unique ConstantPR. S22, In-process abstract interpretation: Iterate through all COPY, MULTIEQUAL, LOAD, and INT_ADD instructions of the function. For the COPY instruction, set the pointer representation set of the output operands to the pointer representation set of the input operands. For the MULTIEQUAL instruction, set the pointer representation set of the output operands to the union of the pointer representation sets of the input operands. For the LOAD instruction, set the pointer representation set of the output operands to DerefPR obtained by dereferencing all pointer representations of the input operands. For the INT_ADD instruction, first model the offset based on the def-use chain, then set the pointer representation set of the output operands to PlusPR obtained by adding offset to all pointer representations of the input operands. The iteration terminates when the pointer representation set of all pointer variables has not changed compared to the previous iteration. S23, Scope analysis of STORE instructions: For each STORE instruction; starting from the program location of the STORE instruction, traverse all instructions according to the program's control flow. If another STORE instruction is encountered, and the set of pointer representations of the pointer variables corresponding to the STORE instruction is equal to the set of pointer representations of the pointer variables of the initial STORE instruction, then the initial STORE instruction is killed. If a LOAD instruction is encountered, it is collected. Starting from the output operand of the collected LOAD instruction, based on the def-use chain, obtain the set of all pointer variables that may be affected by the STORE instruction. S24, STORE semantic propagation: Iterate through all STORE instructions in the program. Assume the instruction semantics are *p=q, where the pointer representation of p is pr1 and the pointer representation of q is pr2. Iterate through the pointer representations of pointer variables in the scope of the STORE instruction. If a base such as DerefPR(pr1) is included, replace this base with pr2 and add the new pointer variable obtained after the replacement to the pointer representation set. The iteration terminates when the pointer representation set of all pointer variables has not changed compared to the previous iteration.
5. The demand-driven reusable binary pointer analysis method according to claim 4, characterized in that, The method performs pointer analysis within the process based on pointer representation of abstract fields and fixed-point iteration; performs scope analysis on STORE instructions, improving the flow sensitivity of memory variables; places STORE instructions for unified processing at the end, and defines replacement-based STORE instruction processing rules.
6. The demand-driven reusable binary pointer analysis method according to claim 1, characterized in that, Step S3 specifically includes the following steps: S31, Initialize the search queue: Assume that the target pointer variable is located in the function foo, and all pointers to the target pointer variable are represented by pr. Add the (foo,pr) tuple to the search queue. S32, Traverse the search queue: Traverse each tuple in the queue, process each tuple in the queue in turn, until the queue is empty; S33, Determine the function to be analyzed as needed: For the tuple (foo, pr), determine the function to be analyzed based on the lowest-level base of pr; if the lowest-level base of pr is a formal parameter of the foo function, or a pointer to an actual return value of the foo function represents the base of pr, then the function that calls the foo function needs to be analyzed; if the lowest-level base of pr is a formal return value of the foo function, or a pointer to an actual parameter of the foo function represents the base of pr, then the function called by the CALL instruction needs to be analyzed; if the lowest-level base of pr is ConstantPR, then other functions referencing this constant need to be analyzed. S34, Obtain the in-process analysis results: For the function to be analyzed determined in step S33, obtain the in-process analysis results of the function to be analyzed determined in step S33 from the intermediate result library. If it does not exist, trigger the in-process analysis. S35, Obtain the new pointer representation of the target pointer variable: For the tuple (foo, pr), obtain the new pointer representation through substitution: If the lowest-level base of pr is a formal parameter of the foo function, then replace the lowest-level base of pr with the pointer representation of the corresponding actual parameter; if the lowest-level base of pr is the formal return value of the foo function, then replace the lowest-level base of pr with the pointer representation of the corresponding actual return value; if the pointer representation of some actual parameter of the foo function is the base of pr, then replace this part of the base of pr with the pointer representation of the corresponding formal parameter in the called function; if the pointer representation of some actual return value of the foo function is the base of pr, then replace this part of the base of pr with the pointer representation of the corresponding formal return value in the called function; if the lowest-level base of pr is ConstantPR, then no substitution is performed. S36, Expand the search queue: Bind the function to be analyzed determined in step S33 with the new pointer representation obtained in step S35 to form a new tuple and add it to the search queue.
7. The demand-driven reusable binary pointer analysis method according to claim 6, characterized in that, The method determines the function to be analyzed on demand based on the base relationship represented by pointers, and supports multi-level function calls through a traversal algorithm based on breadth-first search.