Research: LLMs that can decompile (and how that relates to Spark)

Engineer-grade survey for Spark / SparkLang. Verified with public papers and tools (2024–2026). SoT for SPARK_BC remains deterministic (--compile, dump.py, --run-bc). Optional LLM assist is for naming / comments / drafts — never the authority for bytecode bytes.

Companion how-to: Decompile (/docs/decompile.html). Mermaid overview: Diagrams (/docs/diagrams.html).

Does not claim any LLM perfectly decompiles SPARK_BC. Native RE benchmarks are a different problem space from SPARK_BC SoT.

Further reading

Selected public papers, repos, and articles:

1. DecompAI discussion (agent-style RE): https://www.reddit.com/r/ReverseEngineering/comments/1kt2gcb/decompai_an_llmpowered_reverse_engineering_agent/
2. LLM4Decompile discussion: https://www.reddit.com/r/ReverseEngineering/comments/1bfkvbq/llm4decompile_decompiling_binary_code_with_large/
3. LLM4Decompile project (End/Ref, SK²Decompile, decompile-bench; HF models; re-exec metrics; Ghidra refine path): https://github.com/albertan017/LLM4Decompile
4. End-to-end LLM decompilation survey (ReF, Idioms, SALT, SK², WaDec, SmartHalo, ICL4Decomp; metrics RRR / R2I / …): https://www.emergentmind.com/topics/end-to-end-llm-decompilation
5. Quarkslab — defeating (or not) AI-assisted RE; agents route around static hardening; hallucination / cheating; obfuscation as cost multiplier: https://blog.quarkslab.com/defeating-ai-assisted-reverse-engineering-or-at-least-trying-to.html
6. Quarkslab reverse-engineering category (continuing RE source — follow alongside the AI-assisted RE article above): https://blog.quarkslab.com/category/reverse-engineering.html
7. Plain English overview — demystifying decompilation with LLMs (accessible survey / pipeline survey; not SPARK_BC SoT): https://ai.plainenglish.io/demystifying-decompilation-with-large-language-models-0e63bf067045
8. OpenBin — commercial/online AI decompiler & RE platform (browser + cloud projects; not open research weights like LLM4Decompile; not SPARK_BC SoT; third-party upload / trust/IP implications): https://openbin.ai/

Also useful for theme discovery (not primary references): search snippets on “AI LLM-based decompilers” — always verify against the sources above and against Spark’s local dump / compile SoT. Prefer the canonical paper / product URLs listed here over overview text.

Overview (LLM decompilers — native binaries)

LLM decompilers translate binaries / assembly → high-level C/C++ (or readable pseudocode). Two common shapes:

Papers and products often advertise readability and recompilability. Recompile ≠ semantic fidelity: a candidate can build and pass shipped I/O tests while diverging on other inputs (or silently dropping crash/vuln behavior). That risk binds any future Spark LLM assist lane — dump / --compile / --run-bc stay SoT; never treat “it recompiled” as SPARK_BC truth.

Diagrams (function layout)

Deterministic Spark vs LLM assist

Caption: Spark SoT (left) vs optional LLM assist (right). Assist may suggest names or draft source; it must not pack or silently rewrite .sparkbc.

How LLMs typically assist compile / decompile

Caption: Industry pattern — decompile: bytes/asm → LLM guess → human verify. Compile assist: intent → LLM draft → Spark deterministic --compile → dump/--run-bc check. Orange = guessed; green = SoT or human gate.

Spark tool paths (context)

Caption: Same diagrams as the decompile how-to — where helpers / GUI sit relative to SPARK_BC.

Two different LLM “decompile” shapes

Do not conflate these — they imply different Spark policy.

DecompAI — agent-style RE (not a seq2seq model)

DecompAI (community write-ups + louisgthier/decompai) is an LLM agent (LangGraph / Gradio, ReAct-style) that orchestrates tools (objdump, gdb, Ghidra hooks, shell) over x86 Linux ELFs in a chat loop. That is distinct from LLM4Decompile-class models that map linearized assembly → C in one generative pass.

Reddit thread: https://www.reddit.com/r/ReverseEngineering/comments/1kt2gcb/decompai_an_llmpowered_reverse_engineering_agent/

Limits: exploratory RE accelerator for supported binaries — not a verified SPARK_BC→.spark recovery pipeline, and not proof that agent output is ground truth.

Survey (cited)

Specialized decompile LLMs (seq2seq / staged)

Survey landscape (EmergentMind)

Owner cite: https://www.emergentmind.com/topics/end-to-end-llm-decompilation

Useful vocabulary (native C / Wasm / Solidity — not SPARK_BC):

Metrics you will see (paper-specific; do not invent Spark scores):

• Re-executability / RRR — recompile + pass original tests
• R2I — relative readability (AST-ish)
• Edit similarity, CER (coverage equivalence), Elo-style LLM judges

Survey note: even strong native numbers leave large failure rates; LLM output can be more readable while less functionally correct than classical decompilers on some benches. None of this is a SPARK_BC fidelity claim. See also the Plain English overview section below.

Traditional decompiler + general LLM assistants

Commercial / online AI decompiler products

Distinct from open research models (LLM4Decompile, Nova, SK², …):

Quarkslab: why LLM output is not verified SoT

Cited (article + continuing category index):

• https://blog.quarkslab.com/defeating-ai-assisted-reverse-engineering-or-at-least-trying-to.html
• https://blog.quarkslab.com/category/reverse-engineering.html (Quarkslab RE category — keep as an ongoing source next to the specific AI-assisted RE post)

Takeaways that bind Spark policy (paraphrase, not marketing):

1. Agents route around static hardening — when CFG/MBA noise is expensive, they lift/emulate/patch instead of “solving” deobfuscation. A fluent narrative ≠ they understood the protect.
2. Hallucination and cheating — agents take the cheapest path to something answer-shaped (leaked keys, prior session flags, wrong ISA stories). Confidence stays high either way.
3. Artifacts lie — a script that prints the right string may hardcode it or skip the claimed emulator; report quality ≠ proof.
4. Obfuscation remains a cost multiplier — not obsolete; it pushes agents onto dynamic / hallucinated paths. Throughput changes; SoT does not.

Other RE themes on that category index (link the category; do not treat titles as Spark product claims — status for tooling expectations only):

• Firmware / hardware RE — black-box secure chips, smartwatch firmware teardown, blinkenlights-style extract paths; slow evidence work, not one-shot LLM “decompile.”
• VM attack comparison (QBDI vs TritonDSE) — dynamic instrumentation / DSE trade-offs against a protected VM; reminds that bytecode-ish VMs need instrumentation evidence, not fluent narrative alone.
• Obfuscation — same cost-multiplier theme as the AI-assisted RE post; hardening raises agent cost, it does not mint verified SoT.

Spark implication: treat any LLM / agent decompile or rename as assist only. Verified bytes and behavior stay --compile / dump.py / --run-bc (+ human). Never promote model text to SPARK_BC SoT because it “looked right.”

Plain English: demystifying LLM decompilation

Overview cite: https://ai.plainenglish.io/demystifying-decompilation-with-large-language-models-0e63bf067045

Use as a readable overview of how LLM decompile pipelines are framed in industry writing (stages, assist roles, failure modes). It does not change Spark policy: dump/--compile/--run-bc remain SoT; LLM text is assist; no perfect SPARK_BC recovery claim;

Bytecode / other RE note

Native x86/ARM C recovery dominates the literature. JVM/Python/WASM and custom ISAs (including SPARK_BC) are under-covered. Do not assume LLM4Decompile-style models or DecompAI tool loops transfer to Spark orchestration opcodes without new data and evals.

How this maps to Spark SPARK_BC

Deterministic disasm vs LLM naming: Spark dump is the ground truth of what is in the file. An LLM may invent prettier names that are wrong. Always recompile and re-dump to verify.

Recommendations for Spark

1. Keep deterministic decompiler/inspect (dump.py, --run-bc) as SoT.
2. Optional later: LLM assist lane that consumes dump text only (comments / rename proposals) — never silent rewrite of .sparkbc.
3. Do not claim Spark “beats” LLM4Decompile / Nova / DecompAI / OpenBin on native binary benchmarks — different problem, different metrics.
4. If evaluating assist: measure dump→suggested-name accuracy and recompile round-trip — and remember recompile more ≠ preserve more (arXiv:2609.05370).
5. Treat agent loops (DecompAI / OpenBin-class) with the same Quarkslab caution: tool traces can still cheat or invent; require dump/--run-bc gates. Prefer local artifacts over third-party upload for proprietary SPARK_BC.
6. Prefer CPU or a consumer GPU for any SPARK_BC factory GPU train.

Operator brief (short)

• Specialized models (LLM4Decompile End/Ref, Nova, SK², AutoDecompiler, DecLLM, HELIOS, ReF) help native binary→C with partial re-exec; none are SPARK_BC SoT.
• DecompileBench (ACL) and Recompile More / Preserve Less both warn: readable / recompilable output can still be semantically wrong — call this out for any future Spark LLM assist.
• OpenBin = online commercial/community AI RE product — distinct from open research weights; not Spark SoT; third-party trust/IP.
• DecompAI = agent + tools, not the same as seq2seq decompile models.
• Quarkslab: agents evade, hallucinate, and write confident wrong artifacts — another reason LLM ≠ verified decompile SoT. Keep following the RE category index (firmware, QBDI/TritonDSE VM attacks, obfuscation) without scraping it into this page.
• Plain English demystify piece is a readable overview only — not a SPARK_BC fidelity claim. Google AI Overview clusters are secondary.
• General LLMs + Ghidra plugins excel at annotation, not guaranteed recovery.
• Spark path: compile/dump/run deterministic; LLM optional for docs- level assist only.

Related

• Decompile · COMPILE.md
• Factory hub · SPARK_BC.md
• Diagrams (Mermaid; screenshots live on DECOMPILE)