A method, device, and medium for constructing a semantic feature library of industrial control protocols based on program behavior analysis.

Abstract

This application belongs to the field of industrial control protocols and discloses a method, device, and medium for constructing an industrial control protocol semantic feature library based on program behavior analysis, including: S1: constructing typical industrial control field tags to form a unified set of field semantic tags; S2: acquiring execution context data; S3: performing symbolic execution analysis of protocol message processing to extract symbolic expressions related to protocol field processing; S4: dividing protocol field boundaries and classifying symbolic expressions by field as the original dataset; S5: extracting field program behavior features; S6: filtering field semantic features to select the most distinguishable field semantics from the original features; S7: constructing a semantic feature library by statistically analyzing the filtered features of each field in the original dataset, selecting filtered features that appear more frequently than a preset frequency and combining them to form composite features that can describe field semantics, and forming a complete industrial control protocol semantic feature library by constructing composite features for all fields.

Description

Technical Field

[0001] This application belongs to the field of industrial control protocol technology, and in particular relates to a method, device and medium for constructing an industrial control protocol semantic feature library based on program behavior analysis. Background Technology

[0002] With the widespread application of industrial control systems (ICS), various ICS manufacturers have implemented numerous proprietary protocols to meet the characteristics and functional requirements of their products. These protocols lack public documentation and their content is opaque, making adaptation difficult when conducting attack and defense security assessments, data collection, and system interconnection. Therefore, researching automated reverse engineering methods for ICS proprietary protocols has become an important research direction for improving the network security and interoperability capabilities of ICS systems.

[0003] The core problem to be solved in automated reverse engineering of industrial control protocols is the automated identification of protocol field boundaries and the reasoning of the semantics of protocol fields. Currently, it is mainly divided into two categories: traffic analysis and program behavior analysis. Existing traffic analysis methods typically rely on statistical analysis and feature extraction from a large number of packet samples, making them more suitable for handling periodic and easily collected packet types. However, for sporadic packets, the difficulty in obtaining large-scale samples limits the application of traffic analysis methods to these types of packets. Existing program behavior analysis methods have yielded many research results, and research methods tend to combine dynamic and static analysis. Because the starting point for protocol unpacking logic analysis has typical characteristics, existing methods mainly focus on analyzing the protocol unpacking logic. However, in an industrial control environment, the specific functions implemented by the communicating parties are usually asymmetrical, and analyzing only the unpacking logic cannot fully explain the characteristics of industrial control protocols. The protocol packet assembly process in industrial control protocol implementation software may be triggered by different conditions, and its data sources lack typical characteristics. Furthermore, industrial control messages widely use nested variable-length fields such as TLV structures and self-describing structures, whose content is influenced by the execution context. Conventional static analysis methods struggle to automatically determine the boundaries of these fields, while large-scale execution tracing techniques can negatively impact the operational efficiency of large industrial control software. In addition, traditional protocol reverse analysis methods for automated semantic reasoning of protocol fields primarily rely on heuristic strategies based on message data characteristics, analytical experience, and human-defined patterns. Their applicability is limited by the coverage of the established rules and strategies, and when dealing with industrial control protocols lacking unified standards and exhibiting significant format differences, the analysis results may severely deviate from the actual message format.

[0004] From a program behavior perspective, both dedicated industrial control protocols and open-source industrial control protocols are built upon fundamental logical operations within the software. When processing fields with similar functions, the underlying logical operations of different protocol implementations share certain similarities. Therefore, by using program analysis methods to uncover these similarities in open-source industrial control protocols, it is helpful to identify fields with similar functions across different industrial control protocols, thereby providing new insights for the research of automated semantic reasoning in dedicated industrial control protocols. Summary of the Invention

[0005] The purpose of this application is to overcome the problems of existing technologies by disclosing a method, device, and medium for constructing a semantic feature library for industrial control protocols based on program behavior analysis, thereby achieving generalizable automated reasoning capabilities for the semantics of industrial control protocol fields. Addressing the difficulty in automatically determining the boundaries of nested variable-length fields during protocol packet assembly analysis, this application designs an automatic identification strategy for variable-length field boundaries under single-execution tracing conditions, based on the widespread presence of length indicator fields in industrial control protocols. This application does not rely on large-scale message samples for the analysis of single-category messages, making it more suitable for the sporadic messages in industrial control protocols. The constructed semantic feature library can describe the main business characteristics of industrial control protocols and has strong generalization capabilities when applied to automated reasoning of the semantics of unknown industrial control protocol fields.

[0006] On the one hand, the objective of this application is achieved through the following technical solution:

[0007] A method for constructing an industrial control protocol semantic feature library based on program behavior analysis, the method comprising:

[0008] S1: Construction of typical industrial control field tags. Based on the analysis and summary of various preset industrial control protocols, the field types of industrial control protocols are summarized from the perspective of their functions, forming a unified set of field semantic tags.

[0009] S2: Execution context data acquisition, based on the dynamic instrumentation method to instrument the basic block sequence to be observed and acquire execution context information;

[0010] S3: Symbolic execution analysis of protocol message processing. Based on the symbolic execution method, symbolic execution analysis is performed on the protocol message processing to extract symbolic expressions related to protocol field processing.

[0011] S4: Protocol field boundary delineation. This involves analyzing symbolic expressions to delineate the field boundaries of protocol data and classifying the symbolic expressions by field as the original dataset.

[0012] S5: Field program behavior feature extraction, extracting four types of original features from the original dataset: arithmetic and logical operations, control flow, function calls, and memory operations;

[0013] S6: Field semantic feature filtering, using the chi-square test method to filter out the filtering features that can best distinguish the semantics of the fields from the original features;

[0014] S7: Semantic feature library construction. The filtering features of each field in the original dataset are statistically analyzed. The filtering features that appear more frequently than the preset frequency are selected and combined to form composite features that can describe the semantics of the fields. By constructing composite features for all fields, a complete industrial control protocol semantic feature library is formed.

[0015] According to a preferred embodiment, step S2 includes:

[0016] Static data flow analysis is used to analyze the industrial control protocol implementation software, trace the data dependencies of the packet sending buffer of the message sending function, and record the entry position of the basic block where all instructions with defined dependencies on the packet data are located, as the basic block sequence to be observed;

[0017] The DymanoRIO dynamic instrumentation framework is used to instrument the basic block sequence to be observed, the call positions of message sending class functions, and the call positions of message receiving class functions, and to collect execution context information.

[0018] According to a preferred embodiment, in step S2, the acquired execution context information includes stack information, thread information, register information, global data segment information, and actual sent or received message data.

[0019] According to a preferred embodiment, the protocol message processing in step S3 includes a protocol packet assembly process and a protocol depacketization process.

[0020] Specifically, for the protocol packet assembly process: using the actual triggering basic block sequence observed in S2 as input, and taking the first basic block of the corresponding sequence as the starting point, the initial state of symbolic execution is constructed based on the execution context information collected at the corresponding position in step S2; during symbolic execution, all data sources that have defined dependencies on the packet data are symbolized, and a breadth-first strategy is adopted to force path selection based on the triggering order of the basic block sequence; when the symbol value affecting the length of the symbol variable is unsolvable, a conservative strategy is used to preset the length of the corresponding symbol variable to 1 byte, and such symbol variables are recorded as a set. ;

[0021] Furthermore, the symbolic expressions recorded during the protocol packet assembly process are derived from the message buffer, branch path condition constraints, function call behavior monitoring, and memory operation behavior monitoring in the final active state.

[0022] For the protocol unpacking process, the actual received message data collected by instrumentation in S2 and the execution context of the message receiving class function are used as input; the code position after the message receiving function call is selected as the starting point, and the initial state of symbol execution is constructed according to the execution context information; during symbol execution, the actual sent or received message data guides the path selection, and symbol expressions are recorded during symbol execution for subsequent analysis;

[0023] Furthermore, the symbolic expressions recorded during the protocol unpacking process come from the conditional constraints of the branch path, function call behavior monitoring, and memory operation behavior monitoring.

[0024] According to a preferred embodiment, step S4 includes:

[0025] Based on the symbolic expression information extracted in S3, the field boundaries of the actual sent or received message data extracted in S2 are divided, and different division methods are used for the protocol packet assembly and protocol depacketization processes.

[0026] For the protocol packet assembly process, read the symbol data of the same length as the actual message from the message sending buffer in the symbol execution state. For fixed-length fields, decompose them in reverse according to the concatenation operation in the symbol expression. For the protocol unpacking process, after the symbol execution terminates the exploration, divide the field boundaries according to the natural segmentation of the symbolized message data.

[0027] According to a preferred embodiment, step S5 includes: manually annotating the protocol fields divided in S4 based on the typical industrial control protocol field semantic tag set output by S1, and analyzing the symbolic expressions classified by field in S4 to extract the original features.

[0028] Among them, the arithmetic and logical operation features are extracted based on whether assignment operations, logical operations, arithmetic operations, shift operations, and sign extensions exist;

[0029] Control flow features are extracted based on whether they dominate branch conditions, participate in loop condition calculations, or are processed within loops.

[0030] Function call characteristics are extracted based on whether they are passed as parameters and whether they are affected by the function return value with preset semantics.

[0031] Memory operation characteristics are extracted based on whether they affect global memory, whether address operations are involved, and whether they affect memory read / write operations.

[0032] According to a preferred embodiment, step S6 includes:

[0033] The chi-square test method is used to evaluate the correlation between each original feature and the field type. The deviation of the original feature from the typical field type is calculated, i.e., the p-value. The smaller the p-value, the higher the ability of the corresponding feature to distinguish the typical field type. Features with p-values ​​less than the preset value are selected as screening features.

[0034] According to a preferred embodiment, step S7 includes:

[0035] For each field with a type label, based on statistical results, select filtering features that have a probability of appearing in all datasets greater than a preset value and combine them to form a composite feature for the corresponding type field;

[0036] The semantics of an industrial control field type are described by a set of composite features, and all composite features constitute the semantic feature library of the industrial control protocol.

[0037] On the other hand, this application also discloses:

[0038] An electronic device includes: at least one processor; and a memory communicatively connected to said at least one processor;

[0039] The memory stores instructions that can be executed by the at least one processor. By executing the instructions stored in the memory, the at least one processor performs the aforementioned method for constructing an industrial control protocol semantic feature library based on program behavior analysis.

[0040] On the other hand, this application also discloses:

[0041] A computer-readable storage medium for storing instructions that, when executed, enable the aforementioned method for constructing an industrial control protocol semantic feature library based on program behavior analysis.

[0042] The aforementioned main solution and its various further alternative solutions can be freely combined to form multiple solutions, all of which are solutions that can be adopted and are claimed in this application. Those skilled in the art, after understanding the solution of this application, will realize that there are many combinations based on the prior art and common general knowledge, all of which are technical solutions to be protected in this application, and will not be exhaustively listed here.

[0043] The beneficial effects of this application are:

[0044] This application enables the analysis of commonalities in field functions across different industrial control protocols from a program analysis perspective, providing new insights for the research of automated semantic reasoning in industrial control protocols. The semantic feature library constructed using this method is based on application scenarios of typical industrial control protocols, and is not limited to specific protocols, possessing strong generalization capabilities. It can provide fundamental support for application scenarios such as security assessment, data acquisition, and protocol reverse engineering. Attached Figure Description

[0045] Figure 1 This is a flowchart illustrating the method of this application;

[0046] Figure 2 This is a schematic diagram of the equipment structure in this application. Detailed Implementation

[0047] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0048] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0049] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this application is in use. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. In addition, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0050] Furthermore, terms such as "horizontal," "vertical," and "sag" do not imply that components must be absolutely horizontal or suspended, but rather that they can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal than "vertical," not that the structure must be completely horizontal, but can be slightly tilted.

[0051] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "set up," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0052] Furthermore, it should be noted that unless otherwise specified in this application, the specific structures, connections, positions, power sources, etc. involved are all things that a person skilled in the art can know without creative effort based on the prior art.

[0053] Example 1

[0054] refer to Figure 1 As shown in this embodiment, a method for constructing an industrial control protocol semantic feature library based on program behavior analysis is disclosed. First, based on research on typical industrial control protocols, representative typical industrial control protocol fields are summarized to form a typical industrial control field tag set. Then, based on dynamic instrumentation and symbolic execution techniques, symbolic expressions related to protocol field processing in the message processing process of the protocol implementation software are extracted. Based on the analysis of symbolic expressions, the field boundaries of the protocol data are delineated, and the symbolic expressions are categorized by field as the original dataset. Subsequently, four categories of original features—arithmetic and logical operations, control flow, function calls, and memory operations—are extracted from the original dataset, and the chi-square test method is used to select the most distinguishable field semantics from the original features. Finally, the selected features of each field in the original dataset are statistically analyzed, and frequently occurring selected features are combined to form composite features that can describe the field semantics. By constructing composite features for all fields, a complete industrial control protocol semantic feature library is further formed.

[0055] Specifically, the method for constructing an industrial control protocol semantic feature library based on program behavior analysis in this application includes the following steps.

[0056] (1) Construction of typical industrial control field tags

[0057] Based on manual analysis and summarization of various typical industrial control protocols, this paper systematically summarizes the field types of industrial control protocols from the perspective of their functions, forming a unified set of field semantic tags to support data annotation in subsequent analysis processes. Typical industrial control field types are shown in Table 1.

[0058] Table 1 Typical Industrial Control Field Types

[0059]

[0060] (2) Execution context data collection

[0061] A static data flow analysis method is employed to analyze the industrial control protocol implementation software, tracing the data dependencies of the packet sending buffer in message sending functions. The entry positions of all instructions with defined dependencies on the sent data are recorded as the basic block sequence to be observed. Based on the DymanoRIO dynamic instrumentation framework, instrumentation is performed on the basic block sequence, the call positions of message sending functions, and the call positions of message receiving functions, and execution context information is collected. The collected execution context information includes stack information, thread information, register information, global data segment information, and the actual sent or received message data.

[0062] (3) Symbol execution analysis of protocol message processing

[0063] The symbolic execution engine, based on the Angr analysis framework, performs symbolic execution analysis on the protocol message processing process. The protocol message processing includes protocol assembly and decompression, employing different path selection strategies during symbolic execution.

[0064] For the protocol packet assembly process, the actual triggering basic block sequence observed in step (2) is used as input, and the first basic block of the sequence is used as the starting point. The initial state of symbolic execution is constructed based on the execution context information collected at this position in step (2). During symbolic execution, all data sources that have defined dependencies on the packet data are symbolized, and a breadth-first strategy is adopted to force path selection based on the triggering order of the basic block sequence.

[0065] Since the message data in the packet assembly process has no definite source, under limited execution context conditions, the symbol values ​​affecting the length of symbol variables are unsolvable, affecting the accuracy of the symbolic expressions in the assembled message. Therefore, at this stage, a conservative strategy is adopted to preset the length of such symbol variables to 1 byte, and these symbol variables are recorded as a set VL, prioritizing the normal execution of symbolic operations, and analyzing the specific values ​​of these symbol variables in subsequent steps.

[0066] The analysis of the protocol unpacking process uses the actual received message data collected by instrumentation in step (2) and the execution context of the message receiving function as input. The code position after the message receiving function call is selected as the starting point, and the initial state of symbolic execution is constructed based on the execution context information. During symbolic execution, the actual sent or received message data guides the path selection.

[0067] Symbolic expressions are recorded during symbolic execution for subsequent analysis. The symbolic expressions recorded during the protocol packet assembly process primarily originate from the message buffer in the final active state, conditional constraints of branch paths, function call behavior monitoring, and memory operation behavior monitoring. Similarly, the symbolic expressions recorded during the protocol unpacking process primarily originate from conditional constraints of branch paths, function call behavior monitoring, and memory operation behavior monitoring.

[0068] (4) Protocol field boundary delineation

[0069] Based on the symbolic expression information extracted in step (3), the field boundaries of the actual sent or received message data extracted in step (2) are divided, and different division methods are used for the protocol packet assembly and protocol unpacking processes. For the protocol packet assembly process, symbolic data of the same length as the actual message is read from the message sending buffer in the symbol execution state. For fixed-length fields, they are decomposed in reverse according to the concat operation in the symbolic expression. For the protocol unpacking process, after the symbol execution terminates exploration, the field boundaries are divided according to the natural segmentation of the symbolized message data.

[0070] To address the challenge of automatically determining the boundaries of nested variable-length fields during protocol packet assembly analysis, an automatic boundary identification strategy for variable-length fields is designed based on the characteristics of length indicator fields in industrial control protocols. The core idea is that for related length indicator fields and variable-length fields in protocol messages, a correlation inevitably exists during program processing. By analyzing symbolic expressions to uncover this correlation, the strategy identifies length indicator fields and variable-length fields, thereby achieving automated identification of the boundaries of nested variable-length fields.

[0071] The main implementation steps are as follows:

[0072] (a) Sequence analysis is performed on the actual observed triggering basic block sequence during a message transmission process. Repeating subsequences are extracted from the sequence, with each repeating subsequence representing a loop structure in the code. A loop digest set L is constructed using the symbolic expressions processed within the loop structure. For any loop digest l∈L, it can be represented as a quadruple l=(depth, iter, exprs, cond). Here, depth is the nesting depth of the loop, iter is the number of loop iterations, exprs is the set of symbolic expressions for the symbolic variables in the loop structure, and cond is the loop condition constraint expression. For any expr∈exprs, it is determined whether it affects the message data. The determination method is to traverse the set of symbolic expressions for the message data and extract symbolic expressions containing expr in the sub-elements. The affected message data symbolic expressions are recorded using expr.impact, and the offset position affecting the message transmission buffer is recorded using expr.offset.

[0073] (b) Using the loop digest set L, message data P, and the length variable set VL recorded in step (2) as input parameters, derive the boundary of the variable-length field. The pseudocode of the method is shown in Algorithm 1. Sort the loop digest set L in ascending order of the minimum value of expr.offset and in descending order of depth to ensure that the traversal order is consistent with the message data. According to the nesting depth of the loop, analyze all loop digests in sequence starting from the outer loop. For each loop digest l, identify the symbolic variables representing the length indicator field and the variable-length field in the loop structure. The criteria for judging the length indicator field is that the symbolic variable has a fixed length, and the symbolic expression and the loop condition constraint expression have common sub-elements and affect the message data. In the algorithm pseudocode, it is represented by lenf. The criteria for judging the variable-length field is that its symbolic variable appears repeatedly in the iteration process, and the symbolic expression and the length indicator field symbolic expression have common sub-elements and affect the message data. In the algorithm pseudocode, it is represented by seg.

[0074] (c) Calculate the offset and length of the variable-length field in each iteration. Iterate through the child elements of the variable-length field, for each symbolic variable recorded in set VL, construct constraints using the actual values ​​lenv and expr.impact of the length indicator field, and solve for the actual values ​​of the symbolic variables that affect the length of the variable-length field. Then, inject the actual values ​​into the symbolic expression of the variable-length field, solve for its actual length, and record the offset and actual length of the field in set S.

[0075] (d) The algorithm outputs a set S describing the offset and length of nested variable-length fields, and uses this as a basis to divide the fields into boundaries.

[0076] The algorithm for identifying the boundaries of nested variable-length fields during protocol packet assembly can be implemented by the following program, including:

[0077] 1. Input: Circular digest set L, message data P, length-type symbolic variable set VL

[0078] 2.S ← new Set()

[0079] 3.sort L by Min(l.expr.offset for l in L) ascending and depthdescending

[0080] 4. For each l in L, do:

[0081] 5.for each expr in l.exprs do:

[0082] 6.if l.cond.AST ∩ expr.cond.AST ≠ and expr.impact ≠ :

[0083] 7.lenf ← expr

[0084] 8.end if

[0085] 9.end for

[0086] 10.offset ← lenf.offset

[0087] 11.lenv ← Extract(P, offset, BitWidth(lenf))

[0088] 12.for i ← 1 to l.iter do:

[0089] 13.exprs’ ← {expr∈l.expr│expr.iter=i}

[0090] 14.for each expr in exprs’ do:

[0091] 15.if expr.cond.AST ∩ lenf.cond.AST ≠ and expr.impact ≠ :

[0092] 16.seg← expr

[0093] 17.end if

[0094] 18.end for

[0095] 19.for sym in seg.AST do:

[0096] 20.if sym in VL do:

[0097] 21.constraint ← ExtractConstraint(expr.impact, sym)

[0098] 22.val ← Solve(constraint ∪ lenf.impact.value=lenv)

[0099] 23.if val ≠ TOP:

[0100] 24.sym.value ← val

[0101] 25.end if

[0102] 26.end if

[0103] 27. end for

[0104] 28.slen ← BitWidth(Solve(seg))

[0105] 29. S.add({offset, slen})

[0106] 30. offset ← offset + slen

[0107] 31. end for

[0108] 32. end for

[0109] 33. Return S

[0110] 34. Output: A collection S describing the offsets and lengths of nested variable-length fields.

[0111] (5) Extraction of field program behavior features

[0112] Based on the set of semantic tags for typical industrial control protocol fields output in step (1), the protocol fields divided in step (4) are manually labeled, and the symbolic expressions categorized by field in step (4) are analyzed to extract the original features. The extracted original features include four categories, as shown in Table 2, all of which are binary features.

[0113] Table 2 Original Features

[0114]

[0115] The extraction methods for each feature in Table 2 are as follows:

[0116] (a) Assignment operation: The symbolic value is stored in a variable or memory unit;

[0117] (b) Logical operations, AND, OR, NOT, XOR logical operations involving symbolic variables, take the existence of each type of logical operation as a primitive feature;

[0118] (c) Arithmetic operations, such as addition, subtraction, multiplication, and division involving symbolic variables, with the existence of each type of arithmetic operation as a primitive feature;

[0119] (d) Shift operations: For left and right shift operations involving symbolic variables, the existence of left and right shift operations is taken as a primitive feature.

[0120] (e) Symbolic extension, which takes the existence of symbolic extension members in the symbolic expression of a symbolic variable as a primitive feature;

[0121] (f) Dominant branch conditions, taking whether the symbolic variable participates in the condition constraint operation as a primitive feature;

[0122] (g) Participate in the calculation of loop conditions, and treat whether the symbolic variable is processed in the loop body and participates in the condition constraint calculation as an original feature;

[0123] (h) is processed in the loop, taking whether the symbolic variable is processed in the loop body as a primitive feature;

[0124] (i) As a function call parameter: whether a symbolic variable is used as a function parameter is taken as a primitive feature;

[0125] (j) Affected by the return value of specific semantic functions: Whether symbolic variables are affected by the return value of specific types of functions. Specific types of functions include memory allocation, file and device I / O, time and synchronization, string processing, and system status query system function calls. Each type of function is considered as an original feature.

[0126] (k) Impact on global memory: Whether symbolic variables are written to the global memory segment is taken as a primitive feature;

[0127] (l) Existence of address arithmetic: In logical operations involving symbolic variables, whether the operand contains an explicit address member is taken as a primary characteristic;

[0128] (m) Affecting memory read and write operations: Whether a symbolic variable is the source address, destination address, or read / write length of a memory read / write operation is taken as a primitive feature.

[0129] After this step is completed, output all fields in the actual messages that have industrial control field type labels, as well as the original characteristics of each field.

[0130] (6) Field semantic feature filtering

[0131] In step (5), the original features of each field are screened. Specifically, the chi-square test is used to assess the correlation between each original feature and the field type, and the deviation of the original feature from the typical field type is calculated, i.e., the p-value. The smaller the p-value, the higher the distinguishing ability of the corresponding feature for the typical field type. In this step, features with p-values ​​less than 0.05 are selected as screening features. Only the screened features are retained for each field for further analysis.

[0132] (7) Construction of semantic feature library

[0133] To highlight the general semantics of typical industrial control fields, it is necessary to remove infrequently occurring filtering features. For each field with a type label, filtering features that appear with a probability greater than 40% in all datasets are selected based on statistical results and combined to form composite features for that type of field. A set of composite features describes the semantics of an industrial control field type, and all composite features constitute the semantic feature library of the industrial control protocol.

[0134] This application presents a method for constructing a semantic feature library for industrial control protocols based on program behavior analysis. This method can uncover the commonalities in field functions across different industrial control protocols from a program analysis perspective, providing new insights for the research of automated semantic reasoning in industrial control protocols. The semantic feature library constructed by this method is divided based on the application scenarios of typical industrial control protocols, and is not limited to specific protocols. It has strong generalization capabilities and can provide fundamental support for application scenarios such as security assessment, data acquisition, and protocol reverse engineering.

[0135] Example 2

[0136] like Figure 2 As shown in Embodiment 1, this embodiment also discloses an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; the specific connection medium between the processor and the memory is not limited in this embodiment.

[0137] Figure 2 This example illustrates the connection between the processor and memory via a bus. The bus... Figure 2 The connections between other components are shown in thick lines for illustrative purposes only and should not be construed as limiting. Buses can be categorized into address buses, data buses, control buses, etc., but for ease of representation, [the specific bus type is not shown here]. Figure 2 A single thick line is used to represent a processor, but this does not mean there is only one bus or one type of bus. Alternatively, a processor can also be called a controller; there is no restriction on the name.

[0138] In this embodiment, the memory stores instructions executable by the at least one processor. By executing the instructions stored in the memory, the at least one processor performs the method described in Embodiment 1. The processor can implement... Figure 2 The functions of each module in the device are shown.

[0139] The processor is the control center of the device. It can connect to various parts of the control device through various interfaces and lines, and can run or execute instructions stored in memory and call data stored in memory.

[0140] In an alternative design, the processor may include one or more processing units. The processor may integrate an application processor and a modem processor, wherein the application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may also not be integrated into the processor. In some embodiments, the processor and memory may be implemented on the same chip; in some embodiments, they may also be implemented separately on separate chips.

[0141] The processor can be a general-purpose processor, such as a CPU, digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method for constructing an industrial control protocol semantic feature library based on program behavior analysis disclosed in the embodiments of this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0142] Memory, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory can include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), and electrically erasable programmable read-only memory (EPROM). Only memory (EEPROM), magnetic storage, magnetic disks, optical disks, etc. A memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in embodiments of this invention can also be a circuit or any other device capable of performing storage functions for storing program instructions and / or data.

[0143] By designing and programming the processor, the code corresponding to the method for constructing an industrial control protocol semantic feature library based on program behavior analysis described in the foregoing embodiments can be embedded into the chip, thereby enabling the chip to execute the steps of the method described in the foregoing embodiments during runtime. How to design and program the processor is a technique well-known to those skilled in the art and will not be elaborated upon here.

[0144] Example 3

[0145] Based on Embodiment 1, this embodiment also discloses: a computer-readable storage medium for storing instructions that, when executed, cause the method described in Embodiment 1 to be implemented.

[0146] In some alternative embodiments, the present invention also provides that various aspects of the method for constructing an industrial control protocol semantic feature library based on program behavior analysis can also be implemented in the form of a program product, which includes program code. When the program product is run on a device, the program code is used to cause the control device to perform the steps in the method for constructing an industrial control protocol semantic feature library based on program behavior analysis according to various exemplary embodiments of the present invention as described above.

[0147] It should be noted that although several units or sub-units of the apparatus have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the invention, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units. Furthermore, although the operation of the method of the invention is described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0148] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can be implemented in one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs) containing computer-usable program code. The form of a computer program product implemented on ROM, optical memory, etc.

[0149] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a server, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0150] Program code for performing the operations of this invention can be written using any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0151] In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0152] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0153] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

Claims

1. A method for constructing a semantic feature library of industrial control protocols based on program behavior analysis, characterized in that, The method for constructing the semantic feature library of the industrial control protocol includes: S1: Construction of typical industrial control field tags. Based on the analysis and summary of various preset industrial control protocols, the field types of industrial control protocols are summarized from the perspective of their functions, forming a unified set of field semantic tags. S2: Execution context data acquisition, based on the dynamic instrumentation method to instrument the basic block sequence to be observed and acquire execution context information; S3: Symbolic execution analysis of protocol message processing. Based on the symbolic execution method, symbolic execution analysis is performed on the protocol message processing to extract symbolic expressions related to protocol field processing. S4: Protocol field boundary delineation. This involves analyzing symbolic expressions to delineate the field boundaries of protocol data and classifying the symbolic expressions by field as the original dataset. S5: Field program behavior feature extraction, extracting four types of original features from the original dataset: arithmetic and logical operations, control flow, function calls, and memory operations; S6: Field semantic feature filtering, using the chi-square test method to filter out the filtering features that can best distinguish the semantics of the fields from the original features; S7: Semantic feature library construction. The filtering features of each field in the original dataset are statistically analyzed. The filtering features that appear more frequently than the preset frequency are selected and combined to form composite features that can describe the semantics of the fields. By constructing composite features for all fields, a complete industrial control protocol semantic feature library is formed. Step S2 includes: Static data flow analysis is used to analyze the industrial control protocol implementation software, trace the data dependencies of the packet sending buffer of the message sending function, and record the entry position of the basic block where all instructions with defined dependencies on the packet data are located, as the basic block sequence to be observed; Based on the DymanoRIO dynamic instrumentation framework, instrumentation is performed on the basic block sequence to be observed, the call positions of message sending class functions, and the call positions of message receiving class functions, and execution context information is collected. In step S2, the collected execution context information includes stack information, thread information, register information, global data segment information, and actual sent or received message data; The protocol message processing in step S3 includes protocol packet assembly and protocol depacketization. Specifically, for the protocol packet assembly process: using the actual triggering basic block sequence observed in S2 as input, and taking the first basic block of the corresponding sequence as the starting point, the initial state of symbolic execution is constructed based on the execution context information collected at the corresponding position in step S2; during symbolic execution, all data sources that have defined dependencies on the packet data are symbolized, and a breadth-first strategy is adopted to force path selection based on the triggering order of the basic block sequence; when the symbol value affecting the length of the symbol variable is unsolvable, a conservative strategy is used to preset the length of the corresponding symbol variable to 1 byte, and such symbol variables are recorded as a set. ; Furthermore, the symbolic expressions recorded during the protocol packet assembly process are derived from the message buffer, branch path condition constraints, function call behavior monitoring, and memory operation behavior monitoring in the final active state. For the protocol unpacking process, the actual received message data collected by instrumentation in S2 and the execution context of the message receiving class function are used as input; the code position after the message receiving function call is selected as the starting point, and the initial state of symbol execution is constructed according to the execution context information; during symbol execution, the actual sent or received message data guides the path selection, and symbol expressions are recorded during symbol execution for subsequent analysis; Furthermore, the symbolic expressions recorded during the protocol unpacking process come from the conditional constraints of the branch path, function call behavior monitoring, and memory operation behavior monitoring.

2. The method for constructing an industrial control protocol semantic feature library based on program behavior analysis as described in claim 1, characterized in that, Step S4 includes: Based on the symbolic expression information extracted in S3, the field boundaries of the actual sent or received message data extracted in S2 are divided, and different division methods are used for the protocol packet assembly and protocol depacketization processes. For the protocol packet assembly process, read the symbol data of the same length as the actual message from the message sending buffer in the symbol execution state. For fixed-length fields, decompose them in reverse according to the concatenation operation in the symbol expression. For the protocol unpacking process, after the symbol execution terminates the exploration, divide the field boundaries according to the natural segmentation of the symbolized message data.

3. The method for constructing an industrial control protocol semantic feature library based on program behavior analysis as described in claim 2, characterized in that, Step S5 includes: based on the typical industrial control protocol field semantic tag set output by S1, manually annotating the protocol fields divided in S4, and analyzing the symbolic expressions classified by field in S4 to extract the original features; Among them, the arithmetic and logical operation features are extracted based on whether assignment operations, logical operations, arithmetic operations, shift operations, and sign extensions exist; Control flow features are extracted based on whether they dominate branch conditions, participate in loop condition calculations, or are processed within loops. Function call characteristics are extracted based on whether they are passed as parameters and whether they are affected by the function return value with preset semantics. Memory operation characteristics are extracted based on whether they affect global memory, whether address operations are involved, and whether they affect memory read / write operations.

4. The method for constructing an industrial control protocol semantic feature library based on program behavior analysis as described in claim 3, characterized in that, Step S6 includes: The chi-square test method is used to evaluate the correlation between each original feature and the field type. The deviation of the original feature from the typical field type is calculated, i.e., the p-value. The smaller the p-value, the higher the ability of the corresponding feature to distinguish the typical field type. Features with p-values ​​less than the preset value are selected as screening features.

5. The method for constructing an industrial control protocol semantic feature library based on program behavior analysis as described in claim 4, characterized in that, Step S7 includes: For each field with a type label, based on statistical results, select filtering features that have a probability of appearing in all datasets greater than a preset value and combine them to form a composite feature for the corresponding type field; The semantics of an industrial control field type are described by a set of composite features, and all composite features constitute the semantic feature library of the industrial control protocol.

6. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor. By executing the instructions stored in the memory, the at least one processor causes the at least one processor to perform the method for constructing an industrial control protocol semantic feature library based on program behavior analysis as described in any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store instructions that, when executed, enable the method for constructing an industrial control protocol semantic feature library based on program behavior analysis as described in any one of claims 1 to 5 to be implemented.

Images