3.1 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AI-Assisted Reverse Engineering | 2026-06-29 | 2026-07-02 | concept |
|
|
medium |
AI-Assisted Reverse Engineering
AI-assisted reverse engineering は、binary 解析、逆コンパイル、型復元、関数名付け、コメント付け、デバッグ観察を、人間だけの手作業ではなく AI エージェントと専門道具の組で進める考え方。ghidra-mcp はこの形を Ghidra と MCP で具体化している。
重要なのは、LLM に「それらしく読ませる」だけでは品質が安定しないこと。逆解析では、関数名、型、構造体、呼び出し関係、根拠コメントが後続作業の足場になるため、一度の推測ミスが広く伝播する。Ghidra MCP の README は、命名規則、型変更の拒否、文書化の完全性得点、batch operation、transaction といった仕組みを通じて、作業のばらつきを道具側で抑えようとしている。
FluxSec の Windows 11 kernel / ETW:TI write-up は、AI 支援の有無にかかわらず reverse engineering の良い検証 loop を示す例として使える。NtWriteVirtualMemory から undocumented MiReadWriteVirtualMemory、PsIsProcessLoggingEnabled、EtwTiLogReadWriteVm へ進み、decompiler の読みを KPCR/KTHREAD/KPROCESS/EPROCESS offset、WinDbg breakpoint、bitfield 確認、driver 実装で検証している。AI エージェントに逆解析を手伝わせる場合も、このように「静的な推測 → 動的な観測 → 最小実装で再現」の loop を harness 側で要求しないと、もっともらしい構造体名や flag 解釈が事実として固着しやすい。^[raw/articles/fluxsec-windows-11-kernel-reverse-engineering-etwti-2026.md]
見るべき軸
- 読み取りから書き込みへ: AI が decompile 結果を要約するだけでなく、rename、retype、comment、structure creation まで行うなら、取り消しや検査の境界が必要になる。
- 作法の固定: 命名や型付けの規則を prompt ではなく tool layer に置くと、ai-research-automation と同じく、人間が毎回注意しなくても運用が続く。
- 静的解析と動的観察の接続: P-code 実行や debugger 連携は、単なる text reading ではなく、仮説を実行で確かめる経路を作る。
- 共同作業と版違い: Ghidra Server、version control、function hash による文書化移植は、複数人・複数版 binary の解析で効く。
Open Questions
- AI が書き込んだ rename/type/comment を、どの段階で人間が承認するべきか。
- convention enforcement が強すぎると、未知の binary に必要な例外を潰さないか。
- MCP 経由の Ghidra 操作ログを、wiki-maintenance-loop の raw source や監査記録としてどう残すか。
- 逆解析支援道具を扱うとき、研究・防御・教育の用途と悪用可能性の線引きをどう説明するか。