{"id":"2cb389c1-19cf-4f06-a7a7-26aaa0c3384b","arxiv_id":"1908.09204","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"Minerva automatically unpacks system-wide Windows malware into PE files with valid import tables and patched API calls, and its evaluation shows fewer spurious API calls and more detected multi-process propagation than the compared unpacker.","lead":"Minerva is a new automated tool that unpacks Windows malware by tracing how malicious code spreads across the whole system and rebuilding the unpacked code as normal executable files. It aims to give malware analysts clean PE files with working import tables instead of messy memory dumps.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Taint model does not handle implicit flows; Minerva's claim of capturing code generated by benign code may fail for control-flow-dependent writes, and the benchmarks do not test this case.","rationale":"The reader's weakest-assumption analysis identified the dependence on dynamic taint analysis propagating exactly along all relevant information flows, including implicit flows. My stress-test agrees with that assessment and makes it more concrete: Algorithm 2 explicitly taints outputs only for instructions in the malware execution trace (those whose addresses are tainted), so any code generation performed by benign code under control-flow influence of tainted data would not be captured unless the underlying PANDA taint plugin provides implicit-flow propagation as an unstated default. The paper presents no evidence that it does, and the benchmarks do not include such a case. This is a correctness risk, not merely a consensus disagreement, because the paper's central claim is about precision and generality relative to the write-then-execute heuristic. The rest of the design (execution waves, API correlation, PE reconstruction) is conditional on this taint foundation. I therefore support the reader's CONDITIONAL verdict, with no change. The concrete test I propose would settle whether the implicit-flow gap is real; if it fails, the paper's central claim overstates Minerva's generality and would need a caveat or a revised propagation model.","tokens_in":26417,"tokens_out":6765,"duration_ms":67170,"concrete_test":"Construct a synthetic sample in which the malware injects a tainted flag value into a benign process and arranges, via a code-reuse callback, for the benign process to execute a loop that writes one byte of shellcode only when a branch on the tainted flag is true. Run Minerva on this sample. If the written shellcode is not included in an execution wave of the benign process, the claim that waves are independent of the writer is false for implicit flows. If it is included, instrument the taint plugin to confirm whether the taint arrived through explicit data-flow in the benign thread or through implicit-flow propagation; either way, the result should be reported as a separate benchmark item in data set #1.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The malware execution trace is defined as instructions whose memory is tainted (Definition 1, Algorithm 1 lines 7-8), and the propagation model in Section 3.3 taints all outputs of instructions in the trace (Algorithm 2 lines 3-5). However, no mechanism is described for propagating taint along implicit flows. Consequently, if benign code uses tainted malware data as a branch condition to control which bytes are written to executable memory, the writing instruction is not in the malware execution trace (its address is in benign code, not tainted) and its output is not explicitly tainted. The resulting generated code would not be tainted and would be missed by the wave collector. This directly contradicts the Section 4.2 claim that execution waves capture dynamically generated code independent of who wrote the code. The synthetic benchmarks (D1-D4, C1-C5, M1) all generate code through explicit data-flow: writes from tainted instructions or injected code that becomes tainted by direct data copies. None exercises the implicit-flow scenario that motivates Limitation 1.1. Since the central precision claim depends on the taint set exactly capturing all dynamically generated malicious code, the missing implicit-flow handling is a load-bearing gap in the argument.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Minerva, an automatic malware-unpacking system that combines full-system dynamic taint analysis (built on PANDA) with static reconstruction of PE files. The system defines a \"malware execution trace\" as the set of instructions whose memory is tainted (Definition 1, Algorithm 1), partitions this trace into per-process \"execution waves\" based on information-flow analysis (Section 4), collects API calls made by tainted instructions and maps them to waves (Section 5), and then statically merges memory dumps, rebuilds import address tables, and patches branch calls to produce PE files (Section 6). The evaluation uses a new self-authored synthetic benchmark suite, selected malware families (CryptoWall, Tinba, Gapz, Ramnit), 13 public packers, and 119 real-world malware samples. The paper compares Minerva against PackerInspector (Ugarte et al.) as a black-box baseline and claims that Minerva is significantly more precise than previous work, particularly for system-wide unpacking and for exposing API dependencies in unpacked code.","tokens_in":26605,"tokens_out":5469,"duration_ms":55757,"significance":"If the central claims hold, Minerva would be a useful contribution to malware analysis: it formalizes a wave-based model of dynamically generated code, addresses system-wide unpacking through taint propagation, and produces PE files with reconstructed IATs that are suitable for follow-up static analysis. The paper's strengths include the explicit formal model of execution waves, the design of a benchmark suite with synthetic ground-truth samples, and the implementation of the full pipeline on PANDA with reproducible machine-checked trace and output artifacts. However, the significance is weakened by two fundamental concerns: (1) the taint model appears to handle only explicit flows, so the claim of capturing malicious code generated via benign code is not fully supported; and (2) the comparative evaluation rests on a single black-box baseline running on a different OS, with no comparison to the author's closest prior system (Tartarus), making the \"significantly more precise than previous work\" claim under-evidenced.","major_comments":[{"comment":"The central claim that execution waves \"capture dynamically generated code independent of who wrote the code\" (Section 4.2) is not supported for implicit information flows. Algorithm 2 (lines 3-5) taints only the explicit outputs of instructions in the malware execution trace, and no mechanism for propagating taint along control dependencies is described. Consequently, if benign code uses tainted malware data as a branch condition that determines which bytes are written to executable memory, the writing instruction is not tainted and its output is not tainted, so the generated code would be missed by the wave collector. The synthetic benchmarks in Table 2 (D1-D4, C1-C5, M1) all generate code through explicit data-flow paths; none exercises an implicit-flow scenario. Since the paper's precision and generality claims depend on the taint set exactly capturing all dynamically generated malicious code, this limitation should be addressed either by implementing implicit-flow tracking or by explicitly restricting the claim to explicit data flows and discussing the consequences of the restriction.","section":"Section 3.3, Algorithm 2; Section 4.2"},{"comment":"The comparative evaluation that supports the main claim of being \"significantly more precise than previous work\" is based on a single baseline, PackerInspector, which is accessed as a black-box web service and runs on a different OS (Windows XP, inferred by the authors) than Minerva (Windows 7). The authors acknowledge this environment mismatch in Section 7.4 but still draw strong comparative conclusions. More importantly, Minerva is a direct extension of Tartarus [29], which the paper identifies as the closest prior work, yet no comparison to Tartarus is included. Without a side-by-side evaluation against Tartarus (or a reimplementation) under the same conditions and on the same ground-truth benchmarks, the magnitude and source of the precision improvement over prior art are not established. The authors should either provide such a comparison or substantially temper the comparative claims.","section":"Section 7.4, Tables 3 and 4; Section 7 introduction"},{"comment":"There appears to be an internal tension between the formal wave definition and the wave-collection algorithm. Definition 3's second bullet enforces a strict ordering of all instructions between waves, and the text states this \"preclude[s] instructions from any given execution wave to be used in any other execution wave.\" However, Section 4.2 case (1) describes the situation where \"code from the current wave transfers execution to code that is part of an earlier wave,\" and the algorithm then appends that instruction to the current wave. If an instruction address from an earlier wave is executed again in a later wave, the claim of preclusion is either incorrect or relies on an implicit distinction between instruction instances and addresses; this distinction is not made explicit. The authors should clarify how the formal definition and the algorithm reconcile repeated execution of the same address across waves.","section":"Section 4.1, Definition 3; Section 4.2, Algorithm 1"}],"minor_comments":[{"comment":"The word \"concatic\" in the title appears to be a typo for \"concatenative\" or \"concolic\"; please correct it.","section":"Title"},{"comment":"The text reads \"in order to ensure the samples are indeed benign,\" which should say \"malicious\" given the preceding discussion of anti-malware vendor detection.","section":"Section 7.5"},{"comment":"The row for \"WinUpack\" contains an out-of-place character \"w\" in the #PE column; this looks like a typographical error that should be fixed.","section":"Table 10"},{"comment":"The limitations section does not mention the implicit-flow limitation of the taint model, despite it being a core threat to the generality claim; this should be added.","section":"Section 8"},{"comment":"The real-world evaluation reports only aggregate distributions (e.g., 66%, 15%, 9%, 5%, 5% for process counts) without per-sample counts or a description of how these metrics were computed; including per-sample data or a scatterplot would improve reproducibility and interpretability.","section":"Section 7.5, Tables 5-9"}],"recommendation":"major_revision","confidential_remarks":"The paper is essentially a follow-up to the author's Tartarus system [29], and the failure to compare directly against Tartarus is a significant omission that weakens the novelty claim. The evaluation also leans heavily on a black-box baseline with a different OS environment. These issues are fixable in revision, but they are central to the paper's principal contribution. I would not recommend rejection because the system itself appears sound within the explicit-flow regime and the synthetic benchmark suite is a useful resource, but the manuscript currently overstates its precision and comparative advantages."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth a read if you work on unpacking or dynamic taint analysis applied to malware. The core idea is to replace the write-then-execute heuristic with whole-system taint: an execution wave is the set of instructions whose memory is tainted, and the tool then reconstructs PE files with import address tables and patched API calls. The wave semantics are clearly defined in Definitions 1-3, and the post-processing pipeline is genuinely new: grouping related memory pages, building IATs, and patching call sites. This goes beyond the author's earlier Tartarus, which simply dumped tainted memory. The new synthetic benchmark suite (Table 2) is a real contribution; it gives ground truth and is easy to reason about, exactly what the area lacks.\n\nThe case studies, especially the Tinba one, show the tool working on real samples in a way that is concrete and plausible. I believe the central mechanism works as described for the cases tested.\n\nSoft spots, in order of severity. First, the comparative evaluation only pits Minerva against PackerInspector, a black-box web service that runs on Windows XP while Minerva runs on Windows 7. The author acknowledges this, but it still means the headline precision gain is a cross-environment comparison with no baseline against Tartarus or RePEconstruct, the author's own closest systems. The reader's conditional accept is right: a controlled comparison or an artifact release would settle this. Second, the taint model only tracks explicit data-flow; there is no implicit-flow handling. The stress-test note is correct about the gap: if benign code uses tainted values as a branch condition to decide which bytes to write, those writes will not be tainted and the generated code will be missed. This does qualify the Section 4.2 claim that execution waves capture dynamically generated code independent of who wrote the code. In practice, most real unpacking payloads are written through explicit data-dependent operations, so I see this as a limitation to document rather than a fatal flaw, but the paper is silent on it. Third, the performance evaluation is single-environment and the distribution tables (5-9) are hard to interpret without per-sample ground truth.\n\nOverall, the design is plausible, the formalization is a genuine advance for the subfield, and the negative results against PackerInspector are believable. The main work for a revision is an honest comparison to the author's own prior systems and a paragraph on implicit flows and taint precision. The paper deserves a serious referee.","headline":"Minerva is a real step forward for system-wide unpacking with genuinely new wave semantics and PE reconstruction, but the evaluation's single black-box baseline and the unaddressed implicit-flow gap keep it from being fully convincing.","tokens_in":27145,"tokens_out":3290,"would_cite":true,"duration_ms":36143,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Minerva claims that taint-based execution waves recover packed malware code and its external dependencies with enough precision for static analysis, outperforming current unpackers on system-wide packing.","keywords":["malware unpacking","dynamic taint analysis","execution waves","import address table reconstruction","system-wide malware analysis","runtime packing","code injection","PE file reconstruction"],"falsifier":"Run a sample where malicious code is generated by an implicit flow, for example a tainted value that selects a branch or indexes a table without the tainted byte being moved, and check whether Minerva's wave dumps include the generated executable bytes; if an executed instruction is missing from the malware trace, the taint model is incomplete.","tokens_in":26168,"feed_emoji":"🦠","tokens_out":6714,"duration_ms":66007,"temperature":0.7,"pith_summary":"Minerva is an automatic malware unpacker that tries to solve the two hard parts of unpacking at once: recovering dynamically generated code no matter which process wrote it, and reconstructing executable files that reveal the malware's external dependencies. Its central claim is that a system-wide dynamic taint trace, partitioned into per-process execution waves, captures every layer of packed malicious code even when benign OS code performs the writes, and that static reconstruction from those waves yields PE files with import tables and patched API calls suitable for off-the-shelf analysis. If this is right, unpacking stops being a memory-dump heuristic and becomes a recoverable intermediate representation connecting dynamic behavior to static code, with direct use in reverse engineering and malware triage.","feed_headline":"Taint traces expose malware hidden in system-wide packers","feed_subtitle":"Minerva follows tainted bytes across processes and rebuilds PE files with API imports that other unpackers omit.","key_machinery":"The central machinery is the malware execution trace, defined as the set of instructions whose operands or address are tainted, and the execution-wave partition maintained by the paper's wave-collection algorithm. A wave is carried by a shadow memory of tainted bytes and a set of tainted writes; when an executing instruction's address is in the tainted writes but not in the current shadow memory, a new wave starts and the old wave is dumped. This handles shared-memory transfers, code injection into other processes, and dynamically generated code written by benign code, because taint follows the data, not the writer. The second half of the machinery is dependency capture: every branch destination in the malware trace is checked against the per-process export table, and the resulting API-call log is merged into reconstructed PE files by patching six-byte branch instructions and rebuilding the import address table. Related memory dumps are grouped into sections by speculative disassembly, so the final PE files are self-contained and keep the virtual addresses of the dumped memory.","core_discovery":"The paper claims that information-flow-based 'execution waves' should replace the write-then-execute heuristic. An execution wave is a process-level sequence of instructions whose memory is tainted, together with the tainted memory itself, and waves are delimited whenever execution reaches freshly written tainted memory that is not in the current wave's shadow memory. Because taint propagates through benign and malicious instructions alike, a wave can contain code that was written by an OS API, by another process, or by a code-reuse gadget, not only by the malware's own instructions. The paper further claims that recording every branch destination in the malware trace and matching it against loaded module exports gives exact API-call attribution per wave, which makes it possible to build new PE files whose import address table is valid and whose API calls are patched even when the original malware used a custom loader or obfuscated the call instruction. Empirical comparison against a state-of-the-art unpacker shows the baseline over-approximates API calls roughly 200x on synthetic samples and fails to detect multi-process unpacking, while Minerva recovers the expected calls and imports.","pith_inferences":["Editorial inference: because wave boundaries are defined by taint propagation, a natural next test is to add implicit-flow tracking and check whether new waves appear for malware that transfers control through addresses computed from tainted values without moving tainted bytes.","Editorial inference: the performance findings suggest a practical extension in which replay detects stalling loops and skips or summarizes them; a testable claim is that this would reduce the reported slowdown without losing wave content.","Editorial inference: the same wave abstraction could be applied to non-PE targets, such as firmware or script-based packers, although the paper only demonstrates Windows PE reconstruction."],"forward_implications":["Packed samples that inject code into benign processes can be unpacked without requiring the malware's own instructions to perform the memory writes.","The output PE files expose external dependencies, so follow-up analysis can identify behavior, such as injection APIs, without first reversing a custom import resolution routine.","API-call counts and unique-API sets reported by an unpacker become trustworthy, since calls are attributed to tainted instructions rather than to the whole process.","New ground-truth benchmarks for unpacking become possible, because the paper's benchmark samples combine code injection, dynamic code generation, and import-address-table destruction in known configurations."],"supporting_citations":[{"why":"Supplies the system-wide taint-based tracing of malware propagation that Minerva builds on to follow code across processes.","marker":"[29]"},{"why":"Provides the record-and-replay full-system emulation infrastructure on which the dynamic analysis runs.","marker":"[11]"},{"why":"The state-of-the-art unpacker used as the baseline; its over-approximation of API calls and failure to show dependencies define the comparison being made.","marker":"[42]"},{"why":"Gives the formal execution-environment model that the paper extends, and is an early representative of the write-then-execute approach.","marker":"[10]"},{"why":"A canonical write-then-execute unpacker whose imprecise memory extraction is one of the limitations Minerva addresses.","marker":"[23]"},{"why":"Supplies the empirical claim that more than 80% of malware samples are packed, motivating the unpacking problem.","marker":"[15]"},{"why":"Prior work on reconstructing binaries with import-address-table destruction, which Minerva extends with wave-based reconstruction.","marker":"[28]"}],"fun_headline_variants":["Minerva's taint waves unpack malware system-wide","Execution waves reveal hidden malware code","Taint-based unpacking nails API imports","System-wide taint tracking defeats packers","Minerva lifts malware layers with precise waves"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Everything downstream assumes the dynamic taint engine tracks every information flow that carries malware-generated bytes and no more; if taint misses an implicit flow or spreads to benign memory, the execution waves and reconstructed files lose their precision.","fun_headline_variants_meta":{"raw":{"variants":["Minerva's taint waves unpack malware system-wide","Execution waves reveal hidden malware code","Taint-based unpacking nails API imports","System-wide taint tracking defeats packers","Minerva lifts malware layers with precise waves"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000496,"raw_usage":{"total_tokens":2450,"prompt_tokens":980,"completion_tokens":1470,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":596,"completion_tokens_details":{"reasoning_tokens":1404}},"tokens_in":596,"tokens_out":1470,"duration_ms":10980,"temperature":1.0,"reasoning_tokens":1404,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T11:18:48.421100+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a sample where malicious code is generated by an implicit flow, for example a tainted value that selects a branch or indexes a table without the tainted byte being moved, and check whether Minerva's wave dumps include the generated executable bytes; if an executed instruction is missing from the malware trace, the taint model is incomplete.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The state-of-the-art unpacker used as the baseline; its over-approximation of API calls and failure to show dependencies define the comparison being made."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the empirical claim that more than 80% of malware samples are packed, motivating the unpacking problem."}],"review_version":1}