An app-assisted remote Internet of Things terminal black box fuzzing method

Abstract

The application provides an App-assisted remote Internet of Things terminal black box fuzzy test method, which comprises the following steps: extracting an App control command based on a document; identifying a mutation point based on App hybrid analysis; conducting fuzzy test based on side channel information guidance; and monitoring an Internet of Things terminal crash based on network behavior. The application uses the time interval between the sending and receiving responses of network messages as side channel information to infer the server-side black box verification logic, realizes the Internet of Things terminal black box fuzzy test technology supported by the bypass cloud server, and thus automatically mines the vulnerabilities of the Internet of Things terminal remotely. The application effectively solves the challenge of remote Internet of Things device black box fuzzy test and improves the fuzzy test efficiency.

Description

Technical Field

[0001] This invention belongs to the field of software technology and relates to testing methods, specifically to an App-assisted black-box fuzzy testing method for remote IoT terminals. Background Technology

[0002] The Internet of Things (IoT) is a network of physical objects embedded with sensors, software, and other technologies, capable of exchanging collected data with other devices or systems via the internet or other communication networks. An IoT system typically comprises three parts: a controller, IoT devices, and a cloud server. The controller is usually a smartphone with a specific control app installed, allowing users to send control commands to specific IoT devices to perform specific functions. IoT devices are physical objects designed for specific applications, equipped with specific sensors and software, and can transmit data via the internet or other networks. The cloud server stores, manages, and configures the data, as well as enabling remote access and control.

[0003] Due to the closed-source nature of IoT systems and the heterogeneity of peripherals, black-box fuzzing has become a preferred method for vulnerability discovery in IoT devices. However, existing work focuses on fuzzing IoT devices within an intranet, which presents challenges when fuzzing IoT devices that rely on remote server communication, particularly with the need for bypass server verification. Furthermore, these works tend to focus on Java code within the control app, limiting their effectiveness in analyzing non-Java code (such as JavaScript-based MiniApps).

[0004] To address the above issues, this invention designs and discloses an App-assisted remote IoT terminal black-box fuzz testing method. Through document-based App control command extraction, mutation point identification based on hybrid App analysis, fuzz testing guided by side-channel information, and IoT terminal crash monitoring based on network behavior, it ultimately achieves remote automated discovery of IoT terminal vulnerabilities. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides an App-assisted remote IoT terminal black-box fuzzing test method. It provides black-box server verification logic speculation based on side-channel information, realizes IoT terminal black-box fuzzing test technology supported by a bypass cloud server, and thus automatically and remotely discovers IoT terminal vulnerabilities.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A method for app-assisted black-box fuzzing testing of remote IoT terminals includes the following steps:

[0008] Step 1, Extraction of document-based App control commands:

[0009] Extract all IoT device control commands from the official documentation to serve as the basis for building a custom fuzz test data package;

[0010] Step 2, Mutation point identification based on App hybrid analysis:

[0011] By performing hybrid analysis on the control app, the mutation point is located, thereby constructing a fuzz test message;

[0012] Step 3, Fuzzy testing guided by side-channel information:

[0013] By recording the time interval between the sending time of the fuzz test message and the receiving time of the response message, it is inferred whether the fuzz test message can bypass the server-side verification; based on the mutation point identified in step 2, the dynamic instrumentation App captures the formatted IoT device control command obtained in step 1, and mutates the control command to construct the fuzz test data packet; the fuzz test data packet is sent multiple times, and the data packets that successfully bypass the cloud server-side verification are separated from the data packets that fail to bypass the verification, so as to infer the server verification logic and guide the subsequent fuzz test message generation;

[0014] Step 4, IoT terminal crash monitoring based on network behavior:

[0015] By observing network behavior, we can monitor whether IoT devices have crashed. When abnormal network behavior is detected, we consider that the target IoT device has crashed.

[0016] Furthermore, in step 1, at least one of the following two methods is used to collect official documents:

[0017] (1) Set up a middleman proxy and generate a self-signed certificate, and then use dynamic instrumentation technology to bypass the mobile terminal certificate verification, decrypt SSL / TLS encrypted traffic and extract official documents;

[0018] (2) Obtain device documentation from the Internet of Things platform.

[0019] Furthermore, in step 1, regular expressions are used to extract App control commands.

[0020] Furthermore, step 2 specifically includes the following process: First, the interface functions that receive control commands from the mini-program are identified through static program analysis. The control commands that control the functions of specific IoT devices are found from the device documentation. The control functions in the App are executed. Then, the interface functions and the functions called by them are dynamically instrumented and filtered to obtain the function parameters. If key-value pair control commands are detected in the parameters of these functions, it indicates that a potential mutation point has been identified.

[0021] Furthermore, after the interface functions are identified through analysis, a large language model is used to exclude functions that are irrelevant to the control of IoT devices.

[0022] Furthermore, once a potential mutation point is identified, the value field in the key-value pair is modified by dynamic instrumentation, and the App operation is replayed to execute the IoT device control operation. The network data packets sent by the App are monitored by a man-in-the-middle agent. If the mutated key-value pair control command appears in the network traffic, the mutation point is confirmed; otherwise, the recursive analysis continues until the data mutation point is located.

[0023] Furthermore, in step 3, the method for guiding the generation of subsequent fuzz test messages is to mutate the values ​​in the control command key-value pairs into data types that can be verified by the server.

[0024] Furthermore, step 4 includes a vulnerability identification phase based on network behavior and a vulnerability confirmation phase based on packet retransmission; the vulnerability identification phase uses abnormal network behavior to identify potential vulnerabilities in the target IoT device and records the exploitable data packets; the vulnerability confirmation phase confirms the discovered potential vulnerabilities by retransmitting fuzz test data packets several times, and if abnormal network behavior continues to exist during retransmission, then the IoT device has a vulnerability.

[0025] Furthermore, the process of identifying potential vulnerabilities in target IoT devices using abnormal network behavior includes:

[0026] (1) Active heartbeat unreachable: Actively use Ping to send heartbeat data packets to the target IoT device within the local network. If a "Destination Host Unreachable" response appears, it indicates that a vulnerability that may cause denial of service or device restart has been triggered.

[0027] (2) Passive network sniffing: The connection between IoT devices and cloud servers is interrupted or unresponsive.

[0028] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0029] 1. This invention combines document-based control command extraction, mutation point identification based on App hybrid analysis, and black-box fuzz testing guided by time-side channel information, effectively solving the challenges of black-box fuzz testing for remote IoT devices. Finally, it improves fuzz testing efficiency by monitoring the network behavior between the IoT device and the cloud server to detect whether the IoT terminal has crashed.

[0030] 2. This invention extracts all IoT device control commands based on official documentation, solving the problems of existing methods based on manual triggering or blind triggering with MonkeyRunner, which require complex analysis and are difficult to cover all control commands, and achieving the highest possible fuzz test code coverage.

[0031] 3. This invention uses the time interval between sending and receiving network packets as channel information to infer the server-side black-box verification logic, thereby supporting the efficient construction of fuzzy test packets that can bypass server verification, and effectively performing remote fuzzy testing on IoT devices.

[0032] 4. This invention locates mutation points through hybrid App analysis, solving the problem of highly confusing mini-program analysis, realizing the analysis of All-in-one Apps on IoT platforms, and achieving functions that existing technologies have not been able to achieve. Attached Figure Description

[0033] Figure 1 To implement the IoT system architecture of the embodiments of the present invention.

[0034] Figure 2 A schematic diagram of the App-assisted remote IoT terminal black-box fuzzy testing method provided by the present invention. Detailed Implementation

[0035] The technical solutions provided by the present invention will be described in detail below with reference to specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0036] The App-assisted remote IoT terminal black-box fuzzy testing method provided in this embodiment is mainly aimed at, for example... Figure 1 The process of the IoT system that supports remote control shown is as follows: Figure 2 As shown, it includes the following steps:

[0037] Step 1: Extracting document-based App control commands

[0038] Because IoT devices are black boxes, code coverage information cannot be obtained. This invention aims to achieve higher IoT device-side code coverage by activating as many IoT device functions as possible through the App, which requires enumerating all IoT device control commands. To enumerate all control commands, this invention first proposes two methods to collect official documentation. The first method involves analyzing network traffic between the App and the cloud server. However, communication between the App and the cloud server is typically protected by SSL / TLS encryption. To bypass this protection, a man-in-the-middle proxy tool and a self-signed certificate are first built. Then, the certificate verification on the mobile device is bypassed by dynamically instrumenting the code to bypass the certificate verification on the App side. Therefore, it is possible to crack the SSL / TLS encrypted traffic and obtain the official documentation, and use regular expressions to extract all IoT device control commands on the App side, thereby testing all IoT device functions and achieving the highest possible code coverage. In addition, some IoT platforms, such as Xiaomi, have been observed to have developed document query engines. This allows obtaining the necessary device documentation by entering the name or model of the target device. After obtaining the documentation, regular expressions can be used to extract all control commands of the companion application. These control commands serve as the basis for building a custom fuzzing package, capable of covering all remote control commands of the App.

[0039] Step 2: Mutation point identification based on hybrid app analysis

[0040] This invention attempts to discover mutation points in an App through hybrid analysis, specifically the functions between data encoding and data packet transmission. Based on these mutation points, formatted IoT device control commands can be identified and mutated. Then, meaningful fuzzy test packets can be constructed using the App's program logic. A simple idea for mutating control commands generated by a mini-program is to directly and dynamically instrument interface functions—Java functions that connect JavaScript and Java code—and mutate the data to generate fuzzy test packets. However, observation reveals that for some IoT platforms, the control commands generated by the mini-program are not the key-value pairs shown in the documentation. The control commands generated by the mini-program need to be converted into key-value pairs in the Java code using data encoding functions. Therefore, only after the data encoding function can data mutation be effectively constructed, necessitating further identification of data mutation points.

[0041] The method of this invention can be summarized as follows: (I) First, static analysis is used to locate and identify candidate functions in the App that may process control commands generated by the mini-program, i.e., interface functions for communication between the All-in-one App Java code and the mini-program. Then, a large language model is used to exclude functions unrelated to IoT device control. Then, control commands (formatted key-value pairs) controlling specific IoT device functions are found from the device documentation. The relevant control functions in the App are executed, and the filtered interface functions and the functions called by them are dynamically instrumented (function call relationships are obtained by constructing a function call graph) to obtain function parameters. (II) If key-value pair control commands are detected in the parameters of these functions, it indicates that a potential mutation point has been identified. To confirm whether it is a real mutation point, this invention modifies the value field in the key-value pair by dynamically instrumenting, replays the App operation to execute IoT device control operations, and monitors the network data packets sent by the App through a man-in-the-middle proxy. If the mutated key-value pair control commands appear in the network traffic, the mutation point is confirmed, and further fuzzy testing guided by side-channel information can be performed. Otherwise, recursive analysis continues until the data mutation point is located.

[0042] Step 3: Fuzzy Testing Guided by Side-Channel Information

[0043] Constructing a fuzz test data package involves first capturing control commands via dynamic instrumentation, typically in key-value pair format. Then, based on the control commands identified in step one, both the key and value are mutated, replacing the original control commands. The mutated key-value pairs are then sent by the app to the server. The primary focus in constructing the fuzz test data package is mutating key-value pairs based on the control commands extracted from the documentation to enumerate all functions of IoT devices that can be triggered by the app. This process begins by randomly selecting a triggered IoT device function, then randomly choosing a data type from the following options, and replacing it with the corresponding value:

[0044] 1) Numeric Data Types: For numeric data types, including "Int" and "Float", this invention generates two types of values ​​designed to trigger integer overflow or out-of-bounds access. The first involves generating values ​​that conform to the data constraints specified in the device documentation for each data type, ensuring that these values ​​are within the expected range for each type. The second method is more random, involving the random generation of large or negative values.

[0045] 2) Value of “Bool”: For “Bool”, randomly select “True” or “False” to construct the fuzz test data packet.

[0046] 3) String Length: Since documents typically do not limit the length of "String", the effective length cannot be inferred from the document. Therefore, a string of length 1-10000 is randomly generated to discover vulnerabilities such as buffer overflows caused by excessively long input.

[0047] Generating fuzzy test packets using randomly mutated key-value pairs presents challenges in bypassing cloud server verification. Because cloud servers perform message verification, directly constructing fuzzy test packets often results in failure to pass server verification, leading to low fuzzing efficiency. Furthermore, since cloud servers are typically black boxes, their verification process is not directly accessible. However, a significant difference was observed in the time interval between sending a request message and receiving a response message in two scenarios: one where the packet passed server verification, and another where it failed. If the fuzzy test packet fails to bypass cloud server verification, the server typically sends a response to the client immediately. This results in a significantly shorter time interval, a stark contrast to the scenario where successfully bypassing cloud server verification, reaching the IoT device, and then waiting for the IoT device's response. Clearly, the time interval between sending a fuzzy test message that passes cloud server verification and sending a response message is much longer than the time interval for a fuzzy test message that fails verification.

[0048] Based on this, this invention proposes to infer server verification logic through time-side channel information. Specifically, it infers whether a fuzzy test message can bypass server-side verification by recording the time interval between the sending time of the fuzzy test message and the receiving time of the response message. Using this side-channel information, the cloud server's verification process can be inferred, guiding subsequent fuzzy test message construction. Specifically, in the subsequent fuzzy test message generation process, only the values ​​in the control command key-value pairs are mutated to data types that can pass server verification, thereby improving the efficiency of fuzzing. To determine whether a fuzzy test packet successfully bypasses cloud server verification, an appropriate threshold needs to be set. This patent configures an appropriate delayed response using the "tc" tool available in the Linux environment on the IoT device side. This intentional delay is to distinguish between two different categories of time intervals. Subsequently, fuzzy test packets are sent multiple times, separating packets that successfully bypass cloud server verification from those that fail. The time interval between request sending and response receiving is monitored, and after collecting this dataset of intervals, an appropriate threshold can be identified to distinguish different categories of messages using clustering techniques. In this way, fuzzy test data packets can be systematically constructed, achieving the goal of bypassing cloud server verification.

[0049] Step 4, Crash monitoring based on network behavior

[0050] When performing fuzz testing on IoT devices, it is necessary to observe whether they crash, thereby monitoring whether the fuzz testing has found vulnerabilities in the IoT devices. Specifically, the method of this invention includes a vulnerability identification phase based on network behavior and a vulnerability confirmation phase based on packet retransmission.

[0051] Given that IoT devices typically operate as black boxes, many lack user interfaces, making it impossible to directly observe whether a crash has occurred. Therefore, directly monitoring device crashes during remote fuzzing presents a significant challenge. Furthermore, connections between IoT devices and cloud servers are usually encrypted using SSL / TLS, making it impossible to determine a crash by analyzing the content of the response data sent by the IoT device. This patent relies on network behavior between the IoT device and the cloud server as a reliable side-channel information source for crash monitoring. Specifically, it utilizes the following anomalous network behaviors to identify potential vulnerabilities in target IoT devices and then records exploitable data packets:

[0052] 1) Active Heartbeat Unreachable: Actively use Ping to send heartbeat packets to the target IoT device within the local network to assess its network status. If a "Destination Host Unreachable" response occurs, it indicates that a vulnerability has been triggered that could lead to denial of service or device restart.

[0053] 2) Passive Network Sniffing: Passive network sniffing methods can be divided into two parts: connection interruption and no response. (I) Unexpected termination of the connection between the IoT device and the cloud server is considered an indication of a crash. For example, if the device actively transmits a FIN packet to terminate the connection after receiving a fuzzing packet from the cloud server, it can be inferred that the fuzzing packet caused a vulnerability, leading the IoT device to actively terminate the connection. (II) No response to a fuzzing request sent by the app suggests a possible crash. This situation may mean that the request may have triggered a vulnerability in the device, causing the device to restart, etc., thus resulting in no response message being sent.

[0054] During the vulnerability confirmation phase, potential vulnerabilities were further confirmed by resending the fuzz test data packets three times. If anomalous network behavior persisted during these retransmissions, it could be concluded that the IoT device was vulnerable, and the vulnerability was not attributable to network anomalies.

[0055] It should be noted that the above content merely illustrates the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. For those skilled in the art, various improvements and modifications can be made without departing from the principle of the present invention, and all such improvements and modifications fall within the scope of protection of the claims of the present invention.

Claims

1. A method for app-assisted black-box fuzzy testing of remote IoT terminals, characterized in that, Includes the following steps: Step 1, Extraction of document-based App control commands: Extract all IoT device control commands from the official documentation to serve as the basis for building a custom fuzz test data package; Step 2, Mutation point identification based on App hybrid analysis: By performing hybrid analysis on the control App, the mutation point is located, thereby constructing a fuzzy test message; the mutation point is the function between data encoding and data packet sending functions. Step 3, Fuzzy testing guided by side-channel information: By recording the time interval between the sending time of the fuzz test message and the receiving time of the response message, it is inferred whether the fuzz test message can bypass the server-side verification; based on the mutation point identified in step 2, the dynamic instrumentation App captures the formatted IoT device control command obtained in step 1, and mutates the control command to construct the fuzz test data packet; the fuzz test data packet is sent multiple times, and the data packets that successfully bypass the cloud server-side verification are separated from the data packets that fail to bypass the verification, so as to infer the server verification logic and guide the subsequent fuzz test message generation; Step 4, IoT terminal crash monitoring based on network behavior: By observing network behavior, we can monitor whether IoT devices have crashed. When abnormal network behavior is detected, we consider that the target IoT device has crashed.

2. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 1, characterized in that, In step 1, at least one of the following two methods is used to collect official documents: (1) Set up a middleman proxy and generate a self-signed certificate, and then use dynamic instrumentation technology to bypass the mobile terminal certificate verification, decrypt SSL / TLS encrypted traffic and extract official documents; (2) Obtain device documentation from the Internet of Things platform.

3. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 1, characterized in that, In step 1, regular expressions are used to extract App control commands.

4. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 1, characterized in that, Step 2 specifically includes the following process: First, the interface functions that receive control commands from the mini-program are identified through static program analysis. The control commands that control the functions of specific IoT devices are found from the device documentation. The control functions in the App are executed. Then, the interface functions and the functions called by them are dynamically instrumented and filtered to obtain the function parameters. If key-value pair control commands are detected in the parameters of these functions, it indicates that a potential mutation point has been identified.

5. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 4, characterized in that, Once the interface functions are identified through analysis, a large language model is used to exclude functions that are irrelevant to the control of IoT devices.

6. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 4, characterized in that, Once a potential mutation point is identified, the value field in the key-value pair is modified by dynamic instrumentation, and the App operation is replayed to execute the IoT device control operation. The network data packets sent by the App are monitored by a man-in-the-middle agent. If the mutated key-value pair control command appears in the network traffic, the mutation point is confirmed; otherwise, the recursive analysis continues until the data mutation point is located.

7. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 1, characterized in that, In step 3, the method for guiding the generation of subsequent fuzz test messages is to mutate the values ​​in the control command key-value pairs into data types that can be verified by the server.

8. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 1, characterized in that, Step 4 includes a vulnerability identification phase based on network behavior and a vulnerability confirmation phase based on packet retransmission. The vulnerability identification phase uses abnormal network behavior to identify potential vulnerabilities in the target IoT device and records the exploitable data packets. The vulnerability confirmation phase confirms the discovered potential vulnerabilities by retransmitting fuzz test data packets several times. If abnormal network behavior continues to exist during retransmission, the IoT device has a vulnerability.

9. The App-assisted remote IoT terminal black-box fuzzy testing method according to claim 8, characterized in that, The process of identifying potential vulnerabilities in target IoT devices by utilizing abnormal network behavior includes: (1) Active heartbeat unreachable: Actively use Ping to send heartbeat data packets to the target IoT device within the local network. If a "Destination Host Unreachable" response appears, it indicates that a vulnerability that may cause denial of service or device restart has been triggered. (2) Passive network sniffing: The connection between IoT devices and cloud servers is interrupted or unresponsive.

Images