add

2026-07-03 00:38:05 +09:00
parent 87eacd39b2
commit 86cad348b4
149 changed files with 24450 additions and 105 deletions
@@ -1,10 +1,10 @@
 ---
 title: AI-Assisted Reverse Engineering
 created: 2026-06-29
-updated: 2026-06-29
+updated: 2026-07-02
 type: concept
 tags: [security, dev-tool, agent, automation, quality]
-sources: [raw/articles/ghidra-mcp-2026.md]
+sources: [raw/articles/ghidra-mcp-2026.md, raw/articles/fluxsec-windows-11-kernel-reverse-engineering-etwti-2026.md]
 confidence: medium
 ---

@@ -14,6 +14,8 @@ AI-assisted reverse engineering は、binary 解析、逆コンパイル、型

 重要なのは、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 まで行うなら、取り消しや検査の境界が必要になる。