Internet of Things equipment command line targeting test method and system, terminal equipment and medium

Abstract

The invention discloses an Internet of Things equipment command line targeted testing method and system, terminal equipment and a medium, and relates to the technical field of Internet of Things equipment testing. The method comprises the following steps: analyzing firmware of Internet of Things equipment to obtain a structured function set; constructing a function call relation graph based on the set, and screening and positioning a high-value objective function through a preset weight calculation algorithm; extracting an execution path of the high-value objective function, and inputting a large language model to generate a command line test case; and executing the test case to obtain a test result. According to the method, the key function is targeted and positioned, and the effective use case is generated in combination with the large language model, so that the problems of high blindness and low efficiency of a traditional test are solved, the test targeting and the semantic effectiveness of the use case are improved, the test resource consumption is reduced, the test depth is remarkably improved, and the test safety and the result reliability are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of IoT device testing technology, and in particular to a command-line targeted testing method, system, terminal device, and medium for IoT devices. Background Technology

[0002] IoT devices have been widely used in industrial control, smart homes and other fields. Their firmware contains a large number of executable code segments and cross-process call relationships. Command line testing is a key means to ensure device security.

[0003] Existing technologies have several shortcomings: First, they rely on manual design of test cases, which is inefficient and makes it difficult to guarantee semantic validity, failing to meet the testing needs of complex firmware. Second, they lack targeted positioning of high-value core functions, resulting in blind test coverage, high resource consumption, and insufficient test depth. Third, they are not fully adapted to cross-process call scenarios, with some solutions directly executing tests on real devices, posing a risk of device damage. Fourth, they lack a dynamic optimization mechanism based on code coverage, making it difficult to accurately complete uncovered branches.

[0004] Therefore, there is an urgent need for a command-line testing method for IoT devices that can solve the problems of blind spots in path coverage, lack of semantic validity, and defects in resource adaptation, in order to fill the gaps in existing technologies. Summary of the Invention

[0005] The technical problem this invention aims to solve is that, in the field of IoT device testing, traditional methods suffer from core issues such as strong testing blindness, low semantic validity of test cases, insufficient testing efficiency and depth, and high risk of execution on real devices. Therefore, an effective solution is urgently needed to address these technical problems.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a command-line targeted testing method for Internet of Things (IoT) devices, applied to IoT devices, the method comprising: The firmware of the IoT device is parsed to obtain a set of structured functions; A function call graph is constructed based on the structured function set, and high-value target functions are selected and located through a preset weight calculation algorithm. Extract the execution path corresponding to the high-value objective function and input it into the large language model to generate command-line test cases; Execute the command-line test cases to obtain the test results.

[0007] In one implementation, parsing the firmware of the IoT device to obtain a set of structured functions includes: Based on the firmware of the IoT device, binary parsing is performed on the firmware to obtain the binary structure data of the firmware; Based on the binary structure data, extract the executable code segment and command-line interface-related entry functions from the firmware; The executable code segment and command-line interface related entry functions are integrated to obtain the structured function set.

[0008] In one implementation, constructing the function call graph based on the structured function set includes: Based on the structured function set, the cross-process call relationship between the executable code segments and command-line interface-related entry functions in the set is identified, and the cross-process call path is extracted; By using the executable code segment and command-line interface-related entry functions as function nodes and the cross-process call path as call edges, a cross-process function call relationship graph is constructed.

[0009] In one implementation, the step of constructing a cross-process function call graph by using the executable code segment and command-line interface-related entry functions as function nodes and the cross-process call path as call edges includes: Using lightweight disassembly and function flow analysis, the executable code segment and command-line interface-related entry functions are defined as function nodes, and the cross-process call paths are defined as call edges, thus constructing a cross-process function call relationship graph.

[0010] In one implementation, the step of filtering and locating high-value objective functions through a preset weight calculation algorithm includes: Based on the function call relationship graph, the weight value of each function node is calculated using the PageRank algorithm based on function call frequency; The weight values ​​are sorted from largest to smallest, and several quantitative functions are selected based on the sorting order to obtain the high-value objective function.

[0011] In one implementation, the damping factor of the PageRank algorithm is set to 0.85.

[0012] In one implementation, extracting the execution path corresponding to the high-value objective function and inputting it into a large language model to generate command-line test cases includes: Based on the high-value objective function, extract the execution path corresponding to the high-value objective function; The execution path is compressed and encoded to obtain path summary information; The path summary information and preset file format constraints are input into the large language model to generate command-line test cases.

[0013] In one implementation, the length of the compressed path digest information is less than 4096 tokens.

[0014] In one implementation, after compressing and encoding the execution path to obtain path digest information, the method further includes: The path summary information is pruned in instruction space to obtain optimized path summary information.

[0015] In one implementation, the step of inputting the path summary information and preset file format constraints into the large language model to generate command-line test cases includes: Based on the path summary information and file format constraints of the input large language model, semantically valid command-line interface combinations and file tool commands are generated; By integrating the command-line interface combination and file tool commands, the command-line test cases are obtained.

[0016] In one implementation, the temperature parameter in the generation strategy of the large language model is set to 0.

[0017] In one implementation, executing the command-line test case and obtaining the test result includes: Execute the command-line test cases in an instruction-level simulated sandbox environment; Real-time monitoring of code coverage and vulnerability triggering status during the testing process; The test results are obtained based on the vulnerability triggering state.

[0018] In one implementation, the instruction-level simulation sandbox environment is a device instruction-level simulation environment based on QEMU extensions, which supports the simulated execution of device instructions.

[0019] In one implementation, obtaining the test result based on the vulnerability triggering state includes: Based on the vulnerability triggering state, the command-line vulnerability feature library is invoked for vulnerability matching. The vulnerability feature library includes option combination features, file format attack surface features, and built-in industrial protocol instruction set features. Based on the matching results, vulnerability information triggered by a combination of structured storage options or a combination of files, wherein the vulnerability information includes the vulnerability type and vulnerability triggering conditions; The vulnerability information is integrated from the structured storage to generate a test result report containing the vulnerability information, thus obtaining the test results.

[0020] In one implementation, the real-time monitoring of code coverage during the testing process includes: Analyze the monitoring results of the code coverage; When the code coverage of the high-value objective function falls below a preset threshold, the system automatically switches to the next high-value objective function and dynamically adjusts the objective function weight and test case generation strategy.

[0021] In one implementation, the dynamic adjustment of the objective function weights and test case generation strategy includes: A branch heatmap is generated based on the code coverage, visually presenting the branch coverage distribution and the location of uncovered branches for the current high-value objective function; Based on the uncovered branch locations fed back by the branch heatmap, the weights of the current objective function are adjusted through dynamic weight migration; Based on the adjusted objective function weights and the execution path characteristics of the new test objectives, optimize the test case generation strategy.

[0022] Secondly, embodiments of the present invention also provide a command-line targeted testing system for IoT devices, applied to IoT devices, the system comprising: The device firmware input module is used to parse the firmware of the IoT device to obtain a set of structured functions; The meta-guide kernel processing module is used to construct a function call relationship graph based on the structured function set, and to filter and locate high-value target functions through a preset weight calculation algorithm; The path extraction and test case generation module is used to extract the execution path corresponding to the high-value objective function and input it into the large language model to generate command-line test cases. The test execution module is used to execute the command-line test cases and obtain the test results.

[0023] Thirdly, embodiments of the present invention also provide a terminal device, the terminal device including a memory, a processor, and an IoT device command-line targeted test program stored in the memory and executable on the processor, wherein when the processor executes the IoT device command-line targeted test program, it implements the steps of the IoT device command-line targeted test method described in any of the above schemes.

[0024] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing an IoT device command-line targeted testing program, wherein when the IoT device command-line targeted testing program is executed by a processor, it implements the steps of the IoT device command-line targeted testing method described in any of the above schemes.

[0025] Beneficial Effects: This invention discloses a command-line targeted testing method, system, terminal device, and medium for IoT devices, relating to the field of IoT device testing technology. The method first parses the firmware of the IoT device to obtain a structured function set. Then, a function call relationship graph is constructed based on the structured function set, and high-value target functions are selected and located using a preset weight calculation algorithm. Next, the execution paths corresponding to the high-value target functions are extracted and input into a large language model to generate command-line test cases. Finally, the command-line test cases are executed to obtain test results. Compared with existing technologies, this invention avoids blind testing and significantly reduces resource consumption by using structured firmware parsing and targeted selection of high-value functions. Furthermore, it utilizes a large language model to generate semantically valid test cases, improving testing efficiency, accuracy, and depth, and ensuring the comprehensiveness of vulnerability discovery and the reliability of results. Attached Figure Description

[0026] Figure 1 A flowchart illustrating a specific implementation of the command-line targeted testing method for IoT devices provided in this embodiment of the invention.

[0027] Figure 2 This is a flowchart illustrating a specific implementation of the command-line targeted testing method for IoT devices provided in this embodiment of the invention.

[0028] Figure 3 This is a business integration diagram illustrating a specific implementation of the command-line targeted testing method for IoT devices provided in this embodiment of the invention.

[0029] Figure 4 A schematic diagram of the business process of the command-line targeted testing method for IoT devices provided in an embodiment of the present invention.

[0030] Figure 5 This is a schematic diagram of the IoT device command-line targeted testing device provided in an embodiment of the present invention.

[0031] Figure 6 This is a block diagram illustrating the internal structure of the terminal device provided in an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0033] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0034] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0035] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, "first control information" and "second control information" are only used to distinguish different control information and do not limit their order.

[0036] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0037] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0038] The Internet of Things (IoT) has been deeply applied in key areas such as industrial control, vehicle networking, and smart cities, encompassing various devices including production line programmable logic controllers (PLCs), smart meters, battery management systems (BMS) for new energy vehicles (ECUs), road monitoring cameras, and smart streetlights. The firmware of these devices contains numerous command-line interface (CLI) related entry functions and complex cross-process call relationships. For example, the security of high-risk command-line operations such as industrial equipment firmware upgrades (ota_update -f), protocol configuration (modbus_set_parm), vehicle networking ECU diagnostic interface commands (can_bus --inject=0x7DF), and smart city terminal remote maintenance commands (config_rtsp -p 554) directly impacts equipment operational stability and data security. Therefore, CLI testing has become a primary technical means for pre-production safety certification and in-operation safety auditing of equipment.

[0039] Current CLI testing technology for IoT devices faces numerous technical shortcomings in practical applications, making it difficult to meet the actual needs of industrial IoT device security certification, vehicle ECU security auditing, smart city terminal protection, and security enhancement for equipment manufacturers. Specific technical issues are as follows: Firstly, there are blind spots in path coverage, resulting in severely insufficient testing depth. Traditional fuzzing in IoT firmware can only reach an average call depth of 1.2 layers, failing to detect deep nested cross-process function chain vulnerabilities such as main()→parse_args()→hevc_parse_nal(). This makes it difficult for mandatory penetration testing before mass production of industrial equipment to cover core function chains of high-risk operations such as ota_update -f and modbus_set_parm. CAN instruction injection vulnerabilities in vehicle-to-everything (V2X) ECUs cannot be accurately discovered, such as vulnerabilities like Common Vulnerabilities and Exposures (CVE)-2023-48795, significantly impacting the effectiveness of device security authentication.

[0040] Secondly, the lack of semantic validity leads to low testing efficiency. In the FFmpeg test data, only 14% of randomly generated test cases passed CLI syntax validation, with the vast majority being blocked by the basic parser. FFmpeg is an open-source, cross-platform multimedia processing library and command-line tool. In scenarios such as industrial equipment protocol configuration and remote maintenance command testing for smart city terminals, a large number of invalid test cases result in excessively long test times, failing to meet the efficiency requirements of 24 / 7 operation of municipal facilities. Generally, a single complete test should take less than seven hours.

[0041] Thirdly, there are resource adaptation defects and poor compatibility. Industrial IoT devices and vehicle ECUs generally lack symbol tables or debugging information. Existing dynamic analysis tools consume excessive memory (>128MB), far exceeding the available memory of the device (<16MB), causing the testing tools to be unable to run on the target device. This makes it difficult to meet the needs of equipment manufacturers to integrate the testing tools into the safety management platform and provide automated testing services for partner manufacturers.

[0042] Fourth, there are security risks in test execution. Existing technologies often execute test cases directly on real devices. If a test case triggers a vulnerability, it can easily lead to serious consequences such as production line interruptions in industrial equipment and abnormal operation of vehicle-to-everything (V2X) ECUs. Furthermore, some simulation execution environments lack the ability to accurately simulate mainstream instruction sets of IoT devices such as ARM (Advanced RISC Machines) Cortex-M / R, failing to reproduce real-world operating scenarios and affecting the reliability of test results.

[0043] Fifth, the testing process lacks a dynamic optimization mechanism. During test execution, code coverage monitoring relies primarily on static data feedback, failing to visualize branch coverage distribution and uncovered bottlenecks, and lacking a dynamic adjustment strategy based on coverage data. When high-value target function coverage falls short of expectations, it's impossible to promptly switch test targets, adjust function weights, and modify test case generation strategies, leading to wasted testing resources and hindering in-depth vulnerability discovery.

[0044] Sixth, vulnerability handling and output are not standardized. There is a lack of a unified vulnerability signature library that includes option combination characteristics, file format attack surface characteristics, and industrial protocol instruction set characteristics such as Modbus and CAN. Vulnerability matching lacks standardized basis. Furthermore, vulnerability information is stored in a chaotic manner, making it impossible to clearly identify key information such as vulnerability type and triggering conditions. The output test result reports are difficult to directly integrate with equipment security certification processes, resulting in lengthy industrial equipment access certification cycles. Traditional technologies require 14 days, which cannot meet manufacturers' needs for quickly obtaining vulnerability remediation solutions such as CLI parameter boundary check patches.

[0045] Therefore, there is an urgent need for a complete technical solution to systematically address the multiple shortcomings of existing technologies in CLI testing of IoT devices in various scenarios, improve the depth, efficiency, security and reliability of testing, and meet the actual needs of device security certification, audit protection and industrial applications.

[0046] Figure 2 This invention demonstrates the workflow and business integration logic of the command-line targeted testing method for IoT devices, starting with the IoT device firmware and unfolding around the meta-guide kernel processing layer. The meta-guide kernel processing layer is the core processing logic based on function call graphs and weighting algorithms to select high-value target functions. This layer includes processing modules such as static path extraction, LLM targeted guidance, and sandboxed execution verification. Through function call graph analysis to locate high-weight targets, context compression to optimize input, iterative LLM inference to generate test cases, and coverage-driven optimization of testing strategies, the entire chain of collaborative testing achieves accurate testing. Simultaneously, Figure 2 The exhibition also showcased business integration points, covering three application scenarios: security authentication, CLI protection for industrial equipment, and vehicle-to-everything (V2X) instruction set auditing. The technical solutions are deeply integrated with actual business operations, highlighting the integrated logic of targeted testing, vulnerability discovery, and security protection.

[0047] Figure 3This paper demonstrates the business implementation architecture of this invention, which uses a security middleware platform as the core hub to build a three-way collaborative system involving OEM device manufacturers, the security middleware platform, and endpoint security. After OEM device manufacturers submit unhardened firmware, the middleware platform completes targeted testing and vulnerability discovery through the meta-guided testing engine and open trusted execution environment. The technology stack provides support such as hardening solutions, OTA management platforms, and OS security enhancement modules, achieving full-process coverage from testing to remediation. The diagram clearly shows the composition of the technology stack and the data flow of each stage, reflecting the lossless adaptability of the architecture, supporting 90% of cooperative devices, and the test results can be directly connected to the security certification process, highlighting the closed-loop business design of testing, hardening, and deployment.

[0048] Figure 4 The demonstration showcased the business interaction process, including the collaborative logic among the three parties. Specifically, the device manufacturer submits unhardened firmware to the platform. The platform then uses its meta-testing engine to target and discover vulnerabilities, automatically generating CVE patches. Simultaneously, the platform pushes OS-level security updates to the endpoint security server, achieving OTA deployment within minutes. Finally, the device manufacturer receives the hardening solution and completes firmware security enhancement. The entire process forms a closed loop of submission, testing, repair, and deployment, eliminating redundant manual steps, highlighting cost reduction and efficiency improvements, and addressing the pain points of long traditional certification cycles and cumbersome deployments. It intuitively demonstrates the value of automated and efficient business implementation.

[0049] This embodiment provides a command-line targeted testing method for IoT devices, such as... Figure 1 As shown, the specific steps include the following: Step S100: Parse the firmware of the IoT device to obtain a set of structured functions.

[0050] In this embodiment, the firmware of an IoT device is the software carrier for the device's operation. It integrates the executable code, configuration data, drivers, and command-line interaction logic required for the device's normal operation. It is commonly found in devices such as industrial programmable logic controllers, vehicle-to-everything (V2X) electronic control units, and smart city surveillance cameras. Examples include the control firmware of a new energy vehicle battery management system and the metering control firmware of a smart meter. The process of parsing the firmware can involve in-depth binary-level analysis. This involves using techniques such as disassembly, data segment separation, and instruction sequence recognition to disassemble the firmware's internal structure and obtain binary structure data. The structured function set is a collection of the parsed executable code segments and command-line interface-related entry functions, organized according to a unified data format and classification rules. The executable code segments contain instruction sequences that implement the device's core functions, while the command-line interface-related entry functions are the starting functions for the device to receive, parse, and execute command-line instructions, such as the entry function corresponding to the firmware upgrade instruction `ota_update` and the processing function for the protocol configuration instruction `modbus_set_parm`.

[0051] Traditional firmware parsing can only extract scattered functions or data fragments, lacking a unified structure that results in unreliable data for subsequent call relationship analysis. This embodiment precisely separates the executable code segment and command-line interface-related entry functions through binary parsing, then integrates them into a structured set. This ensures the integrity of function information and provides a standardized data foundation for subsequent cross-process call relationship identification and function call relationship graph construction. The structured processing method effectively avoids omissions in call path extraction due to data chaos, enabling the subsequent selection of high-value target functions based on comprehensive and accurate function information. This prevents missing key test targets due to missing function information, thus providing a prerequisite for improving test depth and vulnerability detection rate.

[0052] In practical applications, this parsing method successfully extracted the complete entry function and associated executable code segment of the config_rtsp remote maintenance command for the firmware of road monitoring cameras using HiSilicon chips and the OpenHarmony system, providing accurate function basis for the generation of subsequent test cases.

[0053] In one implementation, parsing the firmware of the IoT device to obtain a set of structured functions specifically includes the following steps: Step S110: Based on the firmware of the IoT device, perform binary parsing on the firmware to obtain the binary structure data of the firmware; Step S120: Based on the binary structure data, extract the executable code segment and command-line interface related entry functions from the firmware; Step S130: Integrate the executable code segment and the command-line interface related entry functions to obtain the structured function set.

[0054] In this embodiment, the mathematical logic for binary parsing based on the firmware of an IoT device can be expressed as follows:

[0055] in This represents the raw binary data of the firmware, encompassing all byte information in the firmware file, including the file header, code segment, data segment, configuration information, etc. This represents the structured function set obtained after parsing, which forms the core data foundation for subsequent analysis. Binary parsing technology reads... The byte sequence is analyzed to identify its internal structural features, separate executable instructions from non-executable data, and finally obtain binary structure data containing function information. The process does not rely on the firmware's source code or debugging information. Even though industrial equipment firmware generally lacks symbol tables and debugging information, it can accurately decompose the firmware structure through instruction sequence features and data offset patterns, thus solving the problem of poor adaptability caused by the reliance on symbol tables in traditional parsing methods.

[0056] When extracting executable code segments and command-line interface-related entry functions based on binary structure data, the extraction of executable code segments follows mathematical logic, and the expression is:

[0057] in, Indicates the first An executable code segment, It is a conditional function Is it a boolean function that is executable code? This function returns true when it contains consecutive machine instructions with a fixed instruction length and opcode characteristics. By traversing the instruction sequence in the binary structure data and combining it with the instruction feature libraries of architectures such as ARM and MIPS, all instructions can be accurately separated. This excludes non-execution parts such as data segments and configuration segments. Identification of command-line interface entry functions is achieved by analyzing the function's parameter characteristics, calling scenarios, and interaction logic. These functions typically receive string-type command-line arguments and include logic for command parsing, parameter validation, and function execution. For example, a function that receives the `ota_update -f` command has a filename path as its argument and is associated with a firmware upgrade module call. These characteristics allow for identification... The target entry function is selected from the data.

[0058] The executable code segment and command-line interface-related entry functions are integrated to form a structured function set. At the same time, uniform classification and storage rules are followed. First, they are classified according to the functional modules of the functions. The modules are categorized, such as firmware upgrade modules, protocol configuration modules, and remote maintenance modules; then, the command-line interface entry functions are associated with their corresponding functional modules, clarifying the corresponding entry function. Scope; finally, a standardized data structure is used to store function information, including fields such as function name (if identifiable), entry address, parameter types, return value type, associated code segment, and function description, to ensure... The standardization and usability.

[0059] The mathematical logic described above ensures the accuracy of executable code segment and entry function extraction, overcoming the shortcomings of traditional firmware parsing, which is unstructured and relies on symbol tables. Industrial equipment firmware commonly lacks symbol tables and debugging information; existing dynamic analysis tools often fail to accurately parse the firmware structure, resulting in incomplete function extraction. This step, however, utilizes binary parsing and feature recognition technology to accurately extract functions without requiring a symbol table. The command-line interface-related entry functions are compatible with over 90% of IoT device firmware. This integration forms... This provides a standardized and complete data foundation for the subsequent construction of cross-process function call relationship graphs, avoiding omissions in call relationship identification due to chaotic function information and ensuring the accuracy of subsequent high-value target function selection. In smart meter firmware parsing tests, this step successfully extracted the entry function and complete... No functions were omitted or misjudged, verifying the reliability of the parsing method.

[0060] Step S200: Construct a function call relationship graph based on the structured function set, and filter and locate high-value target functions through a preset weight calculation algorithm.

[0061] In this embodiment, the function call graph is a graphical representation of the call relationships between functions in a structured function set. Function nodes represent executable code segments or command-line interface-related entry functions in the structured set, while call edges represent call behaviors between functions, including intra-process calls and cross-process calls. A preset weight calculation algorithm is a mathematical method used to quantify the importance of each function node. This embodiment can employ ranking algorithms such as PageRank based on function call frequency. The ranking algorithm is used for sorting; after adaptation, it calculates the weight value of each function node based on the number of calls, call depth, and dependencies between functions. A higher weight value indicates a greater core position and wider influence of the function in the device firmware. High-value target functions refer to functions with high weight ranking, crucial to the secure operation of the device, high call frequency, and potential high-risk vulnerabilities, such as the extract_hvcc_hevc function in FFmpeg and core processing functions in the firmware upgrade process.

[0062] When constructing the function call graph, the call relationships between functions, especially cross-process call relationships, are first identified based on the function information in the structured function set. Then, a complete call graph is constructed using functions as nodes and call relationships as edges. When selecting high-value target functions, a weighted algorithm is used to calculate the weight value of each function node. Subsequently, all function nodes are sorted from largest to smallest weight value, and the top few functions are selected as high-value target functions based on testing requirements.

[0063] Introducing a weighting algorithm into function importance assessment solves the problem of blindness caused by random selection or manual specification of target functions in traditional testing. Traditional fuzz testing, lacking a scientific target selection mechanism, consumes a large amount of resources on low-value functions, resulting in insufficient coverage of core functions and an average test depth of only 1.2 call layers. This embodiment comprehensively presents call relationships through a function call graph and accurately locates high-value target functions using a weighting algorithm, enabling test resources to be concentrated on testing critical functions and effectively improving the targeting of tests. Actual test data shows that for FFmpeg firmware, high-value target functions selected using this method increased the average test depth from the traditional 1.2 layers to 11.3 layers, successfully exposing deeply nested cross-process function chain vulnerabilities, demonstrating a significant effect in improving test depth and vulnerability detection rate.

[0064] In one implementation, constructing the function call graph based on the structured function set specifically includes the following steps: Step S210: Based on the structured function set, identify the cross-process call relationship between the executable code segment and the command-line interface related entry function in the set, and extract the cross-process call path; Step S220: Construct a cross-process function call relationship graph by taking the executable code segment and command line interface related entry functions as function nodes and the cross-process call path as call edges.

[0065] In this embodiment, based on a set of structured functions Identifying cross-process call relationships and constructing a function call graph involves mathematical logic for modeling cross-process calls, expressed as follows:

[0066] in Let be the vertex set, defined as:

[0067] Right now All executable code segments and command-line interface-related entry functions are treated as independent function nodes.

[0068] Let be an edge set, defined as:

[0069] That is, when the function There is a function call When doing this, This constitutes a call edge. If the call occurs between different processes, it is a cross-process call edge.

[0070] When identifying cross-process call relationships, each function node is first determined by its process ID, memory address space, and resource usage characteristics. The process to which it belongs; then analyze the function call instructions and parameter passing paths. If a function call instruction contains indicators of cross-process communication, such as inter-process communication interface calls, shared memory access instructions, or parameter passing involving the memory address spaces of different processes, then it is determined to be a cross-process call, and the corresponding call path... This allows for cross-process call edges, thereby extracting the complete cross-process call path.

[0071] When constructing a cross-process function call graph, with The functions in the code are used as nodes, and each node contains core information such as function name, process affiliation, and entry address; the extracted cross-process call paths correspond to... As a call edge, the edge's attributes include the cross-process call type, call frequency, parameter passing method, etc. During the construction process, a graphical modeling tool is used to group and arrange function nodes according to process affiliation, clearly presenting the call relationships between different processes. At the same time, key information of each call edge is labeled, so that the function call relationship graph can intuitively and completely reflect the overall picture of all cross-process function calls.

[0072] Through the aforementioned mathematical modeling, the function call network of IoT device firmware was defined. Traditional testing methods cannot identify cross-process call relationships, resulting in the failure to detect cross-process function chain vulnerabilities. However, this step, by accurately identifying cross-process call relationships, extracting complete call paths, and constructing a function call relationship graph, provides comprehensive call association evidence for subsequent high-value target function screening and execution path extraction, enabling testing to cover cross-process function chains and improving testing depth. In the testing of vehicle-to-everything (V2X) electronic control units, the call relationship between the CAN bus control process and the OTA upgrade process was successfully identified through the function call relationship graph, providing path support for the subsequent reproduction of CAN instruction injection vulnerabilities such as CVE-2023-48795.

[0073] In one implementation, the step of constructing a cross-process function call graph by using the executable code segment and command-line interface-related entry functions as function nodes and the cross-process call path as call edges specifically includes the following steps: Step S221: Using lightweight disassembly and function flow analysis, define the executable code segment and command line interface related entry functions as function nodes, define the cross-process call path as call edges, and construct a cross-process function call relationship graph.

[0074] In this embodiment, lightweight disassembly is a disassembly technique optimized for the resource-constrained characteristics of IoT devices. Compared with traditional heavyweight disassembly tools, it has advantages such as low memory consumption, high execution efficiency, and compatibility with embedded device firmware. Its principle is to simplify the disassembly process and optimize the instruction recognition algorithm, reducing resource consumption while ensuring disassembly accuracy. It can run normally even when the available memory on the device is less than 16MB, solving the over-limit and compatibility issues caused by the memory consumption exceeding 128MB in existing dynamic analysis tools. During lightweight disassembly, only the structured function set is targeted. Core executable segment The disassembly process skips redundant data and configuration segments and employs an efficient instruction caching mechanism to reduce repetitive parsing operations and improve disassembly efficiency.

[0075] Function flow analysis is a technique for tracing the execution flow of functions and identifying call relationships between functions. By analyzing the instruction sequence obtained from disassembly, it identifies function call instructions, return instructions, and parameter passing instructions, thereby constructing the function's execution flowchart. Function flow analysis can identify direct call relationships and, through techniques such as branch prediction and conditional jump analysis, can identify indirect and conditional call relationships, ensuring comprehensive call relationship identification. For example, if a function indirectly calls another function by passing the call address through a register, function flow analysis can identify the target calling function by tracing changes in the register values. This further supplements the edge set in the cross-process function call relationship graph.

[0076] When constructing a cross-process function call graph using lightweight disassembly and function flow analysis, the first step is to perform lightweight disassembly... Disassembling the code yields information such as the instruction sequence, function entry addresses, and parameter passing methods; then, function flow analysis traces each function node. The execution flow is analyzed, identifying intra-process and cross-process call relationships, and supplementing / improving [the system / mechanism]. The call edges in the graph are used to extract the complete call path; finally, based on the definition of the function call graph, the attribute information of the nodes and edges is clarified to construct a complete and accurate cross-process function call graph.

[0077] The low resource consumption of lightweight disassemblers makes this method suitable for resource-constrained scenarios such as industrial IoT devices and vehicle-to-everything (V2X) electronic control units, solving the problem that traditional disassemblers cannot run on embedded devices. Function flow analysis technology ensures accurate identification of cross-process call relationships and indirect call relationships, avoiding incomplete function call graphs due to omissions in call relationships.

[0078] In one implementation, the step of filtering and locating high-value objective functions through a preset weight calculation algorithm specifically includes the following steps: Step S230: Based on the function call relationship graph, calculate the weight value of each function node using the PageRank algorithm based on function call frequency; Step S240: Sort the weight values ​​from largest to smallest, and filter several quantitative functions based on the sorting order to obtain the high-value objective function.

[0079] In this embodiment, the weight value of each function node is calculated using the PageRank algorithm based on the function call graph. This process quantifies the importance of functions, and its mathematical expression is as follows:

[0080] in, Represents function nodes The weight value is used to measure The degree of coreness in the network call; It is the damping factor; The total number of functions, i.e., the set of structured functions. The total number of functions included; Indicates all calls The set of predecessor functions, that is, directly pointing to The set of function nodes; Represents the predecessor function node The out-degree, that is The total number of other functions called.

[0081] The core idea of ​​the PageRank algorithm is that nodes referenced by important nodes also have high importance, analogous to webpage link relationships in terms of function call relationships. The bigger, The smaller, right The greater the weight contribution, the better. In the function call scenario of IoT device firmware, this algorithm can effectively reflect the coreness and influence of a function in the entire call network. For example, firmware upgrade processing functions that are frequently called by multiple core functions will receive higher weights. .

[0082] During the calculation, the weights of all function nodes are first initialized, with all functions initially assigned the same importance. Then, the PageRank algorithm formula is iteratively executed until the weights converge. Finally, the final weights for each function node are obtained. .right After sorting from largest to smallest, a certain number of functions are selected as high-value objective functions based on the sorting order. The number of functions selected can be flexibly set according to the testing requirements, for example, selecting... The top 20% of functions, or Functions with a value greater than 0.7 are selected to ensure that all selected functions call the core functions in the network.

[0083] pass This calculation avoids the subjectivity and blindness of manually specifying or randomly selecting target functions in traditional testing. Traditional testing methods, lacking an effective function importance assessment mechanism, often consume a large amount of testing resources on low-value functions, resulting in insufficient test coverage of core functions and a low vulnerability detection rate. This embodiment comprehensively presents call relationships through a function call graph and accurately calculates them using the PageRank algorithm. This method can accurately identify high-value objective functions that are crucial to the safe operation of equipment, allowing testing resources to be focused on testing critical functions, thus improving the targeting and efficiency of testing. In FFmpeg firmware testing, the vulnerability detection rate of high-value objective functions selected using this method is 4.2 times higher than that of existing screening methods, verifying the effectiveness of this weight calculation and screening method.

[0084] In one implementation, the damping factor of the PageRank algorithm is set to 0.85.

[0085] In this embodiment, based on the function call characteristics of IoT device firmware and experimental verification results, the damping factor in the PageRank algorithm is... Set it to 0.85 to ensure Accuracy of calculation. The role of the damping factor is to simulate random jump behavior during function calls, that is, the probability that a function may not jump according to the predetermined call relationship during execution, but instead randomly call other functions. In web page ranking scenarios, this factor simulates the behavior of users randomly clicking on web pages; in function call scenarios, this factor simulates the randomness of function call jumps caused by abnormal handling, interruption response, etc. during device operation.

[0086] like If the value is too high, then Over-reliance The call relationships within the function lack consideration for random jump behavior, which may lead to some functions referenced by a small number of core functions having excessively high weights, while the weights of other potentially important functions are underestimated; if If the value is too low, the impact of random redirection will be too great. The discriminatory power decreases, and it cannot effectively reflect the function's performance. The core nature of the objective function leads to inaccurate selection of high-value objective functions.

[0087] The setting of the damping factor ensures the applicability and accuracy of the PageRank algorithm in calculating function weights for IoT devices, providing key parameter support for the accurate selection of high-value objective functions, avoiding selection bias caused by inappropriate parameters, and thus improving the targeting of tests and the vulnerability detection rate. At the same time, this value has strong universality, achieving good results in different types of IoT device firmware without requiring individual adjustments for each device, thus improving the practicality and adaptability of the method.

[0088] Step S300: Extract the execution path corresponding to the high-value objective function and input it into the large language model to generate command-line test cases.

[0089] In this embodiment, the execution path corresponding to a high-value objective function refers to the complete instruction flow and function call chain from the function's invocation to its completion. This includes all sub-functions, instruction sequences, and data interaction logic involved in the function's execution. For example, the call chain `main()→parse_args()→hevc_parse_nal()` is the execution path of a high-value objective function. For the execution path, compression encoding can be used to simplify and encode the lengthy execution path information. By removing redundant instructions, merging duplicate links, and using efficient encoding formats, the path information is compressed into path summary information. The path summary information is compressed data of the execution path, retaining the key nodes of the function call and the execution logic, avoiding a decrease in the processing efficiency of large language models or the omission of key information due to information redundancy.

[0090] Large language models are artificial intelligence models with natural language understanding and logic generation capabilities. Command-line test cases are sets of test instructions composed of command-line interfaces and file utility commands, which can be recognized and executed by the command-line interfaces of IoT devices. For example, `ffmpeg -i test.h265 -c:v hevc -f rtp` is a valid test case generated for audio and video processing functions.

[0091] When extracting execution paths, the complete execution flow of high-value target functions is traced based on the function call graph to ensure the integrity of path information. After compression encoding, instruction space pruning can be performed according to test requirements to further remove instruction information irrelevant to the test objective from the path summary, thus optimizing the summary quality. After inputting the path summary information and file format constraints into the large language model, the model generates semantically valid command-line interface combinations and file tool commands based on the execution logic and constraints in the path summary, and then integrates them to form the final command-line test cases.

[0092] By combining path compression coding with targeted guidance from a large language model, this method solves the problems of low efficiency and poor semantic validity in traditional test case generation. Only 14% of traditionally randomly generated test cases pass command-line syntax validation, resulting in a large number of invalid test cases that lead to wasted testing resources and low efficiency. This embodiment ensures that path information is compatible with the processing capabilities of the large language model through compression coding, and guides the model to generate test cases that conform to the device interaction logic based on file format constraints. This increases the proportion of effective test cases to 89% while reducing resource consumption by 76%. In the testing of vehicle-to-everything (V2X) electronic control units, test cases generated using this method successfully reproduced the CAN instruction injection vulnerability for the high-value function corresponding to the `can_bus --inject=0x7DF` diagnostic interface command, verifying the accuracy and effectiveness of the test case generation.

[0093] In one implementation, extracting the execution path corresponding to the high-value objective function and inputting it into a large language model to generate command-line test cases specifically includes the following steps: Step S310: Based on the high-value objective function, extract the execution path corresponding to the high-value objective function; Step S320: Compress and encode the execution path to obtain path summary information; Step S330: Input the path summary information and the preset file format constraints into the large language model to generate command line test cases.

[0094] In this embodiment, the preset file format constraints are a set of rules based on common file interaction formats of IoT devices, including Modbus protocol data format commonly used in industrial control, H265 file format in audio and video processing, CAN command data format in vehicle networking, etc., which are used to constrain the test cases generated by the large language model to adapt to the file processing logic of the device.

[0095] Based on the extraction of corresponding execution paths from high-value objective functions, and according to the function call relationship graph and function flow analysis results, the mathematical logic is path filtering, expressed as:

[0096] in, This indicates the execution path of the extracted high-value objective function. Indicates from the entry function To the objective function The set of all possible paths, Representing a path All function nodes The sum of Operations are used to filter out The path with the largest sum, i.e., the execution path with the most concentrated core call chain, ensures that the extracted... This is the most valuable path for testing. Execution path Is the function from Called to The complete execution process includes all involved sub-functions, instruction sequences, parameter passing procedures, and branch jump logic, for example... When it is extract_hvcc_hevc, It could be main()→parse_args()→decode_h265→extract_hvcc_hevc.

[0097] right The purpose of compression encoding is to adapt to the context window limitations of large language models. Its mathematical logic is path compression encoding, and the expression is:

[0098] in, This represents the compressed path summary information. This represents the upper limit of the context window for the large language model. In this embodiment, There are 4096 tokens. Functions represent the application of specific rules to... Perform simplification and encoding conversion. Typically containing a large number of redundant instructions and repetitive links, directly inputting them into a large language model can lead to information overload. Compression is achieved through three methods: removal and... Redundant instructions unrelated to core functions, such as local variable assignments and simple logical judgment instructions; merge duplicate call chains and use simplified identifiers to represent duplicate parts; adopt a token-based encoding method to convert commonly used function names and instruction types into short tokens to reduce character length.

[0099] Will When inputting the large language model along with preset file format constraints to generate command-line test cases, the mathematical logic is constructed using contextual hints, and the expression is:

[0100] in, This represents the input context of a large language model. For concatenation functions, The expression is:

[0101] It represents a set of file format constraints, including rules for industrial protocol data formats such as Modbus protocol RTU format, audio and video file formats such as H265 or RTP format, and configuration file formats such as XML or JSON format. It can guide the large language model to generate test cases that conform to the device file processing logic, avoiding the generation of invalid test cases that cannot be parsed by the device. The large language model receives... Then, based on its trained command-line syntax knowledge and logic generation capabilities, test cases containing command-line interface combinations and file tool commands are generated to ensure the semantic validity and syntactic correctness of the test cases.

[0102] pass Select the most valuable execution path, through Ensure that path information is adapted to the model's processing capabilities, through Constructing a complete input context solves the problem of low semantic effectiveness in traditional randomly generated test cases. In FFmpeg firmware testing, test cases generated through this step have a semantic effectiveness rate increased from 14% to 89% compared to traditional methods, and can accurately cover... The key branches in the process provide high-quality test cases for subsequent vulnerability detection.

[0103] In one implementation, the length of the compressed path digest information is less than 4096 tokens.

[0104] In this embodiment, the compressed and encoded path digest information The length is less than 4096 tokens. This length limit is based on the context window characteristics of large language models and The actual length is determined based on This setting specifies 4096 tokens. Tokens are the basic units for text processing in large language models. One token typically corresponds to 1-4 characters. The maximum context window size for mainstream large language models is 4096 tokens. If the length exceeds this limit, the model will be unable to receive and process it completely. This can lead to omissions in critical call logic or broken logic in generated test cases.

[0105] The technical effect of this length limit is to ensure... It can be fully processed by large language models without losing core logic, providing accurate path basis for test case generation. If the length exceeds 4096 tokens, the large language model will truncate the excess portion, resulting in subsequent test case generation lacking critical path information and failing to cover core branches; however, when the length is kept within 4096 tokens, the model can fully understand the code. The logic generates test cases that can accurately match... The key link.

[0106] In one implementation, after compressing and encoding the execution path to obtain path digest information, the method further includes the following steps: Step S321: Perform instruction space pruning on the path summary information to obtain optimized path summary information.

[0107] In this embodiment, for Compressed encoding process is performed to obtain The purpose of subsequent instruction space pruning is to further optimize. The quality of instruction space pruning is improved by removing redundant, repetitive, or irrelevant instructions, highlighting the calling logic and key branches, and enhancing the accuracy of test cases generated by the large language model. Instruction space pruning is based on the test objective and... The core function, for The instructions in the code are filtered and optimized to ensure that the retained information can accurately guide the model to generate specific targets. Test cases for the core logic.

[0108] The specific implementation of instruction space pruning includes three dimensions: first, pruning of function-independent instructions, identifying... Zhongyu Remove and delete instructions that are irrelevant to core functionality, such as error handling instructions, log printing instructions, and non-critical parameter validation instructions during function execution. These instructions do not affect the core functionality. The core logic and vulnerability triggers, once removed, can reduce the model's processing burden; secondly, duplicate instructions are merged. The system first identifies consecutive repetitive instruction sequences or identical branches, then merges them using simplified identifiers to avoid information redundancy; thirdly, it prunes low-value branches to filter out... middle Lower branch paths and simplify them, focusing on preserving complete information about high-value branches.

[0109] Do not damage during pruning Ensure the integrity of the core logic after pruning It can still accurately reflect The execution flow and key call relationships are clearly defined, without omitting any critical instructions related to vulnerability triggering, and the code is adapted to the understanding capabilities of large language models, with pruned branches. A clear logical structure must be maintained to avoid the model being unable to understand the path logic due to excessive pruning.

[0110] After pruning Irrelevant information and redundant data were removed, allowing the model to focus on... The core logic is to reduce the generation of invalid test cases and shorten the time. The reduced length further decreases the processing burden on the model and improves the speed of use case generation.

[0111] In one implementation, the step of inputting the path summary information and preset file format constraints into the large language model to generate command-line test cases specifically includes the following steps: Step S331: Based on the path summary information and file format constraints of the input large language model, generate semantically valid command-line interface combinations and file tool commands; Step S332: Integrate the command line interface combination and file tool commands to obtain the command line test cases.

[0112] In this embodiment, semantically valid command-line interface combinations and file tool commands are generated based on the input large language model. The mathematical logic is an LLM generation strategy, expressed as:

[0113] in, This represents the generated combination of command-line options. The command represents the generated file tool. Represents a large language model, This refers to the temperature parameter. A semantically valid command-line interface combination refers to a combination of instructions that conforms to the command-line syntax rules of IoT devices and can be parsed and executed by the device, including elements such as command name, option parameters, and parameter values. It refers to the command that invokes the device or system file processing tools to simulate scenarios such as file reading and writing, format conversion, and data transmission.

[0114] During the generation process, the large language model first parses... In and ,understand The execution flow, key calling stages, and parameter requirements. Then, combined with... The file format constraints in the code determine the file format type and data interaction rules corresponding to the test cases. Then, based on... The generation strategy constructs a system that conforms to the device's interaction logic. and During the generation process, ensure the syntactic correctness of the commands, such as matching option parameters with their values, ensuring the logical order of commands, and adapting the file format to the command functionality. Also ensure the semantic validity of the commands, meaning the commands can be triggered. The core execution path is optimized to avoid generating meaningless or invalid commands.

[0115] Based on the test scenario and objectives, appropriate combinations and integrations should be made. and Obtain command-line test cases. For test scenarios requiring file input, and To combine, first through Prepare the test file, then pass Call Process the file. For test scenarios that do not require file input, directly input one or more files. It integrates and simulates continuous command-line operations.

[0116] pass The calculations provide the model with comprehensive contextual information, combined with The generation strategy improves the semantic effectiveness of test cases generated in this step. Traditionally randomly generated test cases only pass device command-line syntax validation by 14%, while the semantic effectiveness of test cases generated in this step increases to 89%, enabling precise triggering. This method optimizes the core execution path and improves vulnerability detection rates. In smart city surveillance camera testing, test cases generated through this step successfully triggered a privilege bypass vulnerability in the config_rtsp remote maintenance command, while traditional test cases failed to trigger the vulnerability despite multiple executions, thus verifying the superiority of this test case generation method.

[0117] In one implementation, the temperature parameter in the generation strategy of the large language model is set to 0.

[0118] In this embodiment, the temperature parameter of the generation strategy is set to 0. This parameter value can minimize the randomness of the generation results and ensure that the output command line test cases have deterministic semantic and syntactic validity.

[0119] The temperature parameter in the generation strategy of the large language model is set to 0, and its logic is reflected in... In the generation rules, the temperature parameter... This is the core parameter controlling the randomness of the model's generated results. Its value typically ranges from 0 to 1; a higher value indicates greater randomness, while a lower value indicates greater certainty. When... At this time, the randomness of the model's generated results is minimized, and it strictly selects the words and logic with the highest probability for combination, resulting in the most stable and consistent output. The result of the input logic; and when When the probability approaches 1, the model will randomly select words and logic with lower probabilities, generating more diverse but potentially semantically biased results.

[0120] In the scenario of generating command-line test cases for IoT devices. The reason is that test cases need to have high semantic validity and syntactic correctness to avoid invalid test cases caused by randomness. The command-line interface of IoT devices has strict syntax rules, and there are fixed requirements for option parameters, parameter values, command order, etc. If there are random jumps during the model generation process, it may lead to command syntax errors or semantic irrelevant issues such as missing option parameters or mismatched parameter values, which will reduce the effectiveness of test cases. At that time, the model will be based on In , and Choose the command combination that best conforms to the syntax rules and path logic to ensure the generated... and It can be parsed and executed by the device.

[0121] Setting this parameter ensures the stability, syntactic correctness, and semantic validity of generated test cases, providing reliable test case support for subsequent test execution and vulnerability detection.

[0122] Step S400: Execute the command-line test case and obtain the test results.

[0123] In this embodiment, when executing command-line test cases, the generated test cases can be input into an instruction-level simulation sandbox environment. The test cases are run by simulating the CPU instruction execution, memory read / write, and peripheral device interactions of the device. During real-time monitoring, instrumentation techniques can be used to trace the code path of the test cases and calculate code coverage. Simultaneously, memory monitoring and instruction sequence analysis techniques can be used to capture characteristic signals of vulnerability triggering, such as memory out-of-bounds access, abnormal instruction execution, and abnormal privilege escalation. When obtaining test results based on the vulnerability triggering status, a command-line vulnerability feature library is first called for vulnerability matching. This feature library includes option combination features, file format attack surface features, and built-in industrial protocol instruction set features, which can accurately identify the characteristic signals of different types of vulnerabilities. Then, vulnerability information is stored in a structured format according to a unified format, clearly defining the vulnerability type, triggering conditions, involved functions, and instruction sequences. Finally, all vulnerability information is integrated to generate a test result report containing complete vulnerability details and test data.

[0124] In one implementation, executing the command-line test case to obtain the test result specifically includes the following steps: Step S410: Execute the command-line test cases in the command-line simulation sandbox environment; Step S420: Monitor code coverage and vulnerability triggering status in real time during the testing process; Step S430: Based on the vulnerability triggering state, obtain the test results.

[0125] In this embodiment, the instruction-level simulation sandbox environment is an isolated testing environment built based on hardware instruction simulation technology. It can accurately simulate the CPU instruction execution, memory read / write, and peripheral device interactions of IoT devices, ensuring that test cases behave identically on real devices while being physically isolated to prevent vulnerability triggering from damaging the real device during testing. When executing test cases, the generated... and Enter the sandbox environment and run test cases by simulating device command execution, memory operations, and other behaviors.

[0126] Code coverage refers to the proportion of lines and branches of code covered during test case execution to the total number of lines and branches of code, and is a key indicator for measuring the adequacy of testing. Vulnerability trigger status refers to whether device vulnerabilities are triggered during test case execution, including buffer overflows, instruction injection, privilege escalation, and other types of vulnerabilities. The test results are a structured report formed by combining code coverage data and vulnerability trigger information, including core content such as vulnerability type, triggering conditions, impact scope, and remediation suggestions.

[0127] Command-line test cases are executed in a command-line simulated sandbox environment. The mathematical logic includes two parts: coverage monitoring and vulnerability detection.

[0128] The mathematical expression for coverage monitoring is:

[0129] in, represent The corresponding set of basic blocks, i.e. The set of the smallest code execution units contained in the execution process; Represents the test round; Indicates the first Basic blocks in round testing To be executed This indicates that the action was not taken. Indicates the first The basic block coverage of round testing is used to quantify the impact of test cases on the overall performance of the test. Code coverage.

[0130] The mathematical expression for vulnerability detection is:

[0131] in, This represents the set of vulnerabilities detected. Input data representing test cases, such as file content and parameter values; This indicates that vulnerability detection mechanisms such as memory out-of-bounds detection and abnormal instruction execution detection were triggered during the execution of the test case, meaning that a vulnerability exists.

[0132] During real-time monitoring, instrumentation techniques are used to trace the code paths executed by test cases and to collect statistics. The value, combined with The calculation formula yields the basic block coverage, which in turn generates a code coverage report, presenting the test cases' coverage. The coverage status. Simultaneously, through techniques such as memory monitoring and instruction sequence analysis, the coverage status is captured. Characteristic signals, such as buffer overflow vulnerabilities leading to out-of-bounds memory access (triggering memory detection mechanisms), instruction injection vulnerabilities resulting in abnormal instruction execution (triggering instruction verification mechanisms), and privilege bypass vulnerabilities accompanied by abnormal privilege level elevation (triggering privilege detection mechanisms), are used to determine whether vulnerabilities exist.

[0133] When obtaining test results based on vulnerability triggering status, firstly... A preliminary analysis of the vulnerability trigger signals was conducted to determine the approximate location and type of vulnerability trigger; then, combined with... The data is used to determine whether the code path where the vulnerability is located has been adequately covered; finally, the data is integrated. and The system generates test result reports containing information such as vulnerability type, triggering conditions, involved functions, code location, coverage data, and remediation suggestions.

[0134] The sandbox environment avoids the security risks of real-device testing, enabling high-risk vulnerability testing to be conducted safely. This is achieved through a combination of sandbox isolation execution and a real-time dual-monitoring mechanism, and through... and The dual monitoring mechanism comprehensively captures code coverage and vulnerability triggering information, providing rich data support for test result analysis. This avoids missed or misjudged vulnerabilities due to incomplete test data, solving the security risks and incomplete test data inherent in traditional testing performed on real devices. Traditional testing executes test cases directly on real devices; triggering high-risk vulnerabilities can lead to hardware damage, data loss, or operational interruption. Furthermore, some simulation environments cannot accurately reproduce the device's instruction execution logic, resulting in distorted test results. The sandbox environment in this embodiment ensures both test security and the reliability of test results through precise instruction simulation. Simultaneously, real-time monitoring of code coverage and vulnerability triggering status comprehensively captures test data, providing a basis for subsequent dynamic optimization of test strategies.

[0135] In one implementation, the instruction-level simulation sandbox environment is a device instruction-level simulation environment based on QEMU extensions, which supports the simulated execution of device instructions.

[0136] In this embodiment, the instruction-level simulation sandbox environment is an isolated testing environment built based on hardware instruction simulation technology. It can be a device instruction-level simulation environment based on QEMU extensions, supporting the simulation of mainstream instruction sets for IoT devices such as ARM Cortex-M / R. It can accurately reproduce the instruction execution logic and operating state of the device, while being isolated from the real device to prevent vulnerability triggering and damage during testing. The instruction-level simulation sandbox environment is a device instruction-level simulation environment based on QEMU extensions. QEMU is an open-source virtual machine monitor with cross-platform and multi-architecture instruction simulation capabilities. It can simulate instruction execution from various processor architectures such as ARM, x86, and MIPS, and is a commonly used basic tool for IoT device simulation testing. "Based on QEMU extensions" refers to customized development on top of native QEMU, tailored to the characteristics of IoT devices, enhancing the simulation capabilities of embedded device instruction sets, peripheral interfaces, and memory management mechanisms, making it more suitable for the testing needs of IoT devices such as industrial PLC controllers, vehicle-to-everything (V2X) ECUs, and smart city terminals.

[0137] This sandbox environment supports the simulated execution of device instructions. It uses instruction translation and behavior simulation technologies to translate the target instructions of an IoT device into instructions for execution on the host machine. Simultaneously, it simulates the device's memory layout, register states, and peripheral interaction logic to ensure that the execution effect of test cases is consistent with that of a real device. Specifically, the sandbox environment first parses the firmware image of the IoT device, restoring the device's memory partitions, code segment load addresses, peripheral configuration parameters, etc.; then... and The test cases are input into a simulated environment, and the instruction translation module translates the device instructions into instructions executable by the host machine. During execution, real-time simulations of register value changes, memory read / write operations, and peripheral data interactions are performed, such as simulating CAN bus data transmission and serial port instruction reception. Finally, the output results and abnormal states of the test case execution are captured. Calculation and The test provides data.

[0138] To address the diversity of IoT devices, this sandbox environment has undergone multi-architecture adaptation optimization, with a focus on supporting instruction emulation for embedded processor architectures such as the ARM Cortex-M / R series and MIPS M series. These architectures are widely used in devices in industrial control, connected vehicles, and smart cities. Simultaneously, the sandbox environment provides a flexible configuration interface, allowing customization of parameters such as memory size, peripheral type, and interrupt handling mechanisms based on the firmware characteristics of different devices. For example, for industrial devices with less than 16MB of available memory, the simulated memory in the sandbox environment can be configured to 8MB, accurately replicating the device's resource constraints and ensuring optimal performance. and The test results are consistent with those of the actual equipment.

[0139] The technical effect of this sandbox environment is to achieve accurate simulation of IoT device commands, ensuring the authenticity and reliability of test case execution results while guaranteeing test security. Native QEMU lacks sufficient support for peripheral simulation and command details of embedded devices, leading to deviations between test results and real-world device performance. The QEMU-extended sandbox environment, through customized development, overcomes this deficiency, significantly improving the accuracy of command simulation. In vehicle-to-everything (V2X) ECU testing, this sandbox environment successfully simulated instruction execution on the ARM Cortex-R5 architecture, accurately reproducing the CAN bus command interaction logic, providing a solid foundation for future testing. The accurate detection provides a reliable simulation environment; at the same time, the isolation characteristics of the sandbox environment prevent the vulnerability triggering from damaging the real ECU, enabling high-risk vulnerability testing to be carried out safely.

[0140] In one implementation, obtaining the test result based on the vulnerability triggering state specifically includes the following steps: Step S431: Based on the vulnerability triggering state, call the command-line vulnerability feature library to perform vulnerability matching, wherein the vulnerability feature library includes option combination features, file format attack surface features, and built-in industrial protocol instruction set features. Step S432: Based on the matching results, vulnerability information triggered by a combination of structured storage options or a combination of files, wherein the vulnerability information includes vulnerability type and vulnerability triggering conditions; Step S433: Integrate the vulnerability information stored in the structured storage, generate a test result report containing the vulnerability information, and obtain the test results.

[0141] In this embodiment, vulnerability matching is performed by calling the command-line vulnerability signature database based on the vulnerability triggering status. Its mathematical logic includes two parts: attack surface modeling and risk quantification.

[0142] The mathematical expression for attack surface modeling is:

[0143] in, Represents the attack surface matrix. for Quantity, For the number of file types, For vulnerability indication functions, when and When the vulnerability is triggered by combination, ,otherwise .

[0144] The mathematical expression for risk quantification is:

[0145] in, A risk score representing a vulnerability. for The corresponding weighting coefficients, For the first Common Weakness Enumeration for File Types for The severity level is categorized as high-risk, medium-risk, or low-risk.

[0146] Command-line vulnerability signature database is a database containing various command-line related vulnerability signature information. Its core signature categories include option combination signatures, file format attack surface signatures, and built-in industry protocol instruction set signatures. The dimensions correspond to each other. Option combination features correspond to... Combination patterns, such as certain command-line tools using the forced operation -f and verbose output -v options simultaneously, may contain buffer overflow vulnerabilities. These option combinations and their corresponding memory overflow characteristics are recorded in the library; file format attack surface characteristics correspond to... Abnormal patterns, such as when a maliciously crafted H265 file is processed by ffmpeg commands, may trigger a parsing vulnerability. The abnormal format characteristics and command execution characteristics of this file are included in the library. The characteristics of industrial protocol instruction sets correspond to the instruction vulnerability patterns of industrial protocols such as Modbus, CAN, and RTSP. For example, the Modbus protocol's read holding registers instruction may have a privilege bypass vulnerability when the parameters are abnormal. The abnormal format and privilege characteristics of this instruction are recorded.

[0147] During vulnerability matching, the first step is to extract vulnerability triggering characteristic signals detected during testing, including memory state, instruction sequence, system calls, and error output; then, based on these characteristic signals, the corresponding vulnerability triggering characteristic signals are determined. and ,calculate The value is used to construct the attack surface matrix. ; then will The vulnerability is compared one by one with the feature matrix in the vulnerability feature database to calculate the similarity. When the similarity exceeds the preset threshold, it is determined to be a successful match, the vulnerability type and triggering conditions are determined, and the vulnerability risk score is calculated.

[0148] When storing vulnerability information in a structured manner based on the matching results, a standardized data format is used to record the core information of the vulnerability, including the vulnerability type (specifically, whether it is a buffer overflow, instruction injection, or other type), and the vulnerability triggering conditions (detailed records). , (parameter configuration, etc.), and the functions involved (where the vulnerability is located) (and associated functions), code location (the specific line of code and instruction address that triggered the vulnerability), (Risk score), scope of impact (potential device malfunctions or security risks that vulnerabilities may cause), etc.

[0149] When generating test result reports by integrating vulnerability information from structured storage, the mathematical logic for generating authentication reports is as follows:

[0150] in, For the final test result report, For report generation functions, This refers to system security authentication rules, such as OpenHarmony security protocol rules. During the generation process, according to... The system sorts vulnerabilities by their numerical values, prioritizing the presentation of detailed information on high-risk vulnerabilities; and also combines... The data is analyzed to assess the coverage of each vulnerability's path, providing a basis for prioritizing vulnerability remediation. Finally, test summaries and remediation recommendations are provided, such as suggesting boundary checks on function parameters or... Access is strictly controlled, and vulnerability patching can be generated based on OTA patch construction logic. The expression is:

[0151] in, Deploying patches for OTA For patch constructor, This is a vulnerable code segment. This is the repaired, secure code segment.

[0152] By constructing and quantifying risks through attack surface modeling, we ensure accurate matching and risk quantification of different types of vulnerabilities, avoiding missed detections or misjudgments; structured storage makes vulnerability information standardized and uniform, facilitating subsequent processing; the test result reports generated by the certification reports are directly connected to the security certification process, providing a comprehensive basis for vulnerability remediation and security certification.

[0153] In one implementation, the real-time monitoring of code coverage during the testing process specifically includes the following steps: Step S421: Analyze the monitoring results of the code coverage; Step S422: When the code coverage of the high-value objective function is lower than a preset threshold, automatically switch to the next high-value objective function and dynamically adjust the objective function weight and test case generation strategy.

[0154] In this embodiment, code coverage is monitored in real time during the testing process and dynamically adjusted. The mathematical logic for this is a target switching function, expressed as:

[0155] in, This represents the adjusted test objective function. Represents the next high-value objective function. Representing the Round testing Code coverage, In this embodiment, a preset threshold is set for coverage. , For the current test round, To maximize the number of attempts, in this embodiment... .

[0156] analyze The core of the monitoring results is to evaluate the impact of test cases on... The coverage level includes multiple dimensions such as line coverage, branch coverage, and function call coverage, which are ultimately summarized as follows: Line coverage reflects the percentage of line content executed by a test case. The proportion of total code and branch coverage reflects the percentage of conditional branches covered by test cases. The proportion of total branches and function call coverage reflects the percentage of function calls triggered by test cases. The proportion of total calls. By comprehensively analyzing these indicators, we can accurately determine... The sufficiency of the test, for example, a certain The code line coverage reached 90%, but the branch coverage was only 60%, indicating that some conditional branches were not tested and covered, posing a risk of missed vulnerabilities.

[0157] when When, explain If the preset coverage standard is still not met after two rounds of testing, further investment in testing resources may not significantly improve the coverage performance. At this point, a trigger is activated. Automatically switch to the next high-value objective function to avoid wasting test resources; otherwise, keep... Continue to address the current situation Conduct the test.

[0158] When dynamically adjusting the objective function weights and test case generation strategy, the mathematical logic is that the weights are dynamically adjusted, and the expression is:

[0159] in, For the adjusted number The weight values ​​of each function. The weight values ​​before adjustment. As the attenuation factor, in this embodiment , This represents the current average coverage. Objective function weight adjustment refers to... ,reduce The weight of the function, boost The weight of untested functions may cause subsequent testing resources to be tilted towards the uncovered targets; test case generation strategy optimization refers to adjusting the input constraints and the generation logic of the large language model based on the characteristics of the uncovered branches to generate test cases that can cover the uncovered branches. For example, a certain The parameter anomaly branch was not covered; the optimization strategy can be adjusted to add more parameter anomalies. Constraints guide the model to generate data containing outlier parameters. and .

[0160] By designing a target switching function and dynamically adjusting weights, dynamic allocation of test resources and precise optimization of test strategies are achieved, improving the comprehensiveness and efficiency of testing. This avoids the resource waste caused by fixed targets and strategies in traditional testing methods and ensures that all high-value objective functions can be fully tested.

[0161] In one implementation, the dynamic adjustment of the objective function weights and test case generation strategy specifically includes the following steps: Step S4221: Generate a branch heatmap based on the code coverage rate to visually present the branch coverage distribution and the location of uncovered branches of the current high-value objective function; Step S4222: Based on the uncovered branch positions fed back by the branch heatmap, the weights of the current objective function are adjusted through dynamic weight migration; Step S4223: Optimize the test case generation strategy based on the adjusted objective function weights and the execution path characteristics of the new test objective.

[0162] In this embodiment, generating a branch heatmap based on code coverage is... A key method for visualizing abstract data. Branch heatmaps use color depth to intuitively present data. The distribution of branch coverage and the location of uncovered branches are typically indicated by green for covered branches, yellow for partially covered branches, and red for uncovered branches. The coverage count and location of each branch are also noted. The local values. The horizontal axis of the branched heatmap is... The code line or branch number is displayed on the left, and the vertical axis represents coverage metrics such as coverage count or coverage percentage, providing a clear visual representation. Coverage status, for example, a certain The branch is displayed in red, indicating that the branch is not covered by any test cases and is a test blind spot.

[0163] In the process of generating a branched heatmap, the first step is to extract... The branch coverage information includes the identifier of each branch, The data includes the values ​​and coverage counts; then, using data visualization tools, this information is mapped to color gradients and graphical elements to generate a heatmap; finally, the specific locations of uncovered branches (such as line numbers and branch conditions) are marked, providing an intuitive basis for subsequent weight adjustments and strategy optimization.

[0164] Based on the uncovered branch locations identified by the branch heatmap feedback, the objective function weights are adjusted through dynamic weight transfer. Dynamic weight transfer refers to... The weights of low-coverage functions are transferred to high-value objective functions that are either uncovered or have low coverage, thereby increasing the testing priority of uncovered functions. Specifically, firstly, each... The coverage rate is the target rate; functions with a target rate lower than a preset threshold are considered functions to be adjusted; then, based on the number of uncovered branches and... Determine the weight migration ratio; the more uncovered branches, the more... The higher the value, the greater the migration weight ratio; finally, by adjusting the weight values ​​of each function, we ensure that the uncovered functions receive more test resources.

[0165] Based on the adjusted objective function weights and the new test objective Based on the execution path characteristics, optimize the test case generation strategy. The optimization directions include three aspects: first, adjust... The first is to extract key information, specifically for execution paths corresponding to uncovered branches, by extracting more detailed branch logic and parameter features; the second is to optimize... First, add file format features related to uncovered branches. For example, if an uncovered branch involves an abnormal file length, add constraints on file length. Second, adjust the generation parameters of the large language model. Increase the generation weight of instructions related to uncovered branches to guide the model to prioritize generating instructions that cover that branch. and .

[0166] By generating branch heatmaps, precise optimization of testing strategies and efficient allocation of testing resources were achieved, significantly improving test coverage and vulnerability detection rates. The visual presentation of branch heatmaps makes the locations of uncovered branches immediately apparent, avoiding the blind optimization caused by traditional data abstraction; dynamic weight migration ensures that uncovered functions receive sufficient testing resources; and optimized test case generation strategies specifically fill in test blind spots, improving coverage.

[0167] In summary, this invention discloses a command-line targeted testing method for IoT devices, achieving full-process optimization of command-line testing for IoT devices with significant and quantifiable technical effects. Firstly, it overcomes the bottleneck of deep path coverage by eliminating symbol dependencies through a meta-guiding layer and locating high-value target functions based on function call graphs and PageRank weights. This successfully increases the testing depth on FFmpeg experimental data from 1.2 layers in traditional fuzzing to 11.3 layers, effectively exposing deep logic vulnerabilities in device firmware and completely solving the problem of undetectable cross-process function chain vulnerabilities. It also avoids testing obstacles caused by missing symbol tables in embedded devices. Secondly, it significantly improves the effectiveness of test cases. Relying on an LLM targeted guidance strategy, it integrates path compression encoding with file constraints to generate semantically valid command-line interface combinations and file tool commands, increasing the proportion of effective test cases from 14% to 89%. This significantly reduces invalid test cases intercepted by the basic parser and reduces resource consumption by 76%, significantly improving testing efficiency. Thirdly, it achieves lightweight adaptation and accurate testing. Through a coverage-driven dynamic target switching function and weight optimization mechanism, it ensures stable operation of the testing process under resource constraints of less than 8MB of device memory. It successfully reproduces CAN instruction chain vulnerabilities that originally required large amounts of memory for detection. Furthermore, the sandbox layer supports the ARM Cortex-M / R instruction set, covering 90% of relevant IoT devices, perfectly adapting to resource-constrained scenarios such as industrial equipment and vehicle-to-everything (V2X) ECUs. Thirdly, it constructs a closed-loop security authentication system. Based on instruction-level simulation environment coverage calculation and vulnerability detection, it directly connects to device security authentication standards, enabling industrial gateway test results to directly access the security authentication system without additional adaptation, reducing the authentication cycle from 14 days to 3 hours. Simultaneously, it can automatically generate vulnerability remediation solutions and security patches, achieving OTA deployment within minutes, forming a business closed loop of testing, vulnerability discovery, remediation, and authentication, providing equipment manufacturers with a one-stop security enhancement service.

[0168] like Figure 5 As shown in the figure, this embodiment of the invention provides a command-line targeted testing system for IoT devices. The system includes: a device firmware input module 10, a meta-kernel processing module 20, a path extraction and test case generation module 30, and a test execution module 40.

[0169] Specifically, the device firmware input module 10 is used to parse the firmware of the IoT device to obtain a structured function set; the meta-guiding kernel processing module 20 is used to construct a function call relationship graph based on the structured function set, and to filter and locate high-value target functions through a preset weight calculation algorithm; the path extraction and test case generation module 30 is used to extract the execution path corresponding to the high-value target function, input it into a large language model to generate command-line test cases; and the test execution module 40 is used to execute the command-line test cases to obtain test results.

[0170] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 6 As shown, the terminal device includes a processor, memory, network interface, display screen, and temperature sensor connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a command-line targeted testing method for IoT devices. The display screen can be an LCD screen or an e-ink screen. The temperature sensor is pre-installed inside the terminal device to detect the operating temperature of internal components.

[0171] Those skilled in the art will understand that Figure 6 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0172] In one embodiment, a terminal device is provided, including a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs including instructions for performing operations as described in the embodiments of the methods above.

[0173] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0174] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0175] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A command-line targeted testing method for Internet of Things (IoT) devices, characterized in that, Applied to Internet of Things (IoT) devices, the method includes: The firmware of the IoT device is parsed to obtain a set of structured functions; A function call graph is constructed based on the structured function set, and high-value target functions are selected and located through a preset weight calculation algorithm. Extract the execution path corresponding to the high-value objective function and input it into the large language model to generate command-line test cases; Execute the command-line test cases to obtain the test results.

2. The command-line targeted testing method for IoT devices according to claim 1, characterized in that, The firmware of the IoT device is parsed to obtain a set of structured functions, including: Based on the firmware of the IoT device, binary parsing is performed on the firmware to obtain the binary structure data of the firmware; Based on the binary structure data, extract the executable code segment and command-line interface-related entry functions from the firmware; The executable code segment and command-line interface related entry functions are integrated to obtain the structured function set.

3. The command-line targeted testing method for IoT devices according to claim 2, characterized in that, The construction of the function call relationship graph based on the structured function set includes: Based on the structured function set, the cross-process call relationship between the executable code segments and command-line interface-related entry functions in the set is identified, and the cross-process call path is extracted; By using the executable code segment and command-line interface-related entry functions as function nodes and the cross-process call path as call edges, a cross-process function call relationship graph is constructed.

4. The command-line targeted testing method for IoT devices according to claim 3, characterized in that, The step of constructing a cross-process function call graph by using the executable code segment and command-line interface-related entry functions as function nodes and the cross-process call path as call edges includes: Using lightweight disassembly and function flow analysis, the executable code segment and command-line interface-related entry functions are defined as function nodes, and the cross-process call paths are defined as call edges, thus constructing a cross-process function call relationship graph.

5. The command-line targeted testing method for IoT devices according to claim 1, characterized in that, The step of filtering and locating high-value objective functions through a preset weight calculation algorithm includes: Based on the function call relationship graph, the weight value of each function node is calculated using the PageRank algorithm based on function call frequency; The weight values ​​are sorted from largest to smallest, and several quantitative functions are selected based on the sorting order to obtain the high-value objective function.

6. The command-line targeted testing method for IoT devices according to claim 5, characterized in that, The damping factor of the PageRank algorithm is set to 0.

85.

7. The command-line targeted testing method for IoT devices according to claim 1, characterized in that, The step of extracting the execution path corresponding to the high-value objective function and inputting it into a large language model to generate command-line test cases includes: Based on the high-value objective function, extract the execution path corresponding to the high-value objective function; The execution path is compressed and encoded to obtain path summary information; The path summary information and preset file format constraints are input into the large language model to generate command-line test cases.

8. The command-line targeted testing method for IoT devices according to claim 7, characterized in that, The length of the compressed path digest information is less than 4096 tokens.

9. The command-line targeted testing method for IoT devices according to claim 8, characterized in that, After compressing and encoding the execution path to obtain path digest information, the process further includes: The path summary information is pruned in instruction space to obtain optimized path summary information.

10. The command-line targeted testing method for IoT devices according to claim 8, characterized in that, The step of inputting the path summary information and preset file format constraints into the large language model to generate command-line test cases includes: Based on the path summary information and file format constraints of the input large language model, semantically valid command-line interface combinations and file tool commands are generated; By integrating the command-line interface combination and file tool commands, the command-line test cases are obtained.

11. The command-line targeted testing method for IoT devices according to claim 10, characterized in that, The temperature parameter in the generation strategy of the large language model is set to 0.

12. The command-line targeted testing method for IoT devices according to claim 1, characterized in that, The execution of the command-line test cases yields test results, including: Execute the command-line test cases in an instruction-level simulated sandbox environment; Real-time monitoring of code coverage and vulnerability triggering status during the testing process; The test results are obtained based on the vulnerability triggering state.

13. The command-line targeted testing method for IoT devices according to claim 12, characterized in that, The instruction-level simulation sandbox environment is a device instruction-level simulation environment based on QEMU extensions, which supports the simulated execution of device instructions.

14. The command-line targeted testing method for IoT devices according to claim 12, characterized in that, The test results obtained based on the vulnerability triggering state include: Based on the vulnerability triggering state, the command-line vulnerability feature library is invoked for vulnerability matching. The vulnerability feature library includes option combination features, file format attack surface features, and built-in industrial protocol instruction set features. Based on the matching results, vulnerability information triggered by a combination of structured storage options or a combination of files, wherein the vulnerability information includes the vulnerability type and vulnerability triggering conditions; The vulnerability information is integrated from the structured storage to generate a test result report containing the vulnerability information, thus obtaining the test results.

15. The command-line targeted testing method for IoT devices according to claim 12, characterized in that, The real-time monitoring of code coverage during the testing process includes: Analyze the monitoring results of the code coverage; When the code coverage of the high-value objective function falls below a preset threshold, the system automatically switches to the next high-value objective function and dynamically adjusts the objective function weight and test case generation strategy.

16. The command-line targeted testing method for IoT devices according to claim 15, characterized in that, The dynamic adjustment strategy for objective function weights and test case generation includes: A branch heatmap is generated based on the code coverage, visually presenting the branch coverage distribution and the location of uncovered branches for the current high-value objective function; Based on the uncovered branch locations fed back by the branch heatmap, the weights of the current objective function are adjusted through dynamic weight migration; Based on the adjusted objective function weights and the execution path characteristics of the new test objectives, optimize the test case generation strategy.

17. A command-line targeted testing system for Internet of Things (IoT) devices, characterized in that, The system, applied to Internet of Things (IoT) devices, includes: The device firmware input module is used to parse the firmware of the IoT device to obtain a set of structured functions; The meta-guide kernel processing module is used to construct a function call relationship graph based on the structured function set, and to filter and locate high-value target functions through a preset weight calculation algorithm; The path extraction and test case generation module is used to extract the execution path corresponding to the high-value objective function and input it into the large language model to generate command-line test cases. The test execution module is used to execute the command-line test cases and obtain the test results.

18. A terminal device, characterized in that, The terminal device includes a memory, a processor, and an IoT device command-line targeted test program stored in the memory and executable on the processor. When the processor executes the IoT device command-line targeted test program, it implements the steps of the IoT device command-line targeted test method as described in any one of claims 1-16.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an IoT device command-line targeted test program, which, when executed by a processor, implements the steps of the IoT device command-line targeted test method as described in any one of claims 1-16.

Images