デコンパイラ研究調査

Transcript

1. デコンパイラ研究調査 安藤 慎 システムセキュリティ研究室 ゼミ / 2026 年 5 月 22 日
2. はじめに デコンパイラとは1 バイナリを高級言語のソースコードに再変換するソフトウェア ソースコード コンパイル → ← デコンパイル バイナリ 1https://techbookfest.org/product/66QXa8WfF5QJRiqcSHBCQs 1 / 34
3. デコンパイラとは デコンパイルの難所 1. コンパイルによって、ソースコードに含まれる情報が失われる e.g. シンボル名、型、制御構造（if-then-else, while, switch など） 2. そもそもデコンパイルで解くべき問題のいくつかは決定不能1 e.g. 間接ジャンプのターゲットアドレス 3. 同じプログラムでも、そのコードの書き方は無数にある → 何らかの基準をもって候補を選ぶ必要がある 1https://binary.ninja/presentations/Modern%20Binary%20Analysis%20with%20ILs%20with%20notes.pdf 2 / 34
4. デコンパイラとは デコンパイルでよくある間違い1 1https://www.usenix.org/conference/usenixsecurity24/presentation/dramko 3 / 34
5. デコンパイラとは 良いデコンパイルとは (1) デコンパイル結果のソースコードが人間にとって読みやすい 応用: 脆弱性診断 • ソースコードの行数が少ない1 • ソースコードの循環的複雑度が小さい2 • ソースコード中の goto の数が少ない3 1https://yurichev.com/mirrors/DCC_decompilation_thesis.pdf 2https://dl.acm.org/doi/10.1145/3320269.3384766 3https://www.ndss-symposium.org/ndss2015/ndss-2015-programme/no-more-gotos-decompilation-using-pattern-independent-control-flow- structuring-and-semantics/ 4 / 34
6. デコンパイラとは 良いデコンパイルとは (2) デコンパイル結果のソースコードと元のソースコードが似ている 応用: ライセンス調査、使用ライブラリの特定 • 元のソースコードと CFG が同じ1 • 元のソースコードとの CodeBLEU（コードの類似度）が高い2 1https://www.usenix.org/conference/usenixsecurity24/presentation/basque 2https://arxiv.org/abs/2603.28002 5 / 34
7. デコンパイラとは 良いデコンパイルとは (3) デコンパイル結果のソースコードと元のソースコードが意味的に同じ 応用: ソフトウェアの修正・検証、ソースコードベースの検査 • ソースコードを再コンパイルしたバイナリがテストをパスする1 • ソースコードを再コンパイルすると元のバイナリと同じになる2 • 意味的に等価で、かつ再コンパイルできる3 1https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/schwartz 2https://www.usenix.org/c/usenixsecurity22/presentation/burk 3https://dl.acm.org/doi/10.1007/978-3-030-58768-0_14 6 / 34
8. デコンパイラとは 一般的なデコンパイラの構成 多くの場合、以下のような段階を踏んで（あるいは繰り返して） デコンパイルが行われる1 バイナリ → CFG Recovery → Variable / Type Recovery → CFG Structuring → ソースコード 1https://decompilation.wiki/fundamentals/overview/ 7 / 34
9. 一般的なデコンパイラの構成 CFG Recovery バイナリの制御フローを解析し Control Flow Graph(CFG) を構築する CFG の例1: → 1https://decompilation.wiki/fundamentals/cfg-recovery/overview/ 8 / 34
10. CFG Recovery Control Flow Graph(CFG) とは プログラムを実行して通る可能性のある経路をグラフで示したもの1 関数単位で作られる ノード 連続して実行される命令列（基本ブロック） エッジ あるブロックからあるブロックに制御が移る（分岐する） 先ほどの CFG の例: • jle 命令@1138: 分岐成立・不成立で 2 つのエッジをもつ • jmp 命令@1141: 分岐先への 1 つのエッジをもつ • mov 命令@114a: 次の命令への 1 つのエッジをもつ 1https://en.wikipedia.org/wiki/Control-flow_graph 9 / 34
11. CFG Recovery CFG を使うと何が嬉しいのか • コンパイラの文脈で行われてきた研究が活かせる ‣ データフロー解析 ‣ ループの検出 • 表現として制御構造の復元に適している 10 / 34
12. CFG Recovery rev.ng: a unified binary analysis framework to recover CFGs and function boundaries1 提案手法の概要 1. バイナリ内の機械語をアセンブリに変換する（Disassemble） 2. 基本ブロックと、基本ブロック間の制御フローを特定する 3. 関数の範囲を特定する 1https://dl.acm.org/doi/10.1145/3033019.3033028 11 / 34
13. CFG Recovery CFG Recovery の難所1 1. バイナリ内の機械語をアセンブリに変換する（Disassemble） コードとデータの区別が難しい 命令の開始アドレスの特定が難しい 一般的なバイナリでは 96% 以上の精度を達成しているとの研究も2 2. 基本ブロックと、基本ブロック間の制御フローを特定する 直接ジャンプ命令はオペランドからジャンプ先を容易に解析できる 一方、間接ジャンプ命令はジャンプ先の特定が困難 1https://dl.acm.org/doi/10.1145/3033019.3033028 2https://dl.acm.org/doi/10.5555/3241094.3241140 12 / 34
14. CFG Recovery CFG Recovery の難所1 (Cont’d) 3. 関数の境界を特定する 以下のようなケースで、関数が終わるアドレスの特定が難しい • exit 関数などの noreturn 関数 • 末尾呼び出し最適化された関数 • 別の関数とコードを共有する関数 • 複数のエントリポイントを持つ関数 1https://dl.acm.org/doi/10.1145/3033019.3033028 13 / 34
15. CFG Recovery 関連研究 SoK: All You Ever Wanted to Know About x86/x64 Binary Disassembly1 既存ツールが CFG Recovery のために用いるアルゴリズム・ヒューリ スティックを整理 番号の読み方: ⚪︎ アルゴリズム ⚫︎ ヒューリスティック 1https://www.computer.org/csdl/proceedings-article/sp/2021/893400a194/1mbmHyBd1Dy 14 / 34
16. CFG Recovery 15 / 34
17. CFG Recovery 関連研究 BinPointer: towards precise, sound, and scalable binary-level pointer analysis1 メモリ空間を論理的なブロックに分割することで計算時間を抑えつつ 間接ジャンプの宛先を解析 Compiler-Agnostic Function Detection in Binaries2 バイナリ全体で制御フローグラフを構築、独立したグラフを抽出して 関数の範囲を特定 1https://dl.acm.org/doi/10.1145/3497776.3517776 2https://ieeexplore.ieee.org/document/7961979 16 / 34
18. 一般的なデコンパイラの構成 Variable / Type Recovery レジスタ・メモリへのアクセスから、変数・型情報を復元する アセンブリでは変数の情報が失われ、単なるメモリアクセスになる c 1 2 3 4 5 6 7 8 9 int global; int main() { int local; local = 1; // mov DWORD PTR [rbp-4], 1 global = 1; // mov DWORD PTR "global"[rip], 1 } 17 / 34
19. Variable / Type Recovery DIVINE: Discovering Variables in Executables1 変数の復元手法を提案 対象とする変数: • グローバル変数 • ローカル変数 • ヒープ変数 ‣ p = malloc(sizeof(foo_t)); p->field1; p->field2; 対象でない変数: • レジスタ変数 1https://pages.cs.wisc.edu/~bgogul/Research/Invited-Papers/vmcai07.invited.pdf 18 / 34
20. Variable / Type Recovery DIVINE: Discovering Variables in Executables1 (Cont’d) 提案手法の概要 1. Value Set Analysis • [rbp-4], [rbp-48+rax*4] 等がアクセスするアドレス範囲を特定 2. Aggregate Structure Identification • 特定したアドレス範囲へのアクセスパターンを見て、変数に分割 1https://pages.cs.wisc.edu/~bgogul/Research/Invited-Papers/vmcai07.invited.pdf 19 / 34
21. Variable / Type Recovery TIE: Principled Reverse Engineering of Types in Binary Programs1 提案手法の概要 • メモリアクセスから型制約を集める ‣ n バイト ‣ signed / unsigned ‣ 浮動小数点演算 ‣ 既知の関数呼び出し • 型制約から型の候補を特定 1https://www.ndss-symposium.org/wp-content/uploads/2017/09/lee.pdf 20 / 34
22. Variable / Type Recovery Variable / Type Recovery の難所 1. 変数・型情報の完全な復元は不可能 2. 変数の同一性判定が困難 同じレジスタ・メモリが別の変数に再利用される場合がある 3. 評価基準が自明でない 変数名（count, size は同じか） 、型（uint32_t, unsigned int は同じか） 21 / 34
23. Variable / Type Recovery 関連研究 DIRTY: Augmenting Decompiler Output with Learned Variable Names and Types1 Transformer でデコンパイル結果に後処理を適用し、変数名・型を生 成する 1https://www.usenix.org/conference/usenixsecurity22/presentation/chen-qibin 22 / 34
24. 一般的なデコンパイラの構成 CFG Structuring CFG を解析し、高級言語の制御構造（if-then-else, while switch など） を復元する1 1https://ieeexplore.ieee.org/document/11129273 23 / 34
25. CFG Structuring Native x86 Decompilation Using Semantics-Preserving Structural Analysis and Iterative Control-Flow Structuring1 提案手法の概要 1. 制御構造ごとに定義したスキーマとマッチングする 2. マッチングにおいて邪魔なエッジは仮想化する • Single Entry Single Successor(SESS) を満たさないエッジ • 仮想化: goto, break, continue 等に置き換え、エッジを削除する 3. どのスキーマともマッチングできない場合は適当なエッジを 1 つ goto に置き換えて削除する 1https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/schwartz 24 / 34
26. CFG Structuring 25 / 34
27. CFG Structuring CFG Structuring の難所1 1. 自然に構造化できない（非可約な）CFG が存在する • ユーザーが goto 文を使用したプログラム • コンパイラによって最適化されたプログラム 2. 構造化できない制御フローの扱い方が複数ある • goto の挿入 • 基本ブロックの複製 • 条件式の複製 1https://ieeexplore.ieee.org/document/11129273 26 / 34
28. CFG Structuring 3. 構造化の順序によって結果が変わりうる どのループを先に構造化したかによって結果が変わる例: 27 / 34
29. CFG Structuring 関連研究 No More Gotos: Decompilation Using Pattern-Independent Control- Flow Structuring and Semantics-Preserving Transformations1 特定の基本ブロックに到達する条件を解析して意味的に等価なコード を生成し、goto 0 のデコンパイルを達成 A Comb for Decompiled C Code2 基本ブロックを複製してスキーマにマッチさせ、goto 0 のデコンパイ ルを達成 1https://www.ndss-symposium.org/ndss2015/ndss-2015-programme/no-more-gotos-decompilation-using-pattern-independent-control-flow- structuring-and-semantics/ 2https://dl.acm.org/doi/10.1145/3320269.3384766 28 / 34
30. CFG Structuring Ahoy SAILR! There is No Need to DREAM of C: A Compiler-Aware Structuring Algorithm for Binary Decompilation1 Control Flow Graph Edit Distance(CFGED) を評価指標として提案 コンパイラの最適化の逆操作を適用して、最適化前の CFG を推測 1https://www.usenix.org/conference/usenixsecurity24/presentation/basque 29 / 34
31. CFG Structuring 一般的なデコンパイラの構成（再掲） 多くの場合、以下のような段階を踏んで（あるいは繰り返して） デコンパイルが行われる1 バイナリ → CFG Recovery → Variable / Type Recovery → CFG Structuring → ソースコード 1https://decompilation.wiki/fundamentals/overview/ 30 / 34
32. 関連研究 LLM を用いたデコンパイル PyLingual: Toward Perfect Decompilation of Evolving High-Level Languages1 Python バイトコードのデコンパイラ LLM に元のバイトコードとの一致度をオラクルとして与えることで高 精度なデコンパイルを達成 1https://www.computer.org/csdl/proceedings-article/sp/2025/223600a052/21B7QZB86cg 31 / 34
33. 関連研究 32 / 34
34. 関連研究 LLM を用いたデコンパイル CASCADE: LLM-Powered JavaScript Deobfuscator at Google1 LLM が意味を保ったまま JavaScript のコードを変換できるよう、 JavaScript の中間表現 JSIR を開発 Towards LLM-Resistant Software Protection: Agent Failure Patterns in CTF Reverse Engineering2 デコンパイルによって一部の情報が失われ、むしろデコンパイラを使 わないほうがリバースエンジニアリングに成功するケースがあった 1https://arxiv.org/abs/2507.17691 2https://www.ndss-symposium.org/ndss-paper/auto-draft-657/ 33 / 34
35. 関連研究 考えていること • 人間にとって読みやすいコードの生成は LLM が得意 ‣ 機械語からソースコードへの翻訳 • 一方、正しさの保証については既存のデコンパイラの方が得意 • LLM にデコンパイルを任せつつ、間違いを検出・指摘できる仕組み があると良さそう 34 / 34