Power grid terminal program vulnerability detection method based on dynamic modeling of control flow diagram

Abstract

The invention provides a power grid terminal program vulnerability detection method based on dynamic modeling of a control flow diagram. The method comprises the following steps: step 1, dynamic modeling of a terminal program control flow diagram; and step 2, program slicing based on the control flow and the data flow. According to the technical scheme, dynamic analysis and control flow graph modeling are combined, so that security vulnerabilities in a program can be identified and positioned more accurately.

Description

Technical Field

[0001] The invention relates to the technical field of power grid terminal programs, and in particular to a power grid terminal program vulnerability detection method based on control flow graph dynamic modeling. Background Art

[0002] Grid terminal programs play a vital role in modern power systems, so their security is crucial to grid stability and data security. Traditional vulnerability detection methods may have certain limitations, especially when dealing with complex grid terminal programs.

[0003] A key issue in firmware code control flow graph modeling is how to correctly obtain the target address of indirect transfer instructions, which is a problem that is difficult to solve using static control flow graph modeling methods.

[0004] The dynamic control flow graph modeling of firmware code is to get the control flow graph of the firmware program by running the program, obtaining the execution instruction process, dividing the program into basic blocks, and establishing the association relationship between blocks.

[0005] Dynamic control flow graph modeling is obviously limited by the execution branches of the program. If the condition of a branch cannot be met, that is, the branch is not executed, then the modeled control flow Figure 1 How to model all paths to the maximum extent possible is the focus of research on dynamic control flow graph modeling technology for firmware code. Currently, most dynamic control flow graph modeling technologies focus on solving the problem of incomplete path modeling from the perspective of how to obtain a complete input set. Among them, the input methods of dynamic control flow graph modeling are mainly divided into manual, random, and constraint condition solving methods.

[0006] The manual method is the initial input method for dynamic control flow graph modeling. It runs the target program in a debuggable environment. The debugger traverses all possible input values ​​based on his or her own experience and repeatedly executes the program, hoping to execute all paths of the program, thereby maximizing the modeling of a complete control flow graph. This method is determined by the level and experience of the analyst, has a low degree of automation, is time-consuming and labor-intensive, and cannot guarantee the comprehensiveness of path execution and the integrity of the input value set.

[0007] The random type belongs to the automatic input setting method, which is to automatically select input values ​​so that the program executes different paths. Compared with the method of manually giving input values, this method has a higher degree of automation, but the range of program input values ​​is usually very large. For example, if a target program has only one integer input variable x, on a computer with a 32-bit integer type, the input space size of the program is 232; if the program has two integer input variables (x, y), the input space size reaches 264. It can be seen that even if the target program is very small, it is quite complicated to randomly select some typical input values ​​in the huge input space and then model all paths. Therefore, under the condition of a large input space and random selection of input values, it is easy to have problems such as repeated modeling paths and inability to fully model all paths.

[0008] The constraint condition solving formula is a way to automatically determine the program input value based on the analysis results of the path constraint condition. This method analyzes the path constraint conditions at the branch nodes in the program execution path, finds the relationship between the conditions and the input variables, and thus determines the program input value. For ease of description, C language code is used for description, and the research object is firmware code. Among them, Figure 1 (a) is the target program P, Figure 1 (b) is the control flow subgraph of the target program P. Assuming that the input x of the program is 10, at the first branch, path A is executed; then at the next branch, path B is executed. At this point, there are still two unmodeled paths C and D. In this example, the reason why paths C and D are not visited is that there are no input values ​​that can satisfy the execution of these two paths, that is, the given input values ​​cannot satisfy the path constraints of the corresponding branch points. To model path C, the target program can be rolled back to the second branch point. Since the modeling of path C depends on the first two path constraints, the two path constraints x>3 and x<8 are conditionally parsed. It can be seen that the set of input values ​​that simultaneously satisfy the two path constraints is {4,5,6,7}. Select any number from them to reassign x, and then execute path C from the second branch point, and path C can be correctly modeled. By parsing the first path constraint, it can be obtained that the set of input values ​​that satisfy the execution of path D is {0,1,2,3}. By giving input values ​​and executing the program, path D can be modeled. In this way, by solving the constraints and obtaining the input values ​​that meet the path execution conditions, the corresponding path branches can be modeled.

[0009] The method of solving the given input value based on the constraint condition overcomes the inefficiency and blindness of the given input conditions in both manual and random ways, and significantly improves the efficiency of dynamic control flow graph recovery. However, the dynamic control flow graph recovery technology based on path constraint analysis strongly depends on the analysis results of the path constraint conditions. When the constraint condition is unsolvable, it is impossible to give an input value that satisfies the condition, and thus it is impossible to recover the corresponding conditional branch path.

[0010] Although the dynamic analysis method can effectively avoid the problem of difficulty in obtaining the target address of indirect transfer instructions, it also has the problem of over-reliance on program input, that is, there is a problem that the path execution may not be complete. For this reason, many researchers have carried out research on multi-path analysis technology based on dynamic analysis. Although multi-path analysis solves the problem of path coverage to a certain extent, it is heavily dependent on solving path constraints. When encountering complex and difficult to solve path conditions, there is a problem of low execution efficiency. Summary of the invention

[0011] In view of this, the purpose of the present invention is to provide a power grid terminal program vulnerability detection method based on control flow graph dynamic modeling, which can more accurately identify and locate security vulnerabilities in the program by combining dynamic analysis and control flow graph modeling.

[0012] To achieve the above object, the present invention adopts the following technical solution: a method for detecting power grid terminal program vulnerabilities based on dynamic modeling of control flow graph, comprising the following steps:

[0013] Step 1: Dynamic modeling of terminal program control flow graph;

[0014] Step 2: Program slicing based on control flow and data flow.

[0015] In a preferred embodiment, the step 1 is specifically based on path-driven dynamic modeling of the control flow graph; the target firmware program is placed in a controllable simulation debugging environment, and a path-driven method is used to dynamically simulate the execution of the target program, and the program is divided into modules according to the transfer target address and the transfer instruction type, and a logical association relationship between blocks is established, and finally a complete control flow graph is formed.

[0016] In a preferred embodiment, the basic process of path-driven execution is as follows: execute the target program instructions one by one in the simulator, and determine the type of each instruction executed. If it is a sequential instruction, continue to execute downward; otherwise, determine whether this branch instruction can be executed based on the current input and the value of the flag register. If it cannot be executed, save the transfer target address and mark the branch point in red. Otherwise, save the address of the next instruction of the branch instruction and mark the branch point in red. Red means that only one of the branches is executed and the current state is saved; execute along this branch path and mark according to the above method until all paths starting from this branch path are executed; when the execution is completed or the program terminates, check whether there are red branch points in the program; if so, fall back to the nearest red branch point, restore the state related to the branch node, point the instruction pointer to the unvisited path, mark the branch node in black, and then drive the execution of this path; repeat the above process until all edges are executed; when all conditional branch points are marked in black, it means that all paths of the program have been traversed, and the program execution is terminated at this time.

[0017] In a preferred embodiment, partial save and direct rollback strategies are used to save and restore the state; partial save means that for the first basic block of the program, all register and memory state values ​​are saved, and for subsequent basic blocks, at the last instruction of each basic block, the registers and memories to be modified in the subsequent basic block are searched, and the state values ​​of these registers and memories at the instruction are saved; direct rollback means that whenever rollback is needed, it is not a rollback of a single instruction, but a rollback to the last instruction of the previous basic block. It is necessary to directly write the register and memory value snapshot saved in the previous basic block back to the corresponding registers and memories to ensure the correctness of the program state, and then modify the PC value, so that the program can jump to other branch instructions to continue execution.

[0018] In a preferred embodiment, a recovery strategy is used to handle modeling exceptions; when a program error is found, the processing of the block is stopped and the block is marked as an error, then the process returns to the last branch node that has not been fully traversed, and the control flow recovery continues downward. When the block marked as an error is reached again, control flow recovery is continued to be attempted; if no error occurs, the disassembly error mark for the block is revoked; if an error occurs again and a new path is still reached, control flow recovery is continued to be attempted until all paths are traversed.

[0019] In a preferred embodiment, the step 2 specifically includes a binary program slicing algorithm based on a data flow equation;

[0020] Define slicing criteria: The slicing criteria of a program P is a tuple (i, V), where i is a statement in P and V is a subset of variables in P;

[0021] Define state trajectory: state trajectory of length k <t>k is a sequence of finite ordered pairs in the program P: <(n1,s1),...,(nk,sk)>, where ni is a node in P, si is a function that maps variables in V to values, and (ni,si) gives the value of the variable in V before executing ni.

[0022] Define the projection: <t>k = (t1, ..., t2) is a state trajectory, n is a node in the program P, s is a function that maps variables to values, and projection

[0023]

[0024] Where:

[0025] s|V——Limit s

[0026] In V;∈——empty;

[0027] Then, Proj(i,V)( <t>k)=Proj′(i,V)(t1)...Proj′(i,V)(tk);

[0028] Definition of program slicing: A program slice S of a program P based on the slicing criterion C = (i, V) is a subroutine that satisfies the following properties:

[0029] 1) S is obtained by deleting zero or more statements in program P;

[0030] 2) When P can stop under input I, its corresponding state trajectory is T, then S can also stop under input I, its corresponding state trajectory is T′, and it satisfies ProjC( <t>)=ProjC′(<T′> ), where C′=(succ(i),V), succ(i)=i when i itself is in S, otherwise, succ(i) is the successor in P that is closest to i and remains in S.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] 1) Accurate detection: Dynamic modeling can more accurately capture the dynamic behavior of a program at runtime and overcome problems that static analysis cannot solve, such as the uncertainty of the target address of indirect transfer instructions.

[0033] 2) Real-time update: The dynamically generated control flow graph reflects the control flow situation in actual operation and can be updated in real time to adapt to changes in program status and provide the latest security analysis.

[0034] 3) Comprehensive analysis: Combining dynamic and static analysis methods can provide a more comprehensive security assessment of power grid terminal programs and improve the accuracy and reliability of vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A firmware program fragment of a power terminal device and its corresponding control flow graph according to a preferred embodiment of the present invention, wherein (a) is a firmware code fragment, and (b) is a corresponding control flow graph;

[0036] Figure 2 A control flow graph dynamic modeling algorithm based on path driving according to a preferred embodiment of the present invention;

[0037] Figure 3 An example of a firmware code fragment flow chart of a preferred embodiment of the present invention;

[0038] Figure 4 It is a schematic diagram of an abnormal branch path control flow graph of a preferred embodiment of the present invention;

[0039] Figure 5 The program slice example code of the preferred embodiment of the present invention;

[0040] Figure 6 It is a CFG schematic diagram corresponding to the code of the preferred embodiment of the present invention. DETAILED DESCRIPTION

[0041] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0042] It should be noted that the following detailed descriptions are illustrative and are intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used in the present invention have the same meanings as those commonly understood by those skilled in the art to which the present application belongs.

[0043] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application; as used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or their combinations.

[0044] A power grid terminal program vulnerability detection method based on control flow graph dynamic modeling, reference Figure 1-6 , including the following steps:

[0045] Step 1: Dynamic modeling of terminal program control flow graph;

[0046] Step 2: Program slicing based on control flow and data flow.

[0047] Step 1 is as follows: Dynamic modeling of control flow graph based on path drive

[0048] (1) Algorithm Description

[0049] The basic idea of ​​the path-driven firmware code control flow graph recovery algorithm is as follows: place the target firmware program in a controllable simulation debugging environment, use a path-driven approach to dynamically simulate the execution of the target program, divide the program into modules according to the transfer target address and the transfer instruction type, and establish a logical relationship between blocks, and finally form a complete control flow graph. The core of the algorithm is path-driven execution. The basic process of path-driven execution is as follows: execute the target program instructions one by one in the simulator, and determine the type of each instruction executed. If it is a sequential instruction, continue to execute downward; otherwise, determine whether this branch instruction is based on the current input and the value of the flag register.

[0050] If it cannot be executed, save the transfer target address and mark the branch point in red. Otherwise, save the next instruction address of the branch instruction and mark the branch point in red (indicating that only one of the branches is executed and the current state is saved). Execute along this branch path and mark it according to the above method until all paths starting from this branch path are executed. When the execution is completed or the program terminates, check whether there are red branch points in the program. If so, fall back to the nearest red branch point, restore the state related to the branch node, point the instruction pointer to the unvisited path, mark the branch node in black, and then drive the execution of this path. Repeat the above process until all edges are executed. When all conditional branch points are marked in black, it means that all paths of the program have been traversed, and the program execution is terminated at this time. Figure 1 It is a firmware program and its corresponding control flow graph. The present invention uses the program as the target program and dynamically simulates the execution in the simulation operation platform to illustrate the target path driven execution process.

[0051] This code starts at 0x0030H and executes instructions sequentially. At 0x0036H, the first conditional branch instruction CJNE is scanned. The transfer target address is calculated based on the semantics of the conditional branch instruction and the value in the current CPU flag register. In this example, the value in register A is not equal to #02H, so the program will jump to 0x003DH. At the same time, the address of the instruction next to the CJNE instruction is saved, and this branch node is marked as a red node.

[0052] At this time, the program continues to execute from 0x003DH until the program runs to 0x0043H, encountering the second conditional branch instruction CJNE, and determining which branch path to execute. Since the value in register A is equal to #99H, the program will not jump, so it is necessary to save the jump target address and mark this branch node in red. At this time, the two conditional branch points at 0x003DH and 0x0043H are both marked in red, indicating that the branch paths corresponding to these two conditional branch points have not been completely traversed, that is, each branch point only executes one of the branch paths. Therefore, it is necessary to roll back the program to the nearest red branch point, restore the state of this branch point, assign the saved address to the instruction pointer, execute the instruction at 0x004CH, and then mark the branch node in black, indicating that both branches of the node have been visited. Next, the program goes back to the next nearest red branch point, which is the branch node at 0x0036H, restores the state of this branch node, assigns the next instruction address of the current CJNE instruction to the PC instruction pointer, and starts executing instructions from 0x0039H, marking the branch node black. The above steps are run continuously until all conditional branch points in the program are marked black.

[0053] The path-driven firmware code control flow graph recovery algorithm uses a depth-first traversal algorithm. The execution order of the binary target code program is pre-designed by the programmer. For reverse researchers, the execution order of the program is unknown. When executing to the program branch, the program decides whether to jump or execute sequentially based on the conditions, which is a natural driving mode for reverse analysis. The traversal is exactly the same as the strategy of the depth-first traversal algorithm. The detailed description of the algorithm is as follows: Figure 2 shown.

[0054] Algorithm 3.4 overcomes the problem of incomplete path recovery in existing dynamic control flow graph recovery methods through path-driven execution and state preservation and recovery. It should be pointed out that since the program control flow is an inherent property of the program itself, that is, the control flow is independent of the specific program input, path driving will not affect the correctness of the control flow graph recovery. Path-driven execution is implemented by setting the PC instruction pointer, and does not rely on specific inputs to drive the program to execute different paths, thus eliminating the need for costly path constraint analysis and avoiding the problem of being unable to recover the control flow graph when the path constraints are unsolvable.

[0055] (2) State preservation and recovery mechanism

[0056] The state preservation and restoration is particularly necessary for the processing of indirect transfer branch points. Since the indirect transfer target address is stored in registers or memory, if the current program does not jump to the transfer target address at the indirect transfer branch point and does not save the current register and memory state, then when the program is driven to this path later, it will cause the calculation of the wrong transfer target value, thereby restoring the invalid path. Therefore, the state preservation and restoration is an important strategy implemented in the path-driven execution algorithm. The core of path-driven execution is to drive the target firmware program to the unvisited branch. In order to ensure that each branch path is executed under its original state conditions after modifying the CPU PC value, the state of the system at the branch node must be saved during dynamic simulation execution. There are generally two ways to save: one is to save the entire memory and all register values ​​at the branch condition. This approach spends a lot of time on saving and restoring memory and register data, which will seriously affect the efficiency of dynamic execution; the other method is to record the register and memory values ​​before each instruction of the program modifies the register or memory from the beginning of the program execution, and restore them one by one in reverse order when it is necessary to roll back.

[0057] This method has a problem of recording depth. If the values ​​of registers and memories before each instruction is modified are recorded, the amount of data to be recorded is too large, and the problem of excessive memory space consumption will occur. At the same time, the recovery of each instruction will inevitably affect the efficiency of dynamic simulation execution. Therefore, we adopt the partial preservation and direct rollback strategy. Partial preservation means that for the first basic block of the program, all register and memory state values ​​are saved. For subsequent basic blocks, at the last instruction of each basic block, the registers and memories to be modified in the subsequent basic block are searched and the state values ​​of these registers and memories at the instruction are saved. Direct rollback means that whenever rollback is needed, it is not a single instruction rollback, but a rollback to the last instruction of the previous basic block. The register (including PC) and memory value snapshot saved in the previous basic block needs to be directly written back to the corresponding registers and memories to ensure the correctness of the program state. Then the PC value is modified, and the program can jump to other branch instructions to continue execution. This strategy adopts the idea of ​​partial preservation, reduces the storage amount and space requirements, and adopts direct rollback, which improves the efficiency of the algorithm compared with single instruction rollback.

[0058] (3) Modeling exception handling strategies

[0059] When the path driver is executed, the control flow of the program is modified by changing the PC value, without considering the damage to the program context caused by this modification. In fact, the condition for executing the branch path of the branch node has not changed. If the execution continues after the modification, the program may crash.

[0060] like Figure 3 The following is a control flow chart of a BIOS firmware code. In this program, 50H, 60H, 65H and 67H are the entrances of four different sub-functions. Addresses 70H to 7FH are data buffers. 70H stores the number of valid data starting from 71H. This program first stores the input of port P0 into the FLAG address, determines whether the value of FLAG is 30H, and generates two different branches a and b. Branch a stores the value 2 at [70H]; branch b stores the value 3 at [70H]. After several operations, the program compares the data in FLAG with 30H again to see if they are equal, and generates branches c and d. The operation performed by branch c is to store the entry addresses 60H and 67H of two sub-functions at [71H] and [72H] respectively; the operation performed by branch d is to store the entry addresses 50H, 65H and 67H of three sub-functions at [71H], [72H] and [73H] respectively; then, in block 8, a loop is used to call the sub-function corresponding to the data stored in the cache area.

[0061] According to the path-driven control flow graph recovery algorithm, Figure 4 As shown in the figure, if the value stored in FLAG is 30H when the program is executed, then at the branch point of program block a, branch d is executed normally. After restoring this path, the initial state of the branch point is restored at the conditional branch of block a, and the PC register is forcibly modified to drive the execution of branch c. At this time, the data in R0 is still 3, so the operation executed by branch c now is to obtain the entry address of the sub-function stored in [71H], [72H] and [73H], and call these functions in sequence. At this time, the program execution path is: block a→block b→block d→block e→block g→block f→block h→block i→block j→block k→block m→block n. The normal execution path of branch C should be: block a→block b→block d→block e→block g→block f→block h→block i→block j. That is, blocks k, m, and n represented by bold dotted lines in the figure are the result of forcibly changing the PC value and driving the execution of branch C. Among them, the memory content pointed to by 73H in block n is unknown, and the call cannot be executed, causing a program error.

[0062] For this situation, there are generally three processing strategies: abandonment strategy, conditional analysis strategy, and recovery strategy.

[0063] The abandonment strategy is to abandon the processing of the branch, roll back the program to the nearest branch point that is marked but not processed, and execute the branch path that has not been visited. Obviously, this method is the simplest, but it will reduce the integrity of the dynamic control flow graph.

[0064] The conditional analysis strategy is to analyze the branch conditions in the program, construct local branch condition expressions, and try to avoid destroying the program context when the controlled jump occurs. However, this strategy needs to be combined with variable dependency analysis, which increases the cost of system analysis.

[0065] We use a re-recovery strategy. The main idea of ​​the re-recovery strategy is to stop processing the block when a program error is found, mark the block as an error, and then return to the last branch node that has not been traversed completely, and continue to recover the control flow downward. When the block marked as an error is reached again, continue to try to recover the control flow; if there is no error, unmark the disassembly error for the block; if an error occurs again and there are still new paths to reach, continue to try to recover the control flow until all paths are traversed. Figure 3 As can be seen, after the program fails on the path of block 1 → block 3 → block 4 → block 5 → block 7 → block 8, block 8 is marked, and then an attempt is made to restore block 8 on the path of block 1 → block 2 → block 4 → block 5 → block 7 → block 8 to obtain the correct control flow information.

[0066] In step 2, the binary program slicing algorithm based on the data flow equation

[0067] Definition (Slicing Criteria): The slicing criterion for a program P is a tuple (i, V), where i is a statement in P and V is a subset of the variables in P.

[0068] Definition (state trajectory): a state trajectory of length k <t>k is a sequence of a finite number of ordered pairs in the program P: <(n1,s1),...,(nk,sk)>, where ni is a node in P, si is a function that maps variables in V (a subset of variables in P) to values, and (ni,si) gives the values ​​of the variables in V before executing ni.

[0069] Definition (projection): Let <t>k = (t1, ..., t2) is a state trajectory, n is a node in the program P, s is a function that maps variables to values, and projection

[0070]

[0071] Where:

[0072] s|V——Limit s

[0073] In V;∈——empty.

[0074] Then, Proj(i,V)( <t>k)=Proj′(i,V)(t1)...Proj′(i,V)(tk).

[0075] Definition (Program Slicing): A program slice S of a program P based on a slicing criterion C = (i, V) is a subprogram that satisfies the following properties:

[0076] 1) S is obtained by deleting zero or more statements from program P.

[0077] 2) When P can stop under input I, its corresponding state trajectory is T, then S can also stop under input I, its corresponding state trajectory is T′, and it satisfies ProjC( <t>)=ProjC′(<T′> ), where C′=(succ(i),V), succ(i)=i when i itself is in S, otherwise, succ(i) is the successor in P that is closest to i and remains in S.

[0078] Algorithm 2 gives the process based on the data flow equation

[0079] Inner slicing algorithm. Among them:

[0080] DEF[n] and REF[n] represent the definition subset and reference subset generated in statement n, respectively;

[0081] RC[i][n] represents the set of variables related to the slicing criterion C in program statement n. i is 0, which means the set of directly related variables. i greater than 0 means the set of indirectly related variables.

[0082] SC[i] represents program slicing, i represents the number of iterations;

[0083] BC[i] represents the partition that affects the slice statement in SC[i].

[0084] A set of branch statements; n∈PRE(m) means n is the predecessor of m;

[0085] INFL(b) represents the set of all statements on the path from b to the nearest backward dominating statement, excluding the endpoint. INFL(b) is not empty only when its direct successor is greater than or equal to 2.

[0086] The input of the algorithm is the original program P and the slicing criterion C = (i, V), and the output is the sliced ​​program SC. The algorithm first constructs the control flow graph CFG of the program P, and then calculates the definition subset and reference subset DEF[n] and reference subset REF[n] of each statement node in the control flow graph according to CFG, and then calculates the variable set RC[0][n] directly related to the slicing criterion C in each statement node n:

[0087]

[0088] That is, if the statement node n in CFG is the same as the statement i specified in the slicing criterion, then RC[0][n] is equal to all the variables in V. Otherwise, if the variables related to the slicing criterion in m are defined in the predecessor n of any statement m, then the variables related to the slicing criterion in n are the union of the variables in RC[0][m] referenced by n in RC[0][n] minus the variables defined by n. If the variables related to the slicing criterion in m are not defined in the predecessor n of any statement m, then the variables in RC[0][m] are directly copied to RC[0][n].

[0089] SC[0] represents the initial set of slices calculated based on directly related variables such as [0], SC[0] = {n|RC[0][m]∩DEF(n) = φ∧n∈PRE(m)}, that is, SC[0] contains all statements that define the variables of RC[0][m] in the predecessors of m.

[0090] After calculating RC[0][n] and SC[0], the algorithm enters an iterative loop, in which the conditional branch statement BC[i] that affects the slicing statement is first calculated (lines 15 to 19), and then the variables related to the variables of the conditional branch statement are added to RC[i+1][n] as indirect affecting variables (lines 25 to 27). In this way, RC[i+1][n] constitutes a set of direct and indirect variables related to C in program P.

[0091] Then, Sc[i+1] is calculated based on RC[i+1][n] (lines 28 to 33). Finally, if oldBC / =BC[i], it means that a new slicing statement has been added, and the iteration needs to continue until no new slicing statement is added. At this time, SC[i] is the program slice of P with respect to the criterion C.

[0092] According to the CFG diagram corresponding to the code, Figure 5 The step-by-step calculation process of the algorithm is as follows: (1) Calculate REF[n] and DEF[n], and the calculation results are shown in the 3rd and 4th columns of Table 1; (2) Calculate R(14,{i})[0][n] based on REF[n], DEF[n] and C=(14,i). The calculation process starts from the 14th line of code and calculates in the reverse direction of CFG, that is, first calculate R(14,{i})[0]

[14] ={i}, and then calculate R(14,{ i})[0][5], since DEF[5]=φ, the 5th line of code does not define the variables in R(14,{i})[0]

[14] ={i}, so R(14,{i})[0][5]=R(14,{i})[0]

[14] ={i}, then calculate R(14,{i})[0][4] and R(14,{i})[0]

[12] . Since DEF[4]∩R(14,{i})[ 0][5] / =φ, so R(14,{i})[0][4]=REF[4]∪(RC[0][5]\DEF(5))=φ, and DEF

[12] ∩R(14,{i})[0][5]=φ, so R(14,{i})[0]

[12] =R(14,{i})[0][5]={i}, and so on; (3) From the formula SC[0]={n|RC[0][m]∩DEF( n) / =φ∧n∈PRE(m)}, we can get S(14,{i})[0]={4,11}, because R(14,{i})[0][5]∩DEF(4) / =φ∧4∈PRE(5), R(14,{i})[0]

[12] ∩DEF(11) / =φ∧11∈PRE(12); (4) Calculate INFL(5)={7,9,11,12}, INFL(7)={9}, and the others are empty. (5) Since 11∈S(14,{i})[0] and 11∈INFL; (5), 5∈B(14,{i})[0]; (6) Calculate the related variable R(5,{i,n})[0][n] of conditional branch statement 5. The calculation process is similar to (2); (7) Take the union of R(14,{i})[0][n] and R(5,{i,n})[0][n] to form R(14,{i})[1][n]; (8) Calculate S(14,{i})[0] based on R(14,{i})[1][n]. The calculation process is similar to (3);

[0093] At this point, the first round of iteration ends. In the second round of iteration, since B(14,{i})[1]=B(14,{i})[0]={5}, the loop exits and the final slicing result S(14,{i})={4,5,11,12} is obtained.

[0094] When processing program slicing between procedures, the slicing criteria within the procedure need to be converted into slicing criteria within the corresponding function according to the function parameters of the calling function and the called function, and then calculated according to the slicing algorithm within the procedure. Table 1:

[0095] < / t> < / t> < / t> < / t> < / t> < / t> < / t> < / t>

Claims

1. A method for detecting power grid terminal program vulnerabilities based on dynamic modeling of control flow graphs, characterized in that: The following steps are involved: Step 1: Dynamic modeling of terminal program control flow graph; Step 2: Program slicing based on control flow and data flow.

2. A method for detecting power grid terminal program vulnerabilities based on control flow graph dynamic modeling according to claim 1, characterized in that: The step 1 is specifically to dynamically model the control flow graph based on path driving; the target firmware program is placed in a controllable simulation debugging environment, and the target program is dynamically simulated and executed in a path-driven manner, and the program is divided into modules according to the transfer target address and the transfer instruction type, and a logical association relationship between blocks is established, and finally a complete control flow graph is formed.

3. A method for detecting power grid terminal program vulnerabilities based on control flow graph dynamic modeling according to claim 2, characterized in that: The basic process of path-driven execution is as follows: execute the target program instructions one by one in the simulator. Each time an instruction is executed, its type is determined. If it is a sequential instruction, it continues to be executed; otherwise, it is determined whether this branch instruction can be executed based on the current input and the value of the flag register. If it cannot be executed, the transfer target address is saved and the branch point is marked in red. Otherwise, the next instruction address of the branch instruction is saved and the branch point is marked in red. Red means that only one of the branches is executed and the current state is saved. Execute along this branch path and mark it as above until all paths starting from this branch path are executed; when execution is completed or the program terminates, check whether there are red branch points in the program; if so, roll back to the nearest red branch point, restore the state related to the branch node, point the instruction pointer to the unvisited path, mark the branch node black, and then drive the execution of this path; repeat the above process until all edges are executed; when all conditional branch points are marked black, it means that all paths of the program have been traversed, and the program execution is terminated at this time.

4. A method for detecting power grid terminal program vulnerabilities based on control flow graph dynamic modeling according to claim 3, characterized in that: Partial save and direct rollback strategies are used to save and restore the state; partial save means saving all register and memory state values ​​for the first basic block of the program, and for subsequent basic blocks, searching for the registers and memories to be modified in the subsequent basic block at the last instruction of each basic block, and saving the state values ​​of these registers and memories at the instruction; direct rollback means that whenever rollback is needed, it is not a single instruction rollback, but a rollback to the last instruction of the previous basic block. The register and memory value snapshot saved in the previous basic block needs to be directly written back to the corresponding registers and memories to ensure the correctness of the program state, and then the PC value is modified, and the program can jump to other branch instructions to continue execution.

5. A method for detecting power grid terminal program vulnerabilities based on control flow graph dynamic modeling according to claim 3, characterized in that: A recovery strategy is used to handle modeling exceptions. When a program error is found, the processing of the block is stopped and the block is marked as an error. Then, the process returns to the last branch node that has not been fully traversed, and the control flow is restored downward. When the block marked as an error is reached again, control flow recovery is continued to be attempted. If no error occurs, the disassembly error mark for the block is revoked. If an error occurs again and a new path is still reached, control flow recovery is continued to be attempted until all paths are traversed.

6. A method for detecting power grid terminal program vulnerabilities based on control flow graph dynamic modeling according to claim 1, characterized in that: The step 2 specifically includes a binary program slicing algorithm based on a data flow equation; Define slicing criteria: The slicing criteria of a program P is a tuple (i, V), where i is a statement in P and V is a subset of variables in P; Define state trajectory: state trajectory of length k <t> k is a sequence of finite ordered pairs in the program P: <(n1,s1),...,(nk,sk)>, where ni is a node in P, si is a function that maps variables in V to values, and (ni,si) gives the value of the variable in V before executing ni.< / t> Define the projection: <t> k = (t1, ..., t2) is a state trajectory, n is a node in the program P, s is a function that maps variables to values, and projection< / t> Where: s|V——Limit s In V;∈——empty; Then, Proj(i,V)( <t> k)=Proj′(i,V)(t1)...Proj′(i,V)(tk);< / t> Definition of program slicing: A program slice S of a program P based on the slicing criterion C = (i, V) is a subroutine that satisfies the following properties: 1) S is obtained by deleting zero or more statements in program P; 2) When P can stop under input I, its corresponding state trajectory is T, then S can also stop under input I, its corresponding state trajectory is T′, and it satisfies ProjC( <t> )=ProjC′(<T′> ), where C′=(succ(i),V), succ(i)=i when i itself is in S, otherwise, succ(i) is the successor in P that is closest to i and remains in S.< / t>

Images