Method and system for reproducing one or more BUGS identified by a wireless fuzzer on a target device

Abstract

A method of reproducing one or more bugs identified by a wireless fuzzer on a target device is provided. The method includes: obtaining fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generating, for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug including one or more selected fuzzed packets for attempting to trigger the bug; generating, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and executing, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device. There is also provided a corresponding system for reproducing one or more bugs identified by a wireless fuzzer on a target device.

Description

METHOD AND SYSTEM FOR REPRODUCING ONE OR MORE BUGSIDENTIFIED BY A WIRELESS FUZZER ON A TARGET DEVICECROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of priority of Singapore Patent Application No. 10202403759Y filed on 2 December 2024, the content of which being hereby incorporated by reference in its entirety for all purposes.TECHNICAL FIELD

[0002] The present invention generally relates to a method of reproducing one or more bugs identified by a wireless fuzzer on a target device, and a system thereof.BACKGROUND

[0003] The security of wireless communication protocols is crucial for the success of intemet-of-things (ToT) systems. In the past few years, there has been a significant progress in designing offensive tools to automatically discover wireless protocol implementation vulnerabilities. Among others, over-the-air (OTA) wireless fuzzing has successfully uncovered numerous security vulnerabilities in Wi-Fi, Bluetooth Low Energy, Bluetooth Classic or BT, LTE and 5G NR, among others. While OTA fuzzing primarily focuses on the discovery of security vulnerabilities (e.g., crashes), in general, significant manual effort is involved or required to create minimal Proof of Concept (PoC) code that could reliably reproduce the wireless vulnerabilities discovered by fuzzing. This is critical to assist in the triaging and subsequent root-cause identification and patching of the vulnerability.100041 A need therefore exists to provide a method of reproducing one or more bugs identified by a wireless fuzzer on a target device, as well as a system thereof, that seeks to overcome, or at least ameliorate, one or more deficiencies in existing methods of reproducing bugs identified by a wireless fuzzer on a target device, and more particularly, with enhanced efficiency and effectiveness. It is against this background that the present invention has been developed.SUMMARY

[0005] According to a first aspect of the present invention, there is provided a method of reproducing one or more bugs identified by a wireless fuzzer on a target device, the method comprising: obtaining fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generating, for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; generating, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and executing, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

[0006] According to a second aspect of the present invention, there is provided a system for reproducing one or more bugs identified by a wireless fuzzer on a target device, the system comprising: at least one memory; and at least one processor communicatively coupled to the at least one memory and configured to: obtain fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generate, for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; generate, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproductiontest scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and execute, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

[0007] According to a third aspect of the present invention, there is provided a computer program product, embodied in one or more non-transitory computer-readable storage mediums, comprising instructions executable by at least one processor to perform the method of reproducing one or more bugs identified by a wireless fuzzer on a target device according to the above-mentioned first aspect of the present invention.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Embodiments of the present invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:FIG. 1 depicts a schematic diagram of a method of reproducing one or more bugs identified by a wireless fuzzer on a target device, according to various embodiments of the present invention;FIG. 2 depicts a schematic block diagram of a system for reproducing one or more bugs identified by a wireless fuzzer on a target device, according to various embodiments of the present invention;FIG. 3 illustrates a bug reproduction workflow with and without AIRBUGCATCHER (an example method of reproducing bugs identified by a wireless fuzzer on a target device, as well as a system thereof, according to various example embodiments of the present invention);FIGs. 4A to 4C illustrate example of fuzzed (i.e., mutated or replayed) packets that lead to (a) ambiguous bug reason (root cause) during fuzzing campaign (FIG. 4 A); (b) failure in reproducing bugs due to simple replay not handling dynamic fields such as Auth (i.e., not using AIRBUGCATCHER) (FIG. 4B); (c) minimal reproduction of bug via use of AIRBUGCATCHER (FIG. 4C);FIG. 5 illustrates an example work / operation flow of AIRBUGCATCHER according to various example embodiments of the present invention;FIG. 6A illustrates AIRBUGCATCHER packet analysis and subsequent validation of test scenarios, according to various example embodiments of the present invention;FIGs. 6B to 6D show example packet filtering rules for the over-the-air (OTA) protocols used in experiments conducted, according to various example embodiments of the present invention;FIG. 7 shows an example algorithm (Algorithm 1) for an example process for generating test scenarios for bugs identified by a wireless fuzzer on a target device, according to various example embodiments of the present invention;FIGs. 8 A and 8B illustrate examples of test code generation, whereby FIG. 8 A illustrates the case for mutated packets and FIG 8B illustrates the case for replayed packets, according to various example embodiments of the present invention,FIG. 9 shows Table 1 presenting example AIRBUGCATCHER parameters used in offline bug analysis and over-the-air (OTA) bug reproduction;FIG. 10 shows Table 2 presenting various details of target devices used in evaluation performed;FIG. 11 shows Table 3 presenting statistics of the fuzzing logs from different test devices;FIG. 12 shows Table 4 presenting the effectiveness of AIRBUGCATCHER in reproducing crashes on different test devices;FIG. 13 highlights the distribution of time taken to reproduce a bug by AIRBUGCATCHER;FIG. 14 shows Table 5 presenting results of the ablation study of AIRBUGCATCHER conducted;FIG. 15 shows Table 6 presenting the results of the experiment conducted on five target devices; andFIG. 16 shows Table 7 presenting the results of the baseline experiments.DETAILED DESCRIPTION

[0009] Various embodiments of the present invention provide a method of reproducing one or more bugs identified by a wireless fuzzer on a target device, and a system thereof.

[0010] As discussed in the background, existing methods involve or require significant manual efforts for reproducing bugs identified by a wireless fuzzer on a target device. In this regard, various embodiments of the present invention provide a method of reproducing one ormore bugs identified by a wireless fuzzer on a target device, as well as a system thereof, that seeks to overcome, or at least ameliorate, one or more deficiencies in existing methods of reproducing bugs identified by a wireless fuzzer on a target device, and more particularly, with enhanced efficiency (e.g., automated) and effectiveness (e.g., reliable).

[0011] FIG. 1 depicts a schematic diagram of a method 100 of reproducing one or more bugs identified by a wireless fuzzer on a target device, according to various embodiments of the present invention. The method 100 comprises: obtaining (at 106) fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generating (at 108), for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; generating (at 1 10), for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and executing (at 112), for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

[0012] In various embodiments, the fuzzing logs comprise a packets trace between the wireless fuzzer and the target device and a target device log of the target device generated during the fuzzing campaign by the wireless fuzzer which wirelessly fuzzed the target device.

[0013] In various embodiments, the above-mentioned generating (at 108) the set of bug reproduction test scenarios for the bug comprises: determining a sequence of fuzzed packets relating to the bug based on the fuzzing logs; and generating the set of bug reproduction test scenarios for the bug based on the sequence of fuzzed packets relating to the bug.

[0014] In various embodiments, the set of bug reproduction test scenarios for the bug is generated based on a backward traversal of a sliding window applied on the sequence of fuzzed packets relating to the bug with respect to a bug location of the bug.

[0015] In various embodiments, the above-mentioned determining the sequence of fuzzed packets relating to the bug comprises: determining, for each fuzzed packet of the sequence offuzzed packets relating to the bug, a plurality of attributes for the fuzzed packet, including a packet filter attribute and a packet state attribute, wherein the packet filter attribute indicates a name of a packet field for filtering in relation to the bug and the packet state attribute indicates a packet state of the packet field for filtering in relation to the bug; and assigning, for each fuzzed packet of the sequence of fuzzed packets, the plurality of attributes determined for the fuzzed packet to the fuzzed packet.|0016| In various embodiments, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the packet filter attribute and the packet state attribute of each of the one or more selected fuzzed packets of the bug reproduction test scenario. Furthermore, the executable bug reproduction test code is configured to selectively intercept one or more packets of the live wireless communication of the target device based on a packet filter attribute and a packet state attribute of the one or more packets of the live wireless communication of the target device.10017] In various embodiments, for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a mutated packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the selected fuzzed packet of the bug reproduction test scenario and a corresponding original packet thereof. Furthermore, the executable bug reproduction test code is further configured to mutate one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

[0018] In various embodiments, for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a replayed packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is further configured to replay one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

[0019] In various embodiments, the method 100 further comprises, for each of the one or more bugs identified by the wireless fuzzer on the target device, setting the executable bug reproduction test code generated for the bug reproduction test scenario for the bug as an executable bug reproduction code for the bug based on the executable bug reproduction test code generated for the bug reproduction test scenario for the bug being successful in triggering the bug on the target device.

[0020] In various embodiments, the one or more bugs identified by the wireless fuzzer correspond to one or more unique bugs. In this regard, the method 100 further comprises, foreach of one or more bug classifications: determining multiple bugs identified by the wireless fuzzer during the fuzzing campaign as belonging to the bug classification; and grouping the multiple bugs determined to belong to the bug classification into the bug classification that represents a unique bug with a bug identifier.

[0021] FIG. 2 depicts a schematic block diagram of a system 200 for reproducing one or more bugs identified by a wireless fuzzer on a target device, according to various embodiments of the present invention, corresponding to the above-mentioned method 100 of reproducing one or more bugs as described hereinbefore according with reference to FIG. 1 according to various embodiments of the present invention. The system 200 comprises: at least one memory 202; and at least one processor 204 communicatively coupled to the at least one memory 202 and configured to perform the method 100 of reproducing one or more bugs according to various embodiments of the present invention. Accordingly, the at least one processor 204 is configured to: obtain fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generate, for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; generate, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and execute, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

[0022] It will be appreciated by a person skilled in the art that the at least one processor 204 may be configured to perform various functions or operations through set(s) of instructions (e.g., software modules) executable by the at least one processor 204 to perform various functions or operations. Accordingly, as shown in FIG. 2, the system 200 may comprise: a fuzzing logs obtaining module (or a fuzzing logs obtaining circuit) 206 configured to obtain fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; a bug reproduction test scenarios generating module (or a bug reproduction test scenarios generating circuit) 208 configured to generate, for each of the one or more bugs identified bythe wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; a bug reproduction test code generating module (or a bug reproduction test code generating circuit) 210 configured to generate, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and a bug reproduction test code executing module (or a bug reproduction test code executing circuit) 212 configured to execute, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

[0023] It will be appreciated by a person skilled in the art that the above-mentioned modules of the system 200 are not necessarily separate modules, and two or more modules may be realized by or implemented as one functional module (e.g., a circuit or a software program) as desired or as appropriate without deviating from the scope of the present invention. For example, two or more of the fuzzing logs obtaining module 206, the bug reproduction test scenarios generating module 208, the bug reproduction test code generating module 210 and the bug reproduction test code executing module 212 may be realized (e.g., compiled together) as one executable software program (e.g., software application), which for example may be stored in the at least one memory 202 and executable by the at least one processor 204 to perform the corresponding functions or operations as described herein according to various embodiments of the present invention.

[0024] In various embodiments, the system 200 for reproducing one or more bugs corresponds to the method 100 of reproducing one or more bugs as described hereinbefore with reference to FIG. 1, therefore, various operations, functions or steps configured to be performed by the at least one processor 204 may correspond to various operations, functions or steps of the method 100 of reproducing one or more bugs described hereinbefore according to various embodiments, and thus need not be repeated with respect to the system 200 for reproducing one or more bugs for clarity and conciseness. In other words, various embodiments described herein in context of methods (e.g., the method 100 of reproducing one or more bugs) are analogouslyvalid for the corresponding systems or devices (e.g., the system 200 for reproducing one or more bugs), and vice versa.

[0025] A computing system, a controller, a microcontroller or any other system providing a processing capability may be provided according to various embodiments in the present invention. Such a system may be taken to include one or more processors and one or more computer-readable storage mediums. For example, the system 200 for reproducing one or more bugs described hereinbefore includes at least one processor 204 and at least one computer- readable storage medium (or memory) 202 which are for example used in various processing carried out therein as described herein. A memory or computer-readable storage medium used in various embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).

[0026] In various embodiments, a “circuit” may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus, in an embodiment, a “circuit” may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e g , a microprocessor (e g , a Complex Instruction Set Computer (CISC) processor or a Reduced Instruction Set Computer (RISC) processor). A “circuit” may also be a processor executing software, e.g., any kind of computer program, e.g., a computer program using a virtual machine code, e.g., lava. Any other kind of implementation of various functions or operations may also be understood as a “circuit” in accordance with various other embodiments. Similarly, a “module” may be a portion of a system according to various embodiments in the present invention and may encompass a “circuit” as above, or may be understood to be any kind of a logic-implementing entity therefrom.

[0027] Some portions of the present disclosure may be explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm may be, and generally, conceived to be a self-consi stent sequence of steps leading to a desired result.

[0028] The present specification also discloses a system (e.g., which may also be embodied as devices or apparatuses), such as the system 200 for reproducing one or more bugs, for performing various operations, functions or steps of various methods described herein. Such a system may each be specially constructed for the required purposes or may comprise a general purpose computer system selectively activated or reconfigured by a computer program stored in the computer system. In general, various algorithms that may be presented herein are not limited to being implemented or executed by any particular computer system. Alternatively, the construction of more specialized computer system to perform various operations, functions or steps of various methods described herein may be provided as desired or as appropriate without going beyond the scope of the present invention.

[0029] In addition, the present specification also at least implicitly discloses computer program(s) or software / functional module(s), in that it would be apparent to a person skilled in the art that various operations, functions or steps of various methods described herein may be put into effect by computer code. The computer program(s) is not intended to be limited to any particular programming language and implementation thereof, and it will be appreciated by a person skilled in the art that a variety of programming languages and coding thereof may be used to implement the computer program(s). Moreover, the computer program(s) is not intended to be limited to any particular control flow as there are a variety of programming languages which can use different control flows. It will be appreciated by a person skilled in the art that a computer program may be stored on any computer-readable storage medium (non- transitory computer-readable storage medium), such as but not limited to, a magnetic disk, an optical disk or a memory chip. For example, a computer program stored on a computer-readable storage medium may be loaded and executed on a computer system to implement various operations, functions or steps of various methods described herein according to various embodiments of the present invention.

[0030] Accordingly, in various embodiments, there is provided a computer program product, embodied in one or more computer-readable storage mediums (non-transitory computer-readable storage medium), comprising instructions (e.g., the fuzzing logs obtaining module 206, the bug reproduction test scenarios generating module 208, the bug reproduction test code generating module 210 and / or the bug reproduction test code executing module 212) executable by one or more computer processors to perform the method 100 of reproducing one or more bugs as described hereinbefore with reference to FIG. 1 according to various embodiments of the present invention Accordingly, various computer programs or softwaremodules described herein may be stored in a computer program product receivable by a system therein, such as the system 200 for reproducing one or more bugs as shown in FIG. 2, for execution by at least one processor 204 of the system 200 to perform various operations, functions or steps of various methods described herein according to various embodiments of the present invention.

[0031] It will be appreciated by a person skilled in the art that various modules of systems described herein (e g., the fuzzing logs obtaining module 206, the bug reproduction test scenarios generating module 208, the bug reproduction test code generating module 210 and / or the bug reproduction test code executing module 212) may be software module(s) realized by computer program(s) or set(s) of instructions executable by a computer processor to perform various functions or operations. Various modules described herein (e g., the fuzzing logs obtaining module 206, the bug reproduction test scenarios generating module 208, the bug reproduction test code generating module 210 and / or the bug reproduction test code executing module 212) may also be implemented as hardware module(s) being functional hardware unit(s) designed to perform various functions or operations. More particularly, in the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA). Numerous other possibilities exist. It will also be appreciated by a person skilled in the art that a combination of hardware and software modules may be implemented. Furthermore, various operations, functions or steps of various methods described herein may be performed in parallel rather than sequentially as desired or as appropriate (e.g., as long as it does not render the method(s) inoperable or unsatisfactory for its intended purpose).

[0032] It will be appreciated by a person skilled in the art that the terminology used herein is for the purpose of describing various embodiments only and is not intended to be limiting of the present invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0033] Any reference to an element or a feature herein using a designation such as “first”, “second” and so forth does not limit the quantity or order of such elements or features, unless stated or the context requires otherwise. For example, such designations may be used herein as a convenient way of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not necessarily mean that only two elements can be employed, or that the first element must precede the second element, unless stated or the context requires otherwise. In addition, a phrase referring to “at least one of’ a list of items refers to any single item therein or any combination of two or more items therein.

[0034] In order that the present invention may be readily understood and put into practical effect, various example embodiments of the present invention will be described hereinafter by way of examples only and not limitations. It will be appreciated by a person skilled in the art that the present invention may, however, be embodied in various different forms or configurations and should not be construed as limited to the example embodiments set forth hereinafter. Rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art.

[0035] Fuzzing has been proven to be an effective tool to find implementation bugs in a range of wireless Internet of Things (loT) devices such as smartphones, trackers, smart wearables, routers, etc However, reliable and automated reproduction of vulnerabilities reported by over-the-air (OTA) fuzzing pipelines remains an open problem. Various example embodiments of the present invention note that while bug reproduction is crucial for troubleshooting and fixing of security flaws, it remains a challenge due to the non-determini Stic nature of wireless devices. In this context, various example embodiments of the present invention provide a method of reproducing bug(s) identified by a wireless fuzzer on a target device, as well as a system thereof, with enhanced efficiency (e.g., automated) and effectiveness (e g., reliable), which may herein be referred to as AIRBUGCATCHER. For example, AIRBUGCATCHER is a hardware and protocol agnostic tool that can automatically identify reliable OTA attack vectors and reproduce bugs in commercial-off-the-shelf (COTS) loT devices. According to various example embodiments of the present invention, AIRBUGCATCHER aims to address two fundamental challenges during reproduction of vulnerabilities: Reproduction of bugs under the non-determini Stic communication of wireless devices and resolution of ambiguities during the attack vector analysis of bugs within fuzzing logs. In various example embodiments of the present invention, AIRBUGCATCHERaccomplishes this by firstly analyzing packet traces and logs from an existing fuzzing pipeline and then extracting / generating minimal sets of fuzzing packets that may be responsible for triggering bugs identified by the existing fuzzing pipeline in the target loT device. Subsequently, AIRBUGCATCHER reliably reproduces bugs by generating executable bug reproduction test codes (e.g., proof of concept (PoC) codes) (test cases) and executing them against the target device for attempting to trigger the bugs on the target device to validate the root cause of the bugs. To demonstrate the efficiency and effectiveness of AIRBUGCATCHER, it was evaluated against four COTS loT devices employing wireless protocols such as 5GNR, Bluetooth and Wi-Fi. The experimental results show that AIRBUGCATCHER can reproduce 90.4% (40 / 44) of bugs (crashes or hangs) extracted from fuzzing logs and generate an executable bug reproduction code (e.g., PoC code) for each bug that contains minimal attack vectors For instance, in a non-limiting illustrative example, AIRBUGCATCHER only generates up to three fuzzed packets (i.e., three attack vectors) for reproducing a bug from fuzzing logs that contain about 47,000 fuzzed packets. Finally, various example embodiments demonstrate that a standard replay-based approach (i.e., attempting to replay all packets from fuzzing logs) fail to reproduce most bugs (15 out of 16) due to the non-determini stic nature of wireless protocol implementations. Overall, AIRBUGCATCHER has been demonstrated to offer a valuable addition to loT fuzz testing pipelines by automating the process of OTA bug reproduction and empowering researchers and developers to identify and fix security flaws in loT devices more efficiently.

[0036] Accordingly, various example embodiments provide AIRBUGCATCHER, a systematic and automated process, as well as a system thereof, to reproduce wireless vulnerabilities on target devices (e.g., COTS loT devices). FIG. 3 illustrates a bug reproduction workflow with and without AIRBUGCATCHER In this regard, FIG. 3 illustrates a position or an arrangement of AIRBUGCATCHER (automated bug reproduction) in a bug reproduction workflow according to various example embodiments of the present invention, compared with conventional manual bug reproduction. In particular, conventionally, based on current fuzzing logs (e.g., comprising packet traces and target device logs (e.g., crash logs) from the target device), significant manual effort is involved to produce the bug reproduction code (e.g., PoC) for each bug, which may be sent to a vendor for debugging. In AIRBUGCATCHER according to various example embodiments, a systematic process is provided that analyzes the fuzzing logs and automatically generates the bug reproduction code (PoC) for each bug, thus substantially reducing effort needed before patching.

[0037] In AIRBUGCATCHER according to various example embodiments, two key challenges are addressed to reliably reproduce a wireless vulnerability. Firstly, a straightforward or naive strategy would be to replay the exact sequence of benign and fuzzed packets that resulted in a bug or vulnerability (e.g., a crash) during a fuzzing campaign. While such a strategy may work for mostly deterministic protocols (e g., TCP / IP, HTTP, FTP), various example embodiments note that this will often fail to reproduce bugs or vulnerabilities in wireless protocols that are inherently non-deterministic. Indeed, it is not possible to fully control the state of a wireless device during test, resulting in the straightforward replay strategy being impractical. AIRBUGCATCHER addresses this challenge by a fundamentally different method or approach for bug reproduction. In particular, according to various example embodiments, AIRBUGCATCHER first analyzes fuzzing logs using only a few rules and accurately computes conditions on targeted packet layers and field values that resulted the fuzzed packets leading to a bug. Subsequently, instead of replaying a test that contains previously recorded sequence of benign and fuzzed packets, AIRBUGCATCHER creates tests (executable bug reproduction test codes) for attempting to trigger bugs that act as man-in-the-middle attacks. More specifically, each test (each executable bug reproduction test code) intercepts a packet only when the analyzed condition for a fuzzed packet (e.g., attributes of the packet of a live wireless communication of the target device match attributes of the fuzzed packet of interest) is met, and may then modify targeted packet field values of the intercepted packet (in the case of the fuzzed packet of interest being a mutated packet) for sending the modified packet towards the target loT device on-the-fly. In such a manner, AIRBUGCATCHER lets the live wireless communication of the target device to proceed normally, except only for the targeted packets that are intercepted for modification for fuzzing to attempt to reproduce a bug.

[0038] Secondly, even though fuzzing logs contain packet traces, such traces involve often hundreds or thousands of fuzzed packets, many of which are unrelated to the vulnerability (bug) under investigation. In practice, developer often needs an executable bug reproduction code (e.g., minimal PoC) that facilitates in the debugging of root cause. In various example embodiments, AIRBUGCATCHER addresses this challenge via a two-stage process. Firstly, it analyzes fuzzing logs to group identical bugs (or bugs deemed to be the same). Then, for each bug group, AIRBUGCATCHER conducts a systematic backward traversal (a backward traversal of a sliding window) on the packet traces, starting from a bug location of a bug (e.g., a bug location of a first bug of the bug group), to generate bug reproduction test scenarios (including selected fuzzed packets) for the bug. For example, the systematic backward traversalmay first be conducted from the first bug in the bug group for generating bug reproduction test scenarios (including selected fuzzed packets) for attempting to reproduce the first bug, and then proceed to the second or next bug in the bug group if the bug reproduction test scenarios for the first bug failed to reproduce the first bug. For example, for the first bug, fuzzed packets may be selected from a packets trace between the first and second bug locations for generating bug reproduction test scenarios for attempting to reproduce the first bug. If the first bug is not reproduced by the bug reproduction test scenarios generated for triggering the first bug, the fuzzed packets may be selected from a packets trace between the second and third bug locations for generating bug reproduction test scenarios for attempting to reproduce the second bug and so on. The systematic backward traversal for generating bug reproduction test scenarios will be described in more detail later below with reference to FIG. 6A according to various example embodiments of the present invention. This heuristically computes many test scenarios, each of which contains a minimal set of fuzzed packets that potentially may trigger the corresponding bug on the target device. In the second stage, each test scenario for a bug group is leveraged for test code generation and bug reproduction until a test scenario of the bug group is successful in reproducing the desired or corresponding bug (thus obtaining the corresponding bug reproduction code for the bug), which then completes the bug reproduction process of this bug group (i.e., there is no need to evaluate any remaining test scenarios for the bug group).

[0039] Prior works on automated PoC generation rely on intrusive approaches such as making use of external hardware or through access to source code and firmware emulation. In contrast, AIRBUGCATCHER provides the software security community with a tool that can be easily integrated to fuzzing pipelines quickly and non-intrusively. Moreover, the core process embodied within AIRBUGCATCHER is agnostic to the target hardware and protocol. In other words, as long as the wireless fuzzer supports the target fuzzing, then AIRBUGCATCHER can be coupled with such a wireless fuzzer to assist in triaging.

[0040] In summary, various example embodiments of the present invention provide the following contributions:1) a methodology behind AIRBUGCATCHER, an automated process aimed at reliably reproducing wireless protocol vulnerabilities, is provided;2) an open-source tool implementing the methodology behind AIRBUGCATCHER is provided, which can be easily integrated with wireless fuzzing tools;3) AIRBUGCATCHER is evaluated with four loT devices employing three different wireless protocols: 5G NR, Bluetooth Classic and Wi-Fi. The evaluation reveals thatsuch devices exhibit more than 240 bugs (crashes or hangs) in the fuzzing log. AIRBUGCATCHER first discovers that only 44 of these bugs are potentially unique. Subsequently, AIRBUGCATCHER automatically and reliably reproduces 40 bugs and confirms 33 of them are related to the bugs appearing in the fuzzing log. This shows the efficacy of AIRBUGCATCHER when paired to existing state-of-the-art wireless fuzzers (e.g., Matheus E. Garbelini, et al., BrakTooth: Causing havoc on Bluetooth link manager via directed fuzzing. In 3 / st USENIX Security’ Symposium (USENIX Security 22), pages 1025-1042, Boston, MA, August 2022. USENIX Association (hereinafter referred to as the BrakTooth reference) and Zewen Shang, et al., U-fuzz: Stateful fuzzing of iot protocols on cots devices. 17thIEEE Internationa] Conference on Software Testing, Verification and Validation (ICST), 2024) (hereinafter referred to as the U-fuzz reference);4) the evaluation reveals that AIRBUGCATCHER generates minimal bug reproduction codes (e.g., PoCs). For example, the maximum number of mutation or replay actions in the PoC may be limited to only three, whereas the respective fuzzing logs contain up to 46,992 mutations and up to 12,645 replay actions;5) AIRBUGCATCHER is demonstrated to be efficient. For example, in OnePlus phone, AIRBUGCATCHER reproduces and generates PoC for 13 unique crashes in about two hours;6) AIRBUGCATCHER was compared with a conventional replay-based approach and showed that such a conventional replay-based approach reproduces only one out of 16 bugs in an loT device, whereas AIRBUGCATCHER reproduces 16 bugs.Overview

[0041] An overview and example use-case of AIRBUGCATCHER will now be described according to various example embodiments of the present invention.

[0042] Wireless Fuzzing'. AIRBUGCATCHER is suitable for use with protocol software testing and particularly with over-the-air (OTA) fuzzing. Such a category of fuzzing tools is centered around testing protocol implementation in a greybox or blackbox fashion. In particular, the implementation of these fuzzing tools involves exchanging mutated or replayed inputs (packets) and responses over-the-air via an RF antenna, as opposed to a wired or internal loop- back interface. Example of state-of-the-art (SOTA) wireless fuzzers includes Sweyntooth (Matheus E. Garbelini, et al., SweynTooth: Unleashing mayhem over bluetooth low energy In2020 USENIX Annual Technical Conference (USENIX ATC 20j. pages 911-925. USENIX Association, July 2020 (hereinafter referred to as the Sweyntooth reference)), Braktooth (the BrakTooth reference mentioned hereinbefore), BLEDiff (Karim, et al., Blediff: Scalable and property-agnostic noncompliance checking for ble implementations. In 2023 IEEE Symposium on Security and Privacy (SPf pages 3209-3227, 2023 (hereinafter referred to as the BLEDiff reference)), Owfuzz (Hongjian Cao, etal., Owfuzz: Discovering wi-fi flaws in modern devices through over-the-air fuzzing. In WISEC, pages 263-273. ACM, 2023 (hereinafter referred to as the Owfuzz reference)), U-Fuzz (the U-fuzz reference mentioned hereinbefore), etc. These tools support testing the implementation of several Internet of Things (loT) devices employing wireless protocol such as Bluetooth Low Energy, Bluetooth Classic, 5G NR, etc. During the testing with such devices (i.e., fuzzing campaign), such tools expose logs containing communication traces of protocol packets exchanged during the fuzzing campaign and core dumps once a bug is triggered within the target. However, conventionally, reproduction of bugs obtained or identified during the fuzzing campaign is often manual and time consuming. In this context, AIRBUGCATCHER is designed to leverage fuzzing logs of an existent fuzzing pipeline (generated during a fuzzing campaign) such that bugs reported or identified by an arbitrary wireless fuzzer are automatically reproduced via creation of executable bug reproduction codes (e.g., PoC C++ codes) that are ready to be sent to the software vendor for debugging and patching.

[0043] Motivation. Reproducing bugs in wireless protocols implementation is a highly challenging task as opposed to reproducing bugs in wired protocols. This is because various example embodiments of the present invention note that a complete control of the testing environment is not possible when testing blackbox targets over-the-air. Firstly, repeating the same sequence of packets of the fuzzing campaign is not guaranteed to trigger bugs due to non- deterministic and stateful behaviour of the target’s response. Secondly, many mutated and replayed packets during the fuzzing campaign are often not related to causing a certain bug (e.g., crash). This results in ambiguity when analyzing the root cause of such a bug.

[0044] FIGs. 4A to 4C illustrate example of fuzzed (i.e., mutated or replayed) packets that lead to (a) ambiguous bug reason (root cause) during fuzzing campaign (FIG. 4A); (b) failure in reproducing bugs due to simple replay not handling dynamic fields such as Auth (i.e., not using AIRBUGCATCHER) (FIG 4B); (c) minimal reproduction of bug via use of AIRBUGCATCHER (FIG. 4C).

[0045] For example, consider the fuzzing campaign illustrated in FIG. 4A where several benign and fuzzed packets are sent to the target. Subsequently, the target crashes (e.g., segmentation fault) after receiving packet r2 from the fuzzer. In such a case, the user is aware of the sequence of benign and fuzzed packets (i.e., mutated or replayed) before the bug is triggered. A simple process will attempt to replay this sequence as shown in FIG. 4B. However, the third replayed packet is rejected by the target, before m2 could trigger the bug. This is because replayed packets (regardless if they are benign or not) do not preserve messages / fields that contain dynamic information such as authentication messages, features exchange in Bluetooth, and several 16-bytes authentication parameters for 5G NR (i.e., Auth parameter in FIG. 4B). Therefore, replayed packets contain other fields of several bytes that are invalid in subsequent communication sessions and can be simply dropped by the target. This invalidates the attempted replay, as the target may not process the fuzzed message down to the specific mutated bytes.

[0046] More broadly, failure in reproducing wireless bugs during replay is a common phenomenon due to the non-determini Stic nature of wireless protocols. Intuitively, this happens due to the wireless target replying differently (e.g., unsolicited requests, different message order / response etc.) such that long replay sequences get broken and not due to any false positives during the fuzzing campaigns. While the target internal state and protocol replies can be enforced in source code or emulation-based fuzzing, this level of control is infeasible for over-the-air fuzzing with closed source wireless stacks. FIG. 4A also shows multiple mutated and replayed packets during fuzzing campaign. However, it is the packet m2, which results in the bug, irrespective of what packets are exchanged afterwards. Hence, simply replaying packet r2 or rl, which are indeed the packets closer to the bug location in the packet trace, results in an unsuccessful reproduction of the bug. In practice, even if there are not too many bugs, the number of fuzzed messages, during the fuzzing campaign, could be significant (often in the order of several thousands). Thus, manually identifying a minimal set of fuzzed messages causing the bug (typically 1-3, as shown in our evaluation) is still infeasible.

[0047] To address the above-mentioned challenges, AIRBUGCATCHER (illustrated in FIG. 4C) aims to significantly reduce the time taken to manually analyze and reproduce bugs. This is accomplished by automatically creating test cases, each with a minimal amount of fuzzing actions (i.e., mutation or replay), while avoiding the ambiguity to reason about crashes during bug reproduction.

[0048] AIRBUGCATCHER Workflow. AIRBUGCATCHER offloads the task of reproducing bugs discovered or identified by a wireless fuzzer 510 (i.e., manual reproduction) to an example bug reproduction pipeline 500 (an example overview of AIRBUGCATCHER) shown in FIG. 5 according to various example embodiments of the present invention. Firstly, in a post-fuzzing scenario (Step 1), packets traces (e.g., PCAP file) and target logs (e.g., crash / segmentation-fault dump), as captured during the fuzzing campaign, are fed to AIRBUGCATCHER for further analysis. The target logs are usually captured via serial port or by using standard tools such as Logcat for Android smartphones targets. Concurrently, the communication between the fuzzer 510 and a target device 512 is monitored during the fuzzing campaign and recorded into a standard packets trace format such as PCAP

[0049] Subsequently, a Packet Analysis component 520 (Step 2) receives both the packets trace and target device log (e g , including bug log such as crash log). A function of the Packet Analysis component 520 is to accurately identify attack vector(s) (e.g., a minimal set of mutated and replayed packets) for each unique bug (e.g., crash) in the packets trace. To this end, AIRBUGCATCHER first conducts a simple analysis to identify and group fuzzed packets relating to each unique bug (or each bug group). Then, for each bug (e.g., each unique bug or each bug group), the Packet Analysis component 520 (Step 2) systematically selects fuzzed packets for the bug based on a tunable sliding window that moves backwards from the bug location (e g., Crash indication in Step 1). The outcome of this step may result in many test scenarios for each bug, each test scenario comprising a minimal set of selected fuzzed packets for the bug. Such test scenarios may then be sent to the Test Case Generation component 530 in Step 3 for test-code generation, execution and validation of the respective bug.

[0050] Given a test scenario computed in Step 2, the Test Case Generation component 530 first generates the respective test code. This may be accomplished by analyzing the fuzzed packets of the test scenario and translating the fuzzing action (e.g., mutation or replay) into an executable bug reproduction test code (e.g., C++ code). Once the test code is generated, it may be compiled into binary code and run against the same target device 512 of step 1. During the execution of such test cases, packets trace and target logs are saved and used to determine whether bugs analyzed from step 2 are reproduced correctly. This step is repeated until all bugs found by the fuzzer 510 are evaluated or a time budget is reached. The outcome of step 3 may be a report (step 4), which aggregates all the relevant bug information (e.g., type of bug such as crash, hang or flooding) and a minimal PoC code (i.e., the test case from Step 3) for each bug (e g., each unique bug or each bug group) identified in Step 2 and reproduced in Step 3.Such a report may then be sent to a vendor affected by the bugs in order to accelerate the triaging and fixing process.

[0051] Collection of fuzzing logs’. AIRBUGCATCHER can easily work with existent OTA fuzzers by (i) reusing packet traces collected during the fuzzing campaign and (ii) supporting collection of target logs via serial port, ssf Logcat or other debugging tools capable of exporting logs to text files. Such a non-intrusive approach makes AIRBUGCATCHER easily adoptable by the software security community.Methodology

[0052] At a high level, AIRBUGCATCHER may be separated into two distinct stages according to various example embodiments of the present invention. A first stage performs Offline Bug Analysis (Step 2 of FIG. 5) of fuzzing logs and extracts two relevant outputs: (i) groups of bugs with the same bug identifier and (ii) a set of test scenarios for each bug (e.g., each bug group) that can potentially trigger the corresponding bug on the target device. The second stage of AIRBUGCATCHER, leverages the set of test scenarios for each bug (e g., each bug group) to perform Over-the-Air Bug Reproduction against the target device (Step 3 of FIG. 5). This may be performed repeatedly until all bugs (e.g., all bug groups) are evaluated and categorized or a time budget is reached. Example design and implementation details of each ATRBUGCATCHER stage will now be described according to various example embodiments of the present invention.Offline Bug Analysis

[0053] Fuzzed Packet & Bug Discovery. Initially, AIRBUGCATCHER takes or obtains fuzzing logs (comprising Packet Trace and Target Device Logs) generated during a fuzzing campaign by a wireless fuzzer on a target device as an input. In various example embodiments, AIRBUGCATCHER may further obtain packet filtering rules as a further input from a user. These packet filtering rules are used to identify (fuzzed) packet states and they may borrow a syntax alike Wireshark display filters. The packet filtering rules may specify the names of packet fields which hold values of packet types (states) for different protocol layers for filtering or intercepting packets. For illustration purposes, an example packet filtering rule will be described below, and other example packet filter rules used for the evaluated protocols are shown in FIGs. 6B (Bluetooth classic packet filtering rules), 6C (5G NR packet filtering rules) and 6D (Wi-Fi packet filtering rules). In particular, FIGs. 6B to 6D show example packetfiltering rules for the OTA protocols used in experiments conducted. More specifically, FIGs. 6B, 6C and 6D demonstrate the packet filtering rules for Bluetooth Classic, 5GNR and Wi-Fi respectively.

[0054] It is worthwhile to mention that even though packet filtering rules may be supplied manually, this does not involve a significant manual effort. This is because, for example, a security analyst is usually aware of the parts / portions of the protocol being fuzzed. AIRBUGCATCHER may start the offline analysis by traversing the packets trace within the provided fuzzing log to chronologically discover all fuzzed packets (i.e., mutated or replayed packets) and bug locations. FIG. 6A illustrates an example packet trace including the aforementioned mutated and replayed packets shown as labelled arrows, most of which belong to the same fuzzing iteration (rl, r , ml), whereby the unlabelled arrows represent benign packets.

[0055] Each fuzzed packet (i.e., fuzzed packet) is processed and stored as an object comprising raw bytes and additional attributes such as packet state, packet filter, and fuzzing type (e g., classified as either mutation or replay). Attributes such as packet state and packet filter are specially introduced by AIRBUGCATCHER to help identify or filter specific packets during wireless communication via stateful protocols such as 5G NR, Bluetooth and Wi-Fi. These attributes may be generated using packet filtering rules, as described hereinbefore. In various example embodiments, the packet filter captures a logical condition to precisely categorize the packets belonging to the respective packet state. Thus, such packet filters are used subsequently during our test code generation to intercept and modify packets. For example, for each bug in the fuzzing logs, fuzzed packet contains a list of all fuzzed packets (and their attributes) encountered between the moment the bug appears in the packet traces and the moment when the previous bug appears or the start of fuzzing campaign, whichever is earlier. In addition, the type of a bug may be classified, e.g., crash or hang. While a crash may be indicated in the packet traces or target logs, hangs may be identified via the use of a timeout. This is due to large delays in target’s consecutive responses during hang.

[0056] Bug Identifier and Bug Grouping'. In the fuzzing logs, numerous bugs may appear to be triggered by the same root cause. Nonetheless, such bugs often manifest as separate ones in the fuzzing logs. In various example embodiments, to help reduce the number of bugs for ATRBUGCATCHER to reproduce, bugs may be grouped via the use of bug identifiers. This bug identifier is obtained by analyzing both the packets trace and target device log. For example, bug patterns may be identified based on their types: (i) For crashes, AIRBUGCATCHER mayidentify crash dump or reboot messages in the target logs associated with the bug location, (ii) for hangs, AIRBUGCATCHER may identify hangs by searching for the unresponsiveness of the target device within a certain amount of time. For example, when the target device log emit useful information (e g., source-code line and / or memory addresses) upon crashes, crashes may be identified and grouped based on such information. In the case that no target device logs are available for analysis or such target device logs do not provide additional information (e.g., source-code line or memory addresses), AIRBUGCATCHER may construct bug identifiers from packet state and groups bugs based on identical packet states. For crashes, the packet state may be computed when the crash is manifested. For hangs, various example embodiments posit that the last fuzzed packet in the fuzzing iteration may lead the target device to hang. Therefore, the bug identifier for such cases may be captured using the packet state of the closest fuzzed packet before the hang. For example, an example identifier may be “hang TX / LMP / LMP Jeatures req” , where hang indicates the bug type, “TA” captures packet direction (transmission), “LMP” captures the packet protocol-layer and “LMP features req” is the packet type. More implementation-specific details of identifying and grouping bugs for a variety of target logs will be described later below according to various example embodiments of the present invention. Accordingly, for each of one or more bug classifications, multiple bugs identified by the wireless fuzzer during the fuzzing campaign may be determined as belonging to the bug classification, and the multiple bugs determined to belong to the bug classification may be grouped into the bug classification that represents a unique bug with a bug identifier.

[0057] Test Scenario Generation. This step is to extract or generate sequences of fuzzed packets (i.e., test scenarios) corresponding to each unique bug (or each bug group). Such a test scenario, once translated into a test case, assists in the deterministic reproduction of the fuzzed packet sequence during over-the-air communication with the target. An example of test scenarios generation is shown in FIG. 6A. In particular, FIG. 6A illustrates AIRBUGCATCHER packet analysis and subsequent validation of test scenarios (ts), whereby labels rl, r2 indicate replayed packets and labels ml, m2 indicate mutated packets. After processing and analyzing the packet trace, the resulting test scenarios are represented by Al to tsn, each containing a sequence of fuzzed packets that may be mutated (ml, m2) or replayed (rl, r2) towards the target device. In various example embodiments, for example, the test scenarios may be evaluated from the simplest test scenario (e g., the test scenario containing only one fuzzed packet nearest to the bug location). For example, if the one-fuzzed-packet test scenarios do not successfully reproduce the desired or corresponding bug, scenarios containingonly two fuzzed packets may be evaluated (e.g., starting from the two fuzzed packets nearest to the bug location), so on and so forth.

[0058] As an illustrative example and without limitation, Algorithm 1 shown in FIG. 7 illustrates an example process for generating test scenarios for bugs identified by a wireless fuzzer on a target device The process receives as input the bug groups Bgsfrom the previous Bug Grouping step. In this regard, as described hereinbefore under Fuzzed Packet & Bug Discovery, AIRBUGCATCHER may store a sequence of fuzzed packets (fuzzed _packet) relating (or potentially relating) to each bug (or each bug group). In Algorithm 1, a bounded backward traversal is performed on this sequence (i.e., bug.fuzzed _packet in line 11). The bounded traversal is controlled by the parameter Maxyi (line 13). This captures the maximum amount of past fuzzing iterations to search for. In this regard, the backward search is based on a hypothesis that often packets closer (even though not the closest) to the bug location are responsible for the bug. The backward bounded search reveals a limited set of fuzzed packets Fpkts (line 17), which are then used for test scenario generation. For example, a set of test scenarios from Fpkismay be generated using all possible combinations of fuzzed packets up to a length Maxfpg(line 20). Even though such a process may lead to a combinatorial explosion in theory, according to various example embodiments, a small value of Maxjpg(e.g., two or three) is selected and found to be sufficient in practice. Hence, AIRBUGCATCHER efficiently reproduces real world wireless bugs.

[0059] The outcome of Algorithm 1 is TS, a set of all test scenarios for each bug. It is worthwhile to mention that although the full set of test scenarios TS may be sent to the Test Case Generation component 530, not all scenarios matching a group Gid needs to be evaluated. For example, a test case may only be generated only for a representative bug in each bug group. Moreover, additional time budget may be employed during Test Case Generation to better manage the efficiency of AIRBUGCATCHER for generating and executing test cases.

[0060] Accordingly, in various example embodiments, for each of the one or more bugs (e.g., unique bugs or bug groups) identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios may be generated for the bug based on the fuzzing logs. In this regard, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprises one or more selected fuzzed packets for attempting to trigger the bug. In various example embodiments, the set of bug reproduction test scenarios for the bug may be generated based on determining a sequence of fuzzed packets relating to the bug based on the fuzzing logs, and generating the set of bug reproduction test scenarios for the bug based on the sequenceof fuzzed packets relating to the bug. In various example embodiments, as described above, the set of bug reproduction test scenarios for the bug may be generated based on a backward traversal of a sliding window applied on the sequence of fuzzed packets relating to the bug with respect to a bug location of the bug. Furthermore, in various example embodiments, the above- mentioned determining the sequence of fuzzed packets relating to the bug may comprise: determining, for each fuzzed packet of the sequence of fuzzed packets relating to the bug, a plurality of attributes for the fuzzed packet, including a packet filter attribute and a packet state attribute, whereby the packet filter attribute indicates a name of a packet field for filtering in relation to the bug and the packet state attribute indicates a packet state of the packet field for filtering in relation to the bug; and assigning, for each fuzzed packet of the sequence of fuzzed packets, the plurality of attributes determined for the fuzzed packet to the fuzzed packet.Over-the-Air Bug Reproduction[0061 J At this stage, AIRBUGCATCHER leverages the information computed by offline analysis, then generates and executes test codes on loT devices. The execution of the test codes may also be monitored to check whether the bugs are expected.

[0062] Test Case Generation'. The Test Case Generation component 530 of AIRBUGCATCHER takes a test scenario for a bug and translates it into a test case (an executable bug reproduction test code) for attempting to trigger the bug. Each test scenario comprises one or more selected fuzzed packets (e.g., a small set of fuzzed packets) as extracted from the fuzzing logs for attempting to trigger the bug. Moreover, the wireless fuzzing tools used by AIRBUGCATCHER approach (e g., the wireless fuzzing tools in the above-mentioned BrakTooth reference and the above-mentioned U-fuzz reference) record the corresponding original packet for each fuzzed packet transmitted. In various example embodiments, for using the set of fuzzed packets and their corresponding original packets, the test scenario is transformed into a test case.

[0063] FIGs. 8A and 8B illustrate examples of test code generation, whereby FIG. 8A illustrates the case for mutated packets and FIG. 8B illustrates the case for replayed packets. The leftmost side of FIG. 8B shows an example excerpt of the packet filtering rules (5G NR) used for extracting packet states. In this regard, the entry Filter shows the name of the protocol layer, whereas the entry StateNameField captures the name of the packet field holding the packet type. Thus, using the value of the field nr-rrc.cl, types of stateful RRC-layer packets canbe identified. FIGs. 8A and 8B also illustrate the fuzzed packet (say P^) for the test scenario, the corresponding original packet (say Po) and their raw bytes aligned with the byte offset.

[0064] Accordingly, in various example embodiments, the test case translation may involve two steps: (i) computing the condition to selectively intercept packet for fuzzing, and (ii) computing the code to generate the fuzzed packet. Tn FIG 8A, using the packet filtering rules, the value of the field nr-rrc.cl is extracted from Po and the filtering condition “nr-rrc.cl=l” is constructed. In this example, the condition of “=1” (i.e., state or value of “1”) corresponds to the packet state of the packet field nr-rrc.cl being filtered. This means that the test case will only fuzz packets when the condition “nr-rrc.cl=l” holds. After the creation of the condition, the code may be generated for fuzzing packets. For malformed or mutated packets, this may be accomplished by comparing the raw bytes of Pu and Po. For example, in FIG. 8A, P^ differs from Po in offsets 1 12 and 153. The modification of raw byte content in such offsets is accordingly generated (see the “Test Case” in FIGs. 8A and 8B).

[0065] For replayed packets (see FIG. 8B), the test case generation similarly involves the identification of condition “btbrlmp .op = 39” to select packets for fuzzing. However, in contrast to modifying the packet content, the same packet may be sent twice whenever the filtering condition is met. This may be accomplished via m_send_packet, which takes the raw packet bytes (packet), and replays the packet as many times as specified via a counter (e.g., may be set to 1 ). Moreover, as described hereinbefore, the offline packet analysis associates a list of fuzzed packets with each bug discovered. In this regard, in various example embodiments, a flooding test case may be generated only if the proportion of replayed packets in this list is larger than a threshold (e g., set to 0.8 in evaluation). This is similar to the test case for replay packets, except that the replayed packet is continuously sent to the target device (via m_send_packet interface) in a flooding test case.

[0066] It is worthwhile to mention that the test case according to various example embodiments advantageously does not replay previously recorded packet sequence. Instead, it selectively filters or intercept packets based on the analysis of fuzzing logs and modifies them accordingly during live communication. In various example embodiments, to intercept packets, the wireless fuzzer may be communicatively connected to the target device, whereby the live communication of the target device refers to the communication between the target device and the wireless fuzzer regardless of whether there is an interception or not. This approach advantageously overcomes the difficulty and uncertainty of non-deterministic wireless protocols in the process of reproducing bugs This is because the dynamic context of wirelesscommunication is preserved. Furthermore, the test code generation process illustrated in FIGs. 8A and 8B is protocol agnostic and is applicable to bugs resulting due to arbitrarily mutated, replayed or flooded packet sequence. For example, in the case of test scenario ts6 illustrated in FIG. 6A, codes are generated for fuzzing corresponding to fuzzed packet ml first and then fuzzing corresponding to fuzzed packet rl .

[0067] Accordingly, in various example embodiments, for each of the one or more bugs (e.g., unique bugs or bug groups) identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario may be generated for attempting to trigger the bug. In this regard, in various example embodiments, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the packet filter attribute and the packet state attribute of each of the one or more selected fuzzed packets of the bug reproduction test scenario, and is configured to selectively intercept one or more packets of the live wireless communication of the target device based on a packet filter attribute and a packet state attribute of the one or more packets of the live wireless communication of the target device. Furthermore, in various example embodiments, for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a mutated packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the selected fuzzed packet of the bug reproduction test scenario and a corresponding original packet thereof, and is further configured to mutate one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet. On the other hand, in various example embodiments, for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a replayed packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is further configured to replay one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

[0068] Test Case Execution'. AIRBUGCATCHER may generate and execute test cases sequentially for each group within a maximum time budget Maxtt. For each test execution, ATRBUGCATCHER may monitor the logs and stop the test execution once an expected bug is triggered or a timeout set for bug detection (e.g., G, Htand Ft in Table 1 in FIG. 9) is reached. In particular, Table 1 shows example AIRBUGCATCHER parameters used in offline buganalysis and over-the-air bug reproduction. The default timeout values for detecting hangs (Ht) and flooding (Ft) in experiments conducted are larger than the timeout set for crashes (Ct). This is because hangs and flooding typically require longer time to trigger the respective bugs.

[0069] In various example embodiments, once a bug is triggered during test execution (either detected in the log or via the timeout parameters), the identifier of the triggered bug is compared against the identifier of the bug group under test. This may be accomplished via the same methodology described hereinbefore under Bug Identifier and Bug Grouping. When identifiers of the triggered bug and the bug group match, the test execution concludes that the expected bug identifier has been found for the bug group and AIRBUGCATCHER proceeds to execute the test cases in the next bug group. FIG. 6A illustrates the execution process of test cases. Specifically, FIG. 6A shows that AIRBUGCATCHER continues to the next bug group after the test case tc finds the expected bug. If no expected bug is found for a bug group after maximum trial time Maxtt, the reproduction process may be aborted for the current bug group and AIRBUGCATCHER may move on to generate and execute test cases for the next bug group.

[0070] In various example embodiments, for each of the one or more bugs (e g., unique bugs or bug groups) identified by the wireless fuzzer on the target device, AIRBUGCATCHER sets the executable bug reproduction test code generated for the bug reproduction test scenario for the bug as an executable bug reproduction code for the bug based on the executable bug reproduction test code generated for the bug reproduction test scenario for the bug being successful in triggering the bug on the target device.Example Implementation Details

[0071] AIRBUGCATCHER is designed with generalizability in its focus In particular, AIRBUGCATCHER is protocol agnostic and it is designed to work with different types of bugs (e g., crashes and hangs). Moreover, AIRBUGCATCHER works with a variety of target wireless devices with different device log formats. Notably, among the evaluated devices (see Table 2 in FIG. 10), the SIMCom device does not output any logs, whereas Cypress device does not output any memory address / source-code line upon a crash. In particular, Table 2 shows various details of target devices used in evaluation where the application name is not appliable (N.A.) on devices that do not require a specific application. On the contrary, both the ESP32 device and the OnePlus phone emit source-code line upon a crash. In certain cases, the ESP32 device also outputs a memory trace Finally, it is noted that hangs do not exhibit any visibleoutput in device log due to unresponsive target. Therefore, hangs are identified via the state of the fuzzed packet closest to the bug.

[0072] Implementation of Bug Identifier'. In various example embodiments, while the design of AIRBUGCATCHER is general, various example embodiments implement several strategies to deal with the device-specific log formats, when available. In particular, various example embodiments developed bug identification strategies (see Bug Identifier and Grouping described hereinbefore) that work both with the presence and absence of target logs, albeit with different effectiveness. For instance, target devices such as ESP32-WROOM-32 and OnePlus phone (see Table 2) easily output detailed logs in the event of crashes, while other target devices such as Cypress Board do not output logs. In target that expose logs, there are two kinds of traces exposed during the moment a crash is triggered: source code line trace showing reachable assert, e g., “ASSERT_PARAM(1 0), in Id acl.c at line 1772” and memory trace like “ 0x40082dca:0x3ffbe2d0” . Furthermore, in the case that target logs are not available, the identifier is constructed from the packet state when the target crashes. Various example embodiments note that more precise identifiers are possible to construct, for example, by looking at a history of packet states. However, various example embodiments may only take the crashed location to keep the implementation of AIRBUGCATCHER simple, which is shown in evaluation discussed herein that such a strategy works well in practice.

[0073] Implementation of Bug Grouping'. In various example embodiments, once the bug identifiers are computed, they are used to group potentially identical bugs. While hangs can be grouped simply based on the associated identifier (which is typically the closest packet state before hang), the grouping process for crashes is slightly more involved. Specifically, when target logs show reachable assert (or similar) in the source code, crashes are grouped together if source-code line traces match exactly. Otherwise, memory trace is used to decide if bugs can be grouped. However, various example embodiments note that memory traces originated from certain loT device crashes (e.g., in ESP32-WROOM-32 orESP-WROVER-KIT) may manifest in a slightly different manner. Despite this, memory offset patterns exist in such traces, hence helping to group multiple crashes. For example, the following two bug identifiers extracted from ESP32-WROOM-32 fuzzing log (backtraces), are triggered by the same root cause (truncated for illustration):BugIDl = 0x401013 l l:0x3ffccl700x4001 a637:0x3flfccl 90 ...BugID2 = 0x401013 H:0x3ffcc5800x4001a637:0x3ffcc5a0 ...

[0074] There are two pairs of memory addresses in each BugID that are separated by a colon The first addresses in both pairs of addresses in BugIDl matches with that of BugH)2. This, however, does not hold for the second addresses in both pairs. Nonetheless, the second addresses in both the pairs of addresses in the two bug identifiers are separated by identical offset. Due to such simple patterns, AIRBUGCATCHER groups both BugIDl and BugID2 together. Finally, if target logs are not available, the packet state of the bug location is used as the bug identifier. Consequently, only bugs triggered at the same packet state are grouped. All the bug groups discovered in this process are passed to the next step of AIRBUGCATCHER (namely, Test Scenario Generation).

[0075] False Positives and Negatives in Bug Grouping. Various example embodiments note that both false positives (i.e., the same bug with different identifiers) and negatives (different bugs with the same identifier) are possible in our bug grouping. This inaccuracy stems from the situation that AIRBUGCATCHER may deal with the closed source firmware. Thus, AIRBUGCATCHER aims to leverage as much information (e g., protocol states and target logs) as a human expert would have done in the absence of source code, to analyze and group the bugs. Accordingly, the confirmation of truly unique bugs may only be possible with the availability of the source code and such is unavailable in the case of over-the-air fuzzing. In general, AIRBUGCATCHER aims to speed up the triaging process with the device vendor.

[0076] Once the vendor triages the bug report, ambiguities in bug grouping (e.g., the same bug with different identifiers and PoCs) can be quickly verified due to the reproducible PoCs. Then, the bug grouping can be tweaked and AIRBUGCATCHER may be executed again to reproduce the bugs that may have been incorrectly grouped and generate bug reports automatically.Evaluation Setup

[0077] Hardware and Software Setup'. AIRBUGCATCHER was evaluated on three different wireless protocols: BT (i.e., Bluetooth Classic), 5GNR and Wi-Fi. For each protocol, the evaluation includes one or two test devices (targets) to demonstrate that AIRBUGCATCHER works with different protocols and test devices. Table 2 in FIG. 10 shows the details of the evaluated devices, including vendor names, targeted protocols, firmwareversions and application names. The firmware versions in Table 2 are chosen because such versions were demonstrated to exhibit crashes in earlier works (e.g., the above-mentioned U- fuzz reference and the above-mentioned BrakTooth reference). To launch over-the-air (OTA) fuzzing campaign on the diverse set of devices employing multitudes of wireless protocols, several off-the-shelf hardware devices were leveraged. Specifically, ESP32-Ethemet-Kit and ESP-WROVER-KIT were used to establish a BT connection with the target ESP-WROOM-32 (the above-mentioned BrakTooth reference). Both these devices are flashed with Braktooth firmware. For 5G NR connectivity with smartphones (OnePlus), a Software Defined Radio (SDR) was used, i.e., USRP B210, to create the 5Gbase station. Finally, an AL A A WJS036AC dongle serves as the Wi-Fi access point (AP) in our evaluation. In addition, a USB Per-Port Control Hub was used to perform programmable power-cycles. This is to address scenarios where targets become unresponsive during the fuzzing campaign and require power cycles for the campaign to continue without any manual effort. Finally, both the fuzzing campaign and AIRBUGCATCHER workflow (see FIG. 5) were executed on a Beelink SER5 Mini PC with an AMD Ryzen 7 5800H processor and 12 GB memory, running Armbian 23.02.2 operating system with kernel 5.15.0 version.

[0078] As an illustrative example, AIRBUGCATCHER software is written in Python using 2710 lines of code (LoC). This includes fuzzing log analyzer and crash finder to locate crashes in the fuzzing logs (Step 2 in FIG. 5) as well as PoC (i.e., test case) generator and PoC runner (Step 3 in FIG. 5).

[0079] Fuzzing Log Generation. To generate fuzzing logs that constitute the inputs of AIRBUGCATCHER, we use earlier works on BT fuzzing (described in the above-mentioned BrakTooth reference) and follow its default setup to launch OTA fuzzing on ESP-WROOM- 32, Cypress board and ESP-WROVER-KIT. To run fuzzing on OnePlus phone and SIM8202G, open-source OTA fuzzing framework U-Fuzz (described in the above-mentioned U-fuzz reference) was utilized and its default setup was followed to conduct 5G NR fuzzing. Table 3 in FIG. 11 presents statistics of the fuzzing logs from different test devices. The Mutation and #Replay columns present the total number of mutated and replayed packets throughout the entire fuzzing campaign, respectively. Table 3 also reports the total number of crashes in the fuzzing log. In this regard, fuzzing log generation is not the focus of AIRBUGCATCHER, instead ATRBUGCATCHER complements the security testing pipeline by leveraging the fuzzing logs to automatically create the PoC (e.g., see FIG. 5).Evaluation Results

[0080] For better understanding, the following research questions (RQ) are addressed to evaluate and demonstrate the capabilities of AIRBUGCATCHER.

[0081] RQ1. How effective is AIRBUGCATCHER to reproduce crashes? In order to evaluate the effectiveness of experiments conducted, most of the AIRBUGCATCHER parameters were kept unaltered from the default values of Table 1 and modify them only for certain devices. Table 4 outlines the effectiveness of AIRBUGCATCHER in reproducing crashes on different test devices. Firstly, for test with 5G devices such as OnePlus phone and SIM8202G, the fuzzing logs do not exhibit replayed packets. Consequently, parameters Fe and Re are set to false. Secondly, the Wi-Fi test device ESP-WROVER-KIT disconnects from the Braktooth Wi-Fi Fuzzer in every fuzzing iteration. This means that it is sufficient to generate PoCs based on the fuzzed packets that are one iteration before a bug is triggered. Hence, Maxiy is set to one (1).

[0082] The evaluation results are showcased in Table 4 in FIG. 12. When AIRBUGCATCHER tries to reproduce one bug group, it is possible that no bug is triggered at all. Such results are categorized as Not reproduced. In contrast, a bug group is only categorized as Reproduced if AIRBUGCATCHER Minimal Bug Reproduction (see FIG. 5) successfully triggers any bug within the target. However, there is a chance that the identifier of a triggered bug does not match the expected bug identifier (as analyzed by the Packet Analysis component) during test execution. Therefore, such cases are categorized as Unexpected. In this context, the column Expected indicates bugs that are successfully triggered with the expected bug identifier. For all cases, the results are partitioned in types of bugs (i.e., crash and hang) and quantified within the parenthesis. Last but not least, the Max #Mutation and Max Replay columns represent the maximum number of mutated and replayed packets within each generated PoC across all trials of the Test Case Generation. Finally, the total number of generated PoCs and total time taken for running AIRBUGCATCHER are shown in columns / esi Case and Time respectively.

[0083] The findings reveal that AIRBUGCATCHER triggers all the 16 bugs within BT target ESP32-WROOM-32, while 11 out of 16 bug groups have expected reproductions. On the contrary, there are only two reproductions out of 4 unique bugs for Wi-Fi target ESP- WROVER-KIT, while the two reproductions are also expected This is possibly because the Bluetooth stack used in ESP-WROVER-KIT involves many states and complex protocol procedures In regards to the time to complete all trials, ESP32-WROOM-32 takes 6 hours 44minutes for 11 expected reproductions as compared to its fuzzing duration of about 15h. In contrast, OnePlus phone takes 2 hours 9 minutes for 13 reproductions as opposed to its fuzzing duration of about 13h. Such difference in time comes from where bugs are located. Since most of the bugs for OnePlus are caused due to a single mutated packet (rrcSetup), few test cases generated by AIRBUGCATCHER can already reproduce majority of bugs for such target without additional test cases employing packet replay and flooding. In summary, AIRBUGCATCHER reproduces most crashes from the fuzzing log and takes significantly less time than that of the respective fuzzing campaign.

[0084] RQ2'. How efficient is AIRBUGCATCHER to reproduce crashes? FIG. 13 highlights the distribution of time taken to reproduce a bug by AIRBUGCATCHER. Specifically, FIG. 13 captures the time period taken for AIRBUGCATCHER to automatically reproduce an expected bug, versus the number of bugs obtained within such time periods. Note that only the expected bugs are counted in FIG. 13. The findings reveal that most bugs can be successfully reproduced within four minutes for most devices, while only one or two crashes take more than 30 minutes for reproduction. More specifically, the time to automatically obtain the first expected bug for the five target devices (ESP32-WROOM-32, Cypress Board, OnePlus Phone, SIM8202G and ESPWRO VER-KIT) is 9.7, 0.8, 1.3, 12.9 and 56.4 minutes, respectively. Moreover, the average reproduction time for the five targets (i.e., total evaluation time divided by the number of expected reproductions) is 36 8, 21 .6, 10, 28.8 and 86.8 minutes, respectively. These results highlight the efficiency and hence practicality of employing AIRBUGCATCHER into an existing fuzzing pipeline, which previously would require significant manual effort to reproduce bugs otherwise.

[0085] RQ3. How do the different design options impact the effectiveness of AIRBUGCATCHER? To evaluate the effectiveness of AIRBUGCATCHER design, experiments related to different bug grouping and reproduction parameters were conducted. Firstly, to evaluate the design effectiveness of bug grouping as discussed hereinbefore, modifications were made to AIRBUGCATCHER that allow to enable or disable use of target logs in the Packet Analysis component 520 (see FIG. 5). This is to verify the effectiveness of target logs in the identification and reproduction of bugs. For AIRBUGCATCHER variant that does not analyze target logs, AIRBUGCATCHER falls back to use the state information, as discussed hereinbefore. Secondly, three variants of ATRBUGCATCHER were created to evaluate the effectiveness of bug reproduction strategy (c.f., Test Case Generation describedhereinbefore). Overall, six variants of AIRBUGCATCHER (with or without support from targets logs) based on different types of bug grouping and reproduction were evaluated:1) Mutation Only. AIRBUGCATCHER only processes fuzzed packets that are mutated during Test Case Generation.2) Mutation + Replay. Both mutated and replayed packets are included in Test Case Generation.3) All'. Adds flooding detection and generation to the Test Case Generation where applicable.

[0086] The results of the ablation study are shown in Table 5 in FIG. 14 and structured as follows. Firstly, for each evaluated target, the rows labeled with logs and w / o logs indicate variants of the Packet Analysis Component. Secondly, columns grouped into Expected / Unexpected show the reproduction of bugs using different AIRBUGCATCHER variations ( 1)- (3), as discussed in the preceding paragraph. Note that only mutated packets are exhibited in the results for 5G devices (OnePlus Phone and S1M8202G) because there is no replayed packets present in their fuzzing logs. Moreover, some devices (Cypress Board and SIM8202G) do not produce target logs when a bug occurs. Thus, those devices are only experimented without support from targets logs. Lastly, column Unique Bugs shows the total number of grouped bugs obtained for each variation of the Packet Analysis component and the final column Max. Time represents the longest time to finish the evaluation of any respective variants of AIRBUGCATCHER.

[0087] It can be observed from Table 5 that the variation of AIRBUGCATCHER supporting logs may yield much less Unique Bugs than its counterpart without logs (for ESP32- WROOM-32). This is because, in complex stateful protocols (e.g., Bluetooth) and in the absence of target logs, AIRBUGCATCHER fails to group potentially similar bugs that are triggered in different states during the fuzzing campaign. This is particularly observed with target ESP32-WROOM-32, in which a total of 29 bugs are attempted to be reproduced by AIRBUGCATCHER. Consequently, the lack of target logs results in a worst-case time of 18 hours as opposed to only 7.54 hours when target logs are used. In contrast, for OnePlus phone and ESP-WROVER-KIT, the lack of logs contributed to lower identification of unique bugs (six and two) when compared to usage of logs (fourteen and four). This is because many different bugs were manifested in few 5G and Wi-Fi states only. Thus, using the state information for bug grouping resulted identical group for different bugs. It can also be observedthat target logs provide more precise bug identifier to the Test Case Generation. This reduces the number of failures when reproducing bugs and time taken for bug reproduction.

[0088] Finally, Table 5 shown in FIG. 14 clearly indicates that the variant All generally reproduced more unique bugs as opposed to the other variants “Mutation Only” and “Mutation + Replay”. This is particularly observed for ESP32-WROOM-32. This is because target ESP32- WROOM-32 contains multiple bugs that can only be triggered by replaying or flooding packets as opposed to only mutation.

[0089] Overall, the ablation results of AIRBUGCATCHER reveal that its proposed components are suitable and resilient to reproduce bugs over a range of different configurations.

[0090] RQ4-. How do the various execution parameters affect the effectiveness ofAIRBUGCATCHER? To evaluate the effectiveness of AIRBUGCATCHER running with different parameters, experiments were carried out using different values for Maxfpgand Maxtt. Table 6 shown in FIG. 15 presents the results of the experiment conducted on all five target devices. In the findings, a larger Maxfpghelps to reproduce more bugs. This is expected because certain bugs require more fuzzed packets to trigger than others. Furthermore, longer trial time contributes to the increase on the number of expected and unexpected bugs. One possible reason is that certain bugs are triggered by the fuzzed packets that are far away from the bug location. Consequently, these fuzzed packets are not generated during trials if Maxtt is small since fuzzed packets closer to the bug location are tried first. Finally, Maxfpgand Maxtt have little impact for the target OnePlus phone, because most of its bugs can be triggered by only one fuzzed packet. Therefore, a smaller window size and shorter maximum trial time suffice to trigger most bugs. Moreover, the impact of Maxjpgand Maxu on ESP-WROVER-KIT is not obvious because its fuzzing log contains only four unique bugs and bugs are more difficult to reproduce in a complicated Wi-Fi protocol.

[0091] RQ5. How does AIRBUGCATCHER compare to existing tools? In this experiment, the AIRBUGCATCHER approach was compared against baseline approaches used by other protocol fuzzers (Jinsheng Ba, et al., Stateful greybox fuzzing. In 31st USENIX Security Symposium (USENIX Security 22), pages 3255-3272, Boston, MA, August 2022. USENIX Association (hereinafter referred to as the Stateful greybox fuzzing reference) and Xiaotao Feng, et al., Snipuzz: Black-box fuzzing of iot firmware via message snippet inference. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, CCS ’21, page 337-350, New York, NY, USA, 2021. Association for Computing Machinery (hereinafter referred to as the Snipuzz reference)) To this end, the intuitive approachof baseline fuzzers to reproduce bugs by replaying all TX packets from the fuzzing log (i.e. Simple Replay) was evaluated. The idea behind this approach is that a bug may be reproduced if an identical sequence of packets can be replayed to the target device, since the bug happens after such a sequence of packets were exchanged. However, this is often not a deterministic task because we only have control over TX packets but not RX packets which are received from the test device in real-time. Nonetheless, baseline experiment with the Simple Replay approach was conducted against all five target devices without grouping bugs. Then, for each target device, the experiment attempts to generate and run as many PoCs as the number of crashes in the respective fuzzing logs. The baseline experiments were also repeated five times on each target device to potentially reduce the impact from non-deterministic behaviors of over-the-air protocols. During each trial, the control of packet transmission is performed by either direct injection of replayed TX packets (Bluetooth) or replacing (i.e., overwriting) TX packets of live communication with replayedTX. packets in the sequence (5G, Wi-Fi). The slight difference in the simple replay, based on target protocol, is due to the implementation details of the tool (disclosed in the above-mentioned BrakTooth reference) used by AIRBUGCATCHER to communicate with target devices. Each PoC has a crash detection timeout of 60 seconds (the same as our other experiments). The results of our baseline experiments are presented in Table 7 in FIG. 16. It can be observed that simple replay approach is only able to trigger a few bugs (13-23 out of 190 across five trials) in the ESP32-WROOM-32 target, while no bugs were triggered at all in other targets.

[0092] In contrast, AIRBUGCATCHER is able to reliably reproduce 16 unique bugs (out of 16 unique bugs in fuzzing log) for ESP32-WROOM-32 as highlighted in the Reproduced column of Table 4 in FIG. 12. The underwhelming performance of baseline is due to communication timeouts or the target expecting random packet field values (context) during bug reproduction. Since the target does not receive a response that corresponds to such field values, it drops the connection or send rejection messages during bug reproduction. These results highlight the practicality of AIRBUGCATCHER to reproduce bugs under non- deterministic and adverse protocol communication scenarios.Threats to Validity

[0093] Comprehensiveness of the Target Logs'. The usage of target logs to identify unique bugs is one of the fundamental steps for precisely grouping bugs. If the target cannot provide logs, which contain crash dumps, the precision of the bug identifier is impaired. This mayincrease the time to reproduce bugs as can be observed in the results reported in Table 5 in FIG. 14. Various example embodiments mitigate this risk by enabling debug logs in the evaluated targets and by providing several mechanisms of log collection such as via serial port, SSH and Logcat.

[0094] Number of bugs within bug groups The number of bugs within a bug group may affect the capability of AIRBUGCATCHER to reproduce complex bugs. For example, if there are only few bugs within a group, then it reduces the variations of test cases to be tried by AIRBUGCATCHER (e.g., due to the lack of many locations for the bug). To mitigate this, various example embodiments set the parameters Maxifl and MaxfPg(see Table 1 in FIG. 9) appropriately such that many combinations of fuzzed packets are explored by AIRBUGCATCHER.

[0095] Completeness of Packet Filtering Pules'. For AIRBUGCATCHER to create test cases, it needs to generate certain packet filters that match specific packets during the trial of the PoCs. Such is required for systematic transmission of mutated, replayed or flooding packets towards the target. In this context, it is important that the user provides reasonable packet filtering rules to the Packet Analysis component of AIRBUGCATCHER. Various example embodiments address this threat by creating packet filtering rules based on protocol standard, as also explored by prior works in protocol fuzzing (e.g., the above-mentioned BrakTooth reference)

[0096] Reproducible Target Builds: Since AIRBUGCATCHER relies on fuzzing logs of an existing fuzzing pipeline, using a slightly different target (or firmware version) within the same fuzzing pipeline may lead AIRBUGCATCHER to not reproduce bugs. This is due to deviations in target’ s behaviour. Such deviations might be caused by different responses from the target during PoCs trial or target logs mismatches (e.g., different crash dumps addresses) between what is received during fuzzing versus what is received during bug reproduction. Various example embodiments mitigate this by using the same target or firmware version throughout fuzzing and AIRBUGCATCHER test case generation to ensure reproduction of results.Related Work

[0097] Bug Reproduction Within Protocol Fuzzers'. Existing protocol fiizzers that offer reproduction of stateful bugs normally implement an approach that records the sequence of packets exchanged with the target (e.g., the above-mentioned Stateful greybox fuzzing reference and the above-mentioned Snipuzz reference). Subsequently, they replay benign orfuzzed packet sequences towards the target. While this approach may reproduce bugs for protocols that are mostly sequential and deterministic in nature, it does not consider deviations of the target’s response due to non-determini stic behaviour of wireless protocols. Specifically for wireless communication, full control over the target’s state during a test is not guaranteed. Therefore, replay techniques employed in prior works ought to fail reproduction of deeply rooted or ambiguous bugs. In contrast, AIRBUGCATCHER addresses this shortcoming by adopting a minimal number of state machine rules that can guide its test case generation towards only specific parts of the communication with the target. Additionally, prior works attempt to reproduce bugs by sending the entire fuzzed sequence instead of communicating a minimal set of fuzzed packets that contribute to the bug. Consequently, AIRBUGCATCHER is more suitable to help triaging teams to focus on the relevant attack vector and hence fix the root cause of bugs faster.

[0098] Deterministic Network Replay or Instrumentation. Works that focus in reproducing (e.g., Yuliang Li, etal., DETER: Deterministic TCP replay for performance diagnosis. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), pages 437- 452, Boston, MA, February 2019. USENIX Association, Ravi Netravali, et al., Mahimahi: Accurate Record-and-Replay for HTTP. In 2015 USENIX Annual Technical Conference (USENIX ATC 15), pages 417-429, Santa Clara, CA, July 2015. USENIX Association, Andreas Wundsam, etal., OFRewind: Enabling record and replay troubleshooting for networks. Tn 2011 USENIX Annual Technical Conference (USENIX ATC 11), Portland, OR, June 2011. USENIX Association) or monitoring (e.g., Praveen Tammana, etal., Distributed network monitoring and debugging with SwitchPointer. In 15thUSENIX Symposium on Networked Systems Design and Implementation (NSDI 18), pages 453-456, Renton, WA, April 2018. USENIX Association) communication behaviour of network systems do not offer precise modification of protocol contents or interfacing with network protocols other than Ethernet. Aside from such works’ usefulness in deterministically debugging wired network protocols, their support for construction of test cases is limited to only the recorded protocol packets. Moreover, collecting target logs is out-of-scope for such works. Consequently, analysis of target bugs is limited to hangs or performance degradation (e.g., the above-mentioned Yuliang Li reference).

[0099] Wireless Sensor Network Replay. Tardis (Matthew Tancreti et al., Tardis: software- only system-level record and replay in wireless sensor networks. Tn Proceedings of the 14th International Conference on Information Processing in Sensor Networks, IPSN’ 15, page 286- 297, New York, NY, USA, 2015. Association for Computing Machinery) and Minerva (PhilippSommer et al., Minerva: distributed tracing and debugging in wireless sensor networks. In Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems, SenSys ’ 13, New York, NY, USA, 2013. Association for Computing Machinery) offers packet replay facilities for wireless networks based on intrusive approaches. For example, Tardis requires access to the target’s source code such that debugging code can be introduced into the target firmware. Subsequently, the new firmware generates instrumentation logs during normal operation of the target and is then used inside an emulator to replay packets offline. Similarly, Minerva enables replay of wireless packets through use of external debugging hardware (i.e., JTAG) attached to the target. In summary, both works require intrusive approaches which are not suitable to reproduce protocol bugs in closed wireless stacks such as the loT devices targeted by AIRBUGCATCHER.

[0100] Reproduction of Rugs in Software. AIRBUGCATCHER is orthogonal to several parallel works that aim to reproduce the behaviour of both distributed software systems (e.g., Chri stopher Lidbury et al. , Sparse record and replay with controlled scheduling. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI 2019, page 576-593, New York, NY, USA, 2019. Association for Computing Machinery), Zhenyu Guo et al., Rex: replication at the speed of multi -core. In Proceedings of the Ninth European Conference on Computer Systems, EuroSys ’ 14, New York, NY, USA, 2014. Association for Computing Machinery, Wei Wang et al., Clusterrr: a record and replay framework for virtual machine cluster. In Proceedings of the 18thACM SIGPLAN / SIGOPS International Conference on Virtual Execution Environments, VEE 2022, page 31-44, New York, NY, USA, 2022. Association for Computing Machinery), and mobile applications (e.g., Sidong et al., Prompting is all you need: Automated android bug replay with large language models. In ICSE, pages 67 : 1-67 : 13. ACM, 2024 and Yu Zhao, et al. , Recdroid: Automatically reproducing android application crashes from bug reports. In 2019 IEEE / ACM 41st International Conference on Software Engineering (ICSE), pages 128-139, 2019). Concretely, these works are tailored to reproduce bugs within software binary that runs full- fledged operational system and hence they do not generalize to operate with external hardware, as often required with wireless fiizzers. In contrast, AIRBUGCATCHER focuses solely in the protocol interaction between two peers and hence it does not need to take into account the full behaviour of the underlying OS used by the targets during the fuzzing campaign.

[0101] Automated Exploit Generation. AIRBUGCATCHER runs orthogonally to prior works that automatically generate exploitable code based on open-source code or binarysoftware. On the one hand, Siege (Emanuele lannone et al., Toward automated exploit generation for known vulnerabilities in open-source libraries. In 2021 IEEE / ACM 29th International Conference on Program Comprehension (ICPC), pages 396-400. 2021) and Evomaster (Andrea Arcuri. Restful api automated test case generation with evomaster. ACM Trans. Sofiw. Eng. Methadol., 28(1), Ian 2019) are whitebox approaches that generate exploitable code based on static analysis of the target program. On the other hand, Crax (Shih- Kun Huang et al., Crax: Software crash analysis for automatic exploit generation by modeling attacks as symbolic continuations. In 2012 IEEE Sixth International Conference on Software Security and Reliability), pages 78-87, 2012 (hereinafter referred to as the Crax reference) and Flowstitch (Hong Hu et al., Automatic generation of Data-Oriented exploits. In 24th USENIX Security Symposium (USENIX Security 15), pages 177-192, Washington, D.C., August 2015. USENIX Association (hereinafter referred to as the Flowstitch reference)) generate exploits solely using the program binary. While the latter works are well suitable to reproduce bugs in a blackbox target, these approaches are orthogonal to our objective, as various example embodiments aim to reproduce bugs based on existing test case scenarios obtained from a wireless fuzzer. Moreover, leveraging such binary analysis (e.g., the Crax reference and the Flowstitch reference) may introduce significant technical challenges to reproduce protocol (e.g., stateful) bugs and to support static analysis on different architectures. In this context, ATRBUGCATCHER distinguishes itself by generating test cases while being inherently hardware and protocol agnostic. This is because AIRBUGCATCHER focuses on the bugs discovered by wireless fuzzers and integrates well to accelerate the triaging process.

[0102] Root Cause Diagnosis on Software Code: There are several works that can indicate the root cause of bugs within software code via static or dynamic analysis (e.g., Ao Li et al., ExChain: Exception dependency analysis for root cause diagnosis. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 2047-2062, Santa Clara, CA, April 2024. USENIX Association and Ranjita Bhagwan et al., Orca: Differential bug localization in Large-Scale services. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 493-509, Carlsbad, CA, October 2018. USENIX Association), delta debugging (A. Zeller etal., Simplifying and isolating failure inducing input. IEEE Transactions on Software Engineering, 28(2): 183-200, 2002, as well as pinpointing the commits in which bugs were firstly introduced (Rui Abreu et al., Reducing time-to-fix for fuzzer bugs. In 2021 36th IEEE / ACM International Conference on Automated SoftwareEngineering (ASE), pages 1126-1130, 2021). However, such works are neither directly applicable to stateful protocols fuzzing, nor applicable to closed-source loT targets.

[0103] Various example embodiments of the present invention propose and implement AIRBUGCATCHER, to automatically and systematically reproduce bugs in wireless loT devices to accelerate the troubleshooting, triaging and fixing process of vulnerable ToT devices. Various example embodiments show that the non-deterministic nature of wireless protocols demand a fundamentally different approach for bug reproduction, as simple replay-based techniques fail to preserve the dynamic context during wireless communication. Moreover, the AIRBUGCATCHER approach provides a range of offline analysis to reduce the size of executable bug reproduction code (PoC) to only a few packets, which significantly helps in understanding the root cause of bugs for the vendors. Apart from reliably reproducing wireless implementation bugs, the capabilities embodied in AIRBUGCATCHER can be leveraged for several other future research directions in wireless security. For example, the extracted filtering conditions by AIRBUGCATCHER are used for test-case generation, however, such conditions may also assist in over-the-patch creation or input repair to protect the vulnerable loT devices. Moreover, this input-repair process may also guide the fuzzing process to discover other vulnerabilities that do not appear in the fuzzing log. Accordingly, AIRBUGCATCHER provides a valuable tool to improve the security testing pipeline of loT devices.

[0104] While embodiments of the invention have been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS1. A method of reproducing one or more bugs identified by a wireless fuzzer on a target device, the method comprising: obtaining fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generating, for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; generating, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and executing, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

2. The method according to claim 1, wherein the fuzzing logs comprise a packets trace between the wireless fuzzer and the target device and a target device log of the target device generated during the fuzzing campaign by the wireless fuzzer which wirelessly fuzzed the target device.

3. The method according to claim 1 or 2, wherein said generating the set of bug reproduction test scenarios for the bug comprises: determining a sequence of fuzzed packets relating to the bug based on the fuzzing logs; and generating the set of bug reproduction test scenarios for the bug based on the sequence of fuzzed packets relating to the bug.

4. The method according to claim 3, wherein the set of bug reproduction test scenarios for the bug is generated based on a backward traversal of a sliding window applied on the sequence of fuzzed packets relating to the bug with respect to a bug location of the bug.

5. The method according to claim 3 or 4, wherein said determining the sequence of fuzzed packets relating to the bug comprises: determining, for each fuzzed packet of the sequence of fuzzed packets relating to the bug, a plurality of attributes for the fuzzed packet, including a packet filter attribute and a packet state attribute, wherein the packet filter attribute indicates a name of a packet field for filtering in relation to the bug and the packet state attribute indicates a packet state of the packet field for filtering in relation to the bug; and assigning, for each fuzzed packet of the sequence of fuzzed packets, the plurality of attributes determined for the fuzzed packet to the fuzzed packet.

6. The method according to claim 5, wherein the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the packet filter attribute and the packet state attribute of each of the one or more selected fuzzed packets of the bug reproduction test scenario, and is configured to selectively intercept one or more packets of the live wireless communication of the target device based on a packet filter attribute and a packet state attribute of the one or more packets of the live wireless communication of the target device.

7. The method according to claim 6, wherein for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a mutated packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the selected fuzzed packet of the bug reproduction test scenario and a corresponding original packet thereof, and is further configured to mutate one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

8. The method according to claim 6 or 7, wherein for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a replayed packet, the executable bug reproduction test code for the bug reproduction test scenario forattempting to trigger the bug is further configured to replay one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

9. The method according to any one of claims 1 to 8, further comprising, for each of the one or more bugs identified by the wireless fuzzer on the target device, setting the executable bug reproduction test code generated for the bug reproduction test scenario for the bug as an executable bug reproduction code for the bug based on the executable bug reproduction test code generated for the bug reproduction test scenario for the bug being successful in triggering the bug on the target device.

10. The method according to any one of claims 1 to 9, wherein the one or more bugs identified by the wireless fuzzer correspond to one or more unique bugs, and the method further comprises, for each of one or more bug classifications: determining multiple bugs identified by the wireless fuzzer during the fuzzing campaign as belonging to the bug classification; and grouping the multiple bugs determined to belong to the bug classification into the bug classification that represents a unique bug with a bug identifier11. A system for reproducing one or more bugs identified by a wireless fuzzer on a target device, the system comprising: at least one memory; and at least one processor communicatively coupled to the at least one memory and configured to: obtain fuzzing logs generated during a fuzzing campaign by the wireless fuzzer on the target device; generate, for each of the one or more bugs identified by the wireless fuzzer on the target device, a set of bug reproduction test scenarios for the bug based on the fuzzing logs, each bug reproduction test scenario of the set of bug reproduction test scenarios for the bug comprising one or more selected fuzzed packets for attempting to trigger the bug; generate, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of one or more bug reproduction test scenarios of the set of bug reproductiontest scenarios for the bug, an executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug; and execute, for each of the one or more bugs identified by the wireless fuzzer on the target device and for each of the one or more bug reproduction test scenarios of the set of bug reproduction test scenarios for the bug, the executable bug reproduction test code for the bug reproduction test scenario for the bug with respect to a live wireless communication of the target device for attempting to trigger the bug on the target device.

12. The system according to claim 11, wherein the fuzzing logs comprise a packets trace between the wireless fuzzer and the target device and a target device log of the target device generated during the fuzzing campaign by the wireless fuzzer which wirelessly fuzzed the target device.

13. The system according to claim 11 or 12, wherein said generate the set of bug reproduction test scenarios for the bug comprises: determining a sequence of fuzzed packets relating to the bug based on the fuzzing logs; and generating the set of bug reproduction test scenarios for the bug based on the sequence of fuzzed packets relating to the bug.

14. The system according to claim 13, wherein the set of bug reproduction test scenarios for the bug is generated based on a backward traversal of a sliding window applied on the sequence of fuzzed packets relating to the bug with respect to a bug location of the bug.

15. The system according to claim 13 or 14, wherein said determining the sequence of fuzzed packets relating to the bug comprises: determining, for each fuzzed packet of the sequence of fuzzed packets relating to the bug, a plurality of attributes for the fuzzed packet, including a packet filter attribute and a packet state attribute, wherein the packet filter attribute indicates a name of a packet field for filtering in relation to the bug and the packet state attribute indicates a packet state of the packet field for filtering in relation to the bug; and assigning, for each fuzzed packet of the sequence of fuzzed packets, the plurality of attributes determined for the fuzzed packet to the fuzzed packet16. The system according to claim 15, wherein the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the packet filter attribute and the packet state attribute of each of the one or more selected fuzzed packets of the bug reproduction test scenario, and is configured to selectively intercept one or more packets of the live wireless communication of the target device based on a packet filter attribute and a packet state attribute of the one or more packets of the live wireless communication of the target device.

17. The system according to claim 16, wherein for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a mutated packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is generated based on the selected fuzzed packet of the bug reproduction test scenario and a corresponding original packet thereof, and is further configured to mutate one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

18. The system according to claim 16 or 17, wherein for each selected fuzzed packet of the one or more selected fuzzed packets of the bug reproduction test scenario being a replayed packet, the executable bug reproduction test code for the bug reproduction test scenario for attempting to trigger the bug is further configured to replay one or more packets of the live wireless communication of the target device intercepted as corresponding to the selected fuzzed packet.

19. The system according to any one of claims 11 to 18, wherein the at least one processor is further configured to, for each of the one or more bugs identified by the wireless fuzzer on the target device, set the executable bug reproduction test code generated for the bug reproduction test scenario for the bug as an executable bug reproduction code for the bug based on the executable bug reproduction test code generated for the bug reproduction test scenario for the bug being successful in triggering the bug on the target device.

20. The system according to any one of claims 11 to 19, whereinthe one or more bugs identified by the wireless fuzzer correspond to one or more unique bugs, and the at least one processor is further configured to, for each of one or more bug classifications: determine multiple bugs identified by the wireless fuzzer during the fuzzing campaign as belonging to the bug classification; and group the multiple bugs determined to belong to the bug classification into the bug classification that represents a unique bug with a bug identifier.

21. A computer program product, embodied in one or more non-transitory computer- readable storage mediums, comprising instructions executable by at least one processor to perform the method of reproducing one or more bugs identified by a wireless fuzzer on a target device according to any one of claims 1 to 10.

Images