PaperlayerView exact revision on arXiv

Source-linked AI summary

SLaDe: A Portable Small Language Model Decompiler for Optimized Assembly

Jordi Armengol-Estapé, Jackson Woodruff, Chris Cummins, Michael F. P. O'Boyle

arXiv:2305.12520v3cs.PLcs.AI

TL;DR

Existing decompilers are hard to read or cannot handle external types, while neural methods often use synthetic data and generate incorrect code. SLaDe uses type inference with PsycheC to complete partial C programs and address missing types in generated code. Across more than 4,000 functions, SLaDe is more accurate and readable than BTC, Ghidra, and ChatGPT across two ISAs and optimization levels.

  • Problem

    Existing decompilers are hard to read or cannot handle external types, while neural methods often use synthetic data and generate incorrect code.

    Source: §I · p. 1

  • Method

    SLaDe uses type inference with PsycheC to complete partial C programs and address missing types in generated code.

    Source: B. Type Inference · p. 6

  • Results

    Across more than 4,000 functions, SLaDe is more accurate and readable than BTC, Ghidra, and ChatGPT across two ISAs and optimization levels.

    Source: A. Summary of Approach · p. 2, §X · p. 11

  • Takeaways & Limitations

    SLaDe demonstrates that combining neural translation with type inference can deliver portable decompilation that is both readable and correct within the evaluated scope.

    Source: A. Summary of Approach · p. 2, §X · p. 11

    Future work should extend decompilation to larger program units and further investigate integrating learnable and analytic approaches.

    Source: §X · p. 11

Abstract

from arXiv · show

Decompilation is a well-studied area with numerous high-quality tools available. These are frequently used for security tasks and to port legacy code. However, they regularly generate difficult-to-read programs and require a large amount of engineering effort to support new programming languages and ISAs. Recent interest in neural approaches has produced portable tools that generate readable code. However, to-date such techniques are usually restricted to synthetic programs without optimization, and no models have evaluated their portability. Furthermore, while the code generated may be more readable, it is usually incorrect. This paper presents SLaDe, a Small Language model Decompiler based on a sequence-to-sequence transformer trained over real-world code. We develop a novel tokenizer and exploit no-dropout training to produce high-quality code. We utilize type-inference to generate programs that are more readable and accurate than standard analytic and recent neural approaches. Unlike standard approaches, SLaDe can infer out-of-context types and unlike neural approaches, it generates correct code. We evaluate SLaDe on over 4,000 functions from ExeBench on two ISAs and at two optimizations levels. SLaDe is up to 6 times more accurate than Ghidra, a state-of-the-art, industrial-strength decompiler and up to 4 times more accurate than the large language model ChatGPT and generates significantly more readable code than both.

I. INTRODUCTION

Decompilers must balance readability, correctness, external-type handling, real-world applicability, and portability. SLaDe addresses these goals with a neural assembly-to-C model, type inference, and evaluation across diverse binaries.

I. INTRODUCTION

  • Traditional decompilers produce hard-to-read code and cannot reliably determine types declared outside the source assembly.Their readability depends on extensive pattern-matching rules and programmer assistance for external declarations.Source: §I · p. 1
  • Neural decompilers improve readability but commonly rely on synthetic data and generate code that resembles the source while remaining incorrect.Token- or string-level similarity metrics do not capture translation correctness.Source: §I · p. 1

II. MOTIVATION

  • The paper frames its goal as combining traditional decompilers’ accuracy with neural approaches’ readability, while handling external types and portability.This motivation spans real-world code, multiple ISAs, and different optimization levels.Source: §I · p. 1

A. Summary of Approach

  • SLaDe combines a 200M-parameter Transformer trained on real-world functions with novel tokenization, no-dropout training, and type inference.The model translates assembly to C and uses PsycheC to complete missing types.Source: A. Summary of Approach · pp. 1–2
  • SLaDe targets portable decompilation across ISAs and optimization levels, unlike existing neural work focused on x86.The paper presents it as the first neural decompiler applied across ISAs and optimization levels.Source: A. Summary of Approach · p. 1
  • Across more than 4,000 ExeBench programs, SLaDe is more accurate and readable than BTC, Ghidra, and ChatGPT across ISA and optimization settings.It is up to 6× more accurate than Ghidra and up to 4.2× more accurate than ChatGPT.Source: A. Summary of Approach · p. 2

A. Examples

Examples show that optimization makes assembly difficult to interpret and that SLaDe combines readable output with correct behavior. Its pipeline uses Transformer translation, type inference, and I/O-based checking.

A. Examples

  • GCC -O3 transforms a simple loop into 55 lines of assembly with unrolling, vectorization, multiple loops, and vector instructions.This illustrates why optimized assembly is difficult to map back to source structure.Source: A. Examples · p. 2
  • Ghidra can be correct but remains verbose and tightly coupled to assembly structure, without interpretable variable names.Its output bears little resemblance to the original source code.Source: A. Examples · p. 2
  • BTC produces less verbose output than Ghidra but lacks a function header and has incorrect behavior, while ChatGPT generates complete yet complex and incorrect code.ChatGPT also introduces x86 intrinsics that obscure the function’s meaning.Source: A. Examples · p. 2
  • SLaDe’s output preserves correct control flow and equivalent behavior while making the function’s purpose immediately apparent.Its variable names and pointer-versus-array declaration may differ from the original without changing functionality.Source: A. Examples · p. 2

B. Our Approach

  • The approach trains a sequence-to-sequence Transformer on assembly–C pairs with cross-entropy loss and no dropout, then uses beam search, type inference, and I/O examples.SLaDe directly consumes assembly instructions rather than machine bytes and supports x86 and Arm at O0 and O3.Source: B. Our Approach · p. 2, §III · p. 2

A. Examples

  • SLaDe produces readable, correct code, whereas Ghidra and ChatGPT are difficult to read and ChatGPT is incorrect; BTC is readable but incorrect.The comparison uses GCC O3 input for most techniques and O0 for BTC.Source: Figure 1 · p. 3

A. Equivalence

SLaDe evaluates decompilation using semantic equivalence rather than surface similarity alone. Because full equivalence is undecidable, it combines finite-set I/O checking with edit similarity as a readability measure.

A. Equivalence

  • Correct translation requires assembly and C programs to have identical meaning, ideally preserving program state rather than only return values.The paper notes that general equivalence is undecidable.Source: A. Equivalence · p. 3
  • The evaluation therefore uses input/output equivalence over finite subsets, treating tested behavior as a decidable approximation to full equivalence.The method assumes termination and becomes more confidence-inspiring as the finite test subset grows, without guaranteeing equivalence over infinite domains.Source: A. Equivalence · pp. 3–4
  • The pipeline trains the Transformer, generates C, uses PsycheC [15] for missing types, and checks executable outputs with I/O examples.This connects the model’s generated code to the paper’s correctness evaluation.Source: Figure 2 · p. 4
  • Edit similarity measures readability by normalizing edit distance from the decompiled program to the ground-truth source, with higher values indicating closer code.Edit distance counts the minimum insertions, deletions, and replacements needed for transformation.Source: A. Equivalence · p. 4

IV. TOKENIZATION

SLaDe uses subword tokenization tailored to code so identifiers and unseen tokens remain representable. Its edit-distance dynamic program supports the normalized readability metric.

IV. TOKENIZATION

  • Subword tokenization prevents unknown identifiers by constructing unseen tokens from character-level or smaller seen subwords.The tokenizer is based on UnigramLM [26] and can represent characters present in the training set.Source: §IV · p. 4
  • The edit-distance algorithm computes the minimum sequence edits through delete, insert, and replace cases, using ε for the empty sequence.The resulting distance is converted into edit similarity by normalizing against target length.Source: §IV · p. 4, Figure 3
  • The tokenizer uses an 8k vocabulary, digit-by-digit number encoding, separate punctuation tokens, and protected spaces inside string literals.These choices are adapted to the smaller vocabulary of C keywords and assembly opcodes.Source: §IV · pp. 4–5

V. TRAINING

SLaDe formulates decompilation as sequence-to-sequence translation from assembly functions to C functions, trained by maximum likelihood with cross-entropy. Its training uses real-world assembly–C pairs and Transformer encoder–decoder components with residual connections, attention, causal masking, and teacher forcing.

V. TRAINING

  • SLaDe trains a parameterized model on paired assembly and C functions using maximum likelihood estimation, implemented by minimizing cross-entropy.Source: §V · p. 5

A. Training dataset

  • The expanded AnghaBench dataset contains around 4M real-world compilable C functions paired with function-level assembly, deduplicated against the test set.Functions are used instead of whole programs to avoid longer, more computationally difficult sequences.Source: A. Training dataset · p. 5
  • SLaDe trains without surrounding context, predicting external functions, typedefs, and variables through later type inference.Evaluation restores the original C-program context and uses inferred types for compilation and execution.Source: A. Training dataset · p. 5

B. Sequence-to-Sequence Transformer

  • The encoder uses stacked blocks combining multi-head attention, layer normalization, feed-forward networks, and residual connections.Residual connections ease learning and enable deeper models.Source: B. Sequence-to-Sequence Transformer · p. 5
  • The decoder adds encoder–decoder attention and causal masking, then projects outputs into vocabulary-token probabilities.Causal masking prevents future target tokens from leaking into decoder inputs during training.Source: B. Sequence-to-Sequence Transformer · p. 5

C. Model Architecture and Training Details

SLaDe uses a BART-derived Transformer trained with Adam and weight decay instead of dropout, then performs beam-search inference followed by type inference. PsycheC resolves missing or ambiguous types by generating constraints, solving them, and injecting compilable dependencies.

C. Model Architecture and Training Details

A. Model Inference

  • Beam search with beam size k = 5 retains the highest-probability hypotheses and selects the first one passing IO tests.The model is small enough to run with decent latency on consumer CPUs.Source: §VI · p. 6, A. Model Inference · p. 6

B. Type Inference

  • PsycheC converts partial C programs with missing types into complete compilable programs by parsing ambiguities, generating type constraints, and solving them.Its constraints capture equivalences such as τ1 = τ2 ⇒ τ1* = τ2*.Source: B. Type Inference · p. 6

VII. RESULTS

SLaDe is evaluated against Ghidra, ChatGPT, and BTC on Synth and ExeBench across x86 and ARM at -O0 and -O3, using IO accuracy and edit similarity. Results show strong performance on optimized and real-world benchmarks, while simpler unoptimized Synth cases favor Ghidra slightly in accuracy.

VII. RESULTS

  • SLaDe is compared across two ISAs, two optimization levels, and two benchmark suites using IO accuracy and normalized edit similarity.ExeBench contains about 4,000 unseen test programs and includes challenging user-defined types and external calls.Source: §VII · p. 6, 1) Benchmarks · p. 6

2) Decompilers:

  • SLaDe produces 1.17x to 3.83x more correct code and higher edit similarity than Ghidra, ChatGPT, and BTC on x86 ExeBench.Figure 4 covers -O0 and -O3 using IO accuracy and edit similarity; BTC’s reported edit distance comes from a different -O0-only dataset.Source: Figure 4 · p. 7
  • SLaDe produces 2.2x to 6.32x more accurate code and higher edit similarity than existing techniques on ARM ExeBench across -O0 and -O3.Source: Figure 5 · p. 7
  • On simpler unoptimized Synth benchmarks, Ghidra has slightly higher IO accuracy than SLaDe on both x86 and ARM.Source: Figure 6 · p. 7
  • On optimized Synth benchmarks, SLaDe produces 1.81x to 4.28x more accurate code, with smaller degradation than Ghidra under optimization.SLaDe has superior accuracy and readability for both ISAs in this setting.Source: Figure 7 · p. 7
  • All approaches decompile shorter assembly more accurately, while neural methods decline more steeply with program length than Ghidra.ExeBench’s assembly-length distribution is biased toward shorter sequences.Source: Figure 8 · p. 8, Figure 9 · p. 8

B. x86 Decompilation

On x86, SLaDe substantially outperforms competing approaches on both unoptimized and optimized ExeBench code, while retaining higher readability. Its advantage persists on ARM, where portability exposes a much larger accuracy degradation for Ghidra.

B. x86 Decompilation

  • Almost 60% of unoptimized x86 ExeBench programs are accurately decompiled by SLaDe, 17% more than Ghidra and more than twice ChatGPT.BTC does not accurately decompile any programs in this comparison.Source: B. x86 Decompilation · p. 8
  • SLaDe achieves over 70% edit similarity on unoptimized x86, compared with 40%–44% for the other approaches.Ghidra’s edit similarity is similar to ChatGPT’s in this evaluation.Source: B. x86 Decompilation · p. 8
  • Almost three times as many optimized x86 programs are correctly decompiled by SLaDe as Ghidra, and almost four times as many as ChatGPT.SLaDe’s generated code is also nearly twice as readable as Ghidra’s and ChatGPT’s in this setting.Source: B. x86 Decompilation · p. 8

C. ARM Decompilation

  • On ARM, SLaDe’s accuracy and edit similarity decline slightly relative to x86, while Ghidra’s accuracy declines by at least a factor of two.SLaDe is more than 2× as accurate as Ghidra on -O0 and more than 6× as accurate on -O3; ChatGPT is 3× less accurate than SLaDe.Source: C. ARM Decompilation · p. 8

D. Discussion

SLaDe’s type inference addresses a central source of Ghidra’s correctness failures, but simpler synthesis benchmarks reveal a trade-off between accuracy and readability. The reported failure cases show that type prediction and compiler optimization remain practical boundaries.

D. Discussion

  • Ghidra leaves external types and functions undefined, causing many IO failures because its outputs are not compilable without programmer intervention.Filling in those missing dependencies is non-trivial because Ghidra’s generated code is difficult to understand.Source: D. Discussion · pp. 8–9

E. Synthesis Benchmark

  • On unoptimized simple benchmarks, SLaDe and Ghidra both exceed 80% IO accuracy, but SLaDe has more than double Ghidra’s edit similarity on both x86 and ARM.Ghidra leads accuracy by 5% on x86 and 20% on ARM, while SLaDe remains more readable.Source: E. Synthesis Benchmark · p. 9
  • Optimization sharply reduces Ghidra’s performance, especially on ARM where IO accuracy falls by over two-thirds, while SLaDe retains superior accuracy and readability.Ghidra’s and ChatGPT’s readability almost halves after optimization, whereas SLaDe experiences only a small degradation.Source: E. Synthesis Benchmark · p. 9

F. SLaDe failure

  • SLaDe can mistype function arguments when common training examples bias its type prediction toward an incorrect type.One reported failure assigns a matrix argument an integer-array type instead of float-related typing.Source: F. SLaDe failure · p. 9
  • Compiler optimization can obscure assembly enough that Ghidra produces correct code at -O0 but non-compilable code at -O3.The example also shows SLaDe producing semantically related code with different struct and field names and altered increment operations.Source: F. SLaDe failure · p. 9

VIII. ANALYSIS

SLaDe’s accuracy declines with longer assembly and varies by program characteristics, while type inference materially improves executable correctness. Compilation is broadly associated with IO accuracy, whereas neural approaches show greater sensitivity to training-distribution effects than Ghidra.

A. Impact of Assembly Length on Accuracy

  • All three decompilers perform better on shorter assembly, but ChatGPT and SLaDe decline more steeply with length than Ghidra.The analysis links the steeper neural decline to greater sensitivity to the distribution of training examples.Source: A. Impact of Assembly Length on Accuracy · p. 9

B. Impact of type inference

  • 14% average improvement from type inference comes from generating missing typedefs that make otherwise correct code compile and execute.The ablation attributes these recovered cases to inferred typedefs required by the generated code.Source: B. Impact of type inference · pp. 9–10
  • SLaDe exceeds 80% IO accuracy on simple integer benchmarks but reaches only 40% on x86 and 60% on Arm for functional-programming benchmarks.These results show strong dependence on program type and architecture.Source: Figure 11 · p. 10

C. Features

  • Compilation is important across approaches and ISAs, but ChatGPT’s weaker correlation reflects compilable programs that remain incorrect.Edit similarity matters particularly for neural schemes, while longer programs show a small negative correlation with accuracy and other feature correlations are weak.Source: C. Features · p. 10

D. Impact of Program Type

Program type strongly affects decompilation performance, with SLaDe especially strong across Arm categories. The paper positions SLaDe as a real-world, portable neural decompiler that combines type inference with supervised translation, while noting broader future directions and artifact constraints.

D. Impact of Program Type

  • On Arm, SLaDe outperforms across all benchmark categories, while ChatGPT and Ghidra each fail on categories they handle better on x86.On x86, Ghidra and SLaDe tie in four groups, Ghidra wins L2, and SLaDe wins the remaining three; ChatGPT fails on Sketchadapt.Source: D. Impact of Program Type · p. 10

IX. RELATED WORK

  • Earlier neural decompilers primarily targeted readable code from short synthetic or restricted snippets rather than semantically correct real-world programs.Related work also includes binary-source matching and neural code translation, which address adjacent tasks rather than this generative setting.Source: §IX · pp. 10–11

X. CONCLUSION AND FUTURE WORK

  • SLaDe is the first neural decompiler described here as portable across ISAs and optimization levels, combining supervised training with type-inference-based program analysis.The evaluation covers 4,000 functions across two benchmark suites, two ISAs, and two optimized-binary settings.Source: §X · p. 11
  • Future work should extend decompilation to larger program units and investigate pretraining, program repair, and tighter integration of learnable and analytic methods.The conclusion specifically identifies larger program scope as a direction for improving accuracy.Source: §X · p. 11

DATA AVAILABILITY STATEMENT

  • The accompanying artifact provides evaluation instructions, model weights, tokenizers, data, and code, but omits BTC weights and ChatGPT API keys.The paper refers readers to artifact for the available materials.Source: DATA AVAILABILITY STATEMENT · p. 11

APPENDIX

The appendix documents how to run SLaDe, its type-inference evaluation, and baseline comparisons. Reproduction requires a Unix-like environment with specified software and system dependencies, and some baselines have access or reproducibility constraints.

APPENDIX

  • IO evaluation executes potentially unsafe code and may fail or produce incorrect results when host dependencies and configuration differ from the expected environment.The appendix advises running the evaluation in a sandbox.Source: APPENDIX · p. 14

A. Running SLaDe

  • Running SLaDe requires additional dependencies for type inference and IO evaluation, including Python packages, PsycheC, Haskell Stack, GCC, and an AArch64 cross-compiler.The documented setup assumes a Unix, ideally Ubuntu, machine and specifies Python 3.8, PyTorch 1.10.2, and Transformers 4.22.2.Source: A. Running SLaDe · p. 14
  • SLaDe inference decodes generated C from assembly, while evaluation can enable or disable type inference and select ExeBench or synthesis data.The appendix exposes these choices through the INFER_DEPS, EVAL_DATA_PATH, and DIRECTION variables.Source: A. Running SLaDe · p. 14

B. Running the baselines

  • Baseline reproduction is constrained because ChatGPT outputs may change, BTC weights are unavailable, and BTC only supports x86 O0 with the ground-truth signature prepended.Ghidra additionally requires its headless Docker setup.Source: B. Running the baselines · p. 14
Loading 2305.12520v3…