Pith. sign in

REVIEW 3 major objections 5 minor 43 references

NotDec: WebAssembly Decompilation With Inter-Procedural Type Recovery

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

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

Pith's one-line read NotDec claims WebAssembly binaries can be decompiled into recompilable C with custom struct types recovered, reporting 100% recompilation success on 5,241 Juliet samples where Ghidra reaches only 45.95%.

desk verdict Solid Wasm decompiler with a genuinely new type-recovery piece, but the 100% claim is contradicted by the paper's own table and semantic equivalence is asserted, not demonstrated. read the letter →

arxiv 2608.03286 v1 pith:XZQJJHM3 submitted 2026-08-04 cs.SE

Jikai Wang , Ningyu He , Tianming Liu , Junhai Wang , Haoyu Wang This is my paper
classification cs.SE
keywords WebAssemblydecompilationtyperecoverystaticsingleassignmentbinaryreverseengineeringLLVMIRpointerversusnumericdifferentiationRetypdstructuredcontrolflow
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

NotDec claims that WebAssembly bytecode can be decompiled into readable, recompilable C code with custom struct types recovered, as long as the wasm came from a mainstream C compiler. The central move is to treat the problem as native-binary type recovery: lift wasm to SSA-based LLVM IR with the spec's own validation algorithm, apply compiler optimizations plus low-level pattern recognition to expose stack allocations and memcpy/memset idioms, then run the Retypd type-recovery algorithm guided by a new PNDiff graph that distinguishes pointers from numbers. The reported results are 100% recompilation success across all 5,241 Juliet samples and all Howard programs — versus 45.95% for Ghidra — and 85.33% of struct member accesses recovered versus 9.24%. A reader should care because WebAssembly now runs in nearly every browser, container, and IoT device, and security auditing of a module currently means reading raw pointer arithmetic; if the claim holds, auditors can read the struct fields and layouts the compiler erased.

What carries the argument

Three mechanisms carry the argument. The front end extends the WebAssembly specification's validation algorithm to convert the operand stack into SSA-based LLVM IR, so standard compiler optimizations become applicable. The middle end's PNDiff graph classifies every value as Ptr, Num, Unknown, or Non-PN, merges values related by dataflow, and applies pointer-arithmetic inference rules (subtraction of two pointers is numeric; pointer plus numeric is pointer) to seed Retypd's constraint graph, which then performs bottom-up summary generation and top-down type propagation to produce struct 'sketches.' Stack SROA treats a function's stack region as one large structure and splits it into local var

What would settle it

Compile the Howard programs with link-time optimization so memcpy and memset are inlined (the paper names this as a failure mode for its pattern matching), decompile with NotDec, and count recovered struct member accesses; if the 85.33% figure drops substantially, the Section 3.2.1 heuristics — not the type inference — are carrying the result.

Watch

Extended reading notes

Core claim

NotDec claims that WebAssembly can be decompiled into recompilable C code with custom struct types recovered despite untyped linear memory. It extends the wasm validation algorithm to lift bytecode to SSA-based LLVM IR, applies optimization and pattern recognition to expose stack allocations and memcpy/memset, runs Retypd (a polymorphic binary type-recovery algorithm) guided by a PNDiff graph that separates pointer from numeric values, and uses Memory SSA plus semantics-preserving structuring to emit C. On 5,241 Juliet samples and five real-world programs it reports 100% recompilation success versus Ghidra's 45.95%, and 85.33% of struct member accesses versus 9.24%. The full inter-procedural

Load-bearing premise

Every reported result depends on the input wasm being the output of a mainstream C compiler: the stack-pointer decrements at function entry, the alloca-style dynamic allocations, and the memcpy/memset store sequences must appear in the canonical shapes the pattern matchers look for — the paper states 'We assume that the input of NotDec is generated by a common compiler.'

Editorial extensions

If this is right

  • Every one of the 5,241 Juliet samples and every Howard program decompiles to C that GCC accepts, so the pipeline's output is syntactically sound across the whole evaluated corpus.
  • Struct member accesses come back as field accesses (85.33%) rather than raw pointer arithmetic, making decompiled output readable enough for security auditing of wasm modules.
  • The recipe transfers to other source languages: the paper argues only the allocation-pattern matchers and the backend syntax tree need retargeting to support Rust- and Go-compiled wasm.
  • When inter-procedural analysis is too slow, the intra-procedural variant NotDec_F keeps per-function type recovery and still beats Ghidra's time and memory on unoptimized binaries.
  • Compiler optimizations applied before recovery remove enough redundancy to cut output lines by roughly 70% in the ablation, independent of type recovery.

Reading between the lines

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

  • The 54 missed struct member accesses in the Howard dataset are all flattening losses on global structs decomposed into independent variables; a whole-program global-aggregate recovery pass would plausibly close most of that 14.67% gap, though the paper does not propose one.
  • The PNDiff rules in Table 1 form a small type system for pointer arithmetic; exposing them as a typed intermediate representation rather than a recovery heuristic could make the pointer/numeric distinction checkable and reusable beyond wasm.
  • Because the pipeline assumes compiler-canonical idioms, its adversarial bound is likely set by obfuscation rather than by type-inference difficulty; a stress test with stack-pointer-obfuscating transformations would map that bound.
  • The 100% recompilation claim measures acceptance by GCC, not behavioral equivalence with the original binary; differential execution of original and recompiled code on shared inputs is the natural next validation step.
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. NotDec is an open-source WebAssembly-to-C decompiler organized as a three-stage pipeline: (1) a front end that lifts Wasm bytecode to an SSA-based LLVM IR by extending the Wasm validation algorithm; (2) a middle end that applies compiler optimizations, low-level pattern recognition for stack-pointer allocation and memcpy/memset idioms, an inter-procedural type recovery algorithm (Retypd) augmented with a PNDiff graph for pointer/numeric differentiation, and SROA-based stack splitting; and (3) a back end that uses Memory SSA and structured control-flow analysis to emit C code. The evaluation uses 5,241 Juliet samples and five Howard programs compiled at -O0 and -O3, comparing against Ghidra with the wasm plugin, WaDec, and WasmDec. The paper claims 100% recompilation success on all Juliet samples, 85.33% struct-member-access recovery versus Ghidra's 9.24%, and large efficiency improvements for the intra-procedural variant NotDecF.

Significance. The paper addresses a practically important problem and demonstrates a substantial engineering effort: a complete, open-source decompiler pipeline that combines mature compiler optimizations with a state-of-the-art binary type-recovery algorithm. The type-recovery results, if reproducible, would be a clear improvement over the main open-source baseline for WebAssembly reverse engineering. The authors are also honest about scalability limitations and the common-compiler assumption. However, the central correctness claim is not supported by the evaluation as presented: recompilation success is only a syntactic check, and the only dataset that could support runtime equivalence testing is not used for that purpose. The contribution is therefore best understood as a readability and type-recovery tool, with the semantic-preservation claim needing either a proof or a substantial experimental upgrade.

major comments (3)
  1. [Abstract and Table 6] The abstract states that 'NotDec achieves 100% recompilation success rate on all 5,241 Juliet samples and all Howard dataset programs,' but Table 6 shows that full NotDec timed out on 6 of the 10 Howard binaries (grep-O3, gzip-O0, lighttpd-O0/O3, wget-O0/O3) and has missing recompilation data. The 100% rate on Howard holds only for NotDecF, and only for binaries that completed. This is a load-bearing overstatement that must be corrected in the abstract, the RQ2 answer, and the conclusion.
  2. [§3.3, §4.2, and Experiment Setup] Semantic equivalence of the decompiled C is never tested. Recompilation success, as defined in §4.2, only checks that GCC accepts the generated C; it does not establish behavioral equivalence with the original WebAssembly. The Howard binaries 'cannot be actually executed' according to the Experiment Setup, and no execution-based comparison is reported for Juliet either. The Memory SSA mechanism in §3.3 only decides whether to insert a temporary for a memory load; it does not by itself prove that expression caching, statement ordering, or C-type rewrites preserve behavior. Consequently, the paper's claims of 'semantically consistent C code' (Abstract) and 'semantics-preserving' structuring (§3.3) are unsupported. I recommend adding differential/runtime equivalence tests on the executable Juliet samples, or rewriting the claims to refer to syntactic recompilability and readability.
  3. [§4.3, Table 8] The ablation table compares non-comparable quantities. NotDec_d2 reports 275 recovered structure variables and 1,905 member accesses on 269 sampled Juliet functions, while full NotDec reports 6 and 14. Because NotDec_d2 treats the entire function stack as one large structure, its counts are artificial stack-layout artifacts, not recovered user-defined types. The sentence 'Manual inspection ... confirms that all recovered structure variables and member accesses are accurate and complete' is therefore ambiguous and, if applied to NotDec_d2, conflicts with the fact that these are synthesized stack structures. The presentation should clearly separate true source-level struct recovery (full NotDec) from stack-as-struct artifacts (NotDec_d2), and the 85.33% Howard accuracy figure should be attributed to NotDecF only.
minor comments (5)
  1. [§4.2 Type Recovery Accuracy] The manual inspection of 319 functions lacks reproducibility details: how were the 50 Juliet cases selected, and how were the 5 functions per Howard program chosen? A seed or a documented sampling procedure should be provided.
  2. [Throughout] There are several typographical errors: 'Memroy' in Table 4, 'Propergation' in Figure 2, 'inter-procedual' in §3.2.2, and 'matting' instead of 'matching' in §4.3.
  3. [References] Reference [27] is cited as an arXiv preprint; if the Retypd algorithm has a peer-reviewed publication, that should be cited instead or additionally.
  4. [Table 6] The '–' entries for full NotDec are labeled as missing data, but the reader must infer that they are timeouts. Add a footnote or table caption making this explicit, since the abstract's '100%' claim depends on reading the table carefully.
  5. [§6 Discussion] The key assumption that input WebAssembly is generated by a common compiler appears only in the 'Obfuscated WebAssembly Code' subsection. Since the entire pattern-recognition layer depends on this assumption, it should be stated prominently in the introduction or the design section.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the pipeline is validated against external ground truth (GCC recompilation and manual comparison to original C source); load-bearing algorithms (Retypd, MemorySSA, structured CFG analysis) are cited from independent work, and the same-group citations appear only as baselines or related mechanism.

full rationale

The paper's derivation chain is empirical rather than definitional: WebAssembly is lifted to SSA IR, optimized, type-recovered via the externally published Retypd algorithm plus a PNDiff constraint graph, and then emitted as C via MemorySSA-based load handling and standard structuring algorithms. None of these stages fits parameters to the evaluation targets. Recompilation success (GCC compiling the decompiled C) is an external syntactic check, and type-recovery accuracy is measured by manually comparing decompiled output to original C source code; the claimed struct recoveries are not defined in terms of the tool's own pattern matchers. The only self-citations are [14] (BREWasm) and [19] (Eunomia) in background/related work and [31] (WaDec) as a baseline; none is load-bearing for the central design or for the evaluation. No uniqueness theorem from the authors is invoked, and no ansatz is smuggled in via self-citation: the adoption of Retypd cites Noonan et al. [27], MemorySSA cites LLVM documentation [6], and the structuring algorithm cites [11,13]. Section 6 explicitly states the compiler-generated-input assumption and other limitations, which bound the claims rather than making them circular. The skeptic's concern that 'semantically consistent C code' is not proven by recompilation success is a validity/evidence gap, not a circularity: the paper never defines semantic consistency as equivalent to recompilability. Consequently, no circular step can be exhibited with a specific reduction of an equation or fitted parameter, and the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim rests on assumptions about typical compiler-generated Wasm and the soundness of Retypd and Memory SSA. No numeric free parameters are fitted to data.

assumptions (3)
  • domain assumption Input WebAssembly is generated by a common compiler with recognizable stack-pointer manipulation and memcpy/memset patterns.
    Stated in Section 6: 'We assume that the input of NotDec is generated by a common compiler.' Stack SROA and type recovery depend on these heuristics.
  • domain assumption Retypd's type recovery algorithm works correctly on LLVM IR lifted from WebAssembly.
    The middle end treats Retypd as a black box; the paper does not formally verify its correctness on Wasm-specific memory layouts.
  • domain assumption Memory SSA's intra-procedural alias analysis is sufficient to preserve load semantics in generated C code.
    Section 3.3 relies on Memory SSA, acknowledging over-approximation is handled conservatively by inserting temporaries.

how reviews work

0 comments
Cite this review

Pith. "Pith review of NotDec: WebAssembly Decompilation With Inter-Procedural Type Recovery." pith.science (2026). https://pith.science/paper/XZQJJHM3

@misc{pith2026260803286,
  author       = {Pith},
  title        = {Pith review of: NotDec: WebAssembly Decompilation With Inter-Procedural Type Recovery},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XZQJJHM3}},
  note         = {Machine review of arXiv:2608.03286}
}
read the original abstract

With WebAssembly widely supported in browsers, containers, IoT devices, and serverless platforms and increasingly adopted as a universal low-level bytecode standard, auditing its hidden vulnerabilities and malicious intentions has become critical. Decompiling existing WebAssembly modules can help security researchers and end users understand binary behavior, but current tools suffer from verbose result, poor readability, and limited type recovery. We present NotDec, an advanced WebAssembly decompilation framework. NotDec extends the WebAssembly type checking algorithm to lift bytecode into an SSA-based IR, applies the inter-procedural type recovery algorithm Retypd with pointer and numeric value differentiation methods to recover complex data structures, and leverages Memory SSA alongside semantics-preserving structured control-flow analysis to emit readable, semantically consistent C code. NotDec achieves 100% recompilation success rate on all 5,241 Juliet samples and all Howard dataset programs, significantly outperforming baselines including Ghidra (45.95% success rate). On type recovery accuracy, NotDec recovers 85.33% of struct member accesses in real-world programs, vastly exceeding Ghidra's 9.24%. While the full inter-procedural version faces scalability challenges on large binaries, the intra-procedural variant NotDec_F demonstrates superior efficiency, consuming less than half of Ghidra's memory and up to 97% less execution time on unoptimized binaries.

Figures

Figures reproduced from arXiv: 2608.03286 by the authors.

Figure 1
Figure 1. The overview of our WebAssembly decompilation method. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 4
Figure 4. Sample code that requires inter-procedural type [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 3
Figure 3. Examples shows the conversion of instructions for [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 5
Figure 5. Figure 5: Constraint graph for main. types. We exploit this to derive additional inference rules based on type equality, as shown in [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: The time spent on inter-procedural type recovery [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Decompilation results of kwsalloc from grep, where NotDec can recover fields of the custom structure used. one global struct is flattened during decompilation, with its mem￾bers treated as independent global variables. In contrast, Ghidra identified only 4 (13.79%) of …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

43 extracted references · 34 canonical work pages

  1. [1]

    wwwg/wasmdec: WebAssembly to C decompiler

    2018. wwwg/wasmdec: WebAssembly to C decompiler. https://github.com/ wwwg/wasmdec. Accessed: June 2025

    work page 2018

  2. [2]

    SAC 2022 Dataset

    2021. SAC 2022 Dataset. https://figshare.com/articles/dataset/SAC_2022_Dataset/ 17297477?file=31953221. Accessed: July 2025

    work page 2021

  3. [3]

    Small LLMs may stuck in a loop

    2023. Small LLMs may stuck in a loop. https://news.ycombinator.com/item?id= 37554095. Accessed: July 2025. 2https://github.com/NationalSecurityAgency/ghidra/commit/7559acf5 ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil Jikai Wang, Ningyu He, Tianming Liu, Junhai Wang, and Haoyu Wang

    work page 2023

  4. [4]

    nneonneo/ghidra-wasm-plugin: Ghidra Wasm plugin with disassembly and decompilation support

    2024. nneonneo/ghidra-wasm-plugin: Ghidra Wasm plugin with disassembly and decompilation support. https://github.com/nneonneo/ghidra-wasm-plugin. Accessed: July 2025

    work page 2024

  5. [5]

    IDA Decompiler

    2025. IDA Decompiler. https://hex-rays.com/decompiler. Accessed: July 2025

    work page 2025

  6. [6]

    MemorySSA - LLVM Documentation

    2025. MemorySSA - LLVM Documentation. https://llvm.org/docs/MemorySSA. html. Accessed: June 2025

    work page 2025

  7. [7]

    NationalSecurityAgency/ghidra: Ghidra is a software reverse engineering (SRE) framework

    2025. NationalSecurityAgency/ghidra: Ghidra is a software reverse engineering (SRE) framework. https://github.com/NationalSecurityAgency/ghidra. Accessed: July 2025

    work page 2025

  8. [8]

    Validation Algorithm - WebAssembly 2.0

    2025. Validation Algorithm - WebAssembly 2.0. https://webassembly.github.io/ spec/core/appendix/algorithm.html. Accessed: July 2025

    work page 2025

Show all 43 references
  1. [9]

    WebAssembly Design Rationale

    2025. WebAssembly Design Rationale. https://github.com/WebAssembly/design/ blob/af8e951/Rationale.md#why-a-stack-machine. Accessed: March 2025

    2025

  2. [10]

    WebAssembly/wasi-sdk: WASI-enabled WebAssembly C/C++ toolchain

    2025. WebAssembly/wasi-sdk: WASI-enabled WebAssembly C/C++ toolchain. https://github.com/WebAssembly/wasi-sdk. Accessed: July 2025

    2025

  3. [11]

    Zion Leonahenahe Basque, Ati Priya Bajaj, Wil Gibbs, Jude O’Kain, Derron Miao, Tiffany Bao, Adam Doupé, Yan Shoshitaishvili, and Ruoyu Wang. 2024. Ahoy SAILR! There is No Need to DREAM of C: A Compiler-Aware Struc- turing Algorithm for Binary Decompilation. In33rd USENIX Secur...

    2024

  4. [12]

    Tiago Brito, Pedro Lopes, Nuno Santos, and José Fragoso Santos. 2022. Wasmati: An efficient static vulnerability scanner for WebAssembly.Computers & Security 118 (2022), 102745

    2022

  5. [13]

    Schwartz, and Maverick Woo

    David Brumley, JongHyup Lee, Edward J. Schwartz, and Maverick Woo. 2013. Na- tive x86 Decompilation Using Semantics-Preserving Structural Analysis and Iter- ative Control-Flow Structuring. In22nd USENIX Security Symposium (USENIX Se- curity 13). USENIX Association, Washington,...

    2013

  6. [14]

    Shangtong Cao, Ningyu He, Yao Guo, and Haoyu Wang. 2023. BREWasm: A General Static Binary Rewriting Framework for WebAssembly. InStatic Anal- ysis: 30th International Symposium, SAS 2023, Cascais, Portugal, October 22–24, 2023, Proceedings(Lisbon, Portugal). Springer-Verlag, B...

    2023 doi

  7. [15]

    2017.Algebraic subtyping

    Stephen Dolan. 2017.Algebraic subtyping. BCS, The Chartered Institute for IT

    2017

  8. [16]

    Khaled ElWazeer, Kapil Anand, Aparna Kotha, Matthew Smithson, and Rajeev Barua. 2013. Scalable variable and data type detection in a binary rewriter. In Proceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and Implementation(Seattle, Washington, USA)(P...

    2013

  9. [17]

    WebAssembly Community Group. 2025. WebAssembly Specifications. https: //webassembly.github.io/spec/. Accessed: March 2025

    2025

  10. [18]

    Andrea Gussoni, Alessandro Di Federico, Pietro Fezzardi, and Giovanni Agosta

  11. [19]

    Ningyu He, Zhehao Zhao, Jikai Wang, Yubin Hu, Shengjian Guo, Haoyu Wang, Guangtai Liang, Ding Li, Xiangqun Chen, and Yao Guo. 2023. Eunomia: Enabling User-Specified Fine-Grained Search in Symbolically Executing WebAssembly Binaries. InProceedings of the 32nd ACM SIGSOFT Intern...

    2023

  12. [20]

    Aaron Hilbig, Daniel Lehmann, and Michael Pradel. 2021. An empirical study of real-world webassembly binaries: Security, languages, use cases. InProceedings of the web conference 2021. 2696–2708

    2021

  13. [21]

    Sun Hyoung Kim, Dongrui Zeng, Cong Sun, and Gang Tan. 2022. BinPointer: towards precise, sound, and scalable binary-level pointer analysis. InProceedings of the 31st ACM SIGPLAN International Conference on Compiler Construction (Seoul, South Korea)(CC 2022). Association for Co...

    2022

  14. [22]

    JongHyup Lee, Thanassis Avgerinos, and David Brumley. 2011. TIE: Principled reverse engineering of types in binary programs. (2011)

    2011

  15. [23]

    Daniel Lehmann, Johannes Kinder, and Michael Pradel. 2020. Everything Old is New Again: Binary Security of WebAssembly. In29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 217–234. https://www.usenix.org/ conference/usenixsecurity20/presentation/lehmann

    2020

  16. [24]

    Daniel Lehmann and Michael Pradel. 2022. Finding the Dwarf: Recovering Precise Types from WebAssembly Binaries. InProceedings of the 43rd ACM SIGPLAN International Conference on Programming Language Design and Implementation (San Diego, CA, USA)(PLDI 2022). Association for Com...

    2022

  17. [25]

    Marius Musch, Christian Wressnegger, Martin Johns, and Konrad Rieck. 2019. New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild. InDetection of Intrusions and Malware, and Vulnerability Assessment, Roberto Perdisci, Clémentine Maurice, Giorgio Giacinto, and...

    2019

  18. [26]

    Faraz Naseem Naseem, Ahmet Aris, Leonardo Babun, Ege Tekiner, and A Sel- cuk Uluagac. 2021. MINOS: A Lightweight Real-Time Cryptojacking Detection System.. InNDSS

    2021

  19. [27]

    Matthew Noonan, Alexey Loginov, and David Cok. 2016. Polymorphic Type Inference for Machine Code. arXiv:1603.05495 [cs.PL] https://arxiv.org/abs/1603. 05495

    2016 arXiv

  20. [28]

    2005.FULCRA pointer analysis framework

    Erik Matthew Nystrom. 2005.FULCRA pointer analysis framework. University of Illinois at Urbana-Champaign

    2005

  21. [29]

    Lionel Parreaux. 2020. The simple essence of algebraic subtyping: principal type inference with subtyping made easy (functional pearl).Proc. ACM Program. Lang. 4, ICFP, Article 124 (Aug. 2020), 28 pages. doi:10.1145/3409006

    2020 doi

  22. [30]

    Andreas Rossberg, Ben L Titzer, Andreas Haas, Derek L Schuff, Dan Gohman, Luke Wagner, Alon Zakai, JF Bastien, and Michael Holman. 2018. Bringing the web up to speed with WebAssembly.Commun. ACM61, 12 (2018), 107–115

    2018

  23. [31]

    Xinyu She, Yanjie Zhao, and Haoyu Wang. 2024. WaDec: Decompiling We- bAssembly Using Large Language Model. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 481–492

    2024

  24. [32]

    Asia Slowinska, Traian Stancescu, and Herbert Bos. 2011. Howard: A Dynamic Excavator for Reverse Engineering Data Structures.. InNDSS

    2011

  25. [33]

    Ian Smith. 2024. BinSub: The Simple Essence of Polymorphic Type Inference for Machine Code. arXiv:2409.01841 [cs.PL] https://arxiv.org/abs/2409.01841

    2024 arXiv

  26. [34]

    Benedikt Spies and Markus Mock. 2021. An Evaluation of WebAssembly in Non-Web Environments. In2021 XLVII Latin American Computing Conference (CLEI). 1–10. doi:10.1109/CLEI53233.2021.9640153

    2021

  27. [36]

    Quentin Stiévenart, Coen De Roover, and Mohammad Ghafari. 2022. Security risks of porting C programs to webassembly. InProceedings of the 37th ACM/SIGAPP Symposium on Applied Computing(Virtual Event)(SAC ’22). Association for Computing Machinery, New York, NY, USA, 1713–1722. ...

    2022 doi

  28. [37]

    Quentin Stiévenart and Coen De Roover. 2020. Compositional Information Flow Analysis for WebAssembly Programs. In2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM). 13–24. doi:10. 1109/SCAM51674.2020.00007

    2020

  29. [38]

    Hanzhuo Tan, Qi Luo, Jing Li, and Yuqun Zhang. 2024. Llm4decompile: Decom- piling binary code with large language models.arXiv preprint arXiv:2403.05286 (2024)

    2024 arXiv

  30. [39]

    2007.Static Single Assignment for Decompilation

    Michael Van Emmerik. 2007.Static Single Assignment for Decompilation. PhD Thesis. The University of Queensland. doi:10.14264/158682

    2007 doi

  31. [40]

    Khaled Yakdan, Sebastian Eschweiler, Elmar Gerhards-Padilla, and Matthew Smith. 2015. No More Gotos: Decompilation Using Pattern-Independent Control- Flow Structuring and Semantic-Preserving Transformations.. InNDSS. Citeseer

    2015

  32. [41]

    Chengfeng Ye, Yuandao Cai, Anshunkang Zhou, Heqing Huang, Hao Ling, and Charles Zhang. 2025. Manta: Hybrid-Sensitive Type Inference Toward Type- Assisted Bug Detection for Stripped Binaries. InProceedings of the 29th ACM International Conference on Architectural Support for Pr...

    2025

  33. [42]

    Zhuo Zhang, Yapeng Ye, Wei You, Guanhong Tao, Wen-chuan Lee, Yonghwi Kwon, Yousra Aafer, and Xiangyu Zhang. 2021. Osprey: Recovery of variable and data structure via probabilistic analysis for stripped binary. In2021 IEEE Symposium on Security and Privacy (SP). IEEE, 813–832

    2021

  34. [43]

    Muqi Zou, Hongyu Cai, Hongwei Wu, Zion Leonahenahe Basque, Arslan Khan, Berkay Celik, Antonio Bianchi, Dongyan Xu, et al . 2025. D-LiFT: Improving LLM-based Decompiler Backend via Code Quality-driven Fine-tuning.arXiv preprint arXiv:2506.10125(2025)

    2025 arXiv

  35. [2020]

    InProceedings of the 15th ACM Asia Conference on Computer and Communications Security(Taipei, Taiwan)(ASIA CCS ’20)

    A Comb for Decompiled C Code. InProceedings of the 15th ACM Asia Conference on Computer and Communications Security(Taipei, Taiwan)(ASIA CCS ’20). Association for Computing Machinery, New York, NY, USA, 637–651. doi:10.1145/3320269.3384766

Pith tools

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