Homolog-based internet of things web service fuzzing method

Abstract

The application provides a homology-based Internet of Things web service fuzzy testing method, which identifies input functions and processing functions in web service programs from different Internet of Things firmware batches, the input functions are used for parsing and reading user data from memory; the web service programs are grouped by homology, cross-firmware homology processing function difference analysis is performed on the processing functions in each homology group, semantic evaluation is performed on the differences by using a semantic reasoning engine or a machine learning model, and a differentiated test plan is generated accordingly; symbolic execution and taint analysis are performed, a key-value pair structure test seed decoupled from a network protocol is generated, and key fields in the test seed flowing to dangerous functions or custom functions are marked; a fuzzy testing driver program is constructed, the execution entry of the web service program is redirected to a target processing function by using a Hook technology, the calling of the processing function to the input function is intercepted, and the test seed is directly provided to the processing function for function-level fuzzy testing.

Description

Technical Field

[0001] This invention belongs to the field of IoT security and vulnerability discovery technology, specifically involving a fuzz testing method for IoT web services based on homology. Background Technology

[0002] In recent years, with the widespread application of IoT devices, complex service programs (especially web service programs responsible for providing system management interfaces and device function configurations) in devices such as wireless routers and cameras that handle network management requests have exposed numerous security vulnerabilities that can be used to launch cyberattacks. To reduce R&D costs and shorten delivery cycles, device manufacturers commonly reuse mature code across models and devices, resulting in significant code homogeneity between different firmware versions. This is the root cause of the widespread dissemination of vulnerabilities across devices. However, existing firmware security analysis techniques generally treat each target firmware as an independent analysis object, ignoring the homogeneity characteristics between firmware versions. When faced with batches of homogeneous IoT firmware, traditional methods lack mechanisms for identifying and filtering known or duplicate code segments, leading to a significant waste of computational resources on redundant testing of identical code logic. Even when some methods introduce binary code similarity detection to guide fuzzing, these methods are usually limited to a one-to-one linear comparison between two single target programs, lacking a design for multi-target collaborative deduplication, making it difficult to extend and apply to real-world scenarios involving the cross-analysis of batches of homogeneous firmware.

[0003] Furthermore, existing conventional firmware vulnerability detection technologies face significant bottlenecks in practical implementation. Particularly in the field of dynamic fuzzing, existing IoT fuzzing methods face numerous challenges: on the one hand, firmware web service programs often have deep dependencies on specific hardware peripherals or complex initialization environments during startup, making remanufacturing and simulation extremely difficult; on the other hand, because the input processing of web service programs typically involves lengthy and complex network protocol (such as HTTP request) parsing and legitimacy verification logic, traditional fuzzing tools struggle to automatically generate high-quality test cases that can penetrate shallow message verification, making it extremely difficult to effectively reach and explore the deep, high-risk business processing logic of web service programs. Even though some existing methods introduce heuristic strategies such as directed fuzzing to attempt to guide the execution flow to cover and explore specific processing functions as much as possible, these methods still adhere to the program's original input entry point. This means that each test case execution must repeatedly undergo a lengthy and complex pre-processing protocol parsing and state verification process, and cannot guarantee full coverage of all processing functions. Summary of the Invention

[0004] To address the shortcomings and deficiencies of existing technologies, this invention provides a fuzz testing method for IoT Web services based on homogeneity. Existing IoT firmware fuzz testing lacks mechanisms for identifying and filtering duplicate code across devices when dealing with batches of homogeneous firmware, leading to significant computational resource consumption on redundant testing. Furthermore, strong firmware emulation dependencies and lengthy front-end network protocol parsing paths make it difficult to effectively reach and cover deep business processing logic. Therefore, this invention first identifies the input functions for reading user data and the processing functions for executing business logic in the batch of firmware Web service programs, designating them as data injection points and direct test targets, respectively. By grouping the batch of Web service programs into homogeneous groups, a cross-firmware difference analysis is performed on each processing function within the group. A semantic reasoning engine or machine learning model is used to semantically evaluate the differences, eliminating non-substantial changes caused by compilation optimization, address offsets, variable renaming, etc., retaining only processing functions with substantial functional differences. Based on this, a differentiated test plan eliminating redundancy is generated. For each target processing function in this plan, independent execution is performed, starting from the function itself. Symbolic execution and taint analysis are employed. Input values ​​read from the input function are symbolized and tainted. During path exploration, if a symbolic value is detected flowing to a dangerous function or a user-defined function, constraint solving is triggered to generate a key-value pair test seed decoupled from the network protocol. Simultaneously, the input key corresponding to the symbolic value is marked as a critical field. Subsequently, a fuzz test driver is constructed, using hook technology to redirect the execution entry point of the web service program to the target processing function and intercept the processing function's call to the input function. The test seed is directly provided as input data to the processing function to perform function-level fuzz testing. During the mutation phase, critical fields are assigned higher mutation weights than non-critical fields. This invention achieves global redundancy elimination in multi-firmware scenarios by combining source difference analysis with semantic evaluation of large language models; by identifying processing functions and intercepting input calls, it avoids the dependence on system-level simulation and pre-protocol parsing, ensuring direct test coverage of all target processing functions; and by generating high-quality key-value pair structure seeds adapted for function-level testing and marking security-sensitive key fields through symbolic execution and taint co-analysis starting from processing functions, it significantly improves the efficiency and ability to discover deep vulnerabilities in IoT firmware.

[0005] The specific technical solution adopted by this invention to solve its technical problem is as follows: A fuzz testing method for IoT web services based on homology includes: Identify input functions and processing functions in web service programs from batches of different IoT firmware, wherein the input functions are used to parse and read user data from memory, and the processing functions are used to execute business logic in response to network requests; The batch of Web service programs are grouped into homogeneous groups. Within each homogeneous group, a cross-firmware homogeneous processing function difference analysis is performed on the processing function. The differences are semantically evaluated using a semantic reasoning engine or machine learning model to identify substantial functional differences and eliminate redundancy caused by non-substantial changes, thereby generating a differentiated test plan. For each target processing function in the differentiated test plan, symbolic execution and taint analysis are performed starting from the processing function to generate key-value pair structure test seeds decoupled from the network protocol, and the key fields in the test seeds that flow to dangerous functions or user-defined functions are marked. A fuzz test driver is constructed, which redirects the execution entry point of the Web service program to the target processing function through Hook technology, intercepts the processing function's call to the input function, directly provides the test seed to the processing function to perform function-level fuzz testing, and assigns higher mutation weights to key fields compared to non-key fields.

[0006] Furthermore, the steps for identifying the input function include: extracting shared keywords between the IoT firmware front-end page and the Web service program; filtering candidate input functions based on the call frequency of the shared keywords; performing multiple independent semantic analyses on each candidate input function using a large language model; and determining the final input function through a majority voting mechanism.

[0007] Furthermore, the steps for identifying processing functions include: detecting URL path registration functions in the Web service program and scanning the structured function table in the program data segment to extract the initial processing function list; filtering processing functions that have not called input functions based on the function call graph to obtain the final processing function.

[0008] Furthermore, the steps of grouping batch Web service programs into homogeneous groups and performing cross-firmware difference analysis include: using a binary code similarity comparison tool to cross-compare batch Web service programs, clustering batch Web service programs into multiple homogeneous firmware groups based on a preset similarity threshold; extracting the decompiled code difference data of each processing function within the homogeneous group, and globally unifying the homogeneous processing functions distributed in different firmwares through a disjoint-set data structure.

[0009] Furthermore, the differences are semantically evaluated using a semantic reasoning engine or machine learning model. Specifically, the differences are semantically evaluated using a large language model, including filtering out non-substantial changes caused by address offsets, variable renaming, compilation optimization, and log changes, and retaining only substantive functional differences involving business logic modifications or security verification changes.

[0010] Furthermore, the steps for generating differentiated test plans include: based on the semantic evaluation results of the large language model, dividing the processing functions into unique, locally shared, globally shared, and modified types; selecting a single program instance for testing the unique, locally shared, and globally shared processing functions; and after dividing the modified processing functions into subgroups according to logical equivalence, selecting a single program instance from each subgroup for testing.

[0011] Furthermore, the steps for generating key-value pair structure test seeds decoupled from the network protocol include: initializing the input values ​​read by the input function as symbolic values ​​carrying taint labels; during symbolic execution, when it is detected that symbolic values ​​flow to dangerous functions or user-defined functions, triggering the constraint solver to generate key-value pair structure test seeds that satisfy the current path constraints; when symbolic execution reaches the preset execution limit, extracting the symbolic states of execution paths of different lengths for constraint solving, and generating supplementary test seeds.

[0012] Furthermore, the steps for constructing and mounting the fuzz test driver include: redirecting the execution entry point of the web service program through Hook technology to restore the running context of the target processing function; intercepting the call of the processing function to the input function through inline Hook technology; monitoring command injection-type dangerous functions through Hook technology to capture vulnerability abnormal states; and mounting the driver to the web service program by modifying the dynamic dependency table of the target web service program. If mounting fails, a preloading mechanism is used to force mounting.

[0013] Furthermore, the steps for performing function-level fuzz testing include: monitoring program crash status and edge coverage growth status; when the edge coverage does not increase within a preset time period, adaptively terminating the fuzz testing task of the current target processing function.

[0014] And, an IoT web service fuzzing device based on homology, comprising: The function identification module is used to identify input functions and processing functions in web service programs from batches of different IoT firmware; The difference analysis module is used to group the batch of Web service programs into homogeneous groups, perform homogeneous processing function difference analysis across multiple firmwares, and use a semantic reasoning engine or machine learning model to perform semantic evaluation on the differences in order to identify substantial functional differences and eliminate redundancy caused by non-substantial changes, thereby generating a difference test plan. The seed generation module is used to perform symbolic execution and taint analysis starting from the target processing function, generate key-value pair structure test seeds that are decoupled from the network protocol, and mark the key fields in the test seeds that flow to dangerous functions or user-defined functions; The fuzzing execution module is used to construct a fuzzing driver program. It redirects the execution entry point of the Web service program to the target processing function through Hook technology, intercepts the processing function's call to the input function, directly provides the test seed to the processing function to perform function-level fuzzing, and assigns higher mutation weights to key fields compared to non-key fields.

[0015] Compared to existing technologies, this invention and its preferred solution overcome the limitations of traditional one-to-one analysis, achieving global redundancy testing optimization in batch firmware scenarios, significantly reducing repeated testing of identical or equivalent logic code, and effectively reducing the consumption and waste of computing resources; it avoids complex system-level firmware remanagement dependencies, bypasses the cumbersome pre-network protocol parsing and verification process, and achieves direct testing and full coverage protection of the target processing function, significantly improving the ability to discover high-risk vulnerabilities in the deep structure of the device; it combines symbolic execution and taint analysis techniques to generate high-quality initial seeds that satisfy the internal constraints of the target function, and through a key field mutation strategy, it greatly enhances the vulnerability triggering capability for security-sensitive areas, improving the overall efficiency and effectiveness of fuzz testing. Attached Figure Description

[0016] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments: Figure 1 This is a general implementation framework diagram of the embodiment of the present invention; Figure 2 This is a flowchart of the processing function difference analysis in an embodiment of the present invention. Detailed Implementation

[0017] To make the features and advantages of the present invention more apparent and understandable, specific embodiments are described below in detail: It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0018] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0019] like Figure 1As shown in the figure, this invention discloses an IoT fuzzy testing method based on homology, including the following steps: input and processing function identification; processing function difference analysis; seed generation based on function-level fuzzy testing; and function-level processing function fuzzy testing.

[0020] Step 1: Input and Processing Function Identification This invention aims to conduct fuzz testing on processing functions in Internet of Things (IoT) web service programs. To determine the testing objectives of function-level fuzz testing and support an efficient testing process, this invention first uses reverse engineering tools such as Ghidra to identify input and processing functions.

[0021] 1. Input function recognition The input function is used to parse and read user data from memory, serving as the test input point for subsequent fuzzing tests. In IoT firmware, service programs typically transmit user-requested data through keywords shared between the front-end and back-end web service programs. The input function is responsible for parsing and extracting data corresponding to these keywords from memory and passing it to the processing function. Based on this characteristic, this step first uses front-end / back-end keyword association tools such as SaTc to extract shared keywords between the front-end page and the corresponding web service program of the IoT firmware, and then searches for functions referencing these keywords in the binary file of the back-end service program, using them as candidate input functions. Subsequently, candidate input functions in the web service program are extracted based on the calling frequency of shared keywords, and the candidate functions are sorted, with the top K (e.g., K=50) functions forming the core candidate set. Further, to correctly identify the input function that actually receives user data, this scheme introduces a large language model for semantic discrimination, using the large language model to assist in identifying the input function. Specifically, the function name of the candidate function and the decompiled code are structured into prompt words, which are then input into the large language model to analyze its code semantics. To ensure the determinism and stability of the output results of the large model, a self-consistency strategy is adopted, that is, the same candidate function is queried multiple times (e.g., 3 times), and the final conclusion is obtained through a majority voting mechanism to ensure the stability of the identification results.

[0022] 2. Processing function identification The processing function responds to specific network requests by executing corresponding business logic, serving as the direct test target for subsequent fuzzing. Internally, it typically only covers data extraction and processing, without significant hardware dependencies. This step first extracts an initial processing function list by detecting URL path registration functions and scanning the structured function table in the program data segment, traversing and extracting candidate processing functions. Subsequently, since not all processing functions directly handle user input, to avoid ineffective fuzzing of processing functions without user interaction entry points, this scheme combines the accurately identified input functions to filter out initial processing functions that do not call input functions, determining the retained processing functions as the final test targets. Specifically, a function call graph is constructed based on static analysis, and the call chain of each processing function is examined, eliminating those processing functions that do not call any known input functions in the execution path. After this filtering step, only those processing functions that can truly acquire and process user input data from external network requests are retained as the test targets for subsequent fuzzing.

[0023] like Figure 2 The diagram shown is a flowchart of the processing function difference analysis in this application.

[0024] Step 2: Processing Function Difference Analysis To eliminate redundant testing of the same or equivalent code during vulnerability discovery across multiple firmware versions (such as different models from the same manufacturer), this invention, based on the identification of processing function sets, conducts in-depth difference analysis and generates differentiated test plans. Specifically, it includes the following four sub-steps: 1. Service program grouping First, the binary files of the web service programs are extracted from the collected firmware images. A binary code similarity comparison tool (such as BinDiff) is used to cross-compare the batch of web service programs, calculating the overall similarity score of the corresponding web service programs across different devices. Then, a preset similarity threshold (e.g., 85%) is set, and a greedy grouping strategy is used to cluster the highly similar web service programs that meet this threshold into multiple homogeneous firmware groups, which serve as the base set for subsequent homogeneous processing function comparisons.

[0025] 2. Function Difference Extraction For each Web service application instance within the same source group, a difference comparison tool such as Ghidriff is used to perform pairwise comparison analysis on the processing functions identified in step one, recording the differences and matching information in the decompiled code. The decompiled code of the processing functions in each Web service application within the same firmware group is extracted to generate difference data. To track the same processing function across multiple device instances within the entire source group, this step employs a disjoint-set data structure. Using this structure, matching processing functions are grouped into the same disjoint set based on function matching information, thereby globally unifying and associating source-related processing functions distributed across different firmware instances. This integrates source-related processing functions from various devices into a global processing function data structure encompassing multiple device instances.

[0026] 3. Large language model-assisted differential assessment Traditional binary comparison tools are susceptible to low-level factors such as compiler optimizations, load base address offsets, register reallocations, log changes, and variable renaming, generating significant non-substantial noise. Therefore, this step introduces a large language model for in-depth semantic difference significance assessment. Specifically, the decompiled code corresponding to processing functions with initial differences is extracted, and structured hints containing the difference context are constructed and submitted to the large language model for inference analysis. The large language model evaluates the difference data, filtering out non-substantial changes such as address offsets and variable renaming to identify and record significant semantic differences involving functionality or security. To ensure the determinism and stability of the large model's evaluation results, a self-consistent strategy is adopted, i.e., multiple independent prediction queries (e.g., 3 times) are performed on the same processing function's differing code, and a final conclusion is reached through a majority voting mechanism.

[0027] 4. Generation of Differentiated Test Plans Based on the evaluation results of the large language model and the distribution of processing functions across various device instances, homologous processing functions are classified into unique, locally shared, globally shared, and modified types according to significant semantic differences. A differentiated test plan is generated based on the classification results to eliminate redundant testing: for unique, locally shared, and globally shared functions, only a single program instance is selected; for modified functions, they are further subdivided according to logical equivalence, and then a single program instance is selected for each subgroup. This combination generates a differentiated test plan. This mechanism ensures that redundant processing functions are tested only once, thereby significantly reducing redundant testing overhead.

[0028] Step 3: Seed generation based on function-level fuzzing For the testing scenarios described in this invention, which skips pre-protocol parsing and directly hooks the processing function, traditional message seeds containing complex protocol headers are no longer suitable. Therefore, this section, based on binary analysis frameworks such as angr, performs parallel symbolic execution and taint analysis on the processing function to automatically generate a high-quality structured seed with a key-value pair structure specifically tailored for function-level fuzzing, and annotates its key fields. This dedicated key-value pair seed, stripped of its network layer shell, can be directly read by the hooked input function, thus adapting to the input requirements of function-level fuzzing. The specific execution process is as follows: 1. Local symbolization and path constraint collection This step does not need to start from the global main function of the service program, but instead independently unfolds symbolic execution from the processing function in the differentiated test plan. This is because the processing function itself is a self-contained business logic unit, and its control flow and data flow are mainly driven by user input data obtained through the input function, rather than by external program state or preceding execution context. Therefore, it is sufficient and reasonable to use this function as the entry point for symbolic analysis, without needing to rely on under-constrained symbolic execution to compensate for the lack of global context. The target function of the corresponding web service program is loaded through the angr binary analysis engine, and the input values ​​read from the input function are initialized as symbolic values ​​carrying taint labels, and simultaneously initialized to a tainted state. Subsequently, the angr engine is driven to execute downwards along the control flow of the processing function, continuously tracking the branch state and collecting the corresponding path constraint equations during execution. To control computational overhead, a maximum number of execution steps and a timeout limit are pre-imposed on the symbolic execution.

[0029] 2. Structured seed solving with multiple triggering mechanisms During symbolic execution exploration, once it is detected that symbolic values ​​flow to dangerous functions (such as system, sprintf, etc.) or arbitrary user-defined functions (non-standard library functions, third-party functions defined by firmware manufacturers), the constraint solver is triggered to generate an initial seed in a key-value pair structure that satisfies the path constraints. If the exploration is forced to end due to triggering the maximum number of steps or timeout limit, and the above functions are not reached throughout the process, the symbolic states of the longest, medium, and shortest execution paths are extracted for constraint solving to supplement the initial seed. The engine will extract three representative symbolic states corresponding to the longest, medium, and shortest execution paths from the saved state set for constraint solving to generate a structured initial seed.

[0030] 3. Collaborative taint tracking and key field annotation While the angr engine deduces path constraints, the system performs taint analysis in parallel. The system continuously monitors tainted symbolic variables, and when it detects that a tainted variable is passed to the aforementioned dangerous functions or arbitrary user-defined functions, it locks the input key corresponding to that variable and marks it as a critical field to guide subsequent mutation resource allocation. Input fields marked as critical fields indicate that the data substantially participates in complex logical operations or reaches sensitive execution points of underlying dangerous functions during the testing phase, possessing a higher probability of vulnerability triggering and greater potential for deeper logic exploration compared to ordinary fields. In the subsequent function-level fuzzing phase, this critical field will guide the mutation strategy in allocating resources.

[0031] Step 4: Function-level fuzzy testing After completing the differential test plan and generating a high-quality initial seed containing key fields, this invention enters the dynamic function-level fuzzing phase. A fuzz test driver (Harness) is constructed to redirect the Web service program's execution entry point to the processing function in the differential test plan, and key fields in the initial seed are subjected to focused mutation. The core reason this invention can directly test the processing function is that the hardware dependencies of IoT Web service programs are typically concentrated in the system startup and global initialization phases, while the specific processing functions rarely involve strong dependencies on the underlying hardware. The external dependencies of these processing functions are mostly limited to obtaining network request data through specific input functions. Furthermore, this invention uses Hook interception rather than static code slicing, meaning that the processing function remains within the complete original program image during execution, and can normally call any other functions or dependent libraries within the program. Therefore, there is no need to build a large system-level simulation environment and a complete network request parsing process; simply reconstructing the input function to accurately provide the required user input ensures the complete operation of the processing function's functional logic. Based on this, this stage relies on fuzz testing engines such as AFL++ (American Fuzzy Lop plus plus) and its QEMU user-mode simulation mode to directly hook and test the target processing function. Specific implementation details are as follows: 1. Test driver construction To bypass the hardware initialization logic and cumbersome network request parsing process in the target service program, the system first uses templates constructed in languages ​​such as Python to automatically generate independent fuzzing drivers for the tested processing function. These drivers uniformly encapsulate a Hook mechanism for the target function at the source code level. Entry redirection Hook: Using Hook technology, the execution entry point of the Web service program is redirected to the target processing function, and the corresponding function call environment is configured to restore the running context. The original program entry point (such as __uClibc_main) is intercepted using dynamic linking Hook technology, and a forced jump is made to the custom main function inside the driver to build the context environment required by the target processing function. Dangerous function monitoring hook: Hook command injection dangerous functions to capture vulnerability abnormal states. Considering that command injection dangerous functions such as system and execve are usually located in the system dynamic library, the driver also uses dynamic link hook to intercept them at the underlying level in order to accurately capture unauthorized execution behavior at runtime. Input function inline hook: This method uses hook technology to intercept and reconstruct calls to input functions within the processing function. Since input functions are usually statically linked during firmware compilation, they cannot be intercepted by conventional dynamic hooks. This solution is designed for the limited MIPS and ARM architectures and implements inline hook logic within the driver program. That is, at runtime, the memory instructions of the corresponding input function are directly overwritten, forcing a jump to a custom input function that can parse the structured seed.

[0032] In addition, for the few utility functions inside the processing function that involve hardware interaction or network connection status management, inline hooks can also be used to shield or simplify them to ensure that the processing function can still execute stably in an environment without complete hardware simulation.

[0033] 2. Compiling, linking, and mounting the driver module After completing the comprehensive driver program consisting of entry redirection, dangerous function monitoring, and input function inline hooking, the system compiles it into a dynamic link library format and then mounts the driver dynamic library onto the target web service program. The specific linking mechanism is as follows: the system prioritizes calling binary patching tools such as patchelf to directly write the name of the driver dynamic library into the dynamic dependency table of the target binary firmware file; if the linking operation fails due to target binary file format or environmental limitations, it automatically downgrades, using a mechanism such as the LD_PRELOAD environment variable to force the driver library to be mounted first during the program preloading phase. Through this method, at the moment the target program starts, the fuzzy driver program, referenced by the dynamic library, is fully loaded by the operating system, subsequently successfully hijacking the execution flow and performing fuzzing to intercept the target processing function.

[0034] 3. Mutation strategy for integrating key fields Upon receiving the structured initial seed and key field annotation information created in step three, the system reconfigures the mutants within the AFL++ fuzzing engine. During the mutation phase of fuzzing, mutation resources are allocated based on key fields, and a custom mutation strategy is used to focus on mutating key seed fields. The system designs a matching combination of mutation operators based on the specific seed format. In addition to retaining the native Havoc heuristic mutation, it introduces local operations specifically targeting the `values` field in the seed key-value pairs for data modification, insertion, and deletion. In terms of energy allocation, the system prioritizes the majority (e.g., 80%) of the total global mutation resources to key-value pairs marked as key fields; while the remaining (e.g., 20%) is used to modify ordinary fields, ensuring testing of the vulnerability trigger area while maintaining the overall structural legitimacy of the seed input.

[0035] 4. Differential task scheduling and adaptive termination During fuzzing, the AFL++ engine strictly follows the differentiated test plan generated in step two, fundamentally eliminating testing of redundant processing functions. Simultaneously, the system utilizes lightweight instrumentation technology based on the QEMU pattern to collect the edge coverage of the current processing function in real time. Firmware vulnerabilities are recorded by monitoring program crashes and edge coverage growth, and the fuzzing task of the current processing function is adaptively terminated based on the edge coverage. Given that independent processing functions have a flatter control flow topology and a relatively limited state space compared to the entire service program, allowing for sufficient traversal of logical paths without the need for long-term time overhead, the system introduces a time window monitoring mechanism: once it is found that the current target processing function fails to trigger any new independent code branch boundaries within a preset time period (e.g., 5 consecutive minutes), its code exploration is deemed saturated, and the engine will immediately and adaptively trigger a termination signal.

[0036] Compared to existing technologies, the solution provided in this embodiment overcomes the limitations of traditional one-to-one analysis and achieves global redundancy testing optimization in batch homogeneous firmware scenarios. This invention performs comprehensive grouping and function difference extraction for batch homogeneous firmware, and introduces a large language model to conduct deep semantic evaluation of the extracted function differences, thereby generating differentiated test plans across firmware. This solution completely avoids the repetitive testing of identical or equivalent logic code within a large number of homogeneous firmware in traditional methods, filling the gap in existing technologies regarding the lack of global redundancy removal when facing complex many-to-many firmware groups, and significantly reducing the consumption and waste of computing resources.

[0037] By circumventing complex firmware remanagement dependencies, this invention achieves direct testing and full coverage of target processing functions: Employing a function-level fuzzing strategy, it accurately identifies and intercepts firmware input and processing functions, successfully bypassing cumbersome shallow execution paths such as pre-processing network protocol parsing, message verification, and authentication. Compared to traditional targeted fuzzing methods that still rely on the program's original entry point and attempt to guide the execution flow through lengthy pre-processing steps using heuristic algorithms to reach the target, this solution directly injects engine-supplied data into deep processing functions via low-level hooking technology. This not only eliminates the stringent requirement of building a complete system-level simulation environment but also ensures comprehensive analysis of all target processing functions, significantly improving the ability to discover high-risk vulnerabilities in the device's deep structure.

[0038] This invention improves the quality and mutation effectiveness of initial seeds, enhancing test coverage and vulnerability triggering capabilities: By combining symbolic execution and taint analysis techniques, it can automatically generate high-quality initial seeds that satisfy the internal constraints of the objective function and annotate key seed fields that are more likely to trigger vulnerabilities. These high-quality seeds enable the fuzzing engine to quickly satisfy constraints and cover a large number of code blocks in the early stages of execution; based on this, by implementing a focused mutation strategy on the annotated key fields, the vulnerability triggering capability for security-sensitive areas is significantly enhanced.

[0039] Based on the same inventive concept, this invention also provides a computer device, comprising: one or more processors, and a memory for storing one or more computer programs; the programs include program instructions, and the processor executes the program instructions stored in the memory. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, used to implement one or more instructions, specifically for loading and executing one or more instructions stored in a computer storage medium to implement the above-described method.

[0040] It should be further explained that, based on the same inventive concept, the present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, performs the above-described method. This storage medium can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0041] It should be noted that, unless otherwise defined, the technical or scientific terms used in this invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0042] This invention is not limited to the preferred embodiment described above. Anyone inspired by this invention can derive other forms of fuzz testing methods for IoT web services based on homology. All equivalent variations and modifications made within the scope of the claims of this invention should be included within the scope of this invention.

Claims

1. A fuzz testing method for IoT web services based on homology, characterized in that: Identify input functions and processing functions in web service programs from batches of different IoT firmware, wherein the input functions are used to parse and read user data from memory, and the processing functions are used to execute business logic in response to network requests; The batch of Web service programs are grouped into homogeneous groups. Within each homogeneous group, a cross-firmware homogeneous processing function difference analysis is performed on the processing function. The differences are semantically evaluated using a semantic reasoning engine or machine learning model to identify substantial functional differences and eliminate redundancy caused by non-substantial changes, thereby generating a differentiated test plan. For each target processing function in the differentiated test plan, symbolic execution and taint analysis are performed starting from the processing function to generate key-value pair structure test seeds decoupled from the network protocol, and the key fields in the test seeds that flow to dangerous functions or user-defined functions are marked. A fuzz test driver is constructed, which redirects the execution entry point of the Web service program to the target processing function through Hook technology, intercepts the processing function's call to the input function, directly provides the test seed to the processing function to perform function-level fuzz testing, and assigns higher mutation weights to key fields compared to non-key fields.

2. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for identifying the input function include: extracting shared keywords between the IoT firmware front-end page and the Web service program; filtering candidate input functions based on the call frequency of the shared keywords; performing multiple independent semantic analyses on each candidate input function using a large language model; and determining the final input function through a majority voting mechanism.

3. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for identifying processing functions include: detecting URL path registration functions in the Web service program and scanning the structured function table in the program data segment to extract the initial processing function list; filtering processing functions that have not called input functions based on the function call graph to obtain the final processing function.

4. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for grouping batch Web service programs by source and performing cross-firmware difference analysis include: using a binary code similarity comparison tool to cross-compare the batch Web service programs, clustering the batch Web service programs into multiple source firmware groups based on a preset similarity threshold; extracting the decompiled code difference data of each processing function within the source group, and globally unifying the source processing functions distributed in different firmwares through a disjoint-set data structure.

5. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The differences are semantically evaluated using a semantic reasoning engine or machine learning model. Specifically, the differences are evaluated using a large language model, including filtering out non-substantial changes caused by address offsets, variable renaming, compilation optimization, and log changes, and retaining only substantive functional differences involving business logic modifications or security verification changes.

6. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for generating a differentiated test plan include: based on the semantic evaluation results of the large language model, dividing the processing functions into unique, locally shared, globally shared, and modified types; selecting a single program instance for testing the unique, locally shared, and globally shared processing functions; and after dividing the modified processing functions into subgroups according to logical equivalence, selecting a single program instance from each subgroup for testing.

7. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for generating key-value pair structure test seeds decoupled from network protocols include: initializing the input values ​​read by the input function as symbolic values ​​carrying taint labels; during symbolic execution, when it is detected that symbolic values ​​flow to dangerous functions or user-defined functions, triggering the constraint solver to generate key-value pair structure test seeds that satisfy the current path constraints; when symbolic execution reaches the preset execution limit, extracting the symbolic states of execution paths of different lengths for constraint solving, and generating supplementary test seeds.

8. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for constructing and mounting a fuzz test driver include: redirecting the execution entry point of the web service program through Hook technology to restore the running context of the target processing function; intercepting the call of the processing function to the input function through inline Hook technology; monitoring command injection-like dangerous functions through Hook technology to capture vulnerability abnormal states; and mounting the driver to the web service program by modifying the dynamic dependency table of the target web service program. If mounting fails, a preloading mechanism is used to force mounting.

9. The fuzz testing method for IoT web services based on homology according to claim 1, characterized in that: The steps for performing function-level fuzz testing include: monitoring program crash status and edge coverage growth status; when the edge coverage does not increase within a preset time, adaptively terminating the fuzz testing task of the current target processing function.

10. A fuzz testing device for Internet of Things (IoT) web services based on homology, characterized in that, include: The function identification module is used to identify input functions and processing functions in web service programs from batches of different IoT firmware; The difference analysis module is used to group the batch of Web service programs into homogeneous groups, perform homogeneous processing function difference analysis across multiple firmwares, and use a semantic reasoning engine or machine learning model to perform semantic evaluation on the differences in order to identify substantial functional differences and eliminate redundancy caused by non-substantial changes, thereby generating a difference test plan. The seed generation module is used to perform symbolic execution and taint analysis starting from the target processing function, generate key-value pair structure test seeds that are decoupled from the network protocol, and mark the key fields in the test seeds that flow to dangerous functions or user-defined functions; The fuzzing execution module is used to construct a fuzzing driver program. It redirects the execution entry point of the Web service program to the target processing function through Hook technology, intercepts the processing function's call to the input function, directly provides the test seed to the processing function to perform function-level fuzzing, and assigns higher mutation weights to key fields compared to non-key fields.

Images