A program flow monitoring method based on segmented signature and inter-segment transition relationship and a computer device

Abstract

The application provides a program flow monitoring method and computer equipment based on segmented signature and inter-segment transition relationship, and belongs to the technical field of program flow monitoring. Specifically, a monitored program function is analyzed, a conditional branch point is identified, and the function is divided into multiple straight line segments according to the branch point; a segment identifier is assigned to each straight line segment, a signature initial value is set, and an expected signature value is calculated; all legal jump relationships between the straight line segments are saved in combination of the source segment identifier and the target segment identifier. The identifier of the last executed straight line segment is recorded, if the identifier is valid, the legality of the jump between the two segments is checked, and if the jump is illegal, fault processing is immediately performed; if the jump is legal, the signature register is initialized by loading the signature initial value of the current segment. When each step in the segment is executed, the identifier of the belonging segment and the current running segment identifier are verified; if the identifiers are consistent, the step identifier is sent to the signature update function, and the signature register is iteratively updated. When leaving the current straight line segment, the register operation value is compared with the expected signature value of the segment. The application improves the completeness of the verification result.

Description

Technical Field

[0001] This invention belongs to the field of program flow monitoring technology. Specifically, this invention relates to a program flow monitoring method and computer device based on segmented signatures and inter-segment transfer relationships. Background Technology

[0002] The operational security of industrial control programs such as embedded control software and vehicle-mounted electronic control programs directly determines the reliability of equipment operation. Abnormal attacks such as program flow tampering and instruction disorder can easily lead to security risks such as equipment malfunction and loss of control. Therefore, high-precision and low-overhead program flow monitoring technology has become the core means to ensure the reliable operation of programs.

[0003] Chinese Patent 113176983A discloses an invention in the field of CPU technology, providing a program flow monitoring method and system, a CPU, and a chip. The program flow monitoring method includes: recording the execution information of the program flow by setting monitoring points in the program to determine the execution trajectory of the program flow; determining the expected execution time of the program flow based on the recorded execution information; calculating the actual execution time of the program flow; and determining whether the program flow is executing as expected based on a comparison between the actual execution time and the expected execution time.

[0004] Existing technologies can only check the execution trajectory of the program flow, but cannot monitor the program execution between monitoring points, which affects the integrity of the program flow verification results. Summary of the Invention

[0005] The present invention aims to provide a program flow monitoring method and computer device based on segmented signature and inter-segment transfer relationship, so as to improve the technical objective of improving the integrity of program flow verification results.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] This invention provides a program flow monitoring method based on segmented signatures and inter-segment transfer relationships, including a preprocessing step and a program runtime monitoring step:

[0008] Preprocessing steps:

[0009] Step 1: Analyze the monitored program function, identify the conditional branch points in the program function, and divide the program function into multiple line segments according to the conditional branch points;

[0010] Step 2: Construct a segment identifier for each line segment; configure an initial signature value for each line segment and calculate the corresponding expected signature value; store the segment identifier, initial signature value, and expected signature value for each line segment;

[0011] Step 3: Based on the control flow structure of the program function, store all legal transfer relationships between line segments in the form of a combination of source segment identifier and target segment identifier;

[0012] Program runtime monitoring steps:

[0013] Step 4: Save the segment identifier of the previously run line segment; if the previously run line segment has a valid value, query the valid transfer relationship between the previously run line segment and the current line segment, and determine whether the transfer relationship between the previously run line segment and the current line segment is valid. If the transfer relationship is invalid, trigger fault handling; if the transfer relationship is valid, read the initial signature value of the current line segment and set the initial value of the signature register to the initial signature value of the current line segment.

[0014] Step 5: When executing each step in a line segment, first check whether the segment identifier of the line segment to which the step belongs is consistent with the segment identifier of the currently running line segment. If they are inconsistent, trigger fault handling; if they are consistent, input the identifier of the current step into the signature update function to update the operation value of the signature register.

[0015] Step Six: When exiting the monitoring of the current line segment, read the expected signature value of the current line segment stored in the preprocessing step, compare the current operation value of the signature register with the expected signature value. If the comparison matches, the line segment is verified; if the comparison does not match, fault handling is triggered.

[0016] In step one, the split line segment does not contain conditional branch statements, has only one entry point and one exit point, and has only one step execution path.

[0017] In step two, the expected signature value is calculated as follows: starting from the initial signature value of the line segment, the identifier of each step is sequentially input into the signature update function according to the order of execution steps within the segment to obtain the expected signature value.

[0018] The signature update function uses any of the following operations: XOR operation with the step identifier after circular left shift, XOR operation with the step identifier after linear feedback shift register operation, or CRC operation.

[0019] In step two, the initial signature value for each line segment is configured by a random number provided by an external watchdog.

[0020] In step three, when storing all legal transfer relationships between line segments, a time window field is added to set the transfer time between line segments.

[0021] In step four, at the start of the runtime monitoring step, both the current line segment identifier and the previous line segment identifier are set to invalid values; if the segment identifier of the previous line segment of the current line segment is invalid, the verification of the legal transfer relationship between segments is skipped, and the initial value setting operation of the signature register is directly executed.

[0022] In step five, the step verification within the line segment is performed sequentially according to the step execution order; after the current step completes the verification and the signature update function in the signature register, it is determined whether there is a next execution step within the line segment. If there is, the verification and signature update function of the next step are executed; if not, the process proceeds to step six.

[0023] The present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0024] The technical effects of this invention are as follows:

[0025] (1) This invention solves the problem of storage explosion in multi-branch paths. Traditional program flow overall signature schemes are for functions with n conditional branches. The number of theoretically feasible execution paths of the program increases exponentially with the number of branches, requiring pre-calculation and storage of the expected signature values ​​corresponding to all paths. When the number of branches increases slightly, the storage demand expands dramatically. This invention divides the program function into straight line segments without internal branches with the conditional branch points as boundaries. Each straight line segment maintains only one set of initial signature values ​​and a unique expected signature value. At the same time, it uses an inter-segment transition graph to record the legal segment jump relationships. The number of legal transfer records is only linearly related to the number of conditional branches, eliminating the problem of path combination explosion in multi-branch scenarios and significantly reducing the pre-calculation workload and storage requirements.

[0026] (2) This invention improves signature integrity and path verification capabilities. Conventional checkpoint sequence monitoring schemes only verify the execution order at preset checkpoint locations, and can only determine whether the program arrives at each checkpoint in sequence. They cannot perceive the running status of the code segment between two checkpoints, and cannot effectively detect runtime faults such as intermediate code tampering or instruction skipping. This invention adopts intra-segment cumulative signature verification, where signatures are generated by sequentially accumulating calculations based on execution steps within a segment, which can verify whether all steps within a straight segment are executed completely and in an orderly manner. The path validity verification and code execution integrity verification work together to compensate for the protection deficiencies of single checkpoint monitoring schemes.

[0027] (3) During the execution of each step, the present invention compares the segment identifier pre-configured for the step with the currently running line segment identifier in real time. If the two are inconsistent, fault handling is triggered directly. It can accurately capture cross-segment execution errors and identify abnormal behaviors that are difficult to detect by conventional monitoring methods, such as code segment misalignment and illegal jumps of instructions to other code segments, thereby further expanding the scope of fault and attack detection.

[0028] (4) This invention adopts a segment and step naming rule based on functions. The segment and step numbers within the same function are unique, and the numbering between different functions is independent, forming an isolated namespace with functions as the boundary. The segment signature tables and inter-segment transfer relationships corresponding to different functions are independent of each other, and the identifiers will not conflict. It supports configuring monitoring rules for any number of target functions in the system individually, and can flexibly select some functions to enable program flow protection, which is convenient for modular deployment and incremental expansion, and adapts to the software architecture of large-scale embedded software with multiple tasks and multiple functions coexisting.

[0029] (5) This invention reduces the resource consumption of the computer, and the overall static storage overhead of the segment signature table and the legal transfer table between segments is low; the storage overhead increases linearly and smoothly when the number of branches increases. When the program runs, the monitoring logic only needs to maintain three types of runtime variables: the current line segment identifier, the previous line segment identifier, and the signature register; the monitoring operation only includes lightweight operations such as shift, XOR, and CRC, which do not require complex calculations, consume low processor computing power, and will not have a significant impact on the real-time performance of the business.

[0030] (6) This invention reduces the probability of false alarms through a deterministic verification mechanism. All signature operations and transfer relationship determinations in this invention are deterministic logic, and there are no strategies such as statistical discrimination that are prone to introducing false alarms. By reasonably configuring the signature register length, the collision probability can be reduced to a negligible level in engineering; the operation process is stable and controllable, avoiding false alarms caused by algorithm uncertainty, and improving the reliability of the program flow monitoring system. Attached Figure Description

[0031] This manual includes the following figures, which illustrate the following:

[0032] Figure 1 This is a flowchart of a program flow monitoring method and computer device based on segmented signatures and inter-segment transfer relationships according to the present invention.

[0033] Figure 2 This is an inter-segment transfer relationship diagram of an embodiment of a program flow monitoring method and computer device based on segmented signatures and inter-segment transfer relationships according to the present invention. Detailed Implementation

[0034] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, in order to help those skilled in the art to have a more complete, accurate and in-depth understanding of the inventive concept and technical solution of the present invention, and to facilitate its implementation.

[0035] This invention provides a program flow monitoring method based on segmented signatures and inter-segment transfer relationships, including a preprocessing step and a program runtime monitoring step:

[0036] Preprocessing steps:

[0037] Step 1: Analyze the monitored program function, identify the conditional branch points in the program function, and divide the program function into multiple line segments according to the conditional branch points;

[0038] Step 2: Construct a segment identifier for each line segment; configure an initial signature value for each line segment and calculate the corresponding expected signature value; store the segment identifier, initial signature value, and expected signature value for each line segment;

[0039] Step 3: Based on the control flow structure of the program function, store all legal transfer relationships between line segments in the form of a combination of source segment identifier and target segment identifier;

[0040] Program runtime monitoring steps:

[0041] Step 4: Save the segment identifier of the previously run line segment; if the previously run line segment has a valid value, query the valid transfer relationship between the previously run line segment and the current line segment, and determine whether the transfer relationship between the previously run line segment and the current line segment is valid. If the transfer relationship is invalid, trigger fault handling; if the transfer relationship is valid, read the initial signature value of the current line segment and set the initial value of the signature register to the initial signature value of the current line segment.

[0042] Step 5: When executing each step in a line segment, first check whether the segment identifier of the line segment to which the step belongs is consistent with the segment identifier of the currently running line segment. If they are inconsistent, trigger fault handling; if they are consistent, input the identifier of the current step into the signature update function to update the operation value of the signature register.

[0043] Step Six: When exiting the monitoring of the current line segment, read the expected signature value of the current line segment stored in the preprocessing step, compare the current operation value of the signature register with the expected signature value. If the comparison matches, the line segment is verified; if the comparison does not match, fault handling is triggered.

[0044] In step one, the split line segment does not contain conditional branch statements, has only one entry point and one exit point, and has only one step execution path.

[0045] In step two, the expected signature value is calculated as follows: starting from the initial signature value of the line segment, the identifier of each step is sequentially input into the signature update function according to the order of execution steps within the segment to obtain the expected signature value.

[0046] The signature update function uses any of the following operations: XOR operation with the step identifier after circular left shift, XOR operation with the step identifier after linear feedback shift register operation, or CRC operation.

[0047] In step two, the initial signature value for each line segment is configured by a random number provided by an external watchdog.

[0048] In step three, when storing all legal transfer relationships between line segments, a time window field is added to set the transfer time between line segments.

[0049] In step four, at the start of the runtime monitoring step, both the current line segment identifier and the previous line segment identifier are set to invalid values; if the segment identifier of the previous line segment of the current line segment is invalid, the verification of the legal transfer relationship between segments is skipped, and the initial value setting operation of the signature register is directly executed.

[0050] In step five, the step verification within the line segment is performed sequentially according to the step execution order; after the current step completes the verification and the signature update function in the signature register, it is determined whether there is a next execution step within the line segment. If there is, the verification and signature update function of the next step are executed; if not, the process proceeds to step six.

[0051] The present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0052] The following is a detailed description of a program flow monitoring method based on segmented signatures and inter-segment transfer relationships according to the present invention.

[0053] Before monitoring a program, it needs to be preprocessed. Specifically, the monitored program functions are analyzed to identify conditional branch points, and the program functions are then divided into multiple line segments based on these branch points. Each line segment satisfies the following conditions: it does not contain any conditional branch statements; it has only one entry point and one exit point; and the execution path within the segment is uniquely determined.

[0054] For each line segment, a segment identifier is constructed. Specifically, each line segment is named using the function name plus a segment number (e.g., FUNC_SEG_1, FUNC_SEG_2A, FUNC_SEG_2B, FUNC_SEG_3), where FUNC represents the function, SEG represents the segment, and the number is used to distinguish different segments. Segment numbers within the same function are unique, and segment numbers for different functions are independent. It should be noted that the naming rules for line segments are not limited to the format in the above embodiment.

[0055] An initial signature value is configured for each line segment, and the corresponding expected signature value is calculated. The initial signature value for each line segment is determined by a random number provided by an external watchdog, which enhances protection against pre-calculated attacks compared to using a fixed initial signature value. The expected signature value is calculated as follows: starting from the initial signature value of the line segment, the identifier of each step is sequentially input into the signature update function for cumulative calculation to obtain the expected signature value, according to the order of execution steps within the segment. The step identifier format within the line segment is configured as "function name_STEP_number", such as FUNC_STEP_1, FUNC_STEP_BRANCH_A1. The signature update function is defined as: Sig=f(Sig,FUNC_STEP_j), where f is one of the following operations: XOR operation with the step identifier after a circular left shift, XOR operation with the step identifier after a linear feedback shift register (LFSR) operation, or CRC operation.

[0056] After constructing the segment identifier, configuring the initial signature value, and calculating the expected signature value for each line segment, the obtained data is stored. In this embodiment of the invention, it is stored in the form of a segment signature table, as shown in the table below.

[0057] Fields meaning illustrate FUNC_SEG_i Segment identifier A monitoring segment is uniquely identified by its format "function name_SEG_number". Sig_init initial signature value The starting value for signature calculation is set independently for each segment. Sig_expt_i Expected signature value The expected signature result after all steps in this section have been executed in the correct order.

[0058] In practice, data storage is not limited to the table format mentioned above; adjacency lists and adjacency matrices can also be used to store data.

[0059] Based on the control flow structure of the program function, all legal transfer relationships between line segments are stored in the form of a combination of source segment identifier and target segment identifier; in the embodiments of the present invention, the source segment identifier and target segment identifier of all line segments are stored in the form of a legal transfer table between segments, as shown in the table below.

[0060] Fields meaning illustrate FUNC_SEG_from Source segment identifier The starting segment of the transfer FUNC_SEG_to Target segment identifier The destination segment of the transfer

[0061] An inter-segment transfer is considered valid if and only if the pair (FUNC_SEG_from, FUNC_SEG_to) exists in the inter-segment transfer table. The number of records in the valid inter-segment transfer table is equal to twice the number of conditional branches in the program function plus the number of linear connections between branches, and is linearly related to the number of branches.

[0062] When storing the legal transfer relationships between line segments through the inter-segment legal transfer table, a time window field can be added to require the inter-segment transfer to be completed within a specified time.

[0063] When the program officially enters the running monitoring phase, both the current line segment identifier and the previous line segment identifier are set to invalid values; invalid values ​​indicate that no line segment has been entered for monitoring.

[0064] When a straight line segment enters the monitoring process, perform the following operations:

[0065] The current line segment identifier is saved as the identifier of the previous line segment. If the segment identifier of the previous line segment is invalid, the verification of the valid inter-segment transfer relationship is skipped, and the initial value setting operation of the signature register is directly executed. If the previously executed line segment has a valid value, the valid transfer relationship between the previously executed line segment and the current line segment is queried to determine whether the transfer relationship between the previously executed line segment and the current line segment is valid. If the transfer relationship is invalid, fault handling is triggered; if the transfer relationship is valid, the initial signature value of the current line segment is read, and the initial value of the signature register is set to the initial signature value of the current line segment, that is, Sig = Sig_init is set.

[0066] When executing each step within a line segment, the segment identifier of the line segment to which the step belongs is first checked against the segment identifier of the currently running line segment. If they do not match, fault handling is triggered. If they match, the identifier of the current step is input into the signature update function to update the calculated value of the signature register. It should be noted that the step verification within the line segment is performed sequentially according to the step execution order. After the current step completes the verification and the update of the signature update function in the signature register, it is determined whether there is a next execution step within the line segment. If there is, the verification and signature update function update of the next step are continued; otherwise, the process proceeds to the next step.

[0067] When exiting the monitoring of the current line segment, the expected signature value of the current line segment stored in the preprocessing step is read, and the current operation value of the signature register is compared with the expected signature value. If the comparison matches, the line segment is verified; otherwise, fault handling is triggered.

[0068] The present invention will now be described with reference to the embodiments.

[0069] Taking a function containing a conditional branch as an example, the function includes a general step Step1, conditional if branch steps Step2_branch_A1 and Step2_branch_A2, else branch step Step2_branch_B1, and a general step Step3.

[0070] like Figure 2 As shown, there are two valid paths:

[0071] Path A (if: branch A): Step1->Step2_branch_A1->Step2_branch_A2->Step3

[0072] Path B (else: branch B): Step1->Step2_branch_B1->Step3

[0073] Segmentation results:

[0074] Before branching: FUNC_SEG_1={Step1}

[0075] if branch: FUNC_SEG_2A={Step2_branch_A1,Step2_branch_A2}

[0076] else branch: FUNC_SEG_2B={Step2_branch_B1}

[0077] After branching: FUNC_SEG_3={Step3}

[0078] Section signature form:

[0079] Segment identifier Signature initial value Sig_init Expected signature value R_sig Calculation process FUNC_SEG_1 0xA5 0x4A f(0xA5, FUNC_STEP_1)= ROTL(0xA5) XOR 0x01= 0x4A FUNC_SEG_2A 0xA5 0x91 f(f(0xA5, FUNC_STEP_2_BRANCH_A1), FUNC_STEP_2_BRANCH_A2)= f(0x49, 0x03)= 0x91 FUNC_SEG_2B 0xA5 0x4F f(0xA5, FUNC_STEP_2_BRANCH_B1)= ROTL(0xA5) XOR 0x04= 0x4F FUNC_SEG_3 0xA5 0x4E f(0xA5, FUNC_STEP_2)= ROTL(0xA5) XOR 0x05= 0x4E

[0080] Inter-segment transfer table:

[0081] Serial Number Source segment identifier (FUNC_SEG_from) Target segment identifier (FUNC_SEG_to) meaning 1 FUNC_SEG_1 FUNC_SEG_2A After Step 1 is completed, proceed to the if branch. 2 FUNC_SEG_1 FUNC_SEG_2B After Step 1 is completed, proceed to the else branch. 3 FUNC_SEG_2A FUNC_SEG_3 After the if branch completes execution, merge. 4 FUNC_SEG_2B FUNC_SEG_3 After the else branch completes execution, the processes converge.

[0082] Since there are no conditional branches within each segment, the expected signature value Sig_expt_i is uniquely determined. The legal transfer table between segments contains only 4 records, which is linearly related to the number of branches.

[0083] Fault detection certificate:

[0084] Fault 1 (Inter-segment skip): If Step2_branch_A1 is skipped, segment FUNC_SEG_2A actually only executes Step2_branch_A2, the signature update only includes FUNC_STEP_BRANCH_A2, the calculated Sig is not equal to Sig_expt_i=0x91, and an anomaly is detected in step six.

[0085] Fault 2 (Step Out of Order): If Step2_branch_A2 is executed before Step2_branch_A1, the result of Sig is different from the correct order and not equal to R_2A because the left shift operation in the signature update function does not satisfy the commutative law. An anomaly is detected in step six.

[0086] Fault 3 (Skip the entire segment): If FUNC_SEG_2A is completely skipped, the program jumps directly from FUNC_SEG_1 to FUNC_SEG_3. In step four, the program searches the inter-segment legal transfer table for (FUNC_SEG_1, FUNC_SEG_3). The record does not exist in the table, and an anomaly is detected.

[0087] Fault 4 (Incorrect Step Attribution): If the step Step2_branch_A1 is incorrectly placed in the code area of ​​FUNC_SEG_2B, an anomaly is detected in step five when verifying that S_cur(FUNC_SEG_2B) is not equal to the segment identifier FUNC_SEG_2A to which the step belongs.

[0088] In addition to the four fault detection methods mentioned above, there are also methods to detect branch errors in step four and to detect multiple execution errors within a segment in step six.

[0089] Storage size comparison:

[0090] Number of conditional branches Traditional overall signature scheme (the expected number of signature values ​​to be stored) This scheme (expected number of segment signature records) 5 2^5 = 32 2 x 5 + 2 = 12 10 2^10 = 1,024 2 x 10 + 2 = 22 20 2^20 = 1,048,576 2 x 20 + 2 = 42

[0091] The traditional solution has a storage requirement of O(2^3) n The exponential growth of the original scheme is O(n), while this scheme has linear growth of O(n).

[0092] The beneficial effects of the present invention are described in detail below.

[0093] This invention addresses the problem of exploding storage requirements in multi-branch path scenarios. Traditional overall program flow signature schemes, for functions with n conditional branches, show an exponential increase in the number of theoretically feasible execution paths, requiring the pre-computation and storage of expected signature values ​​for all paths. As the number of branches increases slightly, storage demands escalate dramatically. This invention divides the program function into straight segments with no internal branches, using the conditional branch points as boundaries. Each segment maintains only one set of initial signature values ​​and a unique expected signature value. Simultaneously, it utilizes an inter-segment transition graph to record legitimate segment jump relationships. The number of legitimate transition records is linearly related only to the number of conditional branches, eliminating the path combination explosion problem in multi-branch scenarios and significantly reducing pre-computation workload and storage requirements.

[0094] This invention improves signature integrity and path verification capabilities. Conventional checkpoint sequence monitoring schemes only verify the execution order at preset checkpoint locations, determining whether the program arrives at each checkpoint in sequence. They cannot detect the execution status of code segments between checkpoints, nor can they effectively detect runtime faults such as tampering with intermediate code or instruction skipping. This invention employs intra-segment cumulative signature verification, generating a signature based on the sequential accumulation of execution steps within a segment. This verifies whether all steps within a straight segment are executed completely and in order. The path validity verification and code execution integrity verification work together to overcome the protection deficiencies of single-checkpoint monitoring schemes.

[0095] This invention compares the pre-configured segment identifier of each execution step with the currently running line segment identifier in real time. If the two are inconsistent, fault handling is triggered directly. It can accurately capture cross-segment execution errors and identify abnormal behaviors that are difficult to detect by conventional monitoring methods, such as code segment misalignment and illegal instruction jumps to other code segments, thus further expanding the scope of fault and attack detection.

[0096] This invention employs a segment and step naming convention based on functions. Segment and step numbers are unique within the same function, and their numbers are independent between different functions, forming isolated namespaces bounded by functions. The segment signature tables and inter-segment transfer relationships corresponding to different functions are independent, preventing identifier conflicts. It supports configuring monitoring rules individually for any number of target functions within the system, allowing flexible selection of functions to enable program flow protection. This facilitates modular deployment and incremental expansion, adapting to the multi-tasking, multi-function software architecture of large-scale embedded software.

[0097] This invention reduces the resource consumption of the computer, with low overall static storage overhead for the segment signature table and the legal transfer table between segments; storage overhead increases linearly and gradually as the number of branches increases. During program execution, the monitoring logic only needs to maintain three types of runtime variables: the current line segment identifier, the previous line segment identifier, and the signature register; the monitoring operations only include lightweight operations such as shift, XOR, and CRC, without the need for complex calculations, resulting in low processor power consumption and no significant impact on the real-time performance of the business.

[0098] This invention reduces the probability of false alarms through a deterministic verification mechanism. All signature operations and transition relationship determinations in this invention are deterministic logic, eliminating strategies such as statistical discrimination that are prone to misjudgment. By appropriately configuring the signature register length, the collision probability can be reduced to a negligible level in engineering applications; the operation is stable and controllable, avoiding false alarms caused by algorithmic uncertainties and improving the reliability of the program flow monitoring system.

[0099] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. A program flow monitoring method based on segmented signatures and inter-segment transfer relationships, characterized in that, This includes preprocessing steps and runtime monitoring steps: Preprocessing steps: Step 1: Analyze the monitored program function, identify the conditional branch points in the program function, and divide the program function into multiple line segments according to the conditional branch points; Step 2: Construct a segment identifier for each line segment; configure an initial signature value for each line segment and calculate the corresponding expected signature value; store the segment identifier, initial signature value, and expected signature value for each line segment; Step 3: Based on the control flow structure of the program function, store all legal transfer relationships between line segments in the form of a combination of source segment identifier and target segment identifier; Program runtime monitoring steps: Step 4: Save the segment identifier of the previous running line segment; If the previously executed line segment is a valid value, then query the valid transition relationship between the previously executed line segment and the current line segment, and determine whether the transition relationship between the previously executed line segment and the current line segment is valid. If the transition relationship is invalid, then trigger fault handling. If the transfer relationship is valid, then read the initial signature value of the current line segment and set the initial value of the signature register to the initial signature value of the current line segment. Step 5: When executing each step in a straight line segment, first check whether the segment identifier of the straight line segment to which the step belongs is consistent with the segment identifier of the currently running straight line segment. If they are inconsistent, trigger fault handling. If they match, input the identifier of the current step into the signature update function to update the operation value of the signature register; Step Six: When exiting the monitoring of the current line segment, read the expected signature value of the current line segment stored in the preprocessing step, compare the current operation value of the signature register with the expected signature value. If the comparison matches, the line segment is verified; if the comparison does not match, fault handling is triggered.

2. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 1, characterized in that: In step one, the split line segment does not contain conditional branch statements, has only one entry point and one exit point, and has only one step execution path.

3. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 1, characterized in that: In step two, the expected signature value is calculated as follows: starting from the initial signature value of the line segment, the identifier of each step is sequentially input into the signature update function according to the order of execution steps within the segment to accumulate and obtain the expected signature value.

4. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 3, characterized in that: The signature update function uses any of the following operations: XOR operation with the step identifier after circular left shift, XOR operation with the step identifier after linear feedback shift register operation, or CRC operation.

5. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 1, characterized in that: In step two, the initial signature value for each line segment is configured by a random number provided by an external watchdog.

6. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 1, characterized in that: In step three, when storing all legal transfer relationships between line segments, a time window field is added to set the transfer time between line segments.

7. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 1, characterized in that: In step four, at the start of the runtime monitoring step, both the current line segment identifier and the previous line segment identifier are set to invalid values; if the segment identifier of the previous line segment of the current line segment is invalid, the verification of the legal transfer relationship between segments is skipped, and the initial value setting operation of the signature register is directly executed.

8. The program flow monitoring method based on segmented signatures and inter-segment transfer relationships as described in claim 1, characterized in that: In step five, the step verification within the line segment is performed sequentially according to the step execution order; after the current step completes the verification and the signature update function in the signature register, it is determined whether there is a next execution step within the line segment. If there is, the verification and signature update function of the next step are executed; if not, the process proceeds to step six.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, it implements the method of any one of claims 1 to 8.

Images