paperbot · PL 论文追踪

全部论文 待读 收藏

P2 Decompiling for Constant-Time Analysis

面向常数时间分析的反编译
OOPSLA 10(OOPSLA1)2026匹配度 4/10 · 论文属于静态分析与形式化验证范畴,且是典型的问题驱动研究(指出反编译/内部变换会消除CT违规导致误判),兼具理论(CT透明性定义与证明)与工程实现(CT-RetDec),与用户偏好的研究风格契合。但其核心场景是密码库的常量时间/侧信道安全,与应用静态分析于 ML/Agentic 程序、用 LLM 改进静态分析、浮点或贝叶斯程序分析这几个具体追踪方向均无交集。引用 1 inbox
Santiago Arranz-Olmos, Gilles Barthe, Lionel Blatter, Youcef Bouzid, Sören van der Wall, Zhiyuan Zhang
crossref: 2026-09-10

AI 速览

一句话:揭示反编译与分析变换会消除CT违规,提出CT透明性并构建CT-RetDec验证工具。

常数时间编程保护密码库免受侧信道攻击,但编译器与程序变换可能引入或掩盖违规,故需验证汇编是否满足常数时间。本文研究“先反编译再分析”这一替代方案的方法学与可扩展性。作者先给出反例:现有反编译器和两种流行CT分析工具的内部变换会在分析前消除CT违规,使非CT且可利用的程序被误判为常数时间。为此提出CT透明性:变换既不消除也不引入CT违规;给出证明方法,证明若干变换透明,并扩展到推测性常数时间。实践上构建CT透明的RetDec并与CT-LLVM结合为CT-RetDec,在真实二进制漏洞基准上评估,显示修改显著影响工具表现。

问题
常数时间代码难写,编译器与程序变换可能引入CT违规;而“先反编译再分析”方案可能因反编译器内部变换消除违规,导致非CT程序被误判。本文研究该方案的方法学与可扩展性。
方法
定义CT透明性(变换既不消除也不引入CT违规),给出证明变换CT透明的一般方法,证明若干变换透明,并扩展到推测性常数时间;实现CT透明的LLVM反编译器RetDec并与CT-LLVM结合。
评估
通过构造反例说明现有反编译器和两种流行CT分析工具会误接受非CT程序;在真实二进制漏洞基准上评估CT-RetDec,显示所做修改显著影响其分析表现。
原文摘要(Abstract)

The constant-time programming discipline is commonly used to protect cryptographic libraries against side-channel attacks. However, it is hard to write constant-time code; moreover, compilers can introduce constant-time violations. Therefore, it is important to ensure that assembly code is constant-time. One approach is to show that source programs are constant-time, and that constant-timeness is preserved by compilation. In this paper, we explore the methodological soundness and scalability of the Decompile-then-Analyze approach, a less conventional alternative that has been suggested in the broader setting of static analysis. Informally, the Decompile-then-Analyze approach uses decompilers a front-end for static analysis tools. As a motivation for our study, we show that current decompilers eliminate CT vulnerabilities before CT analysis, leading to non-CT programs being accepted as constant-time. Independently, we provide constructed examples of non-CT, exploitable, programs that are accepted by two popular CT analysis tools; in both cases the culprit are program transformations that are used internally prior to CT analysis and eliminate CT violations. While our examples do not invalidate the general approach of these tools, they emphasize the need for studying the Decompile-then-Analyze approach. On the methodological side, we define the notion of CT transparency . Informally, a program transformation is CT transparent if does not eliminate nor introduce CT violations. We also provide general methods for proving that a transformation is CT transparent, and show that several transformations of interest are transparent. We also sketch an extension of CT transparency to speculative constant-time, which is used by cryptographic software as a protection against Spectre attacks. On the practical side, we build a CT-transparent version of the popular LLVM-based decompiler Ret Dec , and combine it with CT-LLVM, an existing CT verification tool for LLVM. We evaluate the resulting tool, called CT- Ret Dec on a benchmark set of real-world vulnerabilities in binaries, and show that the modifications had significant impact on how well CT- Ret Dec performs.

链接与引用

DOI 原文 · PDF(开放获取) ·

BibTeX
@article{paperbot3841,
  title = {Decompiling for Constant-Time Analysis},
  author = {Santiago Arranz-Olmos and Gilles Barthe and Lionel Blatter and Youcef Bouzid and Sören van der Wall and Zhiyuan Zhang},
  journal = {Proceedings of the ACM on Programming Languages},
  volume = {10},
  number = {OOPSLA1},
  year = {2026},
  doi = {10.1145/3798201}
}