Visual Decompiler

• Visual decompiler is a method that reverses low-level artifacts into high-level representations, making intermediate structures like geometry and code provenance visibly inspectable.
• It employs techniques such as Bézier stroke reconstruction, AST and CFG visualizations, and provenance tracking to provide richer, alternative interpretations.
• Applications range from pictographic character synthesis to binary, quantum, and DNN executable analysis, enabling more precise debugging and reverse-engineering.

Searching arXiv for recent work on visual decompilation and decompilation visualization. A visual decompiler is a system that translates a low-level, opaque, or rendered artifact back into a higher-level representation while making the recovered structure inspectable through explicit geometry, program syntax, provenance, control-flow layout, or aligned source-level views. In the narrowest sense, the term denotes a model that maps a raster glyph to an executable geometric program of Bézier strokes, described as a translation from “a rendered visual artifact—a raster glyph—back into its underlying generative specification” (Wan et al., 29 Oct 2025). In a broader research sense, the same label has been used for interfaces and frameworks that visually expose decompilation artifacts such as ASTs, CFGs, provenance graphs, alignment traces, and side-by-side source–binary correspondences, thereby turning decompilation from a purely textual reverse-engineering step into a structured, inspectable process (Hye et al., 21 Oct 2025).

1. Definition and conceptual scope

The central operation of decompilation is the reverse of compilation: a low-level representation is lifted to a higher-level one. In software reverse engineering, this means reconstructing C-like code, OpenCL, Qiskit, or model specifications from binaries, assembly, or QASM; in visual program synthesis, it means reconstructing an executable geometric description from pixels (Liu et al., 30 Mar 2026). A visual decompiler differs from a conventional decompiler by exposing the intermediate structure of that lifting procedure rather than only producing a final textual output.

In the pictographic setting, the task is formulated as visual program synthesis: given a raster input $I$, the model produces a program $P$ in a domain-specific language of Bézier strokes, with $f: I \to P$ and $R(P) \approx I$, where $R(P)$ is a rendering function and “$\approx$” denotes geometrically faithful reconstruction rather than exact pixel equality (Wan et al., 29 Oct 2025). In quantum architecture search, decompilation is the reverse engineering of circuits back into high-level code that captures algorithmic structure such as loops, subroutines, and controlled operations, and a visual decompiler adds side-by-side QASM vs. Qiskit views, AST trees, circuit diagrams, and metrics overlays (Xie et al., 11 Apr 2025).

In binary analysis, the same conceptual pattern appears in provenance-guided superset decompilation, where lifting is organized as modular passes over an intermediate-representation hierarchy, ambiguity is retained as parallel candidates, and provenance is attached to each candidate so that alternative interpretations can be inspected rather than prematurely discarded (Liu et al., 30 Mar 2026). This suggests that “visual decompiler” is best understood not as a single implementation style, but as an approach in which the recovered high-level representation and the evidence supporting it remain visible.

2. Raster-to-program reconstruction and the geometric interpretation of vision

A particularly literal use of the term appears in pictographic character reconstruction. Here, each character is represented by an executable program composed of parameterized Bézier strokes, and the model is trained to decompile raster images into that program text (Wan et al., 29 Oct 2025). The DSL is a serialized text sequence delimited by <bezierseq> and <bezier> tags; each stroke contains either 3 control points for a quadratic Bézier or 4 control points for a cubic Bézier; and all numeric parameters are normalized to $[0,1]$ in a Cartesian frame overlaid on the image.

The geometry is explicit. A Bézier curve of degree $n$ with control points $\{b_0,\dots,b_n\}$ is defined as

$$c(t)=\sum_{i=0}^{n} b_i B_{i,n}(t), \quad 0 \le t \le 1,$$

with the quadratic and cubic special cases and their derivatives used for tangent computation during evaluation (Wan et al., 29 Oct 2025). Rendering is non-differentiable and is used for visualization and inspection; evaluation instead operates directly on sampled points and tangents. The output must remain syntactically valid, parsable, and executable, and a validator enforces tag order, parenthesis counts, point cardinality, and numeric ranges.

The model uses Qwen2.5-VL-7B with a frozen ViT-based vision encoder and an autoregressive decoder. A key design choice is the overlay of a normalized Cartesian coordinate system on the input image; the paper states that these axes provide explicit spatial anchors and significantly improve geometric grounding (Wan et al., 29 Oct 2025). Supervised fine-tuning uses next-token prediction on axis-augmented images and ground-truth program text, while a reinforcement-learning phase with GRPO optimizes a Geometric Score. The primary evaluation metric is

$P$0

with stroke correspondences established by the Hungarian method.

Quantitatively, the system reports $P$1 on Chinese STD, $P$2 on Chinese Stylistic, and $P$3 on Oracle Bone Script for the SFT model, compared with GPT-4o zero-shot scores of $P$4, $P$5, and $P$6 respectively (Wan et al., 29 Oct 2025). A blind side-by-side human study on 150 samples shows an average 91.6% win rate for the SFT reconstructions over GPT-4o. The most notable result is zero-shot cross-script generalization: training only on modern Chinese characters nevertheless yields substantial fidelity on Oracle Bone Script. The paper interprets this as evidence of a transferable geometric grammar rather than memorized pixel templates. A plausible implication is that visual decompilation can serve as a testbed for whether multimodal models recover generative structure rather than only semantic labels.

3. Visualization as a decompilation interface

In software analysis, visual decompilation often refers less to the output language than to the interface by which low-level structure is made intelligible. DisViz exemplifies this orientation. It does not generate C-like pseudocode; instead, it integrates address-ordered tracing with structural control-flow cues inside a single disassembly view, grouping instructions into bordered basic blocks, displaying loop membership, and using back-edges plus indentation to make loop structure visible without abandoning memory-address order (Hye et al., 21 Oct 2025). The interface also includes pseudo-blocks for non-contiguous loop blocks, a block-based mini-map, clickable jump targets, and dynamic linking to source code across the full application.

This design addresses a specific tension in existing tools: linear listings preserve instruction order but hide structure, while CFG views expose structure but sacrifice traceability. In the evaluation, ten expert participants completed tasks involving loop exploration, finding large basic blocks, and stepping through loops in both Memory Address and Loop Structure order; all completed the tasks successfully, and several used the integrated view to hypothesize vectorization, unrolling, and inlining (Hye et al., 21 Oct 2025). The paper therefore positions visual decompilation as an interface discipline that reconstructs high-level affordances while preserving exact binary fidelity.

Dewolf extends the same human-centric emphasis to decompiler output itself. Built on Binary Ninja’s MLIL in SSA form, it applies a collection of readability-oriented transformations, including continue-node insertion for loops, more permissive for-loop recovery, switch reconstruction without a jump table via variable tracing, a custom logic engine for compacting conditions, subexpression elimination, dead-path elimination, array access detection, redundant-cast removal, and an improved out-of-SSA procedure (Enders et al., 2022). Its surveys indicate that decompilers aimed at manual analysis should be highly configurable and need not always follow the code structure dictated by the assembly if semantics are preserved.

The renaming problem addressed by DIRE adds another visual dimension. DIRE treats decompilation as incomplete when semantically meaningful identifiers are absent, because placeholders such as VAR1 and VAR2 increase cognitive load. It combines a lexical encoder over decompiled tokens with a structural GGNN over the decompiler’s AST and predicts names one sub-token at a time, reaching 74.3% exact-match recovery and 28.3% CER on its corpus (Lacomis et al., 2019). The paper explicitly argues that visual decompilers benefit directly from good names because they improve scanning of call graphs and data-flow panes. This suggests that visual decompilation is not limited to graphs and layouts; semantic labeling of recovered entities is also part of making the lifted representation visually usable.

4. Declarative, provenance-aware, and explainable decompilation

Another line of work treats visual decompilation as the exposition of alternatives and their justifications. Superset Decompilation formalizes provenance-guided superset decompilation (PGSD), in which decompilation is organized as monotone derivation of facts into a relation store over an IR hierarchy such as x86-64, Asm, Mach, LTL, RTL, Cminor, Csharpminor, and Clight (Liu et al., 30 Mar 2026). Passes are positive Datalog programs, facts are never retracted, and ambiguous interpretations are retained as parallel candidates with provenance polynomials in the semiring $P$7.

The framework defines the immediate consequence operator

$P$8

and computes least fixpoints monotonically (Liu et al., 30 Mar 2026). Selection is deferred to a final phase, formalized abstractly as minimizing compiler errors under global consistency constraints. Manifold, the implementation, lifts Linux ELF binaries to C99 in approximately 35K lines of Rust and Datalog and matches major decompilers on several quality metrics while producing fewer Clang frontend errors.

The relevance to visual decompilation lies in the explicit design patterns proposed for interacting with this fact store: a relation explorer, provenance DAGs, candidate side-by-side views, pass-by-pass timelines, dual CFG/AST views, type-inference justifications, and interactive resolution aligned with Clang diagnostics (Liu et al., 30 Mar 2026). In this setting, a visual decompiler is not merely a graphical frontend over a conventional pipeline; the visualization follows directly from the underlying semantics of ambiguity retention and provenance recording.

DeQompile brings a related explainability agenda to quantum architecture search. It lifts low-level OpenQASM circuits into readable Python/Qiskit programs represented as Python ASTs, synthesized through genetic programming with symbolic simplification via SymPy (Xie et al., 11 Apr 2025). Candidate fitness combines normalized Levenshtein similarity, gate-frequency cosine similarity, longest-common-subsequence similarity, and a parsimony term over AST size:

$P$9

The paper explicitly frames a visual decompiler as one providing side-by-side QASM and Qiskit views, AST visualizations, circuit diagrams, fitness plots, and pattern overlays for motifs such as QFT’s controlled rotations or GHZ fan-out entanglement.

Benchmark cases show that 1-qubit patterns achieve perfect combined score $f: I \to P$0 within about 30 generations under representative settings; GHZ is recovered compactly; and QFT reaches scores above 0.85 for $f: I \to P$1–10 in approximately 150 generations and above 0.9 for $f: I \to P$2 in about 100 generations (Xie et al., 11 Apr 2025). The common principle shared with PGSD is that decompilation becomes more interpretable when the intermediate hypothesis space—ASTs, patterns, candidates, and scores—is visible.

5. Machine learning, alignment, and domain-specific decompilers

Recent neural work makes visual decompilation increasingly alignment-aware. Self-Constructed Context Decompilation and Fine-grained Alignment Enhancement target C source recovery from x86-64 assembly using llm4decompile-6.7b-v1.5 (Feng et al., 2024). The first method recompiles the model’s own initial decompilation result, disassembles it, and feeds the resulting assembly–source pair back as an in-context exemplar; the second method uses DWARF-enabled objdump -S interleavings to teach statement-level assembly-to-source alignment during fine-tuning.

On Decompile-Eval, the base model reports 47.68% average Re-executability, sc$f: I \to P$3dec alone reaches 51.52%, FAE with vanilla inference reaches 52.28%, and FAE plus sc$f: I \to P$4dec reaches 55.03%, with per-level Re-executability of 71.95% at O0, 53.66% at O1, 48.78% at O2, and 45.73% at O3 (Feng et al., 2024). The paper explicitly proposes synchronized panes, alignment overlays, confidence scores, recompilation diagnostics, and interactive refinement as components of a visual decompiler. Here visualization is driven by statement-level correspondence rather than only final source rendering.

Domain-specific decompilers extend the concept to nontraditional execution substrates. BTD reconstructs DNN operator types, graph topology, dimensions, and parameters from stripped x86 ELF executables produced by DL compilers such as TVM, Glow, and NNFusion (Liu et al., 2022). It combines operator inference from opcode sequences, dynamic pointer-based topology recovery, and trace-based symbolic execution for dimension and parameter inference. The recovered specifications are sufficient for recompilation into a new executable exhibiting identical behavior to the input model, and the paper argues that the natural visual abstraction is a computational graph with node attributes, edge tensor provenance, and parameter tensors.

OpenCLDecompiler does something analogous for AMD GCN kernels, translating assembly to OpenCL C through preprocessing, system-value extraction, arithmetic decompilation, data-type recovery, CFG construction, region-graph analysis, and branch reconstruction (Mihajlenko et al., 2021). It recovers built-ins such as get_local_id, get_group_id, get_global_offset, and get_global_size, reconstructs address-space distinctions for LDS and global memory, and decompiles if/else patterns driven by the EXEC mask. The implementation is reported to pass all repository tests over approximately 931 synthetic and real kernels.

Across these systems, the visual aspect does not arise from one standardized UI paradigm. Rather, it arises from whichever latent structure best explains the low-level artifact: statement alignment in x86 assembly, tensor graphs in DNN executables, SIMD/SIMT control and memory spaces in GPU kernels, or ASTs and loop patterns in quantum circuits. This suggests that visual decompilation is strongly domain-conditional even when the underlying lifting task is analogous.

6. Limitations, misconceptions, and research directions

A common misconception is that visual decompilation is equivalent to adding graphics to a conventional decompiler. The surveyed work indicates a stronger requirement: the visualization must correspond to a recoverable, executable, or auditable structure. In the pictographic case, that structure is an executable Bézier DSL; in PGSD, it is a provenance-annotated candidate space; in DisViz, it is the joint presentation of execution order and loop structure; in sc$f: I \to P$5dec and FAE, it is statement-level assembly–source alignment (Wan et al., 29 Oct 2025).

Another misconception is that the decompiled output is necessarily unique. PGSD explicitly rejects premature commitment to a single interpretation and retains multiple candidates with provenance until a final selection phase (Liu et al., 30 Mar 2026). Dewolf’s survey findings likewise imply that there is no single universally optimal reconstruction for human readers, because preferences over restructuring, variable treatment, and output style vary across analysts (Enders et al., 2022). A plausible implication is that high-quality visual decompilers should expose alternatives and uncertainty rather than suppress them.

Limitations recur across domains. In raster glyph decompilation, failure modes include junctions and forks, stroke-order ambiguities, highly expressive calligraphy, low-resolution or noisy inputs, and tokenization bottlenecks for long numeric sequences (Wan et al., 29 Oct 2025). In binary lifting, memory growth under ambiguity, type corner cases, compiler-specific patterns, and incomplete struct recovery remain active challenges (Liu et al., 30 Mar 2026). In neural source recovery, sc$f: I \to P$6dec depends on first-pass compilability and FAE depends on DWARF and source interleavings (Feng et al., 2024). In DNN executable decompilation, unsupported custom or quantized operators and non-x86 platforms constrain coverage (Liu et al., 2022). In AMD GPU decompilation, complex loop constructions and certain instructions remain unsupported, with inline pseudo-code used as fallback (Mihajlenko et al., 2021).

Future directions are correspondingly heterogeneous but conceptually aligned. The pictographic work points to richer DSLs with stroke width, caps, joins, arcs, quantized coordinates, learned vector tokens, or hierarchical programs (Wan et al., 29 Oct 2025). PGSD points to broader ISA and language coverage, richer analyses, and interactive, incrementally recomputed provenance views (Liu et al., 30 Mar 2026). DeQompile proposes interactive AST editing, motif detection, and hybrid symbolic-neural synthesis (Xie et al., 11 Apr 2025). sc$f: I \to P$7dec and FAE suggest tighter integration of recompilation feedback and alignment-aware user interfaces (Feng et al., 2024). Taken together, these directions indicate that the field is moving toward decompilers that are not only translators, but also explanatory systems in which code, geometry, provenance, and structure are exposed as first-class objects of analysis.