add

concepts/ai-assisted-reverse-engineering.md

@@ -0,0 +1,29 @@
+---
+title: AI-Assisted Reverse Engineering
+created: 2026-06-29
+updated: 2026-06-29
+type: concept
+tags: [security, dev-tool, agent, automation, quality]
+sources: [raw/articles/ghidra-mcp-2026.md]
+confidence: medium
+---
+
+# AI-Assisted Reverse Engineering
+
+AI-assisted reverse engineering は、binary 解析、逆コンパイル、型復元、関数名付け、コメント付け、デバッグ観察を、人間だけの手作業ではなく AI エージェントと専門道具の組で進める考え方。[[ghidra-mcp]] はこの形を Ghidra と MCP で具体化している。
+
+重要なのは、LLM に「それらしく読ませる」だけでは品質が安定しないこと。逆解析では、関数名、型、構造体、呼び出し関係、根拠コメントが後続作業の足場になるため、一度の推測ミスが広く伝播する。Ghidra MCP の README は、命名規則、型変更の拒否、文書化の完全性得点、batch operation、transaction といった仕組みを通じて、作業のばらつきを道具側で抑えようとしている。
+
+## 見るべき軸
+
+- **読み取りから書き込みへ**: 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 や監査記録としてどう残すか。
+- 逆解析支援道具を扱うとき、研究・防御・教育の用途と悪用可能性の線引きをどう説明するか。

concepts/extensible-data-file-formats.md

@@ -0,0 +1,28 @@
+---
+title: Extensible Data File Formats
+created: 2026-06-29
+updated: 2026-06-29
+type: concept
+tags: [data-format, dev-tool, reliability, supply-chain]
+sources: [raw/articles/f3-file-format-2026.md]
+confidence: medium
+---
+
+# Extensible Data File Formats
+
+Extensible data file formats は、保存した時点の読み書き実装だけに縛られず、あとから新しい符号化、圧縮、索引、読み出し単位を足せるようにしたデータ形式の考え方。[[f3-file-format]] はこの方向を、列指向分析ファイルと WebAssembly 復号器の組み合わせで試している。
+
+既存の広く使われる形式は、互換性が強みである一方、一度広まった配置や符号化の前提を変えにくい。F3 の主張は、ファイルを「固定仕様に従うバイト列」としてだけでなく、「自分を読むためのメタデータと小さな実行物を持つ保存物」として設計すれば、古い読者と新しい符号化のあいだに橋をかけられる、というもの。
+
+## 見るべき軸
+
+- **自己説明性**: schema、列メタデータ、checksum、辞書、任意メタデータが、読み手の推測ではなくファイルに残るか。
+- **実行可能な拡張**: 未対応の符号化を Wasm などで安全に復号できるか。
+- **保存と実行の境界**: ファイルに実行物を含めると、互換性は増えるが、検証、砂箱化、供給網、安全性の設計が必要になる。
+- **再現性**: ベンチや論文の主張が、どの入力、どの環境、どの外部 fork に依存しているかを追えるか。
+
+## 他のページとの関係
+
+[[ghidra-mcp]] は、専門作業の手順や品質基準を道具の入口に寄せる例。extensible data file formats は、データを読むための知識をファイル形式側に寄せる例。どちらも [[wiki-maintenance-loop]] と同じく、後から読む人・使う人が毎回文脈を再発見しなくてよい状態を作ろうとしている。
+
+[[llm-wiki-pattern]] との共通点は、情報をただ置くのではなく、将来の読み手が利用できる形に編み直すこと。ただし LLM Wiki は人間と LLM のための知識整理であり、F3 は分析システムのためのバイナリ保存形式である。