{"id":"c3caf567-da67-4152-bf22-e2ff52b67cb7","arxiv_id":"1908.07835","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Memory dumps of MQTT brokers and clients reveal plaintext topics, messages, IPs, and credentials, even when the network traffic is TLS-encrypted.","lead":"This paper shows that when MQTT messaging programs run on a computer, their memory dumps contain readable copies of topic names, messages, IP addresses, and sometimes passwords. This matters because encrypting network traffic does not protect these secrets once an attacker can read the device's memory.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"TLS-resistance claim in Section V.B is asserted but not demonstrated: no TLS configuration, handshake/ciphertext capture, or TLS-specific dump excerpt is reported.","rationale":"I read the paper's strongest claim as including the TLS-resistance result, because that is what makes the work relevant beyond plaintext memory forensics. The reader's attribution/control concern is real, but the process-level dumps and the MQTT-specific strings in the appendix already give partial support for attribution; the TLS claim has no such supporting exhibit. The two concerns are related (both are missing verification data), but they are not the same, so agreement is partial. Verdict remains conditional: a single reproducible TLS experiment would settle it, and the rest of the inventory is plausible enough not to merit rejection.","tokens_in":4175,"tokens_out":6478,"duration_ms":69339,"concrete_test":"Reproduce Section V.B using Mosquitto with TLS enabled on port 8883: configure a CA-signed or self-signed certificate, run tcpdump -w capture.pcap during the publish/subscribe session, and confirm the TLS ClientHello/ServerHello and encrypted application data in Wireshark. Then take a procdump of the broker and search for the topic name and message string with the same hex-editor procedure. If the plaintext strings appear while the pcap shows encrypted payloads, the TLS claim is confirmed; if no TLS handshake is captured or the strings are absent, the claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's most consequential claim—that encrypted MQTT traffic can still be read from process memory—rests entirely on Section V.B. The section states that brokers were 'running on port 8883 and which uses TLS encryption' and that 'network capturing tools could not display the contents of the packets due to TLS layer,' followed by the conclusion that memory dumps still reveal topic names, messages, and client IDs. No TLS server/client configuration, certificate details, cipher suite, or captured TLS handshake is reported. Port 8883 is conventionally associated with MQTT over TLS, but a listener on that port can be plaintext, and a self-signed certificate may still be configured insecurely; nothing in the paper rules out that the memory dumps came from a session that was not actually TLS-encrypted. The footnote 'Results are same which is displayed in Table -1' is not adequate evidence, because Table 1 and all appendix excerpts were produced from plaintext experiments. If the TLS session was not genuinely established, the central security conclusion of the paper—that encryption does not protect MQTT data in memory—is unsupported. This is a correctness risk, not merely missing polish.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":4358,"tokens_out":3262,"duration_ms":37275,"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":[{"comment":"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.","section":"V.B"},{"comment":"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.","section":"V.A"},{"comment":"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.","section":"IV and V"}],"minor_comments":[{"comment":"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.","section":"Section V.A"},{"comment":"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":"Appendix"},{"comment":"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.'","section":"Section V.B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads like a short workshop demonstration rather than a fully developed journal article. The authors should be given the opportunity to strengthen the TLS evidence and add control experiments, but if the venue expects comprehensive experimental methodology, the current level of detail is marginal. The plaintext memory-extraction claim is plausible and worth publishing once the load-bearing gaps are addressed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"I've read the MQTT memory forensics paper. The short version: the plaintext artifact inventory is credible and useful; the TLS claim in Section V.B is not supported by the evidence on the page. The stress-test note is on target.\n\nWhat's actually new is the catalog itself. The paper lists recoverable strings from five brokers and three clients—client IDs, topic names, message payloads, broker IPs, file paths. Tables I and II, with the memory dump screenshots in the appendix, are the substance. That is a modest but real contribution; I'm not aware of another paper with exactly this inventory. The method is simple—procdump and a hex editor—but for a checklist of where to look in a process dump, it works. There's no circular reasoning or forced assumptions; these are direct observations, and the plaintext screenshots back them up.\n\nThree soft spots, in order of severity. First, no control dumps. The paper says the dump was manually examined but doesn't say how the authors excluded data from other processes, libraries, or the OS. Attribution of each string to the MQTT application is therefore uncertain. Second, the search procedure is not repeatable—no keyword list, no success rate, no raw dump archive. An independent lab can't reproduce the exact findings. These two are standard rigor issues for memory forensics and would be fixable.\n\nThe third is the real problem: the TLS-resistance claim. Section V.B states that Mosquitto, Mosca, and HiveMQ were run on port 8883 with TLS encryption, and that memory dumps still revealed topic names, messages, and client IDs. But the paper gives no TLS configuration, no certificate details, no cipher suite, and no captured handshake or TLS-encrypted traffic. Port 8883 is conventional for MQTT over TLS, but it's not proof. And the footnote 'Results are same which is displayed in Table -1' is not evidence, because Table I was produced from plaintext experiments. So the claim that encryption doesn't protect MQTT data in memory is not demonstrated. This is a load-bearing gap, not missing polish. The stress-test note gets this exactly right.\n\nThe plaintext part probably holds up, and the paper is completely honest about its manual approach—it doesn't overreach in the methodology, only in that TLS section. Who is this for? Forensic investigators and MQTT system administrators who want a quick checklist of where to look in a memory dump. It's not going to change how IoT forensics is done, but it's a convenient reference.\n\nFor publication, I'd want a revision: add baseline dumps from a clean VM, define the search protocol, and either provide real TLS evidence or cut the TLS section down to a stated open question. I'd send it to peer review with that expectation. The artifact inventory deserves to be archived, but only with the missing controls and TLS verification. Engage it, but demand the extra evidence.","headline":"Useful and credible plaintext artifact inventory for MQTT memory forensics, but the paper's headline TLS claim is not supported by the reported evidence.","tokens_in":4873,"tokens_out":2679,"would_cite":false,"duration_ms":28208,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"MQTT applications leave recoverable plaintext in process memory even when TLS encrypts traffic.","keywords":["MQTT","memory forensics","IoT forensics","process memory dump","TLS/SSL","broker","client applications"],"falsifier":"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.","tokens_in":3974,"feed_emoji":"🧠","tokens_out":6669,"duration_ms":58176,"temperature":0.7,"pith_summary":"The paper sets out to show that MQTT broker and client applications store sensitive protocol data in their own process memory, and that this data survives as readable strings in a memory dump. The authors run five different brokers and three different clients in Linux virtual machines, transfer messages over MQTT, capture process dumps, and inspect the dumps with a hex editor. They report recovering topic names, subscriber messages, client IDs, broker and client IP addresses, execution paths, startup timestamps, and logged-in user credentials. In the TLS/SSL case, the same artifacts were still readable from the broker dump, so the paper's point is that endpoint memory, not just network encryption, must be protected.","feed_headline":"Memory dumps reveal MQTT messages even when TLS encrypts the wire","feed_subtitle":"Process memory on broker and client machines yields topics, messages, and credentials that network sniffing misses.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Motivates the approach by showing that IoT device memory and companion apps leave recoverable digital traces useful to forensic examiners.","marker":"[2]"},{"why":"Supplies the MQTT publish/subscribe attack-scenario context that the paper extends from network interception to host memory acquisition.","marker":"[3]"},{"why":"Documents the current MQTT security landscape built on traffic-layer protections, the baseline that memory-based disclosure would bypass.","marker":"[4]"},{"why":"Describes the MQTT topic hierarchy and publish/subscribe model used to identify the recovered string artifacts.","marker":"[5]"},{"why":"Establishes the IoT security-and-forensics challenge that motivates examining devices and applications as evidence sources.","marker":"[6]"}],"fun_headline_variants":["Memory dumps expose MQTT data despite TLS","MQTT secrets recoverable from memory dumps","Forensic memory grabs MQTT topics and credentials","RAM analysis uncovers MQTT messages even with TLS","MQTT session data leaks from device memory"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Memory dumps expose MQTT data despite TLS","MQTT secrets recoverable from memory dumps","Forensic memory grabs MQTT topics and credentials","RAM analysis uncovers MQTT messages even with TLS","MQTT session data leaks from device memory"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000269,"raw_usage":{"total_tokens":1564,"prompt_tokens":828,"completion_tokens":736,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":444,"completion_tokens_details":{"reasoning_tokens":662}},"tokens_in":444,"tokens_out":736,"duration_ms":6823,"temperature":1.0,"reasoning_tokens":662,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T12:19:25.216459+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"D igital Investigation Elsevier, vol","cited_arxiv_id":null,"evidence_quote":"Motivates the approach by showing that IoT device memory and companion apps leave recoverable digital traces useful to forensic examiners."},{"cited_title":"Attack Scenarios and Security Analysis of MQTT Communication Protocol in IoT System","cited_arxiv_id":null,"evidence_quote":"Supplies the MQTT publish/subscribe attack-scenario context that the paper extends from network interception to host memory acquisition."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the current MQTT security landscape built on traffic-layer protections, the baseline that memory-based disclosure would bypass."},{"cited_title":"A Survey on MQTT: A Protocol of Internet of Things (IOT)","cited_arxiv_id":null,"evidence_quote":"Describes the MQTT topic hierarchy and publish/subscribe model used to identify the recovered string artifacts."},{"cited_title":"Internet of Things Security and Forensics: Challenges and Opportunities","cited_arxiv_id":null,"evidence_quote":"Establishes the IoT security-and-forensics challenge that motivates examining devices and applications as evidence sources."}],"review_version":1}