SK2Decompile: Skeleton-to-Skin Binary Decompilation

• SK2Decompile is a binary decompilation framework that separates the process into two phases: structure recovery and identifier naming.
• The system employs an obfuscated intermediate representation to preserve control-flow and data structures while masking user-defined identifiers.
• Reinforcement learning tailored to compilability and semantic naming underpins its two-phase approach, yielding improved readability and re-executability.

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 $P$0. If it compiles, the reward is $P$1, where

$P$2

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 (Tan et al., 26 Sep 2025).

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:

$P$3

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 $P$4; 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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Fu et al., 2019). 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 (Tan et al., 26 Sep 2025).

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% (Zhang et al., 27 Apr 2026).

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 (Zhang et al., 27 Apr 2026). 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 (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).

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 (Feng et al., 2024). In contrast, SK2Decompile properly denotes the 2025 “skeleton-to-skin” framework centered on IR obfuscation, two-phase training, and phase-specific RL (Tan et al., 26 Sep 2025).

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 (Tan et al., 26 Sep 2025).