NotDec: WebAssembly decompilation with inter-procedural type recovery

What happened on this date

At 08:01 UTC on 2026-08-04, arXiv received v1 of "NotDec: WebAssembly Decompilation With Inter-Procedural Type Recovery", with a comment that it was published at ICSE'26. 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 to recover complex data structures, and uses Memory SSA plus semantics-preserving structured control-flow analysis to emit C. The abstract reports a 100% recompilation success rate on all 5,241 Juliet samples and all Howard dataset programs, against 45.95% for Ghidra, and recovery of 85.33% of struct member accesses in real-world programs, against 9.24% for Ghidra. The authors also state the limits: the full inter-procedural version faces scalability problems on large binaries, while the intra-procedural variant NotDec_F uses less than half of Ghidra's memory and up to 97% less time on unoptimized binaries.

Why it matters for people protecting app logic

Many teams compile compute-heavy or "please don't read this" logic to WebAssembly and ship it in web pages, Electron apps or cross-platform front ends, assuming it is harder to read than JavaScript. Work like NotDec shows that most of that difficulty comes from lost types and data structures, which is exactly what research is recovering. Once struct members and control flow come back as recompilable C, reading cost drops sharply, and pairing the output with an LLM for naming and summaries lowers it further. To be fair to the evidence, the evaluation sets are mostly test suites and research datasets, the efficiency numbers are for unoptimized binaries, and the abstract does not claim the same results on large optimized modules. For defenders the direction is still clear: a .wasm file delivered to clients should be treated as public code. It raises analysis cost; it is not a secrecy boundary.

Concrete checks

First, inventory every .wasm file shipped to clients and list the business logic, constants and key-like data each module contains. Second, check whether release builds still carry the name section or DWARF debug information, and make sure that is a deliberate choice. Third, keep decisive logic such as license decisions, pricing rules and risk thresholds on the server, and let client-side Wasm do only computation you can afford to be public. Fourth, after each toolchain or optimization-setting change, spot-check the readability of your own build with publicly available decompilers and record the result as a baseline for later assessments.

Your checklist

• Inventory every shipped .wasm module and its contents
• Check whether release builds keep the name section or DWARF
• Keep license and pricing decisions server-side
• Spot-check your own build's readability after toolchain changes