An internet vulnerability assessment analysis method

Abstract

The present application relates to the technical field of internet analysis, and particularly relates to an internet vulnerability evaluation and analysis method, comprising the following steps: obtaining original vulnerability data, binding an evaluation terminal device fingerprint, an operator biological feature hash, a network environment snapshot, and generating a vulnerability responsibility label; stripping environment dependent items in the vulnerability responsibility label and replacing them with cross-platform equivalent functions to generate a repair instruction chain; executing the repair instruction chain in a target environment, capturing a repair behavior offset; associating the system repair behavior offset with the vulnerability responsibility label, reversely locating a responsibility node, and generating a traceability tree. The present application not only breaks through the information fragmentation problem of the traditional system that "repair behavior cannot be used to reverse the responsibility attribution", but also supports locating the responsibility node through the traceability tree and provides a matching evidence data package.

Description

Technical Field

[0001] This invention relates to the field of internet analysis technology, and in particular to a method for assessing and analyzing internet vulnerabilities. Background Technology

[0002] With the increasing complexity of internet system architecture and the continuous evolution of attack methods, software vulnerability assessment and remediation have become an important part of cybersecurity governance. Currently, the mainstream vulnerability handling process usually includes vulnerability detection, vulnerability notification, manual remediation and retesting.

[0003] Most existing vulnerability analysis systems focus on the triggering conditions of vulnerabilities and remediation suggestions, but lack a mechanism to effectively link vulnerability events with their device environment and operator behavior. Especially in scenarios involving multi-user shared systems, remote access, or cross-node deployment, accountability is difficult to trace, often leading to ambiguity and a lack of accountability. Traditional vulnerability remediation processes often build patches based on specific operating systems and hardware architectures, such as relying on Windows APIs, Linux kernel calls, or specific register structures. This tightly coupled structure makes it difficult to deploy and verify patches on heterogeneous platforms, hindering the application of remediation solutions in diverse systems such as IoT, embedded systems, and edge nodes.

[0004] Current remediation efforts typically rely on manual judgment or static regression testing, which struggles to capture dynamic behavioral changes at the system level and quantifies the differences in execution results before and after the remediation. This leads to frequent misjudgments and omissions. Furthermore, it is difficult to trace failed remediations or abnormal behaviors back to the responsible party or the specific operating environment. Summary of the Invention

[0005] This invention provides an Internet vulnerability assessment and analysis method that can reliably bind vulnerability behavior to operators, devices, and network environments, and supports the construction and execution verification of platform-independent automated remediation chains. Ultimately, it realizes an Internet vulnerability assessment and analysis system that quantifies offset behavior analysis and constructs a responsibility tracing tree, thereby improving the automation, security, reliability, and cross-platform adaptability of vulnerability handling.

[0006] An internet vulnerability assessment and analysis method includes performing the following:

[0007] 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;

[0008] 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;

[0009] 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;

[0010] S4, Generate a responsibility tracing tree: Associate the offset of the system repair behavior with the vulnerability responsibility label, reverse locate the responsibility node and generate a tracing tree.

[0011] Optionally, in step 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.

[0012] Optionally, after receiving 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:

[0013] Bind the fingerprint of the evaluation terminal device: Collect the CPU microcode hash value and motherboard firmware signature of the evaluation terminal to generate a device fingerprint string;

[0014] 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;

[0015] Bind network environment snapshot: Captures the current network state's TCP / IP stack configuration, routing table, and firewall rule hashes.

[0016] Optionally, S1 further 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.

[0017] Optionally, S2 specifically includes:

[0018] S21, Analyze environment dependencies: Extract operating system kernel function call operators and hardware register access paths from vulnerability liability tags;

[0019] 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;

[0020] 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;

[0021] 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.

[0022] Optionally, S23 specifically includes performing the following for each call operator:

[0023] Lookup table: Search the function mapping table to determine the name and signature of the substitute function;

[0024] Semantic substitution: Replaces the invocation operator directive with the corresponding WebAssembly function symbol;

[0025] Constructing the replacement sequence: All replaced function symbols are concatenated in their original order to form a sequence of function pointer operations.

[0026] Optionally, the function pointer operation sequence is represented as follows: ;in, Represents a WASM function pointer. Represents the equivalent memory or register processing function;

[0027] 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.

[0028] Optionally, S3 specifically includes:

[0029] 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;

[0030] 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;

[0031] S33, calculate the Euclidean distance of key parameters before and after repair, and capture the offset of repair behavior;

[0032] S34 records the offset of each repair action and the corresponding environmental parameters, generating an offset dataset.

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

[0034] Optionally, S4 specifically includes:

[0035] 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;

[0036] S42, Reverse positioning of responsibility nodes:

[0037] When the offset is greater than or equal to the first threshold, locate the operator node corresponding to the biometric hash.

[0038] When the second threshold ≤ offset < first threshold, locate the environmental dependency node associated with the device fingerprint;

[0039] When the offset is less than the second threshold, the node is marked as having passed the repair verification.

[0040] 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.

[0041] The beneficial effects of this invention are:

[0042] This invention generates a "vulnerability responsibility label" containing the operator's biometric hash, device fingerprint, and network environment snapshot. It also introduces a behavior offset calculation and triplet association binding mechanism during subsequent remediation chain verification, achieving a closed-loop responsibility association between vulnerability events and their remediation effects. This not only overcomes the information fragmentation problem of traditional systems where "remediation behavior cannot be used to trace responsibility," but also supports locating responsibility nodes through a source tree and provides supporting evidence data packages (such as register differential logs and system call traces), achieving audit-level accountability traceability. It is particularly suitable for complex network environments with multiple users sharing accounts or ambiguous operation paths.

[0043] This invention constructs a "decoupled repair chain" that completely shields platform differences and hardware dependencies by separating the original system calls from the physical address access paths, converting them into WASM general function pointers with the help of a predefined function mapping table, and finally compiling them into portable WebAssembly bytecode modules. This mechanism supports secure injection execution in various sandbox environments, is compatible with heterogeneous architectures such as x86, ARM, and RISC-V, and improves the platform universality and remote deployability of the vulnerability repair solution.

[0044] This invention quantifies vulnerability remediation effectiveness using "behavioral offset," comprehensively considering peak changes in memory usage and differences in system call sequences, and employing Euclidean distance for normalization calculation. Combining responsibility threshold rules and a tree-like topology, the system can automatically categorize and locate nodes as "operator responsibility nodes," "environment responsibility nodes," or "remediation passed nodes," visually represented through red / yellow / green node color coding. This approach not only significantly improves the automation of remediation verification but also reduces the cost of manual judgment. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram illustrating the generation of the repair instruction chain according to an embodiment of the present invention;

[0047] Figure 2 This is a schematic diagram of the system execution method according to an embodiment of the present invention. Detailed Implementation

[0048] 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.

[0049] like Figures 1-2 As shown, an internet vulnerability assessment and analysis method includes performing the following:

[0050] 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;

[0051] 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;

[0052] 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;

[0053] S4, Generate a responsibility tracing tree: Associate system repair behavior offsets with vulnerability responsibility labels, reverse locate responsibility nodes and generate a tracing tree.

[0054] S1 specifically includes:

[0055] 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:

[0056] Vulnerability signature: ;

[0057] Affected memory addresses: ;

[0058] Attack vector description: ;

[0059] It can be represented as a triple: .

[0060] Receive the standard output data packet from the vulnerability scanning tool via the security API interface and extract the key fields as follows:

[0061] 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.

[0062] After receiving the report data, the evaluation unit first decodes and parses the format. During the parsing process, the field paths are automatically adapted according to the scanning tool type, and the following three key indicators are extracted:

[0063] Vulnerability Signature: A unique identifier field extracted from the report for each vulnerability record, such as a 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.

[0064] Affected memory addresses: Extract address information or offsets of the locations affected by the vulnerability, such as memory addresses and function entry points, to guide the instruction injection locations and patch matching operations in subsequent remediation chains.

[0065] Attack Vector Description: Extract descriptive information related to the vulnerability exploitation method, including attack path, triggering conditions, protocol type, etc., and combine it with the vulnerability risk description field to form a structured semantic representation of the attack vector, which facilitates the subsequent generation of equivalent substitution functions and the construction of verification test scenarios.

[0066] The three analyzed metrics were uniformly packaged into the core information of the vulnerability incident.

[0067] S12, Binding and evaluating the terminal device fingerprint: This involves calling low-level hardware instructions to combine the unique identifiers of the CPU and motherboard, and then performing hash processing. ;in, This indicates the CPU microcode version information. This is a unique identifier for the motherboard (SMBIOS format). This is a string concatenation operation. This represents a 256-bit SHA-3 hash function.

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

[0069] S14, Bind Network Environment Snapshot: Extract the current network stack state, merge hashes to generate a network snapshot:

[0070] BLAKE3 ;in, This indicates the TCP / IP stack configuration exported by the netstat command. This indicates the contents of the routing table; This indicates firewall rules. This indicates that multiple configuration files are concatenated and pre-hashened, BLAKE3 This indicates the fast hash algorithm.

[0071] S15, Generate Vulnerability Liability Labels: Combine all the above-bound data into a numeric label using TLV (Type-Length-Value) encoding format:

[0072] ;

[0073] in, This indicates the field type identifier (e.g., Bxe1 represents a vulnerability liability label). Indicates the length of the corresponding field content. The value of the field is either the hash result or the original description mentioned above. This indicates the number of bound items. A combined tag can be represented as:

[0074] Type Len Type Len Fingerprint Type Len Fingerprint Type Len Snapshot .

[0075] S2 specifically includes:

[0076] S21, Parsing Environment Dependencies: Extracting environment-sensitive operational data fields from the vulnerability liability label, and extracting behavioral characteristics strongly bound to the platform environment from the vulnerability liability label, 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 liability label, specifically:

[0077] Type=0x02: This indicates that the field is an "environment dependency";

[0078] The Value field is a compressed representation of the environment-dependent instruction sequence, using platform-independent intermediate instruction representation (IR) or binary disassembly results, and is represented as follows:

[0079] ;

[0080] in, Indicates the first System call instructions, such as svc#0 for Linux's intex80 and ARM architecture. Indicates the first The item register access path, such as movedx,Bxffffe000, indicates access to the physical memory-mapped region. This set is obtained by parsing the Type=0x02 field in the TLV tag, which is the environment dependency field.

[0081] The specific analysis process is as follows:

[0082] S211, Decoding and Line Break Processing: The Value field with Type 0x02 is split according to newline or semicolon, and the instruction statements are processed one by one.

[0083] S212, System Call Command Identification Rules: Based on pattern matching, the rules for identifying platform-specific system calls are as follows:

[0084] Table 1 System Call Command Identification Rules

[0085]

[0086] System calls can be located by instruction prefixes or function names on the call stack, and the call number or parameters can be decoded into semantic identifiers.

[0087] S213, Register access path identification rules:

[0088] Identify the following behaviors:

[0089] Access special memory regions (e.g., 0xFFFF0000, 0x3F200000).

[0090] Register manipulation instructions such as mov, ldr, str, lea, etc., are associated with immediate values ​​at their addresses;

[0091] Recognition rules:

[0092] If the immediate address falls within the known MMIO_access and BIOS_read configuration space range, it is determined to be an environment-sensitive path.

[0093] S22, stripping environmentally sensitive operations: for The operations in the process include stripping, including:

[0094] Delete platform-specific system call entry commands;

[0095] Replace the physical address mapping with a virtual generic placeholder.

[0096] Represented as the set after stripping: ;in, This means that only semantic call symbols, such as sys_read, sys_write, and sys_mmap, are retained after stripping. This indicates that the physical address in the register path has been replaced with a placeholder, such as VIRT_ADDR.

[0097] S23 is replaced with a cross-platform equivalent function: Based on S21 and S22, two standardized instruction semantic sets are obtained:

[0098] System semantic caller set: sys_read, sys_write, sys_mmap These represent the standardized operational semantics of platform-specific calls;

[0099] Set of environment access modifiers: MMIO_access,BIOS_read ;

[0100] Use function mapping table Map the above semantic instructions to a generic function form in WebAssembly:

[0101] ;

[0102] ;

[0103] in, This represents a WebAssembly (WASM) function pointer. Represents the equivalent memory or register processing function;

[0104] Table 2 Function Mapping Table

[0105]

[0106] Note: WASM function names are all logical identifiers and will be declared in the WAT source code later.

[0107] {Detailed Replacement Logic Flow}: For each call operator Perform the following steps:

[0108] Step 1: Look up the table. Determine the name and signature of the substitution function;

[0109] Step 2: Semantic Substitution: Substitute semantic instructions Replace with the corresponding WebAssembly function symbol or ;

[0110] Step 3: Construct the replacement sequence: Concatenate all the replaced function symbols in their original order to form a sequence of function pointer operations. This is the final cross-platform repair instruction sequence.

[0111] S24, Generate repair instruction chain: This involves converting the function pointer sequence... Reassemble and compile into WebAssembly bytecode format to generate a repair chain: ;

[0112] generated It is a .wasm file containing a neutral representation of all fix function calls, and is platform independent.

[0113] S3 specifically includes:

[0114] S31, Instruction Chain Secure Injection:

[0115] Load the WebAssembly bytecode format repair instruction chain output by S2 into an isolated sandbox virtual environment:

[0116] ;

[0117] And initialize its memory-mapped table: ;

[0118] in, The bytecode repair instruction chain output by S2 Indicates a secure, isolated execution environment. This represents the virtual memory mapping table, which is a description of the allocation of virtual address space during the WebAssembly sandbox runtime. For the first The starting position of each virtual address indicates the access point. This represents the mapped memory page object, containing information such as the actual memory page's content and permissions. This indicates the total number of memory pages allocated, i.e., the number of mapping entries.

[0119] S32, Differential Parallel Execution:

[0120] S321, construct two synchronous execution threads:

[0121] : Execute the original vulnerability trigger path;

[0122] : Execute the repair bytecode instruction chain;

[0123] S322, the system periodically reads the key states of two threads, including:

[0124] CPU register sets: such as RAX, RBX, RIP;

[0125] System call sequence: recorded in chronological order.

[0126] S323, Define Time The differential register state is: ;

[0127] S324 defines the difference in system call sequences as the Hamming distance: ;

[0128] in, These are the register state vectors of the two threads. An ordered sequence of system calls. This represents the Hamming distance function.

[0129] S33, Capture Behavior Offset: Define the system repair behavior offset as the following Euclidean distance:

[0130] ;

[0131] in:

[0132] Peak memory change rate : ;

[0133] System call sequence timing difference (Discrete characteristics): ; This indicates the peak memory usage during execution.

[0134] S34, Generate offset dataset:

[0135] The result of each differential verification will form a structured record unit:

[0136] ;

[0137] in, Indicates the first Offset for the next execution For timestamps, Indicates the current CPU load. For network latency (e.g., for verification in remote environments); all records will be aggregated to form the behavioral offset dataset. : .

[0138] S4 specifically includes:

[0139] S41, Offset-Label Triple Binding: This involves binding the remediation action offset to a triplet of the operator's biometric hash and the terminal device fingerprint in the vulnerability liability label, defined as:

[0140] ;in, Indicates the first The responsibility binding triple for the secondary repair verification This represents the operator's biometric hash. This indicates the fingerprint of the evaluation terminal device. To correct the behavior offset (Euclidean distance value), the triple will be used for subsequent responsibility node decisions.

[0141] S42, Reverse positioning of responsibility nodes: Based on the numerical value of each repair offset. Threshold rules are used to determine the type of responsibility:

[0142] ;

[0143] in, This indicates mapping to the operator's responsibility node. This indicates mapping to a device or environment responsibility node. This indicates that the node has passed the repair verification. 0.3 is the first threshold and 0.1 is the second threshold.

[0144] S43, Dynamically construct the traceability tree structure: Build the tree structure with the responsibility tag ID (VID) as the root node:

[0145] ;

[0146] Root node: Corresponds to the vulnerability responsibility label ID;

[0147] First-level branch: Responsibility classification node (operator / environment / pass);

[0148] Second-level leaf nodes (Leaf): These nodes carry the feature and offset data from the triples; each leaf node includes the following data tuples: ;

[0149] This refers to the original technical evidence extracted during the repair verification, such as register differential logs, system call traces, and other original evidence data.

[0150] S44, Node Color Mapping Rules: To achieve a visual representation of the source tree, color coding is used to label the level of responsibility.

[0151] ;

[0152] This color mapping can be used for front-end interface rendering and visual output of graph database annotations.

[0153] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0154] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

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; 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; 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; 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.

2. 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.

3. 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.

4. 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.

5. The Internet vulnerability assessment and analysis method according to claim 1, characterized in that, 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.

6. The Internet vulnerability assessment and analysis method according to claim 5, characterized in that, The key parameters include the peak memory change rate and the timing difference of the system call sequence.

Images