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

[0001] The present application is a divisional application of the application with application number 202510926581.X and entitled "Internet vulnerability assessment and analysis system", filed on July 7, 2025. TECHNICAL FIELD

[0002] The present application relates to the technical field of internet analysis, and in particular to an internet vulnerability assessment and analysis system. BACKGROUND

[0003] With the increasing complexity of the structure of the Internet system and the continuous evolution of attack means, 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 retest, etc.

[0004] Most of the existing vulnerability analysis systems focus on the triggering conditions and repair suggestions of the vulnerability itself, but lack an effective mechanism to bind the vulnerability event with the device environment and operator behavior. Especially in multi-user shared systems, remote access or cross-node deployment scenarios, it is difficult to trace the responsibility, often leading to blurred responsibility and lack of accountability. Traditional vulnerability repair processes often build patches based on specific operating systems and hardware architectures, such as relying on Windows API, Linux kernel calls or specific register structures. This tight coupling structure makes it difficult to deploy and verify patches on heterogeneous platforms, hindering the application of repair solutions in diverse systems such as the Internet of Things, embedded systems, and edge nodes.

[0005] Current repair effects are usually completed by manual judgment or static regression testing, which is difficult to capture dynamic behavior changes at the system level and cannot quantify the differences in pre- and post-repair execution results, leading to misjudgment and missed judgment. At the same time, it is also difficult to trace the responsibility subject or specific operating environment for failed repairs or abnormal behavior. SUMMARY

[0006] The present application 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 a quantitative shift behavior analysis and responsibility traceability tree construction internet vulnerability assessment and analysis system to improve the automation level, security and reliability, and cross-platform adaptability of vulnerability handling.

[0007] An internet vulnerability assessment and analysis system, comprising the following: S1, generating a vulnerability responsibility label: obtaining original vulnerability data, binding an evaluation terminal device fingerprint, an operator biometric feature hash, and a network environment snapshot to generate a vulnerability responsibility label; S2, constructing a decoupled repair chain: based on the vulnerability responsibility label, stripping the environmental dependencies in the vulnerability responsibility label and replacing them with cross-platform equivalent functions to generate 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, generating a responsibility trace tree: correlating the system repair behavior offset with the vulnerability responsibility label, reverse positioning the responsibility node and generating a trace tree.

[0008] Optionally, in S1, the standard output data packet of the vulnerability scanning tool is received through the security API interface, and the original vulnerability data includes key fields: vulnerability feature code, affected memory address and attack vector description, represented as a three-tuple data.

[0009] Optionally, after receiving the original vulnerability data in S1, the evaluation terminal device fingerprint, operator biometric hash and network environment snapshot are bound, specifically including: Binding the evaluation terminal device fingerprint: collecting the CPU microcode hash value and motherboard firmware signature of the evaluation terminal to generate a device fingerprint string; Binding the operator biometric hash: real-time collection of the operator's voice waveform, and generating a double SHA-256 hash value after Fourier transform; Binding the network environment snapshot: capturing the TCP / IP stack configuration, routing table and firewall rule hash of the current network state.

[0010] Optionally, S1 also includes encoding the bound data into a digital label in TLV format, and the label header includes a version number and an encryption identifier to generate a vulnerability responsibility label.

[0011] Optionally, S2 specifically includes: S21, analyzing environmental dependencies: extracting operating system kernel function call symbols and hardware register access paths from the vulnerability responsibility label; S22, stripping environmental sensitive operations: identifying platform corresponding system call symbols in the kernel function call instructions, and deleting physical address mappings in the register access path; S23, replacing with cross-platform equivalent functions: querying a preconfigured function mapping table to convert the call symbols in S21 and S22 into WASM universal function pointers; S24, generating a repair instruction chain: recombining the converted function pointers and vulnerability repair logic, and compiling into a WASM bytecode format repair instruction chain.

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

[0013] Optionally, the function pointer operation sequence is represented as: ; Wherein, represents the WASM function pointer, represents the memory or register equivalent processing function; The function pointer sequence is reorganized and compiled into WASM bytecode format to generate a repair instruction chain represented as: ; .wasm file, including the neutral representation of all repair function calls, represents the WebAssembly bytecode file in.wasm format, represents the process of compiling the function symbol sequence into an executable WebAssembly bytecode module, which is completed using the LLVM tool chain or compatible compiler.

[0014] Optionally, the S3 specifically includes: S31, instruction chain security injection: load the WASM bytecode of the repair instruction chain in the isolated sandbox of the target environment, and initialize the virtual memory mapping table; S32, differential parallel execution: synchronously execute the original vulnerability code and the repair instruction chain, and monitor the CPU register state and system call sequence in real time; S33, calculate the Euclidean distance of the key parameters before and after repair, and capture the repair behavior offset; S34, record the repair behavior offset and the corresponding environmental parameters of each execution, and generate an offset dataset.

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

[0016] Optionally, the S4 specifically includes: S41, offset-label association: bind the repair behavior offset to the operator biometric hash in the vulnerability responsibility label and the terminal device fingerprint in a triple representation; S42, responsibility node reverse positioning: When the offset is greater than or equal to the first threshold, locate to the operator node corresponding to the biometric hash; When the second threshold is less than or equal to the offset and the first threshold, locate to the environment dependency node associated with the device fingerprint; When the offset is less than the second threshold, mark it as a repair verification passed node; S43, construct a traceability tree: take the root node as a vulnerability responsibility label ID, the second node is classified according to the responsibility type, the responsibility type includes operators, environment and repair, the leaf node is mounted with offset value and evidence data package.

[0017] The beneficial effects of the present application are: The present application realizes the responsibility association closed loop between the vulnerability event and its repair effect by generating a "vulnerability responsibility label" containing the operator biometric feature hash, device fingerprint and network environment snapshot, and introducing the behavior offset calculation and three tuple association binding mechanism in the subsequent repair chain verification process, not only breaking through the information fragmentation problem of the traditional system "repair behavior cannot be backtracked to the responsibility attribution", but also supporting the positioning of the responsibility node through the traceability tree, and providing the supporting evidence data package (such as register difference log, system call track), realizing the audit level accountability traceability, especially suitable for complex network environment with multiple shared accounts or ambiguous operation path.

[0018] The "decoupled repair chain" constructed by the present application realizes the complete shielding of platform difference and hardware dependency by stripping the original system call and physical address access path, converting it into a WASM universal function pointer with the help of a pre-defined function mapping table, and finally compiling it into a portable WebAssembly bytecode module, which supports safe injection and execution in a variety of sandbox environments, adapts to x86, ARM, RISC-V and other heterogeneous architectures, and improves the platform universality and remote deployability of the vulnerability repair scheme.

[0019] The present application quantitatively measures the vulnerability repair effect as "behavior offset", comprehensively considers the memory usage peak change and system call sequence difference, and adopts mathematical Euclidean distance for normalized calculation. Combined with the responsibility threshold rule and tree topology structure, the system can automatically classify and locate as "operator responsibility node", "environment responsibility node" or "repair pass node", and visually express through red / yellow / green node color coding. This method not only greatly improves the automation degree of repair verification, but also reduces the cost of manual judgment. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the present application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only illustrate the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0021] Fig. 1 A schematic diagram is generated for the repair instruction chain of the embodiment of the present application. Fig. 2This is a schematic diagram of the system execution method according to an embodiment of the present invention. Detailed Implementation

[0022] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. For some well-known technologies, those skilled in the art may also use other alternative methods to implement the invention. Moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0023] like Figs. 1-2 As shown, an internet vulnerability assessment and analysis system includes the following functions: S1, Generate vulnerability liability labels: Obtain raw vulnerability data, bind the fingerprint of the evaluation terminal device, the operator's biometric hash, and the network environment snapshot to generate vulnerability liability labels; S2, Construct a decoupled remediation chain: Based on the vulnerability responsibility label, remove the environment dependency from the vulnerability responsibility label, replace it with a cross-platform equivalent function, and generate a remediation 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 tracing tree: Associate system repair behavior offsets with vulnerability responsibility labels, reverse locate responsibility nodes and generate a tracing tree.

[0024] S1 specifically includes: S11 receives raw vulnerability data: It receives the standard output data packet from the vulnerability scanning tool via 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: .

[0025] Receive the standard output data packet from the vulnerability scanning tool via the security API interface and extract the key fields as follows: The system utilizes a secure API interface to retrieve scan report data packages generated by mainstream vulnerability scanning tools (OpenVAS, Nessus, Qualys), supporting multiple output formats including JSON and XML. The scan reports are uploaded encrypted by the tool to a designated endpoint of the evaluation unit. The interface employs a token-based access control mechanism to ensure the integrity and authentication of data transmission.

[0026] After the evaluation unit receives the report data, it first decodes and formats it, and the parsing process automatically adapts the field path according to the scanning tool type, extracting the following three key indicators: Vulnerability signature: Extract the unique identification field of each vulnerability record from the report, such as CVE number (e.g. "CVE-2022-1234") or tool-defined vulnerability ID. This field is used to identify and match vulnerability repair function templates in subsequent steps.

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

[0028] Attack vector description: Extract the description information related to the vulnerability exploitation method, including attack path, trigger condition, protocol type, etc., combined with the vulnerability risk description field to form a structured attack vector semantic representation, facilitating the generation of equivalent replacement functions and the construction of verification test scenarios.

[0029] The three indicators parsed are encapsulated as the core information of the vulnerability event.

[0030] S12, bind evaluation terminal device fingerprint: call low-level hardware instruction to combine CPU and motherboard unique identification, and perform hash processing: ; Wherein, represents the CPU microcode version information, is the motherboard unique identification (SMBIOS format), is the string concatenation operation, represents a 256-bit SHA-3 hash function.

[0031] S13, bind operator biometric hash: collect voiceprint data and perform Fourier transform and double hash processing: ; Wherein, represents the original voiceprint waveform within 2000ms, represents the Fast Fourier Transform (FFT), and SHA256() represents the 256-bit SHA-2 hash function.

[0032] S14, bind network environment snapshot: extract the current network stack state and merge hash to generate network snapshot: ; Wherein, represents the TCP / IP stack configuration exported by the netstat command, represents the routing table content; represents the firewall rules, represents the concatenation of multiple configuration files and pre-hash, represents a fast hashing algorithm.

[0033] S15, generating vulnerability responsibility label: all the above binding data is combined into a digital label in TLV (Type-Length-Value) encoding format: ; wherein, represents a field type identifier (such as Bxe1 represents a vulnerability responsibility label), represents the length of the corresponding field content, is the value of the field, which is the hash result or the original description, represents the number of binding items here, and the combined label can be represented as: .

[0034] S2 specifically includes: S21, parsing environment dependent items: extracting environment sensitive operation data field from vulnerability responsibility label, extracting behavior characteristics in vulnerability responsibility label that are strongly bound to platform environment, including system call information at operating system level and hardware access path, environment dependent item field is located in TLV encoding structure of vulnerability responsibility label, specifically: Type=0x02: indicates that the field is "environment dependent item"; Value field is a compressed representation of environment dependent instruction sequence, which is represented by platform independent intermediate instruction (IR) or binary disassembly result, and is represented as: ; wherein, represents the th system call instruction symbol, such as intex80 under Linux, svc#0 of ARM architecture, represents the th register access path, such as movedx, Bfffffe000, which represents access to physical memory mapping area, which is obtained by parsing Type=0x02 field in TLV label, i.e. environment dependent item field.

[0035] The specific parsing process is as follows: S211, decoding and line processing: the Value field of Type 0x02 is divided according to the line break or semicolon, and the instruction statements are processed one by one.

[0036] S212, system call instruction recognition rule: platform specific system call is identified based on pattern matching, and the specific rule table is as follows: Table 1 system call instruction recognition rule table

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

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

[0039] S22, stripping environment-sensitive operations: process the operations in , including: Delete platform-specific system call entry instructions; Replace physical addresses with virtual general-purpose placeholders.

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

[0041] S23, replace with cross-platform equivalent functions: based on S21, S22, obtain two standardized instruction semantic sets: System semantic call symbol set: , which represents the operation semantics of the platform-specific call after standardization; Environment access call symbol set: ; Using a function mapping table Map the above semantic instructions to general function forms in WebAssembly: ; ; Where, Indicates a WebAssembly (WASM) function pointer, Indicates a memory or register equivalent processing function; Table 2 function mapping table

[0042] Note: WASM function names are all logical identifiers, declared in the following WAT source code.

[0043] {Detailed replacement logic flow}: for each call operator , perform the following steps: Step 1: look up to determine the replacement function name and signature; Step 2: semantic replacement: replace the semantic instruction with the corresponding WebAssembly function symbol or ; Step 3: build a replacement sequence: all replaced function symbols are concatenated in the original order to form a function pointer operation sequence: ; this is the final cross-platform repair instruction sequence.

[0044] S24, generate repair instruction chain: reorganize and compile the function pointer sequence into WebAssembly bytecode format to generate a repair chain: ; The generated is a.wasm file containing the neutral representation of all repair function calls, which is platform-independent.

[0045] S3 specifically includes: S31, instruction chain security injection: Load the WebAssembly bytecode format repair instruction chain output by S2 into a sandboxed virtual environment: ; and initialize its memory mapping table: ; where represents the bytecode repair instruction chain output by S2, represents the 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, is the starting position of the th virtual address, indicating the access entry, represents the mapped memory page object, containing the actual memory page content, permissions, etc., represents the total number of allocated memory pages, i.e., the number of mapping entries.

[0046] S32, differential parallel execution: S321, build two synchronous execution threads: : execute original vulnerability trigger path; : execute repair bytecode instruction chain; S322, the system periodically reads the key states of the two threads, including: CPU register group: such as RAX, RBX, RIP; System call sequence: record in time sequence.

[0047] S323, define the moment The difference in register state is: ; S324, define the system call sequence difference as Hamming distance: ; Where, is the register state vector of the two threads, is the ordered sequence of system calls, indicates the Hamming distance function.

[0048] S33, capture behavior offset: define the system repair behavior offset as the following Euclidean distance: ; Where: Memory peak change rate ; System call sequence timing difference (discrete features): ; Indicates the peak memory usage during execution.

[0049] S34, generate offset dataset: The execution result of each difference check will form a structured record unit: ; Where, indicates the offset of the execution, is the timestamp, indicates the current CPU load, is the network delay (if applicable to remote environment verification); all records will be aggregated to form the behavior offset dataset .

[0050] S4 specifically includes: S41, offset-label triple binding: bind the repair behavior offset with the operator biometric hash in the vulnerability responsibility label and the terminal device fingerprint to form a triple, defined as: ; Where, indicates the The responsibility binding triple of the secondary repair verification, The operator bio-feature hash is represented, The terminal device fingerprint is represented, The repair behavior offset (Euclidean distance value) is represented, and the triple will be used for subsequent responsibility node decision-making.

[0051] S42, responsibility node reverse positioning: according to the numerical value of the repair offset each time , the responsibility type is determined by using a threshold rule: ; Among them, The operator responsibility node is represented, The device or environment responsibility node is represented, The repair verification pass node is represented, 0.3 is the first threshold value, and 0.1 is the second threshold value.

[0052] S43, dynamically constructing a traceability tree structure: taking the responsibility label ID VID as a root node, a tree structure is constructed: ; Root node (Root): corresponding to the vulnerability responsibility label ID; Primary branch (Branch): responsibility classification node (operator / environment / pass); Secondary leaf node (Leaf): mount the feature and offset data in the triple; each leaf node is attached to the following data tuple: ; The original technical evidence extracted in the repair verification is represented, such as register difference logs, system call traces and other original evidence data.

[0053] S44, node color mapping rule: in order to realize the visual expression of the traceability tree, color coding is used to mark the responsibility level: ; The color mapping can be used for front-end interface rendering, visual output of graph database labeling.

[0054] The present application covers any substitution, modification, equivalent method and scheme made on the essence and scope of the present application. In order to make the public have a thorough understanding of the present application, specific details are described in the following preferred embodiments of the present application, and the present application can also be fully understood without the description of these details. In addition, in order to avoid unnecessary confusion to the essence of the present application, well-known methods, processes, procedures, elements and circuits, etc. are not described in detail.

[0055] The above merely describes the preferred embodiments of the present application, and it should be pointed out that, for those skilled in the art, some improvements and refinements can be made without departing from the principles of the present application, and these improvements and refinements should also be considered as falling within the protection scope of the present application.

Claims

1. A method for assessing and analyzing internet vulnerabilities, characterized in that, This includes executing the following: S1, Generate vulnerability liability labels: Obtain raw vulnerability data, bind the fingerprint of the evaluation terminal device, the operator's biometric hash and the network environment snapshot, and generate vulnerability liability labels; S2, Construct a decoupled remediation chain: Based on the vulnerability responsibility label, remove the environment dependency from the vulnerability responsibility label, replace it with a cross-platform equivalent function, and generate a remediation 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 tracing tree: Associate the offset of the remediation behavior with the vulnerability responsibility label, reverse locate the responsibility node and generate a tracing tree; After obtaining the original vulnerability data, S1 binds the fingerprint of the evaluation terminal device, the operator's biometric hash, and the network environment snapshot, specifically including: Binding the fingerprint of the evaluation terminal device: Collect the CPU microcode version information and the unique identifier of the motherboard of the evaluation terminal, and perform overall hash processing after concatenation to generate the device fingerprint string; Binding operator biometric hash: Real-time acquisition of operator voiceprint waveform, which is then transformed by Fourier transform to generate a dual SHA-256 hash value; Bind network environment snapshot: Capture the TCP / IP stack configuration, routing table and firewall rules of the current network state, and merge them and perform overall hash processing to obtain a network environment snapshot; S3 specifically includes: S31, Instruction Chain Security Injection: Loads WASM bytecode that repairs the instruction chain in the isolated sandbox of the target environment and initializes the virtual memory mapping table; S32, Differential Parallel Execution: Simultaneously executes the original vulnerability code and the repair instruction chain, and monitors the CPU register status and system call sequence in real time; S33, calculate the Euclidean distance of key parameters before and after repair, and capture the offset of repair behavior; S34 records the offset of each repair action and the corresponding environmental parameters, generating an offset dataset.

2. The Internet vulnerability assessment and analysis method according to claim 1, characterized in that, S1 also includes encoding the bound data into a digital tag in TLV format, with the tag header including a version number and an encryption identifier, to generate a vulnerability liability tag.

3. The Internet vulnerability assessment and analysis method according to claim 1, characterized in that, S2 specifically includes: S21, Analyze environment dependencies: Extract operating system kernel function call instructions and hardware register access paths from vulnerability liability tags; S22, Remove environment-sensitive operations: Identify the platform-corresponding system call symbol in the kernel function call instruction and remove the physical address mapping in the register access path; S23, replace with cross-platform equivalent function: query the pre-built function mapping table and convert the call symbols in S21 and S22 into WASM general function pointers; S24, Generate Repair Instruction Chain: Reassemble the converted function pointers and vulnerability repair logic, and compile them into a repair instruction chain in WASM bytecode format.

4. The Internet vulnerability assessment and analysis method according to claim 1, characterized in that, S4 specifically includes: S41, Offset-Label Association: Bind the remediation behavior offset to the operator's biometric hash and the terminal device fingerprint in the vulnerability responsibility label using a triple representation; S42, Reverse positioning of responsibility nodes: When the offset is greater than or equal to the first threshold, locate the operator node corresponding to the biometric hash. When the second threshold ≤ offset < first threshold, locate the environmental dependency node associated with the device fingerprint; When the offset is less than the second threshold, the node is marked as having passed the repair verification. S43, Construct a source tree: The root node is the vulnerability responsibility label ID, the second-level nodes are classified according to the responsibility type, the responsibility type includes operator, environment and remediation, and the leaf nodes are attached with offset values ​​and evidence data packets.

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

6. The Internet vulnerability assessment and analysis method according to claim 1, characterized in that, Specifically, S23 includes performing the following for each call operator: Lookup table: Search the function mapping table to determine the name and signature of the substitute function; Semantic substitution: Replaces the invocation operator directive with the corresponding WebAssembly function symbol; Constructing the replacement sequence: All replaced function symbols are concatenated in their original order to form a sequence of function pointer operations.

7. The Internet vulnerability assessment and analysis method according to claim 3, characterized in that, The sequence of function pointer operations is represented as follows: ;in, Represents a WASM function pointer. Represents the equivalent memory or register processing function; sequence of function pointers Reassembled and compiled into WASM bytecode format, the resulting repair instruction chain is represented as follows: ; The file is a .wasm file, containing a neutral representation of all repair function calls. This refers to a .wasm format WebAssembly bytecode file. This describes 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 method according to claim 7, characterized in that, The key parameters include the peak memory change rate and the timing difference of the system call sequence.

Images