KR102195906B1 - Apparatus and Method for program analysis dynamically - Google Patents

Abstract

A program dynamic analysis apparatus and method are disclosed.
The program dynamic analysis apparatus according to an embodiment of the present invention includes a dynamic analysis unit for dynamically analyzing a binary program to obtain a call trace, and a taint of the binary program based on the call trace. A static analysis unit that generates a dependency graph by performing static analysis, and a dynamic reverse analysis unit that performs a dynamic reverse analysis on the binary program based on the dependency graph, and outputs a result of whether the binary program is related to the input. do.

Description

Apparatus and Method for program analysis dynamically}

The present invention relates to a program dynamic analysis apparatus and a method thereof, and more particularly, to a program dynamic analysis method and apparatus for performing dynamic reverse analysis after slicing a program through static analysis.

Binary program analysis is very important to understand the structure and execution flow of a program without depending on the source code. However, like all other analyzes, accurate program analysis takes a lot of time in proportion to the size of the program, and a simple analysis method that takes less time has a very small scope of application or a high probability of erroneous analysis results. . Therefore, research is needed to efficiently analyze binary programs.

Program dynamic analysis is widely used in security fields such as program vulnerability analysis and malicious code analysis. Among them, dynamic reverse analysis is used to determine whether a specific point in the program is related to the input of the program.

For conventional dynamic reverse analysis, there are ARM-Analyzer and VDT (Visual Data Tracer). However, this method takes a long time to analyze because the program must be executed, and if the analysis takes a long time, it may not be timely to deal with the patch or malicious code of the vulnerability.

In addition, when performing a dynamic reverse analysis of a binary program, the instruction trace is extracted and analyzed. In this case, the larger the size of the trace, the more time required for analysis is required. In actual commercial programs, since the amount of code in the program is large, the size of the trace is also increased, and the time required for analysis is increased. If it takes a long time to analyze a program, there is a disadvantage in that the response to the malicious code is slow or the vulnerability patch of the program is slow.

Accordingly, there is a need to develop a technology capable of performing dynamic analysis by reducing the size of a program execution instruction trace.

Korean Registered Patent Publication No. 10-1482073 (2006.04.24.)

The problem to be solved by the present invention is to provide a program dynamic analysis apparatus and method capable of performing dynamic analysis by reducing the size of a program execution instruction trace.

The problem to be solved by the present invention is not limited to the problem(s) mentioned above, and another problem(s) not mentioned will be clearly understood by those skilled in the art from the following description.

In order to solve the above problems, a program dynamic analysis apparatus according to an embodiment of the present invention includes a dynamic analysis unit that dynamically analyzes a binary program to obtain a call trace, and the binary program based on the call trace. A static analysis unit that generates a dependency graph by performing a static analysis on the taint of, and a result of whether it is related to the input of the binary program by performing a dynamic reverse analysis on the binary program based on the dependency graph It includes a dynamic reverse analysis unit that outputs.

Preferably, the static analysis unit performs a taint analysis through execution of the binary program, statically analyzes all instructions affected by each of the instructions that caused a crash to the binary program, You can analyze the risk of crash.

Preferably, the static analysis unit identifies arrival points of the instructions for each of the instructions that caused the plurality of crashes, finds a point at which the instruction is actually used among the arrival points, and relies on the result. It is generated as a graph, and after identifying a command capable of transferring control of a program from the dependency graph, it is possible to analyze the possibility of attacking the command that caused the crash.

Preferably, the static analysis unit is an analysis module within a function that inputs the address of a point where the contaminated data is written and performs intraprocedural analysis from a function having the point, and a system call inside the function of the current analysis point. It may include a function unit analysis module that checks whether there is present and performs interprocedural analysis to check whether there is a relationship with the input of the program.

Preferably, the analysis module in the function starts analysis after inserting the instruction at the point where the crash occurred into the set of contaminated instructions, and repeats the process of finding the instruction that used the instruction. Can be done.

Preferably, the inter-function analysis module checks whether there is a system call inside the function of the current analysis point, checks whether it is related to the input of the program, and, if the check result is related, based on the call trace. After finding all the functions that called the corresponding function (caller function), finding the calling point of the callee function in the Caller function, finding all points where the input of the callee function is put, and performing an inverse taint analysis on that point. .

Preferably, the dynamic reverse analysis unit may prun the dependence graph based on register values and memory information, and perform dynamic reverse analysis of the pruned dependence graph.

In order to solve the above problems, a program dynamic analysis method according to an embodiment of the present invention includes the steps of obtaining a call trace by dynamically analyzing a binary program, and the binary program data based on the call trace. Generating a dependency graph by performing a static analysis on a taint, performing a dynamic reverse analysis of the binary program based on the dependency graph, and outputting a result of whether the binary program is related to the input Includes.

Preferably, in the step of generating the dependency graph, inputting the address of the point where the contaminated data is written and performing intraprocedural analysis starting from the function having the point, the system inside the function of the current analysis point It may include the step of performing interprocedural analysis to check whether there is a call and check whether there is a relation to the input of the program.

According to the present invention, it is possible to improve the speed of dynamic analysis by performing dynamic analysis in a way to reduce the size of a program execution instruction trace.

In addition, since commands to be analyzed are extracted through static analysis before dynamic analysis of a program, the number of commands to be dynamically analyzed is reduced, so that dynamic analysis can be performed more quickly. In this way, by reducing the dynamic analysis time, it is possible to respond to vulnerabilities or malicious codes faster.

The effects of the present invention are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those skilled in the art from the following description.

1 is a diagram illustrating a program dynamic analysis apparatus according to an embodiment of the present invention.
2 is a block diagram of a subdivided dynamic reverse analysis unit shown in FIG. 1.
3 is an exemplary diagram for explaining Reaching-Definition analysis according to an embodiment of the present invention.
4 is an algorithm for explaining intraprocedural analysis according to an embodiment of the present invention.
5 is an exemplary diagram for explaining functional unit analysis according to an embodiment of the present invention.
6 is an exemplary diagram for explaining interprocedural analysis according to an embodiment of the present invention.
7 is an exemplary diagram for explaining a dependence graph used for static analysis and dynamic analysis according to an embodiment of the present invention.
8 and 9 are flowcharts illustrating a program dynamic analysis method according to an embodiment of the present invention.

In the present invention, various modifications may be made and various embodiments may be provided, and specific embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the present invention to a specific embodiment, and it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. In describing each drawing, similar reference numerals have been used for similar elements.

Terms such as first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. These terms are used only for the purpose of distinguishing one component from another component. For example, without departing from the scope of the present invention, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. The term and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

When a component is referred to as being "connected" or "connected" to another component, it is understood that it may be directly connected or connected to the other component, but other components may exist in the middle. Should be. On the other hand, when a component is referred to as being "directly connected" or "directly connected" to another component, it should be understood that there is no other component in the middle.

The terms used in the present application are used only to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In the present application, terms such as "comprise" or "have" are intended to designate the presence of features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, but one or more other features. It is to be understood that the presence or addition of elements or numbers, steps, actions, components, parts, or combinations thereof, does not preclude in advance.

Unless otherwise defined, all terms, including technical and scientific terms, used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in this application. Does not.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram for explaining a program dynamic analysis apparatus according to an embodiment of the present invention, FIG. 2 is a block diagram of a subdivided dynamic reverse analysis unit shown in FIG. 1, and FIG. 3 is a Reaching according to an embodiment of the present invention. -An exemplary diagram for explaining definition analysis, FIG. 4 is an algorithm for explaining intraprocedural analysis according to an embodiment of the present invention, and FIG. 5 is a diagram illustrating functional unit analysis according to an embodiment of the present invention. 6 is an exemplary diagram for explaining interprocedural analysis according to an embodiment of the present invention, and FIG. 7 is a dependency used for static analysis and dynamic analysis according to an embodiment of the present invention. It is an example diagram for explaining the graph.

Referring to FIG. 1, a program dynamic analysis apparatus 100 according to an embodiment of the present invention includes a dynamic analysis unit 110, a static analysis unit 120, and a dynamic reverse analysis unit 130.

The dynamic analysis unit 110 dynamically analyzes a binary program to obtain a call trace. Dynamic analysis is analyzing a program by executing a program, and may be a dynamic analysis of searching an execution path of a binary code. The call trace refers to a dynamic call graph of functions, and the dynamic call graph of functions represents an abstraction used for profiling a program during execution of the program. Profiling is necessary for understanding program behavior, detecting errors in programs and their sources, and analyzing program performance. In order to obtain an accurate dynamic call graph that traces all function calls in the program, the instrumentation of all functions in the program is required and can be used.

The static analysis unit 120 generates a dependency graph by performing static analysis on a taint source of a binary program based on the call trace obtained from the dynamic analysis unit 110. Here, the taint source may be a command that causes a crash in a binary program.

Since a binary program is composed of functions, and each function is composed of instructions, it is necessary to extract only the instructions necessary for analysis before dynamic analysis of the program. In other words, when performing a dynamic reverse analysis of a binary program, the instruction trace is extracted and analyzed. At this time, the larger the size of the trace, the more time required for analysis is required. In actual commercial programs, because the amount of code in the program is large, the size of the trace is also increased, and the time required for analysis is increased. If the analysis of the program takes a long time, the response to the malicious code may be delayed or the vulnerability patch of the program may be slow.

Accordingly, the static analysis unit 120 extracts only commands necessary for analysis through static analysis, and generates a dependency graph. That is, the static analysis unit 120 identifies reaching points of each instruction for each of the instructions that caused the crash (Def-Use Chaining), and among the identified arrival points, the corresponding instruction is actually used (Def-Use Chaining). ) And generate a dependency graph. In this case, the static analysis unit 120 may use a reaching definition analysis, which is a static analysis technique. Reaching-Definition analysis aims to find out how far the command defining a variable can affect, that is, how far it reaches. Therefore, the static analysis unit 120 extracts what instruction can be reached for each instruction through Reaching-Definition analysis, and analyzes the def-use chaining using the result. can do.

On the other hand, Taint analysis is used to know how certain data is propagated. It analyzes the flow of data along a general execution path. However, in static taint analysis, satisfactory analysis must be performed for all execution paths. In other words, when a branch such as a loop or conditional statement occurs, an analysis that satisfies all paths must be performed. The CFG of FIG. 3 is a program having branches with an if statement written in c language. Assuming that the variable a of command 1 is the tainted data, a spreads from command 6 to the variable r. Conversely, in command 7, the variable r is not affected by a. In static analysis, since the branch of the conditional statement does not know whether it will go to 6 or 7, we must say that r is tainted at the point of instruction 8 for safe analysis. Here, the Reaching Definition is an appropriate analysis for all paths, since satisfactory analysis results can be obtained. The results of Reaching Definition analysis are shown as In and Out of each basic block. As in the example, Reaching Definitnion analyzes that the definitions 6 and 7 arrive at both 8. Therefore, it is a suitable method for static taint analysis that must be analyzed conservatively.

This is also effective in reverse analysis. When tracking against variable r, r in 4 is affected by variable a or b. Like forward analysis, you need to track both a and b, not just one of a or b. Such an analysis can be over taint, but it must be done conservatively because the vulnerability should not be missed. Then, the static analysis unit 120 analyzes the Use-Def chain based on the Reaching Definition. That is, the static analysis unit 120 may perform a def-use chaining analysis using a reaching definition analysis result. For example, starting with the input data (Taint Source, crash point), def-use chaining is the relationship between when used in i1 among the definitions reachable to a certain command i1. Reflect in graph. As a result, the relationship of all the instructions affected by the crash is analyzed to complete the def-use graph. The nodes (vertex) included in the def-use graph may be instructions affected by the crash point.

When the dependency graph is generated, the static analysis unit 120 identifies a command capable of transferring control of a program from the dependence graph, and analyzes the possibility of an attack of the command causing the crash.

As described above, the static analysis unit 120 performs static analysis on the call trace obtained from the dynamic analysis unit 120 and outputs a result of whether the binary program is input and related.

That is, when the static analysis unit 120 receives the address of the vulnerable point and the dynamic call trace to the vulnerable address, it inputs the address of the point where the contaminated data is written, and performs intraprocedural analysis from the function where the point is located. Perform. Here, intra-function analysis may mean performing an inverse taint analysis based on Reaching Definition and Use-Def chaining. Inverse-taint analysis analyzes the reverse direction of program execution as to which program point contaminated data affects. When the intra-function analysis is completed, the static analysis unit 120 performs an interprocedural analysis. In other words, it checks whether there is a system call such as read() inside the function of the current analysis point, and checks whether it is related to the input of the program. If there is, the analysis is terminated, and if not, interprocedural analysis is performed by searching for the caller that called the function being analyzed. At this time, in the analysis between functions, analysis is performed based on the call trace obtained through actual execution. Call trace narrows the scope of analysis by allowing only the actually executed function to be analyzed when analyzing points that can cause weaknesses when analyzing between functions. If it is affected by a function argument, it finds the calling function of the function and performs intra-function analysis on the calling function. When the analysis in the function is finished, the relationship analysis with the input of the program and the analysis between the functions are repeated. If it is not related to the argument of the function, the analysis ends. And if the data affects the input of the function, an inverse taint analysis is performed on the function that calls the function. If it is affected by the result of a system call such as read(), it is determined that it is related to the input.

The static analysis unit 120 includes an intra-function analysis module 122 and a function unit analysis module 124.

The intra-function analysis module 122 inputs the address of a point where the contaminated data is written, and performs intraprocedural analysis from the function having the point. Here, the intra-function analysis performs an inverse taint analysis in which the instruction at the point where the crash occurred is inserted into the set of contaminated instructions, and then the analysis is started, and the process of finding the instruction that has influenced the instruction is repeated.

The function unit analysis module 124 checks whether there is a system call in the function of the current analysis point and performs an interprocedural analysis to check whether it is related to an input of a program. That is, the function unit analysis module 124 checks whether the result of the inverse taint analysis is related to the input of the function, and if the result of the check is related, the function that called the function (caller function) based on the call trace It finds all, finds the call point of the callee function in the Caller function, finds all the points where the input of the callee function is put, and performs inverse taint analysis on this point.

Specifically, because static analysis lacks information compared to dynamic analysis, the results of analysis are not elaborate. In particular, there is no information about indirect jumps in CFG, and due to call sensitivity, an unsophisticated analysis is performed. The function unit analysis module obtains indirect jump information through the actual call trace and allows only the path related to the actual vulnerability to be analyzed. The function unit analysis module uses the call trace obtained from the dynamic analysis unit for function unit analysis. By using call trace, only indirect jump information and execution path where the actual vulnerability has occurred can be analyzed.

Interprocedural Analysis is essential to know the source of contaminated data. A program consists of many functions. The system call related to the input is likely to be at the beginning of the program, but the data that the developer wants to observe can exist anywhere in the program. Therefore, in order to know the source of contaminated data, functional unit analysis is not optional, but essential.

The functional unit analysis is performed according to the algorithm shown in FIG. 6. First, do an inverse taint analysis within the function where the crash occurred. Check whether the result of inverse taint analysis is related to the input of the function. If relevant, find all the functions that called this function based on the call graph as in step 4. At this time, the call graph may be a dynamically obtained call graph. In the Caller function, find the call point of the callee function, find all the points where the power of the callee function is put, and perform an inverse taint analysis on this point. After inverse taint analysis, analysis is performed according to the situation defined in FIG. 6. If it has nothing to do with the input of the function, the analysis stops.

3 is an example of a static call graph and a crash in the'crashfunc' function. The ‘crashfunc’ function is called from func4 and func5. At this time, assuming that'func4' is only executed in the dynamically obtained call graph, assuming that'func4' is analyzed, the argument of the'crashfunc' function is the influence of the'eax' and'ecx' registers in the'func4' function Receive. And since these registers are affected by the values of the addresses pointed to by'ebp-4' and'ebp-8', and these addresses are arguments of the'func4' function, the same analysis for'func3' calling'func4' This is done.

When analyzing a function unit, it is also necessary to consider calling external library functions. In static analysis, information about the external library is insufficient, so it is impossible to know how the contaminated data spreads within the function. Therefore, because external library function calls must be analyzed conservatively, if there is an external function call, it is determined that all arguments of the corresponding function are contaminated.

As described above, since the static analysis unit 120 extracts commands necessary for analysis through static analysis before dynamic analysis of the program, the number of commands to be dynamically analyzed is reduced, so that the dynamic analysis can be performed more quickly.

The dynamic reverse analysis unit 130 performs a dynamic reverse analysis on the binary program based on the dependency graph generated by the static analysis unit 120, and outputs a result of whether the binary program is input and related.

After the static analysis is performed, the dynamic analysis apparatus 100 performs dynamic analysis once again based on the result of the static analysis. This is because static analysis has less information for analysis than dynamic analysis. For example, since information such as memory information and system call indicated by a register is small, inaccurate analysis may occur due to these parts when analyzing. Therefore, dynamic analysis is again performed after static analysis. However, if it is determined that there is no vulnerability from the result of static analysis, dynamic analysis is not performed.

The dynamic reverse analysis unit 140 performs an analysis based on the dependence graph obtained from the static analysis, which may be a graph generated by pruning the dependence graph generated in the static analysis as shown in FIG. 7. 7A is a Use-Def graph (dependency graph) obtained from static analysis, and red is not actually a Use-Def relationship, but is generated in this manner in static analysis. (b) is a graph for dynamic analysis based on (a). In dynamic analysis, the wrong Use-Def relationship such as red is removed. In static analysis, since the exact register value such as the memory value is not known, for the safety of analysis, it is not actually a use-def relationship, but it is sometimes defined as a use-def relationship. In dynamic analysis, it is possible to prune these things because the exact register values and memory information are known.

In this way, analysis is possible to alleviate the disadvantages of inaccuracy of static analysis and time-consuming analysis of dynamic analysis.

On the other hand, dynamic analysis of programs is widely used in security fields such as program vulnerability analysis and malicious code analysis. Among them, dynamic reverse analysis is used to determine whether a specific point in the program is related to the input of the program. However, dynamic analysis has the disadvantage that it takes a long time because the program must be executed. If the analysis takes a long time, it may not be timely to patch vulnerabilities or deal with malicious codes.

Accordingly, the program dynamic analysis apparatus 100 reduces analysis time by performing a dynamic reverse analysis, thereby enabling a faster response to a vulnerability or malicious code.

8 and 9 are flowcharts illustrating a program dynamic analysis method according to an embodiment of the present invention.

8 and 9, the dynamic analysis apparatus dynamically analyzes a binary program to obtain a call trace (S810).

After performing step S810, the dynamic analysis device generates a dependency graph by performing static analysis on the taint of the binary program based on the call trace (S820). At this time, the dynamic analysis apparatus identifies arrival points of instructions for each of the instructions that caused the crash, finds a point where the instruction is actually used among the arrival points, and generates the result as a dependency graph.

After performing step S820, the dynamic analysis device inserts the instruction at the point where the crash occurred into the set of contaminated instructions, inputs the address of the point where the polluted data is written, and performs intraprocedural analysis starting from the function at the point. It performs (S830). In other words. The dynamic analysis device performs reverse taint analysis within the function where the crash occurred.

When step S830 is performed, the dynamic analysis device determines whether the result of the inverse taint analysis is related to the input of the program (S840). That is, the dynamic analysis device checks whether there is a system call such as read() in the function of the current analysis point, and checks whether it is related to the input of the program.

If the determination result of step S840 is related, the dynamic analysis device analyzes the risk of crash (S850). That is, if it is related to the input of the program, it is determined that the crash is attackable. If it is determined that there is a possibility of an attack as described above, the dynamic analysis apparatus performs a dynamic reverse analysis of the binary program based on the dependency graph, and outputs a result of whether the binary program is related to the input.

If the determination result of step S840 is not related, the dynamic analysis apparatus performs inter-function analysis (S860) and performs step S840. In other words, if it is not related to the program input, interprocedural analysis is performed by finding the function that called the function being analyzed (Caller). At this time, in the analysis between functions, analysis is performed based on the call trace obtained through actual execution. Call trace narrows the scope of analysis by allowing only the actually executed function to be analyzed when analyzing points that can cause weaknesses when analyzing between functions. If it is affected by a function argument, it finds the calling function of the function and performs intra-function analysis on the calling function. After performing the intra-function analysis, similarly, the relationship analysis with the input of the program and the analysis between functions are repeated. If it is not related to the argument of the function, the analysis ends. And if the data affects the input of the function, an inverse taint analysis is performed on the function that calls the function. If it is affected by the result of a system call such as read(), it is determined that it is related to the input.

So far, the present invention has been looked at around its preferred embodiments. Those of ordinary skill in the art to which the present invention pertains will be able to understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments should be considered from an illustrative point of view rather than a limiting point of view. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

100: dynamic analysis device
110: dynamic analysis unit
120: static analysis unit
130: dynamic reverse analysis unit

Claims (9)

A dynamic analysis unit that dynamically analyzes the binary program to obtain a call trace;
A static analysis unit for generating a dependency graph including a plurality of nodes by performing a static analysis on a taint of the binary program based on the call trace; And
Performing pruning to remove a specific node from the dependency graph based on register values and memory information, and performing dynamic reverse analysis of the binary program based on the pruned dependency graph, and inputting the binary program Dynamic reverse analysis unit that outputs the result of the relationship
Including,
The specific node is a node corresponding to a relationship between the specific instruction and a definition not used for the specific instruction among a plurality of definitions that can reach a specific instruction. The method of claim 1,
The static analysis unit,
By performing a taint analysis through the execution of the binary program, all commands affected by each of the commands that caused a crash for the binary program are statically analyzed to analyze the risk of the crash. Program dynamic analysis device. The method of claim 2,
The static analysis unit,
For each of the instructions that caused the crash, the arrival points of the instructions are identified, the point where the instruction is actually used among the arrival points is found, the result is generated as a dependency graph, and the program is After identifying a command capable of transferring control rights, an attack possibility of the command causing the crash is analyzed. The method of claim 1,
The static analysis unit,
An intra-function analysis module that inputs an address of a point where contaminated data is written and performs intraprocedural analysis from a function having the point; And
A program dynamic analysis device comprising a function unit analysis module that checks whether there is a system call inside a function of a current analysis point and performs interprocedural analysis to check whether it is related to an input of a program. . The method of claim 4,
The analysis module in the function,
A program dynamic analysis device, characterized in that it performs an inverse taint analysis in which the instruction at the point where the crash occurred is inserted into the set of contaminated instructions, and then analysis starts, and repeats a process of finding a use instruction that affects the instruction. . The method of claim 4,
The functional unit analysis module,
It checks whether there is a system call inside the function of the current analysis point, checks whether it is related to the input of the program, and if it is related to the check result, the caller function that called the corresponding function is determined based on the call trace. A program dynamic analysis device, characterized in that after searching for all, finding a call point of the callee function in the Caller function, searching for all points to which the input of the callee function is put, and performing an inverse taint analysis on that point.
delete Dynamically analyzing a binary program by a dynamic analysis unit to obtain a call trace;
Generating a dependency graph by performing static analysis on the taint of the binary program based on the call trace by a static analysis unit; And
By performing pruning to remove a specific node from the dependency graph based on register values and memory information by a dynamic reverse analysis unit, and performing dynamic reverse analysis of the binary program based on the pruned dependency graph, Outputting a result of whether the binary program is related to the input
Including,
The specific node is a node corresponding to a relationship between the specific instruction and a definition not used for the specific instruction among a plurality of definitions that can reach a specific instruction. The method of claim 8,
The step of generating the dependence graph by the static analysis unit,
Inputting an address of a point where contaminated data is written by an analysis module in a function of the static analysis unit, and performing intraprocedural analysis from a function having the point; And
Including the step of performing an interprocedural analysis of checking whether there is a system call in the function of the current analysis point by the function unit analysis module of the static analysis unit, and whether it is related to the input of the program. Program dynamic analysis method characterized by.

Images