Read primary-source research on AI-assisted decompilation and analyst workflows.
Research papers test a specific method under specific inputs, models and benchmarks. Start with the question and evaluation design before comparing reported numbers. A model that compiles code or passes selected tests can still misrepresent unseen behavior, and a plausible name or pseudocode fragment is not proof of original source recovery.
This collection separates the current paper title and version from historical names and records code, dataset and model availability only when a primary source supports it. The author-reported findings are useful hypotheses for tool design. Reproduce the relevant test before relying on a result in your own analysis.
ALT4Decompile explores an abstract loop-tree representation to help a language model reconstruct C-like control flow from assembly. It is relevant when a decompilation method struggles with jumps and nested loops. The current arXiv version has a changed title from the earlier SALT4Decompile version; treat both names as one evolving paper, not separate research findings.
DIRTY studies learned predictions of variable names and types for decompiler output. It addresses readability and analyst comprehension, rather than recovery of the original symbols with certainty. Use it when evaluating how much a suggested name helps navigate code, then verify any semantic interpretation against uses, data flow and observed behavior before adopting it as a fact.
Automatically Attacking Software Reverse Engineering AI Agents studies prompt injection through strings embedded in a binary. It matters for any workflow that gives decompiled text to a language-model agent: attacker-controlled target content can be mistaken for an instruction and corrupt the explanation. Use the paper as a threat model, while checking its experimental conditions before generalizing failure rates.
The AutoDecompiler paper presents feedback-driven, multi-turn refinement of decompiled code using compilation, execution and input/output tests. Its useful idea is to treat a generated program as a hypothesis that can fail observable checks. Read the reported benchmark conditions carefully: compilation success alone does not establish the same behavior as the original binary.
Decomperson investigates how people use decompiler output and what that reveals about human reverse-engineering work. It is useful for designing analyst tools and AI assistance that support real questions instead of optimizing only a code-generation score. Read the study tasks and participant conditions before treating its observations as universal behavior across every analyst and binary type.
LLM4Decompile studies language models trained to transform binary code or refine decompiler output. The paper is relevant when assessing whether an AI-generated program can be re-executed under benchmark tests. Read the task definitions, datasets and evaluation setup before interpreting its reported gains; a passing benchmark does not recover original source or prove equivalence for an unseen application.