SK2Decompile: LLM-based Two-Phase Binary Decompilation from Skeleton to Skin
Authors: Hanzhuo Tan
Weihao Li
Xiaolong Tian
Siyi Wang
Jiaming Liu
Jing Li
Yuqun Zhang
Venue: ICLR 2026 Poster (2026)
Keywords: decompilation
binary analysis
Primary area: other topics in machine learning (i.e., none of the above)

Abstract: Large Language Models (LLMs) have emerged as a promising approach for binary decompilation. However, the existing LLM-based decompilers still are somewhat limited in effectively presenting a program's source-level structure with its original identifiers.
To mitigate this, we introduce SK2Decompile, a novel two-phase approach to decompile from the skeleton (semantic structure) to the skin (identifier) of programs. Specifically, we first apply a Structure Recovery model to translate a program's binary code to an Intermediate Representation (IR) as deriving the program's "skeleton", i.e., preserving control flow and data structures while obfuscating all identifiers with generic placeholders. We also apply reinforcement learning to reward the model for producing program structures that adhere to the syntactic and semantic rules expected by compilers. Second, we apply an Identifier Naming model to produce meaningful identifiers which reflect actual program semantics as deriving the program's "skin". We train the Identifier Naming model with a separate reinforcement learning objective that rewards the semantic similarity between its predictions and the reference code. Such a two-phase decompilation process facilitates advancing the correctness and readability of decompilation independently.
Our evaluations indicate that SK2Decompile, significantly outperforms the SOTA baselines, achieving 21.6% average re-executability rate gain over GPT-5-mini on the HumanEval dataset and 29.4% average R2I improvement over Idioms on the GitHub2025 benchmark.

Published as a conference paper at ICLR 2026
DECOMILLL LLM-BASED TWO-PHASE BINARY DECOMPILATION FROM SKELETON TO SKIN
Hanzhuo Tan 1.2 Weihao Li' ,iiaolong Tian's ,Siyi Wang' ,Jiaming Liu', ,Jing Yuquu Zhang';
"Research Institute of Trustworthy Autonomous Systems, Southern University of Science and Technology *Department of Computing, The Hong Kong Polytechnic University
ABSTRACT
Large Language Models (LLMs) have emerged as a promising approach for binary decompilation. However, the existing LLM-based decompilers are still somewhat limited in effectively presenting a program's 's source-level structure with its origi- nal identifiers. To mitigate this, we introduce SK Decompile a novel two-phase approach to decompile from the skeleton (semantic structure) to the skin (identi- fier) of programs. Specifically, we first apply a Structure Recovery model trans- late a program's 's binary code to an Intermediate Representation (IR) as deriving the program's 's "skeleton", i.e., preserving control flow and data structures while ob- fuscating all identifiers with generic placeholders. We also apply reinforcement learning to reward the model for producing program structures that adhere to the syntactic and semantic rules expected by compilers. Second, apply an Identi- fier Naming model to produce meaningful identifiers which reflect actual program semanties deriving the program's is "skin". We train the Identifier Naming model with a separate reinforcement learning objective that rewards the semantic similar- ity between its predictions and the reference code. Such two-phase decompila- tion process facilitates advancing the correctness and readability of decompilation independently. Our evaluations indicate that SK2 Decompile significantly outper- forms the SOTA baselines, achieving 21.6% average re- re-executability rate gain over GPT-5-min on the HumanEval dataset and 29. 29.4% average R2I improvement over Idioms on the GitHub2025 benchmark.
INTRODUCTION
Decompilation refers to converting compiled binaries back to high-level source code and has been
widely adopted in software security tasks like malware analysis and vulnerability discovery (Brum-
ley et al. 2013 Katz et al. [2188] Wu et al. 2022 Cao et al. 2022 Fu et al.) 2019
2019|Cheer Chen al. [2225]
Gao et al. 2025a)] Huang et al. 2025] Wang et al. 2025aa] Shang et al. [025]] Hamedi et al.]
2025
Ideally, a decompiler ensures both functional correctness and code readability, which can hardly
be realized in practice at the same time. For instance, traditional tools like Ghidra (Ghidra 2024)
and IDA (Hex-Rays 2024) excel at functional correctness but often produce obfuscated, hard-to- read code, while recent Large Language Model (LLM)-based approaches (Hosscini & Gavitt
2022
Armengol-Estap
et al. 2023; Jiang al. 2025 Tan al., 2024] ylfeng et al.] 20224] Dramko
et al. 2025) generate more readable output but frequently fail to preserve the original program s
functionality (Tan et al., 2025b).
Many research efforts imply the root cause of this trade-off as the intractable complexity of simul- taneously inferring control-flow structures, data layouts, and identifiers in a single phase (Lacomis
et al., 2019: Xie et al. 2024 Chen et al.) 2022] Console et al., 2023) Patrick-Fivans et al. 2020; David et al. 2020 Li et al. 2025). To mitigate this, we introduce SK Decompile, a novel LLM- based decompilation technique that decomposes the binary decompilation task into two phases. In particular, we first derive the program's 's skeleton, i.e., its core structure, including control flow and data structure (Aho et al. (007). Then, derive the program's 's skin, i.e., the meaningful type, variable, and function names reflecting the actual program semantics (Lacomis et al. 2019). Such
"Yuqun Zhang is the corresponding author.

---

Published as a conference paper at ICLR 2026
two-phase decompilation design allows for tackling the challenges of functionality and readabil- ity independently for aggregating their respective effectiveness rather than realizing a trade-off in between. In particular, design a novel Intermediate Representation (IR) acting as the "skeleton" of the program. This IR essentially refers to the original source code with all identifiers (variable, function, and type names) replaced by generic placeholders (Lachaux al., (02T) for preserving structural and functional logic of a program, following the Information Bottleneck principle (Tishby) al. 2000, Tishby & Zaslavsky 2015). The decompilation process then split into two sequential phases: Structure Recovery where an LLM translates the compiled binary code to our structural IR and Identifier Naming where a second LLM enriches the IR by predicting meaningful names reflecting actual program semantics for all placeholders. For Structure Recovery, we first train seatueeneeto-squeeeee model (Cummins et al.] 2024, Vaswani et al.] 2017) and further tune it with reinforcement learning (RI.) (Achiam et al. (023), where the compiler checks the syntax and se- mantics to provide the reward. A positive reward is generated only if the generated IR successfully compiles, with additional rewards reflecting the correctness of placeholder recovery. For Identifier Naming, we use a separate RL reward. To better capture human-centric readability, this model is not rewarded for exact name match but for the semantic similarity between its output and the reference code (Zhang et al., 2025). In this way, SK2 Deccomplee enhances functional correctness and semantic readability simultaneously for LLM-based decompilation.
Our evaluations show that SK Decompile significantly outperforms prior SQTA models on four open-source benchmark suites. To our best knowledge, SK2 Decompile is the first to approach the average re-executability rate of 70% on HumanEval (Chen 2021) and ~60% on MBPP (Austin
al.
202T). also achieves 21.6% average re-executability rale gain over GPT-5-mini (OpenAl)
2025
on HumanEval and 29, 4% average R2I (Eom et al. 2024) improvement over Idioms (rramko
ct al.
2025) on the GitHub2025 benchmark (Tan et al. 2025b).
The code has been released in GitHub page
|
Our main contributions are as follows.
Two-phase Decompilation Framework. We propose the first decompilation framework con- sisting of two phases: Structure Recovery for advancing the recovery of source-level program structures and Identifier Naming for advancing the recovery of meaningful identifiers reflecting actual program semantics. Each phase trains a model using reinforcement learning with specific rewards respectively.
Intermediate Representation (IR), We propose our IR as the obfuscated source code. This IR satisfies the Information Bottleneck principle by maximizing the compression of the semantics embodied in identifiers while preserving the semantics embodied in the structure of the program, and it is practically simple to generate.
Extensive Evaluations. We perform extensive evaluations on SK Decompile and find that it achieves the optimal performance compared with the studied baselines. For instance, SK2 Decompile achieves 21 21.6% average re-executability rate gain over GPT-5-mini on HvmanEval and 29.4% average R21 improvement over Idioms on the GitHub2025 benchmark.
BACKGROUND
2.1 RELATED WORK
Decompilation, i.e., the reconstruction of source code from binary executables, has long relied on
control/data-Rie -low analysis and pattern matching (Brumley et al., 2013 Katz et al. 2018 Wu et al,
2022 Fu et al.] 2019). Typically, conventional decompilers like IDA Pro HexxRRas] (2024) tend to
recover a program's 's basic logic, with their generated pseudocode close to low-level assembly code,
i.., their outputs often lack readability and re-executability (Cao et al. 2024 Liu & Wang 2020).
Motivated by the success of Large Language Models (LLMs) in code-related tasks (Zeng et al. 2022
Wang et al. 2024 Jiang et al.) 2024 Su et al. 2024
Wang et al.) [025b] Szafraniec et al. 2022
2026; Gao et al. 2025b Lu et al. 2021 Tan et al. 2025a), recent research has focused on applying L.MMs to refine the pseudocode generated by traditional decompilers (Hu al.)
Xiang et al. 2024:
2024 Wong et al., 2023). Note that as pseudocode is deterministic with the corresponding binary
code, we use the terms interchangeably in this paper. Initial efforts, such as LLM4Decompile (Tan)
https: htte:://githibb.o///aaaaaaaaaaa 1Dccompp
2

---

Published as a conference paper at ICLR 2026
al. 2024), demonstrated that LLMs could effectively learn to translate low-level pseudocode to high-level source code and inspire subsequent studies (ylieng et al. 2024, Feng et al. (025). Other research focuses incorporating contextual information. For instance, Idioms (Dramko et al. 2025) enriches the input by incorporating information from adjacent functions the call graph and attempts jointly recover user-defined type definitions with the decompiled code. Recently, D-LIFT (Zou et al. 2025) enhanced the training pipeline by incorporating reinforcement learning, guided by novel reward function D-SCORE which provides multi-faceted assessment of code based on accuracy and readability. Despite these advancements, the functional correctness of LLM- based techniques remains significant challenge, with existing models failing on approximately half of the tasks in the HaimanEval--ecomppe benchmark (Tan et al. 2024).
(a) Pseudo code
(b) L.M4Decompile
(c) Source code
uint64. t esuo____0000 usub_1CDCa( long long all f-.
struct _otist
vold tab tablcReovahhiteeeae etable) { ableeter iter:
LABEL 21
FUN, wt_.Becccclsstrucc _glist L.
wfint =][at 411:
1 VAR 8->g1 next;
Entry ventry;
Mhi
SelletteiniitGitter table)y
while Tresult 65 t-resule)
While (VAn VAR
Mille (tablelte (alte, tablo, Sentry]
result
1-2gl
(result return result;
1=
toblelterieeevelaleee table);))
(Elluint #3105 1
Decompile
WhL
vold funciltypel evarl] (d) Obfuscated IR
105 (W0,, all:
VAI. 1 VAIL
typez varz:
el (VAR_3+4:))
type3 evar3:
acto LASCL 3+
else (VAR [AAR_1+++]] }}
ver1);
return [VAR_1]:)
Ahile funcitevar2, vari, warra
functiSvard,
Figure 1: An example with its (a) pseudocode, (b) refinement by LLM4Decompile, (c) source code, and (d) Obfuscated IR. red marks the while thile loop in different forms, blue represents the data access.
2.2 MOTIVATING EXAMPLE
As shown in Figure [ while LLM4Decompile, a widely-studied LLM-based decompiler, correctly interprets constructs like whiler (1) and goto LABEL_2 found in the IDA pseudocode and suc- cessfully recovers them to a semantically equivalent and more readable while loop. However, the decompiler struggles with recovering the program's 's data type structure, and its ability to sign meaningful identifier names reflecting actual program semantics remains limited. For instance, domain-specific types such as Table and Entry are erroneously mapped generic struet named _glis iliss st. This fundamental limitation in the decompiler's understanding of the data organization leads to the failure in generating meaningful identifiers. Consequently, variables and functions are reduced to generic placeholders like VAR_1 and TUN_0001ccoe making it even more difficult to understand the original intent of the program. Such deficiencies motivate two-phase decompi- lation process for recovering both program structure and meaningful identifiers respectively rather than realizing a trade-off in between, as illustrated in Section 3
3 SE'DECOMPILE
3.1 OVERVIEW
Figure presents the framework of SK2 Decompile (Skelcton-to-Skee Decompile) which includes a two-phase decompilation process, i.e., Structure Recovery and Identifier Naming (Section 3.2
which are realized upon the design of the Intermediate Representation (IR, Sections 3.3 and 3.4)
with their respective reward functions to advance the correctness and readability of the final decom- piled code (Section 3.5
3.2 TWO-PHASE DECOMPILATION PROCESS
We draw an analogy comparing the two-phase decompilation process of SK2 Decompile the struc- ture of the human body. In particular, Structure Recovery refers to constructing the global code structure, such loops, conditionals, and data structures, deriving the program's "skeleton".
3

---

Published as a conference paper at ICLR 2026
(a) Data preparation
Obfiscate Ini
Funci [typel] (
typedef int Mooce orphan*/ typel; struct TYPE 2_ int Mhos0 orphan"/ fieldl;
varr:;
psychec
SRC
Header
typez
typedel TYPE type2; int thoos orphan*/ func2 (int /Peee orphan" /
Tunc2 vara (ields))
Chip ;
in164 sub 461FF( al){ char vl;
myFune ( kmp- name
Pseudo
68
30
12
09
46
88
memopyt...) sub 44794(v2))
Bin
</>
39
(b) Structure recovery model
(c) Identifier naming model
Pscudo
IR
Func. IR
IR
SRC
Read. SRC
P(y(x)
Header
P(y|)
Qwen-Embd
SFT
RI:
not compiled
r. compiled
SFT
RL: Care)
Figure 2: Overview of the SK3 Decompile framework. (a) Data preparation: We obfuscate identi- fiers to produce an Intermediate Representation (IR). Headers are inferred using psychec to serve ground truth for checking compilability during the RL stage of Structure Recovery (b). We also compile the code and use IDA to generate initial pseudo code. SK2 SK2 Decompplee employs a two-phase decompilation process comprising (b) Structure Recovery and (c) Identifier Naming, where obfus- cated source code serves as the IR connecting the two phases. Each model undergoes Supervised Fine-Tuning (SFT) followed by Reinforcement Learning (RL) with phase-specific rewards.
Identifier Naming refers to inferring meaningful names for functions, types, fields, and variables to further reflect actual program semantics.
We formalize SK2 Decompile from probabilistic perspective. In particular, the goal of decompila- tion is to find the most probable source code (s) given low-level representation, i.e., the pseudocode (u) in paper. Correspondingly, the decompilation goal can be modeled maximizing the condi- tional probability P(sju). Our core hypothesis is that introducing an intermediate representation (i) simplify this task. Using the chain rule of probability, we can decompose the probability P(slu) as Σ, P(sli, u) Piilu). This decomposition effectively splits the decompilation task into two more manageable sub-tasks, which illustrate with the example in Figure dd and its corresponding pseudocode and source code presented in Figure Da) and Figure [c).
Structure Recovery. This phase corresponding P(ilu) focuses exclusively translating the syntax and control flow of the low-level pscudocode (Figure [a]) to well-formed, high-level IR (Figure I.)).. For example, this task includes identifying that a while (1) combined with goto LABEL_2 2 in the pseudocode corresponds to single, conditional while () loop structure the IR. This phase also transforms opaque pointer arithmetic, like * (uint8_t *) (v5 1), to clean, nested structure access var3~>fiel22->-f
Identifier Naming: This phase corresponding P(s|i, u) takes the recovered IR (Figure I)) and infers meaningful names for variables and functions to produce the final, human-readable source code (Figure [c), e-g., transforming a generic call var3->field2 -f to the one with more mcaningful, semantic names entry->key
key insight is that once the clean structured IR recovered, the original, messy pseudocode provides almost additional information for the naming task. For instance, after recovering the model no longer needs the pointer expression the structure (v5 1) infer the correct variable names. This insight allows to make (uint8_t t a Markov assumption (Evans & Rosenthal 2004), which simplifies the naming probability from P(s]i, u) Pssli). This simplification yields our final probabilistic model:
4

---

Published as a conference paper at ICLR 2026
P(sju)= =
Σ P(sli) P(ilu)
(I)
By decomposing the problem, we create a focused, two-phase process. First, solve the complex Structure Recovery challenge (P(ilu)), and then perform the Identifier Naming task on a clean, abstract representation (P(si)). In this way, we reduce the overall complexity for more robust learning and higher-quality decompilation.
3.3 INTERMEDIATE REPRESENTATION
The two-phase decompilation process necessitates an intermediate representation (IR) that serves as a bridge between pseudocode and source code. However, designing the IR presents a funda- mental challenge, i.e., must be simple enough to be reliably recovered from pseudocode, yet rich informative enough to enable accurate source code reconstruction.
This challenge naturally frames our problem as an Information Bottleneck (IB) optimization task (Tishby al. 2000; Tishby & Zaslavsky 2015). In particular, for any information flow pseu- docode - IR - source, the intermediate representation acts as a bottleneck that must balance two competing factors, i.e., compression and relevance. More specifically, compression means that the IR should discard irrelevant details from the pseudocode to make the Structure Recovery phase tractable. Moreover, relevance refers to that the IR must preserve sufficient information to recon- struct the source code in the Identifier Naming phase. Ideally, the IR should be maximally inferable from the pseudocode and structurally close to the target source code. Accordingly, the Information Bottleneck (IB) principle formalizes this trade-off through the objective:
min CIB ((u; (i; P((aa
where iu; measures the mutual information between pscudocode and IR (to be minimized) and s(i;s) measures the mutual information between IR and source code (to be maximized). Formula guides our choice of IR. We thus propose using obfuscated source code (Lachaux et al., 2021 particularly the original source with all identifiers replaced by generic placeholders. Such repre- sentation emerges naturally from the IB objectives. In particular, for the compression objective, the model should distill high-level structural abstractions from the noisy, low-level patterns of the input pseudocode. This process inherently discards irrelevant input details, thus minimizing the mutual information between the input and our IR. Meanwhile, for the relevance objective, the obfuscated code is an ideal structural representation as it can be theoretically recoverable from compiled binary code even when the semantics embodied in original identifiers lost during compilation. Conse- quently, this IR preserves the maximum possible relevant information about the source code, thereby maximizing the mutual information between the IR and the source.
Note that the obfuscated code can be automatically generated from source code through identifier obfuscation (Section 3.4b, making it practical in real world.
3.4 IR GENERATION
Algorithm 1 illustrates the process of generating the obfuscated code (IR) from the source code. Specifically, the pseudocode is first analyzed to extract all function and type names that should remain unchanged in the obfuscated code, e.g., the standard type int and library function memcpy. which are stored in the reserved list Fp (line 1). Specifically, the source code and pseudo are parsed to extract set of [Category. Name] tuples. These dictionaries are then compared across the pseudocode and source code. Whenever [Category, Name] pair matches exactly, the name is perserved in the obfuscated IR. The source code is then parsed into an abstract syntax tree (AST) to provide precise identifier positions (line 2). For each identifier category, we initialize renaming maps and counters, as well as an empty replacement list (lines 3-5). We then invoke the recursive procedure TRAVERSE on the root of the AST (lines 6-1)). During traversal, each node is classified to determine its identifier type and name (line 7). If the name does not appear in the reserved list Fp, a new obfuscated name is generated and stored in the renaming map (lines 8-1.). A replacement entry containing the start and end offsets together with the new name is then appended to the replacement list (line 14). The procedure continues recursively all children of the current node (lines 16-18)
5

---

Published as a conference paper at ICLR 2026
Algorithm Generation of Intermediate Representation (IR)
Require: Source code C, corresponding pseudocode
Ensure: Obfuscated source code (l
Analyze P to extract names that need be preserved: Fp
2: Parse C into an abstract syntax tree (AST): T
3: Initialize rename maps R[[] f- 0 for func, type, field, var
4: Initialize counters cnl[-] < 1 for each identifier type
5: Initialize replacement list +
6: Traverse(node):
7: (id type, name) t- classify node
8: if name & Fp then
9:
name & Ryyd_ then new +- id_type cnd(id type <- new
11:
ent cntped_type] t entfid.type]
13: end if
Append replacement (star((node), end(node), R(id type][name]] to C 15: end if
for each child e of node do
17:
Traverse(c)
18:
end for
19:
Obfuscate(C, L):
20:
Sort & by start position in descending order
21: Let IR be mutable copy of C
22:
for each (s, e, new) in do
Replace substring [R(s: e] with new
24:
end for
25: return IR
26:
return IR
After traversal, the replacements are applied (lines 19-25) OBFUSCATE where the list sorted in descending order of start position (line 20) that later modifications do not shift earlier offsets, and all substitutions are performed on the original code (lines 21 21-24). Finally, the obfuscated code, namely, IR, is returned (line 26).
3.5 ENHANCEMENT WITH REINFORCEMENT LEARNING
To recover the structured IR from pscudocode and the identifier names from the structured IR, we adopt the sqquence-to-sqquenee (S2S) paradigm, which is adopted in many neural machine trans- lation models that aim to predict the output given the input sequence (Vaswani et al.) 2017). This paradigm typically minimizes the cross-entropy (CE) loss for predicted tokens: yr: (c)
En Li log Po(y: yes, x). i.e., calculating the total loss by summing the negative log probabilities of the model correctly predicting each token sequence, given all the preceding tokens.
Such CE loss refers to an aggregation of local, token-level prediction errors, serving as a baseline train an LLM-based decompiler. However, lacks syntactic and semantic awareness, including assigning equal penalties for unequal errors. For example, a misplaced semicolon, which breaks compilation, might receive a similar penalty to choosing a semantically equivalent but different variable name. Therefore, only adopting a supervised model for Structure Recovery might generate syntactically plausible code that does not compile, limiting the effectiveness of SK2 Decompile.
To further enhance Structure Recovery, after the S2S training, we perform reinforcement learning (RL) to align the outputs with compiler's preference and type constraints such that the generated IR could better represent a compilable and functionally sound program. Specifically, we design the reward made up of two components. First, for each generated IR, we provide the compiler with the header of the ground-truth IR in order to verify its compilability and grant reward only upon success, for advancing functional correctness. Additionally, we reward the accurate recovery of placeholder identifiers by computing the Jaccard similarity coefficient between the generated (Tgen)

---

Published as a conference paper at ICLR 2026
and ground-truth sets (IR)). The placeholder recovery reward encourages the model to accurately reconstruct the program s data layout. Formally:
gen
|
0.0,
if IR cannot be compiled
pplacebolder
Agen
JiR]
Istructure
1.00 + Pplaceholder:
IR can be compiled
(3)
Note that using compiler feedback as a reward is feasible and natural. One possible alternative is to build the reward based on the executing unit tests. However, creating unit tests and replicating execution environments for real-world programs often prohibitively complex and costly.
Similarly, for Identifier Naming, the CE loss undesirably penalizes cases where identifiers differ superficially but are semantically equivalent, while such differences are negligible from a human's perspective. To mitigate this, also perform RL and formulate the corresponding reward as the semantic similarity between the embedded generated code (Cgen) and the reference source code (esre), measured by the cosine similarity:
Tidentifier cos Cogen: Care) = Egen escc
(4)
||egen|] ||
By optimizing for this similarity metric, we encourage the model to generate names that are more semantically aligned with the ground truth, in contrast to the CE loss, which strictly enforces an exact lexical match.
EXPERIMENTS
Training Data. We collected our training corpus from the C programs of Exebench (Armengol- Estap's e et al. 2022) and Decompile-Bent Benchh (Tan et al., (2025b) datasets. We compiled the source files into binaries for the x86 Linux platform using GCC and Clang (Clang) 2025), applying opti- mization levels -O0 through -O3. To ensure data quality, we normalized the code by removing all comments and applying clang-format the source code, while formatting the pseudocode to adhere to the R2I standard (Eom et al. (2024). We further employed MinHash-LSH identify and remove near-duplicates (Broder 2000). Following previous reverse engincering practices (Lacomis et al.
2019 Chen et al. 2022 Xie al. 2024), we stripped all binaries and used IDA Pro (Hex-Rays, 2024 to generate pseudocode (please refer to Appendix f stripping examples). This process
yielded comprehensive dataset of approximately 5 million samples, totaling around 2B tokens of pseudocode, 1.5B tokens of IR, and 1.5B tokens of source code.
Evaluation Benchmarks and Metrics. For evaluation, we adopted set of standard benchmarks widely used in previous studies; HumanEval (Chen, 2021), ExeBench (Armengol e et al.) 2022). MBPP (Austin et al. 2021), and Github2025 Tan et al. 20256). These benchmarks were processed using the same compilation pipeline as our training data. To assess the quality of the gen- erated decompiled code, we used three primary metrics, i.e., R2/ (Eom et al. 2024), GPT-judge (Xu
et al. 2025 Liu et al., 2023), and re-execulubility rale (Armengol-Estap" e et al. [0233 Tan et al. 2024 In particular, R2I measures the relative readability of code structure. GPT-judge uses GPT- 5-mini (OpenAl 2025) to evaluate the Identifier Naming effectivvnness of the output, with for poor performance to 5 for excellent performance. For benchmarks that support execution (HumanEval and MBPP), also measure the re-executability rate (Armengol-Estap
al.) 2023 Tan et al., 2024), which checks if the decompiled code can be successfully re-compiled and passes the original test cases. For tests on stripped binaries, we restore the original function name in the generated code. Note that Exebench is excluded from the evaluation on re- re-executability rate because the stripping process disrupts its required execution environment. Detailed definitions for each metric and the prompt of GPT-judge are provided in Appendix A.2
Baselines. We compare against GPT-5-mini (OpenAl 2025), state-of-the-art commercial model, as well as two leading open-souree decompilation models LL LLM4Decompile (Tan et al. (024 and Idioms (Dramko et al. 2025). Other LLM- based decompilers, such as Nova (Jiang et al. 2025), Ref- Ref-Decomp (Feng al. 2025), and D-Lift (Zou et al. 2025), were not included in our comparison because they do not provide details about their data preprocessing approaches or do not release their models, hindering fair and reproducible evaluations.
7

---

Published as a conference paper at ICLR 2026
Configurations. Both the Structure Recovery and Identifier Naming models were initialized from the LLM4Decompile- 7B checkpoint (Tan et al.] 2024). We performed supervised fine-tuning for epoch using the LLaMA-Factoon library (Zheng et al. 2024 with batch size of 128 and learning rate of 3e - 6. For the Reinforcement Learning (RI.) phase, we leveraged the GRPO (Guo al. 2025) algorithm in the veRL. library (Sheng et al. 2024) and trained
random subset of
50,000 samples due to computational constraints. The RL reward for code compilability is verified using Psyche-C (Melo 2025) generate headers, and the reward for semantic similarity is measured using gwen-embeddding-U -.66 (Zhang et al. 2025). All experiments were conducted on clusters of NVIDIA H800-80GB GPUs. During inference, we used the vLLM (Kwon et al., (023) library for accelerated generation and employed greedy decoding to minimize randomness.
4.1
MAIN RESULTS
Table I: Re-executability results between the studied decompilers.
HumanEval
MBPP
Re-cxccutability rates
00
01
02
03
AVG
00
01
02
03
AVG
IDA
56.09
47.05
35.03
25.66
40.95
53.75
47.39
35.09
22.34
39.64
GPT-5-mini
67.07
60.78
49.63
49.56
56.75
55.70
49.33
44.13
39.74
47.23
LLM4Decompile
67.07
37.25
33.58
28.32
41.71
61.56
42.42
36.90
31.32
43.05
Idioms
70.73
25.49
12.41
10.62
29.81
54.78
21.58
11.60
8.06
24.01
Ref-Decompile
85.37
52.29
44.53
46,90
57.27
68.65
52.97
46.54
40.48
52.16
SK- Decompile
86.59
70.59
61.31
57.52
69.00
69.76
62.33
54.83
51.58
59.63
Table 2: R2I results between the studied decompilers with the compilation optimization levels O0, 03 and the averaged results on -0,0,1,2,3).
HumanFval
MBPP
ExeBench
GitHub2025
00
03
AVG
00
03
AVG
00
03
AVG
00
03
AVG
IDA
38.16
40.74
39.45
41.06
34.37
37.72
48.38
51.39
49.89
35.27
43.24
39.26
GPT-S-mini
49.97
37.03
43.49
44.05
31.15
37.60
31.69
28.46
30.08
32.93
27.13
30.03
LLM4Decumpile
73.10
72.64
72.87
66.23
72.35
69.29
60.12
57.85
58.99
44.98
53.96
49.47
Idioms
76.60
53.95
65.30
70.16
55.74
62.95
73.37
54.26
63.82
71.43
51.84
61.63
SK2 Decompile
76.62
77.72
77.17
69.62
78.02
73.82
68.75
77.24
72.99
69.78
73.45
71.62
Table 3: GPT-judge results between the studied decompilers.
HvmanEval
MBPP
ExeBench
GitHub2025
GPT-judge
00
AVG
03
AVG
03
AVG
IDA
3.08
2.67
2.88
3.05
2.57
2.81
2.20
1.91
2.05
2.37
2.19
2.28
GPT-5-mini
4.49
4.07
4.23
4.35
3.88
4.08
2.53
2.33
2.37
3.04
2.86
2.87
LLM-Decompile
3.88
3.29
3.81
3.22
2.47
2.12
2.22
2.52
2.56
2.62
Idioms
4.30
2.70
3.22
4.07
2.61
3.13
2.46
1.71
2.01
2.51
2.10
2.18
Decompile
4.51
4.05
4.24
4.31
3.95
4.12
2.48
2.47
2.42
3.05
3.02
3.06
compares the re-executability rates of the studied decompilers on the HumanEval and MBPP datasets across different optimization levels (00-03). Notably, SK2 Decompile achieves the highest performance, surpassing the best-performing baseline GPT-5-mini by 21.6% and 26.3% averagely each dataset. Specifically, to the best of our knowledge. this is the first model that preserves the functionality of binaries and reaches an average re-exccutability of 700% and ~60% of HumanEval and MBPP cases, underscoring the advantage of decomposing decompilation into two sub-tasks.
Table presents the R2I results the studied decompilers. SK2 Decompile consistently outperforms all the baselines. The improvements particularly significant in the recovery of program structures from real-world binaries. Specifically, on the ExeBench and GitHub2025 datasets, SK3 Decompile achieves performance gains of 18.4 8.4% and 29.4% over the best-performing baseline Idioms.
8

---

Published as a conference paper at ICLR 2026
The effectiveness of Identifier Naming, evaluated by GPT-judge. is presented in Table where SK Decompile produces high-quality names on both the HumanEval and MBPP datasets, achieving scores of 4.24 and 4.12 12 out of 5, respectively. Furthermore, when applied to the real-world datasets, SK- Decompile demonstrates an advantage over the existing techniques, outperforming GPT-5-mini by 2.1 % and 6.7%.
4.2 ABLATIONS
Table 4: Re-executability results between the Decompile variants.
HumanEval
MBPP
Re-executability rates
00
01
02
03
AVG
00
01
02
03
AVG
pseudo-sre
73.78
54.25
48.91
42.48
54.86
58.37
48.97
42.77
39.93
47.51
pseudo-ir
78.66
65.35
54.01
52.21
62.56
55.29
49.33
43.22
41.02
47.25
pscudo-ir-rl
87.80
69.28
59.85
58.41
68.84
68.35
59.88
52.25
47.62
57.06
pseudo-ir-sro
78.66
66.01
55.47
54.86
63.75
60.95
55.03
48.34
46.89
52.83
pscudo-ir-sre-rl 86.59
70.59
61.31
57.52
69.00
69.76
62.45
54.83
51.58
59.63
In the ablation study, designed series SK3 Decompile variants to indicate the individual effects of its major components, including the task decomposition and the crafted reward (RL) as follows.
pseudo-sre: This model represents a direct, end-to-end approach to decompile from pscudo to source code. It is trained using SFT with the training data used in SK2 Decompile.
pscudo-ir: This model is trained with SFT to convert pseudocode to IR for the evaluation the effectiveness of Structure Recovery.
pseudo-ir-sre: This model is trained with SFT to convert to source code. The output from the Structure Recovery phase serves as its input for evaluating the effectiveness of Identifier Nam- ing. Note that the training cost of a direct approach, pseudo- sre and decomposed approach, pseudo- ir with pseudo -ir-irr-- -ir-ii-ssee src, are similar ensure fair comparison.
pseudo-ir-rl: Based on pseudo-is r, the model is further tuned with RL on compiler feedback.
pseudo-ir-stc-rl: This model is the complete version of SK2 Decompile which integrates the de- composed, two-phase framework enhanced with the RL for both phases.
Table 4 presents ablation study results in terms of the re-executability rates. Noticing that pseudo-src TC establishes a baseline performance with re-executability rates of 54.86% and 47.51 % on HumanEval and MBPP dataset, splitting the decompiliation process into Structure Recovery and Identifier Naming (pseudo-1) iir-irrrrr could increase corresponding scores to 63.75% and 52.83% respectively. This validates that tackling decompilation as two simpler sub-tasks is indeed a more effective strategy. Notably, even the Structure Recovery model alone (pseudo-iz) surpasses the pseudo-src, baseline on HumanEval, highlighting that an independent phase on program struc- ture recovery is a critical factor. Moreover, seeudoiir-rr achieves dramatic performance gains of 10.0% and 20.8% over the supervised-only model pseudo-in r, indicating the benefit crafted rewards. At last, pseudo-ir-src-rl achieves the best performance, demonstrating that each com- ponent of SK2 Decompile is critical and combining them together essential for optimizing the performance. We observe similar trends for the R2I and GPT-judge results and present them in Appendix A.3 due to the page limit.
4.3
CASE STUDY
Figure presents case study on memory allocation function. direct decompilation in Figure c produces non-intuitive code that relies on an explicit type cast from generic void opaque. also incorrectly identifies the free field as ptr. GPT-5-mini in Figure 3 fails to reconstruct the data structure, and represents data access with low-level pointer offset (char x) arena
instead. contrast, the Structure Recovery phase of SK2 Decompile in Figure d) successfully recovers the essential control flow, conditions, and data structures. Building on the clean recovered structure from Figure d)) the Identifier Naming phase in Figure B(c) further enhances readability by assigning meaningful names identifiers, such inferring ava! lable

---

Published as a conference paper at ICLR 2026
(a) Paeudocode
(b) Source code
(c) preudo-sre
long long sub 149589 int at, long a char wdtoa, int Stack_allor +alloc)
vo id valloc ignedt int s size,vald vapaque)
signed int vas long long ué;
char erv; int alggedd size a ALteNi,, stzzor clweP)
struct nalloc preque agpaque_
4284967288;
(strust malloc_opaque slopsque;
Hunsigred, long Long) xfuintBALt
(all roc-ofreeeealign sizecral sizestalloc-oent loc-oend)
size (size 7)
(opaque return salloc(size);
opoque_-oend)
mallocta));
alloc-ofree aligned_sizes
*fuintea +16a2 81:
else
void eptr opaque opaque_-pprre
vcuinre4 +1aa 8.81
rolloci)); return rvi)
opacue_ -optr +* size)
return v45)
return ptrs)
(d) Structure Recovery (pscude-ir)
(c) Mdenifier Naming (pscudo-ir-sre)
(D GPT-S-mini
void afunctlint
evar21
a_allociint
ralloc_state estate)
void +arena aatciint size, void warenalf
vois evera;
void aret)
long aligned slangiisiae + 7) -TULL; long cur tong char wlarena B1; long [aliggeed pallactsizel;
vari (varl + 71 -7)
size Isize -7;
if (arrz-ofaetdaaarrserr22--- vara varl=sfieldi;
if Istate-oevall size ez state--lintt)
tona + wlarena 18);
state->avatl;
var2.sfieldi vari;
state-novall $120;
reture var3:) ratloclvar11s)
reti)
<Cong +I[[char +larena 8) curratigred; return 1vold +]curs?
ratoocssiee))>
Figure 3: A case study on a memory allocation function with (a) pseudocode, (b) source code, (c) de- compilation result from pseudo-sre in Table (d) Structure Recovery result from pseudo-iz in Table 4 (e) Identifier Naming result from pseudo- ir-sre from GPT-5-mini.
Table and (f) decompilation
and state semantically appropriate names for the original free and a alloc, leading to struc- turally accurate and semantically rich result.
CONCLUSION
In this work, propose SK2 Decompile which decomposes the binary decompilation task into two phases. First, it recovers the program's "skeleton" i.e., its functional structure, using an Intermediate Representation and compiler-guided Reinforcement Learning. Second, it recovers the program's "skin", i.e., naming identifiers, with a separate reward on semantic similarity to improve readability. Experimental results show that SK2 Decompile the first to achieve the average re-executability rate of approximately 70% on HumanEval and 60% on MBPP datasets. It also achieves a 21. 1.6% average re-executability rate gain over GPT-5-mini on HumanEval and 29.4% average R2I improvement over Idioms on the GitHub2025 benchmark. In conclusion, SK2 SK=Decompile significantly outperforms the existing techniques in producing functionally correct and duman-readale decompilation code.
ACKNOWLEDGMENTS
This work is partially supported by the National Natural Science Foundation of China (No. 62372220), the Research Grants Council of the Hong Kong Special Administrative Region, China (Project No. PolyU/25200821), the Innovation and Technology Fund (Project No. PRP/047/22FX), and PolyU Internal Fund from RC-DSAI (Project No. 1-CEIE). This work is also partially supported by CCFF-Kuishou Large Model Explorer Fund (No. CCF- KuF-hhaishou 2024013).
REPRODUCIBILITY STATEMENT
To ensure full reproducibility of our results, we have made all associated artifacts publicly available in anonymous GitHub repository. This repository contains the complete source code for our model implementation, training scripts, and evaluation protocols. We also provide the processed testing data, along with scripts for data preparation. For case of use, pre-trained model weights are also released. The README.md file in the repository offers a step-by-step guide to set up the environment, and replicate the key results presented in this paper.
ETHICS
SK Decompile was developed under strict ethical guidelines. It is intended for use in legitimate scenarios, such as academic research, debugging, and recovering company' own lost source code, where permission is granted or copyright does not apply. To support this, the model was trained exclusively open-source code from public benchmarks and permissively licensed repositories,
10

---

Published as a conference paper at ICLR 2026
e.g,, MIT, MIT, BSD, and Apache 2.0 (Lozhkov et 2024). Notably, commercial software remains well- protected by obfuscation methods that make effective decompilation infcasible (Tan et al. 2024). thus limiting the potential for misuse.
REFERENCES
Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, lige Akkaya, Florencia Leoni Ale- man, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, al. Gpt-4 technical report. arXiv preprint arXiv:2303. 2023.
Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffiey D. Ullman. Control flow. In Compilers: Principles, Techniques, and Tools, chapter 6, pp. 399-408. Aidison-Wesleyy 2 edition, 2007.
Jordi Armengol- -ettolp---pp'' c. Jackson Woodruff, Alexander Brauckmann, José Wesley de S. Magalhaes, and Michael F. P. Boyle. Exebench: an ml-scale dataset of executable functions. Proceed- ings of the 6th ACM SIGPLAN International Symposium Machine Programming, 2022. URL https: //ppi semant www.seaaatnniicaaccooeeeoe iescholar....ccc
2495536000
Jordi Armengol-Estap'e, e, Jackson Woodruff, Chris Cummins, and Michael F. P. O'Boyle. Slade: A portable small language model decompiler for optimized assembly. 2024 IEEE/ACM In- lernational Symposium Code Generation and Optimizationn (CGO), pp. 67-80, 2023. URL
http:/ppp..seeaattccccc.ccccccea ar. wtwp/oorgs/ooooooooooo 258832337
Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. Program synthesis with large language models. arXiv preprini arXiv:2 108.00728.777 2021.
Andrei Z. Broder. Identifying and filtering near-duplicate documents. In Annual symposium on combinatorial paltern matching, pp. 1-10. Springer, 2000.
David Brumley, JongHyup Lee, Edward J. Schwartz, and Maverick Woo. Native x86 de- compilation using semantics-peeserving structural analysis and iterative control-flow struc- turing. In Samuel T. King (ed.), Proceedings of the 22th USENIX Security Sym- posium, Washington, DC, USA, August 14-16, 2013, pp. 358-368. USENIX Associa- tion, 2013. URL https: /www. usenix wwtp://wwwwoooooooooooo/oooo wtt.e/eeeneeeeeeeeeecrrrrrroeeee xsecurity13) technical sess
sess i ons wtt.oo/seeeeeeeeeeeeeeeeeeeeeeee
Ying Cao, Ruigang Liang, Kai Chen, and Peiwei Hu. Boosting neural networks to decompile op- timized binaries. In Proceedings of the 38th Annual Computer Security Applications Confer- ence, ACSAC '22, pp. 508-518, New York, NY, USA, 2022. Association for Computing Machin- ery. ISBN 9781459397599,
doi: 10.1145/3564625.55779999 URL httpttt:///o...ooo http///ii.rgg/...o/
1145/3564622 3567999
Ying Cao, Runze Zhang, Ruigang Liang, and Kai Chen. Evaluating the effectiveness of decompilers. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2024, pp. 491-502, New York. NY, USA, 2024. Association for Computing Machinery. ISBN 9798400706127.
doi: 10. 10.1145/3600112.355114, URL httpss://do.
org/10 11 45 00011115335550 0114445355222..35555
Guoqiang Chen, Huiqi Sun. Daguang Liu, Zhiqi Wang. Qiang Wang, Bin Yin, Lu Liu, and Lingyun Ying. Recopilot: Reverse engineering copilot in binary analysis, 2025. URL /ttthtttt:///xxi.
org/abs/ 2505. 16366
Mark Chen. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374, 2021.
Qibin Chen, Jeremy Lacomis, Edward J Schwartz, Claire Le Goues, Graham Neubig, and Bogdan Vasileseu. Augmenting decompiler output with learned variable names and types. In 3 USENIX Security Symposium (USENIX Security 22), pp. 4327-4343, 2022.
Clang. Clang, 2025. URL https://clamg 11vm. llv.orr//
Accessed: 2025-09-10.

---

Published as a conference paper at ICLR 2026
Francesca Console, Giuseppe D' D'Aquanno, Giuseppe Antonio Di Luna, and Leonardo Querzoni. Binbench: a benchmark for x64 portable operating system interface binary function representa- tions. PeerJ Computer Science, 9, 2023. httLhttps//// /app//appipp www.nticcscoolarr......o....aaa. ottttttssssppppp.eeeaaaattttattt org/
(TrpuuTDD229029800
Chris Cummins, Volker Seeker, Dejan Grubisic, Baptiste Roziere, Jonas Gehring, Gabriel Synnaeve, and Hugh Leather. Meta large language model compiler: Foundation models compiler opti- mization. arXiv preprint 1rXii:2407.025244 2024.
Yaniv David, Uri Alon, and Eran Yahav. Neural reverse engineering of stripped binaries using augmented control flow graphs. Proc. ACM Program. Lung, 4(OOPSLA), November 2020. doi: 10.1145/3428293, URL https: /dof. .acoooorgee 11..0..1455/00 114///1..11/333222233
Luke Dramko, Claire Le Goues, and Edward J Schwartz. Idioms: Neural decompilation with joint code and type prediction. arXiv e-prints, pp. arXiv-2502, 2025.
Haeun Eom, Dohee Kim, Sori Lim, Hyungjoon Koo, and Sungjae Hwang. R2i: A relative readability metric for decompiled code. Proc. ACM Softw: Eng., 1(FSE). July 2024. doi: 10.1145/3643744.
URL htt.hhttss///ee //w.i org. 2145/3643744
Michael J Evans and Jeffrey S Rosenthal. Probability and statistics: The science of uncertainty. Macmillan, 2004.
Yunlong Feng, Bohan Li, Xiaoming Shi, Qingfu Zhu, and Wanxiang Che. Ref decompile: Relabel- ing and function call enhanced decompile. arXiv preprint arXiv:2502. 122211, 2025.
Cheng Fu, Huili Chen, Haolan Liu, Xinyun Chen, Yuandong Tian, Farinaz Koushanfar, and Jishen Zhao. Coda: An end-to-end neural program decompiler. In H. Wal- lach, H. Larochelle, A. Beygelzimer, F. AAlché-Buc, E. Fox, and R. Gareet (eds.), Ad- vances Neural Information Processing Systems, volume 32. Curran Associates, Inc., 2019. URL. http:////prooeeeem......rrrirrre cctppppppp.pppppppppppppppp www.fieeppppeeee /20ppr/2219/ /ttp:///.0000000000000001111111.
Zeyu Gao, Yuxin Cui, Hao Wang, Siliang Qin, Yuanda Wang, Zhang Bolun, and Chao Zhang. DecompileBench: A comprehensive benchmark for evaluating decompilers in real-world sce- narios. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (eds.), Findings of the Association for Computational Linguistics: ACL 2025, pp. 23250-23267, Vienna, Austria, July 2025a. Association for Computational Linguistics. ISBN 979-8-99176-256- org/2025.
5. doi: 10.18653/v 1/2025. http://...2.2.0---ee.... 1194. URL https: http///aaaattttttteceecc Findings-acl 1194/
Zuchen Gao, Zizheng Zhan, Xianming Li, Erxin Yu, Haotian Zhang, Bin Chen, Yuqun Zhang, and Jing Li. OASIS: Order-augmented strategy for improved code search. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Pupers), pp. 18451-188 18467, Vienna, Austria. July 2025b, Association for Computational Linguistics. ISBN doi: 10.18653/v 10.18633/112002..ad-llooog awt.::25.clllon..00.. URL
904/
Ghidra. Ghidra software reverse engiineeringnngn framework, 2024. URL hwt.:httt///tthhhte com/ NatrioaaSeecuzityygennn///cii
Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma. Peiyi Wang, Xiao Bi, et al. Deepseek-rl: Incentivizing reasoning capability in llms 0at:::551.1244.. 2025.
via reinforcement learning. arXiv preprint
Parisa Hamedi, Hamed Jelodar, Samita Bai, Mohammad Meymani, Roozbeh Razavi-Far, and Ali A.
Ghorbani. Asm2srceval: Evaluating large language models for assembly-to-soute code transla- tion, 2025. URL httpt:ttt/taiiiiiiei www.a/iwwww.....//aaaaaaaaa
20134
Rays. Ida pro: a cross procespr disassembler and debugger, 2024. URL https: hoos://hes htte://exxxee rays www.ss.cc...daapppppa
12

---

Published as a conference paper at ICLR 2026
Iman Hosseini and Brendan Dolan-Gavit, Beyond the Retargetable decompilation using neural machine translation. arXiv preprint arXiv:2212.088 08950, 2022.
Peiwei Hu, Ruigang Liang, and Kai Chen. Degpt: Optimizing decompiler output with 11m. In Proceedings 2024 Network and Distributed System Security Symposium (2024). https://api. se- manticscholar. org/CorpusID, volume 267622140, 40, 2024.
Haohui Huang, Yue Liu, Yuxi Cheng, Haiyang Wei, Jiamu Liu, Yu Wang, and Linzhang Wang. Recover function signature from combined constraints. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communicationn Security, CCS '25, pp. 3386-3400, New York, NY, USA, 2025. Association for Computing Machinery. ISBN 9798400715259. doi: 10.
3719027.3765083 Utt.ttts:://// ctop/iorrr/10/ 10. 1145/ 3765028
Ling Jiang, Junwen An, Huihui Huang, Qiyi Tang, Sen Nie, Shi Wu, and Yuqun Zhang. Binaryai: Binary software composition analysis via intelligent binary source code matching. In Proceedings of the IEEF/ACM 46th International Conference Software Engineering, ICSE '24, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400702174, doi: 10.1145/ 10. 1wt...1111//11.111.. 3633100
3597503.3639100 URL
Nan Jiang, Chengxiao Wang, Kevin Liu, Xiangzhe Xu, Lin Tan, Xiangyu Zhang, and Petr Babkin. Nova: Generative language models for assembly code with hierarchical attention and contrastive learning. In The Thirteenth International Conference on Learning Representations, 2025. URL
https: bttps::/epenzze http:////ppeeeeeeeeeee net. 2eee://ooommmd-yyLL3...5
Pascal Junod, Julien Rinaldini, Johan Wehrli, and Julie Michielin. Obfuscator-LLVM software protection for the masses, In Brecht Wyseur (ed.), Proceedings of the IEEE/ACM 1st International Workshop on Software Protection, SPRO' 1,, Firenze, Italy, May 19th, 2015, pp. 3-9, IEEE, 2015. doi: 10.1 109/SPRO.2015.11
Deborah S. Katz, Jason Ruchti, and Eric M. Schulte. Using recurrent neural networks for decom- pilation. In Rocco Oliveto, Massimiliano Di Penta, and David C. Shepherd (eds.), 25th Inter- national Conference on Software Analysis, Evolution and Reengineering, SANER 2018, Cam- pobasso. Italy, March 20-23, 2018, pp. 346-356. IEEE Computer Society, 2018 doi: 10.1 201ER.2018.8333 8330022. URL https: //doi. wwt. 1109/
1tt.://...o.....11////////...... SANER. 2018 8330222
Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng. Lianmin Zheng. Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and lon Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023.
Marie-Anne Lachaux, Baptiste Roziere, Mare Szafraniec, and Guillaume Lample. Dobf: A de- obfuscation pre-training objective for programming languages. Advances in Neural Information Processing Systems, 34:14967-14979, 2021.
Jeremy Lacomis, Pengcheng Yin, Edward J. Schwartz, Miltiadis Allamanis, Claire Le Goues, Graham Neubig, and Bogdan Vasilescu. Dire: A neural approach to decompiled identifier naming. 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 628-639, 2019. URL https:://pp: www.nt 202676778
Orrg/CorpusID
Gangyang Li, Xiuwei Shang, Shaoyin Cheng, Junqi Zhang, Li Hu, Xu Zhu, Weiming Zhang, and Nenghai Yu. Beyond the edge of function: Unraveling the patterns of type recovery in binary code. arXiv preprint arXiv:2503.07244 2025.
Zehan Li, Xin Zhang, Yanzhao Zhang, Dingkun Long, Pengjun Xie, and Meishan Zhang. Towards general text embeddings with multi-stage contrastive learning. arXiv preprinl 2308.2230. 2023.
Yang Liu, Dan Iter, Yichong Xu, Shuohang Wang, Ruochen Xu, and Chenguang Zhu. G-eval: NLG evaluation using gpt-4 with better human alignment. In Houda Bouamor, Juan Pino, and Ka- lika Bali (eds.), Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pp. 251 2522.. Singapore, December 2023. Association for Computational Linguis- tics. doi: 10. 10.18653/v 1/2033//1//22.oo/// http:02..mmmmmmmn....mm URL ht https:: http:///aaaaaataaaacae wrgpolooooor//222...3 lemn p0 ma i 1537
13

---

Published as a conference paper at ICLR 2026
Zhibo Liu and Shuai Wang. How far we have come: testing decompilation correctness of
decompilers. In Proceedings of the 29th ACM SIGSOFT International Symposium on Soft-
ware Testing and Analysis, ISSTA 2020, pp. 475-487, New York, NY, USA, 2020. Associa- tion for Computing Machinery. ISBN 9781450380089. htttps://do..orge wtt.://///1...11/..... 11tp///1111111133333333 3397373
doi: 10.1145/3395363
URL.
Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy-Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, et al. Starcoder 2 and the stack v2: The next generation. arXiv preprint arXiv:2402. 19173,, 2024.
Zexin Lu, Keyang Ding, Yuji Zhang, Jing Li, Baolin Peng, and Lemao Liu. Engage the public: Poll question generation for social media posts. In Chengqing Zong, Fei Xia, Wenjie Li, and Roberto Navigli (eds.), Proceedings of the 59th Annual Meeting of the Association for Compula- tional Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers), pp. 29-40, Online, August 2021. Association for Computational Lin- guisties. doi: 10. 10.18853/11/202 2atp://1111221..1oooooo.....3 URL https: ttttps://aclatthol.ee org/2021.
acl-longy
Leandro T. C. Melo. A compiler frontend for the с programming language, 2025. URL https: Accessed: 2025-09-10.
//github. www./////wm/e///////oooeooooceee
OpenAl. Gpt-5. Large language model (multimodal) available via OpenAl API, 2025. URL https://openaat com Accessed: 2025-09-25.
James Patrick-Evans Lorenzo Cavallaro, and Johannes Kinder. Probabilistic naming of func- tions in stripped binaries. In Proceedings of the 36th Annual Computer Security Applications Conference, ACSAC '20, pp. 373-385, New York, NY. USA, 2020. Association for Com- puting Machinery. ISBN 4701450388580. doi: 10.1145/347722883477766 URL https:
//dbi.org/10.1111 1145 222
pycparser. Complete c99 parser in pure python, 2025. URL BRLLhttps///gtthub.com///. pycparser Accessed: 2025-09-10.
Shac Ron, Todd Austin, and Tayfun Kayhan. Bringup-bench. https://github. com/
ttoddinuuttin/bringgu bench, 2025, Accessed: 2025-11-22.
Xiuwei Shang, Guoqiang Chen, Shaoyin Cheng, Benlong Wu, Li Hu, Gangyang Li, Weiming Zhang, and Nenghai Yu. Binmetric: A comprehensive binary analysis benchmark for large lan- guage models, 2025. URL httpttts///.xii..rrrrrrr http:////aaxxx...o///////5055 07360
Guangming Sheng, Chi Zhang, Zilingfeng Ye, Xibin Wu, Wang Zhang, Ru Zhang, Yanghua Peng, Haibin Lin, and Chuan Wu. Hybridflow: A flexible and efficient rihf framework. arXiv preprint arXiv: 2409. 19256, 2024.
Zian Su, Xiangzhe Xu, Ziyang Huang, Kaiyuan Zhang, and Xiangyu Zhang. Source code foun- dation models are transferable binary analysis knowledge bases. In A. Globerson, L. Mackey, D. Belgrave, A. Fan, U. Paquet, J. Tomczak. and C. Zhang (eds.), Advances in Neural Information Processing Systems, volume 37, pp. 112624 1894--12655 12655. Curran Associates, Inc.,
2024. URL httpp::/ppocceedd.nstt neur cw/paper http:/papr_ffeeeee /ttpp//ececcpppeeea/////e///e//e httper/ffeeee/pp//2//223/ /tle://c838773300000220033333333 Paper Conference Paw.e--areeee---eceeee.e.m pddf
Mare Szafraniec, Baptiste Roziere, Hugh Leather, Francois Charton, Patrick Labatut, and Gabriel Synnaeve. Code translation with compiler representations. arXiv preprint vrXiv:2207.03574 2022.
Hanzhuo Tan, Qi Luo, Jing Li, and Yuqun Zhang. LimAdecompile: Decompiling binary code with large language models. In Conference Empirical Methods in Natural Language Processing, 2024. URL https::/ //api. weeeetiiscoooleee....... Crt////opoooss11::2333777777
Hanzhuo Tan, Qi Luo, Ling Jiang, Zizheng Zhan, Jing Li, Haotian Zhang, and Yuqun Zhang. brsmdt-based code completion via multi-retrieval augmented generation. ACM Trans. Softw. Eng. Methodol, 35(1), December 2025a. ISSN 1049-331X. doi: 10.1145/3725812. URL
https://doi 00t////../00.11/35551...1
14

---

Published as a conference paper at ICLR 2026
Hanzhuo Tan, Xiaolong Tian, Hanrui Qi. Jiaming Liu, Zuchen Gao, Siyi Wang, Qi Luo, Jing Li, and Yuqun Zhang. eecompile-benchi Million-scale bimary-source function pairs for real-world binary decompilation. arXiv preprint 1adi::2505.126666 2025b.
Naftali Tishby and Noga Zaslavsky. Deep learning and the information bottleneck principle. In 2015 ieee information theory workshop (itw), pp. 1-5. leee, 2015.
Naftali Tishby, Fernando C Pereira, and William Bialek. The information bottleneck method. arXiv preprint physics/00004057,200 2000.
Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. Attention is all you need. In Isabelle Guyon, Ulrike von Luxburg, Samy Bengio, Hanna M. Wallach, Rob Fergus, S. V. N. Vishwanathan, and Roman Garnett (eds.), Advances in Neural Information Processing Systems 30: Annual Conference on Neural Information Processing Systems 2017, December 4-9, 2017, Long Beach, CA, USA, pp. 5998 6008, 2017. URL BRLL/httss//pprccednng..ccm htw.:pproooedddn......e......p.
html
Hao Wang. Zeyu Gao, Chao Zhang, Zihan Sha, Mingyang Sun, Yuchen Zhou, Wenyu Zhu, Wenju Sun, Han Qiu, and Xi Xiao. Clap: Learning transferable binary code representations with natural language supervision. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2024, pp. 503-515, New York, NY. USA. 2024, Associ- ation for Computing Machinery. ISBN 9798400706127. doi: 10.1145/366021223555555 URL 1145 0tt..111///555222555555
btttps://dii.orge
Xiaohan Wang, Yuxin Hu, and Kevin Leach. Context-guided decompilation: A step towards re- executability, 2025a. Utttss/ts: http://axxvvv...//a.o/// wwtp://///////////////// 221l///s//1111111 01763
Yongpan Wang, Xin Xu, Xiaojie Zhu, Xiaodong Gu. and Beijun Shen. Salt4decompile: In- ferring source-level abstract logic tree for Ilm-based binary decompilation. arXiv preprint arXiv:2509. 14646, 2025b.
Wai Kin Wong, Huaijin Wang, Zongjie Li, Zhibo Liu, Shuai Wang. Qiyi Tang, Sen Nie, and Shi Wu. Refining decompiled code with large language models, arXiv preprint arXiv:2310.06530, 2023.
Ruoyu Wu, Taegyu Kim, Dave (Jing) Tian, Antonio Bianchi, and Dongyan Xu. DnD: A Cross- Architecture deep neural network decompiler. In 31st USENIX Security Symposiun (USENIX Security 22), pp. 2135 2152-2152, Boston, MA, August 2022. USENIX Association. ISBN 978-1- 939133-31-1. URL https::///// /www uswnixxei........ x htwp://www.....e.eeeeeeee/eeeeee
presentation/ wu ruoyu
Jiahong Xiang, Xiaoyang Xu, Fanchu Kong, Mingyuan Wu, Zizheng Zhang, Haotian Zhang, and Yuqun Zhang. How far can we go with practical function-level program repair? arXiv preprint arXiv:2404.1 12833, 2024.
Jiahong Xiang, Wenxiao He, Xihua Wang, Hongliang Tian, and Yuqun Zhang. Evaluating and improving automated repository-level rust issue resolution with lim-based agents. In 2026 JEEE/ACM 48th International Conference on Software Engineering (ICSE '26), ICSE '26, 2026.
ISBN 1799-8-4007-2025-3222222
doi: 10.1145/3749916.377111
Danning Xie, Zhuo Zhang, Nan Jiang, Xiangzhe Xu, Lin Tan, and Xiangyu Zhang. Resym: Harness- ing Ilms to recover variable and data structure symbols from stripped binaries. In Conference on Computer and Communications Security, 2024. URL https: api semanticscholar. oxre/Corpus1D:22155011
Jiaqi Xiong, Guoqiang Chen, Kejiang Chen, Han Gao, Shaoyin Cheng, and Weiming Zhang. Hext5: Unified pre-training for stripped binary code information inference. In Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering, ASE 23, pp. 774-786. IEEE Press, 2024. ISBN 9798350329964.. doi: 10.1 1009/AAEE5622..222..oomm https:
URL
//do: www./og..... 09 220.229.2022..0
15

---

Published as a conference paper at ICLR 2026
Xiangzhe Xu, Zhuo Zhang, Zian Su, Ziyang Huang, Shiwei Feng, Yapeng Ye, Nan Jiang, Danning Xie, Siyuan Cheng, Lin Tan, et al. Unleashing the power of generative model in recovering variable names from stripped binary. In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2025.
S. Bharadwaj Yadavalli and Aaron Smith. Raising binaries to Ilmm ir with metoll (wip paper). In Proceedings of the 20th ACM SIGPLAN/IGBED International Conference on Languages, Compilers, and Tools for Embedded Systems, LCTES 2019, Pp. 213-218, New York, NY, USA, 2019. Association for Computing Machinery. ISBN 9781450367240, doi: 10.1145/3316482. 3326354. URL http:::ttt...ooooooooooo htgp://ooo.org///// 10.
3326354
ylfeng, Yang Xu, Dechuan Teng, Honglin Mu, Xiao Xu, Libo Qin, Wanxiang Che, and Qingfu Zhu. Self-constructed context decompilation with fined-grained alignment enhancement. In Conference Empirical Methods in Natural Language Processing, 2024. URI https:
Zhengran Zeng, Hanzhuo Tan, Haotian Zhang, Jing Li, Yuqun Zhang, and Lingming Zhang. An extensive study pre-trained models for program understanding and generation. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2022, pp. 39-51, New York, NY, USA, 2022. Association for Computing Machinery. ISBN 9781450393799. doi: 10.1145/3333777.35543000
URL https://dci..on org/10...00.. 114/
B533767. 3534390
Yanzhao Zhang, Mingxin Li, Dingkun Long, Xin Zhang, Huan Lin, Baosong Yang, Pengjun Xie, An Yang, Dayiheng Liu, Junyang Lin, Fei Huang, and Jingren Zhou. Qwen3 embedding: Advanc- ing text embedding and reranking through foundation models. arXiv preprint arXiv:2506.05176 2025.
Yaowei Zheng, Richong Zhang, Junhao Zhang, Yanhan Ye. Zheyan Luo, Zhangchi Feng, and Yongqiang Ma. Ilamafactory: Unified efficient fine-tuning of 100+ language models. arXiv preprint arXiv:2403. 2333:2203.13372,, 2024.
Muqi Zou, Hongyu Cai. Hongwei Wu, Zion Leonahenahe Basque, Arslan Khan, Berkay Celik, Antonio Bianchi, Dongyan Xu, et al. D-lift: Improving Ilm-based decompiler backend via code duiveny-driven fine-tuning, arXiv preprint arXiv:2506. 10125, 2025.
A APPENDIX
A.1
STRIP
(t) Non-stripped Pseuducode
Stripped Pseuducode
lasg Lorg Besctorl (aaee lorg lang long s2, sradgeed det a2, set all L. toaril
Long Long RULTTrIR lang lasp at, lorg lorg ad, ursigned tet at, Axt wi) (-
if jun_100200
Tvs -2
start S2LL, VIE estaints4 wellvas sells
+eluints4_ enlivs3 2811s
las m 46 vt3) Burge STLLE 1azz, 6x61:
if 56 4311 ROURERSI (v22, 6rb11 (101
If Civis 66 1n5 46 1etuints2_t 41G5 25213
livs1 45 ts reluintz2 al6ve 2301 -3) 45112
(1933)
v1s)
Aldeena e allod eo; t.
tutnts oll + 001 = 15
27408 stutstlL x1 40122
ratarn 47)
retura
v553
v523
Figure An example with its (a) not striped pseudocode, (b) striped pseudocode
Stripping is the process of removing non-essential information from binary executable files and object files (Patrick-Evans et al.; 2020; David et al., 2020), Xiong et al. 2024, Cao et al., 2022). This information, primarily intended for debugging and analysis, is not required for the program's s actual execution. The data typically removed includes Symbol Tables and Debugging Information. Specifically, symbol tables contain the names and addresses of functions, global variables, and other objects within the program. Debugging information refers to the extra data generated by the compiler (e.g.. with the -g flag in GCC) that maps the compiled machine code back to the original source code lines, variable names, and data structures.
16

---

Published as a conference paper at ICLR 2026
Stripping binaries is common and standard practice Lacomis al. (2019; Chen et al. (022))
Xie et al. (024);; Xu et al. (202), particularly for software deployed to production environments, as it ensures size reduction and enhances security. The removal of symbols and debugging infor- mation can significantly decrease the size of an executable file. A stripped binary is considerably more difficult for reverse engineers. Without meaningful function and variable names, attacker or competitor must invest significantly more time and effort to understand the program's 's internal workings, business logic, or potential vulnerabilities.
The pseudocode snippets in Figure + offer an illustration of stripping on a program. In par- ticular, the non-stripped pseudocode in Figure Fa) is significantly more readable to human analyst. It features descriptive function names such as deadlock, deadlock deadlock_seazch, search, caamment__ylle_sstet_
change_vi itim, m, and re_unlock. These names provide im- mediate insight into the potential purpose of the code, suggesting it is part of a system designed to detect and handle deadlocks database context, possibly related to MySQL. as indicated by inn mhlin__me miiiennnsssll_ cond woond_boadccssee
On the other hand, the stripped pseudocode in Fig- ure bb) is obfuscated. The meaningful function names have been replaced with generic, tool- generated placeholders like sub FFB80, sub 100390,00000 sub_ mttb__00630 and sub_ FFADO. These names are derived from the memory addresses of the functions and offer no clues about their func- tionality. An analyst examining this code would face much steeper challenge in deciphering the program's 's logic and intent.
A.2 METRICS
The Relative Readability Index (R21) (Fom et al. 2024) is a quantitative metric for evaluating and comparing the readability of decompiled C code, producing a normalized score between and 1. It functions by constructing an Abstract Syntax Tree (AST) for each output, extracting predefined features, and calculating a weighted sowve.However, the original R21 implementation introduces a significant bias. It discards an entire data sample if any single decompiler's s output fails to be parsed by the pycparser (pycparser, 2025) library. This is problematic because pycparser often fails code containing user-defined types and functions, skewing the evaluation towards simpler programs. To create a more robust and unbiased metric, we modified the process. First, we use pschec (Melo 2025) generate headers, improving the likelihood of successful parsing. More importantly if a specific output still fails to parse, we assign it a score of 0 instead of discarding the entire sample. This allows us to evaluate the other parsable outputs for that program, ensuring a more comprehensive and fair assessment.
Re-executability widely adopted metric in decompilation that evaluates the functional equiva- lence between an original source function and its decompiled output (Tan et al. 2024 Armengol- Estap'e e et al. 2023 ylfeng et al. 2024 Jiang et al., 2025 Feng et al., 2025). Ideally, this means the decompiled function should produce the same output as the original function for every conceivable input. However, since testing every input is impossible, we use practical approach. We run a set of predefined unit tests both the original code and the decompiled code. If the outputs match for every single test case, we consider the decompilation successful and "re-executable", This same concept is often called I/O accuracy or pass rate (Armengol- e et al. 2023 Diang al. 2025)
We leverage GPT-judge to assess the Identifier Naming effectiveness for the decompilers. GPT- judge has become increasingly adopted for evaluating LLM-based decompilers (Tan et al. 2024 2025b Gao et al.) 2025a). In particular, we use GPT--5-mni (OpenAl) 2025) as an automated evalu- ator, which is prompted to perform comparative analysis of the decompiled output and the original source code, specifically focusing on the quality of the recovered identifiers. It provides a rating on 5-point scale, with I for poor performance for excellent performance. The exact prompt used in our evaluation is detailed in Figure 5
A.3 ADDTIONAL RESULTS
We present ablation results for structural readability (R21) and identifier quality (GPT-judge) in Table 5) and Table 6 respectively. The R2I scores in Table 5 exhibit a consistent trend with our re-executability findings (Table 4). further indicating that both task decomposition and specialized rewards improve structural recovery. Table 6 presents a similar trend for Identifier Naming. As expected, the Structure Recovery models score poorly on this metric since they are explicitly de-
17

---

Published as a conference paper at ICLR 2026
You expert reverse engineering analyst tasked with evaluating LLM decompiler performance. You will receive source code and its decompiled version, then assess the readability of the decompiler's output.
each criterion, provide:
poor) to (excellent) 2. concise 1-2 sentence rationale
integer
from
**Input
1. Original Function [SRC]
Decompiled Function [DSRC]
**Scoring guidance:**
**1 Very Poor**
1.1 Function, variable, and field names are meaningless (c.g., 'funci', "varl', 'field_4").
1.2 Names not reflect their semantic roles (e.g., counter named "ptr2") ).
1.3 Types are missing or collapsed into raw pointers/integers, with no sign of higher-tevel structures.
patterns are opaque (e.g., complex pointer arithmetic instead of "arr[i]"
"bbj.feedd').
2.1 Some identifiers exist, but remain generic and uninformative.
2.2 Type information is partially present, but arrays, structs, or objects are poorly reconstructed,
2.3 Code slightly more readable than raw disassembly, yet the correspondence to source-level abstractions weak.
*+3 Fair**
3.1 Function and variable generic.
somewhat descriptive, though often inconsistent too
3.2 Basic type recovery exists: arrays, pointers, and simple structs recognizable.
3.3 Field and array access are partly reconstructed, but may still fall back to pointer
arithnetic in places.
3.4 Readability is acceptable, but requires effart to interpret correctly. Good**
4.1 Names are meaningful, semantically relevant, and generally consistent with their roles.
4.2 Structs, arrays, and object types are restored in a way close to natural source code.
4.3 Field and array access is mostly clean and human-readable ''obl.field', 'arr(i)').
4.4 Overall readability is high, though not fully equivalent to carefully written source code. -Exceleene*
5.1 Function, variable, and type nanes are clear, natural, and semantically accurate. well-structured classes, structs, and arrays that match
Type recovery faithful, typical source-levell abstractions.
unnecessary pointer arithmetic. 5.4 The recovered code feels almost indistinguishable from human-written source, with excellent overall readability.
Field
indexing intuitive entirely
=*Output Format:*s
Provide only a valid JSON object with exactly these two fields:
json
"Code Readability Assessment";
"score": <int>, "rationate"; "estring="
}
Output only the 150N object without additional commentary.
Figure 5: GPT-judge prompt for a qualitative assessment of Identifier Naming effectiveness.
Table 5: R2I results between the SK2 Decompile variants. Note that since R2I evaluates decompiled code relative context quantitatively (Eom et al. 2024). its values can vary significantly for the same decompiler when compared with different baselines.
Humankvval
MBPP
ExeBench
GitHub2025
R2I
AVG
AVG
AVG
00
03
AVG
pseudo-sre
54.62
57.77
56.47
56.53
54.43
55.83
59.11
49.34
55.15
54.41
51.71
53.17
pseudo-ir
51.85
60.25
56.39
54.81
55.73
55.26
55.86
53,96
55.18
58.31
55.30
56.46
pscudo-ir-el
55.51
60.76
57.53
54.49
58.39
57.36
59.68
60.82
60.92
59.24
56.95
57.15
psuedo-ir-sre
53.58
59.52
57.10
55.22
56.30
55.80
56.04
55.50
55.73
59.36
56.06
57.33
psuedo-irssre-l
56.41
59.01
57.49
54.68
59.28
57.75
59.50
60.59
61.06
59.70
57.56
57.73
signed not to restore original names. Overall, the results altogether validate the effectiveness of our decomposed approach.
18

---

Published as a conference paper at ICLR 2026
Table 6: GPT-judge results between the SK Decompile variants
HumanEval
MBPP
ExeBench
GitHub2025
GPT-judge
00
03
AVG
00
03
AVG
00
03
AVG
00
03
AVG
pseudo-sre
4.45
3.80
4.05
4.23
3.89
2.30
2.37
3.08
3.00
pseudo-ir
2.88
2.69
2.74
2.78
2.64
2.72
1.96
1.73
1.75
2.42
2.23
2.34
pscudo-ir-rl
2.93
2.69
2.79
2.80
2.67
2.73
1.97
1.73
1.77
2,43
2.32
2.35
pscudo-ir-sre
4.48
3.99
4.16
4.26
3.94
4.09
2.47
2.45
2.38
3.02
2.96
3.03
pseudo-ir-sre-rl
4.51
4.05
4.24
4.31
3.95
4.12
2.48
2.47
2.42
3.05
3.02
3.06
A.4 THE USE OF LARGE LANGUAGE MODELS
During the preparation of this manuscript. we utilized a Large Language Model (LLM) only for assistance with writing. The LLM's role strictly limited proofreading, correcting grammatical errors, and improving the clarity and readability of the text. The core research ideas, methodologies, and conclusions presented in this paper were conceived and developed entirely by the authors.
A.5 CONSTRAINTS ON RE-EXECUTABILITY TESTING
ExeBench's 'ss unit tests require information (exact symbol/type names) that is intentionally removed during compilation and stripping. As result, even behaviorally correct decompilation cannot be compiled and executed against the ExeBench tests.
To illustrate this, we present the first two test cases from ExeBench as example.
Case 0: Dependency on Global Variables
Source Code:
Pseudocode:
void SCC, Reset(void)
long long sub 4CE3() {
(Wires| Wire VIAI iA7 _ll_iAA_,,0 SCCwaitrq)) =
*(uint32 (qworrd 481 qword_440 481C8) =
SCC.SCC Interrupttt Type
qword 481B8 OLL;
(Wires[Wire SCCIntemuptRqquest)
*(uint32_t t [qwword 481 4 qword 481C0) =
SOCt.oiiner
qword 48180 OL.1;;
SCC.MIE -0;
qword 481A8 OLL:
SCCC.Intrrupeeectoo==00
qword A81 01.1;
SCC InitChannel(1))
sub 4CC6(1LLL);
SCC ImitChannel(O)):
sub 4CC6(0LL);
SCC Reset(Channe(());
sub 4CA9(1LL));
SCC ResetChannel(O):
return sub 4CA9()LL):)
Case 1: Dependency on User-Defined Types
Source Code:
Pseudocode:
void Stateldle(LLtc41511 5 next, Ltc4151 *device) uint32_r t *sub 4CA9(inn al, uint32_t (uint32_t *result; result a2; #a2 al; return result;
(device->state next;
Figure 6: Typical examples of ExeBench.
Globals lost (Case 0): The original source code relies on two external global variables, Wi Wires and SCC, and their specific field names (e.g., Poi nterBi ts). As the pseudocode shows, this symbolic information lost, replaced by direct memory addresses (e.g., qword (0). re-compile and pass the test, decompiler would need to identically recover the exact structure and names of Wires and SCC, which is not feasible from the stripped binary.
User-defined types erased (Case 1): Similarly, the source code requires two specific user-defined types: Lt 114411statt and Lt c4151. These type names are completely lost during compilation and stripping. The ExeBench test suite is designed to compile against the original source headers. Any decompiled output that does not recover these exact (and arbitrary) type names will fail to compile, making the re-executability test impossible to pass.
19

---

Published as a conference paper at ICLR 2026
In summary, ExeBench's re-execution task heavily relies high-level symbolic information like user-defined type names or variable names, which are deterministically lost during compilation and stripping.
We concluded that any success on this benchmark would likely be due to the LLM "remembering" the original source code from its training data (i.e., data leakage) rather than performing genuine decompilation. This would render the evaluation results untrustworthy for our purposes.
A.6 EVALUATION ON BRINGUPBENCH
We have extended our experiments to include the BringUpBench (Ron et al. 2025). We com- piled, decompiled, and executed the projects across optimization levels O0-O3. In total, there's re 90 projects with 505 fucntions. We compared SK2 Decompile against the industry-standant rule-based decompiler, IDA Pro.
Table 7: Compilation and re- re-execution rates on BringUpBench
Re-compilability rates
Re-exccutability rates
Method
00
01
02
03
AVG
00
01
02
03
AVG
IDA
28.4
23.2
23.3
19.4
23.6
25.4
21.6
21.4
18.3
21.7
SK2 Decompile
44.3
44.5
42.1
38.3
42.3
34.3
29.1
24.9
19.7
27.0
Quantitative results on BringUpBench compare SK² Decompile against the industry-standarl de- compiler, IDA. Specifically, method achieves compilation rate of 42.3%, compared to 23.6% for IDA. Furthermore, regarding functional recovery, SK Decompile demonstrates a re-executability rate of 27.0%, whereas IDA achieves 21.7%.
These results confirm that our approach maintains a reasonable success rate and superior functional correctness on complex, real-world binaries where rule-based systems struggle.
Implementation and Reproducibility To ensure transparency, we have open-sourced the repro- duction scripts in the Supplementary Material. Our evaluation pipeline consists of five steps:
I.Compilation: Compile all C projects in BringUpBench into binaries using flags O0-O3.
2. Bassellnee Extraction: Leverage IDA Pro analyze binaries and extract corresponding pseudocode.
3.Ground Truth Mapping: Parse the source code. We pair binary functions with source functions based on file paths and symbol names.
D.Dcoompilttion Decompile each binary function using SK2 Decompile and substitute the result back into the source tree.
Validation: Compile the substituted source code and run the project's test suite to verify functional correctness.
A.7 IMPACT OF FEEDBACK LOOPS
Previous research has shown that feedback loop can improve re-executability (Hu et al., 2024 Wong et al.) 2023). ). To assess this, we ran an automated compile - run - diagnose - edit loop using of-te-of-the-arn commercial Al coding tool, Codex HumanEval dataset. For each decom- piled function, we provided the Codex with the decompiled C code from SK2 Decompile and unit tests, with N 1,5):
= 0 (no tests): Approximates the common real-world case where test is unavailable. The model relies only on compiler/runtime messages and its own edits.
1 (single test): Supplies a minimal behavioral hint.
N 5 (hintful tests): Supplying richer set of tests provided clear behavioral specifications.
20

---

Published as a conference paper at ICLR 2026
Note it's not meaningfull to provide all the test cases to Codex, the tool can synthesize code that passes all cases without preserving the original implementation. Crucially, this feedback loop is a post-processing step that benefits from better initial decompilation. We conducted a comparative study applying the same feedback loop to the output from our baseline, L.M44ecompile.
Table 8: HumanEval Re-exccutability results with refinement using Codex.
SK' Decompile
LLM4Decompile
Re-executability rates
00
01
02
AVG
O0
01
02
03
AVG
Base
86.59
70.59
62.04
58.41
69.41
67.07
37.25
33.58
28.32
41.56
+Codex
90.24
80.39
75.18
72.57
79.60
71.95
49.02
49.64
46.02
54.16
+Codex w test
93.29
83.66
81.75
77.88
84.15
77.44
51.63
56.93
53.10
59.78
+Codex w test
95.73
87.58
87.59
83.19
88.52
82.32
58.82
62.77
59.29
65.80
The refinement loop consistently achieved a higher final executability rate when starting from the SK Decompile output. Compared to using L.M4Decompile, the pass-rate 46.97% higher with N=0 test cases and 34.52% higher with N=5 test cases.
This demonstrates that better starting point and raises the "upper bound" of what even a sophisticated feedback loop can achieve. Therefore, while refinement powerful, improving the core decompiler remains funda- mental.
accurate base decompiler, like SK2 Decompile provides a significantly
Note that the refinement loop is computationally expensive (30 s per item; 30 hours for a full run; Million API tokens usage).
A.8 QUALITATIVE ASSESSMENT
Our inspection confirms that SK2 Decompile remains highly robust across standard decompilation scenarios. However, by analyzing the edge cases, we identified three categories of challenges that stem from the intrinsic nature of the task. We highlight these as key frontiers for the community:
Contextual Boundaries: Challenges arising from dependencies outside the single-function scope resolving global variables), which require context beyond the current input window.
Pattern Rarity: Difficulty handling non-idiomatic patterns that statistically deviate from standard data distributions.
Difficulties with precise numerical operations, known limitation of current LLM architectures rather than the decompilation approach itself.
Arithmetic Precision:
Contextual Boundaries. First, SK2 Decompile ables, which are not defined within the function's 's immediate binary code.
designed handle elements like global vari-
For instance, noted in Figure SK2 Decompile currently struggles with elements like global variables that are not defined within the function's 's immediate binary code.
The original source code relies on two external global variables, Wires and SCC, and their specific field names (e.g., PointerBits). As the pseudocode shows, this symbolic information is lost, replaced by direct memory addresses (e.g., wword_481D0) To re-compile and pass the test, decompiler must to identically recover the exact structure and names of Wires and SCC, which is not feasible from the stripped binary.
The clear research direction is to move towards binary-level decompilation. which would incorpo- rate this wider context (e.g.. information from function calls data sections like rodata). However, this approach introduces a significant new challenge: computation cost. This contextual informa- tion drastically lengthens the input. Based on our GitHub2025 dataset (compiled from real-world projects post-2025), eachfunction calls average of 6.3 other functions. Simply concatenating this data would lead to a quadratic computation cost for the attention mechanism, which extremely expensive for both training and inference. Therefore, research methods that can effectively balance this trade-off between computation cost and perfor- mance, enabling the model to leverage wider binary-level context efficiently.
believe critical future challenge is to
21

---

Published as a conference paper at ICLR 2026
Note that in such condition, the idea of decomposition proposed in this work is more significant. Binary-level decomposition will include sigmificant more types and functions that cross-referred to each other, obfuscated the code for cleaner object will significantly reduce the complexity. And the idea of using compiler feedback as reward proposed this work will continue to benift the training of more effective model.
Pattern Rarity, second critical challenge is that SK2 Decompile can misled by abnormal or non-idiomatic patterns in the input pseudocode. The model inherits and replicates errors from the decompiler (e.g. IDA) instead of correcting them.
Source Code int fimc n)
Pseudocode
long long sub (1nt al) int vvl; int v3; uint32 _int32_tv4[101) vv4[111]; unsigned long long v5;
int [[000]
[[O] 0; [[] = -2 2;] =]]]=;
for (int i- i;
v5 readfsqword(
[ii== = [[i- 1]+ [i- [[i-33+ 4|:
=3=0;
return [[m]]]
v4[0] = 0;
v4[1]
SK2Decompile
v4[2] = 0:
int funo n)
(al
int coun{[100]:
vI &v3:
count[O] 0; count[1] [|] 2: count[2]
do {
for (int = 3; i++) {
vI[4] *vI vI[I] v[[3]+ v1[2]: +vy,;
count[i] = count(i-
count(i 2]
count(i 3] count(i- - 4]:
while (vl !- &v4[al -4):
count(n- 11:3
return (unsigned int)v4[al 13:
Figure 7: Qualitative assessment on pattern rarity.
We observed this in where the source code initialized the first four elements of array: f [[0]=0; [=1]=; f [2]=2; f =[ IDA initializes only three elements of 44 and intro- duces temporary
that adjacent to v4. The loop then updates via v1 &v3, so [4] aliases into v4. This non-idiomatic pattern obscures the intended four-element seed and shifts in- dices. Our model, SK2 Decompile, was misled by this abnormal input. As shown in its output, initializing only three elements (count [0], count [1], count [2]) and failing to semanti- cally reconstruct the correct program logic.
This reveals a significant research challenge, the next frontier is not just scaling models, but inte- grating deeper semantic analysis. Models should learn to critically inspect and correct data flow and logic flow, not just translate patterns. How to efficiently integrate formal program analysis (like data/control-ffow -llow with neural models is a very challenging but necessary next step for the commu- nity.
Arithmetic Precision. A third critical challenge lies reversing compiler optimizations related to numerical operations.
As detailed in the example below, the source code implements a simple modulo op- eration: i & 11 == 0 i $ 13 == o. However, the compiler optimizes this oper- ation into a sequence of multiplications and comparisons using "magic numbers" (e.g., -1171354717 v1 <= 39045157 572 -991146299 expensive division instructions runtime. While SK2 Decompile successfully identifies the semantic intent-correets predicting that modulo operation is taking place-it fails to recover the correct operands. Instead of 11 and 13, hallucinates 20 and 21.
v1 <= 330382099) to avoid
This failure illustrates that while the model understands control flow patterns, it cannot reliably perform the reverse-mathent mathematics required to decode compiler optimizations. Because LLMs are inherently weak precise computation, this identifies key direction for future work: integrating external tools (like SMT solvers) into the generation loop to handle numerical recovery, rather than expecting the L.M to "solve" the math internally.
22

---

Published as a conference paper at ICLR 2026
Source code
Pseudocode
SK2Decompile int func0(int
int func0(int m)
long long sub 12F0 al)
int count 0:
unsigned vl; unsigned int v2;
count 0; for (int = 1;i i++)
for (int 0; n; i++)
unsigned v3; v1 =1
( % 11 =- 0 13 - 0)
(al > 0) {
(i % 20 ||
0)
int q q-
while (al != 1=++v1)
int temp = i;
while (q 0)
while (-1171354717 + v1 <= 390451572
while (temp != !=
(q % 10 7) count
991144299 * <- 330382099)
if (temp % 10 - 7)
9- q 10:3]
v3 vl;
count++;;]
return count:]
7: v3 10u:
temp /- 10:313
while (v3); if (al v1) return v2;)
retrn count:)
return v2:]
Figure 8: Qualitative assessment on arithmetic precision.
A.9 BASELINE AVAILABILITY AND REPRODUCIBILITY
Nova: While the model weights available, the generation logic relies heavily specific <label-N> tags. The code to generate these labels is not provided, rendering the preprocessing pipeline unreproducible. Furthermore, Nova's reported performance (34.36 re-executability rate HumanEval) is already significantly lower than our baseline, LLM4Decompile (41.71), suggesting that even perfect reproduction would not alter conclusions.
DLift: We attempted to access the code referenced the latest paper version, but the GitHub link provided remains placeholder.
Ref-Decompile: We conducted a deep dive to reproduce this work. We successfully adapted their preprocessing for single-file contexts (HumanEval and MBPP). However, extending this to ExeBench and GitHub2025 proved infeasible. Ref-Decompile's preprocessing strictly assumes single C-file compilation via gce (Ref-Deccrainn/ooppeeee:::: 1121111))...p.111122))) whereas ExeBench and GitHub2025 require complex build environments (mixed C/C++Asseembyy and CMake linking).
In terms of re-executability on HumanEval and MBPP, Ref-Decompile performs comparably to SK3 Decompile only on unoptimized code. However, in realistic settings (O3 optimiza- tion). SK2 Decompile significantly outperforms Ref-Decompile, achieving relative improvements of 22.64% and 27,45 27,42%, respectively. Additionally, SK2 Decompile consistently surpasses Ref- Decompile on readability metrics, as evaluated by both R2I and GPT-judge.
Table 9: Re-cxecutability rates on HumanEval and MBPP
HumanEval
MBPP
Method
00
01
02
03
Avg
00
01
02
03
Avg
SK2 Decompile
86.59
70.59
61.31
57.52
69.00
69.76
62.33
54.83
51.58
59.63
Ref-Decom def-Decompile
85.37
52.29
44.53
46.90
57.27
68.65
52.97
46.54
40.48
52.16
Table 10: Round-trip interpretability (R2I) results on HumanEval and MBPP.
HumanEval
MBPP
Method
00
03
Avg
00
03
Avg
SK² Decompile
63.25
61.76
62.14
59.16
62.52
61.23
Ref- Def-Decompile
56.28
58.20
57.97
59.43
60.03
59,91
A. COMPARISON WITH CLASSIC DECOMPILER
have integrated IDA Pro (Hyx) into evaluation to contextualize model's perfor- mance. As detailed in the revised experimental results, SK Decompile demonstrates distinct advan- tages over the conventional baseline. The results included in Table 1 Table 2 and Table 3
23

---

Published as a conference paper at ICLR 2026
Table 11: GPT-judge ratings HumanEval and MBPP
HumanEval
MBPP
Method
00
03
Avg
00
03
Avg
SK. Decompile
4.51
4.05
4.24
4.31
3,95
4.12
Ref-Decompile
4.23
3.64
3.92
3.84
3.43
3.66
Re-executability: SK2 Decompile produces functionally executable code significantly more often than IDA, showing improvements of 68.49 and 50.42 HumenEval and MBPP datasets respec- tively. While IDA generates pseudo-code optimized primarily for static analysis containing syntax errors undefined patterns that require manual patching to compile-our method bridges this gap by generating syntactically complete code that allows for immediate re-execution and dy- namic verification.
We wish to clarify the fundamental distinction between binary Lifting (the goal of tools like me- toll (adavalli & Smith 2019)) and Decompilation (the goal of SK2 Decompile).
Ilvm-metoll aims to translate binary code into LLVM IR. This is an intermediate representation optimized for compiler analysis and re-optimization, representing "Hardware Truth" (low-level op- erations).
In contrast, SK Decompile aims to recover maintainable C source code. This requires recovering high-level abstractions and control flow structures ("Loggcal Truth") optimized for human readabil- ity.
Comparing SK2 Decompile directly to metoll is arguably an their output formats serve different abstraction layers. To illustrate why LLVM IR (even when lifted correctly) is distinct from decompiled source, we provide a concrete examples below.
comparison because
MLTM-1 lifting (total 173 lines)
define aso_local i32 @func0 (164 $argl, i32 $arg2, double $arg3,
double $arg4)
entry:
&stktop_4 alloca 18, 132 40, align .1.21 lines...
br label $bb.1
bb.1: sentry, $bb.9 .9
preds
8memloat oad load 132, ptr 8RBP_N.28, align 1 ...14 lines... cmp eq 11 &SF, 8OF
br il $CmpSFOF_ JGE, label 8bb.10, label $bb.2
bb.2: 2:
i preds $bb.
$memloadi load 132, ptr $RBP_N.28 2228, align ...13 lines... br label $bb.3
bb.3:
; preds bbb. 2,
$bb.7
$memloads oad8 load 132, ptr 8stktop_4, align ...14 lines...
br il (CmpSFOF_JGE4S label 8bb.8, label $bb.4
bb
preds $bb.
$memload15 load 164, ptr SRBP N.16, align 1 ...37 lines...
br i1 SCFAndZF_JBE, label 8bb. 6, label 8bb.5
24

---

Published as a conference paper at ICLR 2026
bb.5: store 132 1, ptr SRBP N.4, 4, align 1 br label 11
; preds $bb.4
bb. 6: br label $bb.7
preds $bb. 4
b
i preds $bb.
&meml 3memload31 oad31 load i32, ptr $stktop_4, align 1
...13 lines... br label 8bb.3
bb. b:
preds $bb.3
br label $bb.9
bb. 9:
preds 8bb.8 8
$memload39 load i32, ptr SR3P_N.28, align
...13 lines...
br label $bb.1
1b:10:
; preds $bb.
store 132 0, ptr $RBP_M.4, align 1
br label $bb.11
bb.
; preds
sbb.10, $bb.5
$memload47 load 132, ptr $R3P SRBP_N.4, align ret 132 $mmml cad47
SK2Decompile
int func0 (float *array, int n, float eps) int i, j: for (i 0, for = 1; i < j++) {
ny it+) {
if (fabs (array [i] - arraylil) < eps)
return 1;11}
return 0;)
Array Indexing (Explicit Arithmetic vs. Abstraction) Source: array [i]
Lifter (metoll): It explicitly reconstructs the byte-offset calculation. In the IR, this appears as:
Smemref-idxen -idxeeg mul i64 4, RRCX ; Index bytes Smemref-basere add i64 $memload15, $memref-idxreg: Base+Offset.
$28 = inttoptr 164 Smemref-baseree to ptr Cast to pointer
SK2 Decompile: Recognizes the pattern base (i sizeof (type)) and collapses back into array [i].
The For-Loop Structure (Flags vs. Logic)
Source: for (i 0;
size; +++)
Lifter (metoll): The CPU uses comparisons and jumps, not loops. metoll preserves the "flag" in- herent to the x86 CMP instruction (calculating differences and setting Zero/Sign flags). These flags creates massive noise in the IR.
9 sub 132 ememloo oad, $8
The subtraction (i - n)
ZF i cmp eq 1.32 89, 0
Zero Flag
25

---

Published as a conference paper at ICLR 2026
SSF icmp
132 shighbit,
Sign Flag
$CmpSFOF_JGE JGE
icmp eq i1 sSF, OF Jump if Greater Equal
SK Decompile: Performs Control Flow Graph (CFG) recovery to identify the cycle, collapsing the subtraction and conditional branches back into a for loop structure.
Because metoll stops at LLVM IR-preserving stack manipulations and flag simulation-it does not compete readability source recovery. The appropriate rule-based state-of-the-art benchmarks are industrial decompilers IDA Pro. It also lifts to an internal IR (Microcode) but then perform the necessary structural analysis to emit high-level pseudocode.
Therefore, we utilized IDA Pro as the rigorous rule-based baseline for our evaluation.
Structural Readability (R21): We observe substantial margin in structural recovery. IDA achieves an R2I score of approximately 40, which is nearly half the 70 achieved by SK Decompile. This low baseline score emphasizes that conventional decompilers. while semantically accurate, often fail to reconstruct the high-level control flow logic or data structure necessary for human readability.
Naming Quality (GPT-judge): SK Decompile surpasses IDA by over 30% in identifier nam- ing quality. unlike conventional tools that rely on generic, register-based nomenclature (e.g., v1, sub 404, arg2), our model leverages semantic context to infer descriptive variable and function names. This results in output that aligns closely with the original developer's intent, significantly reducing the cognitive load for analysts.
A.11 IDENTIFIER NAMING AND SK2 Decompile
[TRADITIONAL APPROACH:
"Decorating Messy Pile"]
variable/type naming only
"Skull"
"Rib"
"Tibis"
"Fenur"
/
RESULT:
Recover names, the pile pile. Logic remains broken and hard to read.
[Phase 1: SKELETON RECOVERY REBUILD THE STRUCTURE Ignore inilially; res joints loed-bearing
[Phase 2: SEMANTIC SKIN CONTEXT-AWARE NAMING
fixed, names
(Head)
function: parsecow()
(Neck)
Spine Control-Flow)
APT/entity labels
II "Mod", ReadBuffer, HashMap
(R1)
(R2)
(R3) (R4)
ribs
Data structure
[Hip]---/
[Shotderr]
11
(Leg)
(Leg)
step total index count
tail
RESULT: Valid high-level structure (CFG, loops, iffelse) stands own. Variables still generic (V1, v2, v3), but the "animal" stands.
RESULT: Fully decompiled, readable code: correct logic + informative names.
Figure Difference between pure Identifier Naming and SK2 Decompile.
Previous Identifier Naming works (Xie et al. 2024 Lacomis al.) 2019 Chen et al., 2022) takes existing. potentially unstructured "messy" pscudocode and attempts predict variable names-effectively "decorating" the components without assembling them. As illustrated in the following plot, this is equivalent to painting
surface without checking the form beneath.
In contrast, our approach treats decompilation as a two-stage generation problem: 1.Structural Re- covery (The Skeleton): Reconstructing the control flow and logic from the "messy components" of low-level code. 2.Semantic Recovery (The Skin): Inferring meaningful variable names and types. As illustrated in the following plot, first rebuild the skeleton, then recovers the skin.
26

---

Published as a conference paper at ICLR 2026
The primary innovation of our implementation is the prioritization of Structure Recovery. Unlike the cited paper, which assumes the structure exists and focuses only on the "skin", we build the anatomy from the ground up. The cited paper attempts to paint cow pattern on a disorganized pile; in contrast, we build the skeleton first to ensure the skin sits on a correct anatomical structure.
A.12 ROBUSTNESS AGAINST ARCHITECTURES AND LANGUAGES
We demonstrate that SK' Decompile is highly robust to architecture changes and discuss its applica- bility to other programming languages like Go and C++.
Robustness Across Architectures and Operating Systems Our method generalizes different architectures without requiring fine-tuning. To validate this, we evaluated SK2 SKeDecoppil on two additional platforms: MacOS-arm64 alln--Cang and Windows-X64-SSVC
As shown in table, the performance remains consistent with our original Linux-x64 XC4-GCC results. For MSVC, optimization flag /Od corresponds to -O0, and /Ox is roughly equivalent to -03.
Table 12: Re-executability of SK2 Decoomppeee when decompiling binaries from different platforms
HumanEval
MBPP
Re-executability rates
00
01
02
03
AVG
00
01
02
03
AVG
Linux
86.59
70.59
61.31
57.52
69.00
69.76
62.33
54,83
51.58
59.63
Windows
70.80
70.34
58.01
51.40
62.63
72.60
67.49
55.23
49.33
61.16
MacOS
83.97
50.98
47.45
44.64
56.76
73.05
55.86
48.48
46.90
56.07
These results demonstrate that Decompie effectively captures program semanties regardless of the underlying instruction set architecture (ISA) OS-specific conventions.
Generalization to Other Languages Our model demonstrates the capability to recover structure and naming information from binaries compiled from other languages, such as Go and C++, without requiring additional fine-tuning.
Case A: Go (Golang) Although SK2 Decompile was trained exclusively on C, it successfully recov- ers the logical structure of Go binaries.
GO code fune funclií int) int
Pseudocode
void main fime n, int int_rr) v2; long long
count
for :- 0; i it+
int v4jlong long v5;
ir1%11 11613
vó;
q-i
v2 - OLI. OLL;
while (a.>
if 1'4 - 71
v4 n: xy3;
count 1)
[v2 (v1--11 "[[long long)X(nsiineed
== 2299/1011 10]1]
(v2 991129997779005554443340000 >>64)
return count)
x2 -2-on=((long Xtunsiiud 1n)
(v2 (m1122/6669922255549222223383313
SKCDecompile
v6
void fincoliint temp- long count for (int i- 0. i-+))
while (v
if(v2-10 "([long longX(22 ((unsignod 2n
(v2*<__ntt) jnt128](oong (tg1:/117775522277672111)))00000 --7)
+-v5.
v2 - (lang longlVv2 ((unsiined in:128)
temp -;;
(v2 * intl28g 2097 2>64)) >5-3:)
while (temp
v2
(tomp % 10 7) counttt:)
++2;
temp - 10:]1]]
v3 - v5:13
Figure 10: Applying SK2 Decompile to decompile Go binaries.
While the logic and variable names generated by SK2 Decompiel are largely accurate, the model lacks awareness of Go-specific syntax. In the provided example, the underlying tool (IDA) incor- rectly identifies Go function having void return type. Consequently, while model correctly
27

---

Published as a conference paper at ICLR 2026
reconstructs the algorithmic logic (looping and modulo operations), it omits the explicit return state- ment. This indicates that our model's 's logic extraction is robust, but the output is bounded by lack of exposure Go grammar.
Case B: C++ Similarly, SK Decompile effectively recovers the logical structure of C++ bi- naries. C++ relies heavily monomorphization (templates) and zero-cost abstractions (e.g., :td::vector or Rust Iterators). While efficient at runtime, these abstractions produce ver- bose, low-level assembly code involving complex pointer arithmetic and distinct iterator types (e.g..
_gru_cxx:
during decompilation.
As shown in the C++ example, our model successfully filters through this "noise" recover the high-level logic. However, because the model was never trained on C++ source code, it cannot reconstruct high-level standard library conventions (such as std: : strring), instead treating them as raw structures.
Limitation on Saneiige-Speecfiic Features It is expected that decompilation performance will degrade or fail when the target binary heavily utilizes language-specifie features that have direct equuvalent. For instance, massive use of C++ template metaprogramming or complex Go runtime interactions cannot be handled effectively, the model's training data is limited to C. Languages like C++ and Go introduce orthogonal challenges- sierengges-seeiicallll heavy reliance on polymorphism, templates, and complex runtime environments (e.g., Garbage Collection). Addressing these fea- tures require designing language-specifie pre-processing steps and paring binary-source functions, which we consider distinct research problem that may deserve a new research paper. Therefore, following the approach of recent LLM-based decompilers (Slade, Nova, LLM4Decompile, Idioms, Ref- DeffDecompile), this work focuses on C.
C+- saree code in fanelh in
Picudaced:
SKCDeoampil:
.054 basill fineleineaa
iet fareliiie ax iell coury Ot
int count -
unsignad in 12.
forinn in ctm tii
int m064 wi; i5 BYTE Pot, BYTE unippe
unsignol in154
Sor (ant i Be 5-13 0 (1 13 wring str to sziagd fumner it- argint)
ii II 11% ---0) Op
v8 codlsppee//iccaa O
aft
stilatiing i std.ae stisafii ()
Sor (1- 0, a.i+al.+++]]
Int 10. 1131 10% 1133
?
adhie strigiitte exsil *p
furnte and atrand it end (111 if ("i 775 counttie]111 count))
11comm))11
v v2, wtb--nngg-hhgeeeeo
rotue count))
while (urmizzed in8) you coo eoccopannttmeeee atiuut Jo5S
if( " BYTE ") zau oot::
hemtoencher "and:wring "ppesssaop"----peeee""" (Av44)
vi:)
Figure 11: Decompilation output from IDA for the C++ binary.
1. OBFUSCATION AND OPTIMIZATION
We conducted additional experiments focusing on two dimensions: adversarial obfuscation using Obfuscator-LLVV and aggressive compilation flags beyond standard -03.
Compiler Obfuscation. We utilized Aittsscator-LLMM Junod et al. 2015) to apply three distinct obfuscation techniques: Instruction Substitution (SUB), Bogus Control Flow (BCF), and Control Flow Flattening (FLA). The results summarized below:
Table 13: Re-cxecutability results under obfuscation.
HumanEval
MBPP
Re-exccutability rates
00
01
02
03
AVG
00
01
02
03
AVG
Base
86.59
70.59
61.31
57.52
69.00
69.76
62.33
54.83
51.58
59.63
BCF
3.66
13.73
10.22
9.73
9.33
10.89
16.73
13.40
13.37
13.60
FLA
14.02
5.88
4.38
5,31
7.40
20.14
10.79
8.89
7.14
11.74
SUB
77.44
52.29
43.07
46.02
54.70
60.02
56.85
47.89
45.79
52.64
As observed, the model exhibits varying degrees of resilience. While Instruction Substitution has moderate impact (retaining over 50% re-executability rate on both dataset), structural obfuscations significantly degrade performance. Specifically, Control Flow Flattening (FL.A) caused the most
28

---

Published as a conference paper at ICLR 2026
severe performance drop (89.27% on HumanEval and 80.31% on MBPP). The observation is similar to what reported in LLM4Decompile, where it achieves around 5% re-executability rate on under FLA.
We view de-obfuscation and SK Decompile is designed to recovering readable, high-quality source code from binaries produced by standard compiler pipelines. Techniques used for obfuscation (e.g.. control flow flattening) are adversarial in nature and intentionally break the patterns that general decompilers rely on. While our model demonstrates robustness against high-level optimizttions, dedicated de-obfuscation is out of the scope of this work. However, believe SK? Decompile could serve downstream module in a de-obfuscation pipeline once the adversarial layers are normalized.
decompilation as related but distinct research areas.
Optimization beyond 03. To test robustness against aggressive optimizations, evaluated four specific configurations generally considered "beyond -O3":
-Ofast: Enables aggressive optimizations that may disregard strict standards.
-O: Optimizes for code size.
-03 mmrrch=aaive:: Optimizes for the host CPU architecture.
-03 funroll-loops: Unrolls loops to trade size for speed.
The results presented in the table below:
Table 14: Re-executability under different optimization.
Optimization
03 Ofast
Os
03 native
03 loops
HumanEval 57.52%
57.52%
58.40%
53.98%
46.90%
MBPP
51.58%
51.02%
52.12%
45.80%
46.45%
Overall, SK2 Decompile demonstrates strong robustness across a diverse set of compiler optimization strategies. Performance remains relatively stable under -Ofast and -Os, suggesting that the model can handle both aggressive speed-centric optimizations and size-focused transformations. Architecture- specific tuning (-march-native) and corplunroliing introduce only moderate degradation. The results indicate that SK* Decompile generalizes well to real-world compiled binaries, where optimization settings can vary widely.
A.14 REWARD MODEL.
We quantified the contribution of each component in our ablation study (Table 4).
Imppcc of Cleaner IR: Moving from the direct pseudo-sre approach to the two-phase pseudo-ir-sre (cleaner IR target) improves the re-executability rate from 54.86 to 63.75 on HumanEval (+16.20%) and from 47.51 52.83 on MBPP (+11.19%).
I.Imp of RL: Applying Reinforcement Learning to this cleaner target (pseudo-ir-sre-r) yields further improvements, reaching 69.00 on HumanEval (+8.23% over the IR model) and 59.63 on MBPP (+ (+12.87% over the IR model).
In summary, while the cleaner IR target provides the initial performance gain, RL contributes significant secondary boost.
also important note why we applied RL specifically the IR-based model rather than the source-base model. Applying compiler-based RI. directly to the pseudo-src model poses signifi- cant challenge. Successful re-compilation (the reward signal) requires exact matches for function, Since this information is lost during standard com-
type, and field names (c.g., Ltc4151Stan pilation, expecting a model to generate these exact user-defined names without data leakage is an ill-posed problem.
Our approach mitigates this by targeting an IR with normalized identifiers (e.g.. typel, type2). By decoupling structural correctness from symbol recovery, ensure the generated code is self- contained and compilable. This allows the RL agent to optimize for logic and syntax to earn rewards, without being penalized for missing original variable names that longer exist.
29

---

Published as a conference paper at ICLR 2026
A.15 REINFORCEMENT LEARNING IMPLEMTATION DETAILS
Leakage analysis. The compilability-bine -aaeed reward is used only in the Structure Recovery phase and only on obfuscated IR. For reward evaluation, the compiler is given a minimal, obfuscated header whose identifiers are opaque placeholders (c.g., typel, funcl). The model never this header; the header is used solely by the compiler to resolve declaration during the reward check. Consequently, the step does not leak any original semantic ground-truth type information the model.
No-header ablation. Our model is trained on real-world code and accordingly generates place- holder symbols (e.g., typel, funcl). If header is provided to declare these placeholders, can- didates systematically fail to compile (unresolved symbols), the reward collapses to zero, and RL receives no learning signal, making the training signal uninformative. The obfuscated header is therefore necessary to obtain a meaningful reward without revealing structure/yppe information.
Thain Serward Thajectory Oemoothed ooer slepp)
Waldetion Reward (sparse chackpeints; contered windoowm3)
1.0
mM /V l Mppll // MM Phape Sw/
6.6
0.22
0.7
Recovery Compilert Placeholder
Structure Recovery
Compiler Placeholder
compless
Trxins
Waain Reward Vraecctory fsmoothedd over stops)
Validation Roward (sparse checkpoints, cer centored windomr-3)
Wearr bemooaseeeeeee amoomee
wwm Mont my M hwwhy//hhhhh
0.40
Identifier Naming
Identifier Naming
Embedding Similarity
Embedding Similarity
0.52
valde on samples tovl.
112
Trining step
Traning step
Figure 12: Training and validation reward for Structure Recovery and Identifier Naming
Structure Recovery: The training reward converges to 0.9 (out of a maximum score of 2.0, representing Compilability Placeholder Recovery). The validation reward tracks closely, indicating stable convergence.
Convergence
Identifier Naming:
The training reward converges to 0.64 (max 1.0 based on embedding similarity). with validation reward reaching 0.66.
Training required approximately 16 hours on H800 GPU with a batch size of 256 and a max sequence length of 4096.
Reward Hacking: We explicitly designed the placeholder recovery reward (the intersection of I_gen and T_ir) to reduce reward hacking. In preliminary tests using only compiler feedback (compilable vs. not), we observed reward hacking: the model maximized rewards by generating trivial degenerate code (c.g., void funcl () return 0; }) simply to satisfy the com- piler. By introducing the placeholder recovery reward, we successfully penalized this behavior and forced the model to generate semantically meaningful code.
A.16 IDENTIFIER NAMING REWARD
To evaluate the sensitivity of our results to the embedding choice, conducted additional exper- iments comparing our baseline (Qwen3-Emie Saendd--meddddn.....m -.6B) against GTE-Large (Li et al., (023) (a widely used model of similar size) and
(a significantly larger model).
30

---

Published as a conference paper at ICLR 2026
Regarding Metric Correlation: We invited human rators and use the GPT-based evaluation proto- col established in the paper rather than Identifier-lewe matching is not suitable for this task for two reasons:
or Exact Match. We argue that exact token
Semantic Equivalence: A variable named count should not be penalized against counter, yet F1/Exact Match would treat them incorrect.
Alignment Issues: There is often no one-to-one correspondence between generated variables and ground truth source code, rendering token-wisse comparisons unreliable.
GPT-judge results: As shown in the table below, the naming quality remains relatively stable across different embedding models on all four datasets. While "wenn-Emeeddinn-8ff yields a slight improvement (approximately 0.07 points on average), the results are quite close to each other and demonstrate that our method robust and overly sensitive to the specific embedding model used.
Table 15: GPT-judge ratings Identifier Naming model trained different embedding models
HumanEval
MBPP
ExeBench
GitHub
Model
00
03
Avg
00
03
Avg
00
03
Avg
00
03
Avg
Qwen-0.6B
4.51
4.05
4.24
4.31
3.95
4.12
2.48
2.47
2.42
3.05
3.02
3.06
GTE-Large
4.48
4.12
4.21
4.24
3.99
4.16
2.45
2.32
2.34
3.01
3.05
3.03
Qwen-8B
4.63
4.19
4.35
4.34
4.09
4.26
2.57
2.37
2.44
3.21
3.02
3.09
To evaluate the impact of embedding choice on human perception, we recruited three graduate students with experience in reverse engineering rate decompiled results. Adopting the same criteria as the GPT-judge (Figure 5), evaluators were presented with the ground truth source code alongside two decompiled outputs. They performed a pairwise comparison to determine which result was superior (Win, Tie, or Lose). The final classification for each sample was determined by the majority vote of the three evaluators. We compared rewards calculated using awen3-embedding 8B, Owen3-embedding 0.66, and GTE-Large across 100 random samples from GitHub2025. The evaluation criteria remained consistent with the GPT-judge results in the above table.
Human Rating:
As shown in the following figure, while -wen-embedding-888 achieved higher win rate, the perfor- mance of GTE-Land Large and lwwen-emeddding-1 -0.6 was comparable. Notably, the majority com- parisons resulted in a "Tie' (71.66%), indicating that evaluators often could not distinguish between the quality of the outputs. This high tie rate suggests that training process not overly sensitive to the specific choice of embedding model.
31

---

Published as a conference paper at ICLR 2026
Win
Tio
loss
19.0
72.0
9.0
Owen-0.60
Owen 88
25.0
68.0
6.0
vs. GTF-Large
Ower-0.88 0.88 GiF--aagge
200
Win Rate
Figure 13: Human Rating GitHub2025.
32


Reviews:
[{"review_id": "Xcqd73MLo6", "reviewer": "Reviewer_564f", "summary": "This paper proposes SK2Decompile, an LLM-based binary decompilation approach.\n\nSection 2 discusses existing decompilation approaches, and provides a motivational example.\n\nSection 3 proposes SK2Decompile. It consists of (1) structure recovery yielding an intermediate representation (IR); and (2) identifier naming. Each phase uses a model that has been subjected to supervised fine-tuning and reinforcement learning. The design of the intermediate representation is cast as an \"Information Bottleneck\" optimization task. The IR produced traverses an abstract syntax tree to determine names and types of identifiers. The identifier naming process employs sequence-to-sequence training followed by reinforcement learning to aligh the outputs with compiler preference and type constraints.\n\nSection 4 covers the evaluation. Exebench is used as training data. The evaluation compares against three other decompilers: GPT5-mini, LLM4Decompile, and Idioms. The evaluation benchmarks used are HumanEval and MBPP. The evaluation metrics used include re-executability rate, the relative readability metric for decompiled code R2I, and GPT-Judge, a score between 1 and 5 reflecting the meaningfulness of variable names. The results mark SK2Decompile as winner in almost all cases. An abblation study illustrates the need for all components (src, ir, and rl). Lastly, the naming benefits are illustrated on a dedicated case.", "questions": "- Why are there no re-executability results for exebench? Doesn't it come with a test suite? I don't understand the remark about stripping blocking this on p.6.\n- Nova (and other models) are easily dismissed as they do not \"provide details about their data preprocessing approaches or do not release their models\" -- but I'm not convinced by this -- what is the best you can do?", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "- LLM4Decompile and Idioms are adequate baselines to compare against\n- The results show good performance\n- The abblation illustrates the need of the various components\n- Meaningful ethics statement", "weaknesses": "- Unclear why re-executability results are limited to just two benchmarks\n- HumanEval is a dataset that is not representative for actual decompilation problems -- the only justification can be that it is used in earlier studies.\n- I would expect a feedback loop trying to fix errors could improve reproducibility. This could be separately discussed\n- The 'case study' is not a case study in a methodological meaning of the word. Is a useful illustration, but not a critical qualitative assessment of the capabilities of the approach proposed.\n- I would like to see a more critical (qualitative) assessments of cases not properly handled by SK2Decompile, in order to identify challenges the research community should focus on next", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "aTe4WPMJ7H", "reviewer": "Reviewer_CTua", "summary": "The paper introduces SK2Decompile, a two phase binary decompilation strategy for binary lifting. The first phase focuses on lifting to the \"skeleton\" of the code, at the IR level, followed by the second phase which aims to provide structured recovery of meaningful identifiers in the actual program semantics. The authors employ both language models and RL for their approach, and the tool is evaluated on multiple benchmarks, and compared to other LLM lifters.", "questions": "While the idea is good, the baseline for evaluation is quite underwhelming to this reviewer. Instead of a \"basic\" benchmark suite such as HumanEval and others, how would such a tool perform on a larger and more realistic codebase, such as BringUpBench?\n\nAdditionally, modern rule-based lifters actually perform quite well on \"simple\" benchmarks such as HE, but struggle against more complex benchmarks. This is true for McToll and a few others. That said, McToll does surprisingly well HumanEval-like benchmarks, which to me indicates that should be the best baseline available, not GPT-5-Mini. If SK2Decompile (or other LLM-based lifters for that matter) do not match McToll level accuracy, then their contribution is questionable.\n\nOn the flip side, BringUpBench is also challenging from a rule-based approach: how does SK2Decompile (and other lifters) perform on such a benchmark suite?\n\nTo summarize:\n- The idea is quite interesting (splitting the decompilation into two phases); however, the evaluation is not well executed given the comparison points (there was no rule-based technique), and the benchmarks are simple.\n- If the authors are able to generate results on BringUpBench-level complexity with their tool, I would increase my score. \n- How does this tool fare compared to rule-based tools, such as McToll, when it comes to re-compilation. \n\nI will say that the R2I and GPT-Judge results are interesting; but practically speaking the recompilation is what is very interesting to this reviewer, as that opens the door for lots of future directions in binary modifications and optimizations.", "limitations": "", "rating": 4, "confidence": 5, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "+ Important, established problem, with lots of headroom for innovation\n+ The 2-phase approach is quite interesting, and I appreciated that contribution", "weaknesses": "- The baseline is not strong: none of the proposed benchmarks are \"realistic\" in their complexity nor size, which makes me question the feasibility of this technique to generalize beyond the studied benchmarks.\n- There are no rule-based tools being compared. In particular, McToll is a well respected tool for decompilation, and I'd be very curious to see how it performs relative to SK2Decompile. This is important, because while LLMs are useful tools, rule-based tools should really be considered state-of-the-art here (as that is what they are replacing), not just other LLM lifters.\n- No true analysis on what fails and what doesn't fail in the decompilation process (some explainability). The ablation study helps explain where some of the performance improvements arise, but does not give practical description of what programs failed to lift, and why that was the case.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "gPZ7jQivql", "reviewer": "Reviewer_e7pk", "summary": "The paper tackles binary decompilation. Traditional tools like Ghidra or IDA produce code that works but is hard to read. LLM-based decompilers make code readable but often wrong.\n\nSK2Decompile proposes a 2-phase approach:\n- Structure Recovery (“skeleton”): translate binary into IR that keeps control flow but with placeholder symbols. \n- Identifier Naming (“skin”): fills in meaningful names for the symbols.\n\nBoth phases use RL. The reward of the phase 1 is IR compilability + structural corectness. Phase 2 is rewarded if the predicted identifiers are semantically similar)\n\nThe method improves both functional correctness and readability independently. Results show large gains over prior systems (GPT-5-mini, LLM4Decompile).", "questions": "Do you have any intuition on how GPT-Judge works for decompilation? What criteria does the model seem to be using?\n\nHow robust is SK2Decompile to compiler obfuscations or optimizations beyond O3?\n\nCan the same IR concept be used cross-language (e.g., C++, Rust)? And with other assembly yargets?\n\nHow much of the gain comes from RL versus just having a cleaner IR target?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 2, "presentation": 2, "contribution": 3, "strengths": "- Reproducibility effort.\n- Clever and clear conceptual decomposition in 2 different parts. Well-motivated.\n- Interesting and well-principled use of the information bottleneck principle.\n- Comprehensive evaluations, and ablation study. Different optimization levels evaluated, diverse benchmarks.\n- Very strong quantitative results.", "weaknesses": "- The 2-level decomposition of decompilation is not novel. The particular implementation is. I don't think the paper itself makes a good job at clarifying these 2 levels. E.g., https://arxiv.org/abs/2103.12801,\n- Limited scope in languages and targets.\n- Algorithm 1 could better specify how “names to preserve” FP are determined automatically.\n- Minor: the paper could greatly improve in clarity with the help of some diagrams.\n\nNits: \n- some citations are incorrectly formatted. \n- Incorrect spacing in some footnote marks.\n- “find out it achieves” → “find that it achieves.”\n-  “we analogize … to the human body” -> “we draw an analogy.”\n- Inconsistencies in capitalization of “Re-Executability” vs “Re-executability.”", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "1rZFnCQjCx", "reviewer": "Reviewer_v9Us", "summary": "SK2Decompile proposes a two-phase LLM-based decompilation framework that separately reconstructs:\n\n1. Program structure (skeleton) via Structure Recovery from binary to IR.\n\n2. Identifier semantics (skin) via Identifier Naming from IR to human-readable source code.\n\nBoth phases are fine-tuned with reinforcement learning (RL):\n\n1. Structure Recovery RL uses compiler feedback and placeholder accuracy.\n\n2. Identifier Naming RL uses semantic cosine similarity between generated and reference code embeddings.", "questions": "- RL reward design & potential leakage:\nYou “provide the compiler with the header of the ground-truth IR” to check compilability and grant reward.\n• Can you quantify how much this leaks structure/type information compared to a realistic setting?\n• Please add an ablation with no ground truth headers and report re-executability/R2I deltas.\n\n- RL stability, sensitivity, and cost:\nYou apply GRPO on 50k samples due to compute limits but report no convergence/variance details.\n• Please provide training curves (reward, validation re-exec/R2I) and GPU hours, and batch/length constraints.\n• Any reward hacking observed?\n\n- Naming reward via a single embedding model: Identifier Naming uses cosine similarity with qwen-embedding-0.6B\n• How sensitive are results to the embedding choice? Please compare against alternative code/text-code embeddings and report correlation with identifier-level F1 and human ratings.", "limitations": "", "rating": 8, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "Originality\n\n* Two-phase “skeleton→skin” formulation reduces a monolithic task to two focused ones. \n* IR defined as obfuscated source, motivated by the Information Bottleneck (compression vs relevance). \n* Phase-specific RL: compiler/placeholder Jaccard for structure; embedding cosine for naming/readability. \n\nQuality\n\n* Clear IR generation algorithm and training details (SFT→GRPO RL).\n* Strong, multi-metric benchmarks (re-executability, R2I, GPT-Judge) across diverse suites. \n* SOTA gains (e.g., +21.6% re-exec on HumanEval; +29.4% R2I on GitHub2025) with solid ablations isolating where gains come from. \n\n Clarity\n\n* Effective figures (motivation, framework, case study) and precise math/rewards. \n* Reproducibility statement and artifact release. \n\nSignificance\n\n* Practical impact: higher re-executability/readability; paradigm likely transferable to other program-recovery tasks.", "weaknesses": "Experimental coverage\n\n1. Architecture/compiler diversity is narrow. All binaries are x86/Linux; no ARM/MIPS, MSVC/Windows, or ICC variants. This limits generalization. Action: add cross-architecture (ARM64) and cross-compiler (MSVC) evaluations; report deltas by ISA/ABI and OS. \n2. Language scope is mostly C/C-like. No results for Rust/Go/C++ templates where type systems and naming semantics differ. Action: evaluate at least one non-C family (Rust, Go) and modern C++ (templates/RAII) to test Identifier Naming generality. \n\nBaselines & fairness\n\nNo head-to-head with classic de-compilers. Action: add side-by-side comparisons (functional pass rate, R2I, blinded human readability) using Ghidra/Hex-Rays outputs to contextualize LLM gains.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)