---
title: 'SK2Decompile: Skeleton-to-Skin Binary Decompilation'
url: https://www.emergentmind.com/topics/sk2decompile
type: topic
---

# SK2Decompile: Skeleton-to-Skin Binary Decompilation

SK2Decompile is a large-language-model-based binary decompilation framework that decomposes source recovery into two sequential tasks: recovering a program’s structural “skeleton” and then restoring its identifier “skin.” In its original formulation, the system takes binary-derived pseudocode, produces an obfuscated source-level intermediate representation (IR) that preserves structure while replacing user-defined identifiers with placeholders, and then generates final source code with meaningful identifiers. Its central claim is that decompilation quality improves when structural recovery and naming are optimized independently, with separate reinforcement-learning objectives for compilability and semantic naming rather than a single end-to-end token-matching objective [2509.22114].

## 1. Conceptual decomposition

SK2Decompile is motivated by a specific failure mode of single-phase LLM decompilers: simultaneously inferring control flow, data layouts, and human-meaningful identifiers is described as intractably complex, and token-level cross-entropy penalizes identifier variants even when they are semantically appropriate. The framework therefore separates decompilation into two sub-problems. The first, **Structure Recovery**, translates binary pseudocode into an IR that preserves program structure and data structures while obfuscating all identifiers with generic placeholders. The second, **Identifier Naming**, maps that IR to human-readable source code by predicting meaningful identifiers. The paper characterizes this decomposition as a way to advance correctness and readability independently [2509.22114].

The pipeline is defined over three artifacts. A binary $B$ is first converted into low-level pseudocode $P$ via IDA Pro; the paper treats pseudocode as a deterministic reflection of the binary. Structure Recovery then computes $P \rightarrow I$, where $I$ is the “skeleton,” and Identifier Naming computes $I \rightarrow C$, where $C$ is the final source program. The probabilistic formulation is expressed as
$$
P(C \mid P) \approx \sum_I P(I \mid P)\, P(C \mid I).
$$
This decomposition is tied to a Markov assumption: after structure recovery, the pseudocode is assumed to provide negligible additional naming information beyond the IR [2509.22114].

The framework is therefore not merely a prompt recipe for improving decompiler output readability. In the original paper, it is a trained two-model architecture whose phases have distinct supervision and distinct RL signals. The first phase targets structural fidelity and compilability; the second targets identifier semantics. A plausible implication is that SK2Decompile treats identifier recovery as a semantically conditioned translation problem rather than as a by-product of source reconstruction.

## 2. Intermediate representation and formal design

The IR used by SK2Decompile is described as “obfuscated source code.” It is derived from the original source by replacing all user-defined identifiers with placeholders while preserving control-flow constructs such as `while`, `for`, and `if/else`, preserving data-structure accesses, and preserving types insofar as the original source AST supports them. The placeholder space is partitioned into four categories—`func`, `type`, `field`, and `var`—and instantiated as `id_type||counter`, such as `func1`, `type3`, `field12`, or `var7`. Reserved names, including standard types like `int` and library functions like `memcpy`, are preserved based on names extracted from pseudocode, denoted $F_P$ in the paper [2509.22114].

IR construction is source-AST-driven. The paper’s IR generation algorithm parses source C into an AST, extracts reserved names from pseudocode, initializes rename maps and counters by identifier category, traverses the AST, and replaces names not found in $F_P$ with freshly assigned placeholders. Replacements are then sorted by source offset and applied to produce the IR. Pointer dereferences are normalized to field accesses, and typing is enforced indirectly through compilability rather than through any explicitly specified SSA form or formal type system [2509.22114].

The paper frames this IR choice using an Information Bottleneck perspective: identifier semantics are compressed away while structural semantics are preserved. In operational terms, the IR is designed to be close enough to source code for the second phase to recover names, but abstract enough that the first phase is not burdened by lexical reconstruction. This suggests a deliberate separation between structural semantics and developer-specific symbol semantics, which is the defining abstraction in SK2Decompile.

## 3. Training regime and reinforcement signals

Both phases are implemented as sequence-to-sequence LLMs initialized from LLM4Decompile-6.7B. Supervised fine-tuning is performed for one epoch with LLaMA-Factory, batch size 128, and learning rate $3 \times 10^{-6}$. Reinforcement learning then uses GRPO via veRL on a random subset of 50,000 samples, a restriction attributed to compute constraints rather than to a methodological choice. Inference uses vLLM with greedy decoding to minimize randomness during generation [2509.22114].

The **Structure Recovery** phase is trained first by SFT and then by compiler-driven RL. Its reward couples compilability and placeholder reconstruction. If the generated IR cannot be compiled, the reward is $0.0$. If it compiles, the reward is $1.0 + r_{\text{placeholder}}$, where
$$
r_{\text{placeholder}} = \frac{|I_{\text{gen}} \cap I_{\text{IR}}|}{|I_{\text{gen}} \cup I_{\text{IR}}|}.
$$
Compilability checks use headers synthesized via Psyche-C during RL. The conditional structure of the reward makes compilation a hard gate rather than a soft preference [2509.22114].

The **Identifier Naming** phase is also trained by SFT followed by GRPO, but with a different objective. Instead of exact token matching, it uses semantic similarity between code embeddings generated by qwen-embedding-0.6B:
$$
r_{\text{identifier}} = \cos(e_{\text{gen}}, e_{\text{src}}).
$$
This design is meant to reward semantically aligned naming even when predicted identifiers differ lexically from the reference. The paper does not specify tokenizer details, context windows, curriculum, or the exact GRPO loss beyond these reward definitions, and it explicitly does not describe joint training or explicit coordination between the two RL phases [2509.22114].

The training corpus is assembled from C programs in ExeBench and Decompile-Bench, compiled with GCC and Clang for x86 Linux at optimization levels `-O0` through `-O3`. Preprocessing removes comments, applies `clang-format` normalization, formats pseudocode to adhere to the R2I standard, performs MinHash-LSH near-duplicate removal, strips binaries, and generates pseudocode via IDA Pro. The reported scale is approximately 5 million samples, about 2 billion pseudocode tokens, about 1.5 billion IR tokens, and about 1.5 billion source-code tokens, trained on NVIDIA H800-80GB GPU clusters [2509.22114].

## 4. Evaluation results and ablations

SK2Decompile is evaluated on HumanEval, MBPP, ExeBench, and GitHub2025, using the same compilation pipeline as in training. The principal metrics are **re-executability rate**, defined by recompiling the decompiled code and running predefined unit tests; **R2I** (Relative Readability Index for Decompiled Code), an AST-based readability metric normalized to $[0,1]$; and **GPT-Judge**, which scores identifier naming quality from 1 to 5 using GPT-5-mini. ExeBench is excluded from re-executability because of environment constraints. For R2I, Psyche-C generates headers to improve parsing success, and non-parsing outputs receive a score of 0 rather than being discarded [2509.22114].

The main reported results are summarized below.

| Benchmark / metric | SK2Decompile | Selected comparison |
|---|---:|---:|
| HumanEval re-executability AVG | 69.00 | GPT-5-mini 56.75 |
| MBPP re-executability AVG | 59.63 | GPT-5-mini 47.23 |
| ExeBench R2I AVG | 71.50 | Idioms 60.40 |
| GitHub2025 R2I AVG | 74.99 | Idioms 57.97 |

On HumanEval, the paper reports SK2Decompile at 69.00 average re-executability versus 56.75 for GPT-5-mini, 41.71 for LLM4Decompile, and 29.81 for Idioms. On MBPP, the corresponding averages are 59.63, 47.23, 43.05, and 24.01. Per optimization level on HumanEval, SK2Decompile records 86.59 at `O0`, 70.59 at `O1`, 61.31 at `O2`, and 57.52 at `O3`. For readability, the R2I averages are 70.27 on HumanEval, 71.66 on MBPP, 71.50 on ExeBench, and 74.99 on GitHub2025. GPT-Judge results are closer: HumanEval 4.24 versus 4.23 for GPT-5-mini, MBPP 4.12 versus 4.08, ExeBench 2.42 versus 2.37, and GitHub2025 3.06 versus 2.87 [2509.22114].

The ablation study isolates both the value of decomposition and the value of RL. On HumanEval, the single-phase `pseudo-src` baseline achieves 54.86, `pseudo-ir` 62.56, `pseudo-ir-rl` 68.84, `pseudo-ir-src` 63.75, and full `pseudo-ir-src-rl` 69.00. On MBPP, the corresponding numbers are 47.51, 47.25, 57.06, 52.83, and 59.63. The paper interprets these results as showing that two-phase decomposition improves over direct pseudocode-to-source translation and that compiler-guided and semantic-similarity RL materially strengthen both phases. In particular, Structure Recovery alone surpasses the single-phase baseline on HumanEval, which the authors take as evidence that structural recovery is central to decompilation quality [2509.22114].

## 5. Relation to other decompilation paradigms

SK2Decompile belongs to a broader neural-decompilation lineage, but its abstraction differs from earlier systems. Coda, for example, is also a two-phase neural decompiler, yet its first phase generates an AST directly from disassembly using an instruction type-aware encoder and tree decoder, and its second phase performs iterative error correction guided by an ensembled neural error predictor and compilation-based verification [1906.12029]. SK2Decompile instead operates from decompiler-produced pseudocode, explicitly inserts an obfuscated source IR between pseudocode and named source, and assigns distinct RL rewards to structural recovery and naming [2509.22114].

A separate external evaluation appears in “Constraint-Guided Multi-Agent Decompilation for Executable Binary Recovery,” which treats SK2Decompile as a readability-oriented two-phase baseline and compares it with Agent4Decompile under model parity. In that paper, SK2Decompile is simulated on Ghidra output using DeepSeek-V3.2, and all methods receive the same raw decompiler output. On a 157-binary benchmark with Ghidra output, the simulated SK2Decompile achieves 21.0% average re-executability, with 32.4 at `O0`, 17.5 at `O1`, 20.0 at `O2`, and 15.0 at `O3`, whereas Agent4Decompile reaches 50.3% and a single-pass DeepSeek baseline reaches 35.2% [2604.23940].

That comparison is accompanied by an explicit threat-to-validity caveat. The Agent4Decompile paper notes that the original SK2 model targets IDA Pro pseudocode, whereas the simulation is conducted on Ghidra output; it therefore presents the result as a workflow comparison under identical backbone and input conditions rather than as a definitive statement about the original SK2Decompile implementation. The same paper further argues that, in its simulated form, SK2Decompile lacks hierarchical validation and execution feedback, and that this limits re-executability even when code becomes more readable [2604.23940]. Read alongside the original SK2Decompile paper, a plausible interpretation is that SK2Decompile’s strongest evidence concerns structure-and-naming recovery benchmarks rather than full behavioral equivalence under adversarial decompiler artifacts.

## 6. Limitations, interpretation, and nomenclature

The original SK2Decompile paper identifies several boundaries on interpretation. It notes that commercial software often uses obfuscation that makes effective decompilation infeasible and states that the framework is trained on open-source datasets targeting realistic but not heavily obfuscated commercial binaries. Re-executability is not measured on ExeBench because of environment issues after stripping. RL is performed on only 50,000 samples because of computational cost. The paper does not specify tokenizers, context-window sizes, precise GRPO objective functions, pass@k metrics, confidence intervals, or statistical tests, and it does not provide latency measurements beyond stating that greedy decoding is used at inference [2509.22114].

The IR itself is also intentionally source-like rather than formally typed in an SSA or theorem-proving sense. The paper explicitly states that no SSA form or special typing conventions are specified beyond structural preservation and indirect type enforcement through compilability. This leaves open the possibility that type-intensive or alias-heavy recovery regimes would require additional mechanisms. The authors also do not discuss overfitting analyses or robustness to extreme domain shifts, inlined assembly, or non-standard calling conventions [2509.22114].

A separate source of confusion is nomenclature. The decompilation literature includes **sc2dec**, short for **Self-Constructed Context Decompilation**, which is a different method: an inference-time procedure that recompiles a model’s own output to construct in-context exemplars, optionally combined with Fine-grained Alignment Enhancement. That paper notes that the method is sometimes seen as “SK2Decompile,” but explicitly states that the canonical name is **sc2dec** [2406.17233]. In contrast, **SK2Decompile** properly denotes the 2025 “skeleton-to-skin” framework centered on IR obfuscation, two-phase training, and phase-specific RL [2509.22114].

Within those limits, SK2Decompile occupies a distinct position in neural decompilation. It is neither a pure end-to-end source reconstructor nor a purely post hoc identifier renamer. Its defining contribution is the formal separation of structure recovery from naming recovery, operationalized through an obfuscated source IR and two distinct reward functions. The empirical record reported by its own paper is strongest on re-executability and readability benchmarks such as HumanEval, MBPP, ExeBench, and GitHub2025, while subsequent work has clarified that high readability and modest compilability do not by themselves guarantee behavioral equivalence under stricter executable-recovery settings [2509.22114].

Source: https://www.emergentmind.com/topics/sk2decompile