Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Idioms: Neural Decompilation With Joint Code and Type Definition Prediction

T0 review · 4 major / 6 minor · reviewed 2026-08-08 · deepseek-v4-flash

Pith's one-line read This paper claims that predicting code and user-defined type definitions jointly, with neighboring functions as context, makes neural decompilers far more accurate on realistic code, and introduces the REALTYPE dataset and IDIOMS models…

desk verdict Solid empirical contribution—joint code+UDT prediction and a new benchmark—but the headline gains over baselines are partly confounded by using different decompiler front-ends. read the letter →

arxiv 2502.04536 v2 pith:PFQWWAWT submitted 2025-02-06 cs.SE cs.CR

classification cs.SEcs.CR
keywords neuraldecompilationuser-definedtypestyperecoverylargelanguagemodelscallgraphcontextREALTYPEdatasetprogramequivalencesecurityanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Neural decompilers promise to recover readable source from binaries, but existing ones stop short: they predict names and even struct field accesses without the type definitions that make those fields meaningful. This paper argues that code and user-defined type definitions must be reconstructed together, since each constrains the other, and that the evidence for a type is scattered across multiple functions. The authors build REALTYPE, a dataset of compiled C functions from real projects with complex structs and unions, and IDIOMS, a finetuning strategy that makes any LLM produce both the function body and the full type definitions in one pass, while reading neighboring functions from the call graph as context. On ExeBench, IDIOMS passes 54.4% of unit tests versus 46.3% for LLM4Decompile and 37.5% for Nova; on REALTYPE, it scores 95-205% higher on correctness metrics. If the claim holds, reverse engineers would finally get decompiled code whose memory layouts are known and analyzable.

What carries the argument

The load-bearing mechanism is a single training sequence that concatenates three blocks: (1) the decompiled body of the target function, (2) the decompiled bodies of its graph neighbors, added breadth-first until the context window fills, and (3) a separator followed by the original source plus the definitions of all user-defined types it uses. Because a causal language model predicts each output token from every preceding token, the type definitions are generated while the code that accesses their fields is still in context, forcing joint consistency. The REALTYPE dataset supplies the paired examples and the call graphs needed for this construction.

What would settle it

Recompute the REALTYPE comparisons under the stricter dependency-equivalence metric that requires structural type agreement, and check whether IDIOMS still beats LLM4Decompile and Nova by a wide margin; if the gap closes, the 95-205% advantage is an artifact of the permissive consistency rule.

Watch

Extended reading notes

Core claim

The paper's central claim is that neural decompilation is a joint prediction problem: the original code of a function and the complete definitions of every user-defined type it uses must be generated in the same autoregressive sequence. The IDIOMS training scheme feeds the model the decompiled target function followed by the decompiled bodies of its callers and callees, in breadth-first order from the target, then asks it to generate the ground-truth function and the full type definitions. This makes field names and their uses mutually consistent, something sequential type recovery cannot achieve. The paper reports that IDIOMS beats prior neural decompilers by 17-36% on ExeBench correctness metrics and by 95-205% on REALTYPE, the new dataset with realistic user-defined types, and that the gains hold across model sizes and base LLMs.

Load-bearing premise

The headline comparisons rest on the relaxed dependency-equivalence metric, which treats any bijective renaming of struct fields as equivalent; if that permissive standard overstates semantic fidelity, the reported advantage over prior decompilers shrinks.

Editorial extensions

If this is right

  • Joint code and type prediction makes neural decompiler output compilable and usable for static analysis, because field offsets and layouts are actually defined.
  • The method is model-agnostic: finetuning any code LLM with the same sequence construction transfers the gains, so further improvements in base models should compound.
  • Benchmarks without substantial user-defined types overstate decompiler quality; REALTYPE's difficulty shift (strict equivalence drops 55-68%) shows that realistic UDTs are the real bottleneck.
  • Neighboring call-graph context improves type recovery with little downside, especially for larger models, suggesting context rather than architecture is the key lever.
  • The O1 drop and plateau at higher optimizations indicates optimization is a distinct obstacle that joint training only partially addresses.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the permissive metric masks weaker true equivalence, a stricter type-preserving metric would give a conservative lower bound; readers should check both before relying on the gap.
  • The same joint sequence idea could be applied to reconstruction of data structures in other lossy settings—such as stripped non-C binaries or obfuscated code—where scattered evidence across functions is the bottleneck.
  • A natural next experiment is to combine the joint prediction with assembly-level input to see whether type consistency and raw-code context are complementary.
  • The dataset's deduplication and by-project split set a strong precedent for leakage-resistant benchmarks in binary analysis, and could be reused for other tasks.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper introduces IDIOMS, a family of neural decompilers that fine-tune causal language models to jointly predict decompiled C function bodies and complete user-defined type (UDT) definitions. It also introduces REALTYPE, a new dataset of 154,301 training and 2,862 evaluation functions mined from GitHub with substantially more complex UDTs than existing benchmarks. The evaluation compares IDIOMS against LLM4Decompile and Nova on EXEBENCH and REALTYPE using unit-test accuracy, dependency-based equivalence, a newly introduced relaxed dependency-equivalence (consistency) metric, and several code/type quality metrics. The paper reports state-of-the-art results, with the largest gains on REALTYPE, and presents ablations showing that realistic UDTs make decompilation harder and that neighboring call-graph context improves UDT reconstruction, especially for larger models.

Significance. If the reported results hold, the paper makes a strong contribution: it identifies a real limitation of prior neural decompilation benchmarks (near-absence of complex UDTs), contributes a new dataset that addresses it, and proposes a sensible joint code-plus-UDT prediction formulation. The release of code, models, and the REALTYPE dataset is valuable for future work. The experimental design also has notable strengths: aggressive deduplication via minhashing and project-level splits, removal of function names to avoid leakage, and re-decompilation of test sets for LLM4Decompile to avoid a covariate shift for that baseline. However, the central external-comparison claim is currently undermined by a decompiler front-end confound that the paper itself acknowledges in passing, and by the absence of any variance estimates. These issues are fixable and do not invalidate the internal ablations, but they must be addressed before the state-of-the-art claim can be accepted.

major comments (4)
  1. [Section 3.1, Table 2, Section 4.1] The headline comparisons are confounded by the decompiler front-end. IDIOMS is evaluated on Hex-Rays output, while LLM4Decompile is evaluated on Ghidra output, and the authors explicitly state in Section 4.1 that 'anecdotally, we find Hex-Rays’ output to be better than Ghidra’s.' Because the input format differs between the two models, the reported gaps (e.g., 54.4 vs 46.3 on EXEBENCH tests, and 'at least 95% better' on REALTYPE relaxed dependency-equivalence) may partly reflect the quality of the input decompiler rather than the joint code-plus-UDT formulation. A controlled comparison, such as training or fine-tuning IDIOMS on Ghidra output or evaluating LLM4Decompile on Hex-Rays output, is needed to support the state-of-the-art claim.
  2. [Tables 2 and 3 (all result tables)] All results are reported as point estimates with no error bars, confidence intervals, or multiple seeds. Several headline gaps are modest relative to the likely variance; for example, Table 2a shows relaxed dependency-equivalence on EXEBENCH of 34.1 for IDIOMS versus 27.9 for LLM4Decompile, a 6.2-point gap, and Table 2d shows 54.4 versus 46.3 on EXEBENCH unit tests. Without repeated runs or significance testing, the claim that IDIOMS is state-of-the-art is not statistically supported. Reporting variance across at least three seeds, or bootstrap confidence intervals, is necessary.
  3. [Section 3.3, Table 2 (optimization-level results)] The Ghidra test sets for the compiler optimization comparison are non-uniform and potentially biased. The authors filter to functions that successfully decompiled at all levels (O0–O3), which removes 76% of Ghidra-decompilable functions, and then use the intersection of Hex-Rays-decompilable and Ghidra-decompilable functions for the LLM4Decompile evaluation. This selective filtering can change the difficulty of the evaluation subset in a way that affects the comparison. The statement that 'as these are test sets, not training, the impact on results is negligible' needs justification; the composition of a test set directly influences measured accuracy, and a harder or easier subset for one baseline can distort the relative ranking.
  4. [Section 4.1, Section 3.1] The baselines are evaluated under a covariate shift on function names. LLM4Decompile and Nova were trained with function names present in the decompiled input, according to the paper's own discussion, but the evaluation canonicalizes names to funcX and removes them from the input. The paper reasonably argues that this is the realistic reverse-engineering setting, but the consequence is that the baselines are not evaluated under their training distribution, while IDIOMS is evaluated on its training distribution. To make a fair algorithm comparison, the baselines should be adapted (for example, fine-tuned on name-removed inputs) or the results should be framed as a comparison under a new realistic condition with the explicit caveat that the prior methods were not retrained.
minor comments (6)
  1. [Section 3.2.1, Table 2c] The metric name 'strict dependency-equivalentce' in Table 2c and in the metric list contains a typo; it should be 'strict dependency-equivalence.'
  2. [Section 3.2.1] The definition of the relaxed dependency-equivalence (consistency) metric is informal. The example illustrates a bijective mapping between field names for a single expression, but it is not specified whether the bijection must be global and consistent across all mapped nodes in the entire function, nor how nested field accesses (e.g., a->b->c) are handled. A precise formal definition would improve reproducibility.
  3. [Section 2.2] The phrase 'so it can be conflidently split' contains a typo; it should be 'confidently.'
  4. [Section 4.1] The word 'reults' in the first sentence of Section 4.1 should be 'results.'
  5. [Abstract, Section 4.1] The claim that the model 'performs at least 95% better' on REALTYPE is not tied to a specific metric and optimization level. Table 2a shows that this figure corresponds to the smallest relative gap in relaxed dependency-equivalence at O0; specifying the metric and the optimization level would make the abstract claim clearer.
  6. [Figure 3] The sequence layout in Figure 3 uses symbols such as '•' and a 'name-indicator token' without defining them in the caption or the surrounding text; the figure is difficult to interpret as a result.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: Idioms' headline results are empirical comparisons against external baselines and ExeBench's unit tests; the authors' self-cited equivalence checker is a symmetric, code-released oracle, not a fitted input, and the Hex-Rays/Ghidra asymmetry is an external-validity confound rather than a definitional reduction.

full rationale

The paper contains no derivation chain in the sense of equations whose outputs equal their inputs by construction; it is an empirical ML systems paper. The strongest SOTA claim is anchored to ExeBench's externally supplied unit-test accuracy (Table 2d: 54.4 vs. 46.3 vs. 37.5), which is independent of the authors' evaluation tools. On the self-built Realtype benchmark, the 'at least 95% better' claim rests on relaxed dependency-equivalence (Table 2a, e.g., 32.3 vs. 16.6 at O0); this metric is defined in Section 3.2.1 and is applied identically to Idioms, LLM4Decompile, and Nova, and its bijective-renaming rule does not encode Idioms's outputs. Realtype's ground truth is extracted from original preprocessed source code, not from Idioms's predictions. The dependency-equivalence checker is cited from the authors' prior work [31], but it is a parameter-free, code-released oracle with stated caveats (side effects, type correctness) and is not fitted to the target result, so under the review rules it counts as real evidence rather than a circular self-citation. The dataset, metric, and model are all created by the same team, which is a self-evaluation risk, but no prediction is the renaming of a fitted parameter. The most serious validity threat is the input-format asymmetry: Section 3.1 says LLM4Decompile is evaluated on Ghidra output while Idioms uses Hex-Rays, and Section 4.1 concedes 'anecdotally, we find Hex-Rays' output to be better than Ghidra's.' That is a measurement confound that could change the magnitude of the reported gaps, but it does not make the claims equivalent to their inputs. Score 2 reflects the minor author-overlapping evaluation components ([13], [31]) without treating them as load-bearing circularity.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim rests on the quality of the Realtype dataset, the validity of the equivalence metrics, and the choice of hyperparameters for finetuning. No new physical entities are introduced; the new artifacts are a dataset, a metric, and a family of models. The main free parameters are training hyperparameters and context window sizes, chosen by hand rather than fitted to the evaluation data.

free parameters (6)
  • Context window: IDIOMS = 4096 tokens
    Chosen by hand; determines how many neighboring functions fit in the prompt.
  • Context window: function-context models = 2048 tokens
    Chosen by hand; used for ablations and baselines.
  • Output token budget = 1024 tokens
    Chosen by hand; reserves space for original code and UDT definitions.
  • Learning rate = 5e-5
    Chosen by hand for cosine schedule finetuning.
  • Batch size = 64
    Chosen by hand for finetuning.
  • Epochs by model size = 8 (CodeQwen-0.5b), 2 (1-2b), 1 (7b)
    Chosen by hand; larger models converge faster.
assumptions (5)
  • domain assumption The dependency graph isomorphism is a sound approximation of program equivalence for decompilation evaluation.
    Used in Section 3.2.1 to define the main correctness metrics; relies on prior work [31], [32].
  • domain assumption The Realtype dataset is representative of real-world C code with user-defined types.
    The paper mines GitHub repositories that compile; malware and obfuscated binaries are excluded (Section 5).
  • domain assumption Ghidra and Hex-Rays decompiler outputs are a suitable input representation for neural decompilation.
    The approach is evaluated only on these decompilers; the paper excludes functions that fail to decompile (Section 3.1).
  • domain assumption Deduplication via minhashing and by-project splitting prevents training/evaluation leakage.
    Described in Section 2.2; leakage would inflate accuracy.
  • domain assumption Type canonicalization (e.g., int32_t to int) does not materially affect evaluation, because all experiments use x86-64 Linux with GCC.
    Stated in footnote 2; this normalization makes type matching easier.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Idioms: Neural Decompilation With Joint Code and Type Definition Prediction." pith.science (2026). https://pith.science/paper/PFQWWAWT

@misc{pith2026250204536,
  author       = {Pith},
  title        = {Pith review of: Idioms: Neural Decompilation With Joint Code and Type Definition Prediction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PFQWWAWT}},
  note         = {Machine review of arXiv:2502.04536}
}
read the original abstract

Decompilers are important tools for reverse engineers that help them analyze software at a higher level of abstraction than assembly code. Unfortunately, because compilation is lossy, deterministic decompilers produce code that is missing many of the details that make source code readable in the first place, like variable names and types. Neural decompilers, on the other hand, offer the ability to statistically fill in these details. Existing work in neural decompilation, however, suffers from substantial limitations that preclude its use on real code, such as the inability to define composite types, which is essential to fully specify function semantics. In this work, we introduce a new dataset, Realtype, that includes substantially more complicated and realistic types than existing neural decompilation benchmarks, and Idioms, a new neural decompilation approach to finetune any LLM into a neural decompiler capable of generating the appropriate user-defined type definitions alongside the decompiled code. We show that our approach yields state-of-the-art results in neural decompilation. On the most challenging existing benchmark, ExeBench, our model achieves 54.4% accuracy vs. 46.3% for LLM4Decompile and 37.5% for Nova; on Realtype, our model performs at least 95% better.

Figures

Figures reproduced from arXiv: 2502.04536 by the authors.

Figure 1
Figure 1. A function with two user-defined types and different decompilations of it. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Our high-level approach. We use our dataset, [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Organization of the model training sequences. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: A function which computes a variant of a polyno [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: IDIOMS-functions’ prediction when given Fig￾ure 1b as input. The lack of additional context causes a sub￾tle but substantial difference relative to the original source. The version produced with neighboring context (Figure 1d) is correct. dependency-equivalence, respec…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Evaluating Fine-Tuning and Metrics for Neural Decompilation of Dart AOT Binaries

    cs.SE 2026-07 accept novelty 6.0 of 10

    Fine-tuning small LLMs for Dart decompilation yields no functional improvement and surface metrics can diverge from correctness.

Reference graph

Works this paper leans on

48 extracted references · 35 canonical work pages · cited by 1 Pith paper

  1. [1]

    Dire: A neural approach to decompiled identifier naming,

    J. Lacomis, P. Yin, E. Schwartz, M. Allamanis, C. Le Goues, G. Neubig, and B. Vasilescu, “Dire: A neural approach to decompiled identifier naming,” in2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2019, pp. 628– 639

  2. [2]

    Direct: A transformer- based model for decompiled variable name recovery,

    V . Nitin, A. Saieva, B. Ray, and G. Kaiser, “Direct: A transformer- based model for decompiled variable name recovery,”NLP4Prog 2021, p. 48, 2021

  3. [3]

    ” len or index or count, anything but v1

    K. K. Pal, A. P. Bajaj, P. Banerjee, A. Dutcher, M. Nakamura, Z. L. Basque, H. Gupta, S. A. Sawant, U. Anantheswaran, Y . Shoshi- taishviliet al., “” len or index or count, anything but v1”: Predicting variable names in decompilation output with transfer learning,” in 2024 IEEE Symposium on Security and Privacy (SP). IEEE Com- puter Society, 2024, pp. 152–152

  4. [4]

    Neural reverse engineering of stripped binaries using augmented control flow graphs,

    Y . David, U. Alon, and E. Yahav, “Neural reverse engineering of stripped binaries using augmented control flow graphs,”Proceedings of the ACM on Programming Languages, vol. 4, no. OOPSLA, pp. 1–28, 2020

  5. [5]

    Symlm: Predicting function names in stripped binaries via context-sensitive execution-aware code embeddings,

    X. Jin, K. Pei, J. Y . Won, and Z. Lin, “Symlm: Predicting function names in stripped binaries via context-sensitive execution-aware code embeddings,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 1631–1645

  6. [6]

    A transformer-based function symbol name inference model from an assembly language for binary reversing,

    H. Kim, J. Bak, K. Cho, and H. Koo, “A transformer-based function symbol name inference model from an assembly language for binary reversing,” inProceedings of the 2023 ACM Asia Conference on Computer and Communications Security, 2023, pp. 951–965

  7. [7]

    Finding the dwarf: recovering precise types from webassembly binaries,

    D. Lehmann and M. Pradel, “Finding the dwarf: recovering precise types from webassembly binaries,” inProceedings of the 43rd ACM SIGPLAN International Conference on Programming Language De- sign and Implementation, 2022, pp. 410–425

  8. [8]

    Osprey: Recovery of variable and data structure via probabilistic analysis for stripped binary,

    Z. Zhang, Y . Ye, W. You, G. Tao, W.-c. Lee, Y . Kwon, Y . Aafer, and X. Zhang, “Osprey: Recovery of variable and data structure via probabilistic analysis for stripped binary,” in2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 813–832

Show all 48 references
  1. [9]

    {TYGR}: Type inference on stripped binaries using graph neural networks,

    C. Zhu, Z. Li, A. Xue, A. P. Bajaj, W. Gibbs, Y . Liu, R. Alur, T. Bao, H. Dai, A. Doup ´eet al., “{TYGR}: Type inference on stripped binaries using graph neural networks,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 4283–4300

  2. [10]

    Augmenting decompiler output with learned variable names and types,

    Q. Chen, J. Lacomis, E. J. Schwartz, C. Le Goues, G. Neubig, and B. Vasilescu, “Augmenting decompiler output with learned variable names and types,” in31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 4327–4343

  3. [11]

    Hext5: Unified pre-training for stripped binary code information inference,

    J. Xiong, G. Chen, K. Chen, H. Gao, S. Cheng, and W. Zhang, “Hext5: Unified pre-training for stripped binary code information inference,” in2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 774–786

  4. [12]

    Resym: Harnessing llms to recover variable and data structure symbols from stripped binaries,

    D. Xie, Z. Zhang, N. Jiang, X. Xu, L. Tan, and X. Zhang, “Resym: Harnessing llms to recover variable and data structure symbols from stripped binaries,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 4554–4568

  5. [13]

    A taxonomy of c decompiler fidelity issues,

    L. Dramko, J. Lacomis, E. J. Schwartz, B. Vasilescu, and C. Le Goues, “A taxonomy of c decompiler fidelity issues,” in33th USENIX Security Symposium (USENIX Security 24), 2024

  6. [14]

    Nova+: Generative language models for binaries,

    N. Jiang, C. Wang, K. Liu, X. Xu, L. Tan, and X. Zhang, “Nova+: Generative language models for binaries,”arXiv preprint arXiv:2311.13721, 2023

  7. [15]

    Degpt: Optimizing decompiler output with llm,

    P. Hu, R. Liang, and K. Chen, “Degpt: Optimizing decompiler output with llm,” 2024

  8. [16]

    LLM4Decompile: Decompiling binary code with large language models,

    H. Tan, Q. Luo, J. Li, and Y . Zhang, “LLM4Decompile: Decompiling binary code with large language models,” inProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, Y . Al-Onaizan, M. Bansal, and Y .-N. Chen, Eds. Miami, Florida, USA: Associatio...

  9. [17]

    An observational investigation of reverse engineers’ processes,

    D. V otipka, S. Rabin, K. Micinski, J. S. Foster, and M. L. Mazurek, “An observational investigation of reverse engineers’ processes,” in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 1875–1892

  10. [18]

    Type inference on executables,

    J. Caballero and Z. Lin, “Type inference on executables,”ACM Comput. Surv., vol. 48, no. 4, May 2016. [Online]. Available: https://doi.org/10.1145/2896499

  11. [19]

    Slade: A portable small language model decompiler for optimized assembly,

    J. Armengol-Estap ´e, J. Woodruff, C. Cummins, and M. F. O’Boyle, “Slade: A portable small language model decompiler for optimized assembly,” in2024 IEEE/ACM International Symposium on Code Generation and Optimization (CGO), 2024, pp. 67–80

  12. [20]

    Exebench: an ml-scale dataset of executable c functions,

    J. Armengol-Estap ´e, J. Woodruff, A. Brauckmann, J. W. d. S. Magalh˜aes, and M. F. P. O’Boyle, “Exebench: an ml-scale dataset of executable c functions,” inProceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming, ser. MAPS 2022. New York, NY , USA: A...

  13. [21]

    Using recurrent neural networks for decompilation,

    D. S. Katz, J. Ruchti, and E. Schulte, “Using recurrent neural networks for decompilation,” inIEEE International Conference on Software Analysis, Evolution and Reengineering, 4 2018, pp. 346– 356

  14. [22]

    Coda: An end-to-end neural program decompiler,

    C. Fu, H. Chen, H. Liu, X. Chen, Y . Tian, F. Koushanfar, and J. Zhao, “Coda: An end-to-end neural program decompiler,”Advances in Neural Information Processing Systems, vol. 32, 2019

  15. [23]

    Boosting neural networks to decompile optimized binaries,

    Y . Cao, R. Liang, K. Chen, and P. Hu, “Boosting neural networks to decompile optimized binaries,” inProceedings of the 38th Annual Computer Security Applications Conference, 2022, pp. 508–518

  16. [24]

    Beyond the c: Retargetable decom- pilation using neural machine translation,

    I. Hosseini and B. Dolan-Gavitt, “Beyond the c: Retargetable decom- pilation using neural machine translation,” 2022

  17. [25]

    Z. Hu. (2021) Ghcc. [Online]. Available: https://github.com/ huzecong/ghcc

  18. [26]

    A dataset for github repository deduplication,

    D. Spinellis, Z. Kotti, and A. Mockus, “A dataset for github repository deduplication,” inProceedings of the 17th international conference on mining software repositories, 2020, pp. 523–527

  19. [27]

    On the resemblance and containment of documents,

    A. Z. Broder, “On the resemblance and containment of documents,” inProceedings. Compression and Complexity of SEQUENCES 1997 (Cat. No. 97TB100171). IEEE, 1997, pp. 21–29

  20. [28]

    The stack: 3 tb of permissively licensed source code,

    D. Kocetkov, R. Li, L. Ben Allal, J. Li, C. Mou, C. Mu ˜noz Ferrandis, Y . Jernite, M. Mitchell, S. Hughes, T. Wolf, D. Bahdanau, L. von Werra, and H. de Vries, “The stack: 3 tb of permissively licensed source code,”Preprint, 2022

  21. [29]

    The pile: An 800gb dataset of diverse text for language modeling,

    L. Gao, S. Biderman, S. Black, L. Golding, T. Hoppe, C. Foster, J. Phang, H. He, A. Thite, N. Nabeshimaet al., “The pile: An 800gb dataset of diverse text for language modeling,”arXiv preprint arXiv:2101.00027, 2020

  22. [30]

    The curious case of neural text degeneration,

    A. Holtzman, J. Buys, L. Du, M. Forbes, and Y . Choi, “The curious case of neural text degeneration,”arXiv preprint arXiv:1904.09751, 2019

  23. [31]

    Fast, fine- grained equivalence checking for neural decompilers,

    L. Dramko, C. Le Goues, and E. J. Schwartz, “Fast, fine- grained equivalence checking for neural decompilers,”arXiv preprint arXiv:2501.04811, 2025

  24. [32]

    Detecting program components with equivalent behaviors,

    W. Yang, S. Horwitz, and T. Reps, “Detecting program components with equivalent behaviors,” University of Wisconsin-Madison Depart- ment of Computer Sciences, Tech. Rep., 1989

  25. [33]

    Codegemma: Open code models based on gemma,

    C. Team, H. Zhao, J. Hui, J. Howland, N. Nguyen, S. Zuo, A. Hu, C. A. Choquette-Choo, J. Shen, J. Kelleyet al., “Codegemma: Open code models based on gemma,”arXiv preprint arXiv:2406.11409, 2024

  26. [34]

    Qlora: Efficient finetuning of quantized llms,

    T. Dettmers, A. Pagnoni, A. Holtzman, and L. Zettlemoyer, “Qlora: Efficient finetuning of quantized llms,”Advances in Neural Informa- tion Processing Systems, vol. 36, 2024

  27. [35]

    Qwen2. 5-coder technical report,

    B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Luet al., “Qwen2. 5-coder technical report,”arXiv preprint arXiv:2409.12186, 2024

  28. [36]

    Code llama: Open foundation models for code,

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remezet al., “Code llama: Open foundation models for code,”arXiv preprint arXiv:2308.12950, 2023

  29. [37]

    Binary code summarization: Benchmarking chatgpt/gpt-4 and other large language models,

    X. Jin, J. Larson, W. Yang, and Z. Lin, “Binary code summarization: Benchmarking chatgpt/gpt-4 and other large language models,”arXiv preprint arXiv:2312.09601, 2023

  30. [38]

    Cadecff: Compiler- agnostic deobfuscator of control flow flattening,

    W. Dong, J. Lin, R. Chang, and R. Wang, “Cadecff: Compiler- agnostic deobfuscator of control flow flattening,” inProceedings of the 13th Asia-Pacific Symposium on Internetware, 2022, pp. 282–291

  31. [39]

    Deobfuscation of virtualization- obfuscated software: a semantics-based approach,

    K. Coogan, G. Lu, and S. Debray, “Deobfuscation of virtualization- obfuscated software: a semantics-based approach,” inProceedings of the 18th ACM conference on Computer and communications security, 2011, pp. 275–284

  32. [40]

    Qsynth-a program syn- thesis based approach for binary code deobfuscation,

    R. David, L. Coniglio, M. Ceccatoet al., “Qsynth-a program syn- thesis based approach for binary code deobfuscation,” inBAR 2020 Workshop, 2020

  33. [41]

    Deobfuscation of virtualization-obfuscated code through symbolic execution and com- pilation optimization,

    M. Liang, Z. Li, Q. Zeng, and Z. Fang, “Deobfuscation of virtualization-obfuscated code through symbolic execution and com- pilation optimization,” inInformation and Communications Security: 19th International Conference, ICICS 2017, Beijing, China, Decem- ber 6-8, 2017, Proce...

  34. [42]

    Dose: Deobfuscation based on semantic equivalence,

    R. Tofighi-Shirazi, M. Christofi, P. Elbaz-Vincent, and T.-H. Le, “Dose: Deobfuscation based on semantic equivalence,” inProceed- ings of the 8th Software Security, Protection, and Reverse Engineering Workshop, 2018, pp. 1–12

  35. [43]

    Deoptfuscator: Defeating advanced control-flow obfuscation using android runtime (art),

    G. You, G. Kim, S. Han, M. Park, and S.-J. Cho, “Deoptfuscator: Defeating advanced control-flow obfuscation using android runtime (art),”IEEE Access, vol. 10, pp. 61 426–61 440, 2022

  36. [44]

    Attention is all you need,

    A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. u. Kaiser, and I. Polosukhin, “Attention is all you need,” inAdvances in Neural Information Processing Systems, I. Guyon, U. V . Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnet...

  37. [45]

    Tie: Principled reverse engi- neering of types in binary programs,

    J. Lee, T. Avgerinos, and D. Brumley, “Tie: Principled reverse engi- neering of types in binary programs,” 2011

  38. [46]

    Automatic reverse engineering of data structures from binary execution,

    Z. Lin, X. Zhang, and D. Xu, “Automatic reverse engineering of data structures from binary execution,” inProceedings of the 11th Annual Information Security Symposium, 2010

  39. [47]

    Howard: A dynamic excavator for reverse engineering data structures

    A. Slowinska, T. Stancescu, and H. Bos, “Howard: A dynamic excavator for reverse engineering data structures.” inNetwork and Distributed System Security Symposium (NDSS), 2011

  40. [48]

    Sgdr: Stochastic gradient descent with warm restarts,

    I. Loshchilov and F. Hutter, “Sgdr: Stochastic gradient descent with warm restarts,”arXiv preprint arXiv:1608.03983, 2016. Appendix We used the following conventions for training models in our experiments. When training on the full compilable partition of theEXEBENCHdataset (f...

Pith tools

Reviewed August 8, 2026 · model on record in the stance chip above.