Pith. sign in

REVIEW 3 major objections 5 minor 80 references

IoTFuzzSentry: A Protocol Guided Mutation Based Fuzzer for Automatic Vulnerability Testing in Commercial IoT Devices

T0 review · 3 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A protocol-guided fuzzer mutates live traffic to uncover credential, image, and video leaks in commercial IoT devices.

desk verdict The tool is real and the command-injection evidence is solid, but the headline privacy exploits are inferred from status codes rather than actual data exfiltration, so the central 'we show their exploits' claim overreaches. read the letter →

arxiv 2509.09158 v1 pith:XPCWX2N4 submitted 2025-09-11 cs.CR

Priyanka Rushikesh Chaudhary , Rajib Ranjan Maiti This is my paper · ORCID
classification cs.CR
keywords IoTsecurityfuzzingmutation-basedprotocolRTSPHTTPTP-LinkSmartHomevulnerabilitydiscovery
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper aims to show that a black-box, mutation-based fuzzer can automatically discover non-crash, privacy-breaking vulnerabilities in commercial IoT devices by mutating a handful of protocol fields in HTTP, RTSP, and TP-Link SmartHome packets. It claims seven new vulnerabilities across a D3D camera, an Ezviz camera, and a TP-Link Kasa smart plug, ranging from leaked device credentials to unauthorized live-image capture, live-video stream access, and command injection. Two of the findings have been assigned CVEs. If the paper is right, IoT vendors can deploy such a fuzzer during the operational phase to catch implementation flaws that crash-free testing misses, and the same seeds-plus-mutation recipe extends to other devices that speak plaintext application protocols.

What carries the argument

The engine is IoTFuzzSentry, a Python-based, black-box mutation fuzzer. It has four modules: a seed collector that pulls HTTP, RTSP, and TP-Link SmartHome/JSON packets from recorded LAN traffic; a mutator that alters specific fields (HTTP method, request-URI, query, version, CRLF; RTSP method, URI, CSeq; TP-Link command length and JSON command string) while preserving packet structure; an injector that sends each crafted packet to the device; and a vulnerability assessor that labels a packet as successful if the device returns a valid success code (HTTP/RTSP 200 OK or TP-Link errcode 0). The classification of the seven vulnerabilities is defined by which field is mutated and which success co

What would settle it

Attempt a complete RTSP session (DESCRIBE, then SETUP, then PLAY) using each mutated URI that returned 200 OK in the paper, and use a media client to see if actual RTP video frames are delivered to a socket; if no video data appears, the 'Sneak IoT Live Video Stream' classification is unsupported. Likewise, for each HTTP image mutation that returned 200 OK, fetch the response body and check whether it is a valid JPEG containing a camera frame rather than a generic success page.

Watch

Extended reading notes

Core claim

The central discovery is that a small set of field-specific seeds extracted from passive network captures—URIs, methods, CSeq values, JSON command strings, and length fields—can be mutated to craft structurally valid packets that commercial IoT devices accept and act on without authentication. The authors establish that three off-the-shelf devices (D3D camera, Ezviz camera, TP-Link Kasa plug) respond to these mutated packets with success codes (HTTP/RTSP 200 OK or TP-Link errcode 0), which the paper treats as evidence of seven distinct exploitable vulnerabilities: access credential leakage, live video stream access, live image capture, and command injection. They also show that existing payl

Load-bearing premise

A device is judged vulnerable whenever a mutated packet draws a success status code (HTTP/RTSP 200 OK or TP-Link errcode 0), without independently verifying that the response actually leaks the claimed data or performs the claimed action.

Editorial extensions

If this is right

  • If the success-code criterion holds, the seven vulnerabilities are real and remotely exploitable by anyone on the same LAN as the device, without needing the companion app or cloud server.
  • Because only a single protocol packet is needed, the attacks are simple to script and can be automated at scale against many devices on a network.
  • The tool's integration into an existing open-source IoT fuzzer means its seven new vulnerability checks are available to other security testers, extending coverage to D3D, Ezviz, and TP-Link Kasa devices.
  • The traffic inspection of six additional devices suggests the same seeds-plus-mutation approach will find similar vulnerabilities in Tapo, Netatmo, Kodak, Imou, Alarm Spy Clock, and Airveda Air Purifier, because they expose similar plaintext HTTP/RTSP endpoints.
  • The response-coverage metric (fraction of mutated packets yielding valid responses) provides a quantitative way to compare how permissive different devices are, and can act as a regression test after vendor patches.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The success-code oracle is the linchpin; if a 200 OK/errcode 0 does not reliably mean actual data exposure or command execution, the count of 'seven vulnerabilities' is inflated, especially for live-video and live-image claims where no video/image bytes are shown to have been recovered. A direct test would be to replay the mutated RTSP URIs in a full SETUP/PLAY session and check whether RTP packet
  • The paper's own limitation (plaintext-only) implies a graceful degradation path: as devices move to TLS/HTTPS, the same field-mutation approach could be applied at the application layer inside the device's firmware or via a proxy that terminates TLS, but that is not demonstrated here.
  • The observation that six more devices expose predictable plaintext URI paths suggests that the hardest part of the attack is not the fuzzing but the initial traffic inspection; an automated version that learns URI templates from pcaps could turn this from a manually-assisted analysis into a fully automatic pipeline.
  • Treating 'command injection' as synonymous with 'the device returns 200 OK to a mutated query' blurs the line between an unintended-but-harmless accepted input and a security flaw; exploitability should be demonstrated by causing a physical effect (e.g., camera pan) or an unauthorized data transfer, as the paper does for D3D 003 but not for all classes.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes IoTFuzzSentry, a black-box, protocol-guided mutation fuzzer for discovering non-crash vulnerabilities in commercial IoT devices. It passively collects PCAPs, extracts seed inputs for HTTP, RTSP, and TP-Link SmartHome/JSON, mutates fields (methods, URIs, CSeq, JSON commands), injects packets, and treats any valid response (HTTP/RTSP 200 OK or TP-Link errcode 0) as evidence of a vulnerability. The tool is integrated into Cotopaxi and evaluated on D3D and Ezviz cameras and a TP-Link Kasa plug, yielding seven reported vulnerabilities in four categories and two CVEs. The authors also analyze traffic of six additional devices and claim extensibility. My assessment agrees with the reader's concern: the strongest evidence is direct for command injection (D3D camera movement in Figure 10, TP-Link errcode 0 in Figure 11), but the privacy-related video/image vulnerabilities are inferred from status codes without demonstrating actual data exfiltration.

Significance. If fully substantiated, the paper offers a useful open-source black-box fuzzer for non-crash vulnerabilities and a concrete integration with Cotopaxi, with replicability (code and sample pcaps) and responsible disclosure (two CVEs and one pending). The direct demonstrations of camera control and smart-plug command execution are concrete strengths. However, the central claim that the paper 'shows exploits' for all four vulnerability types is undercut by the lack of actual video/image data in the privacy cases; two of the seven claimed vulnerabilities (and the two corresponding types) rest only on HTTP/RTSP status-code observations. The generalizability section also overstates evidence for six untested devices. These issues are load-bearing for the abstract and conclusion, but they are fixable within the manuscript's scope.

major comments (3)
  1. [§4.2, §5.2.2, §5.2.3] Privacy vulnerabilities are established only by status codes. Section 4.2 defines D3D 001/Ezviz 000 as a 200 OK to a mutated RTSP request with matching CSeq; §5.2.2 lists valid DESCRIBE/PLAY URIs but no SETUP/PLAY session, no RTP/RTSP packets, and no VLC/iSpy playback capture. Similarly, D3D 002/Ezviz 001 are flagged on HTTP 200 with Content-Type: image/jpeg, but no image bytes are extracted or displayed. A 200 OK to DESCRIBE/OPTIONS does not imply unauthorized video streaming; §4.2 itself says 'if the attacker can view the camera feed...' but no such viewing is shown. This leaves two of the four vulnerability types unsubstantiated. Please add actual packet captures of a video/image body or downgrade these to 'potential' vulnerabilities in the abstract and conclusion.
  2. [§6.5, Table 6] Generalizability overreaches in Table 6. Section 6.5 is based on passive traffic inspection of six additional devices, yet Table 6 assigns concrete vulnerability labels (e.g., 'Sneak IoT Live Video Stream', 'Creep IoT Live Images', 'IoT Access Credentials Leakage') to each device. No active fuzzing was performed on these devices (the text says this is future work). This conflates predicted susceptibility with confirmed vulnerability. Please mark these rows as predictions, or confine Table 6 to protocol/payload observations and state explicitly that active testing remains future work.
  3. [§4.1.1, §5.2.1] D3D 000 (IoT Access Credential Leakage) is not a fuzzing-discovered vulnerability in the same sense as the others. Section 5.2.1 says the tool discovers this vulnerability 'passively' by searching for Authorization: Basic headers, and §4.1.1 explicitly avoids mutating the authorization field. This is a known property of HTTP Basic authentication. Clarify whether this counts as one of the seven vulnerabilities and, if so, justify its novelty relative to standard Basic-auth caveats, or separate it from the mutation-fuzzing results.
minor comments (5)
  1. [§6.1, Table 4] The response-coverage percentages do not add up. D3D RTSP is reported as 48% valid and 52% invalid (total 100%), then the text says 20% of packets were malformed and not considered. Please report raw counts and define the denominator.
  2. [§5.2.2, §5.2.3] The example mutated URIs contain apparent OCR/typo artifacts: 'rtsp://{}:{}/' in §5.2.2, and 'tVmp', 'mtmPfs', and 'og5126' in §5.2.3. These should be verified and corrected.
  3. [§6.3.3] The 'Unsolicited Leakage of Server Communication' paragraph describes HTML/JS functions but does not link them to a specific fuzzed packet or reported vulnerability. Please tie this observation to the findings or remove it.
  4. [§6.4] The Shodan claim that more than 500 D3D cameras are actively online would benefit from a search query, date, and possibly an ethical note about testing online devices.
  5. [References [68], [69]] The two CVE entries are only links. Include a short description of each CVE's scope (affected endpoints, impact) in the text so readers can verify that they cover the claimed endpoints.

Circularity Check

0 steps flagged · score 1.0 of 10

No material circularity: the tool's vulnerability labels are operational detection criteria, and the paper's evidence gaps are correctness concerns rather than circular derivation.

full rationale

The paper's derivation chain is not circular in the sense of fitting an input and then renaming it as a prediction. IoTFuzzSentry extracts seed fields from captured traffic, mutates them, injects packets, and classifies a response as valid based on application-level status codes. Section 4.2 defines each vulnerability by an explicit response criterion, e.g., 'If any of such packets trigger a valid response, e.g., having status code "200 OK" and the same "CSeq" value, then the device has this vulnerability.' This is an operational detector definition, not a fitted parameter disguised as a discovery; a detector reporting the pattern it was programmed to recognize is a tautology of any detector, not circularity. The paper does rely on the authors' prior work [23] as the 'basic idea,' but that self-citation is not load-bearing for the central empirical claims: the present evaluation uses new traffic captures, three tested devices, and external benchmarks (existing Cotopaxi payloads and published CVEs). No uniqueness theorem or forced ansatz is imported from the authors' earlier papers. The main weakness is evidential, not circular: Sections 5.2.2 and 5.2.3 infer 'Sneak IoT Live Video Stream' and 'Creep IoT Live Image' from 200 OK responses and valid mutated URIs without demonstrating actual video/image exfiltration, and Section 4.2 itself conditions successful exploitation on a later external step ('If the attacker can view the camera feed, e.g., using VLC ... the vulnerability stands exploited successfully'). Section 6.6 also acknowledges the tool's limitation to plaintext payloads. These concerns affect whether the vulnerability claims are proven, not whether the derivation is equivalent to its inputs. Accordingly, the circularity score is 1: one minor, non-load-bearing self-citation, with no circular derivation chain.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central evidence rests on the response-status criterion and on the representativeness of the captured traffic. No new physical entity or security mechanism is postulated. The only ad hoc element is the extrapolation from protocol similarity to expected exploitability in six additional devices.

free parameters (2)
  • number of mutated inputs per seed = 200
    The tool generates 200 mutated URIs per seed (Sections 5.2.2 to 5.2.4); the count is chosen without justification and directly affects reported hit rates (e.g., 30/200, 28/200, 39/200).
  • valid-response threshold = HTTP/RTSP 200 OK, TP-Link errcode 0
    A vulnerability is declared when any mutated packet yields a 200 OK or errcode 0 response (Section 4.2); this binary criterion is an ad hoc selection rule rather than a measured exploit outcome.
assumptions (4)
  • domain assumption A protocol response of 200 OK (or TP-Link errcode 0) to a mutated packet is sufficient to conclude the device is vulnerable and the exploit succeeds.
    Used throughout Section 4.2 for D3D 001, D3D 002, D3D 003, Ezviz 001, and TPLink Kasa 000; no full session (e.g., RTSP SETUP/PLAY, actual image extraction) is required.
  • domain assumption Captured LAN traffic is representative and contains seeds (commands, URIs, credentials) that expose all controllable device functions.
    Seed extraction in Section 4.1 relies on passive pcaps; there is no fuzzing of undiscovered endpoints or stateful sequences.
  • ad hoc to paper Presence of HTTP/RTSP/TCP protocols with similar payload directory structures implies similar exploitable vulnerabilities.
    Section 6.5 extends results to six untested devices purely from traffic inspection.
  • domain assumption An attacker who can sniff and inject on the LAN is in scope, while the companion app and cloud server are out of scope.
    Threat model in Section 3 assumes an active LAN attacker but not app or cloud compromise; this limits generalization to Internet-scale attacks.

how reviews work

0 comments
Cite this review

Pith. "Pith review of IoTFuzzSentry: A Protocol Guided Mutation Based Fuzzer for Automatic Vulnerability Testing in Commercial IoT Devices." pith.science (2026). https://pith.science/paper/XPCWX2N4

@misc{pith2026250909158,
  author       = {Pith},
  title        = {Pith review of: IoTFuzzSentry: A Protocol Guided Mutation Based Fuzzer for Automatic Vulnerability Testing in Commercial IoT Devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XPCWX2N4}},
  note         = {Machine review of arXiv:2509.09158}
}
read the original abstract

Protocol fuzzing is a scalable and cost-effective technique for identifying security vulnerabilities in deployed Internet of Things devices. During their operational phase, IoT devices often run lightweight servers to handle user interactions, such as video streaming or image capture in smart cameras. Implementation flaws in transport or application-layer security mechanisms can expose IoT devices to a range of threats, including unauthorized access and data leakage. This paper addresses the challenge of uncovering such vulnerabilities by leveraging protocol fuzzing techniques that inject crafted transport and application-layer packets into IoT communications. We present a mutation-based fuzzing tool, named IoTFuzzSentry, to identify specific non-trivial vulnerabilities in commercial IoT devices. We further demonstrate how these vulnerabilities can be exploited in real-world scenarios. We integrated our fuzzing tool into a well-known testing tool Cotopaxi and evaluated it with commercial-off-the-shelf IoT devices such as IP cameras and Smart Plug. Our evaluation revealed vulnerabilities categorized into 4 types (IoT Access Credential Leakage, Sneak IoT Live Video Stream, Creep IoT Live Image, IoT Command Injection) and we show their exploits using three IoT devices. We have responsibly disclosed all these vulnerabilities to the respective vendors. So far, we have published two CVEs, CVE-2024-41623 and CVE-2024-42531, and one is awaiting. To extend the applicability, we have investigated the traffic of six additional IoT devices and our analysis shows that these devices can have similar vulnerabilities, due to the presence of a similar set of application protocols. We believe that IoTFuzzSentry has the potential to discover unconventional security threats and allow IoT vendors to strengthen the security of their commercialized IoT devices automatically with negligible overhead.

Figures

Figures reproduced from arXiv: 2509.09158 by the authors.

Figure 1
Figure 1. System Model of IoTFuzzSentry Our proposed IoTFuzzSentry is built assuming a security testing environment in a smart home-like scenario, where the IoT devices are operational and can access the Internet via a Wi-Fi router. Every IoT device has its controller, which does not need to be connected to the router to access the IoT devices [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 3
Figure 3. HTTP Packets with authorization header in D3D [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 2
Figure 2. Overview of IoTFuzzSentry. 4.1 Seed Input and Mutation Commercially available IoT devices can use a variety of application protocols, from standard protocols like HTTP and RTSP to proprietary protocols like TP-Link SmartHome/JSON. In general, these protocols do not use encryption, and hence, both the header and payload can be easily intercepted. Device-specific application packets that carry either commands or IoT d… view at source ↗
Figures from the paper (10 more)
Figure 6
Figure 6. Figure 6: RTSP packets with URL in D3D Camera [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: RTSP Packet Format with values. Similar to HTTP packets, we consider four distinguish￾able fields in a RTSP request packet: method, request-URI, RTSP-Version and CRLF (shown in [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 5
Figure 5. Figure 5: HTTP Packets requesting image in D3D Camera. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 8
Figure 8. Figure 8: TP-Link SmartHome/JSON Packets with values. [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: IoTFuzzSentry Structure. summary of vulnerabilities is shown in [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 11
Figure 11. Figure 11: TP-Link SmartHome/JSON packets with Command [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: Our classification of vulnerability packages in Co [PITH_FULL_IMAGE:figures/full_fig_p008_12.png]
Figure 14
Figure 14. Figure 14: Mutated URIs for D3D 003 vulnerability [PITH_FULL_IMAGE:figures/full_fig_p009_14.png]
Figure 15
Figure 15. Figure 15: Report for D3D 003 vulnerability. are identified for each of the test cases executed. The more unique statements, the higher the coverage. In our case, the code executing in an IoT device is not available, and hence, we perform black-box fuzzing. However, it may respo…
Figure 16
Figure 16. Figure 16: Vulnerability D3D 000 in .yaml file TABLE 4: Response Coverage using RTSP responses for live video feed and HTTP responses for live images. IPCam Response Coverage RTSP URL Responses for Live Video Streaming HTTP URL Responses for Live Image Extraction Valid Invalid V…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

80 extracted references · 2 linked inside Pith

  1. [25]

    Anonymous,

    Anonymous, “Anonymous,” https://github.com/ Anonymous120386/Anonymous, 2024

    2024

  2. [1]

    Internet of things (iot) total annual revenue worldwide from 2020 to 2030,

    S. Inc., “Internet of things (iot) total annual revenue worldwide from 2020 to 2030,” https://www.statista. com/statistics/1194709/iot-revenue-worldwide/, 2023

    arXiv 2020

  3. [2]

    Current research on internet of things (iot) security: A survey,

    W. H. Hassan et al., “Current research on internet of things (iot) security: A survey,” Computer networks, vol. 148, pp. 283–294, 2019

    2019

  4. [3]

    The impact of iot security labelling on con- sumer product choice and willingness to pay,

    S. D. Johnson, J. M. Blythe, M. Manning, and G. T. Wong, “The impact of iot security labelling on con- sumer product choice and willingness to pay,” PloS one, vol. 15, no. 1, p. e0227800, 2020

    2020

  5. [4]

    Will products li- ability litigation help protect iot users from cyber- physical attacks?

    J. R. Fichtner and T. J. Strader, “Will products li- ability litigation help protect iot users from cyber- physical attacks?” Journal of International Technology and Information Management, vol. 31, no. 1, pp. 79–96, 2022

    2022

  6. [5]

    Demystifying iot security: An ex- haustive survey on iot vulnerabilities and a first em- pirical look on internet-scale iot exploitations,

    N. Neshenko, E. Bou-Harb, J. Crichigno, G. Kaddoum, and N. Ghani, “Demystifying iot security: An ex- haustive survey on iot vulnerabilities and a first em- pirical look on internet-scale iot exploitations,” IEEE Communications Surveys & Tutorials, vol. 21, pp. 2702–2733, 2019

    2019

  7. [6]

    A survey on inter- net of things security: Requirements, challenges, and solutions,

    H. HaddadPajouh, A. Dehghantanha, R. M. Parizi, M. Aledhari, and H. Karimipour, “A survey on inter- net of things security: Requirements, challenges, and solutions,” Internet of Things, vol. 14, p. 100129, 2021

    2021

  8. [7]

    The se- curity of ip-based video surveillance systems,

    N. Kalbo, Y. Mirsky, A. Shabtai, and Y. Elovici, “The se- curity of ip-based video surveillance systems,”Sensors, 2020

    2020

Show all 80 references
  1. [8]

    150,000 verkada security cam- eras hacked—to make a point,

    M. Labs, “150,000 verkada security cam- eras hacked—to make a point,” https: //www.malwarebytes.com/blog/news/2021/03/ 150000-verkada-security-cameras-hacked-to-make-a-point

    2021

  2. [9]

    The dark side of the internet: Attacks, costs and responses,

    W. Kim, O.-R. Jeong, C. Kim, and J. So, “The dark side of the internet: Attacks, costs and responses,” Information systems, vol. 36, no. 3, pp. 675–705, 2011

    2011

  3. [10]

    Discovering and understanding the security hazards in the interactions between{IoT} devices, mobile apps, and clouds on smart home plat- forms,

    W. Zhou, Y. Jia, Y. Yao, L. Zhu, L. Guan, Y. Mao, P . Liu, and Y. Zhang, “Discovering and understanding the security hazards in the interactions between{IoT} devices, mobile apps, and clouds on smart home plat- forms,” in 28th USENIX security symposium, 2019

    2019

  4. [11]

    U- fuzz: Stateful fuzzing of iot protocols on cots de- vices,

    Z. Shang, M. E. Garbelini, and S. Chattopadhyay, “U- fuzz: Stateful fuzzing of iot protocols on cots de- vices,” in 2024 IEEE Conference on Software Testing, Verification and Validation (ICST), 2024, pp. 209–220

    2024

  5. [12]

    Fuzzing: a survey,

    J. Li, B. Zhao, and C. Zhang, “Fuzzing: a survey,” Cybersecurity, 2018

    2018

  6. [13]

    Demystify the fuzzing methods: A comprehensive survey,

    S. Mallissery and Y.-S. Wu, “Demystify the fuzzing methods: A comprehensive survey,” ACM Computing Surveys, vol. 56, no. 3, pp. 1–38, 2023

    2023

  7. [14]

    Fuzzing: Art, science, and engineering,

    V . J. Manes, H. Han, C. Han, S. K. Cha, M. Egele, E. J. Schwartz, and M. Woo, “Fuzzing: Art, science, and engineering,” arXiv preprint arXiv:1812.00140, 2018

    2018 arXiv

  8. [15]

    Aot-attack on things: A security analysis of iot firmware updates,

    M. Ibrahim, A. Continella, and A. Bianchi, “Aot-attack on things: A security analysis of iot firmware updates,” in IEEE 8th European Symposium on Security and Privacy (EuroS&P). IEEE (EuroS&P), 2023

    2023

  9. [16]

    Siotfuzzer: fuzzing web interface in iot firmware via stateful message generation,

    H. Zhang, K. Lu, X. Zhou, Q. Yin, P . Wang, and T. Yue, “Siotfuzzer: fuzzing web interface in iot firmware via stateful message generation,” Applied Sciences, 2021

    2021

  10. [17]

    Snipuzz: Black-box fuzzing of iot firmware via message snippet inference,

    X. Feng, R. Sun, X. Zhu, M. Xue, S. Wen, D. Liu, S. Nepal, and Y. Xiang, “Snipuzz: Black-box fuzzing of iot firmware via message snippet inference,” in ACM SIGSAC, 2021

    2021

  11. [18]

    Libfuzzer – a library for coverage-guided fuzz testing

    L. 15.0.0git documentation., “Libfuzzer – a library for coverage-guided fuzz testing.” https://www.llvm. org/docs/LibFuzzer.html

  12. [19]

    Diane: Identifying fuzzing triggers in apps to generate under-constrained inputs for iot devices,

    N. Redini, A. Continella, D. Das, G. De Pasquale, N. Spahn, A. Machiry, A. Bianchi, C. Kruegel, and G. Vigna, “Diane: Identifying fuzzing triggers in apps to generate under-constrained inputs for iot devices,” in IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 484–500

    2021

  13. [20]

    Fiotfuzzer: Response-based black-box fuzzing for iot devices,

    Z. Xu, W. Huang, W. Fan, and Y. Cheng, “Fiotfuzzer: Response-based black-box fuzzing for iot devices,” in 2022 IEEE/ACIS 22nd International Conference on Computer and Information Science (ICIS). IEEE IEEE/ACIS 22nd International Conference on Com- puter and Information Science...

    2022

  14. [21]

    Iotfuzzer: Discovering memory corruptions in iot through app- based fuzzing

    J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. Lau, M. Sun, R. Yang, and K. Zhang, “Iotfuzzer: Discovering memory corruptions in iot through app- based fuzzing.” in NDSS, 2018

    2018

  15. [22]

    Baseline security criteria for consumer iot devicesm,

    N. I. of Standards and T. (NIST), “Baseline security criteria for consumer iot devicesm,” https://www. nist.gov/system/files/documents/2021/08/31/IoT% 20White%20Paper%20-%20Final%202021-08-31.pdf, 2021

    2021

  16. [23]

    Iot- fuzzsentry: Hunting bugs in the iot wilderness in oper- ational phase using payload fuzzing,

    P . R. Chaudhary, N. P . Krishna, and R. R. Maiti, “Iot- fuzzsentry: Hunting bugs in the iot wilderness in oper- ational phase using payload fuzzing,” in Proceedings of the Fourteenth ACM Conference on Data and Application Security and Privacy, 2024

    2024

  17. [24]

    Cotopaxi,

    Samsung, “Cotopaxi,” https://github.com/Samsung/ cotopaxi

  18. [26]

    Over: Overhauling vulnerability detection for iot through an adaptable and automated static analysis framework,

    V . Sachidananda, S. Bhairav, and Y. Elovici, “Over: Overhauling vulnerability detection for iot through an adaptable and automated static analysis framework,” in ACM Symposium on Applied Computing, 2020, pp. 729–738

    2020

  19. [27]

    Static analysis for discovering iot vulnerabilities,

    P . Ferrara, A. K. Mandal, A. Cortesi, and F. Spoto, “Static analysis for discovering iot vulnerabilities,” International Journal on Software Tools for Technology Transfer, vol. 23, pp. 71–88, 2021

    2021

  20. [28]

    Discovering iot physical channel vulnerabil- ities,

    M. O. Ozmen, X. Li, A. Chu, Z. B. Celik, B. Hoxha, and X. Zhang, “Discovering iot physical channel vulnerabil- ities,” in ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 2415–2428

    2022

  21. [29]

    A survey of security vulnerability analysis, discovery, detection, and mitigation on iot devices,

    M. Yu, J. Zhuge, M. Cao, Z. Shi, and L. Jiang, “A survey of security vulnerability analysis, discovery, detection, and mitigation on iot devices,” Future Internet, vol. 12, no. 2, 2020. 13

    2020

  22. [30]

    Security analysis of iot frame- works using static taint analysis,

    T. Yavuz and C. Brant, “Security analysis of iot frame- works using static taint analysis,” in ACM Conference on Data and Application Security and Privacy, 2022, pp. 203–213

    2022

  23. [31]

    Cross-program taint analysis for iot sys- tems,

    A. Mandal, P . Ferrara, Y. Khlyebnikov, A. Cortesi, and F. Spoto, “Cross-program taint analysis for iot sys- tems,” in ACM Symposium on Applied Computing, 2020, pp. 1944–1952

    2020

  24. [32]

    Driller: Augmenting fuzzing through selective sym- bolic execution

    N. Stephens, J. Grosen, C. Salls, A. Dutcher, R. Wang, J. Corbetta, Y. Shoshitaishvili, C. Kruegel, and G. Vigna, “Driller: Augmenting fuzzing through selective sym- bolic execution.” in NDSS, vol. 16, no. 2016, 2016, pp. 1–16

    2016

  25. [33]

    An ex- ploratory survey of hybrid testing techniques involving symbolic execution and fuzzing,

    S. Ognawala, A. Petrovska, and K. Beckers, “An ex- ploratory survey of hybrid testing techniques involving symbolic execution and fuzzing,” 2017

    2017

  26. [34]

    Improving function coverage with munch: a hybrid fuzzing and directed symbolic ex- ecution approach,

    S. Ognawala, T. Hutzelmann, E. Psallida, and A. Pretschner, “Improving function coverage with munch: a hybrid fuzzing and directed symbolic ex- ecution approach,” in ACM Symposium on Applied Computing, New York, NY, USA, 2018, p. 1475–1482

    2018

  27. [35]

    Fuzzing the internet of things: A review on the techniques and challenges for efficient vulnerability discovery in embedded systems,

    M. Eceiza-Olaizola, N. Privacy, and M. Iturbe, “Fuzzing the internet of things: A review on the techniques and challenges for efficient vulnerability discovery in embedded systems,” IEEE Internet of Things Journal, vol. PP , pp. 1–1, 02 2021

    2021

  28. [36]

    West- world: Fuzzing-assisted remote dynamic symbolic ex- ecution of smart apps on iot cloud platforms,

    L. Luo, Q. Zeng, B. Yang, F. Zuo, and J. Wang, “West- world: Fuzzing-assisted remote dynamic symbolic ex- ecution of smart apps on iot cloud platforms,” in Proceedings of the 37th Annual Computer Security Applications Conference, New York, NY, USA, 2021, p. 982–995

    2021

  29. [37]

    MINER: A hybrid Data-Driven approach for REST API fuzzing,

    C. Lyu, J. Xu, S. Ji, X. Zhang, Q. Wang, B. Zhao, G. Pan, W. Cao, P . Chen, and R. Beyah, “MINER: A hybrid Data-Driven approach for REST API fuzzing,” in 32nd USENIX Security Symposium (USENIX Security 23), aug 2023, pp. 4517–4534

    2023

  30. [38]

    Mock: Optimizing kernel fuzzing mutation with context-aware dependency,

    J. Xu, X. Zhang, S. Ji, Y. Tian, B. Zhao, Q. Wang, P . Cheng, and J. Chen, “Mock: Optimizing kernel fuzzing mutation with context-aware dependency,” 2024

    2024

  31. [39]

    Physical devices-agnostic hybrid fuzzing of iot firmware,

    L. Situ, C. Zhang, L. Guan, Z. Zuo, L. Wang, X. Li, P . Liu, and J. Shi, “Physical devices-agnostic hybrid fuzzing of iot firmware,” IEEE Internet of Things Journal, vol. 10, no. 23, pp. 20 718–20 734, 2023

    2023

  32. [40]

    Hotfuzz: Dis- covering temporal and spatial denial-of-service vulner- abilities through guided micro-fuzzing,

    W. Blair, A. Mambretti, S. Arshad, M. Weissbacher, W. Robertson, E. Kirda, and M. Egele, “Hotfuzz: Dis- covering temporal and spatial denial-of-service vulner- abilities through guided micro-fuzzing,” ACM Trans. Priv. Secur., vol. 25, no. 4, jul 2022

    2022

  33. [41]

    {kAFL}:{Hardware-Assisted}feed- back fuzzing for{OS}kernels,

    S. Schumilo, C. Aschermann, R. Gawlik, S. Schinzel, and T. Holz, “{kAFL}:{Hardware-Assisted}feed- back fuzzing for{OS}kernels,” in USENIX security symposium, 2017, pp. 167–182

    2017

  34. [42]

    Syztrust: State-aware fuzzing on trusted os designed for iot devices,

    Q. Wang, B. Chang, S. Ji, Y. Tian, X. Zhang, B. Zhao, G. Pan, C. Lyu, M. Payer, W. Wang, and R. Beyah, “Syztrust: State-aware fuzzing on trusted os designed for iot devices,” 2023

    2023

  35. [43]

    Syzkaller,

    V . D., “Syzkaller,” https://github.com/google/ syzkaller, 2015

    2015

  36. [44]

    Fuzzing with spike

    B. S. ., “Fuzzing with spike.” https://samsclass.info/ 127/proj/p16-spike.htmr, 2015

    2015

  37. [45]

    Autofuzz: Auto- mated network protocol fuzzing framework,

    S. Gorbunov and A. Rosenbloom, “Autofuzz: Auto- mated network protocol fuzzing framework,” Ijcsns, vol. 10, no. 8, p. 239, 2010

    2010

  38. [46]

    Snooze: Toward a stateful network protocol fuzzer,

    G. Banks, M. Cova, V . Felmetsger, K. Almeroth, R. Kem- merer, and G. Vigna, “Snooze: Toward a stateful network protocol fuzzer,” in Information Security. Springer, 2006

    2006

  39. [47]

    Go or no go: Differential fuzzing of native and c libraries,

    A. Sorniotti, M. Weissbacher, and A. Kurmus, “Go or no go: Differential fuzzing of native and c libraries,” in 2023 IEEE Security and Privacy Workshops (SPW). Los Alamitos, CA, USA: IEEE Computer Society, may 2023, pp. 349–363. [Online]. Available: https://doi.ieeecomputersoci...

    2023

  40. [48]

    Fuzzing api error handling behaviors using coverage guided fault injection,

    S. Sharma, S. R. Tanksalkar, S. Cherupattamoolayil, and A. Machiry, “Fuzzing api error handling behaviors using coverage guided fault injection,” in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, New York, NY, USA, 2024, p. 1495–1509

    2024

  41. [49]

    American fuzzy lop,

    M. Zalewski, “American fuzzy lop,” https://lcamtuf. coredump.cx/afl/

  42. [50]

    Rpfuzzer: A frame- work for discovering router protocols vulnerabili- ties based on fuzzing,

    Z. Wang, Y. Zhang, and Q. Liu, “Rpfuzzer: A frame- work for discovering router protocols vulnerabili- ties based on fuzzing,” Transactions on Internet and Information Systems (TIIS), vol. 7, no. 8, pp. 1989–2009, 2013

    1989

  43. [51]

    Openrce/sulley: A pure-python fully au- tomated and unattended fuzzing framework

    OpenRCE, “Openrce/sulley: A pure-python fully au- tomated and unattended fuzzing framework.” https: //github.com/OpenRCE/sulley

  44. [52]

    A fork and successor of the sulley fuzzing framework,

    Pereyda, J., “A fork and successor of the sulley fuzzing framework,” https://github.com/jtpereyda/ boofuzz(accessedon27March2021)

  45. [53]

    FuzzGen: Automatic fuzzer generation,

    K. Ispoglou, D. Austin, V . Mohan, and M. Payer, “FuzzGen: Automatic fuzzer generation,” in USENIX Security Symposium, 2020

    2020

  46. [54]

    Discover- ing vulnerabilities in cots iot devices through black- box fuzzing web management interface,

    D. Wang, X. Zhang, T. Chen, and J. Li, “Discover- ing vulnerabilities in cots iot devices through black- box fuzzing web management interface,” Security and Communication Networks, vol. 2019, 2019

    2019

  47. [55]

    HTTP Authentication: Basic and Digest Access Authentication,

    P . J. Franks, P . Hallam-Baker, L. Stewart, J. L. Hostetler, S. Lawrence, P . J. Leach, and A. Luotonen, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, jun 1999. [Online]. Available: https://www.rfc-editor.org/info/rfc2617

    1999

  48. [56]

    Real Time Streaming Protocol (RTSP),

    A. Rao, R. Lanphier, and H. Schulzrinne, “Real Time Streaming Protocol (RTSP),” RFC 2326, Apr. 1998. [Online]. Available: https://www.rfc-editor.org/info/ rfc2326

    1998

  49. [57]

    Display filter reference: Tp-link smart home protocol

    Wireshark, “Display filter reference: Tp-link smart home protocol.” https://www.wireshark.org/docs/ dfref/t/tplink-smarthome.html

  50. [58]

    Tp-link wifi smartplug client and wireshark dissector,

    softScheck, “Tp-link wifi smartplug client and wireshark dissector,” https://github.com/ softScheck/tplink-smartplug/blob/master/ tplink-smarthome-commands.txt, 2023

    2023

  51. [59]

    Python kasa,

    P . K. Developers, “Python kasa,” https://github.com/ python-kasa, 2024

    2024

  52. [60]

    Vlc media player for debian gnu/linux,

    V . organization, “Vlc media player for debian gnu/linux,” https://www.videolan.org/vlc/ 14 download-debian.html, 2022

    2022

  53. [61]

    ispy and agentdvr,

    iSpyConnect, “ispy and agentdvr,” https://www. ispyconnect.com/, 2024

    2024

  54. [62]

    Cameradar,

    Ullaakut, “Cameradar,” https://github.com/ Ullaakut/cameradar, 2022

    2022

  55. [63]

    Zeller, R

    A. Zeller, R. Gopinath, M. Bohme, G. Fraser, and C. Holler, The Fuzzing Book. CISPA Helmholtz Center for Information Security, 2024

    2024

  56. [64]

    Added payload d3d 000 request.raw payload #11

    P . R. Chaudhary, N. P . Krishna, and R. R. Maiti, “Added payload d3d 000 request.raw payload #11.” https:// github.com/Samsung/cotopaxi/pull/11, 2024

    2024

  57. [65]

    {AFL++}: Combining incremental steps of fuzzing research,

    A. Fioraldi, D. Maier, H. Eissfeldt, and M. Heuse, “{AFL++}: Combining incremental steps of fuzzing research,” in USENIX WOOT 20, 2020

    2020

  58. [66]

    Aflnet: A greybox fuzzer for network protocols,

    V . Pham, M. B¨ohme, and A. Roychoudhury, “Aflnet: A greybox fuzzer for network protocols,” in IEEE ICST, 2020

    2020

  59. [67]

    Indian computer emergency response team,

    M. O. Electronics and I. Technology, “Indian computer emergency response team,” https://www.cert-in.org. in/, 2024

    2024

  60. [68]

    Cve-2024-41623,

    P . R. Chaudhary and R. R. Maiti, “Cve-2024-41623,” https://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2024-41623

    2024

  61. [69]

    CVE- 2024-42531,

    R. R. M. Priyanka Rushikesh Chaudhary, “CVE- 2024-42531,” https://cve.mitre.org/cgi-bin/cvename. cgi?name=CVE-2024-42531

    2024

  62. [70]

    Security protocols for iot,

    J. Cynthia, H. Parveen Sultana, M. Saroja, and J. Senthil, “Security protocols for iot,” Ubiquitous computing and computing security of IoT, pp. 1–28, 2019

    2019

  63. [71]

    Security of iot application layer protocols: Challenges and findings,

    G. Nebbione and M. C. Calzarossa, “Security of iot application layer protocols: Challenges and findings,” Future Internet, vol. 12, no. 3, 2020. [Online]. Available: https://www.mdpi.com/1999-5903/12/3/55

    2020

  64. [72]

    Security in the internet of things applica- tion layer: requirements, threats, and solutions,

    M. Abbasi, M. Plaza-Hernandez, J. Prieto, and J. M. Corchado, “Security in the internet of things applica- tion layer: requirements, threats, and solutions,” IEEE Access, 2022

    2022

  65. [73]

    Fuzzowski network fuzzer,

    M. Rivas, “Fuzzowski network fuzzer,” https://github. com/nccgroup/fuzzowski

  66. [74]

    Doona - network fuzzing tool,

    E. Marcussen, “Doona - network fuzzing tool,” https: //github.com/wireghoul/doona

  67. [75]

    Shodan search engine,

    Shodan, “Shodan search engine,” https://www. shodan.io/dashboard, 2024

    2024

  68. [76]

    Analysis of dtls implementations using protocol state fuzzing,

    P . Fiteruau-Brocstean, B. Jonsson, R. Merget, J. De Ruiter, K. Sagonas, and J. Somorovsky, “Analysis of dtls implementations using protocol state fuzzing,” in Proceedings of the 29th USENIX Conference on Security Symposium, ser. SEC’20. USA: USENIX Association, 2020

    2020

  69. [77]

    A survey of protocol fuzzing,

    X. Zhang, C. Zhang, X. Li, Z. Du, B. Mao, Y. Li, Y. Zheng, Y. Li, L. Pan, Y. Liu, and R. Deng, “A survey of protocol fuzzing,” ACM Computing Surveys, vol. 57, no. 2, p. 1–36, Oct. 2024. [Online]. Available: http://dx.doi.org/10.1145/3696788

    2024 doi

  70. [78]

    Quic-fuzz: An effective greybox fuzzer for the quic protocol,

    K. K. Ang and D. C. Ranasinghe, “Quic-fuzz: An effective greybox fuzzer for the quic protocol,” 2025. [Online]. Available: https://arxiv.org/abs/2503.19402

    2025 arXiv

  71. [79]

    Peach fuzzer,

    GitLab, “Peach fuzzer,” https://peachtech.gitlab.io/ peach-fuzzer-community/, 2020

    2020

  72. [80]

    Honggfuzz,

    A. Helin., “Honggfuzz,” https://github.com/aoh/ radamsa

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.