Internet of Things equipment firmware online identification method based on interactive simulation acquisition

Abstract

The invention relates to the field of Internet of Things security, in particular to an Internet of Things equipment firmware online identification method based on interactive simulation acquisition, and aims to realize high-robustness and interpretable firmware version online identification. Comprising the following steps: executing two-stage simulation on a target firmware sample, and repairing an application logic problem identified by the first-stage simulation during the second-stage simulation so as to acquire an available Web page during firmware operation; the method comprises the steps of analyzing a Web page when firmware runs, extracting a hypertext markup language structure, a cascading style sheet structure and a JavaScript structure in the Web page, and constructing the structures of the three languages and the mutual relation thereof into a unified relational graph as a fingerprint of a target firmware sample; and calculating the similarity between the relational graph fingerprint corresponding to the firmware to be identified and the relational graph fingerprint corresponding to the known firmware version in the fingerprint database by using an improved Weisfeier-Lehman graph accounting method, and completing online identification of the firmware version according to the similarity.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security, and in particular to an online identification method for IoT device firmware based on interactive simulation data acquisition. Background Technology

[0002] With the rapid development of IoT technology, the number of IoT devices such as network cameras and wireless routers is growing exponentially. These devices typically run embedded firmware, and a large number of online devices, due to a lack of timely updates, still run outdated firmware versions with known security vulnerabilities, creating a huge attack surface. Attackers can exploit these vulnerabilities to gain large-scale control of devices, launch distributed denial-of-service attacks, or build botnets, posing a serious threat to network security. Therefore, accurately identifying the firmware versions running on IoT devices on the Internet and then matching them to vulnerability databases to assess their risks has become an urgent security requirement.

[0003] Currently, the mainstream technical approach for online firmware version identification of IoT devices is to build a fingerprint database by collecting runtime characteristics of the devices (especially the page content returned by their embedded web management interface), and then achieve identification through feature matching. However, building a large-scale, high-quality fingerprint database faces significant challenges. Directly scanning massive numbers of real devices to collect features poses significant problems in terms of compliance, ethics, and the risk of interference with target devices. Therefore, existing technologies have shifted to running firmware samples in a controlled simulation environment to collect features. Common remanaged techniques aim to achieve protocol-level fidelity by replacing the kernel and starting the firmware system in an emulator, ensuring the survival of the web service process, network reachability, and the return of HTTP responses. However, these existing simulation techniques have significant drawbacks: while they can guarantee service responsiveness, the returned HTTP response content is often an error page, a blank page, or a placeholder page with incomplete functionality, failing to provide effective web page features for high-precision version identification. Summary of the Invention

[0004] The purpose of this invention is to provide an online firmware identification method for IoT devices based on interactive simulation data acquisition, aiming to achieve robust and interpretable online firmware version identification.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: This invention provides an online firmware identification method for IoT devices based on interactive simulation acquisition, comprising: S1: performing a two-stage simulation on the target firmware sample, and fixing the application logic problems identified in the first stage simulation during the second stage simulation to acquire a usable firmware runtime web page; S2: parsing the firmware runtime web page, extracting the Hypertext Markup Language (HTML) structure, Cascading Style Sheets (CSS) structure, and JavaScript (JS) script structure, and constructing a unified relational graph of the three languages ​​and their interrelationships as the fingerprint of the target firmware sample; wherein, the interrelationships include the style association relationship between CSS selectors and HTML nodes, and the behavior binding relationship between JavaScript nodes and HTML nodes; S3: using an improved Weisfeiler-Lehman graph kernel algorithm, calculating the similarity between the relational graph fingerprint corresponding to the firmware to be identified and the relational graph fingerprint corresponding to a known firmware version in the fingerprint database, and completing the online identification of the firmware version based on the similarity.

[0006] The two-stage simulation in step S1 includes: the first stage basic simulation: starting the preprocessed target firmware sample in the simulator and performing network connectivity tests and Web service response tests, while recording network configuration logs and process status logs during the simulation; the second stage interactive repair simulation: judging whether the Web application logic of the target firmware sample is abnormal based on the network configuration logs and process status logs; if the Web application logic of the target firmware sample is abnormal, automatically executing at least one repair operation for the application logic until a complete firmware runtime Web page can be collected.

[0007] Repair operations targeting application logic include at least one of the following: network configuration repair, critical process recovery, general gateway interface execution link repair, page routing repair, or dynamic host configuration protocol service bypass.

[0008] Network configuration repair includes: parsing network configuration logs, extracting network interface, address, bridging and virtual LAN information, and constructing a set of network constraints; based on the set of network constraints, generating and injecting a defined virtual network device configuration on the host side to restore the network connectivity of the target firmware sample in the simulation environment.

[0009] Critical process recovery includes: checking the mount status of the process file system in the simulation environment and repairing the mount if the mount status is abnormal; locating the web server and the set of critical processes that the web server depends on based on the process status log, and triggering the reconstruction of the system initialization chain to restore service startup if any critical processes are missing.

[0010] The generic gateway interface execution link repair includes: identifying the generic gateway interface program in the web server configuration and checking the dynamic link libraries it depends on; when a missing dynamic link library is detected, searching for and filling in the missing dynamic link library from other compatible firmware samples from the same vendor.

[0011] Step S2 specifically includes: S21: Parsing the Hypertext Markup Language (HTML) content of the firmware runtime web page, generating a Document Object Model (DOM) tree, and using DOM nodes as nodes representing the page structure in the relational graph; S22: Parsing the Cascading Style Sheets (CSS) content of the firmware runtime web page, extracting selector levels, and using selector level units as nodes representing style information in the relational graph; S23: Parsing the JavaScript content of the firmware runtime web page, generating an Abstract Syntax Tree (AST), and using syntax units as nodes representing behavior information in the relational graph; S24: Establishing style association edges from CSS nodes to HTML nodes based on the matching relationship between CSS selectors and DOM nodes; establishing behavior binding edges from JavaScript nodes to HTML nodes based on the JavaScript's access or operation relationships to DOM nodes.

[0012] In step S3, the improved Weisfeiler-Lehman graph kernel algorithm collects information about the neighboring nodes of the current node during the iterative refinement of node labels. The neighboring node information includes the type of the connecting edge, the type of the neighboring node, and the previous label of the neighboring node.

[0013] In step S3, the improved Weisfeiler-Lehman graph kernel algorithm is used to calculate the similarity. Specifically, for the two relational graphs to be compared, multiple rounds of node label iteration refinement are performed. After each round of iteration, the frequency of occurrence of different refinement labels is counted according to the node type to form a feature vector. The inner product of the corresponding feature vectors of the two relational graphs in each round of iteration is used as the base kernel value of each round, and the contributions of different node types are weighted and summed. The base kernel values ​​of multiple rounds of iteration are accumulated to obtain the total graph kernel value, and the total graph kernel value is normalized to obtain the similarity in the interval [0,1].

[0014] Before step S1, there is a data collection step for firmware samples and vulnerability information; after step S3, there is a vulnerability association step: matching the identified firmware version with the vulnerability knowledge base and outputting the known vulnerability information associated with the firmware version.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. The online firmware identification method for IoT devices based on interactive simulation acquisition provided in this application embodiment completes the preliminary verification of basic connectivity and service response through the first stage of simulation, while retaining network configuration and process status logs to provide accurate basis for subsequent repairs. Then, through the second stage of simulation, targeted repair operations are performed on typical application logic problems such as abnormal network configuration, missing critical processes, general gateway interface link collapse, page routing errors, and DHCP service blocking. Compared with the drawbacks of traditional simulation technology, which is prone to blank pages, error pages, and pages with incomplete functions, the method provided in this application embodiment can reliably obtain complete and renderable valid Web pages, greatly improving the usability of firmware fingerprint samples and laying a high-quality data foundation for the construction of a large-scale firmware fingerprint database.

[0016] 2. The method provided in this application constructs a unified relational graph fingerprint that integrates the HTML document object model structure, CSS selector style hierarchy, and JavaScript script behavior logic. It also establishes cross-language style association edges and behavior binding edges, achieving a joint representation of three-dimensional features: structure, style, and behavior. This fingerprint not only includes static page layout information but also encompasses style rendering rules and dynamic interaction logic. It can effectively distinguish firmware using the same basic template but with version differences, solving the problem of traditional fingerprints failing to differentiate due to template reuse, and significantly improving the uniqueness and anti-interference capability of the fingerprint.

[0017] 3. The method provided in this application provides targeted improvements to the Weisfeiler-Lehman graph kernel algorithm. It incorporates heterogeneous information such as edge type and neighbor node type during the node label iteration and refinement stage, and weights and normalizes the similarity calculation by node type. This not only adapts to the heterogeneous features of cross-language relational graphs but also accurately characterizes the similarity of different firmware fingerprints in local substructures. Compared to black-box deep learning models, the recognition process is traceable and interpretable, avoiding the black-box drawbacks of model decision-making. Simultaneously, the normalized similarity calculation method reduces the impact of graph size differences on the recognition results, significantly improving the accuracy and robustness of version matching, and enabling accurate determination of firmware versions. Attached Figure Description

[0018] Figure 1 This is a flowchart of an online firmware identification method for IoT devices based on interactive simulation data acquisition, provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0020] This application provides an online firmware identification method for IoT devices based on interactive simulation data acquisition. For example, such as... Figure 1 As shown. The method includes: S1: Perform a two-stage simulation on the target firmware sample, and fix the application logic problems identified in the first stage simulation during the second stage simulation in order to collect a usable firmware runtime web page.

[0021] For example, prior to step S1, a data collection step for firmware samples and vulnerability information is included. Firmware samples and vulnerability information are obtained from vendor websites, FTP sites, and vulnerability disclosure websites using a custom web crawler, forming firmware datasets and vulnerability datasets. The correlation between vulnerabilities and firmware is then organized and analyzed, providing basic data support for subsequent firmware version matching and vulnerability analysis. Through this process, firmware samples from different manufacturers, models, and versions can be stored under a unified data structure, while maintaining a traceable mapping between vulnerability entries and version ranges, enabling rapid vulnerability matching after firmware version identification.

[0022] For example, the two-stage simulation in step S1 includes: the first stage basic simulation: starting the preprocessed target firmware sample in the simulator and performing network connectivity tests and Web service response tests, while recording network configuration logs and process status logs during the simulation; the second stage interactive repair simulation: judging whether the Web application logic of the target firmware sample is abnormal based on the network configuration logs and process status logs; if the Web application logic of the target firmware sample is abnormal, automatically executing at least one repair operation for the application logic until a complete firmware runtime Web page can be collected.

[0023] For example, before performing the two-stage simulation, the original firmware image is first preprocessed to ensure that the target firmware sample meets the basic conditions for full-system simulation operation. The original firmware image refers to the complete firmware image file officially released by the IoT device manufacturer, which has not undergone any simulation adaptation or manual modification, and is the original carrier of the IoT device firmware. The preprocessing stage specifically includes the following operations: extracting kernel-related information from the original firmware image to clarify the kernel version information and identify the startup method of the firmware initialization program; performing the image file preparation process on the file system extracted from the original firmware image, extracting the architecture information and runtime environment information of the original firmware image, creating corresponding associated images, and creating necessary soft links and filling in missing directories within the file system; identifying the type of web server and its corresponding configuration file in the original firmware image; reusing the initial configuration of non-volatile random access memory for different devices from the same manufacturer; and writing the binary tools required for simulation into the image, thereby ensuring that the target firmware sample can complete the boot process in the simulator with a high success rate and has the basic operating conditions to provide web services.

[0024] For the first phase of simulation, the target firmware sample is deployed and launched in a full-system simulator. It enters the firmware runtime environment via kernel instrumentation and serial port interaction, collecting network configuration and process status logs during firmware operation. Network configuration logs include `ip addr` output logs, and process status logs include `ps` output logs. These two types of logs will provide data support for subsequent device network configuration inference and process validity verification. Simultaneously, the first phase of simulation conducts three-dimensional testing on the target firmware sample's external services, specifically covering Ping connectivity testing, HTTP response testing, and browser access testing. The results of these three tests are used to comprehensively determine whether the target firmware sample possesses the basic capability to provide web services. The test process and corresponding output results serve as the basis for triggering the second phase of simulation and as a core reference for subsequent application logic repair.

[0025] When the simulation results in the first phase indicate that the network configuration is incomplete, the interface mapping is unclear, or external access is unavailable, the simulation proceeds to the second phase to perform corrective configuration for the network and application logic.

[0026] For example, repair operations targeting application logic include at least one of network configuration repair, critical process recovery, general gateway interface execution link repair, page routing repair, or dynamic host configuration protocol service bypass.

[0027] As one possible implementation, network configuration repair includes: parsing network configuration logs, extracting network interface, address, bridging and virtual LAN information, and constructing a set of network constraints; based on the set of network constraints, generating and injecting a defined virtual network device configuration on the host side to restore the network connectivity of the target firmware sample in the simulation environment.

[0028] Existing remanaged methods restore network topology based on heuristic inferences captured by the instrumented kernel's network configuration. However, due to insufficient instrumentation function coverage, information is missing. For example, existing methods can only observe the result of a VLAN being added to a bridge, but cannot determine the physical Ethernet interface (ethX) corresponding to the VLAN. This leads to TAP / VLAN injection configuration errors or omissions, manifested as unreachable Ping, no HTTP response, or inaccessibility by the browser. In this embodiment, the network logs captured in the first phase are parsed during the second-phase simulation. Interface names, MAC addresses, IP addresses / masks, bridge members, and VLAN sub-interface naming patterns (e.g., eth0.1, vlan1) are extracted along with default routing information to construct an interface-address-bridge-VLAN constraint set. Based on this, a reproducible host-side network injection configuration is automatically generated, explicitly specifying the binding relationship between the TAP device and the firmware-side bridging interface, and configuring VLAN tags and corresponding virtual port mappings. After generating the configuration, heuristic reconstruction rules are executed for possible multiple solutions. Interfaces carrying the default route are prioritized as WAN / LAN candidates, interfaces associated with the bridge are prioritized as LAN-side members, and VLAN IDs and sub-interface numbers appearing in the logs are prioritized. This configuration is written into the simulation startup script to ensure consistency with each restart. Through deterministic network reconstruction based on runtime logs, firmware-side network connectivity can be restored without relying on instrumentation coverage, enabling the target firmware sample to stably obtain interface and address states consistent with or nearly identical to the real device in the second phase.

[0029] As one possible implementation, critical process recovery includes: checking the mount status of the process file system in the simulation environment and repairing the mount if the mount status of the process file system is abnormal; locating the web server and the set of critical processes that the web server depends on based on the process status log, and triggering the reconstruction of the system initialization chain to restore service startup if any critical processes are missing.

[0030] In the first phase of simulation, incorrect mounting of ` / proc` will result in an invisible process view, abnormal interruption of the `init` startup chain will cause critical daemons to not start in sequence, and errors in the early startup phase will also cause the Web Server and its dependent services to not enter a persistent state. In the second phase of simulation, this application first checks the mount status of ` / proc`, detecting the presence of critical pseudo-files such as ` / proc / 1` and ` / proc / mounts`. If missing, a deterministic mount repair command is executed to restore the process view. Subsequently, based on the `ps` logs captured in the first phase of simulation and the Web Server configuration, the set of critical processes that should exist (Web Server main process, CGI / script interpreter, authentication / configuration related daemons, etc.) is located. If critical processes are missing, the `init` startup chain reconstruction process is triggered, restarting `init` or re-executing the firmware startup entry to restore the service startup order. After restarting, `ps` results are collected again for consistency verification. Through the closed-loop intervention of "proc repair and startup chain recovery coordinating critical process set verification," the state of "invisible processes / services not started" is transformed into "observable processes and stable persistent services," providing a reliable operating premise for subsequent CGI checks, route repair, and page collection.

[0031] As one possible implementation, the generic gateway interface (GTA) execution link repair includes: identifying the GTA program in the web server configuration and checking the dynamic link libraries it depends on; when a missing dynamic link library is detected, searching for and completing the missing dynamic link library from other compatible firmware samples from the same vendor.

[0032] When the HTTP response in the first-stage simulation returns 200 OK but the browser page is blank, a common cause is that the CGI execution chain crashes or returns an abnormal response on the server side, resulting in the dynamic page not being generated or being replaced with an empty response. One key triggering factor is the missing or version mismatch of the dynamic link library that the CGI depends on. For example, the D-Link DIR825 model firmware is missing libm-0.9.30.so. In the second-stage simulation of this application, the CGI execution chain is diagnosed deterministically: the CGI mapping (cgi-bin path, script suffix, interpreter path) in the Web service configuration is identified, the running status of the CGI program triggered by the access is checked, and the missing library list is located through dynamic dependency resolution; when a missing library is detected, the corresponding shared library with the same architecture and compatible version is retrieved in the firmware sample set of the same manufacturer, copied to the standard library path of the firmware root file system, and the dynamic linker search path is updated.

[0033] For page route repair, when a browser encounters a 404 Not Found error or page route anomaly, it's usually not because the page file is actually missing, but rather because the web root (Document Root) mapping is incorrect, the working directory settings are inconsistent, or path relocation fails in the simulation environment, preventing the web server from indexing the actual pages and resource files. This application's embodiment locates and verifies the web working directory in the second stage of simulation: it parses the web server configuration file and startup parameters to obtain the current Document Root / alias / cgi-bin path settings, and simultaneously combines the runtime logs and firmware file system to approximate candidate web directories, such as paths containing subdirectories like index.html, login.*, and img / js / css. After determining the real directory, it creates deterministic soft links or directory bindings between the incorrect directory pointed to by the configuration and the real directory, enabling the URL paths exposed by the web server to map to the actual page and resource files. After repair, it performs regression testing on typical entry pages for verification.

[0034] For Dynamic Host Configuration Protocol (DHCP) service bypass, some firmware relies on DHCP to obtain network parameters during the boot phase. If the DHCP client / service component enters a loop in the simulation environment, the network configuration will fail to load for a long time, thus blocking the Web service from listening to external networks or binding it to an invalid address, ultimately resulting in failures for Ping / HTTP / browser access. This application's embodiment detects the blocking characteristics of DHCP-related components in the second-stage simulation, such as repeatedly printing the same wait logs and continuously retrying to obtain leases, and intervenes by patching the key binary program that triggers the blocking. The DHCP wait branch is conditionally short-circuited or directly returns success, thus skipping the path of "must wait for DHCP to complete"; simultaneously, the static IP / gateway / mask configuration inferred from the first-stage simulation logs is written into the network initialization script or configuration file, enabling the system to complete network parameter loading without DHCP; after intervention, a three-dimensional test is performed to verify the recovery of the network and Web service.

[0035] S2: Parse the firmware runtime web page, extract the Hypertext Markup Language (HML) structure, Cascading Style Sheets (CSS) structure, and JavaScript structure, and construct a unified relational graph of the three languages ​​and their interrelationships as the fingerprint of the target firmware sample; the interrelationships include the style association relationship between CSS selectors and HML nodes, and the behavior binding relationship between JavaScript nodes and HML nodes.

[0036] For example, step S2 specifically includes: S21: Parse the Hypertext Markup Language content of the firmware runtime web page, generate a Document Object Model (DOM) tree, and use the DOM nodes as nodes representing the page structure in the relational graph.

[0037] S22: Parse the Cascading Style Sheets (CSS) content of the firmware runtime web page, extract the selector hierarchy, and use the selector hierarchy units as nodes representing style information in the relational graph.

[0038] S23: Parse the JavaScript content of the firmware runtime web page, generate an abstract syntax tree, and use the syntax units as nodes representing behavioral information in the relational graph.

[0039] S24: Based on the matching relationship between Cascading Style Sheet selectors and Document Object Model (DOM) nodes, establish style association edges from Cascading Style Sheet nodes to Hypertext Markup Language (HTML) nodes; based on the access or operation relationships of JavaScript scripts to DOM nodes, establish behavior binding edges from JavaScript nodes to HTML nodes.

[0040] As one possible implementation, this application embodiment parses the HTML page to construct a DOM tree, using DOM nodes as nodes of the HTML subgraph, and establishing parent-child, sibling, and other structural edges to represent page structural relationships; it parses the CSS text to construct a selector hierarchy structure, using selector hierarchy units as CSS subgraph nodes, and establishing selector hierarchy-related edges to represent style relationships; it parses the JavaScript script to extract the Abstract Syntax Tree (AST) structure, using syntax units such as functions, call expressions, event registrations, DOM access, and network requests as JavaScript subgraph nodes, and establishing AST parent-child edges, call edges, and optional data dependency edges to represent behavioral relationships. After extracting the HTML, CSS, and JavaScript language structures from the page, it further unifies the three language structures into the same relational graph through cross-language relationship construction. Specifically, regarding the relationship between CSS and HTML, selector matching mapping is used to establish an association edge from the CSS selector node to the matched DOM node, which is used to express the relationship of "styles acting on structure". Regarding the relationship between JavaScript and HTML, the binding edge between JavaScript nodes and DOM nodes is established by analyzing the script's access to the DOM, event listening, and data writing behaviors, which is used to express the relationship of "behavior driving structural changes or structure triggering behavior".

[0041] S3: Using the improved Weisfeiler-Lehman graph kernel algorithm, calculate the similarity between the relational graph fingerprint corresponding to the firmware to be identified and the relational graph fingerprint corresponding to the known firmware version in the fingerprint database, and complete the online identification of the firmware version based on the similarity.

[0042] For example, in step S3, the improved Weisfeiler-Lehman graph kernel algorithm collects the neighbor node information of the current node when iteratively refining the node label. The neighbor node information includes the type of the connecting edge, the type of the neighbor node, and the previous label of the neighbor node.

[0043] For example, in step S3, the improved Weisfeiler-Lehman graph kernel algorithm is used to calculate the similarity, which specifically includes: for two relational graphs to be compared, multiple rounds of node label iteration refinement are performed, and after each round of iteration, the frequency of occurrence of different refinement labels is counted according to the node type to form a feature vector; the inner product of the corresponding feature vectors of the two relational graphs in each round of iteration is used as the base kernel value of each round, and the contribution of different node types is weighted and summed; the base kernel values ​​of multiple rounds of iteration are accumulated to obtain the total graph kernel value, and the total graph kernel value is normalized to obtain the similarity in the interval [0,1].

[0044] Specifically, this application employs a customized WL subtree isomorphic iteration to refine node labels round by round, thereby achieving deep fusion of node attributes and neighborhood association features. For each firmware sample's corresponding page set, a heterogeneous directed graph is constructed. , where the set of nodes A collection of DOM nodes CSS selector node collection With JavaScript syntax node collection Composition, that is edge set This indicates the internal structural relationships and cross-linguistic connections within the three language categories; This is a node type mapping function used to identify the language from which the node originates; This is the initial label function for nodes, used to encode the key attributes of nodes into discrete symbols, where... The symbol space representing the initial label of a node; This is a label function for edge types, used to identify different relation categories, where... The symbol space representing edge type labels.

[0045] For relational diagrams , its first The wheel node label function is In the 0th iteration, the initial label of the node is used as the starting reference, that is... , In the first In each round of iteration, for any node It collects message multisets from its neighborhood, and simultaneously encodes edge types and neighbor node types during the collection process. This allows the WL iteration process to accurately distinguish between three types of cross-language related edges: structural edges, style-matching edges, and behavior-binding edges. A message multiset is defined as: in, This represents a multiset construction operator used to retain the occurrence count of repeated elements; This indicates the existence of a line from Pointing to neighbor nodes The directed edges; Representing an edge Edge type label; Representing neighboring nodes Node type, ,in Represents the DOM node of HTML. Represents a CSS node. Represents a JavaScript node; Representing neighboring nodes In the previous round (the... Discrete labels for (wheels).

[0046] The message multiset is then normalized and sorted, concatenated with its own old label (i.e., the label from the previous round), and finally, a new label is generated through hash compression, resulting in: in, For nodes In the The wheel's update tag; For nodes In the previous round of labeling; This indicates that a deterministic ordering is performed on a multiset to obtain a unique sequence representation; This indicates a concatenation operation, used to combine the user's old label with a sequence of neighboring messages into a single sequence. This represents a compression mapping function that maps the concatenated sequence to discrete new labels (same input maps to the same output). This is achieved by introducing an edge type parameter. With neighbor node type parameters This enables the label refinement process to simultaneously perceive cross-language relationship categories and the source of neighboring languages, thereby better adapting to the heterogeneous relationship graph constructed in the embodiments of this application.

[0047] After completing the first To the After setting the label set for the wheels, this embodiment constructs a WL graph kernel to measure the similarity between two relational graphs. Given two relational graphs... and In the After each iteration, the frequency of each label is counted according to node type, and histogram features are generated. (For node type...) Histogram features are defined as follows: in, Representation diagram In the under round iteration, type is The label in the node is equal to The number of nodes; Representation diagram The set of nodes; Represents the cardinality of a set; For the first Rotate to a discrete label; Represents a node The type is ; Represents a node In the The wheel's label is .

[0048] Then, based on the histogram features, the base kernel value for round t is calculated, and a weight coefficient related to the node type is introduced during the calculation process. The base kernel function is used to adjust the contribution ratio of HTML structure, CSS styles, and JavaScript behavior in the similarity metric. in, For the first The base core value of the wheel; For node type The weighting coefficients are used to adjust the contribution ratio of HTML structure, CSS styles, and JavaScript behavior to the kernel value; Indicates the first Wheel of all possible labels Summation. Therefore, the basis kernel function essentially statistically analyzes the two graphs on the 1st... The matching degree of nodes with the same label in the round is calculated, and different types of nodes are weighted and merged.

[0049] Furthermore, the first To the Wheel-based kernel accumulation yields WL graph kernel values: in, For iteration depth is The total value of the WL diagram kernel; The upper limit of the number of iterations in WL (a hyperparameter) represents the depth of the neighborhood expansion considered. Indicates from round 0 to round 1 Accumulate round by round.

[0050] Based on the above definition, It is equivalent to statistically analyzing the matching degree of isomorphic subtree patterns contained in two relation graphs at different iteration depths, which can comprehensively characterize the local substructure similarity of structure, style and behavior.

[0051] This application embodiment converts the overall map core value into an interval. To assess the similarity within the graph and reduce the impact of graph size differences, the WL graph kernel is normalized to obtain the final similarity score. in, Representation diagram With Figure The cosine similarity, with values ​​ranging from [0, 1]; The WL kernel value between the two graphs; and These are the kernel values ​​of the two graphs, used to eliminate differences in graph size and number of labels; the square root term in the denominator corresponds to kernel cosine normalization, making the similarity comparable and scale consistent.

[0052] when At that time, it is determined that the firmware page fingerprints corresponding to the two images match, and then... The firmware version is as follows The recognition result output; where the threshold Based on labeled samples and validated on the validation set, a balance is struck between recognition accuracy and false positive rate. Through this method, embodiments of this application achieve customized WL graph kernel similarity calculation for unified relational graphs in HTML / CSS / JavaScript. This enables firmware recognition to no longer rely on single DOM features or uninterpretable end-to-end black-box models, but rather achieves interpretable and scalable online firmware version recognition based on the fusion of structural, style, and behavioral three-dimensional information.

[0053] For example, after step S3, a vulnerability association step is also included: matching the identified firmware version with the vulnerability knowledge base and outputting the known vulnerability information associated with the firmware version.

[0054] In the description of this specification, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

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

Claims

1. A method for online firmware identification of IoT devices based on interactive simulation data acquisition, characterized in that, include: S1: Perform a two-stage simulation on the target firmware sample, and fix the application logic problems identified in the first stage simulation during the second stage simulation to obtain a usable firmware runtime web page; S2: Parse the firmware runtime web page, extract the Hypertext Markup Language (HTML) structure, Cascading Style Sheets (CSS) structure, and JavaScript structure, and construct a unified relational graph of the structures of the three languages ​​and their interrelationships as the fingerprint of the target firmware sample; wherein, the interrelationships include the style association relationship between CSS selectors and HTML nodes, and the behavior binding relationship between JavaScript nodes and HTML nodes; S3: Using the improved Weisfeiler-Lehman graph kernel algorithm, calculate the similarity between the relational graph fingerprint corresponding to the firmware to be identified and the relational graph fingerprint corresponding to the known firmware version in the fingerprint database, and complete the online identification of the firmware version based on the similarity.

2. The method for online firmware identification of IoT devices based on interactive simulation data acquisition according to claim 1, characterized in that, The two-stage simulation in step S1 includes: the first stage basic simulation: starting the preprocessed target firmware sample in the simulator and performing network connectivity tests and Web service response tests, while recording network configuration logs and process status logs during the simulation; the second stage interactive repair simulation: judging whether the Web application logic of the target firmware sample is abnormal based on the network configuration logs and process status logs; if the Web application logic of the target firmware sample is abnormal, automatically executing at least one repair operation for the application logic until a complete firmware runtime Web page can be collected.

3. The method for online firmware identification of IoT devices based on interactive simulation data acquisition according to claim 2, characterized in that, Repair operations targeting application logic include at least one of the following: network configuration repair, critical process recovery, general gateway interface execution link repair, page routing repair, or dynamic host configuration protocol service bypass.

4. The method for online firmware identification of IoT devices based on interactive simulation data acquisition according to claim 3, characterized in that, The network configuration repair includes: parsing the network configuration log, extracting network interface, address, bridging and virtual LAN information, and constructing a set of network constraints; based on the set of network constraints, generating and injecting a determined virtual network device configuration on the host side to restore the network connectivity of the target firmware sample in the simulation environment.

5. The method for online firmware identification of IoT devices based on interactive simulation acquisition according to claim 3, characterized in that, The critical process recovery includes: checking the mount status of the process file system in the simulation environment, and repairing the mount if the mount status of the process file system is abnormal; locating the Web server and the set of critical processes that the Web server depends on based on the process status log, and triggering the reconstruction of the system initialization chain to restore service startup if any critical processes are missing.

6. The method for online firmware identification of IoT devices based on interactive simulation acquisition according to claim 3, characterized in that, The general gateway interface execution link repair includes: identifying the general gateway interface program in the web server configuration and checking the dynamic link libraries it depends on; when a missing dynamic link library is detected, searching for and supplementing the missing dynamic link library from other compatible firmware samples from the same manufacturer.

7. The method for online firmware identification of IoT devices based on interactive simulation data acquisition according to claim 1, characterized in that, Step S2 specifically includes: S21: Parsing the Hypertext Markup Language (HML) content of the firmware runtime Web page, generating a Document Object Model (DOM) tree, and using DOM nodes as nodes representing the page structure in the relational graph; S22: Parsing the Cascading Style Sheets (CSS) content of the firmware runtime Web page, extracting selector levels, and using selector level units as nodes representing style information in the relational graph; S23: Parsing the JavaScript content of the firmware runtime Web page, generating an Abstract Syntax Tree (AST), and using syntax units as nodes representing behavior information in the relational graph; S24: Establishing style association edges from CSS nodes to HML nodes based on the matching relationship between CSS selectors and DOM nodes; establishing behavior binding edges from JavaScript nodes to HML nodes based on the JavaScript's access or operation relationships to DOM nodes.

8. The method for online firmware identification of IoT devices based on interactive simulation acquisition according to claim 1, characterized in that, The improved Weisfeiler-Lehman graph kernel algorithm in step S3 collects the neighbor node information of the current node during the iterative refinement of node labels. The neighbor node information includes the type of connecting edge, the type of neighbor node, and the previous label of the neighbor node.

9. The method for online firmware identification of IoT devices based on interactive simulation acquisition according to claim 8, characterized in that, In step S3, the improved Weisfeiler-Lehman graph kernel algorithm is used to calculate the similarity, specifically including: for two relational graphs to be compared, multiple rounds of node label iteration refinement are performed, and after each round of iteration, the frequency of occurrence of different refinement labels is counted according to the node type to form a feature vector; the inner product of the corresponding feature vectors of the two relational graphs in each round of iteration is used as the base kernel value of each round, and the contribution of different node types is weighted and summed; the base kernel values ​​of multiple rounds of iteration are accumulated to obtain the total graph kernel value, and the total graph kernel value is normalized to obtain the similarity in the interval [0,1].

10. A method for online firmware identification of IoT devices based on interactive simulation data acquisition according to any one of claims 1-9, characterized in that, Before step S1, there is a data collection step for firmware samples and vulnerability information; after step S3, there is a vulnerability association step: matching the identified firmware version with the vulnerability knowledge base and outputting the known vulnerability information associated with the firmware version.

Images