💻 computer science

LLMs as Idiomatic Decompilers: Recovering High-Level Code from x86-64 Assembly for Dart

This paper demonstrates that small, specialized LLMs augmented with synthetic same-language data can effectively decompile x86-64 assembly into readable, idiomatic Dart code, achieving performance comparable to much larger models while revealing a capacity threshold for effective cross-lingual transfer from related languages like Swift.

Original authors: Raafat Abualazm, Ayman Abo Elhassan

Published 2026-04-03

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Raafat Abualazm, Ayman Abo Elhassan

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you find an old, dusty book written in a secret code (machine code/assembly). You want to read it, but the only way to understand it is to translate it back into a modern language like English (or in this case, Dart, a language used to build apps).

Traditionally, computers have been terrible at this translation. They act like a rigid dictionary that turns the secret code into a list of generic labels like "Variable 1," "Variable 2," and "Do Stuff." It's technically correct, but it's impossible for a human to read or understand.

This paper is about teaching a small, smart AI to be a much better translator. Here is the story of what they did, explained simply.

1. The Goal: From "Robot Speak" to "Human Story"

The researchers wanted to take x86-64 assembly (the raw, messy instructions a computer CPU actually runs) and turn it back into Dart code (the clean, readable code a human developer writes).

Think of assembly as a pile of loose Lego bricks. The goal is to snap them back together into a beautiful, recognizable castle. The problem? Most AI translators just glue the bricks together randomly. They want an AI that knows how a castle is supposed to look.

2. The Secret Sauce: Two Ways to Teach the AI

The researchers had a problem: They didn't have enough examples of Dart code to teach the AI properly. So, they tried two different "tutoring strategies":

Strategy A (The Pure Dart Tutor): They fed the AI thousands of examples of Dart code and its corresponding assembly. They even used other AIs to invent new practice problems (synthetic data) to give the student more homework.
Strategy B (The "Cousin" Tutor): They thought, "Dart is very similar to Swift (another popular app language). Maybe if we teach the AI Swift too, it will learn the concepts faster?" It's like teaching someone French by also teaching them Spanish, hoping the similarities help.

3. The Big Discovery: Size Matters!

This is the most interesting part of the paper. They tested this on two different sizes of AI "brains": a small one (4 Billion parameters) and a medium one (8 Billion parameters).

The Small Brain (4B): When they tried to teach it both Dart and Swift, it got confused. It was like trying to teach a toddler French and Spanish at the same time; the languages started mixing up, and the toddler made mistakes.
- Result: The small brain worked best when it only studied Dart. Adding Swift actually made it worse.
The Medium Brain (8B): This brain was big enough to handle the confusion. It could look at Swift and Dart, see the similarities, and say, "Aha! They both use 'optional types'!"
- Result: The medium brain got much better when it studied both languages.

The Lesson: There is a "tipping point" (a capacity threshold). If the AI is too small, mixing languages hurts it. If it's big enough, mixing languages helps it learn faster.

4. The Results: Small but Mighty

The researchers found something amazing:

They trained a tiny AI (4B parameters) for just 1.5 hours on a single graphics card.
This tiny AI produced Dart code that was almost as good as a giant AI (480B parameters) that is 120 times bigger and requires a massive supercomputer to run.
The tiny AI didn't just produce code that worked; it produced code that looked idiomatic. It used proper variable names (like userList instead of v1) and followed the style rules of Dart developers.

5. The Catch (Limitations)

The paper admits a few flaws, like a student admitting they cheated a little:

The "Optimization" Mismatch: The Dart examples they used were "super-optimized" (like a race car engine), but the Swift examples were "unoptimized" (like a family sedan). This made it a bit harder to compare them fairly.
It Compiles, But Does It Work? They checked if the code could be compiled (turned into a program), but they didn't fully check if the program did the exact right thing logically. It's like checking if a sentence is grammatically correct, but not checking if the story makes sense.

The Bottom Line

This paper proves that you don't need a supercomputer to reverse-engineer modern apps. A small, specialized AI, trained for a short time, can act like a professional translator, turning messy machine code back into clean, readable human code.

It's like taking a tiny, smart apprentice and giving them a specific, focused book to study, rather than hiring a giant, expensive library of books that no one has time to read. For the first time, we have a practical way to understand the "secret code" of modern mobile apps without needing a massive budget.

1. Problem Statement

Reverse engineering machine code back into human-readable high-level languages is a critical challenge. Traditional decompilers (e.g., IDA Pro, Ghidra) produce functionally correct but often unreadable code characterized by generic variable names (e.g., v1, v2) and a lack of semantic context. While recent Large Language Model (LLM) research has improved decompilation for C, modern, object-oriented languages like Dart and Swift remain largely unexplored. These languages present unique challenges due to their rich type systems, null-safety features, and extensive abstraction layers.

The core research question addresses the low-resource scenario: When target-language data (Dart) is scarce, is it more effective to:

Augment training with synthetic same-language examples?
Augment training with data from a closely related language (Swift) to leverage cross-lingual transfer?

2. Methodology

Dataset Construction

The authors constructed a specialized dataset comprising:

Natural Data: 246 Dart functions derived from RosettaCode projects.
Synthetic Data: Generated using multiple LLMs (GPT, Claude, DeepSeek, Qwen) to create diverse coding styles and complexity levels.
Cross-Lingual Data: 754 Swift functions (compiled from unoptimized code) added to a subset of the training set to test cross-language transfer.
Assembly Generation:
- Dart: Compiled using dart compile aot-snapshot (production-level AOT optimization, including type propagation and inlining) to simulate real-world binaries.
- Swift: Compiled with -O0 (no optimization) to preserve source-to-assembly mapping during initial training.
Test Set: 73 held-out Dart functions (diverse complexity) and a subset of 34 natural Dart functions for specific evaluation.

Model Architecture & Training

Base Models: Two state-of-the-art models were selected:
- Qwen3-4B (4.0B parameters).
- DeepSeek-R1-0528-Qwen3-8B (8.0B parameters).
Fine-Tuning: Both models were fine-tuned using LoRA (Low-Rank Adaptation) with DoRA (Weight-Decomposed Low-Rank Adaptation) enhancements.
- Targeted all attention and FFN projections.
- Hyperparameters: Rank $r=32$ , $\alpha=32$ , dropout 0.09.
- Training utilized AdamW (8-bit paged) with a learning rate of $2 \times 10^{-5}$ .
Special Features: The training data included "thinking tokens" (Chain-of-Thought traces) from DeepSeek-R1 to help models understand the reasoning behind code transformations.

Evaluation Metrics

The study employed a dual-metric evaluation protocol:

CODEBLEU: Measures semantic similarity by combining n-gram matches with Abstract Syntax Tree (AST) and data-flow analysis.
compile@k: Measures syntactic correctness by calculating the percentage of top- $k$ generated hypotheses that successfully compile with the Dart compiler.
Statistical Rigor: All metrics include 95% Confidence Intervals (Wilson intervals for proportions, Normal CIs for means) and two-proportion z-tests for significance.

3. Key Contributions

First End-to-End Study: The first neural decompilation study targeting x86-64 assembly to Dart/Swift with idiom-aware evaluation.
Data Strategy Comparison: A direct empirical comparison of synthetic augmentation vs. cross-lingual transfer (Swift $\to$ Dart) under low-data constraints.
Capacity Threshold Discovery: Identification of a model capacity threshold (~8B parameters) determining the efficacy of cross-lingual training.
Efficiency: Demonstrated that small specialized models (4B) can approach the performance of massive code models (~480B) with minimal compute (1.5 hours on a single GPU).

4. Key Results

Code Readability (CODEBLEU)

4B Model Performance: The specialized 4B Dart model (Decompiler-v1) achieved a 71.3 CODEBLEU score.
- This is a 5.2-point improvement over the base 4B model (66.1).
- It is comparable to a ~480B code model (Qwen3-Coder-Plus, 73.1), despite having 120x fewer parameters.
Impact of Cross-Lingual Training (The Capacity Threshold):
- At 4B: Adding Swift data degraded performance (69.3 vs. 71.3). The model suffered from negative transfer/interference due to insufficient capacity to disentangle the two languages.
- At 8B: Adding Swift data significantly improved performance (68.2 vs. 59.5), showing an 8.7-point gain. The larger capacity allowed the model to leverage shared structures between Dart and Swift without confusion.

Syntactic Correctness (compile@k)

On a subset of 34 natural Dart functions, the specialized 4B model achieved a 79.4% compile@k5 rate, compared to 64.7% for the base model.
While this represents a 14.7 percentage point improvement, the difference was not statistically significant ( $p \approx 0.18$ ) due to the small sample size and wide confidence intervals.

Trade-offs

Coverage vs. Similarity: The specialized model successfully compiled more difficult cases that the base model failed to compile. However, the code that did compile had a slightly lower average CODEBLEU score (0.517 vs. 0.607 for the base), suggesting the specialized model tackles harder problems where perfect semantic matching is more difficult.

5. Significance and Limitations

Significance:

Practical Applicability: The study proves that small, specialized LLMs are viable tools for reverse engineering modern, optimized binaries (AOT Dart), offering a computationally efficient alternative to massive models.
Idiomatic Recovery: The models successfully recovered meaningful identifiers and language-specific constructs (e.g., null-safety, arrow functions), moving beyond generic variable naming.
Strategic Insight: The findings provide a clear guideline for training strategies: use cross-lingual data only if the model capacity is sufficient (likely >8B); otherwise, focus on high-quality synthetic same-language data.

Limitations:

Compilation $\neq$ Semantics: compile@k validates syntax but not functional correctness (unit tests).
Optimization Mismatch: The Dart training data was AOT-optimized, while Swift data was unoptimized (-O0). This introduces a confounding variable when comparing cross-lingual transfer.
Human Evaluation: Idiomaticity was assessed by a single reviewer without inter-rater reliability metrics.
Reproducibility: Some hyperparameters (random seeds, warmup schedules) were not fully logged.

Conclusion

The paper demonstrates that small, specialized LLMs can effectively decompile x86-64 assembly into idiomatic Dart, achieving performance comparable to models 120 times larger. Crucially, it identifies a capacity threshold for cross-lingual transfer: adding related language data (Swift) hurts small models (4B) but significantly boosts larger models (8B). This work paves the way for efficient, accessible reverse engineering tools for modern software ecosystems.