pith. machine review for the scientific record. sign in

arxiv: 2605.02121 · v1 · submitted 2026-05-04 · 💻 cs.CR · cs.SE

Recognition: 1 theorem link

SCRIBE: Practical Static Binary Patching via Binary-Aware Recompilation of Decompiled Code

Han Dai , Soumyakant Priyadarshan , Abdullah Imran , Ruoyu Wang , Antonio Bianchi
Authors on Pith no claims yet

Pith reviewed 2026-05-08 18:53 UTC · model grok-4.3

classification 💻 cs.CR cs.SE
keywords binary patchingdecompilationstatic binary analysisvulnerability remediationrecompilationbinary rewritingdecompiler inaccuraciesCVE patching
0
0 comments X

The pith

Decompiled binaries can be patched at the source level and recompiled correctly by repairing semantic inaccuracies with data from the original binary.

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

Modern decompilers produce code with syntactic and semantic errors that block recompilation after source-level patches are applied. SCRIBE extracts details directly from the binary to repair those inaccuracies during recompilation, raising success rates on previously broken functions. This workflow lets users patch binaries without source code access or hand-edited assembly. The approach succeeds on most tested real-world vulnerabilities and raises non-expert success from near zero to full completion in user tests. It also lets large language models produce working patches when routed through the same repair process.

Core claim

SCRIBE's binary-aware recompilation repairs semantic inaccuracies in decompiler output by leveraging information extracted directly from the original binary. This resolves approximately 81 percent of previously incorrect functions from the Hex-Rays decompiler and enables patching of 13 of 14 real-world CVEs without source code or manual binary editing.

What carries the argument

Binary-aware recompilation, which extracts and re-injects binary-level details to correct semantic errors in decompiled code before recompilation.

If this is right

  • Thirteen of fourteen tested real-world CVEs become patchable without source or manual binary edits.
  • Non-expert participants reach 100 percent patching success versus 3.7 percent without the framework.
  • Large language models achieve 100 percent success on the same patching tasks when the framework supplies the repaired decompiled code.
  • Most functions that previously failed to recompile after decompilation become usable for source-level changes.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same repair technique could be applied to other decompilers beyond the one tested.
  • Fully automated binary patching pipelines become practical once language models generate candidate source patches that are then repaired and recompiled.
  • Binary analysis tasks that currently rely on manual decompiler cleanup may gain similar automation.

Load-bearing premise

Details pulled from the original binary suffice to fix decompiler mistakes without creating new functional changes or requiring further manual work.

What would settle it

A set of additional CVEs or functions where SCRIBE produces recompilable but semantically altered code after patching, or where user success rates remain low even with the framework.

Figures

Figures reproduced from arXiv: 2605.02121 by Abdullah Imran, Antonio Bianchi, Han Dai, Ruoyu Wang, Soumyakant Priyadarshan.

Figure 1
Figure 1. Figure 1: Comparison of binary patching approaches. Hu view at source ↗
Figure 2
Figure 2. Figure 2: Overview of SCRIBE needs to access other functions and data objects and may use pointers to do so. Decompilers use static analysis to recover pointer constants, but such static analysis is prone to errors [24], [27]. 4. System Design SCRIBE employs a minimally invasive approach to binary patching. Rather than recompiling entire programs, it selectively recompiles only functions needing modi￾fication, ensur… view at source ↗
Figure 3
Figure 3. Figure 3: Overview of our binary rewriting technique for view at source ↗
Figure 4
Figure 4. Figure 4: Hex-Rays Recompilation Success Rate before view at source ↗
read the original abstract

When source code or the original toolchain is unavailable, patching binaries is difficult because it requires editing low-level assembly code directly. As an alternative, one can decompile the binary, apply the patch at the source level, and then recompile the modified code. However, as this paper demonstrates, this workflow is hindered by pervasive syntactic and semantic inaccuracies in the output of modern decompilers, many of which prior work has overlooked. To address these challenges, we present SCRIBE, a patching framework that handles syntactic and semantic issues in decompiled code, improving both recompilation success and correctness. SCRIBE's novel "binary-aware" recompilation approach repairs semantic inaccuracies in decompiler output by leveraging information extracted directly from the original binary. In our evaluation, SCRIBE resolved approximately 81% of previously incorrect functions produced by the Hex-Rays decompiler, demonstrating the effectiveness of its approach. Moreover, we show that, using SCRIBE, it is possible to patch 13 of 14 real-world CVEs without access to the original source code and without performing any manual binary editing. To further validate our findings, we conducted a user study with 18 participants. Using SCRIBE, participants achieved 100% patching success, compared to 3.7% without it. Finally, we asked three large language models to generate source-level patches via SCRIBE; all three achieved 100% success when using the framework, demonstrating its potential to enable fully automated patching. Overall, these results indicate that SCRIBE makes source-level patching of binaries accessible and reliable, even without access to the original source.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The manuscript presents SCRIBE, a framework for static binary patching that decompiles a binary (primarily via Hex-Rays), applies source-level patches to the decompiled code, and performs binary-aware recompilation. The core innovation is using information extracted directly from the original binary to repair syntactic and semantic inaccuracies in the decompiler output, enabling recompilation to a functionally patched binary without the original source or manual assembly edits. The paper reports that SCRIBE resolves ~81% of previously incorrect decompiled functions, successfully patches 13 of 14 real-world CVEs, yields 100% patching success in a user study with 18 participants (vs. 3.7% without SCRIBE), and enables three LLMs to produce correct patches at 100% success when using the framework.

Significance. If the central claims hold, the work offers a practical advance for binary patching in source-unavailable settings, lowering the expertise barrier compared to direct assembly editing. The binary-aware repair technique and the combination of user-study plus LLM results are notable strengths that could influence both manual and automated patching workflows. The empirical focus on real CVEs adds relevance, though the absence of direct semantic-equivalence oracles limits the strength of the correctness argument.

major comments (3)
  1. [CVE patching evaluation] Evaluation of CVE patching (abstract and §5): success is defined via recompilation plus failure of the original exploit. This indirect metric does not verify that the repaired binary preserves all observable behaviors of the original (e.g., edge-case data flows, aliasing, or side effects not captured by extracted symbols or CFG). Because the original source is unavailable by design, an independent equivalence check (differential testing against the original binary or symbolic execution on non-patched paths) is needed; without it the 13/14 figure cannot be taken as conclusive evidence of semantic fidelity.
  2. [§4] Function-resolution results (abstract and §4): the claim that SCRIBE resolves ~81% of 'previously incorrect' Hex-Rays functions rests on the authors' definition of incorrectness and resolution. The manuscript must specify the exact criteria (compiler errors, runtime crashes, or behavioral divergence) and whether any post-hoc filtering or manual adjustments were applied to the test corpus. This directly affects the load-bearing claim that binary-extracted information suffices to repair semantic inaccuracies without introducing new functional changes.
  3. [§6] User-study and LLM results (abstract and §6): the 100% success rates are reported without details on task selection, participant expertise distribution, time limits, or statistical tests. For the LLM experiments, the prompt templates and failure modes when SCRIBE is not used should be documented so readers can assess whether the framework's contribution is isolated from model capability.
minor comments (2)
  1. [Introduction] The term 'binary-aware recompilation' is introduced in the abstract but would benefit from an explicit, early definition (e.g., which binary artifacts—symbols, types, constants—are extracted and how they are injected into the recompilation pipeline).
  2. [Evaluation figures/tables] Figure captions and table legends should explicitly state the decompiler version, optimization level, and compiler used for the baseline and SCRIBE runs to allow reproduction.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the thorough and constructive review of our manuscript. We address each major comment point by point below, providing clarifications and indicating where revisions will be made to improve transparency and address concerns.

read point-by-point responses

  1. Referee: [CVE patching evaluation] Evaluation of CVE patching (abstract and §5): success is defined via recompilation plus failure of the original exploit. This indirect metric does not verify that the repaired binary preserves all observable behaviors of the original (e.g., edge-case data flows, aliasing, or side effects not captured by extracted symbols or CFG). Because the original source is unavailable by design, an independent equivalence check (differential testing against the original binary or symbolic execution on non-patched paths) is needed; without it the 13/14 figure cannot be taken as conclusive evidence of semantic fidelity.

    Authors: We appreciate the referee's observation regarding the indirect nature of our CVE patching success metric. Since the original source is unavailable by design, a complete independent semantic equivalence oracle (such as full differential testing or exhaustive symbolic execution) is not feasible in this setting. Our metric reflects practical patching goals: successful recompilation to a binary that neutralizes the known exploit. In the revised manuscript, we will expand §5 to provide additional details on our testing approach, including the specific inputs used to verify exploit failure and any checks for obvious regressions on non-exploit paths. We will also add a 'Threats to Validity' subsection that explicitly discusses the limitations of this metric and the challenges of proving full behavioral preservation without source code. revision: partial

  2. Referee: [§4] Function-resolution results (abstract and §4): the claim that SCRIBE resolves ~81% of 'previously incorrect' Hex-Rays functions rests on the authors' definition of incorrectness and resolution. The manuscript must specify the exact criteria (compiler errors, runtime crashes, or behavioral divergence) and whether any post-hoc filtering or manual adjustments were applied to the test corpus. This directly affects the load-bearing claim that binary-extracted information suffices to repair semantic inaccuracies without introducing new functional changes.

    Authors: We agree that the definitions of 'incorrect' and 'resolved' must be stated precisely to support the claim. In our evaluation, a function was classified as 'incorrect' if it failed to compile under the target compiler or produced runtime errors or crashes when executed against the test inputs derived from the binary. 'Resolved' indicates that the function compiles successfully and passes the same test inputs after applying SCRIBE's repairs. No post-hoc filtering or manual adjustments were performed on the test corpus; all functions were processed uniformly according to these criteria. We will revise §4 to explicitly document these definitions, the nature of the test inputs, and the absence of filtering, thereby strengthening the transparency of the 81% figure. revision: yes

  3. Referee: [§6] User-study and LLM results (abstract and §6): the 100% success rates are reported without details on task selection, participant expertise distribution, time limits, or statistical tests. For the LLM experiments, the prompt templates and failure modes when SCRIBE is not used should be documented so readers can assess whether the framework's contribution is isolated from model capability.

    Authors: We will incorporate the requested details into the revised §6. For the user study, we will describe the task selection (patching specific real-world CVEs in provided binaries), the distribution of the 18 participants' expertise levels, the time limits given for each task, and any statistical tests applied to the results. For the LLM experiments, we will document the exact prompt templates used both with and without SCRIBE, along with the observed failure modes when SCRIBE was not used (primarily syntax errors and incorrect decompiler repairs). This will allow readers to better isolate the framework's contribution from the underlying model capabilities. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical system evaluation with independent test outcomes

full rationale

The paper presents SCRIBE as an engineering framework for source-level binary patching via decompilation and binary-aware recompilation. All reported results (81% resolution of Hex-Rays errors, 13/14 CVE patches, 100% user-study success) are direct empirical measurements on external binaries and real-world cases. No equations, derivations, fitted parameters, or self-referential definitions exist that would reduce any claimed outcome to an input by construction. Evaluation metrics rely on observable recompilation success and exploit failure on held-out CVEs, which are independent of the internal repair logic and not tautological.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The abstract provides no explicit free parameters, axioms, or invented entities; the approach appears to build on standard decompilation and recompilation pipelines with an added repair step whose details are not specified here.

pith-pipeline@v0.9.0 · 5604 in / 1109 out tokens · 41144 ms · 2026-05-08T18:53:41.497263+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

81 extracted references · 3 canonical work pages

  1. [1]

    B2SFinder: Detecting open-source software reuse in COTS software,

    Z. Yuan, M. Feng, F. Li, G. Ban, Y . Xiao, S. Wang, Q. Tang, H. Su, C. Yu, J. Xu, A. Piao, J. Xuey, and W. Huo, “B2SFinder: Detecting open-source software reuse in COTS software,” inProceedings of the IEEE/ACM International Conference on Automated Software Engineering (ASE), 2019

    2019

  2. [2]

    Automating patching of vulnerable open- source software versions in application binaries,

    R. Duan, A. Bijlani, Y . Ji, O. Alrawi, Y . Xiong, M. Ike, B. Saltafor- maggio, and W. Lee, “Automating patching of vulnerable open- source software versions in application binaries,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2019

    2019

  3. [3]

    The extent of orphan vulnerabilities from code reuse in open source software,

    D. Reid, M. Jahanshahi, and A. Mockus, “The extent of orphan vulnerabilities from code reuse in open source software,” inPro- ceedings of the International Conference on Software Engineering (ICSE), 2022

    2022

  4. [4]

    Cross- architecture bug search in binary executables,

    J. Pewny, B. Garmany, R. Gawlik, C. Rossow, and T. Holz, “Cross- architecture bug search in binary executables,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2015

    2015

  5. [5]

    discovRE: Efficient cross-architecture identification of bugs in binary code,

    S. Eschweiler, K. Yakdan, and E. Gerhards-Padilla, “discovRE: Efficient cross-architecture identification of bugs in binary code,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2016

    2016

  6. [6]

    VulHawk: Cross-architecture vulnerability detection with entropy-based binary code search,

    Z. Luo, P. Wang, B. Wang, Y . Tang, W. Xie, X. Zhou, D. Liu, and K. Lu, “VulHawk: Cross-architecture vulnerability detection with entropy-based binary code search,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2023

    2023

  7. [7]

    Efficient, sensitivity resistant binary instrumentation,

    A. R. Bernat, K. Roundy, and B. P. Miller, “Efficient, sensitivity resistant binary instrumentation,” inProceedings of the ACM SIG- SOFT International Symposium on Software Testing and Analysis (ISSTA), 2011

    2011

  8. [8]

    Binary rewriting with- out control flow recovery,

    G. J. Duck, X. Gao, and A. Roychoudhury, “Binary rewriting with- out control flow recovery,” inProceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementa- tion (PLDI), 2020

    2020

  9. [9]

    BinRec: Dynamic binary lifting and recompilation,

    A. Altinay, J. Nash, T. Kroes, P. Rajasekaran, D. Zhou, A. Dabrowski, D. Gens, Y . Na, S. V olckaert, C. Giuffrida, H. Bos, and M. Franz, “BinRec: Dynamic binary lifting and recompilation,” inProceedings of the European Conference on Computer Systems (EuroSys), 2020

    2020

  10. [10]

    What you trace is what you get: Dynamic stack-layout recovery for binary recompilation,

    F. Parzefall, C. Deshpande, F. Hetzelt, and M. Franz, “What you trace is what you get: Dynamic stack-layout recovery for binary recompilation,” inProceedings of the ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2024

    2024

  11. [11]

    McSema: Static translation of x86 instructions to LLVM,

    A. Dinaburg and A. Ruef, “McSema: Static translation of x86 instructions to LLVM,” inReCon, 2014

    2014

  12. [12]

    A platform for secure static binary instrumentation,

    M. Zhang, R. Qiao, N. Hasabnis, and R. Sekar, “A platform for secure static binary instrumentation,” inProceedings of the ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE), 2014

    2014

  13. [13]

    SAFER: Efficient and error-tolerant binary instrumentation,

    S. Priyadarshan, H. Nguyen, R. Chouhan, and R. Sekar, “SAFER: Efficient and error-tolerant binary instrumentation,” inProceedings of the USENIX Security Symposium (USENIX Security), 2023

    2023

  14. [14]

    Egalito: Layout- agnostic binary recompilation,

    D. Williams-King, H. Kobayashi, K. Williams-King, G. Patterson, F. Spano, Y . J. Wu, J. Yang, and V . P. Kemerlis, “Egalito: Layout- agnostic binary recompilation,” inProceedings of the ACM Inter- national Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2020

    2020

  15. [15]

    Binary stirring: Self-randomizing instruction addresses of legacy x86 binary code,

    R. Wartell, V . Mohan, K. W. Hamlen, and Z. Lin, “Binary stirring: Self-randomizing instruction addresses of legacy x86 binary code,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2012

    2012

  16. [16]

    Securing untrusted code via compiler-agnostic binary rewriting,

    ——, “Securing untrusted code via compiler-agnostic binary rewriting,” inProceedings of the Annual Computer Security Ap- plications Conference (ACSAC), 2012

    2012

  17. [17]

    Automated pro- gram repair,

    C. Le Goues, M. Pradel, and A. Roychoudhury, “Automated pro- gram repair,”Communications of the ACM, 2019

    2019

  18. [18]

    The living review on automated program repair,

    M. Monperrus, “The living review on automated program repair,” https://hal.science/hal-01956501/file/repair-living-review. pdf, 2018, accessed: November 10, 2025

    2018

  19. [19]

    Neural program repair with execution-based backpropagation,

    H. Ye, M. Martinez, and M. Monperrus, “Neural program repair with execution-based backpropagation,” inProceedings of the In- ternational Conference on Software Engineering (ICSE), 2022

    2022

  20. [20]

    VulRepair: A T5-based automated software vulnerability repair,

    M. Fu, C. Tantithamthavorn, T. Le, V . Nguyen, and D. Phung, “VulRepair: A T5-based automated software vulnerability repair,” inProceedings of the ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engi- neering (ESEC/FSE), 2022

    2022

  21. [21]

    IDA Pro,

    Hex-Rays, “IDA Pro,” https://www.hex-rays.com/products/ida/, 1996, accessed: November 10, 2025

    1996

  22. [22]

    National Security Agency, “Ghidra,” https://ghidra-sre.org/, 2019, accessed: November 10, 2025

    2019

  23. [23]

    Patcherex2,

    PurSecLab, “Patcherex2,” https://github.com/purseclab/patcherex2, 2023, accessed: November 10, 2025

    2023

  24. [24]

    Ramblr: Making reassembly great again,

    R. Wang, Y . Shoshitaishvili, A. Bianchi, A. Machiry, J. Grosen, P. Grosen, C. Kruegel, and G. Vigna, “Ramblr: Making reassembly great again,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2017

    2017

  25. [25]

    Evaluating the effec- tiveness of decompilers,

    Y . Cao, R. Zhang, R. Liang, and K. Chen, “Evaluating the effec- tiveness of decompilers,” inProceedings of the ACM SIGSOFT In- ternational Symposium on Software Testing and Analysis (ISSTA), 2024

    2024

  26. [26]

    Reassembleable disassembling,

    S. Wang, P. Wang, and D. Wu, “Reassembleable disassembling,” inProceedings of the USENIX Security Symposium (USENIX Se- curity), 2015

    2015

  27. [27]

    Datalog disassembly,

    A. Flores-Montoya and E. Schulte, “Datalog disassembly,” inPro- ceedings of the USENIX Security Symposium (USENIX Security), 2020

    2020

  28. [28]

    Headless IDA,

    H. Dai, “Headless IDA,” https://github.com/DennyDai/ headless-ida, 2023, accessed: November 10, 2025

    2023

  29. [29]

    pyhidra,

    DoD Cyber Crime Center, “pyhidra,” https://github.com/ dod-cyber-crime-center/pyhidra, 2022, accessed: November 10, 2025

    2022

  30. [30]

    A tough call: Mitigating advanced code-reuse attacks at the binary level,

    V . Van der Veen, E. G ¨oktas ¸, M. Contag, A. Pawoloski, X. Chen, S. Rawat, H. Bos, T. Holz, E. Athanasopoulos, and C. Giuffrida, “A tough call: Mitigating advanced code-reuse attacks at the binary level,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2016

    2016

  31. [31]

    LLVM Language Reference Manual,

    LLVM, “LLVM Language Reference Manual,” https://llvm.org/ docs/LangRef.html, 2003, accessed: November 10, 2025

    2003

  32. [32]

    Automatically mitigating vulnerabilities in binary pro- grams via partially recompilable decompilation,

    P. Reiter, H. J. Tay, W. Weimer, A. Doup ´e, R. Wang, and S. Forrest, “Automatically mitigating vulnerabilities in binary pro- grams via partially recompilable decompilation,”arXiv preprint arXiv:2202.12336, 2022

    work page arXiv 2022

  33. [33]

    Coreutils,

    GNU, “Coreutils,” https://www.gnu.org/software/coreutils/, 2002, accessed: November 10, 2025

    2002

  34. [34]

    cgc-challenges,

    novafacing, “cgc-challenges,” https://github.com/novafacing/ cgc-challenges, 2022, accessed: November 10, 2025

    2022

  35. [35]

    Binutils,

    GNU, “Binutils,” https://www.gnu.org/software/binutils/, 1991, ac- cessed: November 10, 2025

    1991

  36. [36]

    Wilcoxon signed-rank test,

    R. F. Woolson, “Wilcoxon signed-rank test,” inWiley Encyclopedia of Clinical Trials. John Wiley & Sons, Ltd, 2008

    2008

  37. [37]

    CVE-2014-9471,

    “CVE-2014-9471,” https://nvd.nist.gov/vuln/detail/ CVE-2014-9471, 2014, accessed: November 10, 2025

    2014

  38. [38]

    CVE-2020-16593,

    “CVE-2020-16593,” https://nvd.nist.gov/vuln/detail/ CVE-2020-16593, 2020, accessed: November 10, 2025

    2020

  39. [39]

    VeriBin: Adaptive verification of patches at the binary level,

    H. Wu, J. Wu, R. Wu, A. Sharma, A. Machiry, and A. Bianchi, “VeriBin: Adaptive verification of patches at the binary level,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2025

    2025

  40. [40]

    D-Helix: A generic decompiler testing framework using symbolic differentiation,

    M. Zou, A. Khan, R. Wu, H. Gao, A. Bianchi, and D. J. Tian, “D-Helix: A generic decompiler testing framework using symbolic differentiation,” inProceedings of the USENIX Security Symposium (USENIX Security), 2024

    2024

  41. [41]

    Secure exe- cution via program shepherding,

    V . Kiriansky, D. Bruening, and S. P. Amarasinghe, “Secure exe- cution via program shepherding,” inProceedings of the USENIX Security Symposium (USENIX Security), 2002

    2002

  42. [42]

    Efficient techniques for comprehensive protection from memory error exploits,

    S. Bhatkar, R. Sekar, and D. C. DuVarney, “Efficient techniques for comprehensive protection from memory error exploits,” inPro- ceedings of the USENIX Security Symposium (USENIX Security), 2005

    2005

  43. [43]

    Practical proactive integrity preservation: A basis for malware defense,

    W. Sun, R. Sekar, G. Poothia, and T. Karandikar, “Practical proactive integrity preservation: A basis for malware defense,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2008

    2008

  44. [44]

    Practical control flow integrity and ran- domization for binary executables,

    C. Zhang, T. Wei, Z. Chen, L. Duan, L. Szekeres, S. McCamant, D. Song, and W. Zou, “Practical control flow integrity and ran- domization for binary executables,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2013

    2013

  45. [45]

    Control flow and code integrity for COTS binaries: An effective defense against real-world ROP attacks,

    M. Zhang and R. Sekar, “Control flow and code integrity for COTS binaries: An effective defense against real-world ROP attacks,” inProceedings of the Annual Computer Security Applications Conference (ACSAC), 2015

    2015

  46. [46]

    Practical context-sensitive CFI,

    V . Van der Veen, D. Andriesse, E. G ¨oktas ¸, B. Gras, L. Sambuc, A. Slowinska, H. Bos, and C. Giuffrida, “Practical context-sensitive CFI,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2015

    2015

  47. [47]

    Practical fine-grained binary code randomization,

    S. Priyadarshan, H. Nguyen, and R. Sekar, “Practical fine-grained binary code randomization,” inProceedings of the Annual Com- puter Security Applications Conference (ACSAC), 2020

    2020

  48. [48]

    Gadge me if you can: Secure and efficient ad-hoc instruction- level randomization for x86 and ARM,

    L. V . Davi, A. Dmitrienko, S. N ¨urnberger, and A.-R. Sadeghi, “Gadge me if you can: Secure and efficient ad-hoc instruction- level randomization for x86 and ARM,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2013

    2013

  49. [49]

    Oxymoron: Making fine-grained memory randomization practical by allowing code sharing,

    M. Backes and S. N ¨urnberger, “Oxymoron: Making fine-grained memory randomization practical by allowing code sharing,” inPro- ceedings of the USENIX Security Symposium (USENIX Security), 2014

    2014

  50. [50]

    Protecting COTS binaries from disclosure-guided code reuse attacks,

    M. Zhang, M. Polychronakis, and R. Sekar, “Protecting COTS binaries from disclosure-guided code reuse attacks,” inProceed- ings of the Annual Computer Security Applications Conference (ACSAC), 2017

    2017

  51. [51]

    A principled approach for ROP defense,

    R. Qiao, M. Zhang, and R. Sekar, “A principled approach for ROP defense,” inProceedings of the Annual Computer Security Applications Conference (ACSAC), 2015

    2015

  52. [52]

    SoK: (State of) The Art of War: Offensive Techniques in Binary Analysis,

    Y . Shoshitaishvili, R. Wang, C. Salls, N. Stephens, M. Polino, A. Dutcher, J. Grosen, S. Feng, C. Hauser, C. Kruegel, and G. Vigna, “SoK: (State of) The Art of War: Offensive Techniques in Binary Analysis,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2016

    2016

  53. [53]

    RetroWrite: Statically instrumenting COTS binaries for fuzzing and sanitization,

    S. Dinesh, N. Burow, D. Xu, and M. Payer, “RetroWrite: Statically instrumenting COTS binaries for fuzzing and sanitization,” inPro- ceedings of the IEEE Symposium on Security and Privacy (S&P), 2020

    2020

  54. [54]

    StochFuzz: Sound and cost-effective fuzzing of stripped binaries by incremental and stochastic rewriting,

    Z. Zhang, W. You, G. Tao, Y . Aafer, X. Liu, and X. Zhang, “StochFuzz: Sound and cost-effective fuzzing of stripped binaries by incremental and stochastic rewriting,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2021

    2021

  55. [55]

    BOLT: A practi- cal binary optimizer for data centers and beyond,

    M. Panchenko, R. Auler, B. Nell, and G. Ottoni, “BOLT: A practi- cal binary optimizer for data centers and beyond,” inProceedings of the IEEE/ACM International Symposium on Code Generation and Optimization (CGO), 2019

    2019

  56. [56]

    Binary control-flow trimming,

    M. Ghaffarinia and K. W. Hamlen, “Binary control-flow trimming,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2019

    2019

  57. [57]

    RAZOR: A framework for post-deployment software debloating,

    C. Qian, H. Hu, M. Alharthi, S. P. H. Chung, T. Kim, and W. Lee, “RAZOR: A framework for post-deployment software debloating,” inProceedings of the USENIX Security Symposium (USENIX Security), 2019

    2019

  58. [58]

    ARMore: Push- ing love back into binaries,

    L. Di Bartolomeo, H. Moghaddas, and M. Payer, “ARMore: Push- ing love back into binaries,” inProceedings of the USENIX Security Symposium (USENIX Security), 2023

    2023

  59. [59]

    Pin – A Dynamic Binary Instrumentation Tool,

    Intel, “Pin – A Dynamic Binary Instrumentation Tool,” https://software.intel.com/content/www/us/en/develop/articles/ pin-a-dynamic-binary-instrumentation-tool.html, 2004, accessed: November 10, 2025

    2004

  60. [60]

    An infrastructure for adaptive dynamic optimization,

    D. Bruening, T. Garnett, and S. Amarasinghe, “An infrastructure for adaptive dynamic optimization,” inProceedings of the IEEE/ACM International Symposium on Code Generation and Optimization (CGO), 2003

    2003

  61. [61]

    Better automatic program re- pair by using bug reports and tests together,

    M. Motwani and Y . Brun, “Better automatic program re- pair by using bug reports and tests together,”arXiv preprint arXiv:2011.08340, 2020

    work page arXiv 2011

  62. [62]

    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,” in Proceedings of the USENIX Security Symposium (USENIX Secu- rity), 2024

    2024

  63. [63]

    How far we have come: Testing decom- pilation correctness of C decompilers,

    Z. Liu and S. Wang, “How far we have come: Testing decom- pilation correctness of C decompilers,” inProceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2020

    2020

  64. [64]

    Finding and understand- ing bugs in C compilers,

    X. Yang, Y . Chen, E. Eide, and J. Regehr, “Finding and understand- ing bugs in C compilers,” inProceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementa- tion (PLDI), 2011

    2011

  65. [65]

    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,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2021

    2021

  66. [66]

    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 ACM SIGSAC Con- ference on Computer and Communications Security (CCS), 2024

    2024

  67. [67]

    Variable name recovery in decompiled binary code using constrained masked language modeling,

    P. Banerjee, K. K. Pal, F. Wang, and C. Baral, “Variable name recovery in decompiled binary code using constrained masked language modeling,”arXiv preprint arXiv:2103.12801, 2021

    work page arXiv 2021

  68. [68]

    Unleashing the power of generative model in recovering variable names from stripped binary,

    X. Xu, Z. Zhang, Z. Su, Z. Huang, S. Feng, Y . Ye, N. Jiang, S. Qiao, H. Wang, L. Tan, and X. Zhang, “Unleashing the power of generative model in recovering variable names from stripped binary,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2025

    2025

  69. [69]

    DecLLM: LLM-augmented recompilable decompilation for enabling programmatic use of decompiled code,

    W. K. Wong, D. Wu, H. Wang, Z. Li, Z. Liu, S. Wang, Q. Tang, S. Nie, and S. Wu, “DecLLM: LLM-augmented recompilable decompilation for enabling programmatic use of decompiled code,” Proceedings of the ACM on Software Engineering (ISSTA), 2025. Appendix A. Evaluated CVE Details This appendix provides detailed information about the real-world CVEs used to ev...

    2025

  70. [70]

    Are you 18 years of age or older? •Yes •No

  71. [71]

    and comfortable with bash scripts) •Advanced (extensive system administration and scripting)

    What is your level of experience with Linux/Unix and shell scripting? •No experience •Basic (familiar with common commands like cat, ls, cd, etc. and comfortable with bash scripts) •Advanced (extensive system administration and scripting)

  72. [72]

    What is your level of experience with C programming? •No experience •Basic (can write simple C programs) •Advanced (extensive experience with complex applications)

  73. [73]

    What is your experience with common memory-related vulnera- bilities in C? •No experience •Basic (understand concepts like buffer overflow, use-after-free) •Advanced (experience exploiting memory vulnerabilities)

  74. [74]

    What is your experience with decompiler yrrxpv? •No experience •Basic (this decompiler doesn’t exist, you should select no experience) •Advanced (same as basic, but have more than 1 year of expe- rience)

  75. [75]

    Which other decompilers have you used? (Select all that apply) •Ghidra •IDA Pro •Binary Ninja •Others (Please specify):

  76. [76]

    How comfortable are you with using GNU Debugger (GDB)? •No experience •Basic (familiar with common debugging commands) •Advanced (extensive debugging experience)

  77. [77]

    •Yes •No

    Are you able to commit to a 3.5 hour study session on Zoom? You’ll need a computer with a stable internet connection and an up-to-date Chrome browser. •Yes •No

  78. [78]

    Which declaration creates a pointer to an integer? •ptr * int; •int * ptr; •pointer int

  79. [79]

    What does the arrow operator (-¿) do in C? •Access structure members through a pointer •Moves data from one pointer to another •Compares two pointers

  80. [80]

    How do you convert (cast) one type to another in C? •(int) x •int(x) •convert.int(x)

Showing first 80 references.