Firmware backdoor detection and one-key security restoration method and system

Abstract

The invention discloses a firmware backdoor detection and one-key security restoration method and system, and relates to the technical field of software detection. The method comprises the steps of obtaining an original byte sequence of a firmware upgrade package; performing segmented structure analysis and standardization on an original byte sequence of the firmware upgrade package to obtain a byte interval index of each segment and an upgrade package segment list; extracting ciphertext statistical characteristics of each segment based on the byte interval index and generating an upgrade package statistical fingerprint; comparing the statistical fingerprint of the upgrade package with a historical baseline to obtain a ciphertext anomaly score; when the ciphertext exception score exceeds a verification trigger threshold value, generating an equipment end verification task and collecting equipment end verification evidence; performing fusion judgment on the basis of the ciphertext anomaly score and the equipment end verification evidence, and outputting a comprehensive risk level and a recommended disposal action; according to the method, the risk detection can be realized without depending on a decryption key or a differential synthetic material, so that the security of firmware upgrading is ensured, and the operation and maintenance efficiency is also considered.

Description

Technical Field

[0001] This invention relates to the field of software detection technology, and more specifically, to a method and system for firmware backdoor detection and one-click secure restore. Background Technology

[0002] In remote maintenance and secure operation and maintenance scenarios for IoT terminals, industrial control equipment, and various embedded products, device firmware is typically distributed and updated over the network. To meet the requirements of upgrade efficiency, transmission bandwidth constraints, and supply chain security for mass-produced equipment, firmware publishers generally employ mechanisms such as encrypted encapsulation, differential upgrades, and segmented signatures to ensure the confidentiality and integrity of the upgrade package during transmission and storage. The device itself performs verification, restoration, and writing during the boot chain or upgrade process. Meanwhile, to identify whether the firmware has been implanted with a backdoor, the operation and maintenance team or a third-party testing team typically needs to perform format parsing and unpacking of the firmware package, reconstruct the file system or executable image, and then conduct a security assessment based on file differences, sensitive path scanning, binary feature analysis, and behavioral simulation. Based on this assessment, they decide whether to trigger a one-click restore or replace it with a trusted firmware version.

[0003] However, when the detection side can only obtain the upgrade package itself but not the device-side key, cannot complete decryption in the detection environment, and cannot obtain the old firmware image, differential algorithm parameters, or restoration execution conditions necessary for differential restoration, the plaintext asset reconstruction chain upon which firmware detection relies cannot be established. Because encrypted encapsulation makes the file system and executable image invisible to the detection side, and differential data cannot be directly mapped to the complete target firmware, segmented signatures and private containers further raise the threshold for parsing and restoration. This makes it difficult for the detection side to perform fine-grained analysis of the firmware content, making it impossible to locate potential backdoor files or logical paths, or determine whether abnormal behavior originates from internal firmware code or configuration. Even if the detection side can verify the outer layer of the upgrade package through digests, signatures, or message authentication codes, such verification can only prove the integrity and source credibility of the upgrade package during transmission and storage, and cannot equivalently deduce that there are no backdoors or malicious logic inside the firmware. This restricts firmware backdoor detection at critical entry points, and detection conclusions are prone to remaining in a state of inconclusiveness or only coarse-grained inference based on limited metadata.

[0004] If the aforementioned issues exist, they will directly weaken the ability to detect and restore backdoors with a single click. This will prevent the operations and maintenance system from making timely and reliable judgments when faced with highly sophisticated upgrade packages, potentially leading to the continuous distribution and installation of backdoor firmware on a large number of devices. This could create long-term, latent remote control channels or data leakage channels, and when triggering conditions are met, cause mass device failures, business interruptions, and the spread of security incidents. Furthermore, in the absence of explainable evidence and verifiable conclusions, the operations and maintenance team will find it difficult to take timely measures such as isolation, rollback, or forced recovery. This increases incident response costs and reliance on the supply chain and on-site environment, potentially leading to production stoppages and the leakage of sensitive information.

[0005] In view of this, the present invention proposes a firmware backdoor detection and one-click secure restore method and system to solve the above problems. Summary of the Invention

[0006] To overcome the aforementioned deficiencies of the prior art and achieve the above objectives, the present invention provides the following technical solution: a firmware backdoor detection and one-click secure restore method, comprising:

[0007] Obtain the raw byte sequence of the firmware upgrade package;

[0008] The original byte sequence of the firmware upgrade package is segmented and standardized to obtain the byte range index of each segment and the upgrade package segment list;

[0009] Based on the byte range index, the ciphertext statistical features of each segment are extracted and the upgrade package statistical fingerprint is generated; the upgrade package statistical fingerprint is compared with the historical baseline to obtain the ciphertext anomaly score;

[0010] When the ciphertext anomaly score exceeds the verification trigger threshold, a device-side verification task is generated and device-side verification evidence is collected.

[0011] Based on the fusion of encrypted anomaly scoring and device-side verification evidence, a comprehensive risk level and recommended action are output.

[0012] When the recommended action is to restore, a one-click restore operation is triggered.

[0013] Furthermore, the original byte sequence is sliced ​​according to the segmented byte interval index to obtain segmented byte sequences, and the ciphertext statistical features are calculated on the segmented byte sequences to obtain the upgrade package statistical fingerprint.

[0014] Furthermore, using a set window length in bytes, the Shannon entropy sequence of the segmented byte sequence is calculated by sliding calculation, and the mean, variance, and peak position are taken to obtain the entropy features; the segments are divided into blocks according to the window length in bytes to calculate the proportion of repeating blocks and the block diversity; the byte frequency histogram of the segmented byte sequence is calculated and normalized; the entropy features, proportion of repeating blocks, block diversity, and byte frequency histogram of each segment are sequentially concatenated to generate segmented statistical features; all segmented statistical features are aggregated to generate the statistical fingerprint of the upgrade package.

[0015] Furthermore, the upgrade package statistical fingerprint is used to perform similarity retrieval in the pre-built historical upgrade package statistical fingerprint set. According to the similarity from high to low, multiple historical samples are selected in sequence and the set identifier of the corresponding historical samples is output to obtain the similar historical sample set identifier.

[0016] Using the identifier of similar historical sample set, for comparable segments in the upgrade package segment list, based on the segment type identifier and segment number, the historical segment statistical features corresponding to the identifier of similar historical sample set are selected as the comparison baseline from the pre-constructed historical segment statistical feature set, and the feature deviation is calculated based on the difference of segment statistical features.

[0017] The feature deviation of each comparable segment relative to each historical sample segment is organized into a matrix according to the segment number and the historical sample identifier to obtain the segment-level deviation matrix.

[0018] The segment-level deviation matrix is ​​analyzed into segment-level deviation scores.

[0019] Furthermore, the upgrade package segment list is compared with the pre-built normal segment template subset one by one to verify the consistency of the number of segments, and the structural consistency result is obtained.

[0020] The structural consistency results are parsed as structural deviation scores.

[0021] Further, the upgrade package verification field set is parsed and filled from the original byte sequence; according to the coverage of the verification fields described in the upgrade package verification field set, the digest of the corresponding byte interval of the original byte sequence is calculated and compared with the verification fields to obtain the comparison result; the signature field is verified using the pre-acquired vendor public key certificate set to obtain the verification conclusion; the upgrade package verification result record includes the comparison result and the verification conclusion.

[0022] The upgrade package verification result record is parsed into a signature score;

[0023] The encrypted anomaly score is obtained by weighting and summing the structural deviation score, segment-level deviation score, and signature verification score according to the weights in the pre-configured handling strategy parameters.

[0024] Furthermore, the device-side verification evidence includes isolated network traffic digest data, running process tree digest data, running port listening digest data, running file write digest data, startup chain metric digest data, key file hash value list, device security metric signature information, and signature verification result record;

[0025] After determining the comparison criteria based on the handling strategy parameters, the file path in the list of key file hash values ​​is used as the key to retrieve hash values ​​with the same path from the historical operational behavior baseline summary set and perform consistency comparison to obtain the key file deviation count.

[0026] A consistency comparison was performed on the startup chain metric summary data to obtain a startup chain deviation conclusion.

[0027] Anomaly comparison is performed on isolated network traffic summary data to obtain the set of newly added destination addresses and anomaly time-series characteristics of the isolated network traffic summary data.

[0028] A correlation analysis was performed on the running process tree summary data, the running port listening summary data, and the running file write summary data to form a behavioral correlation graph, and a structural difference score was calculated.

[0029] Recommended actions include a set of actions corresponding to isolation, restoration, and rollback.

[0030] Furthermore, based on the upgrade package segment list, segment statistical features, similar historical sample set identifiers, and disposal strategy parameters, a set of metrics is calculated; the set of metrics is weighted and aggregated according to the weight set in the disposal strategy parameters to obtain an uncertainty measurement record; the confidence of the encrypted anomaly score is corrected based on the uncertainty measurement record to obtain the corrected encrypted anomaly score.

[0031] The corrected ciphertext anomaly score, key document deviation count, initiation chain deviation conclusion, newly added destination address set of isolated network traffic digest data, anomaly timing features, structural difference score, and signature verification result record are fused together to obtain the fusion risk score.

[0032] Furthermore, the overall risk level is obtained by mapping the fusion risk score according to the threshold rules in the disposal strategy parameters. The disposal strategy parameters provide a set of overall risk level thresholds and limit the order relationship between each threshold. During the mapping, the fusion risk score is compared with the set of overall risk level thresholds one by one.

[0033] Using the comprehensive risk level as the entry point, candidate rules that meet the comprehensive risk level are retrieved from the pre-configured set of action rules. Then, the triggering conditions of each candidate rule are determined by combining the encrypted anomaly score, key document deviation count, initiation chain deviation conclusion, new destination address set and anomaly timing characteristics of isolated network traffic digest data, structural difference score and signature verification result record. When the triggering conditions are met, the corresponding set of handling actions is output according to the set of action rules.

[0034] Firmware backdoor detection and one-click secure restore system, including:

[0035] The acquisition module is used to obtain the raw byte sequence of the firmware upgrade package;

[0036] The segmentation module is used to parse and standardize the original byte sequence of the firmware upgrade package into segments, and obtain the byte range index of each segment and the upgrade package segment list.

[0037] The scoring module extracts the ciphertext statistical features of each segment based on the byte range index and generates the upgrade package statistical fingerprint; the upgrade package statistical fingerprint is compared with the historical baseline to obtain the ciphertext anomaly score;

[0038] The task module is used to generate a device-side verification task and collect device-side verification evidence when the ciphertext anomaly score exceeds the verification trigger threshold.

[0039] The judgment module performs a fusion judgment based on the encrypted anomaly score and the device-side verification evidence, and outputs a comprehensive risk level and recommended action.

[0040] The restore module is used to trigger a one-click restore operation when the recommended action is restore.

[0041] Compared with existing technologies, the technical effects and advantages of the firmware backdoor detection and one-click secure restore method and system of the present invention are as follows:

[0042] This invention, without decrypting the firmware upgrade package or reconstructing the file system, first collects information such as device hardware fingerprint, boot chain status, and partition layout, obtains the original byte sequence and source identifier of the upgrade package, and completes evidence sealing. Then, through segmented structure parsing and standardization, it obtains a segment list and byte interval index, extracts the ciphertext statistical features of each segment to generate an upgrade package statistical fingerprint, compares it with the historical baseline to obtain a ciphertext anomaly score, and triggers a device-side verification task based on the uncertainty quantification result. It collects device-side verification evidence, and outputs a comprehensive risk level and recommended action after multi-source evidence fusion. When recommending restoration, it triggers a one-click restoration operation.

[0043] This invention effectively solves the problems of interrupted detection chains, difficulties in fine-grained analysis, and unreliable detection conclusions caused by firmware encryption and encapsulation, differential upgrades, and segmented signatures in existing technologies. It can achieve risk detection without relying on decryption keys or differential synthesis materials. The detection dimensions cover multiple aspects such as ciphertext features, structural consistency, and runtime behavior. The judgment results are supported by sufficient evidence, and the handling process is safe, controllable, and traceable. It not only ensures the security of firmware upgrades but also takes into account operational efficiency. It is compatible with different hardware models and startup chain states and has strong practicality and compatibility. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the firmware backdoor detection and one-click secure restore system according to an embodiment of the present invention;

[0045] Figure 2 This is a flowchart of the firmware backdoor detection and one-click secure restore method according to an embodiment of the present invention;

[0046] Figure 3 This is a flowchart of the method for calculating ciphertext anomaly scores according to an embodiment of the present invention;

[0047] Figure 4 This is a schematic diagram of the industrial control computer in this invention.

[0048] Attached image label: 1. One-click restoration of physical buttons. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be described in detail, clearly, and completely below with reference to the accompanying drawings. It should be particularly noted that the specific embodiments described below are only for better illustrating and explaining the technical solutions of the present invention, and are intended to enable those skilled in the art to better understand and implement the present invention, and should not be construed as limiting the scope of protection of the present invention. Without departing from the spirit and substance of the present invention, those skilled in the art can modify, adjust, or make equivalent substitutions based on the content disclosed in the present invention, and these should all be considered within the scope of protection of the present invention.

[0050] Example 1:

[0051] Please see Figure 1 As shown, this embodiment discloses a firmware backdoor detection and one-click secure restore system, including an acquisition module, a segmentation module, a scoring module, a task module, a judgment module, and a restore module. Each module is connected via wired and / or wireless connections to achieve data transmission.

[0052] The acquisition module is used to obtain the raw byte sequence of the firmware upgrade package.

[0053] The system collects device hardware fingerprint information, device boot chain status information, and device partition layout information. The device boot chain status information is obtained by reading boot loader variables, boot logs, and the status of the security boot switch to record whether boot verification is enabled and whether debug mode is allowed. The device partition layout information is obtained by reading the partition table and the starting offset, length, and purpose identifier of each partition in read-only mode to form a partition layout record. The system downloads and saves the original byte sequence of the upgrade package and the upgrade package source identifier information. The original byte sequence of the upgrade package is obtained from the upgrade server or media and saved byte-for-byte without decoding. The upgrade package source identifier information is used to record source metadata such as download channel, distribution node identifier, acquisition time, filename, and version identifier. A hash value is calculated for each of the above collected items.

[0054] The original byte sequence of the upgrade package is parsed to obtain and populate the upgrade package verification field set. The upgrade package verification field set is parsed from the header and footer of the upgrade package to obtain the signature field, digest field, message authentication field, and their coverage description. Specifically, according to the firmware container parsing rules, the verification field area and signature field area are located from the header region of the original byte sequence of the upgrade package. Each verification item in the verification field area is read, and the field type, field length, field value, coverage description, and digest algorithm identifier of each verification item are written into the upgrade package verification field set. When the verification field area contains multiple verification items, the upgrade package verification field set is parsed and populated sequentially according to the order of appearance of the verification items in the original byte sequence of the upgrade package, ensuring that the upgrade package verification field set can completely describe the coverage and algorithm parameters required for subsequent digest calculation.

[0055] After filling the set of verification fields in the upgrade package, a digest is calculated for the corresponding byte interval of the original byte sequence of the upgrade package according to the coverage description of each verification item in the set of verification fields, and compared with the verification fields. Specifically, for each verification item, the start offset and end position defined in its coverage description are read, the corresponding byte interval is extracted from the original byte sequence of the upgrade package, and the digest algorithm identified by the verification item is used to calculate the digest for the byte interval. The calculated digest is compared with the digest value recorded in the field value of the verification item, and the comparison result is written to the verification field comparison result subfield of the verification result record of the upgrade package verification result. When the coverage description contains multiple non-contiguous byte intervals, the digests of the multiple non-contiguous byte intervals are updated according to the interval order determined by the coverage description, and the final calculated digest is generated. Then, a consistency comparison is performed with the digest value recorded in the verification item, thereby ensuring that the coverage description can be processed consistently under different encapsulation methods. If any verification item fails to match, an upgrade package verification failure reason record is generated. The upgrade package verification failure reason record shall include at least the failed verification item identifier, the description of the failure coverage, the judgment result that the calculated summary and the verification field summary value are inconsistent, and the corresponding start offset and end position for subsequent traceability.

[0056] The signature field is then verified using the vendor's public key certificate set. The vendor's certificate chain and revocation information are exported from trusted storage within the device or imported from a controlled distribution library to obtain the vendor's public key certificate set. Specifically, the signature field is located from the original byte sequence of the upgrade package and parsed to obtain the signature value and signature algorithm identifier. The data range covered by the signature is determined according to the firmware container parsing rules. The signed data is extracted from the original byte sequence of the upgrade package according to the data range covered by the signature, and a verification digest is calculated. The public key certificates in the vendor's public key certificate set are traversed, and the signature value is verified using a verification algorithm consistent with the signature algorithm identifier. A conclusion of successful or failed verification is obtained, and the verification conclusion is written to the signature field verification result subfield of the upgrade package verification result record. If a successful verification conclusion cannot be obtained after traversing the vendor's public key certificate set, an upgrade package verification failure reason record is generated. The upgrade package verification failure reason record includes at least the signature algorithm identifier, a description of the data range covered by the signature, the set of public key certificate identifiers used, and the verification failure conclusion to support subsequent location of reasons such as certificate mismatch, signature tampering, or abnormal signature coverage.

[0057] After completing the digest comparison of the verification fields and the signature verification of the signature field, an upgrade package verification result record is generated. The upgrade package verification result record includes at least the parsing status of the upgrade package verification field set, a subfield of the verification field comparison result for each verification item, a subfield of the signature field verification result, and a comprehensive verification conclusion field generated based on the above results. The comprehensive verification conclusion field is used to characterize the final result of the outer layer authenticity and integrity verification. When any verification field comparison result or signature field verification result fails, the comprehensive verification conclusion field is marked as failed and associated with the corresponding upgrade package verification failure reason record identifier. When all verification field comparison results are passed and the signature field verification result is passed, the comprehensive verification conclusion field is marked as passed and the public key certificate identifier and digest algorithm identifier used are recorded to ensure that the verification process is reproducible and auditable.

[0058] The segmentation module is used to parse and standardize the original byte sequence of the firmware upgrade package into segments, and obtain the byte range index of each segment and the upgrade package segment list.

[0059] First, the upgrade package verification result record is read to confirm the outer layer authenticity and integrity verification status corresponding to the original byte sequence of the upgrade package. This status is then written into the record field of the upgrade package segment list as a subsequent parsing credibility identifier. Next, the firmware container parsing rules are loaded, and the target write partition set and its capacity boundaries are determined based on the device partition layout information. This is used to perform consistency verification on the segment lengths and mapping relationships in the original byte sequence of the upgrade package, preventing segment lengths from exceeding the writable range limited by the device partition layout information.

[0060] Next, a structural scan is performed on the original byte sequence of the upgrade package. The structural scan begins at the start of the original byte sequence and sequentially parses the container header fields according to the firmware container parsing rules to obtain segment quantity information or segment directory information, and obtains the starting offset of the first segment. If the firmware container parsing rules define a segment directory, each segment directory entry is read, and the starting offset, length, segment type identifier, and segment-level verification description of each segment are extracted. If the firmware container parsing rules do not define a segment directory and use sequential concatenation, the segment header fields are read from the current scan position according to the firmware container parsing rules, the segment type identifier and segment-level verification description are extracted, and the length of the segment is parsed from the segment header fields. The current scan position is determined as the starting offset of the segment, and then the current scan position is advanced to the end position of the segment to continue parsing the next segment. Boundary checks are performed on each segment, requiring that the ending position determined by the starting offset and length does not exceed the total length of the original byte sequence of the upgrade package. At the same time, the target write partition capacity corresponding to the segment type identifier is checked in conjunction with the device partition layout information. In the case of alignment padding, the padding area is identified and skipped according to the firmware container parsing rules, so that the starting offset of the subsequent segment falls on the alignment boundary required by the firmware container parsing rules.

[0061] After locating the start offset and length of each segment and extracting the segment type identifier and segment-level verification description, the segment information is standardized using a unified field. This unified field includes the segment number, start offset, length, end position, segment type identifier, segment-level verification description, and a resolution credibility identifier derived from the upgrade package verification result record. Then, an upgrade package segment list is generated in segment order. The segment byte range index is generated simultaneously with the upgrade package segment list. The segment byte range index uses the segment number as the key, determines the byte range using the start offset and end position from the unified field, and saves the slice boundary information of the byte range in the original byte sequence of the upgrade package. This allows subsequent steps to directly locate and extract the corresponding segment's byte sequence from the original byte sequence of the upgrade package based on the segment byte range index. If the firmware container parsing rules allow nested containers, when a segment is identified as a container type, the byte range of that segment is recursively scanned according to the firmware container parsing rules. The recursively obtained sub-segments are then standardized according to a unified field and appended to the upgrade package segment list. At the same time, a corresponding segment byte range index is generated for the sub-segment. The start offset and end position of the sub-segment are recorded with their absolute positions in the original byte sequence of the upgrade package, ensuring that the segment byte range index can always be directly used for locating and truncating the original byte sequence of the upgrade package.

[0062] The scoring module extracts the ciphertext statistical features of each segment based on the byte range index and generates the upgrade package statistical fingerprint; the upgrade package statistical fingerprint is compared with the historical baseline to obtain the ciphertext anomaly score.

[0063] The original byte sequence of the upgrade package is sliced ​​according to the segmented byte range index to obtain segmented byte sequences. Specifically, the segmented byte range index provides the start offset and end position of each segment in the original byte sequence of the upgrade package. The start offset and end position are read sequentially according to the segmentation order in the segmented byte range index, and a continuous byte range is truncated from the start offset to the end position in the original byte sequence of the upgrade package to obtain the corresponding segmented byte sequence. When the segmented byte range index indicates the existence of sub-segments of nested containers, slicing is also performed using the absolute start offset and absolute end position of the sub-segment in the original byte sequence of the upgrade package to ensure a traceable one-to-one correspondence between the segmented byte sequence and the original byte sequence of the upgrade package. The start offset and end position used for slicing are written into the record field of the segmented statistical feature set for subsequent audit and review.

[0064] After obtaining the segmented byte sequence, ciphertext statistical features are calculated for the segmented byte sequence. First, a sliding window entropy calculation is performed on the segmented byte sequence. The sliding window entropy calculation uses a window length of 4096 bytes and slides along the segmented byte sequence from front to back with a preset step size. For each window interval, the frequency of bytes from 0 to 255 within that window interval is counted and converted into a probability distribution. Based on the probability distribution, the Shannon entropy value is calculated, thus forming a Shannon entropy sequence. Then, the mean, variance, and peak position are extracted from the Shannon entropy sequence as entropy features. The window length of 4096 bytes is used to balance the ability to distinguish local structural changes and statistical stability on the segmented byte sequence. This allows the entropy features to reflect both highly random segments caused by compression or encryption and local random mutations caused by insertion, padding, or abnormal structures, thereby improving the detectability of potential anomalies without decrypting the firmware upgrade package. While maintaining the comparability of encrypted statistical features and cross-version consistency, the window length is not limited to a unique 4096 bytes. It is allowed to configure the window length to other fixed lengths. When generating the statistical fingerprint of the upgrade package, the window length is written as a parameter into the segmented statistical feature set to ensure historical baseline alignment. When the window length changes, the sliding window entropy calculation still calculates the probability distribution of statistical bytes for each window interval and calculates the Shannon entropy sequence in the manner described above. The method of extracting the mean, variance and peak position of the Shannon entropy sequence remains unchanged to ensure that the feature definition is consistent under different window lengths and can be compared through parameter alignment.

[0065] Secondly, block repetition calculation is performed on the segmented byte sequence. The block repetition calculation divides the segmented byte sequence into several consecutive blocks from beginning to end using a block length of 4096 bytes. For each block, a block hash value is calculated to form a block hash value sequence. The proportion of repeated block hash values ​​in the block hash value sequence is calculated to obtain the repetition block ratio. Simultaneously, the ratio of the number of different block hash values ​​in the block hash value sequence to the total number of blocks is calculated to obtain block diversity. The block length of 4096 bytes is consistent with the window length of the aforementioned sliding window entropy calculation, which is beneficial for simultaneously capturing two complementary types of information—randomness and repetition—on the same scale. This allows for a stable representation of phenomena such as anomalous implantation, anomalous padding, and anomalous fragment reuse even when the key is unavailable. The block length can also be configured to other fixed lengths, and the block length parameter is recorded in the segmented statistical feature set. When the block length changes, the block repetition calculation still divides the consecutive blocks with the new block length and performs statistical calculations on the repetition block ratio and block diversity of the block hash value sequence, ensuring that the feature calculation process and statistical meaning remain unchanged.

[0066] The byte frequency histogram is calculated again for the segmented byte sequences. The byte frequency histogram uses indices from 0 to 255 to count the frequency of each byte value in the segmented byte sequence, and divides this count by the segmented byte sequence length to obtain a normalized frequency vector. This normalized frequency vector characterizes the overall distribution of the segmented byte sequence, and together with entropy features and block repetition features, constitutes a multi-perspective description of the observable statistical properties of the ciphertext, thereby improving the ability to identify abnormal deviations without decrypting the firmware upgrade package. To ensure comparability between different segment lengths, the byte frequency histogram must be normalized, and the normalization method is written into the record field of the segmented statistical feature set to ensure historical consistency.

[0067] After calculating the encrypted statistical features, the entropy features, repeating block ratio, block diversity, and byte frequency histogram of each segment are concatenated in a fixed order to generate segmented statistical features. The segment number, start offset, end position, window length, and block length parameters corresponding to each segment are also written into the segmented statistical feature set. Subsequently, aggregation is performed on all segmented statistical features to generate an upgrade package statistical fingerprint. The aggregation includes at least concatenating the segmented statistical features in segmented order to obtain a package-level feature vector, or performing package-level statistical aggregation on the numerical features in the segmented statistical features and associating them with the segmented structure information to generate a package-level fingerprint vector. When using package-level statistical aggregation, the window length and block length parameters are also written into the upgrade package statistical fingerprint to ensure alignment and comparability with the historical upgrade package statistical fingerprint set.

[0068] This embodiment aligns structural template constraints with historical statistical baselines, transforming ciphertext statistical deviations under undecryptable conditions into comparable and locatable anomaly references, thus providing a stable basis for subsequent anomaly scoring and device-side verification triggering. First, device hardware fingerprint information is generated and confirmed. This information is obtained by the device diagnostic agent or recovery mode, which reads hardware identification fields such as the main control model, hardware version number, storage media type, and board serial number from the device and concatenates them according to a preset fixed field order to generate a fingerprint record. When the device diagnostic agent is unavailable, the recovery mode reads the same fields and concatenates them according to the same fixed field order, ensuring consistency and comparability of the device hardware fingerprint information across different acquisition paths.

[0069] After obtaining the device hardware fingerprint information, the corresponding normal segmentation template subset is selected using the device hardware fingerprint information. The normal segmentation template is formed by extracting the number of segments, segment order, segment type, and length range from historical upgrade packages in the controlled release library that match the device hardware fingerprint information. The length range is obtained by statistically analyzing the length distribution of the same segment type in multiple historical upgrade packages and is fixed as an allowed range to ensure that the structure comparison can tolerate the length fluctuations brought about by normal version evolution while still providing sensitive constraints for abnormal insertion, abnormal replacement, or abnormal expansion. For historical upgrade packages in the controlled release library, segmentation structure records are generated according to the segmentation structure parsing and standardization method described above. Then, the number of segments, segment order, segment type, and length range are extracted from the segmentation structure records to construct the normal segmentation template. The version set identifier and statistical caliber parameters used for construction are written into the metadata field of the normal segmentation template to ensure consistency in subsequent traceability.

[0070] Subsequently, a structural consistency comparison is performed. The upgrade package segment list and the normal segment template subset are checked one by one for segment quantity consistency. This verifies whether the number of segments in the upgrade package segment list matches the number of segments in the normal segment template. If the number of segments matches, a segment type sequence consistency check is further performed. This verifies whether the segment type identifier sequence arranged in segment order in the upgrade package segment list matches the segment type sequence in the normal segment template. If the segment type sequence matches, the length interval deviation is calculated for each segment. The length interval deviation is obtained by comparing the length of the corresponding segment in the upgrade package segment list with the length interval of the corresponding segment type in the normal segment template. When the segment length falls within the length interval, the length interval deviation is recorded as zero or marked as satisfied. When the segment length exceeds the length interval, the length interval deviation is quantified according to the extent of the excess and associated with the segment number, thus forming a structural consistency result. The structural consistency result includes at least the segment quantity consistency check result, the segment type sequence consistency check result, and the length interval deviation set for each segment.

[0071] After completing the structural consistency comparison, a baseline retrieval is performed. The historical upgrade package statistical fingerprint set is obtained by extracting and calculating the upgrade package statistical fingerprint from the historical upgrade packages in the controlled release library and the encrypted statistical features, and then storing it in the library. When storing, each upgrade package statistical fingerprint is bound to the corresponding device hardware fingerprint information, version identifier, and source identifier to ensure that subsequent retrieval can be aligned and compared within the range corresponding to the device hardware fingerprint information.

[0072] Please see Figure 3 As shown, the methods for calculating ciphertext anomaly scores include:

[0073] The upgrade package statistical fingerprint is used to perform similarity retrieval in the historical upgrade package statistical fingerprint set. The similarity retrieval first filters the historical upgrade package statistical fingerprint set according to the device hardware fingerprint information to obtain a candidate set. Then, the similarity between the upgrade package statistical fingerprint and each historical upgrade package statistical fingerprint in the candidate set is calculated and sorted according to the similarity. Multiple historical samples are selected in order of similarity from high to low and the set identifier of the corresponding historical sample is output to obtain the similar historical sample set identifier, which is used for subsequent anomaly reference and threshold construction.

[0074] After obtaining the identifiers of similar historical sample sets, a segment-level comparison is performed to form a segment-level deviation matrix. The historical segment statistical feature set is obtained by using historical upgrade packages in the controlled release library and the segment structure parsing and standardization method to obtain the segment structure. Then, segment statistical features are calculated for each segment according to the encrypted statistical feature extraction method and stored in the library. During storage, each segment statistical feature is bound to the device hardware fingerprint information, historical upgrade package identifier, segment sequence number, segment type identifier, and segment byte range index parameter to ensure that comparable segments can be correctly aligned. For comparable segments in the upgrade package segment list, based on the segment type identifier and segment number, select the historical segment statistical features corresponding to the similar historical sample set identifier from the historical segment statistical feature set as the comparison baseline, and calculate the feature deviation. The feature deviation is calculated based at least on the differences in entropy features, duplicate block ratio, block diversity, and byte frequency histogram in the segment statistical features. Organize the feature deviation of each comparable segment relative to each historical sample segment into a matrix according to the segment number and historical sample identifier, that is, form a segment-level deviation matrix. The segment-level deviation matrix records the segment number, segment type identifier, and historical sample set identifier used for alignment to ensure the consistency of subsequent anomaly localization and evidence chain citation.

[0075] The encrypted anomaly score is calculated based on the handling strategy parameters. These parameters, defined by the operation and maintenance strategy configuration, include thresholds, confidence thresholds, isolation requirements, restoration conditions, and rollback conditions. They further include a weight set and normalization criteria used for calculating the encrypted anomaly score. The structural consistency result is parsed into a structural deviation score, determined by the segment quantity consistency check result, the segment type sequence consistency check result, and the length interval deviation set. The segment quantity consistency check result and the segment type sequence consistency check result are used to generate the structural consistency penalty term, while the length interval deviation set is used to generate the length deviation penalty term. The segment-level deviation matrix is ​​parsed into a segment-level deviation score, obtained by aggregating the feature deviations of each segment in the segment-level deviation matrix relative to the historical segments identified by the similar historical sample set. During aggregation, the lowest feature deviation value is taken for each segment. The smallest or median value is used as the representative deviation of the segment, and weighted and accumulated according to the segment number and segment type identifier. This allows anomalies concentrated in a few segments to still be identified and located in specific segments. The upgrade package verification result record is parsed into a signature verification score, which is jointly determined by the verification field summary comparison result and the signature field verification result. When the signature field verification fails or the verification field summary comparison fails, the signature verification score takes a higher penalty value. When the signature field verification passes and the verification field summary comparison passes, the signature verification score takes a lower penalty value or zero penalty value. The reason for failure is retained as a scoring explanation field for evidence citation.

[0076] After the above three scores are calculated, the structural deviation score, segment-level deviation score, and signature verification score are weighted and summed according to the weights in the handling strategy parameters to obtain the encrypted anomaly score. The handling strategy parameters provide structural deviation weights, segment-level deviation weights, and signature verification weights. These weights are determined offline and periodically updated based on historical data in the controlled release database by the operation and maintenance strategy configuration. The offline determination includes using historical upgrade packages corresponding to the hardware fingerprint information of the same device as a sample set, constructing a normal sample set and an abnormal sample set according to predetermined labeling rules, and using the normal sample set and the abnormal sample set to calculate the historical distribution of the structural deviation score, segment-level deviation score, and signature verification score, respectively. The structural deviation weights, segment-level deviation weights, and signature verification weights are optimized with the goal of distinguishing between the normal sample set and the abnormal sample set, so that the expected value of the encrypted anomaly score on the normal sample set is lower than the anomaly threshold and the expected value on the abnormal sample set is higher than the anomaly threshold, while meeting the upper limit of false positive rate and upper limit of false negative rate defined by the handling strategy parameters. To ensure the portability of the handling strategy parameters across different device models and hardware versions, the structural deviation score, segment deviation score, and verification score are uniformly normalized and pruned in the offline determination process. The applicable scope of the weights and the corresponding matching conditions of the device hardware fingerprint information are written into the handling strategy parameters, so that the handling strategy parameters can select the corresponding weight set according to the device hardware fingerprint information.

[0077] Specifically, in addition to providing structural deviation weights, segment-level deviation weights, and verification weights, the handling strategy parameters also provide normalization upper limits and pruning rules for structural deviation scores, segment-level deviation scores, and verification scores. First, the structural deviation scores, segment-level deviation scores, and verification scores are normalized and pruned according to their respective normalization upper limits to ensure their values ​​fall within a uniform dimension range. Then, they are multiplied by the structural deviation weights, segment-level deviation weights, and verification weights respectively to obtain weighted components. The sum of these weighted components yields the encrypted anomaly score. The components, normalization parameters, pruning parameters, and weight parameters of the encrypted anomaly score are all written into the scoring metadata field of the encrypted anomaly score to ensure that the score is reproducible, auditable, and easy for subsequent parameter tuning, and to ensure that historical parameter differences can be traced back after the handling strategy parameters are updated.

[0078] To achieve interpretable output of the suspicious segment list, segment contribution is calculated simultaneously when calculating segment-level deviation scores. Segment contribution is determined by the deviation represented by the segment and its corresponding segment weight. The segment weight is given by the handling strategy parameters and obtained offline by statistically analyzing anomaly sensitivity in the historical segment statistical feature set based on segment type identifier and segment sequence number. This ensures that segments with high anomaly sensitivity and high security relevance have a higher contribution to the segment-level deviation score. Segment contribution scores are sorted from highest to lowest to obtain a segment contribution ranking result. This ranking result is used to subsequently determine the segment index range of the suspicious segment list. The ranking result, along with the corresponding segment sequence number and segment type identifier, is written into the record field of the suspicious segment list to ensure consistency between the suspicious segment list and the segment-level deviation matrix and the upgrade package segment list, and to support consistent evidence citation.

[0079] Subsequently, a robust threshold is constructed using the median and absolute deviation, and a confidence interval for the encrypted anomaly score is output. The statistical samples for the median and absolute deviation are provided by the historical encrypted anomaly score distribution corresponding to the historical upgrade package statistical fingerprint set or by the historical encrypted anomaly score distribution identified by the similar historical sample set. The statistical caliber and minimum sample size requirement are specified in the handling strategy parameters. Based on the robust threshold, the encrypted anomaly score is compared with the robust threshold, and the anomaly threshold and confidence threshold in the handling strategy parameters are combined to determine whether to trigger subsequent isolation requirements and device-side verification tasks. Segment indices that deviate beyond the robust threshold are written into the suspicious segment list. The segment indices are determined by the segment contribution ranking result and include at least segment indices whose segment contribution reaches a preset contribution threshold or whose cumulative contribution reaches a preset cumulative threshold. The corresponding segment contribution and representative deviation are recorded for each segment index to support consistency in subsequent evidence citation.

[0080] Simultaneously, uncertainties caused by unobservable factors are written into the uncertainty measurement record. The generation of the uncertainty measurement record is used to quantify the comparability of the current sample relative to the historical baseline and the completeness of the evidence chain, thereby correcting the confidence level of the encrypted anomaly score and imposing conservative strategy constraints on the recommended action in the subsequent fusion and judgment stage. When generating the uncertainty measurement record, the set of measurement items, the normalization upper limit of the uncertainty measurement record, the pruning rules of the uncertainty measurement record, and the weight set of the uncertainty measurement record are first determined based on the handling strategy parameters. The set of measurement items includes at least parameter consistency measurement items, coverage measurement items, alignment integrity measurement items, and verification integrity measurement items, and the judgment conditions and scoring rules required for calculation are pre-configured for each measurement item.

[0081] Subsequently, the values ​​of each metric were calculated, normalized, and pruned. The parameter consistency metric was obtained by reading the window length and block length parameters recorded in the segmented statistical feature set and comparing them with the window length and block length parameters used to construct the similar historical sample set identifiers in the historical segmented statistical feature set. When the window length or block length parameters were inconsistent, the parameter consistency metric value increased according to the degree of inconsistency, and the inconsistent parameter name and value were written into the reason field. The coverage metric was obtained by reading the number of historical samples corresponding to the similar historical sample set identifiers and comparing it with the minimum coverage threshold given by the treatment strategy parameters. When the number of historical samples was lower than the minimum coverage threshold, the coverage metric value increased according to the gap ratio, and the number of historical samples and the minimum coverage threshold were written into the reason field. The alignment integrity metric is obtained by searching the historical segment statistical feature set for each comparable segment in the upgrade package segment list to see if there are any historical segment statistical feature records that match the segment number and segment type identifier of the comparable segment. When a comparable segment cannot find a matching record in the historical segment statistical feature set, the number of missing comparable segments is counted and the missing ratio is calculated. The missing ratio is used as the metric value of the alignment integrity metric, and the missing segment index is written into the cause field. The verification integrity metric is obtained by reading the upgrade package verification result record, determining whether the upgrade package verification result record contains verification result subfields for all verification fields and signature fields, and determining whether there are any unverified fields or incomplete verification chains. When there are unverified fields or incomplete verification chains, the metric value of the verification integrity metric is increased by the penalty range specified by the handling strategy parameters, and the unverified field identifier or incomplete verification chain identifier is written into the cause field.

[0082] After obtaining the values ​​of parameter consistency, coverage, alignment integrity, and validation integrity metrics, each metric is normalized and pruned according to the disposition strategy parameters to fall within a unified dimension range. Then, a weighted aggregation is performed according to the weight set in the disposition strategy parameters to obtain the numerical item of the uncertainty measurement record. This weighted aggregation is achieved by multiplying each normalized metric by its corresponding weight and then summing the results. The numerical item and the cause item of the uncertainty measurement record are written together into the uncertainty measurement record. The cause item at least includes the judgment condition identifier that triggered the addition of the uncertainty measurement item, the corresponding segment index or field identifier, and the statistics used to calculate the metric value. This allows the uncertainty measurement record to be directly used for the generation of coefficients for subsequent confidence level correction and enables the calculation process of the uncertainty measurement record to be reproduced during auditing.

[0083] The task module is used to generate a device-side verification task and collect device-side verification evidence when the encrypted anomaly score exceeds the verification trigger threshold.

[0084] The system reads the verification trigger threshold and uncertainty threshold from the handling strategy parameters, compares the encrypted anomaly score with the verification trigger threshold, and compares the numerical items in the uncertainty measurement record with the uncertainty threshold. When the encrypted anomaly score exceeds the verification trigger threshold or the numerical item in the uncertainty measurement record is higher than the uncertainty threshold, a device-side verification task list is generated. The device-side verification task list consists of the task field set specified by the handling strategy parameters, including at least isolation network requirements, startup to controlled mode requirements, hash measurement requirements for the critical file path list, output startup chain measurement requirements, and output signature requirements. The device-side verification task list records the threshold comparison results generated during the triggering process and the corresponding evidence citation identifier to ensure the traceability of the device-side verification task list.

[0085] After generating the device-side verification task list, the device startup chain status information is read and it is determined whether the device startup chain status information supports controlled mode. When the device startup chain status information does not support controlled mode, the device-side verification task list is downgraded according to the handling strategy parameters. The requirements for starting controlled mode, hashing the critical file path list, outputting startup chain measurement requirements, and outputting signature requirements are adjusted to an unexecutable state. The task content is limited to collecting only runtime process tree digest data, runtime port listening digest data, and runtime file write digest data. At the same time, a confidence reduction flag is written to the device-side verification task list for subsequent confidence correction of relevant evidence during the fusion and judgment stage. The critical file path list is a list of critical paths that must be measured for each type of device, provided by the security policy library, including startup scripts, authentication configurations, network service configurations, system command locations, etc.

[0086] Based on the isolation network requirements in the device verification task list, the device is connected to the isolation network, and the device traffic is mirrored and collected at the isolation gateway to generate isolation network traffic summary data. Based on the boot-to-controlled mode requirements in the device verification task list, the device is put into controlled mode, and runtime process tree summary data, runtime port listening summary data, and runtime file write summary data are collected on the device. Simultaneously, based on the output boot chain metric requirements in the device verification task list, metrics are performed on the boot chain objects, and boot chain metric summary data is generated. Based on the hash metric requirements for the critical file path list in the device verification task list, files in the critical file path list are read item by item, and a list of critical file hash values ​​is generated. Based on the output signature requirements in the device-side verification task list, when the device has a security key or security chip, it generates device security measurement signature information by combining the startup chain metric digest data and the key file hash value list. At the detection end, it uses the vendor's public key certificate set to verify the validity of the device security measurement signature information to generate a signature verification result record. When the device-side verification task list indicates a decrease in credibility, it only collects runtime process tree digest data, runtime port listening digest data, and runtime file write digest data and generates the corresponding collection result record.

[0087] The judgment module performs a fusion judgment based on the encrypted anomaly score and the device-side verification evidence, and outputs a comprehensive risk level and recommended action.

[0088] This embodiment aligns and fuses the encrypted anomaly score obtained under undecryptable conditions with provable metric evidence from the device and observational evidence from the isolated environment to improve the credibility of backdoor detection conclusions without relying on plaintext firmware content, and outputs recommended actions consistent with the risk level to reduce the risk of mishandling and omission.

[0089] First, a consistency comparison of the key document hash value list is performed. After determining the comparison criteria based on the handling strategy parameters, using the file path in the key document hash value list as the key, hash values ​​with the same path are retrieved from the historical operational behavior baseline summary set and compared for consistency. The historical operational behavior baseline summary set is formed by collecting process, port, file write, and network external connection summaries of verified firmware in a controlled environment. When a hash value with the same path exists but is inconsistent with the hash value in the key document hash value list, the file path is added to the deviation path list and the key document deviation count is accumulated. When a hash value with the same path does not exist, the file path is added to the deviation path list and marked as a baseline missing type in the deviation path list for subsequent confidence correction based on uncertainty measurement records. When a hash value with the same path exists and is consistent, it is recorded as a success of consistency. After the comparison is completed, the key document deviation count and the deviation path list are output, and the hash values ​​participating in the comparison in the key document hash value list, the corresponding historical operational behavior baseline summary set entry identifiers, and the comparison conclusions are written into the key document evidence citation field of the evidence chain citation list to ensure traceability of evidence citations.

[0090] Subsequently, a consistency comparison of the startup chain metric summary data is performed. Based on the handling strategy parameters, the set of metric objects and the metric chain caliber of the startup chain metric summary data are determined. The identifiers and metric values ​​of each metric object in the startup chain metric summary data are compared with the baseline startup chain metrics recorded in the historical operational behavior baseline summary set. When any metric object identifier is missing or the metric value is inconsistent, a startup chain deviation conclusion is output, and the set of deviation object identifiers and the reason for the deviation are recorded. Simultaneously, the source identifier, collection time identifier, and the corresponding signature verification result in the signature verification result record of the startup chain metric summary data are bound to the evidence chain reference list to characterize the credible source of the startup chain metric summary data. When all metric objects are consistent, the startup chain deviation conclusion is output as consistent, and the identifier of the baseline startup chain metric entry used for the consistency comparison is written into the startup chain evidence reference field of the evidence chain reference list.

[0091] After completing the comparison of the startup chain metric digest data, anomaly comparison of the isolated network traffic digest data is performed. The isolated network traffic digest data is parsed using the statistical caliber of the external digests specified by the handling strategy parameters to obtain the destination address set, port set, session count sequence, and time series digest. The baseline external digest corresponding to the device hardware fingerprint information and version identifier is used as the comparison baseline. Corresponding entries are retrieved from the historical operational behavior baseline digest set and differences are compared. When a destination address not present in the baseline external digest appears in the isolated network traffic digest data, it is added to the new destination address set, and its frequency and time window are recorded. When the session count sequence and time series digest show sudden or periodic changes inconsistent with the baseline external digest, abnormal timing features are output, and the corresponding time window and difference magnitude are recorded. The new destination address set, abnormal timing features, and corresponding isolated network traffic digest data entry identifiers are written to the external evidence reference field of the evidence chain reference list to ensure consistency with the isolation requirements of the recommended handling actions.

[0092] A correlation analysis is performed on the runtime process tree summary data, runtime port listening summary data, and runtime file write summary data to form a behavioral correlation graph and calculate a structural difference score. The runtime process tree summary data is parsed into a set of process identifiers and a set of parent-child process relationships; the runtime port listening summary data is parsed into a set of process identifiers and a set of port listening relationships; and the runtime file write summary data is parsed into a set of process identifiers and a set of file write relationships. The three sets of relationships are then merged using the process identifier as the association key to form the behavioral correlation graph. When constructing the behavioral correlation graph, the entry identifier of the source summary data is recorded for each relationship to ensure that the edge relationships in the behavioral correlation graph can be traced back to the original evidence. Then, the baseline behavioral correlation graph is retrieved from the historical runtime behavioral baseline summary set, and a structural difference score is calculated between the behavioral correlation graph and the baseline behavioral correlation graph. The structural difference score is obtained by statistically analyzing at least node differences, edge differences, and relationship type differences. The structural difference score and the set of process identifiers and relationships with the highest difference contribution are output to support subsequent risk interpretation and localization. The structural difference score and its corresponding difference contribution information are written into the behavioral evidence citation field of the evidence chain citation list.

[0093] After the consistency comparison and correlation analysis are completed, evidence fusion is performed based on the handling strategy parameters to generate recommended handling actions. First, the confidence level of the encrypted anomaly score is corrected based on the uncertainty measurement record. This confidence level correction is used to reduce the contribution of the encrypted anomaly score to the fusion result when the baseline is missing, the evidence credibility is insufficient, or the acquisition link is incomplete. Specifically, the baseline missing degree, evidence credibility identifier, and acquisition link integrity identifier are read from the uncertainty measurement record. A confidence level correction coefficient is generated based on the uncertainty penalty coefficient pre-configured in the handling strategy parameters. The confidence level correction coefficient is limited to a value between 0 and 1 and is used to scale the encrypted anomaly score to obtain the corrected encrypted anomaly score. When the uncertainty measurement record indicates an increased baseline missing degree, or the evidence credibility identifier indicates insufficient credibility, or the acquisition link integrity identifier indicates an incomplete link, the confidence level correction coefficient decreases accordingly, thereby reducing the impact of the corrected encrypted anomaly score in subsequent fusion calculations and suppressing the risk of false alarms caused by unobservable factors.

[0094] The corrected ciphertext anomaly score, key document deviation count, initiation chain deviation conclusion, newly added destination address set and anomaly timing features of isolated network traffic digest data, structural difference score, and signature verification result record are fused together to obtain a fused risk score. This fused risk score is then mapped to a comprehensive risk level according to the threshold rules in the handling strategy parameters. During the fused calculation, the corrected ciphertext anomaly score, key document deviation count, initiation chain deviation conclusion, newly added destination address set and anomaly timing features of isolated network traffic digest data, structural difference score, and signature verification result record are first converted into corresponding standardized index values ​​according to the handling strategy parameters. These standardized index values ​​are normalized using a normalization upper limit and restricted to a uniform dimension range according to pruning rules. Specifically, the initiation chain deviation conclusion and signature verification result record are converted into numerical standardized index values ​​using mapping rules, and the newly added destination address set and anomaly timing features are converted into numerical standardized index values ​​using counting and strength extraction rules. Then, the standardized indicator values ​​are weighted and aggregated according to the weight set in the disposal strategy parameters. The weighted aggregation is obtained by multiplying each standardized indicator value by its corresponding weight and then summing the results. The weight set, normalization upper limit and pruning rules are written together with the fusion risk score into the fusion calculation metadata field of the evidence chain reference list to ensure that the fusion risk score is reproducible and auditable.

[0095] The overall risk level is obtained by mapping the fusion risk score according to the threshold rules in the handling strategy parameters. The handling strategy parameters provide a set of overall risk level thresholds and limit the order relationship between the thresholds. During mapping, the fusion risk score is compared with the set of overall risk level thresholds one by one. If the fusion risk score is less than the lowest threshold, the overall risk level is mapped to low risk. If the fusion risk score falls into the adjacent threshold range, the overall risk level is mapped to the corresponding medium or high risk. If the fusion risk score is not less than the highest threshold, the overall risk level is mapped to severe risk. At the same time, when the handling strategy parameters specify the existence of a mandatory upgrade rule, when the start chain deviation conclusion characterization deviates or the signature verification result record characterization fails and the mandatory upgrade conditions are met, the overall risk level is upgraded to no less than high risk based on the above threshold mapping results, so as to ensure the priority of handling anomalies in key trusted links.

[0096] Finally, recommended actions are generated based on the handling strategy parameters. In addition to anomaly thresholds, confidence thresholds, isolation requirements, restoration conditions, and rollback conditions, the handling strategy parameters also include a set of action rules to map the comprehensive risk level and evidence triggering conditions to handling actions. This set of action rules is generated by the operation and maintenance strategy configuration and distributed along with the handling strategy parameters. The action rule set defines at least the triggering conditions, preconditions, and mutual exclusion relationships for three types of handling actions: isolation, restoration, and rollback. When generating recommended actions, the system first searches the action rule set for candidate rules that meet the comprehensive risk level, using the comprehensive risk level as the entry point. Then, it combines the encrypted anomaly score, key document deviation count, initiation chain deviation conclusion, newly added destination address set and anomaly timing characteristics of isolated network traffic digest data, structural difference score, and signature verification result records to determine whether the triggering conditions of each candidate rule are met. If the triggering conditions are met, the corresponding set of handling actions is output according to the action rule set. When multiple candidate rules are met simultaneously, the set of handling actions with higher handling intensity and meeting preconditions is selected according to the priority specified by the handling strategy parameters, and conflicting actions are eliminated according to the mutual exclusion relationships specified by the handling strategy parameters. After the recommended action is generated, the comparison result between the evidence item reference identifier triggering the action set and the threshold is recorded in the recommended action. This record is then consistently bound to the key file evidence reference field, initiation chain evidence reference field, external evidence reference field, behavioral evidence reference field, and fusion calculation metadata field in the evidence chain reference list, ensuring that the recommended action is aligned with the evidence chain reference list. Through the above-mentioned fusion judgment and recommended action generation, multi-source evidence cross-validation of potential backdoor risks is achieved without decrypting the firmware upgrade package. This reduces false alarms caused by deviations in single encrypted statistics and improves the detection rate of high-risk samples when deviations occur between the initiation chain and key files, thereby enhancing the reliability and auditability of the action decision.

[0097] The restore module is used to trigger a one-click restore operation when the recommended action is restore.

[0098] Please see Figure 4 As shown, the industrial control computer sets a one-key restore physical button 1 as the one-key handling trigger entry. When the one-key restore physical button 1 is pressed, the industrial control computer enters the preset one-key handling mode and starts the one-key restore operation process. In this embodiment, the physical button trigger signal is received by the startup loader or recovery mode and switches to the one-key handling mode accordingly, so as to execute subsequent handling steps without external interaction. After entering the one-key handling mode, the recommended handling action is read and it is determined whether the recommended handling action requires restoration. When the recommended handling action requires restoration, a trusted firmware source is selected according to the handling strategy parameters and the upgrade package source identification information. The outer layer authenticity and integrity verification is performed again on the firmware upgrade package corresponding to the trusted firmware source to ensure that the written trusted firmware meets the outer layer authenticity and integrity requirements. When the outer layer authenticity and integrity verification fails, a handling result record is generated and the reason for handling abort is marked.

[0099] After the outer layer's authenticity and integrity verification passes, a configuration cleanup backup is performed before restoration. The configuration cleanup backup filters the device configuration based on the handling strategy parameters, retaining only the configuration keys explicitly allowed by the handling strategy parameters to form a cleaned configuration set. Simultaneously, the cleanup results are recorded, and the cleanup results are associated with the upgrade package source identifier information and written into the handling result record to ensure the traceability of the restored configuration state. Subsequently, the target partition is determined based on the device partition layout information, and trusted firmware is written to the target partition. After writing, an atomic switch or rollback strategy is executed according to the device partition layout information and handling strategy parameters, enabling the device to boot with trusted firmware after restarting or roll back to a bootable partition in case of switchover failure. This reduces the risk of device unavailability during the handling process. The partition identifier, the atomic switch or rollback strategy execution status, and the upgrade package source identifier information are written into the handling result record.

[0100] After the device restarts, a re-inspection is performed. The re-inspection includes repeatedly collecting startup chain metric summary data, running port listening summary data, isolated network traffic summary data, and a list of key file hash values. The data collected after the restart is used as input for the re-inspection, and the evidence fusion judgment and disposal suggestion generation process generates a re-inspection conclusion record. The re-inspection conclusion record includes at least a comparison result between the overall risk level of the re-inspection and the overall risk level before disposal. The re-inspection conclusion record is then associated with the disposal result record to form an audit chain from triggering, restoration to re-inspection.

[0101] Example 2:

[0102] Please see Figure 2As shown, this embodiment provides a firmware backdoor detection and one-click secure restore method, which includes the following steps without decrypting the firmware upgrade package or reconstructing the file system content through unpacking:

[0103] Obtain the raw byte sequence of the firmware upgrade package;

[0104] The original byte sequence of the firmware upgrade package is segmented and standardized to obtain the byte range index of each segment and the upgrade package segment list;

[0105] Based on the byte range index, the ciphertext statistical features of each segment are extracted and the upgrade package statistical fingerprint is generated; the upgrade package statistical fingerprint is compared with the historical baseline to obtain the ciphertext anomaly score;

[0106] When the ciphertext anomaly score exceeds the verification trigger threshold, a device-side verification task is generated and device-side verification evidence is collected.

[0107] Based on the fusion of encrypted anomaly scoring and device-side verification evidence, a comprehensive risk level and recommended action are output.

[0108] When the recommended action is to restore, a one-click restore operation is triggered.

[0109] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0110] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A firmware backdoor detection and one-click secure restore method, characterized in that, Without decrypting the firmware upgrade package and without reconstructing the file system content through unpacking, including: Obtain the raw byte sequence of the firmware upgrade package; The original byte sequence of the firmware upgrade package is segmented and standardized to obtain the byte range index of each segment and the upgrade package segment list; Based on the byte range index, the ciphertext statistical features of each segment are extracted and the upgrade package statistical fingerprint is generated; the upgrade package statistical fingerprint is compared with the historical baseline to obtain the ciphertext anomaly score; When the ciphertext anomaly score exceeds the verification trigger threshold, a device-side verification task is generated and device-side verification evidence is collected. Based on the fusion of encrypted anomaly scoring and device-side verification evidence, a comprehensive risk level and recommended action are output. When the recommended action is to restore, a one-click restore operation is triggered.

2. The firmware backdoor detection and one-click secure restore method according to claim 1, characterized in that, The original byte sequence is sliced ​​according to the segmented byte interval index to obtain segmented byte sequences. The ciphertext statistical features are calculated on the segmented byte sequences to obtain the statistical fingerprint of the upgrade package.

3. The firmware backdoor detection and one-click secure restore method according to claim 2, characterized in that, Using a set window length in bytes, the Shannon entropy sequence of segmented byte sequences is calculated by sliding, and the mean, variance, and peak position are taken to obtain the entropy features; The segment is divided into blocks according to the window length bytes, and the proportion of repeated blocks and block diversity are calculated. The byte frequency histogram of the segment byte sequence is calculated and normalized. The entropy feature, proportion of repeated blocks, block diversity and byte frequency histogram of each segment are concatenated in order to generate segment statistical features. All segment statistical features are aggregated to generate upgrade package statistical fingerprint.

4. The firmware backdoor detection and one-click secure restore method according to claim 3, characterized in that, The upgrade package statistical fingerprint is used to perform similarity retrieval in a pre-built set of historical upgrade package statistical fingerprints. Multiple historical samples are selected in order of similarity from high to low and the set identifier of the corresponding historical samples is output to obtain the set identifier of similar historical samples. Using the identifier of similar historical sample set, for comparable segments in the upgrade package segment list, based on the segment type identifier and segment number, the historical segment statistical features corresponding to the identifier of similar historical sample set are selected as the comparison baseline from the pre-constructed historical segment statistical feature set, and the feature deviation is calculated based on the difference of segment statistical features. The feature deviation of each comparable segment relative to each historical sample segment is organized into a matrix according to the segment number and the historical sample identifier to obtain the segment-level deviation matrix. The segment-level deviation matrix is ​​analyzed into segment-level deviation scores.

5. The firmware backdoor detection and one-click secure restore method according to claim 4, characterized in that, The upgrade package segment list is compared with the pre-built normal segment template subset one by one to check the consistency of the number of segments, and the structural consistency result is obtained. The structural consistency results are parsed as structural deviation scores.

6. The firmware backdoor detection and one-click secure restore method according to claim 5, characterized in that, Parse and populate the upgrade package verification field set from the original byte sequence; calculate the digest for the corresponding byte interval of the original byte sequence according to the coverage of the verification fields described in the upgrade package verification field set and compare it with the verification fields to obtain the comparison result; use the pre-acquired vendor public key certificate set to verify the signature field and obtain the signature verification conclusion; the upgrade package verification result record includes the comparison result and the signature verification conclusion. The upgrade package verification result record is parsed into a signature score; The encrypted anomaly score is obtained by weighting and summing the structural deviation score, segment-level deviation score, and signature verification score according to the weights in the pre-configured handling strategy parameters.

7. The firmware backdoor detection and one-click secure restore method according to claim 4, characterized in that, Device-side verification evidence includes isolated network traffic digest data, running process tree digest data, running port listening digest data, running file write digest data, startup chain metric digest data, key file hash value list, device security metric signature information, and signature verification result record; After determining the comparison criteria based on the handling strategy parameters, the file path in the list of key file hash values ​​is used as the key to retrieve hash values ​​with the same path from the historical operational behavior baseline summary set and perform consistency comparison to obtain the key file deviation count. A consistency comparison was performed on the startup chain metric summary data to obtain a startup chain deviation conclusion. Anomaly comparison is performed on isolated network traffic summary data to obtain the set of newly added destination addresses and anomaly time-series characteristics of the isolated network traffic summary data. A correlation analysis was performed on the running process tree summary data, the running port listening summary data, and the running file write summary data to form a behavioral correlation graph, and a structural difference score was calculated. Recommended actions include a set of actions corresponding to isolation, restoration, and rollback.

8. The firmware backdoor detection and one-click secure restore method according to claim 7, characterized in that, Based on the upgrade package segment list, segment statistical characteristics, similar historical sample set identifiers, and disposal strategy parameters, a set of metrics is calculated; The set of metrics is weighted and aggregated according to the weight set in the disposal strategy parameters to obtain the uncertainty measurement record; The confidence level of the ciphertext anomaly score is adjusted based on the uncertainty measurement record to obtain the corrected ciphertext anomaly score. The corrected ciphertext anomaly score, key document deviation count, initiation chain deviation conclusion, newly added destination address set of isolated network traffic digest data, anomaly timing features, structural difference score, and signature verification result record are fused together to obtain the fusion risk score.

9. The firmware backdoor detection and one-click secure restore method according to claim 8, characterized in that, The overall risk level is obtained by mapping the fusion risk score according to the threshold rules in the disposal strategy parameters. The disposal strategy parameters provide a set of overall risk level thresholds and limit the order relationship between each threshold. During the mapping, the fusion risk score is compared with the set of overall risk level thresholds one by one. Using the comprehensive risk level as the entry point, candidate rules that meet the comprehensive risk level are retrieved from the pre-configured set of action rules. Then, the triggering conditions of each candidate rule are determined by combining the encrypted anomaly score, key document deviation count, initiation chain deviation conclusion, new destination address set and anomaly timing characteristics of isolated network traffic digest data, structural difference score and signature verification result record. When the triggering conditions are met, the corresponding set of handling actions is output according to the set of action rules.

10. A firmware backdoor detection and one-click secure restore system, used to implement the firmware backdoor detection and one-click secure restore method according to any one of claims 1-9, characterized in that, include: The acquisition module is used to obtain the raw byte sequence of the firmware upgrade package; The segmentation module is used to parse and standardize the original byte sequence of the firmware upgrade package into segments, and obtain the byte range index of each segment and the upgrade package segment list. The scoring module extracts the ciphertext statistical features of each segment based on the byte range index and generates the upgrade package statistical fingerprint; the upgrade package statistical fingerprint is compared with the historical baseline to obtain the ciphertext anomaly score; The task module is used to generate a device-side verification task and collect device-side verification evidence when the ciphertext anomaly score exceeds the verification trigger threshold. The judgment module performs a fusion judgment based on the encrypted anomaly score and the device-side verification evidence, and outputs a comprehensive risk level and recommended action. The restore module is used to trigger a one-click restore operation when the recommended action is restore.

Images