Code execution path identification method, system, device and medium for protocol software packet assembly process special for industrial control

Abstract

The application discloses a code execution path identification method, system, device and medium for a protocol software packet assembly process of industrial control, the method comprising: constructing a control flow graph of the protocol software of industrial control and all dependent libraries, and taking an upper calling function of a message sending class function as a target function to be analyzed; recursively identifying all sub-functions called by the target function to form a calling subset of the target function; analyzing the calling subset of all target functions in turn to obtain a definition dependency relationship at a function level; based on the definition dependency relationship at the function level and a function abstract of a non-system library function, forming a set of patch target addresses, and performing patch tracking on the set of patch target addresses to obtain a code execution path of the protocol software packet assembly process of industrial control. The application can significantly reduce the influence on the running of the protocol software of industrial control under the premise of ensuring analysis accuracy, and efficiently complete the automatic identification of the code execution path of the packet assembly process.

Description

Technical Field

[0001] This application relates to the field of industrial control system technology, and in particular to a method, system, device and medium for identifying code execution paths in the process of assembling industrial control dedicated protocol software. Background Technology

[0002] Current industrial control systems widely employ numerous proprietary protocols. These protocols typically lack publicly available documentation and their content is opaque, hindering security assessments and data collection for attack and defense against such protocols. Recent research has yielded results on reverse engineering industrial control protocols based on program behavior analysis. The core idea is to infer the protocol's field boundaries, meanings, and interaction logic by observing and analyzing the behavior of industrial control software when processing communication messages. In practical analysis, selecting the analysis path is crucial, encompassing both protocol unpacking and repackaging processes.

[0003] The starting point for analyzing the protocol unpacking process is clearly defined, typically the message reception position, making it easy to combine with program analysis methods such as taint analysis and symbolic execution. Existing research largely focuses on the analysis of the protocol unpacking process; however, the specific functions implemented by the two parties in industrial control protocol communication differ—for example, the logic download function is only initiated by the host computer to the controller. Analyzing only the protocol processing in a single direction makes it difficult to cover all message types of industrial control protocols.

[0004] Currently, research on protocol packet assembly process analysis is limited. The packet assembly process in industrial control software may originate from various events such as interface operations, response processing, and alarm triggering. Therefore, when analyzing the packet assembly process, it is difficult to automatically determine the starting point of the analysis and the actual code execution path. Existing methods often employ dynamic taint analysis based on extensive instruction instrumentation when analyzing the protocol packet assembly process. When the scale of industrial control protocol software is large, extensive instrumentation can reduce software operating efficiency and may even cause software malfunctions, communication timeouts, and other problems, seriously affecting analysis efficiency and the accuracy of results. Summary of the Invention

[0005] In view of this, this application provides a method, system, device and medium for identifying the code execution path in the process of assembling industrial control dedicated protocol software.

[0006] This application discloses a method for identifying the code execution path in the assembly process of industrial control dedicated protocol software, which includes:

[0007] Step 1: Identify the calling conventions of all functions in the industrial control dedicated protocol software and its dependent libraries, and divide the calling conventions into non-system library function calling conventions and system library function calling conventions; the calling conventions include function calling conventions and function prototypes;

[0008] Step 2: Based on the system library function calling convention, construct the function summary of the system library function; the function summary of the system library function is used to determine which input parameters affect the return value in the system library function calling scenario;

[0009] Step 3: Construct the control flow graph of the industrial control dedicated protocol software and all dependent libraries. Based on the reference relationship of the message sending class function in the control flow graph, take the upper-level calling function of the message sending class function as the target function to be analyzed. According to the calling relationship of the target function in the control flow graph, recursively identify all its called sub-functions to form the calling subset of the target function.

[0010] Step 4: Based on the function summaries of system library functions, the static reachability definition analysis method is used to analyze the call subsets of all target functions in turn to obtain the function-level definition dependencies; based on the function-level definition dependencies, the function summaries of non-system library functions are obtained.

[0011] Step 5: Based on function-level definition dependencies and function summaries of non-system library functions, trace the upper-level definitions of message transmission buffer parameters of message transmission class functions to form an instrumentation target address set;

[0012] Step 6: Perform instrumentation tracing on the instrumentation target address set to obtain the code execution path of the industrial control dedicated protocol software assembly process.

[0013] Further, step 2 includes:

[0014] Based on the system library function calling specification, the variable identifiers of the input parameters and function return values ​​are identified. The variable identifiers of the input parameters and function return values ​​are all temporary variables, registers, or memory addresses.

[0015] Based on the fact that all input parameters of a function affect its return value, construct a function summary for the system library functions;

[0016] For functions whose return values ​​are unrelated to the input parameters or whose input parameters have additional relationships, the function summary of the system library functions is set manually.

[0017] For system and exception handling functions compiled under the Windows platform, the analysis of the system and exception handling functions is skipped by manually setting a blacklist, that is, the function summary of the corresponding system library function is not built for them.

[0018] Further, step 4 includes:

[0019] Step 41: For the subset of calls to the target function, perform function-level reachability analysis, starting from the leaf node functions and proceeding upwards, to construct function-level definition dependencies. Leaf node functions should not contain any calls to other non-system library functions. During the construction of function-level definition dependencies, when system library function calls occur, determine which input parameters affect the return value of the system library function based on its function summary. The root node of the call subset is the target function itself; leaf node functions belong to the subset of calls to the target function.

[0020] Step 42: Denote all IR instructions in the objective function as a set. All definitions are denoted as sets. Then the function-level definition dependencies are represented as mapping relationships. For any IR command , In order to All definitions of reachable from, Representation; set It consists of several IR instructions, and is a collection It consists of several definitions, each consisting of a variable identifier and an IR instruction that generates that variable identifier; where the variable identifier can be a temporary variable, a register, or a memory address; and the IR instruction is an intermediate layer instruction used to uniformly describe the semantics of the program.

[0021] Step 43: Identify the variable identifiers of the input parameters and return values ​​of non-system library functions based on the non-system library function calling convention, and identify which input parameters affect the return value based on the function-level definition dependencies, thus obtaining the reachability mapping between the return value and the input parameters. The variable identifiers for both input parameters and return values ​​are temporary variables, registers, or memory addresses; reachability mapping. Used to describe which input parameters affect the return value;

[0022] Step 44: Map based on reachability relations Construct function summaries for non-system library functions.

[0023] Further, step 43 includes:

[0024] Input: Function-level definition dependencies Definition of the return value to be tracked ;

[0025] Initialize a work queue, represented as and will define Add it to the work queue;

[0026] Initialize an empty set, denoted as This is used to record definitions that have been processed.

[0027] Initialize an empty mapping structure, represented as , used to define The variable identifier is mapped to the set of input parameters associated with it;

[0028] right Perform iterations, when When not empty, each iteration starts from Take a definition from the middle, and use it as express;

[0029] judge Has it been recorded? In the middle, if Recorded in If the current iteration is skipped, then skip the current iteration; otherwise, skip the current iteration. join in ;

[0030] Get IR commands, to Indicates that calling Get All definitions of reachable from a given location are represented as , This indicates the definition dependency at the function level. IR command query All definitions of reachable;

[0031] right Perform iterations, and express the definition in each iteration as follows: Each iteration will join in ;

[0032] judge Check if the variable identifier is the same as the variable identifier of the input parameter; if so, update. In definition Add to the set of variable identifier mappings Variable identifier;

[0033] until Until it is empty;

[0034] Output: A description of the definition of the return value to be tracked. Reachability mapping with input parameters .

[0035] Further, step 44 includes:

[0036] Identify the basic blocks containing return instructions in the control flow graph of non-system library functions, and extract the variable identifiers for all return values; the return instruction is the function termination instruction; in reachability mapping... The function retrieves the input parameters that affect the variable identifier of each return value, binds the return value with all the retrieved input parameters, and forms a function summary of the non-system library function.

[0037] Further, step 5 includes:

[0038] Identify all definitions affecting the message transmission buffer at the global program level. Starting with the target function, based on function-level definition dependencies and function summaries of non-system library functions, trace the upper-level definitions of the message transmission buffer parameters of message transmission class functions. If the upper-level definition ultimately comes from external parameters, then take all upper-level call functions of the target function in the control flow graph as new target functions in turn, and repeat steps 3 and 4 to identify call subsets and analyze reachability definitions for the new target functions until there are no upper-level call functions, or the upper-level definition of the message transmission buffer parameters is generated inside the function. Record all upper-level definitions during the analysis process; upper-level definitions are the definitions that affect the message transmission buffer.

[0039] For all instruction addresses that generate upper-level definitions, record the entry address of the basic block in which it resides, forming an instrumentation target address set.

[0040] Further, step 6 includes:

[0041] Based on the DymanoRIO dynamic instrumentation framework, instrumentation tracking is performed on the instrumentation target address set. During the operation of the industrial control dedicated protocol software, the trigger sequence of the instrumented instructions and the execution context at the time of triggering are recorded. The execution context includes the call stack, thread information, and register information.

[0042] The sequence of basic blocks triggered by the same thread during a single message transmission, as observed by instrumentation, is recorded as the code execution path during message construction. The set of all code execution paths is the code execution path of the industrial control dedicated protocol software package assembly process.

[0043] This application also discloses a code execution path generation system for the industrial control dedicated protocol software assembly process, which implements the above-mentioned code execution path identification method for the industrial control dedicated protocol software assembly process, comprising:

[0044] The calling convention segmentation module is used to identify the calling conventions of all functions in industrial control dedicated protocol software and its dependent libraries, and divides the calling conventions into non-system library function calling conventions and system library function calling conventions; the calling conventions include function calling conventions and function prototypes;

[0045] The function summary construction module for system library functions is used to construct function summaries of system library functions based on the system library function calling specification. The function summary of system library functions is used to determine which input parameters affect the return value in system library function calling scenarios.

[0046] The subset construction module is called to construct the control flow graph of the industrial control dedicated protocol software and all dependent libraries. Based on the reference relationship of the message sending class function in the control flow graph, the upper-level calling function of the message sending class function is taken as the target function to be analyzed. According to the calling relationship of the target function in the control flow graph, all its called sub-functions are recursively identified to form the calling subset of the target function.

[0047] The module for obtaining function summaries of non-system library functions is used to obtain function summaries of non-system library functions based on function summaries of system library functions. It employs a static reachability definition analysis method to analyze the call subsets of all target functions sequentially to obtain function-level definition dependencies; based on the function-level definition dependencies, it obtains function summaries of non-system library functions.

[0048] The instrumentation target address set acquisition module is used to trace the upper-level definition of the message sending buffer parameters of message sending class functions based on function-level definition dependencies and function summaries of non-system library functions, and form an instrumentation target address set.

[0049] The code execution path acquisition module is used to instrument the target address set and obtain the code execution path of the industrial control dedicated protocol software assembly process.

[0050] This application also discloses an electronic device, including a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the method described above.

[0051] This application also discloses a computer-readable storage medium comprising a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described above.

[0052] By adopting the above technical solution, this application has the following advantages: Existing automated reverse engineering methods for industrial control system (ICS) dedicated protocols based on program behavior analysis primarily employ dynamic taint analysis based on large-scale instruction monitoring for the analysis of the protocol assembly process. When the ICS dedicated protocol software is large-scale, large-scale taint propagation instruction instrumentation can affect the normal operation of the software. This application proposes a code execution path identification method for the ICS dedicated protocol software assembly process. This method uses static reachability definition analysis combined with a dynamic instrumentation framework to automatically identify the code execution path of the assembly process. The instrumentation scale is smaller and the instrumentation scope is more focused. While ensuring analysis accuracy, it significantly reduces the impact on the operation of the ICS dedicated protocol software. Therefore, it can efficiently complete the automated identification of the code execution path of the assembly process without interfering with the normal operation of the software, providing reliable support for protocol research and automated reverse engineering of ICS dedicated protocol software. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0054] Figure 1 This is a schematic diagram illustrating an application scenario of the industrial control dedicated protocol software according to an embodiment of this application;

[0055] Figure 2 This is a flowchart illustrating a method for identifying the code execution path during the assembly process of industrial control dedicated protocol software, according to an embodiment of this application. Detailed Implementation

[0056] The present application will be further described in conjunction with the accompanying drawings and embodiments. The described embodiments are only some, not all, of the embodiments of the present application. All other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of the present application.

[0057] Industrial control proprietary protocols are control protocols implemented independently by each industrial control system manufacturer. They are primarily used in the communication systems between the manufacturer's proprietary protocol software and the controller. For example... Figure 1 As shown, in the industrial control communication system, the process monitoring layer includes a host computer node, which is mainly used to monitor the operating status of the industrial site, collect data, and manage operations. The field control layer includes industrial switches and controllers, which are mainly used to execute specific control logic and interact with field devices. The industrial control dedicated protocol software runs in the host computer, and the host computer, industrial switches, and controllers exchange data through the industrial control dedicated protocol.

[0058] See Figure 2 This application provides an embodiment of a method for identifying the code execution path in the process of assembling industrial control dedicated protocol software, which includes:

[0059] Step 1: Identify the calling conventions of all functions in the industrial control dedicated protocol software and its dependent libraries, and divide the calling conventions into non-system library function calling conventions and system library function calling conventions; the calling conventions include function calling conventions and function prototypes;

[0060] Step 2: Based on the system library function calling convention, construct the function summary of the system library function; the function summary of the system library function is used to determine which input parameters affect the return value in the system library function calling scenario;

[0061] Step 3: Construct the control flow graph of the industrial control dedicated protocol software and all dependent libraries. Based on the reference relationships of message sending functions (e.g., "send", "sendto", "WSASend") in the control flow graph, take the upper-level calling functions of the message sending functions as the target functions to be analyzed. According to the calling relationship of the target functions in the control flow graph, recursively identify all the sub-functions it calls, forming a subset of the target function's calls.

[0062] Step 4: Based on the function summaries of system library functions, the static reachability definition analysis method is used to analyze the call subsets of all target functions in turn to obtain the function-level definition dependencies; based on the function-level definition dependencies, the function summaries of non-system library functions are obtained.

[0063] Step 5: Based on function-level definition dependencies and function summaries of non-system library functions, trace the upper-level definitions of message transmission buffer parameters of message transmission class functions to form an instrumentation target address set;

[0064] Step 6: Perform instrumentation tracing on the instrumentation target address set to obtain the code execution path of the industrial control dedicated protocol software assembly process.

[0065] Optionally, step 2 includes:

[0066] Based on the system library function calling specification, the variable identifiers of the input parameters and function return values ​​are identified. The variable identifiers of the input parameters and function return values ​​are all temporary variables, registers, or memory addresses.

[0067] Based on the fact that all input parameters of a function affect its return value, construct a function summary for the system library functions;

[0068] For functions whose return values ​​are unrelated to the input parameters or whose input parameters have additional relationships, the function summary of the system library functions is set manually.

[0069] For system and exception handling functions compiled under the Windows platform (such as "__security_init_cookie", "__security_check_cookie", "_SED_proglog", etc.), the analysis of the system and exception handling functions is skipped by manually setting a blacklist, that is, the function summary of the corresponding system library function is not built for them.

[0070] Optionally, step 4 includes:

[0071] Step 41: For the subset of calls to the target function, perform function-level reachability analysis, starting from the leaf node functions and proceeding upwards, to construct function-level definition dependencies. Leaf node functions should not contain any calls to other non-system library functions. During the construction of function-level definition dependencies, when system library function calls occur, determine which input parameters affect the return value of the system library function based on its function summary. The root node of the call subset is the target function itself; leaf node functions belong to the subset of calls to the target function.

[0072] Step 42: Denote all IR instructions in the objective function as a set. All definitions are denoted as sets. Then the function-level definition dependencies are represented as mapping relationships. For any IR command , In order to All definitions of reachable from, Representation; set It consists of several IR instructions, and is a collection It consists of several definitions, each consisting of a variable identifier and an IR instruction that generates that variable identifier; where the variable identifier can be a temporary variable, a register, or a memory address; and the IR instruction is an intermediate layer instruction used to uniformly describe the semantics of the program.

[0073] Step 43: Identify the variable identifiers of the input parameters and return values ​​of non-system library functions based on the non-system library function calling convention, and identify which input parameters affect the return value based on the function-level definition dependencies, thus obtaining the reachability mapping between the return value and the input parameters. The variable identifiers for both input parameters and return values ​​are temporary variables, registers, or memory addresses; reachability mapping. Used to describe which input parameters affect the return value;

[0074] Step 44: Map based on reachability relations Construct function summaries for non-system library functions.

[0075] Optionally, step 43 includes:

[0076] Input: Function-level definition dependencies Definition of the return value to be tracked ;

[0077] Initialize a work queue, represented as and will define Add it to the work queue;

[0078] Initialize an empty set, denoted as This is used to record definitions that have been processed.

[0079] Initialize an empty mapping structure, represented as , used to define The variable identifier is mapped to the set of input parameters associated with it;

[0080] right Perform iterations, when When not empty, each iteration starts from Take a definition from the middle, and use it as express;

[0081] judge Has it been recorded? In the middle, if Recorded in If the current iteration is skipped, then skip the current iteration; otherwise, skip the current iteration. join in ;

[0082] Get IR commands, to Indicates that calling Get All definitions of reachable from a given location are represented as , This indicates the definition dependency at the function level. IR command query All definitions of reachable;

[0083] right Perform iterations, and express the definition in each iteration as follows: Each iteration will join in ;

[0084] judge Check if the variable identifier is the same as the variable identifier of the input parameter; if so, update. In definition Add to the set of variable identifier mappings Variable identifier;

[0085] The above process continues until... Empty;

[0086] Output: A description of the definition of the return value to be tracked. Reachability mapping with input parameters .

[0087] Optionally, step 44 includes:

[0088] Identify the basic blocks containing return instructions in the control flow graph of non-system library functions, and extract the variable identifiers for all return values; the return instruction is the function termination instruction; in reachability mapping... The function retrieves the input parameters that affect the variable identifier of each return value, binds the return value with all the retrieved input parameters, and forms a function summary of the non-system library function.

[0089] Optionally, step 5 includes:

[0090] Identify all definitions affecting the message transmission buffer at the global program level. Starting with the target function, based on function-level definition dependencies and function summaries of non-system library functions, trace the upper-level definitions of the message transmission buffer parameters of message transmission class functions. If the upper-level definition ultimately comes from external parameters, then take all upper-level call functions of the target function in the control flow graph as new target functions in turn, and repeat steps 3 and 4 to identify call subsets and analyze reachability definitions for the new target functions until there are no upper-level call functions, or the upper-level definition of the message transmission buffer parameters is generated inside the function. Record all upper-level definitions during the analysis process; upper-level definitions are the definitions that affect the message transmission buffer.

[0091] For all instruction addresses that generate upper-level definitions, record the entry address of the basic block in which it resides, forming an instrumentation target address set.

[0092] Optionally, step 6 includes:

[0093] Based on the DymanoRIO dynamic instrumentation framework, instrumentation tracking is performed on the instrumentation target address set. During the operation of the industrial control dedicated protocol software, the trigger sequence of the instrumented instructions and the execution context at the time of triggering are recorded. The execution context includes the call stack, thread information, and register information.

[0094] The sequence of basic blocks triggered by the same thread during a single message transmission, as observed by instrumentation, is recorded as the code execution path during message construction. The set of all code execution paths is the code execution path of the industrial control dedicated protocol software package assembly process.

[0095] This application also provides a code execution path generation system for the industrial control dedicated protocol software assembly process, implementing the code execution path identification method for the industrial control dedicated protocol software assembly process described in the above embodiments, which includes:

[0096] The calling convention segmentation module is used to identify the calling conventions of all functions in industrial control dedicated protocol software and its dependent libraries, and divides the calling conventions into non-system library function calling conventions and system library function calling conventions; the calling conventions include function calling conventions and function prototypes;

[0097] The function summary construction module for system library functions is used to construct function summaries of system library functions based on the system library function calling specification. The function summary of system library functions is used to determine which input parameters affect the return value in system library function calling scenarios.

[0098] The subset construction module is called to construct the control flow graph of the industrial control dedicated protocol software and all dependent libraries. Based on the reference relationship of the message sending class function in the control flow graph, the upper-level calling function of the message sending class function is taken as the target function to be analyzed. According to the calling relationship of the target function in the control flow graph, all its called sub-functions are recursively identified to form the calling subset of the target function.

[0099] The module for obtaining function summaries of non-system library functions is used to obtain function summaries of non-system library functions based on function summaries of system library functions. It employs a static reachability definition analysis method to analyze the call subsets of all target functions sequentially to obtain function-level definition dependencies; based on the function-level definition dependencies, it obtains function summaries of non-system library functions.

[0100] The instrumentation target address set acquisition module is used to trace the upper-level definition of the message sending buffer parameters of message sending class functions based on function-level definition dependencies and function summaries of non-system library functions, and form an instrumentation target address set.

[0101] The code execution path acquisition module is used to instrument the target address set and obtain the code execution path of the industrial control dedicated protocol software assembly process.

[0102] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the method described above.

[0103] This application also provides a computer-readable storage medium, which includes a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described above.

[0104] This application constructs the definition dependencies of data in industrial control system (ICS) dedicated protocol software based on static reachability definition analysis, identifies all definition generation points related to message transmission buffers, and combines dynamic instrumentation tools to monitor the instrumentation of these definition generation points, thereby achieving automated identification of the code execution path in the packet assembly process of ICS dedicated protocol software. Compared with the large-scale instruction instrumentation of traditional dynamic taint analysis methods, this method yields a smaller set of definition generation points, a more focused target scope, is unaffected by functionally unrelated dependency libraries, and does not require taint propagation processing during instrumentation, effectively supporting automated reverse analysis of the ICS dedicated protocol packet assembly process.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.

Claims

1. A method for identifying code execution paths of a process of packing software according to an industrial protocol, characterized in that, The method comprises the following steps: Step 1: identify the calling specification of all functions in the industrial control protocol software and its dependent libraries, and divide the calling specification into non-system library function calling specification and system library function calling specification; Step 2: based on the system library function calling specification, a function summary of the system library function is constructed; the function summary of the system library function is used to determine which incoming parameters affect the return value in the system library function calling scenario; Step 3: a control flow graph of the industrial control protocol software and all dependent libraries is constructed, based on the referenced relationship of the message sending class function in the control flow graph, the upper calling function of the message sending class function is taken as a target function to be analyzed; according to the calling relationship of the target function in the control flow graph, all sub-functions called by the target function are recursively identified to form a calling subset of the target function; Step 4: based on the function summary of the system library function, a static reachable definition analysis method is used to analyze all calling subsets of the target function in turn to obtain a function-level definition dependency relationship; according to the function-level definition dependency relationship, a function summary of a non-system library function is obtained; Step 5: based on the function-level definition dependency relationship and the function summary of the non-system library function, the upper definition of the message sending buffer parameter of the message sending class function is tracked to form a set of patch target addresses; Step 6: the set of patch target addresses is patched and tracked to obtain a code execution path of the industrial control protocol software packet assembly process.

2. The method of claim 1, wherein the code execution path identification of the process of grouping the industrial protocol software is performed by a plurality of software modules. The step 2 comprises: Based on the system library function calling specification, the variable identifiers of the incoming parameters and the function return value are identified, and the variable identifiers of the incoming parameters and the function return value are all temporary variables, registers or memory addresses; Based on the fact that all incoming parameters of a function affect the return value of the function, a function summary of the system library function is constructed; For functions whose return value is independent of the incoming parameters or functions with additional associations between the incoming parameters, the function summary of the system library function is set by manual means; For system and exception handling class functions compiled on the Windows platform, the analysis of the system and exception handling class functions is skipped by manually setting a blacklist, that is, the corresponding function summary of the system library function is not constructed.

3. The method of claim 1, wherein the code execution path identification of the process of grouping the industrial protocol software is performed by a plurality of software modules. The step 4 comprises: Step 41: for the calling subset of the target function, function-level reachable definition analysis is performed from the leaf node function to the upper level, the function-level definition dependency relationship is constructed, the leaf node function does not contain any call to other non-system library function; during the construction of the function-level definition dependency relationship, when the system library function is called, the function summary of the system library function is used to determine which incoming parameters affect the return value of the system library function; the root node of the calling subset is the target function itself; the leaf node function belongs to the calling subset of the target function; Step 42: all IR instructions in the target function are recorded as a set , all definitions are recorded as a set , and the definition dependency relationship at the function level is represented as a mapping relationship , for any IR instruction , , all definitions reachable at the instruction are represented by ; the set is composed of several IR instructions, and the set is composed of several definitions, each of which is composed of a variable identifier and an IR instruction generating the variable identifier; wherein the variable identifier is a temporary variable, a register or a memory address; the IR instruction is an intermediate layer instruction for uniformly describing program semantics; Step 43: identifying variable identifiers of incoming parameters and return value of the non-system library function based on the non-system library function call specification, and identifying which incoming parameters affect the return value based on the definition dependency relationship at the function level, to obtain a reachability relationship mapping of the return value and the incoming parameters ; the variable identifiers of the incoming parameters and the return value are all temporary variables, registers, or memory addresses; the reachability relationship mapping for describing which incoming parameters affect the return value; Step 44: mapping according to reachability relationship , construct function digest of non-system library function.

4. The method of claim 3, wherein the code execution path identification of the process of grouping the industrial protocol software is performed by a plurality of software modules. The step 43 comprises: Input: function-level definition dependencies , definition of return values to be traced ; An initialization of a work queue, denoted as and the definition of is put into the work queue; An empty set, denoted as , is initialized to record the processed definitions. An empty map structure is initialized, denoted as , for mapping the variable definitions to the set of incoming parameters associated therewith; for iterations, while is non-empty, one definition is taken from in each iteration to represent; determining whether the user has been recorded in , if the user has been recorded in , then skipping the current round iteration, otherwise adding the user to the group;​ get IR instructions to represent, call get all definitions reachable at , represent definition dependencies at the function level query IR instructions all definitions reachable; To perform iterations, define the representation in each iteration as , each iteration will add to ; judge Check if the variable identifier is the same as the variable identifier of the input parameter; if so, update. In definition Add to the set of variable identifier mappings Variable identifier; Until For nothing. Output: Definition describing return value to be tracked Reachability mapping with incoming parameter .

5. The method of claim 3, wherein the code execution path identification of the process of grouping the industrial protocol software is performed by a plurality of software modules. The step 44 comprises: In the control flow graph of the non-system library function, a basic block containing a return instruction is identified, and variable identifiers of all return values are extracted; the return instruction is a function end instruction; in the reachable relationship mapping Influencing incoming parameters of each return value variable identifier are searched for, and the return values are bound with all the searched incoming parameters to form a function summary of the non-system library function.

6. The method of claim 1, wherein the code execution path identification of the process of grouping the industrial protocol software is performed by a plurality of software modules. The step 5 comprises: All definitions affecting the packet sending buffer are identified in the program global scope, taking the target function as the analysis starting point, based on the function level definition dependency relationship and the function summary of the non-system library function, the upper layer definition of the packet sending buffer parameter of the packet sending class function is tracked, if the upper layer definition ultimately comes from the external parameter, the target function is taken as the new target function in sequence, and steps 3 and 4 are repeated, and the calling subset identification and reachable definition analysis of the new target function are performed, until there is no any upper layer calling function, or the upper layer definition of the packet sending buffer parameter is generated in the function, and all upper layer definitions are recorded during the analysis process; the upper layer definition is a definition affecting the packet sending buffer; For all instruction addresses that generate upper layer definitions, record the entry address of the basic block where the instruction address is located to form a set of patching target addresses.

7. The method of claim 1, wherein the code execution path identification of the process of grouping the industrial protocol software is performed by a plurality of software modules. The step 6 comprises: Based on the DymanoRIO dynamic patching framework, the set of patching target addresses is patched and tracked, and the trigger sequence of the patched instruction and the execution context at the time of triggering are recorded during the running of the industrial control protocol software, the execution context includes the call stack, thread information, and register information; The sequence of basic blocks triggered by the same thread during a packet sending process observed by the patching is recorded as a code execution path during a packet construction, and the set of all code execution paths is the code execution path of the packet building process of the industrial control protocol software.

8. A system for identifying code execution paths of a process of packing software for industrial control protocol according to any one of claims 1-7, wherein Comprise: A call specification division module is used for identifying the call specification of all functions in the industrial control protocol software and its dependent libraries, and dividing the call specification into non-system library function call specification and system library function call specification; A function summary construction module of the system library function is used for constructing the function summary of the system library function based on the system library function call specification; the function summary of the system library function is used for determining which incoming parameters affect the return value in the system library function calling scenario; A calling subset construction module is used for constructing the control flow graph of the industrial control protocol software and all dependent libraries, based on the referenced relationship of the packet sending class function in the control flow graph, the upper layer calling function of the packet sending class function is taken as a target function to be analyzed; according to the calling relationship of the target function in the control flow graph, all sub-functions called by the target function are recursively identified to form a calling subset of the target function; A function summary acquisition module of the non-system library function is used for acquiring the function summary of the non-system library function based on the function summary of the system library function, and performing analysis on all calling subsets of the target function in sequence by using a static reachable definition analysis method to obtain a function level definition dependency relationship; and the function summary of the non-system library function is obtained according to the function level definition dependency relationship; A set of patching target addresses is obtained based on the function level definition dependency relationship and the function summary of the non-system library function, the upper layer definition of the packet sending buffer parameter of the packet sending class function is tracked, and a set of patching target addresses is formed; A code execution path acquisition module is used for patching and tracking the set of patching target addresses to obtain the code execution path of the packet building process of the industrial control protocol software. 9.An electronic device comprising a memory and a processor, the memory storing a computer program, wherein, The computer program is executed by the processor to implement the method in any one of claims 1-7. The computer program is executed by the processor to implement the method in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium includes a computer program or instructions, which, when executed on a computer, cause the computer to perform the method of any one of claims 1-7.

Images