Internet vulnerability evaluation and analysis system

Abstract

The invention relates to the technical field of internet analysis, in particular to an internet vulnerability evaluation and analysis system, which comprises the following steps of: acquiring original vulnerability data, binding an evaluation terminal equipment fingerprint, an operator biological characteristic hash, a network environment snapshot and generating a vulnerability responsibility label; stripping an environment dependency item in the vulnerability responsibility label, replacing the environment dependency item with a cross-platform equivalent function, and generating a repair instruction chain; executing the restoration instruction chain in a target environment, and capturing restoration behavior offset; and associating the system repair behavior offset with the vulnerability responsibility label, reversely positioning a responsibility node and generating a traceability tree. The method not only breaks through the information splitting problem that the repair behavior of the traditional system cannot reversely deduce the responsibility attribution, but also supports the positioning of the responsibility node through the traceability tree, and provides a matched evidence data packet.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet analysis, and in particular to an Internet vulnerability assessment and analysis system. Background Art

[0002] With the increasing complexity of Internet system structures and the continuous evolution of attack methods, software vulnerability assessment and repair have become an important part of network security governance. Currently, the mainstream vulnerability handling process usually includes vulnerability detection, vulnerability notification, manual repair and retesting.

[0003] Most existing vulnerability analysis systems focus on the triggering conditions and remediation recommendations for the vulnerability itself, but lack mechanisms to effectively link vulnerability events to the device environment and operator behavior. This is especially true in scenarios involving multi-user shared systems, remote access, or cross-node deployments, making responsibility difficult to trace, often leading to unclear responsibilities and a lack of accountability. Traditional vulnerability remediation processes often build patches based on specific operating systems and hardware architectures, relying on, for example, Windows APIs, Linux kernel calls, or specific register structures. This tightly coupled structure makes patch deployment and verification difficult on heterogeneous platforms, hindering the application of remediation solutions in diverse systems such as the Internet of Things, embedded systems, and edge nodes.

[0004] Currently, repair effectiveness is typically assessed through manual judgment or static regression testing, which struggles to capture dynamic behavioral changes at the system level and quantify differences in execution results before and after the repair. This leads to frequent misjudgments and missed detections. Furthermore, it's difficult to trace failed repairs or abnormal behavior back to the responsible party or specific operating environment. Summary of the Invention

[0005] The present invention provides an Internet vulnerability assessment and analysis system that can credibly bind vulnerability behavior with operators, devices, and network environments, and support platform-independent automated repair chain construction and execution verification, ultimately realizing an Internet vulnerability assessment and analysis system that can quantitatively analyze deviation behavior and construct a responsibility tracing tree, thereby improving the degree of automation, security credibility, and cross-platform adaptability of vulnerability processing.

[0006] An Internet vulnerability assessment and analysis system includes executing the following: S1, Generate vulnerability responsibility labels: Obtain the original vulnerability data, bind the assessment terminal device fingerprint, operator biometric hash, and network environment snapshot, and generate vulnerability responsibility labels; S2, building a decoupled repair chain: based on the vulnerability responsibility label, stripping the environment dependencies in the vulnerability responsibility label, replacing them with cross-platform equivalent functions, and generating a repair instruction chain; S3, performing repair chain verification: injecting the repair instruction chain into the target environment, executing the repair instruction chain in the target environment, and capturing the repair behavior offset; S4, generate a responsibility traceability tree: associate the system repair behavior offset with the vulnerability responsibility label, reversely locate the responsibility node and generate a traceability tree.

[0007] Optionally, the S1 receives a standard output data packet of a vulnerability scanning tool through a secure API interface, and the original vulnerability data includes key fields: vulnerability signature code, affected memory address, and attack vector description, which are expressed as triple data.

[0008] Optionally, after receiving the original vulnerability data, S1 binds the assessment terminal device fingerprint, operator biometric hash, and network environment snapshot, specifically including: Bind the evaluation terminal device fingerprint: collect the CPU microcode hash value and motherboard firmware signature of the evaluation terminal to generate a device fingerprint string; Binding operator biometric hash: real-time collection of operator voiceprint waveform, and generating double SHA-256 hash value after Fourier transform; Bind network environment snapshot: Captures the current network state of the TCP / IP stack configuration, routing table, and firewall rule hash.

[0009] Optionally, S1 further includes encoding the binding data into a digital tag in TLV format, where the tag header includes a version number and an encryption identifier, to generate a vulnerability responsibility tag.

[0010] Optionally, the S2 specifically includes: S21, parsing environmental dependencies: extracting operating system kernel function call symbols and hardware register access paths from vulnerability responsibility labels; S22, stripping environment-sensitive operations: identifying the platform-corresponding system call symbol in the kernel function call instruction, and deleting the physical address mapping in the register access path; S23, replaced with a cross-platform equivalent function: query the preset function mapping table and convert the call symbols in S21 and S22 into WASM universal function pointers; S24, generate a repair instruction chain: reorganize the converted function pointers and vulnerability repair logic, and compile them into a repair instruction chain in WASM bytecode format.

[0011] Optionally, S23 specifically includes executing the following for each call symbol: Lookup table: look up the function mapping table to determine the replacement function name and signature; Semantic replacement: replace the call symbol instruction with the corresponding WebAssembly function symbol; Build a replacement sequence: All replaced function symbols are concatenated into a function pointer operation sequence in the original order.

[0012] Optionally, the function pointer operation sequence is expressed as: ;in, Represents a WASM function pointer, Indicates memory or register equivalent processing function; Sequence of function pointers Reorganize and compile into WASM bytecode format, and generate the repair instruction chain represented as: ; For .wasm files, including a neutral representation of all fixed function calls, Represents a WebAssembly bytecode file in .wasm format, Represents the process of compiling a sequence of function symbols into an executable WebAssembly bytecode module, using the LLVM toolchain or a compatible compiler.

[0013] Optionally, the S3 specifically includes: S31, instruction chain security injection: load the WASM bytecode of the repaired instruction chain in the isolated sandbox of the target environment and initialize the virtual memory mapping table; S32, differential parallel execution: synchronously executes the original vulnerability code and the repair instruction chain, and monitors the CPU register status and system call sequence in real time; S33, calculates the Euclidean distance of key parameters before and after repair to capture the offset of repair behavior; S34, recording the offset of each repair behavior executed and the corresponding environmental parameters, and generating an offset data set.

[0014] Optionally, the key parameters include a memory peak change rate and a system call sequence timing difference.

[0015] Optionally, the S4 specifically includes: S41, offset-label association: Bind the repair behavior offset with the operator's biometric hash and terminal device fingerprint in the vulnerability responsibility label in a triplet representation; S42, Responsible Node Reverse Location: When the offset is greater than or equal to the first threshold, locating the operator node corresponding to the biometric hash; When the second threshold ≤ the offset < the first threshold, locate the environment dependency node associated with the device fingerprint; When the offset is less than the second threshold, it is marked as a node that has passed the repair verification; S43, build a traceability tree: the root node is the vulnerability responsibility label ID, the secondary nodes are classified by responsibility type, which includes operator, environment, and repair, and the leaf nodes are mounted with offset values and evidence data packets.

[0016] Beneficial effects of the present invention: The present invention realizes a closed loop of responsibility association between vulnerability events and their repair effects by generating a "vulnerability responsibility label" that includes the operator's biometric hash, device fingerprint and network environment snapshot, and introducing a behavior offset calculation and triple association binding mechanism in the subsequent repair chain verification process. It not only breaks through the information fragmentation problem of "repair behavior cannot be reversed to responsibility attribution" in traditional systems, but also supports locating responsibility nodes through the traceability tree and providing supporting evidence data packets (such as register differential logs and system call traces), realizing audit-level accountability traceability, which is particularly suitable for complex network environments where multiple people share accounts or the operation path is ambiguous.

[0017] The present invention constructs a "decoupled repair chain" that strips the original system call from the physical address access path, converts it into a WASM universal function pointer with the help of a predefined function mapping table, and finally compiles it into a portable WebAssembly bytecode module, thereby completely shielding platform differences and hardware dependencies. This mechanism supports secure injection execution in multiple sandbox environments, and is adaptable to heterogeneous architectures such as x86, ARM, and RISC-V, improving the platform versatility and remote deployability of the vulnerability repair solution.

[0018] This method quantifies the effectiveness of vulnerability repairs using "behavior offsets," comprehensively considering peak memory usage changes and differences in system call sequences, and normalizes this using Euclidean distance. Combining responsibility threshold rules with a tree-like topology, the system automatically categorizes nodes as "operator responsibility nodes," "environmental responsibility nodes," or "repair-passed nodes," visually representing these nodes through red / yellow / green color coding. This approach significantly improves the automation of repair verification while reducing manual judgment costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only for the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 A schematic diagram of repair instruction chain generation according to an embodiment of the present invention; Figure 2 Schematic diagram of the system execution method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0021] The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. Those skilled in the art may also implement some known technologies in other alternative ways. The accompanying drawings are only for describing the embodiments in more detail and are not intended to limit the present invention in any specific way.

[0022] like Figure 1-Figure 2 As shown, an Internet vulnerability assessment and analysis system includes executing the following: S1, Generate vulnerability responsibility labels: Obtain the original vulnerability data, bind the assessment terminal device fingerprint, operator biometric hash, and network environment snapshot, and generate vulnerability responsibility labels; S2, building a decoupled repair chain: Based on the vulnerability responsibility label, the environment dependencies in the vulnerability responsibility label are stripped away and replaced with cross-platform equivalent functions to generate a repair instruction chain; S3, perform repair chain verification: inject the repair instruction chain into the target environment, execute the repair instruction chain in the target environment, and capture the repair behavior offset; S4, generate a responsibility traceability tree: associate the system repair behavior offset with the vulnerability responsibility label, reverse locate the responsibility node and generate a traceability tree.

[0023] S1 specifically includes: S11 receives raw vulnerability data: It receives the standard output data packet of the vulnerability scanning tool through the security API interface and extracts the key fields as follows: Vulnerability signature: ; Affected memory addresses: ; Attack vector description: ; It can be represented as a triple: .

[0024] Receive the standard output data packet of the vulnerability scanning tool through the security API interface and extract the key fields as follows: Access scan reports from leading vulnerability scanning tools (OpenVAS, Nessus, and Qualys) through a secure, authenticated API, supporting multiple output formats including JSON and XML. Scan reports are uploaded to the assessment unit's designated endpoint in an encrypted format. Token-based access control ensures the integrity and authenticity of data transmission.

[0025] After receiving the report data, the evaluation unit first decodes and parses it. The parsing process automatically adapts the field path based on the scanning tool type and extracts the following three key indicators: Vulnerability signature: Extracts the unique identification field for each vulnerability record from the report, such as the CVE number (e.g., "CVE-2022-1234") or a tool-defined vulnerability ID. This field is used to identify and match vulnerability remediation function templates in subsequent steps.

[0026] Affected memory address: Extracts the address information or offset position of the vulnerability impacted location, such as memory address, function entry point, etc., to guide the instruction injection location and patch matching operations of the subsequent repair chain.

[0027] Attack vector description: Extracts descriptive information related to vulnerability exploitation methods, including attack paths, trigger conditions, protocol types, etc., and combines them with the vulnerability's risk description field to form a structured attack vector semantic representation, facilitating the subsequent generation of equivalent replacement functions and the construction of verification test scenarios.

[0028] The three analyzed indicators are uniformly encapsulated as the core information of the vulnerability event.

[0029] S12, bind and evaluate the terminal device fingerprint: call low-level hardware instructions to combine the unique identifiers of the CPU and motherboard, and perform hash processing: ;in, Indicates the CPU microcode version information, It is the unique identifier of the motherboard (SMBIOS format). For string concatenation operation, Represents a 256-bit SHA-3 hash function.

[0030] S13, Binding the Operator’s Biometric Hash: Collecting voiceprint data and performing Fourier transform and double hashing: ;in, Represents the original voiceprint waveform within 2000ms, represents the fast Fourier transform (FFT), and SHA256() represents the 256-bit SHA-2 hash function.

[0031] S14, bind network environment snapshot: extract the current network stack status, merge the hash to generate a network snapshot: BLAKE3 ;in, Indicates the TCP / IP stack configuration exported by the netstat command. Indicates the content of the routing table; Indicates firewall rules, Indicates concatenating multiple configuration files and pre-hashing them, BLAKE3 Represents a fast hash algorithm.

[0032] S15, Generate vulnerability responsibility label: Combine all the above binding data into a digital label using TLV (Type-Length-Value) encoding format: ; in, Indicates the field type identifier (such as Bxe1 represents the vulnerability responsibility label), Indicates the length of the corresponding field content, The value of the field is the hash result or original description above. Indicates the number of bound items. The combined label can be expressed as: Type ,Len Type ,Len ,Fingerprint Type ,Len ,Fingerprint Type ,Len ,Snapshot .

[0033] S2 specifically includes: S21, parse environment dependencies: Extract the environment-sensitive operation data field from the vulnerability responsibility label, and extract the behavioral features in the vulnerability responsibility label that are strongly bound to the platform environment, including system call information and hardware access paths at the operating system level. The environment dependency field is located in the TLV encoding structure of the vulnerability responsibility label. Specifically: Type=0x02: indicates that this field is an "environment dependency"; The Value field is a compressed representation of the environment-dependent instruction sequence, using the platform-independent intermediate instruction representation (IR) or binary disassembly result, expressed as: ; in, Indicates the System call instruction symbol, such as intex80 under Linux, svc#0 of ARM architecture, Indicates the The register access path, such as movedx, Bxffffe000, indicates access to the physical memory mapping area. This set is obtained by parsing the Type=0x02 field in the TLV tag, that is, the environment dependency field.

[0034] The specific parsing process is as follows: S211, decoding and line breaking: split the Value field whose Type is 0x02 according to line breaks or semicolons, and process the instruction statements one by one.

[0035] S212, system call instruction identification rules: Identify platform-specific system calls based on pattern matching. The specific rules are as follows: Table 1 System call instruction recognition rules

[0036] System calls can be located by instruction prefix or call stack function name, and the call number or parameters are decoded into semantic identifiers.

[0037] S213, register access path identification rules: Identify the following behaviors: Access special memory areas (e.g. 0xFFFF0000, 0x3F200000); Register operation instructions such as mov, ldr, str, lea, etc. are combined with address immediate values; Identification rules: If the immediate address falls within the known MMIO_access and BIOS_read configuration space range, it is determined to be a context-sensitive path.

[0038] S22, stripping environmentally sensitive operations: The operations in are stripped, including: Delete platform-specific system call entry instructions; Replaces physical address mappings with virtual generic placeholders.

[0039] Represented as a stripped collection: ;in, Indicates that only semantic call symbols are retained after stripping, such as sys_read, sys_write, and sys_mmap. Indicates that the physical address in the register path has been replaced with a placeholder such as VIRT_ADDR.

[0040] S23 is replaced with a cross-platform equivalent function: two standardized sets of instruction semantics are obtained based on S21 and S22: System semantic call symbol set: sys_read,sys_write,sys_mmap , these represent the operational semantics of platform-specific calls after they have been standardized; Environment access call symbol set: MMIO_access,BIOS_read ; Using function mapping tables Map the above semantic instructions to the universal function form in WebAssembly: ; ; in, Represents a WebAssembly (WASM) function pointer, Indicates memory or register equivalent processing function; Table 2 Function mapping table

[0041] Note: WASM function names are all logical identifiers and are declared in subsequent WAT source code.

[0042] {Replacement logic flow details}: For each call symbol , perform the following steps: Step 1: Lookup table ,Determine the replacement function name and signature; Step 2: Semantic replacement: replace the semantic instructions Replaced with the corresponding WebAssembly function symbol or ; Step 3: Construct a replacement sequence: All replaced function symbols are concatenated into a function pointer operation sequence in the original order: ; This is the final cross-platform repair instruction sequence.

[0043] S24, generate repair instruction chain: convert function pointer sequence Reassemble and compile to WebAssembly bytecode format to generate a repair chain: ; Generated Is a .wasm file that contains a neutral representation of all fixed function calls, which is platform-independent.

[0044] S3 specifically includes: S31, instruction chain security injection: Load the WebAssembly bytecode format output by S2 in an isolated sandbox virtual environment to fix the instruction chain: ; And initialize its memory mapping table: ; in, The bytecode repair instruction chain output by S2, Represents a secure isolated execution environment, Represents the virtual memory mapping table, which is a description of the allocation of virtual address space by the WebAssembly sandbox runtime. For the The starting position of a virtual address represents the access entry. Indicates the memory page object mapped to, including the content, permissions and other information of the actual memory page. Indicates the total number of allocated memory pages, that is, the number of mapping entries.

[0045] S32, differential parallel execution: S321, build two synchronous execution threads: : Execute the original vulnerability triggering path; :Execute the repair bytecode instruction chain; S322, the system periodically reads the key status of the two threads, including: CPU register group: such as RAX, RBX, RIP; System call sequence: recorded in chronological order.

[0046] S323, defining the moment The differential register status is: ; S324, define the difference in system call sequences as Hamming distance: ; in, is the register state vector of the two threads, is an ordered sequence of system calls, represents the Hamming distance function.

[0047] S33, Capture behavior offset: Define the system repair behavior offset as the following Euclidean distance: ; in: Memory peak change rate : ; System call sequence timing difference (Discrete features): ; Indicates the peak memory usage during execution.

[0048] S34, generate offset data set: The result of each differential verification will form a structured record unit: ; in, Indicates the The offset of the execution, is the timestamp, Indicates the current CPU load. Network latency (if applicable for remote environment verification); all records will be aggregated to form the behavior offset dataset : .

[0049] S4 specifically includes: S41, offset-label triple binding: Bind the repair behavior offset with the operator biometric hash and terminal device fingerprint in the vulnerability responsibility label, and define it as: ;in, Indicates the The responsibility binding triple for the repair verification, Represents the operator biometric hash, Indicates the evaluation of terminal device fingerprint, To fix the behavior offset (Euclidean distance value), the triplet will be used for subsequent responsible node decision-making.

[0050] S42, Responsible node reverse positioning: according to the value of each repair offset ,Use threshold rules to determine the responsibility type: ; in, Indicates mapping to operator responsibility node, Represents a node that is mapped to a device or environment responsibility. Indicates that the node has passed the repair verification. 0.3 is the first threshold and 0.1 is the second threshold.

[0051] S43, dynamically build the traceability tree structure: take the responsibility tag ID VID as the root node and build the tree structure: ; Root node (Root): corresponds to the vulnerability responsibility label ID; First-level branch (Branch): Responsibility classification node (operator / environment / pass); Secondary leaf node (Leaf): Mounts the feature and offset data in the triplet; each leaf node has the following data tuple attached: ; Represents the original technical evidence extracted during repair verification, such as register differential logs, system call traces, and other original evidence data.

[0052] S44, Node color mapping rules: To achieve visual expression of the traceability tree, use color coding to mark the responsibility level: ; This color map can be used for front-end interface rendering and visual output of graph database annotations.

[0053] The present invention encompasses any alternatives, modifications, equivalents, and solutions that fall within the spirit and scope of the present invention. To provide a thorough understanding of the present invention, specific details are described in detail below in connection with the preferred embodiments of the present invention, but those skilled in the art will be able to fully understand the present invention without these detailed descriptions. Furthermore, to avoid unnecessary confusion regarding the essence of the present invention, well-known methods, processes, procedures, components, and circuits have not been described in detail.

[0054] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. An Internet vulnerability assessment and analysis system, characterized in that: This includes executing the following: S1, Generate vulnerability responsibility labels: Obtain the original vulnerability data, bind the assessment terminal device fingerprint, operator biometric hash, and network environment snapshot, and generate vulnerability responsibility labels; S2, building a decoupled repair chain: based on the vulnerability responsibility label, stripping the environment dependencies in the vulnerability responsibility label, replacing them with cross-platform equivalent functions, and generating a repair instruction chain; S3, performing repair chain verification: injecting the repair instruction chain into the target environment, executing the repair instruction chain in the target environment, and capturing the repair behavior offset; S4, generate a responsibility traceability tree: associate the system repair behavior offset with the vulnerability responsibility label, reversely locate the responsibility node and generate a traceability tree.

2. The Internet vulnerability assessment and analysis system according to claim 1, characterized in that: In the S1, a standard output data packet of a vulnerability scanning tool is received through a secure API interface. The original vulnerability data includes key fields: vulnerability signature, affected memory address, and attack vector description, which are expressed as triple data.

3. The Internet vulnerability assessment and analysis system according to claim 1, characterized in that: After receiving the original vulnerability data, S1 binds the assessment terminal device fingerprint, operator biometric hash, and network environment snapshot, specifically including: Bind the evaluation terminal device fingerprint: collect the CPU microcode hash value and motherboard firmware signature of the evaluation terminal to generate a device fingerprint string; Binding operator biometric hash: real-time collection of operator voiceprint waveform, and generating double SHA-256 hash value after Fourier transform; Bind network environment snapshot: Captures the current network state of the TCP / IP stack configuration, routing table, and firewall rule hash.

4. The Internet vulnerability assessment and analysis system according to claim 3, characterized in that: Said S1 also includes encoding the binding data into a digital tag in TLV format, wherein the tag header includes a version number and an encryption identifier, and generating a vulnerability responsibility tag.

5. The Internet vulnerability assessment and analysis system according to claim 1, characterized in that: The S2 specifically includes: S21, parsing environmental dependencies: extracting operating system kernel function call symbols and hardware register access paths from vulnerability responsibility labels; S22, stripping environment-sensitive operations: identifying the platform-corresponding system call symbol in the kernel function call instruction, and deleting the physical address mapping in the register access path; S23, replaced with a cross-platform equivalent function: query the preset function mapping table and convert the call symbols in S21 and S22 into WASM universal function pointers; S24, generate a repair instruction chain: reorganize the converted function pointers and vulnerability repair logic, and compile them into a repair instruction chain in WASM bytecode format.

6. The Internet vulnerability assessment and analysis system according to claim 5, characterized in that: The S23 specifically includes executing the following for each call symbol: Lookup table: look up the function mapping table to determine the replacement function name and signature; Semantic replacement: replace the call symbol instruction with the corresponding WebAssembly function symbol; Build a replacement sequence: All replaced function symbols are concatenated into a function pointer operation sequence in the original order.

7. The Internet vulnerability assessment and analysis system according to claim 5, characterized in that: The function pointer operation sequence is expressed as: ;in, Represents a WASM function pointer, Indicates memory or register equivalent processing function; Sequence of function pointers Reorganize and compile into WASM bytecode format, and generate the repair instruction chain represented as: ; For .wasm files, including a neutral representation of all fixed function calls, Represents a WebAssembly bytecode file in .wasm format, Represents the process of compiling a sequence of function symbols into an executable WebAssembly bytecode module, using the LLVM toolchain or a compatible compiler.

8. The Internet vulnerability assessment and analysis system according to claim 1, characterized in that: The S3 specifically includes: S31, instruction chain security injection: load the WASM bytecode of the repaired instruction chain in the isolated sandbox of the target environment and initialize the virtual memory mapping table; S32, differential parallel execution: synchronously executes the original vulnerability code and the repair instruction chain, and monitors the CPU register status and system call sequence in real time; S33, calculates the Euclidean distance of key parameters before and after repair to capture the offset of repair behavior; S34, recording the offset of each repair behavior executed and the corresponding environmental parameters, and generating an offset data set.

9. The Internet vulnerability assessment and analysis system according to claim 8, characterized in that: The key parameters include the memory peak change rate and the system call sequence timing difference.

10. The Internet vulnerability assessment and analysis system according to claim 1, characterized in that: The S4 specifically includes: S41, offset-label association: Bind the repair behavior offset with the operator's biometric hash and terminal device fingerprint in the vulnerability responsibility label in a triplet representation; S42, Responsible Node Reverse Location: When the offset is greater than or equal to the first threshold, locating the operator node corresponding to the biometric hash; When the second threshold ≤ the offset < the first threshold, locate the environment dependency node associated with the device fingerprint; When the offset is less than the second threshold, it is marked as a node that has passed the repair verification; S43, build a traceability tree: the root node is the vulnerability responsibility label ID, the secondary nodes are classified by responsibility type, which includes operator, environment, and repair, and the leaf nodes are mounted with offset values and evidence data packets.

Images