REVIEW 3 major objections 3 minor 7 references
Memory Forensic Analysis of MQTT Devices
T0 review · 3 major / 3 minor · reviewed 2026-08-14 · deepseek-v4-flash
Pith's one-line read MQTT applications leave recoverable plaintext in process memory even when TLS encrypts traffic.
desk verdict Useful and credible plaintext artifact inventory for MQTT memory forensics, but the paper's headline TLS claim is not supported by the reported evidence. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The mechanism that carries the argument is the volatile memory of the process under test. A running broker or client keeps MQTT control packets, topic strings, connection metadata, and configuration values in memory; taking a process dump freezes those bytes, and a hex editor lets the examiner locate human-readable strings that correspond to known MQTT fields. The work is a direct application: recognize artifacts by their structure (client ID format, topic path, CONNECT/SUBSCRIBE packet contents) and record which application produced them.
What would settle it
A baseline control experiment would settle the attribution question: dump the memory of an idle Linux VM before starting any MQTT application and check whether the same topic names, client IDs, and credentials appear; if they do, the reported artifacts are not specific to the broker or client process.
Extended reading notes
Core claim
The central discovery is that a running MQTT application leaves a readable copy of the protocol session in memory. In the broker experiments, the dump contained the full publish/subscribe packet details: the topic hierarchy, subscriber messages, client IDs such as mosqsub/12-ubuntu, client and broker IP addresses, the broker's execution path, and the time the broker started. In the TLS/SSL test on port 8883, the same categories of data were recovered even though traffic capture tools saw only ciphertext. On the client side, memory dumps of subscribers yielded the broker IP, topic name, and for one client the logged-in username and password. The paper concludes that anyone with access to a machine running an MQTT broker or client can recover communication contents directly from memory.
Load-bearing premise
The central claim depends on the assumption that the strings recovered from memory dumps come from the MQTT process itself, rather than from other software or leftover data in the virtual machine.
Editorial extensions
If this is right
- On a compromised broker host, TLS/SSL does not keep MQTT topics and messages confidential because the plaintext payloads sit in process memory.
- Forensic examiners can recover a communication log including topics, messages, client IDs, IP addresses, and timestamps from broker process dumps without intercepting the network.
- Client-side dumps can expose broker location, topic names, and for some clients stored username and password details, making client machines a viable evidence source.
- Recovered execution paths and startup timestamps provide event context that can help place when and how the MQTT application was run.
Reading between the lines
- One testable extension is to run the same dump-and-inspect procedure with a clean baseline VM: a memory dump taken before any MQTT process starts would show which recovered strings belong to the environment rather than to the broker or client.
- The credential recovery result suggests a broader attack path: anyone with memory access to a machine running a GUI MQTT client could harvest saved usernames and passwords and try them against other services; the paper does not test that reuse scenario.
- The same memory-disclosure mechanism probably applies to other publish/subscribe IoT protocols such as CoAP or AMQP, but the paper only examines MQTT and does not claim generality.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper describes a memory forensic analysis of MQTT broker and client applications running on Linux virtual machines. The authors use procdump to capture process memory dumps and a hex editor to manually search them. They report extracting client IDs, topic names, subscriber messages, IP addresses, broker installation paths, timestamps, and, in one client, logged-in user credentials. They further claim in Section V.B that when brokers run with TLS/SSL on port 8883, the same artifacts are recoverable from the broker's memory dump even though network captures cannot display the plaintext. The evidence consists of two artifact tables and seven appendix screenshots.
Significance. If the results hold, the paper provides a useful demonstration that MQTT endpoints leave sensitive communication artifacts in process memory and that transport-level encryption does not protect data once it is materialized in application memory. The paper's strengths are its direct experimental screenshots, the simplicity of the approach, and the fact that the central claim is an observational one rather than a derived or model-dependent result. No fitted parameters, constructed datasets, or self-cited load-bearing assumptions are present. However, the demonstrated evidence is currently anecdotal: the TLS claim is unsupported, the attribution of strings to specific processes is not controlled, and the manual search method is not reproducible from the description.
major comments (3)
- [V.B] The claim that encrypted MQTT traffic can still be read from memory dumps is not demonstrated. The text states that Mosquitto, Mosca, and HiveMQ were 'running on port 8883 and which uses TLS encryption,' but no TLS configuration, certificate details, cipher suites, or captured TLS handshake or ciphertext is reported. A listener on port 8883 can be plaintext if not actually configured for TLS, and the footnote that 'Results are same which is displayed in Table -1' does not transfer evidence because Table 1 and the appendix excerpts appear to come from the plaintext experiments. As written, the paper's most consequential conclusion—that encryption does not protect MQTT data in memory—is unsupported. The authors should either provide verifiable TLS session evidence (e.g., capture of the TLS handshake, configuration files, or a tool-based confirmation that port 8883 is TLS-enabled) or temper the claim to what the plaintext experiments support.
- [V.A] The string attribution is not backed by control experiments. The paper says the memory dump 'was manually examined' but does not describe how strings from other processes, loaded libraries, or residual data in the VM were excluded from the artifact inventory. Without a baseline dump of the same VM before the MQTT application starts, or memory-region/process mapping, the recovered strings (topics, messages, client IDs) could originate from unrelated software. This directly affects the validity of Tables I and II, which attribute every checked artifact to the broker or client application. The authors should add control dumps and a defined rule for assigning a string to the target process.
- [IV and V] The methodology is not reproducible. The paper does not report the procdump version or command line, the process identification method, the hex editor used, the specific byte patterns or strings searched, or the criteria for counting an artifact as recovered. Tables I and II report only binary checkmarks, with no quantitative success counts across repeated runs or across the different brokers/clients. To support the central claim that memory dumps reliably reveal this data, the authors should provide a step-by-step search protocol and, ideally, a script or command listing that an independent investigator can follow.
minor comments (3)
- [Section V.A] The paper says 'Table 1 describes name of the broker applications and data that was extracted,' but Table 1 as printed does not include row labels for each artifact type; the table would be clearer if the extracted-data rows were explicitly labeled in the table body.
- [Appendix] Figures 2 through 7 are referenced with inline descriptions but have no figure captions or cross-references in the main text; adding captions that state which broker/client and which configuration (plaintext or TLS) each snippet came from would improve traceability.
- [Section V.B] The phrase 'Results are same which is displayed in Table -1' is grammatically awkward and would be clearer as 'The results are the same as those displayed in Table I for the SSL-enabled brokers.'
Circularity Check
No circularity: the paper reports direct memory-dump observations and derives no predictive claim from fitted parameters or self-cited results.
full rationale
The paper's central claim is that sensitive MQTT artifacts can be recovered from process memory dumps of broker and client applications. This is presented as a direct experimental observation: memory dumps were taken with procdump and manually examined with a hex editor, and Table I, Table II, and the appendix list the recovered strings. There is no derivation chain in which an output quantity is defined in terms of an input quantity, no parameter is fitted and then renamed as a prediction, and no formal model whose conclusion is fixed by its assumptions. The only self-citation is reference [7], which includes an author of the present paper, and it is used to support the general point that MQTT security should include privacy and confidentiality; that claim is not the paper's empirical result and the citation is not load-bearing for the memory-extraction findings. The skeptical concern that the TLS/SSL experiment may not have genuinely established an encrypted session is a correctness or evidence-quality objection, not a circularity objection: even if the claim were unsupported, it would not reduce to the paper's own inputs by construction. Accordingly, no circular step is identified and the appropriate score is 0.
Assumptions & free parameters
assumptions (3)
- domain assumption Memory dumps produced by procdump faithfully represent the process memory of the target application.
- domain assumption Manual hex editor searches correctly attribute recovered strings to the MQTT application rather than unrelated data in the VM.
- domain assumption The Ubuntu virtual machine environment is representative of real-world MQTT deployments.
Cite this review
Pith. "Pith review of Memory Forensic Analysis of MQTT Devices." pith.science (2026). https://pith.science/paper/T5UGUCA4
@misc{pith2026190807835,
author = {Pith},
title = {Pith review of: Memory Forensic Analysis of MQTT Devices},
year = {2026},
howpublished = {\url{https://pith.science/paper/T5UGUCA4}},
note = {Machine review of arXiv:1908.07835}
}
read the original abstract
Internet of Things is revolutionizing the current era with its vast usage in number of fields such as medicine, automation, home security, smart cities, etc. As these IoT devices' uses are increasing, the threat to its security and to its application protocols are also increasing. Traffic passing over these protocol if intercepted, could reveal sensitive information and result in taking control of the entire IoT network. Scope of this paper is limited to MQTT protocol. MQTT (MQ Telemetry Transport) is a light weight protocol used for communication between IoT devices. There are multiple brokers as well as clients available for publishing and subscribing to services. For security purpose, it is essential to secure the traffic, broker and end client application. This paper demonstrates extraction of sensitive data from the devices which are running broker and client application.
Figures
Reference graph
Works this paper leans on
-
[1]
A. Jain, B. Sharma, & P. Gupta (2016). Internet of things: Archit ecture, security goals, and challenges — a survey. International Journal of Innovative Research in Science and Engineering, vol. 2, no. 4, pp. 154– 163
work page 2016
-
[2]
D igital Investigation Elsevier, vol
Francesco Servida, Eoghan Casey(2019).IoT forensic challenges and opportunities for digital traces. D igital Investigation Elsevier, vol. 28, pp. S22-S29
work page 2019
-
[3]
Attack Scenarios and Security Analysis of MQTT Communication Protocol in IoT System
Syaiful Andy, Budi Rahardjo, Bagus Hanindhito. Attack Scenarios and Security Analysis of MQTT Communication Protocol in IoT System
-
[4]
Perrone, Giovanni & Vecchio, Massimo & Pecori, Riccardo & Giaffreda, Raffaele. (2017). The Day After Mirai: A Survey on MQTT Security Solutions After the Largest Cyber-attack Carried Out through an Army of IoT Devices. 246-253. 10.5220/0006287302460253
-
[5]
A Survey on MQTT: A Protocol of Internet of Things (IOT)
Soni, Dipa & Makwana, Ashwin(2017). A Survey on MQTT: A Protocol of Internet of Things (IOT)
work page 2017
-
[6]
Internet of Things Security and Forensics: Challenges and Opportunities
Mauro Conti, Ali Dehghantanha, Katrin Fran ke, Steve Watson (2018). Internet of Things Security and Forensics: Challenges and Opportunities
work page 2018
-
[7]
Anthraper, Joseph Jose and Kotak, Jaidip, Security, Privacy and Forensic Concern of Mqtt Protocol (March 19, 2019). In Proceedings of International Conference on Sustainable Computing in Science, Technology and Management (SUSCOM-2019), February 26 - 28, 2019. Broker IP Message Timestamp
work page 2019
Reviewed August 14, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.