An iot firmware software component analysis and evidence chain offline vulnerability detection method

Abstract

This invention relates to the field of IoT firmware security analysis and offline vulnerability detection technology, and discloses an IoT firmware software component analysis and evidence chain offline vulnerability detection method, including: parsing the firmware encapsulation structure and recursively extracting binary programs, recording the byte offset of each extracted product; extracting a multi-dimensional feature set of the binary program, and generating a software bill of materials by probability supplementation weighting; disassembling code segments to extract the basic block instruction hash values ​​of the control flow graph, comparing them with patch features to generate false positive suppression flags; organizing the firmware hash, byte offset, bill of materials, feature set, vulnerability rules, and judgment conclusions into a six-element directed acyclic graph topology, and outputting detection results that support reverse backtracking. This invention solves the feature drift caused by symbol stripping and the false positive problem of patch reverse porting, and realizes deterministic tracing of detection conclusions to the physical storage area of ​​the firmware.

Description

Technical Field

[0001] This invention belongs to the field of IoT firmware security analysis and offline vulnerability detection technology, and particularly relates to an IoT firmware software component analysis and evidence chain offline vulnerability detection method. Background Technology

[0002] In industrial control, smart manufacturing, and IoT terminal application environments, various field devices typically rely on embedded firmware to complete low-level hardware control, bus communication, network communication, and configuration management. Under the data compliance requirements of physically isolated networks, security analysis systems usually adopt a completely offline deployment method. By parsing the packaging structure of the firmware image and traversing the files within it, text features, symbol information, configuration scripts, and residual records of package management are extracted, and then compared with the local static rule base to generate a software bill of materials and vulnerability detection results.

[0003] As firmware packaging methods continue to evolve, firmware images often contain private segment headers, multi-level nested file systems, and symbols stripped during compilation. In such cases, the external version identifier may remain unchanged, while the instructions in the actual code have changed. Judging solely based on the affected version range where the version number is located cannot identify instruction changes in critical functions that pose a vulnerability, easily leading to false alarms and making it difficult to explain the specific evidence upon which the vulnerability judgment is based. To improve the accuracy of vulnerability identification in symbol-stripped firmware, existing technologies attempt to identify vulnerabilities through control flow graph modeling and graph feature comparison. For example, Chinese invention patent application CN116644430A discloses a firmware vulnerability determination and location method based on syntax similarity analysis. This method extracts the attribute control flow graph (ACFG) of the patch source code and disassembled functions, trains a deep neural network graph embedding model, and compares the cosine distance of the ACFG vectors with a set threshold to determine the existence of vulnerabilities and locate vulnerable functions.

[0004] Therefore, in a local offline, physically isolated environment, how to preserve the correspondence between the unpacked objects at each level and the physical byte positions of the original firmware, accurately determine the software bill of materials by combining multiple features, and further identify the actual integration of security patches at the instruction level, so that the vulnerability detection results can be traced back to the specific location in the original firmware based on complete evidence, has become the technical problem that this invention needs to solve. Summary of the Invention

[0005] This invention aims to solve the problem of how to construct an unpacking spectrum that connects the underlying physical offset in a local offline physical isolation environment, integrate multi-source discrete features to determine the component bill of materials, and resolve patch reverse porting conflicts at the instruction level to generate a vulnerability evidence chain with topological reverse tracing capabilities.

[0006] In this technical solution, an IoT firmware software component analysis and offline vulnerability detection method includes the following steps: Step S1: parse the encapsulation structure of the IoT firmware file to be tested, recursively extract the nested file system image and binary program, and record the starting byte offset and ending byte offset of the extracted product in the original firmware image. Step S2: Extract the multi-dimensional feature set of the binary program, calculate the component identification confidence using a probability supplementary weighting algorithm, map the multi-dimensional feature set with the component identification confidence reaching a preset threshold to the standard component identifier and version number, and generate a software bill of materials; Step S3: Retrieve candidate vulnerability rules in the offline vulnerability rule base according to the standard component identifier and version number, disassemble the code segment affected by the vulnerability, extract the boundary comparison basic block instruction sequence in the control flow graph of the vulnerability key function and calculate the instruction hash value, compare the preset patch characteristics to determine the patch merging status and generate a false alarm suppression flag. Step S4: Organize the firmware hash, start byte offset and end byte offset, software bill of materials, multi-dimensional feature set, matching vulnerability rules and vulnerability judgment conclusions into a six-element directed acyclic graph evidence chain topology. Based on the false alarm suppression flag, remove false alarm items and output the vulnerability detection results that are backtracked along the six-element directed acyclic graph evidence chain topology to the start byte offset and end byte offset of the original firmware image.

[0007] Preferably, the process of parsing the encapsulation structure of the IoT firmware file to be tested in step S1 includes: parsing the header magic number and metadata of the IoT firmware file to be tested to identify the encapsulation format, and decrypting and decompressing according to the encapsulation format; identifying nested file system images by scanning file features, mounting and deconstructing the directory structure and independent binary programs; establishing an unpacking genealogy tree, and bidirectionally indexing and binding the file nodes at each level generated by unpacking with the corresponding start byte offset and end byte offset in the original firmware image.

[0008] Preferably, the process of extracting the multidimensional feature set of the binary program in step S2 includes: parsing the executable and linkable format header metadata of the binary program, extracting the target instruction set architecture, endianness, and list of dependent shared libraries; parsing the symbol table and dynamic segments, extracting unstripped symbols, dynamically exported function symbols, and sequences of externally imported function symbols; scanning the read-only data segment, extracting constant string slices of a preset length, and formatting them into a multidimensional feature vector containing architecture metadata, dynamic symbol table, and character slices.

[0009] Preferably, the process of calculating the component recognition confidence using the probability complement weighting algorithm in step S2 includes: applying preset type weights and feature extraction completeness coefficients to the architecture metadata, dynamic symbol table, and character slices in the multidimensional feature vector; establishing a probability complement function for the matching degree of each feature dimension; inputting the matching results of the multidimensional features into the probability complement weighting model for convergence calculation; and outputting a component recognition confidence value between 0 and 1; when the component recognition confidence value is greater than or equal to a preset threshold, confirming successful component recognition and associating it with a general platform enumeration identifier.

[0010] Preferably, the process of retrieving candidate vulnerability rules from the offline vulnerability rule base in step S3 includes: reading the affected version constraint range and necessary evidence dependency conditions corresponding to the security vulnerability entries from the offline vulnerability rule base; performing version algebra inclusion matching between the standard component identifiers and version numbers in the software bill of materials and the affected version constraint range; verifying whether the binary program contains the dynamic link library file or specific exported symbols specified in the necessary evidence dependency conditions, and eliminating candidate rule items that do not meet the symbol dependency to complete the initial rule screening.

[0011] Preferably, the process of determining the patch integration status and generating a false positive suppression flag in step S3 includes: when the standard component identifier and version number fall within the affected version constraint range of the candidate vulnerability rules, disassembling to locate the assembly instruction flow corresponding to the vulnerability-affected code segment; constructing the control flow graph of the vulnerability's key functions to locate the target basic block containing boundary check logic; extracting the opcode sequence from the target basic block and filtering the operand address offsets, and calculating the cryptographic hash value of the normalized opcode sequence; comparing the cryptographic hash value with the hash features in the pre-built security patch feature library; when the hash values ​​match, determining that the vendor has reverse-ported the security patch, setting the false positive suppression flag and blocking the generation of external alarms.

[0012] Preferably, the process of organizing the evidence chain topology into a six-element directed acyclic graph in step S4 includes: creating six types of topology nodes representing the original firmware hash root node, the unpacked byte offset structure node, the component material identifier node, the low-level feature slice node, the offline vulnerability rule node, and the vulnerability judgment conclusion node, respectively; establishing directed edges with causal constraints between adjacent level nodes according to the unpacking genealogy and vulnerability deduction logic to form a six-element directed acyclic graph; when generating the final vulnerability report, traversing the directed edges in reverse from the vulnerability judgment conclusion node, and addressing the start byte offset and end byte offset in the original firmware image through the corresponding low-level feature slice node and unpacked byte offset structure node.

[0013] Preferably, the process of outputting the vulnerability detection results in step S4 also includes calculating the local vulnerability risk score. : ,in, The base score for the general vulnerability scoring system recorded in the offline vulnerability rule base; The network reachability coefficient of the component's exposed surface is set to the first preset value when the component is bound to an external open network listening port, the second preset value which is less than the first preset value when the component is only called by the local console, and the third preset value which is less than the second preset value when the component is an isolated shared library. The evidence chain integrity weight is calculated by multiplying the proportion of nodes that pass effective closure verification to the total number of necessary nodes in the standard evidence chain with the component identification confidence level; based on the calculated... The detected vulnerabilities are classified into different levels based on numerical values.

[0014] Preferably, after step S4, the method further includes: filtering all matched vulnerability candidate records based on the false positive suppression flag; when the false positive suppression flag is set, updating the status of the corresponding vulnerability record to "patches merged into suppressed" and removing it from the remediation queue; for valid vulnerability records that have not been suppressed, filtering them based on the local vulnerability risk score. The priority sequence for on-site repair and treatment is arranged in descending order of high to low.

[0015] Preferably, after arranging the priority sequence for on-site repair and disposal, the method further includes: packaging and serializing the task detection metadata, software material list, valid vulnerability matching records, six-element directed acyclic graph evidence chain topology, and disposal priority sequence into a structured report file; calculating the hash-based message authentication code HMAC-SHA256 signature value of the structured report file; and writing the structured report file with the signature value into a local protected isolated secure storage area to complete tamper-proof archiving.

[0016] Compared with existing technologies, the present invention provides an IoT firmware software component analysis and offline evidence chain vulnerability detection method, which has the following advantages: 1. In IoT firmware software component analysis and offline vulnerability detection of evidence chains, this invention addresses the issues of multi-layered nested compression, private segmented encapsulation, and potential abnormal interruptions during parsing in IoT firmware. During layer-by-layer unpacking, the invention retains the start and end byte offsets of each object in the original firmware and tracks the locations of parsing failures. This maintains a continuous correspondence between the file system, binary programs, and dependent libraries and the physical storage location of the original firmware, preventing interruptions in the unpacking hierarchy due to abnormal exits. This ensures that subsequently extracted features accurately correspond to specific locations in the original firmware, providing a reliable basis for the physical location and tracing of vulnerability results.

[0017] 2. To address the issue of component name and version identification discrepancies that can easily occur when relying solely on a single string after symbol stripping, this invention comprehensively utilizes multiple information sources, including package management status records, constant reference relationships in the code, shared library dependency fields, and dynamically exported symbols, to identify components. Furthermore, it calculates component identification confidence based on the effectiveness of different features. Therefore, even if the binary program lacks a source code build manifest or some symbol information, it can still determine the standard component identifier and version number by comprehensively considering existing features. This reduces the impact of feature variations caused by different compilation environments on the identification results, lowers false negatives and false positives caused by single-string matching, and makes the generated software bill of materials more reliable.

[0018] 3. To address the issue that false alarms can easily arise from simply relying on version numbers after equipment manufacturers reverse-port security patches to lower-version code, this invention, after initial screening based on version conditions and necessary evidence, further determines whether the patch has been merged based on the actual instruction content of the binary program. By comparing the relevant basic block instructions in the vulnerability's critical functions, it can distinguish between two situations: the version number is still within the affected range and the actual code has been fixed. This allows for timely suppression of false alarms for security patches that have already been merged, reducing false alarms caused by relying solely on version range judgments and improving the accuracy of offline vulnerability detection results. Attached Figure Description

[0019] Figure 1 This is a flowchart of the multi-dimensional feature fusion analysis and patch false alarm suppression of the present invention; Figure 2 This is the offline fault-tolerant scheduling and secure storage archiving topology diagram of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0021] A method for offline vulnerability detection of IoT firmware software composition and evidence chain includes the following steps: Step S1: parse the encapsulation structure of the IoT firmware file to be tested, recursively extract the nested file system image and binary program, and record the starting byte offset and ending byte offset of the extracted product in the original firmware image. Step S2: Extract the multi-dimensional feature set of the binary program, calculate the component identification confidence using a probability supplementary weighting algorithm, map the multi-dimensional feature set with the component identification confidence reaching a preset threshold to the standard component identifier and version number, and generate a software bill of materials; Step S3: Retrieve candidate vulnerability rules in the offline vulnerability rule base according to the standard component identifier and version number, disassemble the code segment affected by the vulnerability, extract the boundary comparison basic block instruction sequence in the control flow graph of the vulnerability key function and calculate the instruction hash value, compare the preset patch characteristics to determine the patch merging status and generate a false alarm suppression flag. Step S4: Organize the firmware hash, start byte offset and end byte offset, software bill of materials, multi-dimensional feature set, matching vulnerability rules and vulnerability judgment conclusions into a six-element directed acyclic graph evidence chain topology. Based on the false alarm suppression flag, remove false alarm items and output the vulnerability detection results that are backtracked along the six-element directed acyclic graph evidence chain topology to the start byte offset and end byte offset of the original firmware image.

[0022] Preferably, the process of parsing the encapsulation structure of the IoT firmware file to be tested in step S1 includes: parsing the header magic number and metadata of the IoT firmware file to be tested to identify the encapsulation format, and decrypting and decompressing according to the encapsulation format; identifying nested file system images by scanning file features, mounting and deconstructing the directory structure and independent binary programs; establishing an unpacking genealogy tree, and bidirectionally indexing and binding the file nodes at each level generated by unpacking with the corresponding start byte offset and end byte offset in the original firmware image.

[0023] Preferably, the process of extracting the multidimensional feature set of the binary program in step S2 includes: parsing the executable and linkable format header metadata of the binary program, extracting the target instruction set architecture, endianness, and list of dependent shared libraries; parsing the symbol table and dynamic segments, extracting unstripped symbols, dynamically exported function symbols, and sequences of externally imported function symbols; scanning the read-only data segment, extracting constant string slices of a preset length, and formatting them into a multidimensional feature vector containing architecture metadata, dynamic symbol table, and character slices.

[0024] Preferably, the process of calculating the component recognition confidence using the probability complement weighting algorithm in step S2 includes: applying preset type weights and feature extraction completeness coefficients to the architecture metadata, dynamic symbol table, and character slices in the multidimensional feature vector; establishing a probability complement function for the matching degree of each feature dimension; inputting the matching results of the multidimensional features into the probability complement weighting model for convergence calculation; and outputting a component recognition confidence value between 0 and 1; when the component recognition confidence value is greater than or equal to a preset threshold, confirming successful component recognition and associating it with a general platform enumeration identifier.

[0025] Preferably, the process of retrieving candidate vulnerability rules from the offline vulnerability rule base in step S3 includes: reading the affected version constraint range and necessary evidence dependency conditions corresponding to the security vulnerability entries from the offline vulnerability rule base; performing version algebra inclusion matching between the standard component identifiers and version numbers in the software bill of materials and the affected version constraint range; verifying whether the binary program contains the dynamic link library file or specific exported symbols specified in the necessary evidence dependency conditions, and eliminating candidate rule items that do not meet the symbol dependency to complete the initial rule screening.

[0026] Preferably, the process of determining the patch integration status and generating a false positive suppression flag in step S3 includes: when the standard component identifier and version number fall within the affected version constraint range of the candidate vulnerability rules, disassembling to locate the assembly instruction flow corresponding to the vulnerability-affected code segment; constructing the control flow graph of the vulnerability's key functions to locate the target basic block containing boundary check logic; extracting the opcode sequence from the target basic block and filtering the operand address offsets, and calculating the cryptographic hash value of the normalized opcode sequence; comparing the cryptographic hash value with the hash features in the pre-built security patch feature library; when the hash values ​​match, determining that the vendor has reverse-ported the security patch, setting the false positive suppression flag and blocking the generation of external alarms.

[0027] Preferably, the process of organizing the evidence chain topology into a six-element directed acyclic graph in step S4 includes: creating six types of topology nodes representing the original firmware hash root node, the unpacked byte offset structure node, the component material identifier node, the low-level feature slice node, the offline vulnerability rule node, and the vulnerability judgment conclusion node, respectively; establishing directed edges with causal constraints between adjacent level nodes according to the unpacking genealogy and vulnerability deduction logic to form a six-element directed acyclic graph; when generating the final vulnerability report, traversing the directed edges in reverse from the vulnerability judgment conclusion node, and addressing the start byte offset and end byte offset in the original firmware image through the corresponding low-level feature slice node and unpacked byte offset structure node.

[0028] Preferably, the process of outputting the vulnerability detection results in step S4 also includes calculating the local vulnerability risk score. : ,in, The base score for the general vulnerability scoring system recorded in the offline vulnerability rule base; The network reachability coefficient of the component's exposed surface is set to the first preset value when the component is bound to an external open network listening port, the second preset value which is less than the first preset value when the component is only called by the local console, and the third preset value which is less than the second preset value when the component is an isolated shared library. The evidence chain integrity weight is calculated by multiplying the proportion of nodes that pass effective closure verification to the total number of necessary nodes in the standard evidence chain with the component identification confidence level; based on the calculated... The detected vulnerabilities are classified into different levels based on numerical values.

[0029] Preferably, after step S4, the method further includes: filtering all matched vulnerability candidate records based on the false positive suppression flag; when the false positive suppression flag is set, updating the status of the corresponding vulnerability record to "patches merged into suppressed" and removing it from the remediation queue; for valid vulnerability records that have not been suppressed, filtering them based on the local vulnerability risk score. The priority sequence for on-site repair and treatment is arranged in descending order of high to low.

[0030] Preferably, after arranging the priority sequence for on-site repair and disposal, the method further includes: packaging and serializing the task detection metadata, software material list, valid vulnerability matching records, six-element directed acyclic graph evidence chain topology, and disposal priority sequence into a structured report file; calculating the hash-based message authentication code HMAC-SHA256 signature value of the structured report file; and writing the structured report file with the signature value into a local protected isolated secure storage area to complete tamper-proof archiving.

[0031] Example 1: The system receives the IoT firmware file to be tested through local physical media or isolated LAN bus, creates an independent encrypted isolation analysis workspace in local non-volatile storage media, reads the binary data stream of the IoT firmware file to be tested, calculates the full secure hash algorithm SHA256 hash value and the segmented context-triggered fuzzy hash value SSDEEP of the IoT firmware file to be tested, obtains the file size as 33,554,432 bytes, extracts the firmware encapsulation extension and import timestamp, generates a globally unique task identifier TASK_ID_20260818_001, and initializes the unpacking task queue and genealogy tracking context structure in the local isolation analysis workspace.

[0032] The algorithm reads the first 256 bytes of the header of the IoT firmware file to be tested, along with its signature magic number and header metadata. It identifies the outer encapsulation structure as a TRX encapsulation header, matches it with a pre-set offline file format signature library, and calls the TRX offline parser to deconstruct the kernel boot image and compressed file system payload. During encapsulation format parsing, it determines whether the payload contains an encryption layer based on the header metadata. If an encryption layer exists, it calls the corresponding local decryption process according to the identified encapsulation format before decompression. If no encryption layer is present, it directly proceeds to decompression. Within the physical storage offset range of 0x00080000 to 0x00A00000, it identifies the SquashFS file system, calls the SquashFS parsing module to mount and deconstruct the file system directory tree, and generates corresponding phylogenetic nodes for each level of unpacking product in the unpacking phylogenetic tree. It records the current unpacking level depth (level 2), the unpacking tool identifier (squashfs_extractor), and the physical starting byte offset. 0x00080000, end byte offset The parser returns 0x00A00000 and indicates an integrity verification status. When recursive parsing encounters an unknown private header structure, file system truncation exception, or parsing failure, it triggers a failure rollback protection mechanism, extracts the physical offset range of the abnormal data segment and calculates the segment hash value, writes the blocking status flag and exception exit code into the unpacking tree branch, and moves the task pointer to the next unpacking object in the unpacking task queue. It scans the section headers and segment attributes of the extracted executable ELF binary files and dynamic shared libraries, checks for the absence of compression shell features, and outputs a set of extracted objects including the root directory tree, dynamic shared libraries, shell scripts, configuration files, and package management remnants. When processing multi-level nested unpacking, for internal independent binary files extracted after decompression or mounting, the parser records the logical relative offset and compressed block index of the internal file within its respective file system image. For files that can be directly... For data mapped by physical address, the physical start byte offset 0x00080000 recorded in the original firmware image by the parent file system node is read. This physical start byte offset is added to the logical relative offset of the internal file to obtain the absolute start byte offset of the internal file in the original firmware binary stream. Then, the absolute end byte offset is determined according to the physical storage byte length occupied by the file. For data using block compression, the physical storage range of the corresponding compressed block in the parent image is queried according to the compressed block index. The physical storage range of the original firmware is determined by the start position of the first compressed block involved in the internal file and the end position of the last compressed block. The unpacking tree binds the file nodes at each level with the obtained start byte offset and end byte offset through bidirectional indexing. On the one hand, the file nodes index the physical storage range of the original firmware, and on the other hand, the physical storage range indexes the corresponding file nodes in reverse.

[0033] The process iterates through all files in the extracted object set, locating the dynamic shared library file ` / usr / lib / libcrypto.so.1.0.0`. It then searches the file system for the package manager residual state library file ` / usr / lib / opkg / status`, extracting the declaration entries `Package:libopenssl` and `Version:1.0.2k-1` through a syntax state machine. This package manager metadata is used as a verification record for the component name and version number. The executable and linkable header metadata of the dynamic shared library file is then parsed to extract the target instruction set architecture, endianness, and dependent shared libraries. The system first generates architecture metadata; then it parses the dynamic segment .dynamic and the dynamic symbol table .dynsym to extract unstripped symbols, dynamically exported function symbols, and sequences of externally imported function symbols, among which the feature exported function symbol EVP_aes_128_cbc_hmac_sha1 is retrieved; it then scans the read-only data segment .rodata to extract constant string slices of a preset length, among which character slices OpenSSL1.0.2k26Jan2017 are obtained through a preset version semantic regular expression; finally, it combines the architecture metadata, dynamic symbol table, and character slices into a multidimensional feature set and formats it into a multidimensional feature vector.

[0034] For the architecture metadata, character slices, and dynamic symbol table in the multidimensional feature vector, configure type weights and feature extraction completeness coefficients respectively. The architecture metadata is used as the first dimension feature, and type weights are configured accordingly. Feature extraction completeness coefficient Character slices are used as the second-dimensional feature, with configured type weights. Feature extraction completeness coefficient The dynamic symbol table serves as the third dimension feature, configuring type weights. Feature extraction completeness coefficient The type weight is preset based on the stability of different feature sources, and the feature extraction completeness coefficient is determined based on the completeness of the extraction of the corresponding field. When the type weight is lower than 0.30 or the feature extraction completeness coefficient is lower than 0.50, the feature matching results of the corresponding dimension are removed from the current calculation. Each dimension feature is compared with the corresponding features of the candidate components in the local offline component feature fingerprint database. The feature matching degree of each dimension is determined by the proportion of consistent features to the effective extracted features of that dimension. After the matching condition of the corresponding dimension is met, the type weight and feature extraction completeness coefficient of that dimension constitute the effective matching contribution, and its probability complement is... .

[0035] The feature matching results from the three effective dimensions are input into the probability complement weighted model to calculate the component recognition confidence. The calculation formula is as follows: ,in, In this embodiment, the total number of independent valid feature dimensions associated with the same component entity is... ; For the first The type weights corresponding to each feature dimension satisfy the following conditions: ; For the first The feature extraction completeness coefficient of each feature dimension in the feature extraction process satisfies the following conditions: ; The confidence level for component identification is defined, with a value range of [value range missing]. Substituting the first-dimensional architecture metadata into the calculation yields... The supplementary item is Substituting the second-dimensional character slice into the calculation yields... The supplementary item is Substituting the third-dimensional dynamic symbol table into the calculation yields... The supplementary item is ; multiplying all the supplementary terms yields The component identification confidence level is obtained by solving the problem. Determine by taking four decimal places. When the component identification confidence level is greater than or equal to the preset threshold of 0.50, the component identification is confirmed to be successful. The component name and version number are mapped to the standard component identifier and version number. The standard component identifier adopts the general platform enumeration identifier cpe:2.3:a:openssl:openssl:1.0.2k:::::::×, and is associated with the general resource unified locator. A software bill of materials is generated, which includes the standard component identifier and version number, the physical path / usr / lib / libcrypto.so.1.0.0, the file SHA256 hash value, the component identification confidence level, and the associated evidence index.

[0036] Load the locally pre-built offline vulnerability rule base, and search for candidate vulnerability rules based on standard component identifiers and version numbers. The rule entry RULE_OPENSSL_002 for the security vulnerability CVE-2016-2107 is matched. This rule defines the affected version constraint range as greater than or equal to 1.0.1 and less than or equal to 1.0.2h, as well as the unpatched 1.0.2k. The rule is configured with the base score of the general vulnerability scoring system. Verify the necessary evidence dependency conditions configured in the rule, confirming the existence of the specified exported function symbol EVP_aes_128_cbc_hmac_sha1 in the extracted object, satisfying the necessary evidence dependency conditions; for versions falling within the affected version constraint range, disassemble the code segment .text of the dynamic shared library file, locate the control flow graph of the vulnerability's critical function aesni_cbc_hmac_sha1_cipher, locate the target basic block containing boundary check logic, extract the boundary comparison basic block instruction sequence and filter operand address offsets, calculate the cryptographic hash value of the normalized opcode sequence, and compare it with the preset patch characteristics; if the comparison results show inconsistency, it is determined that the current binary program has not reverse-ported the security patch, the false positive suppression flag is kept in the reset state, and the candidate vulnerability is determined. If the rule is successfully matched, when locating the target basic block containing boundary check logic in a static control flow graph lacking debug symbols and function names, the system traverses all basic block nodes in the control flow graph, scans the conditional jump instructions and their pre-comparison instructions at the end of each basic block; filters out instruction pairs whose opcodes contain numerical comparisons and conditional branches, and extracts the registers or memory offsets referenced by the comparison instructions; if the operand of the comparison instruction has a data flow dependency relationship with the input buffer length, the number of bytes received in the data packet, or the loop counter variable, and the branch jump target points to the basic block of the exception handling block, the error return path, or the system exit call, then the basic block is determined to be the target basic block containing boundary check logic; then the specific memory offset values ​​and register numbers in the comparison instructions are stripped away, the normalized pure opcode stream is retained, and the corresponding instruction sequence is extracted.

[0037] Construct a six-ary directed acyclic graph evidence chain topology in the memory data space and create the original firmware hash root node. It also writes the firmware SHA256 hash value and task identifier TASK_ID_20260818_001, and creates an unpacking byte offset structure node. It also writes the unpacking tool identifier squashfs_extractor, the unpacking level depth of 2, and the physical start byte offset of 0x00080000 and end byte offset of 0x00A00000, creating a component material identifier node. It writes the standard component identifier cpe:2.3:a:openssl:openssl:1.0.2k:::::::×, the file path / usr / lib / libcrypto.so.1.0.0, and the component identification confidence score of 0.9721, and creates the underlying feature slice node. It also writes architecture metadata, dynamic symbol table, character slices and corresponding feature hash values ​​to create offline vulnerability rule nodes. It also writes the rule number RULE_OPENSSL_002, the affected version constraint range, and the verification status of necessary evidence dependencies, and creates a vulnerability determination conclusion node. The vulnerability ID CVE-2016-2107, base score of 7.5, and local assessment score are written into the data. When establishing directed edges, the data source relationship between adjacent nodes is checked step by step: the physical storage area recorded by the unpacked byte offset structure node belongs to the firmware file corresponding to the original firmware hash root node; the binary program recorded by the component material identifier node can be located to the corresponding unpacked byte offset structure node through the unpacking genealogy and bidirectional index; the feature index in the bottom-level feature slice node points to the component material identifier node; the offline vulnerability rule node is obtained by matching the standard component identifier with the version number and necessary evidence dependency conditions; the vulnerability judgment conclusion node is generated by the matching result of the corresponding offline vulnerability rule and the patch merging status. After the above source relationship verification is successful, a unidirectional directed edge with causal constraints is established between adjacent nodes to form a topological dependency sequence. A node is considered a valid closure verification node when all necessary fields of the node are complete and the directed edges between it and its adjacent nodes can be bidirectionally verified according to the record index. All six types of nodes in this embodiment meet this condition and can be used to determine the vulnerability conclusion node. Traverse backwards along the directed edges to address the original firmware image at the starting byte offset of 0x00080000 and the ending byte offset of 0x00A00000 on the physical storage medium.

[0038] The local deterministic mathematical model is invoked to perform quantitative calculations on the topology of the constructed six-element directed acyclic graph evidence chain. The firmware startup service script ` / etc / init.d / lighttpd` and the Web configuration file are analyzed to confirm that the Web management service daemon is bound to external network listening port 443 and dynamically loads the `libcrypto.so.1.0.0` shared library to directly process external network packets, thus determining the network reachability coefficients of the component's exposed surface. ; Obtain the total number of necessary nodes in the standard chain of evidence Count the number of nodes in the current evidence chain that are actually validly closed and verified. Calculate the weight of the completeness of the chain of evidence. : ,in, This represents the number of nodes in the current chain of evidence that have valid closure verification. The total number of necessary nodes in a standard chain of evidence, satisfying ; Identify confidence levels for components; The weight for the completeness of the chain of evidence is calculated by substituting the parameters. Subsequently, a deterministic weighted model was used to calculate the local vulnerability risk score. : ,in, The base score for the general vulnerability scoring system recorded in the offline vulnerability rule base; The reachability coefficient of the component's exposed surface network; Weighting for the completeness of the chain of evidence; The local vulnerability risk score is calculated by substituting the parameters. Output the number with four decimal places after rounding. The risk level classification uses preset and non-overlapping risk level intervals, and the boundary value of each interval is assigned to only one adjacent level; in this embodiment The system falls within the high-risk P2 level range of 7.0 to 8.5. Based on this, a priority sequence for on-site repair and handling is generated to prioritize upgrading the dynamic shared library. When parsing the self-starting service script and configuration file, the system adopts general text extraction rules based on regular expressions and lexical analysis. Specifically, the system reads the network listening keywords and port binding commands in the service initialization script, and extracts the listening port number and the bound service process name through syntax parsing. Then, for the binary image file corresponding to the service process, the system parses the shared library dependency fields in its executable file and dynamic segment to search for whether there are explicit loading instructions or call relationships for the target dynamic shared library file. If it is confirmed that the service process has opened an external network listening port and its dependency chain contains the target dynamic shared library, then the component is determined to be bound to an external open network listening port, and its network reachability is determined.

[0039] The task detection metadata, software material list, valid vulnerability matching records, hexagram directed acyclic graph evidence chain topology, and handling priority sequence are packaged and serialized into a structured report file containing JSON and PDF formats. The hash-based message authentication code (HMAC-SHA256) signature value of this structured report file is calculated. The structured report file with the signature value and the evidence topology data are written to a local protected isolated secure storage area to complete the tamper-proof archiving. In this signing process, the key used to generate the message authentication code is generated by the local offline computing node through a hardware random number generator during the device's initial initialization and stored in encrypted form in a non-volatile storage medium in the local protected isolated secure storage area. It can only be called by the detection engine's main process during archiving, ensuring key security and report tamper-proofness in the offline environment.

[0040] Example 2: The current test platform is deployed on a dedicated offline computing node, which is physically isolated from the external public network and cloud services. The hardware configuration includes a 64-core instruction processor, 256GB of RAM, and a high-speed NVMe solid-state storage array. The basic operating system runs a Linux-based kernel without a network interface. The test dataset consists of 10 industrial IoT firmware image samples covering ARM, MIPS, PowerPC, and x86 architectures. Each firmware sample is generated by cross-compilation toolchain with code optimization and complete static symbol stripping. It covers various packaging forms such as TRX segmented packaging, UBI image, SquashFS file system, CramFS file system, JFFS2 file system, and CPIO archive. Among them, the key component code segments of 5 samples have been implanted with the manufacturer's source code-level reverse porting security patch while keeping the external version declaration unchanged. The other sample has header truncation and format corruption perturbation manually injected into the physical space of the file system.

[0041] The test procedure sets up four parallel processing test groups. The test group of this invention sequentially performs recursive unpacking and trace retention, multi-dimensional feature extraction and probability supplement weighting, boundary comparison of basic block instruction sequence patch hash comparison in the control flow graph, construction of a six-ary directed acyclic graph evidence chain topology, and local vulnerability risk score calculation. Control group 1 only uses read-only data segment feature strings and filenames for single text fingerprint matching. Control group 2 only matches according to the external version number and the affected version constraint range in the vulnerability rules, without performing code segment opcode patch hash comparison. Control group 3 does not record the start byte offset and end byte offset in the original firmware image, nor does it construct a six-ary directed acyclic graph evidence chain topology, but directly outputs flat alarm results.

[0042] In setting the confidence threshold for component identification, the composite confidence level for a single weak path piece of evidence is 0.2000. When two pieces of auxiliary evidence are used in the calculation, the composite confidence level reaches above 0.7579. When strong evidence and auxiliary evidence are used simultaneously, the composite confidence level reaches above 0.9688. Based on this, the threshold for valid component identification is set at 0.50. In the test results, when the confidence level is below this threshold, forcibly confirming the component will increase the false alarm rate by more than 35%; when it is above this threshold, the overall identification accuracy reaches above 98%, and the component exposure surface network reachability coefficient is [not specified]. The values ​​are assigned based on the calling relationship between components and network packets: service components that open network listening ports and directly process external packets are assigned 1.0; system components that are only called by the local console are assigned 0.7; and isolated shared libraries that are not explicitly called in the service script are assigned 0.4. When the value is lower than 0.4, the corresponding component is in a non-running isolated state, and the evidence chain integrity weight is adjusted accordingly. Total number of necessary nodes in the standard chain of evidence Combined with the actual number of nodes for effective closure verification Component identification confidence Valid closed nodes are defined by the following conditions: the necessary fields of the node are complete, the data source relationship between adjacent nodes is valid, and the corresponding index can complete the verification.

[0043] During the component identification phase, sample F07 was a corrupted SquashFS firmware based on the ARM32 architecture. The target component was libsqlite3.so.0.8.6, and only the product term 0.200 was obtained. The component identification threshold was not met, therefore subsequent patch hash comparison was not triggered; control group 1 showed a false positive on this sample. Sample F03 uses ARM64 architecture and SquashFS encapsulation, the target component is busybox-1.27.2, and the product terms corresponding to the two effective feature dimensions are 0.644 and 0.320, which are obtained after probability supplementation weighting. Control group 1 was correctly identified. Sample F05 uses an x86_64 architecture and CPIO-initramfs encapsulation. The target component is lighttpd-1.4.35. The product terms corresponding to the three effective feature dimensions are 0.810, 0.665, and 0.510, respectively. After the same processing, the results are obtained. Control group 1 also correctly identified the problem.

[0044] The remaining samples were processed using the same data flow method. F01 adopted an ARM32 architecture and TRX-SquashFS encapsulation. The product terms corresponding to the three effective feature dimensions of the target component libcrypto.so.1.0.0 were 0.855, 0.630, and 0.480, respectively. After weighting with probability complements, the results were obtained. Control group 1 was correctly identified. F02 uses the MIPS32-BE architecture and UBI-UBIFS packaging. The two product terms of the target component dropbear-2016.74 are 0.595 and 0.450, respectively. Control group 1 correctly identified F06, which uses a PowerPC architecture and JFFS2 encapsulation. The two product terms of the target component dnsmasq-2.76 are 0.616 and 0.420, yielding... Control group 1 correctly identified F08, which uses the MIPS32-LE architecture and TRX-SquashFS encapsulation. The two product terms of the target component libssl.so.1.0.0 are 0.855 and 0.630, respectively. Control group 1 correctly identified F09 using ARM64 architecture and UBI packaging. The three product terms of the target component ntpd-4.2.8p10 are 0.630, 0.480, and 0.300, yielding... Control group 1 correctly identified the component. F10 uses the MIPS32-BE architecture and SquashFS encapsulation. The target component libz.so.1.2.8 only obtained a product term of 0.420. The component identification threshold was not met, so the patch hash comparison was not triggered; control group 1 showed a false alarm for symbol ambiguity on this sample.

[0045] For F04 with the symbol table completely stripped, the firmware uses the MIPS32-LE architecture and TRX-CramFS encapsulation. The target component is libcurl.so.4.3.0. The system parses the executable and linkable format header metadata, symbol table, dynamic segment, and read-only data segment of the binary program, and formats the architecture metadata, dynamic symbol table, and character slices into multi-dimensional feature vectors. The read-only data segment fingerprint and constant pool cross-reference results obtained in the original test are used for the comparison of corresponding features. Two effective dimensions are retained according to the feature matching results of each dimension. The type weights and feature extraction completeness coefficients used for the two dimensions are 0.70 and 0.80, 0.65 and 0.85, respectively, with corresponding product terms of 0.560 and 0.5525. Substituting the probability complement terms and weighting, the following is obtained: The result exceeded the component identification threshold, and the system confirmed that the component was successfully identified and associated with the general platform enumeration identifier. Control group 1 was missed because it could not retrieve the complete version declaration string from the read-only data segment, and the missed detection was recorded as fingerprint drift.

[0046] During patch integration status verification, the boundary comparison basic block instruction sequence hash values ​​of F01, F03, F05, and F08 did not match the preset patch characteristics, and the patch hash comparison status was unpatched and mismatched. The hash values ​​of F02, F04, F06, and F09 matched the preset security patch characteristics, indicating that the vendor had reverse-ported the security patch. The system set a false positive suppression flag and removed the corresponding vulnerability candidate records from the remediation queue. All four samples showed good risk scores after filtering. The record is 0.0000, indicating that the suppression is effective. In control group 2, no patch hash comparison was performed, and the results were still output according to the constraint range of the external version number and the affected version. Among them, alarms F02 scored 7.8 points, F04 scored 6.8 points, F06 scored 7.5 points, and F09 scored 7.5 points, all of which were false alarms, resulting in a total of 4 false alarms. After the test group of this invention completed the false alarm suppression, the effective false alarm rate was 0. F07 and F10 did not trigger patch hash comparison because the component identification confidence did not reach the judgment threshold.

[0047] For samples not filtered by the false positive suppression flag, the local vulnerability risk score is calculated again, F01. , The offline rule corresponds to a base score of 7.5, combined with Calculated Control group 2 also output 7.5 points, indicating this alarm is valid. F03 is only available for local console use. , The corresponding base score is 5.3, combined with Calculated Control group 2 directly output 5.3 points, without exposure area reduction, F05 , The corresponding base score is 8.1, combined with Calculated The control group 2 output a score of 8.1, which is a valid alarm.

[0048] In F08, libssl.so.1.0.0 exists only as an orphan shared library and is not called by any auto-starting service, therefore ;That The basic score of the general vulnerability scoring system recorded offline rules. At this point, the weight of the completeness of the chain of evidence The local vulnerability risk score is calculated according to a predetermined relationship as follows: This result corresponds to a low-risk level P4; control group 2 did not use the component exposed surface network reachability coefficient for reduction, directly outputting a score of 7.5 and triggering a high-risk alarm, F07. Only formed A valid closed-loop verification node with a risk score of 0.0000 is output and filtered; F10's ,form There are 1 valid closed verification node, and the risk score output is also 0.0000 and is filtered out. Control group 2 still outputs a false alarm of 4.5 points.

[0049] In physical storage backtracking, the system constructs a six-element directed acyclic graph evidence chain topology based on the unpacking phylogenetic tree and the bidirectional index relationship between file nodes at each level and the starting and ending byte offsets of the original firmware image. F01 can backtrack to 0x00080000 to 0x00A00000 and form a closure; F02 can backtrack to 0x00120000 to 0x00650000 and form a closure; F03 can backtrack to 0x00040000 to 0x00420000 and form a closure; F04 can backtrack to 0x00060000 to 0x0038000. 0 forms a closed loop; F05 can backtrack to 0x00020000 to 0x00900000 and form a closed loop; F06 can backtrack to 0x00080000 to 0x00500000 and form a closed loop; F08 can backtrack to 0x00080000 to 0x00A00000 and form a closed loop; F09 can backtrack to 0x00100000 to 0x00780000 and form a closed loop. All of the above normal samples can be traversed backwards from the vulnerability determination node along the directed edge, addressed to the original firmware image via the low-level feature slice node and the unpacked byte offset structure node. and .

[0050] Sample F07's SquashFS file system experienced a truncation anomaly at physical offset 0x004A0000. The test group of this invention triggered the failure rollback protection mechanism, truncated the abnormal data segment, calculated the fragment hash, and wrote a blocking marker into the unpacking phylogenetic tree branch, forming a 0x004A0000 blocking trace. Control group 2 recorded a parsing crash with no trace. In the physical storage traceability comparison, control group 3 also experienced a parsing anomaly crash and did not retain any valid data. F10, due to insufficient confidence in component identification and an unclosed evidence chain, recorded the physical offset backtracking status as unclosed, i.e., insufficient confidence.

[0051] Based on the outputs of each stage, F01 to F06, F08, and F09 can all reverse-link the vulnerability assessment results to the physical storage area of ​​the original firmware. For F02, F04, F06, and F09, which are reverse-ported patches, patch hash comparison can filter out the corresponding false alarms. For the isolated shared library F08, after the network reachability coefficient of the component exposure surface is included in the risk calculation, the local vulnerability risk score is determined by the actual calling relationship of the component. For F07, which has a corrupted format, the failure rollback protection mechanism retains the abnormal physical location and blocking record. In the above test process, recursive unpacking and trace retention, multi-dimensional feature extraction and probability supplementary weighting, boundary comparison of basic block instruction sequence patch hash comparison, construction of the six-element directed acyclic graph evidence chain topology, and calculation of local vulnerability risk scores are all completed in the local physical isolation environment.

[0052] Example 3: The system accesses the embedded IoT firmware image deployed on the monitoring and control terminal of the smart grid substation via physical storage media, and opens an independent static analysis sandbox workspace in the local isolated storage partition; reads the binary data stream of the IoT firmware file to be tested, calculates the full secure hash algorithm SHA256 hash value and the segmented context triggered fuzzy hash value SSDEEP of the file, obtains the file size as 16,777,216 bytes, extracts the firmware encapsulation extension and import timestamp, and generates a globally unique task identifier TASK_ID_20260818_004. The system initializes the unpacking task queue and genealogy tracking context structure. After reading the first 256 bytes of the header of the IoT firmware file to be detected, which are the magic number and corresponding metadata, it identifies the outer encapsulation format as a UBI image structure. For encrypted segments whose processing method can be determined based on the encapsulation format, the corresponding decryption is completed locally first. Then, the UBI offline unpacking engine is called to parse and mount the UBIFS file system. The system deconstructs the directory structure and executable binary program payload at each level in the physical storage offset range from 0x00120000 to 0x00650000, and generates the corresponding genealogy in the unpacking genealogy tree. The system node records the current unpacking level depth of 2, the unpacking tool identifier ubifs_extractor, the physical start byte offset 0x00120000, the end byte offset 0x00650000, and the extraction integrity verification status. The parser also retains the index relationship between each level of file node and its corresponding physical byte range in the original firmware image, so that the file node can index the start byte offset and end byte offset, and can reverse locate the corresponding file node from the physical byte range. When recursively traversing the extraction product, if an unknown private encrypted segment or checksum truncation exception that cannot be processed according to the recognized encapsulation format is encountered, the failure rollback protection mechanism is triggered, the physical offset range of the abnormal data segment is truncated and the segment hash value is calculated, and the blocking status mark and abnormal exit code are written into the unpacking tree branch, and then the subsequent objects in the queue are processed. When parsing the system initialization script and Web service configuration file, the device sensitive identity credentials and private key strings are masked, and only the network communication port definition and daemon startup parameters are extracted to obtain the extraction object set containing the file system root directory tree, ELF binary program, dynamic shared library and configuration file.

[0053] The system iterates through the object collection, locating the target service program ` / usr / sbin / dropbear`. The static symbol table `.symtab` of this binary program has been completely stripped, and the `opkg` and `dpkg` package management database files are not present in the file system. The executable and linkable header metadata is parsed to extract the target instruction set architecture, endianness, and a list of dependent shared libraries, forming the architecture metadata. Simultaneously, the dynamic segment and dynamic symbol table are parsed to extract the obtainable sequences of dynamically exported and imported function symbols. The system continues scanning the read-only data segment `.rodata`, slicing constant strings of a preset length, and then analyzing the code segment `.te`. The cross-reference instructions in xt locate the corresponding character slices, resulting in a set of local character slices containing the version feature string "dropbear", the SSH protocol identifier "SSH-2.0-dropbear", and the authentication function constant string. The relative physical distance offset of each character slice in the binary image is calculated and compared with the local offline component feature fingerprint library for subgraph isomorphism. The result shows that the character slice string overlap rate is 80.0%, which is higher than the preset threshold of 75.0%, and the relative physical distance distribution conforms to the cross-compilation spatial layout constraints. The file path and naming pattern are recorded synchronously as auxiliary verification information when locating component files and generating software bill of materials.

[0054] The architecture metadata, dynamic symbol table, and character slices were formatted into multidimensional feature vectors. No target derived symbols capable of contributing to effective component matching were detected in the dynamic symbol table. Therefore, this probability supplementary weighting calculation used two effective dimensions: character slices and architecture metadata, to maintain... Character slice dimensions use type weights Feature extraction completeness coefficient Its effective matching contribution is 0.5525, and the complement contribution is 0.4475; the architecture metadata dimension uses type weighting. Feature extraction completeness coefficient Its effective matching contribution is 0.2800, and the complement contribution is 0.7200. , and Both remain within the predetermined value range of 0 to 1. The product of the two complementary terms is 0.4475 × 0.7200 = 0.3222. The component identification confidence level is obtained from the weighted relationship of the probability complementary terms. If the value is higher than the preset judgment threshold of 0.50, the component identification is confirmed to be successful. The target component is then mapped to the standard component identifier and version number cpe:2.3:a:dropbear_ssh_project:dropbear:2016.74:::::::× and the corresponding universal resource locator. A software bill of materials is generated, which includes the standard component identifier and version number, the physical file path / usr / sbin / dropbear, the file SHA256 hash value, the component identification confidence level, and the associated evidence index.

[0055] Load the local offline vulnerability rule base and search for candidate vulnerability rules based on the standard component identifier and version number. Two mutually exclusive conflicting rules, RULE_DROPBEAR_001 and RULE_DROPBEAR_002, targeting the Dropbear component are found. RULE_DROPBEAR_001 is associated with the common vulnerability disclosure number CVE-2016-7406, with a base score of 7.8 in the common vulnerability scoring system. Its necessary evidence dependency condition requires the existence of the dynamically exported symbol svr_auth in the binary program; however, this symbol does not exist in the dynamic symbol table of the current target binary program. Therefore, this rule does not meet the necessary evidence dependency condition and is removed in the initial rule screening stage. RULE_DROPBEAR_002 is associated with the common vulnerability disclosure number CVE-2017-10790. The affected version constraint range is less than or equal to 2016.74. The current standard component identifier and version number satisfy the version algebra inclusion property. After disassembling the code segment .text of the target binary program, the buf_decompress control flow graph corresponding to the vulnerable code is located. Based on conditional jumps, pre-comparisons and their data flow dependencies, the target basic block containing buffer decompression length boundary check logic is located. The boundary comparison basic block instruction sequence is extracted, the relative address jump offset in the operands is filtered and the cryptographic hash value of the normalized opcode sequence is calculated. This hash value matches the hash feature in the pre-set patch features. Based on this, it is determined that the device manufacturer has reverse-ported the security patch, and the false alarm suppression flag is set.

[0056] Construct a six-ary directed acyclic graph evidence chain topology in the memory data space and create the original firmware hash root node. Write the firmware SHA256 hash value and task identifier TASK_ID_20260818_004; create an unpacking byte offset structure node. Write the unpacking tool identifier ubifs_extractor, unpacking level depth 2, start byte offset 0x00120000 and end byte offset 0x00650000; create a component material identifier node. Write the standard component identifier and version number cpe:2.3:a:dropbear_ssh_project:dropbear:2016.74:::::::×, file path / usr / sbin / dropbear, and component identification confidence level of 0.6778; create low-level feature slice nodes. Write architecture metadata, dynamic symbol table, relative physical distance information of character slices, and basic block instruction hash values ​​of code segments; create offline vulnerability rule nodes. Write the rule number RULE_DROPBEAR_002, the affected version constraint range, and the patch merging status; create a vulnerability determination conclusion node. Before establishing directed edges between adjacent nodes, and after writing the vulnerability ID CVE-2017-10790, the base score of 7.5, and the false positive suppression flag, the data source relationships between the firmware and the unpacking physical region, the unpacking artifacts and component files, the components and underlying characteristics, the components and vulnerability rules, and the vulnerability rules and assessment conclusions are verified level by level. Once all the above relationships and corresponding indexes are verified to be valid, a [process] is formed. The topological dependency sequence, where each node satisfies the established valid closure verification conditions, can be traversed in reverse order along the directed edges from the vulnerability judgment conclusion node to locate the absolute byte range 0x00120000 to 0x00650000 of the original firmware image in the physical storage medium.

[0057] When performing local quantization calculations on the evidence chain topology of a six-element directed acyclic graph, the service startup script is parsed to confirm that the SSH service daemon is bound to external network listening port 22 and directly handles network communication connections. Total number of necessary nodes in a standard chain of evidence The current number of nodes that are actually valid closure verification , combined Calculated ,according to , and Three factors determine the local vulnerability risk score, resulting in... The vulnerability is then classified according to the established risk level range. Subsequently, based on the set false alarm suppression flag, candidate records are filtered, and their status is updated to "patched and merged into suppressed and removed from the remediation queue." The suppressed alarm output record is 0.0000 points and is not rewritten based on this suppression result. The three-factor calculation value.

[0058] The task detection metadata, software bill of materials, multi-rule conflict resolution records, false alarm suppression status, hexagram directed acyclic graph evidence chain topology, and security compliance judgment conclusions are packaged and serialized into a structured report file containing JSON and PDF formats. The HMAC-SHA256 signature value of the structured report file is calculated, and the structured report file with the signature value and the evidence topology data are written to a local protected isolated secure storage area to complete the tamper-proof archiving.

[0059] Example 4: This example combines Figures 1 to 2 This paper describes a method for analyzing the components of IoT firmware software and detecting vulnerabilities using an offline evidence chain. Figure 1 As shown, in step S1, the encapsulation structure of the IoT firmware file to be detected is parsed, the nested file system image and binary program are recursively extracted, and the starting byte offset and ending byte offset of the extracted product in the original firmware image are recorded; in step S2, the multi-dimensional feature set of the binary program is extracted, the component identification confidence is calculated using a probability complement weighting algorithm, and the multi-dimensional feature set with the component identification confidence reaching a preset threshold is mapped to the standard component identifier and version number to generate a software bill of materials; in step S3, candidate vulnerability rules in the offline vulnerability rule base are retrieved according to the standard component identifier and version number, and the vulnerability is disassembled. The code segment affected by the vulnerability is extracted, and the boundary comparison basic block instruction sequence in the control flow graph of the vulnerability's key function is used to calculate the instruction hash value. The patch merging status is determined by comparing the preset patch characteristics and a false positive suppression flag is generated. In step S4, the firmware hash, start byte offset and end byte offset, software bill of materials, multi-dimensional feature set, matched vulnerability rules and vulnerability judgment conclusions are organized into a six-element directed acyclic graph evidence chain topology. False positive items are eliminated according to the false positive suppression flag, and the vulnerability detection result is output by backtracking along the six-element directed acyclic graph evidence chain topology to the start byte offset and end byte offset of the original firmware image.

[0060] like Figure 2As shown, the master control scheduling unit loads the IoT firmware file to be tested and maintains the unpacking task queue. The master control scheduling unit transmits the IoT firmware file to be tested to the target computing node through a distribution operation. The target computing node constructs an unpacking phylogenetic tree and extracts a multi-dimensional feature set in the isolated analysis workspace. Based on the multi-dimensional feature set, it generates a software bill of materials and organizes the analysis results into a six-element directed acyclic graph evidence chain topology. The target computing node establishes task collaboration with candidate idle computing nodes through fault-tolerant takeover scheduling. The candidate idle computing nodes are configured with an isolated analysis workspace containing the unpacking phylogenetic tree and collaborate with the offline large language model quantization acceleration unit to perform computation processing. The master control scheduling unit, the target computing node, and the candidate idle computing nodes are all physically interconnected with a physical isolation network to perform data interaction and state synchronization. The target computing node directly outputs data to the local protected isolated secure storage area through a write operation. The local protected isolated secure storage area isolates and maintains the offline vulnerability rule base and component feature fingerprint base and stores the received structured report files.

[0061] Example 5: The current industrial field analysis node is in a physically isolated environment. Before starting the firmware security detection task, baseline verification and dynamic maintenance are performed on the offline vulnerability rule base and component feature fingerprint base. The rule increment data packet encapsulated with offline signature is imported through a read-only physical storage medium. The full secure hash value of the rule increment data packet header is parsed, and the verification is completed in combination with the built-in root certificate public key to confirm that the rule increment data packet is complete and the generation timestamp is later than the current local baseline version. Then, the standard component mapping table and patch feature hash entries in the rule increment data packet are parsed to reconstruct the bidirectional search index of the component feature fingerprint base and the offline vulnerability rule base. The type weight corresponding to each evidence item is verified to be in the range of 0 to 1. A sliding time window is configured for historical vulnerability matching records, and a time decay coefficient of 0.85 is configured for private rule entries that have not been matched for more than 180 days, so that the offline vulnerability rule base and component feature fingerprint base continue to perform matching according to the current local baseline in the offline environment without public network connection.

[0062] In an offline analysis cluster composed of multiple computing nodes, the master control scheduling unit distributes the IoT firmware file to be detected to the target computing node according to the idle load status of each computing node and the file hash value. When the analysis processing time of the target computing node exceeds the preset heartbeat timeout threshold of 300 seconds, the offline analysis cluster triggers fault-tolerant takeover scheduling, and reads the latest recorded unpacking level depth, unpacking tool identifier, and starting byte offset in the unpacking phylogenetic tree of that computing node. offset from end byte The system intercepts the incomplete parsing of the mirror payload data stream and redistributes it to candidate idle computing nodes. Each candidate idle computing node inherits the corresponding unpacking family context and continues recursively unpacking, extracting the multi-dimensional feature set of the binary program. A probability-based weighted algorithm is then used to calculate the component identification confidence score. Once the component identification confidence score reaches a preset threshold, the corresponding multi-dimensional feature set is mapped to a standard component identifier and version number, and a software bill of materials is generated. This process continues until each computing node completes the software bill of materials generation, the construction of the six-element directed acyclic graph evidence chain topology, and the local vulnerability risk score. After solving, the master control scheduling unit summarizes the structured report files output by each computing node to form an aggregated structured report file, and calculates the HMAC-SHA256 signature value of the file. Finally, the aggregated structured report file with the signature value and the hexagram directed acyclic graph evidence chain topology data are written to the local protected isolated secure storage area to complete the tamper-proof archiving.

[0063] Example 6: The system performs offline component analysis and vulnerability assessment on the firmware image of an industrial programmable logic controller deployed in the monitoring and control unit of an intelligent power distribution substation. This firmware image is encapsulated using the CramFS file system, and the code segments are inlined and expanded using a cross-compiler. The system reads the firmware data stream, calculates the full-scale secure hash algorithm SHA256 hash value and the segmented context-triggered fuzzy hash value SSDEEP, obtains a file size of 16,777,216 bytes, generates a globally unique task identifier TASK_ID_20260818_006, and stores it locally. An isolated sandbox working area is created in a non-volatile storage medium. The CramFS offline parser is called to deconstruct the file system directory tree in the physical storage offset range from 0x00040000 to 0x00580000. The unpacking hierarchy tree records the unpacking level depth 2, the unpacking tool identifier cramfs_extractor, the starting byte offset 0x00040000, and the ending byte offset 0x00580000. The object set is traversed and extracted to locate the network communication service program / usr / bin / modbus_gw.

[0064] The static symbol table of this program has been stripped, and the file system lacks package management remnants. The executable and linkable format header metadata is parsed to extract the target instruction set architecture as ARM architecture little-endian format, and dependent shared library information is obtained. Dynamic segments and dynamic symbol tables are parsed to extract the available dynamically exported function symbols and externally imported function symbol sequences. Simultaneously, the read-only data segment .rodata is scanned, and constant strings reaching a preset length are sliced. The corresponding character slices are located along the cross-reference instructions in the code segment .text, obtaining the Modbus protocol stack identifier Modbus-TCP-Stack-v2.1 and communication status strings. The relative physical distance offset of each character slice in the binary image is calculated. The architecture metadata, dynamic symbol table, and character slices are formatted into multi-dimensional feature vectors and compared with the local offline component feature fingerprint database. The character slice string overlap reaches 82.5%, and the relative physical distance conforms to the compiler layout constraints. Based on this, the matching results for the character slice dimension are obtained. The original filename pattern continues to serve as auxiliary verification information for component file location and the matching results for this dimension.

[0065] In this embodiment, character slice matching uses a preset type weight in the two effective matching dimensions. and feature extraction completeness coefficient Another effective dimension combines the verification results of architecture metadata and file paths and naming patterns, using... and The matching results from the two dimensions are input into the probability complement weighted model to determine the confidence level of component identification. Calculate using the following formula: ,in, ; satisfy , satisfy The first matching result is The corresponding supplementary item is The second matching result is The corresponding supplementary item is ; multiplying all the supplementary terms yields Thus we obtain If the value is greater than the preset judgment threshold of 0.50, the component is confirmed to be successfully identified. The corresponding multi-dimensional feature set is then mapped to the standard component identifier and version number, and the corresponding software bill of materials item is generated.

[0066] Searching the offline vulnerability rule base based on the standard component identifier and version number, the rule entry RULE_MODBUS_001, which covers the affected version constraint range of version 2.1, was found. This rule is associated with the general vulnerability disclosure number CVE-2018-11529 and the basic score of the general vulnerability scoring system. The target binary program is disassembled, and the control flow graph of the critical vulnerability function `process_modbus_pdu` is located. The boundary comparison basic block instruction sequence is extracted from the target basic block containing message length boundary checking logic. The absolute memory addresses and relative jump offsets in the operands are filtered out, and only the normalized machine opcode sequence is retained and the SHA256 hash value is calculated. The obtained hash value is compared with the hash feature in the preset patch features. If the comparison result is inconsistent, it is determined that the current binary program has not been patched. The false positive suppression flag is kept in the reset state, and the candidate vulnerability rule is effectively hit.

[0067] Construct a six-ary directed acyclic graph evidence chain topology in memory, and sequentially create the original firmware hash root node. Unpacking byte offset structure node Component material identification node Low-level feature slice nodes Offline vulnerability rule nodes and vulnerability assessment conclusion node Construct directed edges with causal constraints based on the unpacking genealogy and vulnerability derivation relationship: Each level node has completed effective closure verification and can traverse backwards along the directed edge from the vulnerability judgment conclusion node to address the original firmware image at the starting byte offset 0x00040000 and the ending byte offset 0x00580000 on the physical medium.

[0068] When performing quantitative calculations on the chain of evidence, the system initialization script / etc / init.d / rcS is parsed to confirm that the modbus_gw daemon is bound to external network listening port 502 and directly processes external communication packets, thus determining the network reachability coefficient of the component's exposed surface. Total number of necessary nodes in a standard chain of evidence The number of nodes that have passed the valid closure verification. Weight of completeness of the chain of evidence Calculate using the following formula: Substituting the values, we get Then, the local vulnerability risk score is calculated. : Substituting the values, we get Round to four decimal places and output. According to the preset risk level range, The calculation results determined it to be a medium-risk level P3, and it was included in the priority sequence for on-site remediation and disposal accordingly.

[0069] When the host computing device detects the deployment of a local offline large language model quantization acceleration unit, it serializes the completed six-element directed acyclic graph evidence chain topology node data, software bill of materials metadata, and network port call relationships into a local structured input context. Within the physically isolated environment, it calls the offline large language model and outputs a judgment conclusion including control flow anomaly analysis, configuration hardening instructions for the substation network access control list, and port restriction suggestions. The generated hardening instructions are then written into the vulnerability judgment conclusion node. Subsequently, the task metadata, software bill of materials, six-element directed acyclic graph evidence chain topology, and on-site repair and disposal priority sequence are packaged into a structured report file. The hash-based message authentication code HMAC-SHA256 signature value of the structured report file is calculated, and the structured report file with the signature value is written to a local protected isolated secure storage area to complete the tamper-proof archiving.

[0070] The embodiments of this application have been described above with reference to the accompanying drawings. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. This application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit of this application and the scope of protection of this invention, and all of these forms are within the protection scope of this application.

Claims

1. A method for offline vulnerability detection of IoT firmware software components and evidence chains, characterized in that, Includes the following steps: Step S1: parse the encapsulation structure of the IoT firmware file to be tested, recursively extract the nested file system image and binary program, and record the starting byte offset and ending byte offset of the extracted product in the original firmware image. Step S2: Extract the multi-dimensional feature set of the binary program, calculate the component identification confidence using a probability supplementary weighting algorithm, map the multi-dimensional feature set with the component identification confidence reaching a preset threshold to the standard component identifier and version number, and generate a software bill of materials; Step S3: Retrieve candidate vulnerability rules in the offline vulnerability rule base according to the standard component identifier and version number, disassemble the code segment affected by the vulnerability, extract the boundary comparison basic block instruction sequence in the control flow graph of the vulnerability key function and calculate the instruction hash value, compare the preset patch characteristics to determine the patch merging status and generate a false alarm suppression flag. Step S4: Organize the firmware hash, start byte offset and end byte offset, software bill of materials, multi-dimensional feature set, matching vulnerability rules and vulnerability judgment conclusions into a six-element directed acyclic graph evidence chain topology. Based on the false alarm suppression flag, remove false alarm items and output the vulnerability detection results that are backtracked along the six-element directed acyclic graph evidence chain topology to the start byte offset and end byte offset of the original firmware image.

2. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 1, characterized in that, The process of parsing the encapsulation structure of the IoT firmware file to be tested in step S1 includes: parsing the header magic number and metadata of the IoT firmware file to be tested to identify the encapsulation format, and decrypting and decompressing according to the encapsulation format; identifying nested file system images through file feature scanning, mounting and deconstructing the directory structure and independent binary programs; establishing an unpacking genealogy tree, and bidirectionally indexing and binding the file nodes at each level generated by unpacking with the corresponding start byte offset and end byte offset in the original firmware image.

3. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 1, characterized in that, The process of extracting the multidimensional feature set of the binary program in step S2 includes: parsing the executable and linkable format header metadata of the binary program, extracting the target instruction set architecture, endianness, and list of dependent shared libraries; parsing the symbol table and dynamic segments, extracting unstripped symbols, dynamically exported function symbols, and sequences of externally imported function symbols; scanning the read-only data segment, extracting constant string slices of a preset length, and formatting them into a multidimensional feature vector containing architecture metadata, dynamic symbol table, and character slices.

4. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 3, characterized in that, The process of calculating the component recognition confidence using the probability complement weighting algorithm in step S2 includes: applying preset type weights and feature extraction completeness coefficients to the architecture metadata, dynamic symbol table, and character slices in the multidimensional feature vector; establishing a probability complement function for the matching degree of each feature dimension; inputting the matching results of the multidimensional features into the probability complement weighting model for convergence calculation; and outputting a component recognition confidence value between 0 and 1; when the component recognition confidence value is greater than or equal to a preset threshold, confirming successful component recognition and associating it with a general platform enumeration identifier.

5. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 1, characterized in that, Step S3 involves retrieving candidate vulnerability rules from the offline vulnerability rule base, including: reading the affected version constraint range and necessary evidence dependency conditions corresponding to the security vulnerability entries from the offline vulnerability rule base; performing version algebra inclusion matching between the standard component identifiers and version numbers in the software bill of materials and the affected version constraint range; verifying whether the binary program contains the dynamic link library file or specific exported symbols specified in the necessary evidence dependency conditions, and eliminating candidate rule items that do not meet the symbol dependency to complete the initial rule screening.

6. The method for IoT firmware software component analysis and offline vulnerability detection based on evidence chain according to claim 1, characterized in that, Step S3, which determines the patch integration status and generates a false positive suppression flag, includes the following steps: when the standard component identifier and version number fall within the affected version constraint range of the candidate vulnerability rules, disassembly locates the assembly instruction flow corresponding to the vulnerability-affected code segment; constructs the control flow graph of the vulnerability's critical functions and locates the target basic block containing boundary check logic; extracts the opcode sequence from the target basic block and filters the operand address offsets, and calculates the cryptographic hash value of the normalized opcode sequence; compares the cryptographic hash value with the hash features in the pre-built security patch feature library; when the hash values ​​match, it is determined that the vendor has reverse-ported the security patch, sets the false positive suppression flag, and blocks the generation of external alarms.

7. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 1, characterized in that, The process of organizing the evidence chain topology into a six-element directed acyclic graph in step S4 includes: creating six types of topology nodes that represent the original firmware hash root node, the unpacked byte offset structure node, the component material identifier node, the low-level feature slice node, the offline vulnerability rule node, and the vulnerability judgment conclusion node, respectively; establishing directed edges with causal constraints between adjacent level nodes according to the unpacking genealogy and vulnerability deduction logic to form a six-element directed acyclic graph; when generating the final vulnerability report, traversing the directed edges in reverse from the vulnerability judgment conclusion node, and addressing the start byte offset and end byte offset in the original firmware image through the corresponding low-level feature slice node and unpacked byte offset structure node.

8. The method for IoT firmware software component analysis and offline vulnerability detection based on evidence chain according to claim 1, characterized in that, Step S4, which involves outputting the vulnerability detection results, also includes calculating the local vulnerability risk score. : ,in, The base score for the general vulnerability scoring system recorded in the offline vulnerability rule base; The network reachability coefficient of the component's exposed surface is set to the first preset value when the component is bound to an external open network listening port, the second preset value which is less than the first preset value when the component is only called by the local console, and the third preset value which is less than the second preset value when the component is an isolated shared library. The evidence chain integrity weight is calculated by multiplying the proportion of nodes that pass effective closure verification to the total number of necessary nodes in the standard evidence chain with the component identification confidence level; based on the calculated... The detected vulnerabilities are classified into different levels based on numerical values.

9. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 8, characterized in that, Step S4 is followed by: filtering all matched vulnerability candidate records based on the false positive suppression flag; when the false positive suppression flag is set, updating the status of the corresponding vulnerability record to "patched and suppressed" and removing it from the remediation queue; for valid vulnerability records that have not been suppressed, based on the local vulnerability risk score... The priority sequence for on-site repair and treatment is arranged in descending order of high to low.

10. The method for IoT firmware software component analysis and offline vulnerability detection based on the evidence chain according to claim 9, characterized in that, After prioritizing on-site repair and handling, the process also includes: packaging and serializing the task detection metadata, software material list, valid vulnerability matching records, six-element directed acyclic graph evidence chain topology, and handling priority sequence into a structured report file; calculating the hash-based message authentication code (HMAC-SHA256) signature value of the structured report file; and writing the structured report file with the signature value into a local protected isolated secure storage area to complete tamper-proof archiving.

Images