【要約】ClaudeのIndexedDB解析でplyvelが地雷だった話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
筆者がClaude DesktopのDispatch機能のログを抽出するため、Electron内部のIndexedDBを解析しようとした際、以下の2つの問題に直面した。
- ・Pythonのplyvel使用時、依存するlibleveldbがRTTI無効でビルドされているため、import時にシンボルエラーが発生する。
- ・Node.jsのlevel使用時、Chromium独自のComparator「idb_cmp1」と既存のComparatorが一致せず、DBのオープンに失敗する。
- ・IndexedDBのキーは型ごとに順序が厳密に定義されており、標準的なmemcmpでは正しい順序を維持できない。
// Approach
筆者はIndexedDBの解析を完遂するために、以下の4つの回避策を検討した。
- ・フォレンジック用ツール「ccl_chromium_reader」を利用し、独自ComparatorとV8構造化複製をまとめて処理する。
- ・Chromiumの仕様に基づき、plyvelのComparatorサブクラスとして「idb_cmp1」を自前で実装する。
- ・Chrome DevTools Protocol (CDP) を介して、外部からDevTools経由でデータにアクセスする。
- ・自動化の工数を見直し、手動でログを記録する運用へ切り替える。
// Result
筆者は解析の頻度と自動化コストを比較検討し、以下の結論を得た。
- ・運用面では、自動化の工数が回収できないため、手動での記録が最も効率的であると判断した。
- ・技術面では、自動化を本気で行うなら「ccl_chromium_reader」の検証が最短経路であると特定した。
- ・解析には、キーのデコードだけでなく、V8 structured cloneのデシリアライザも必要であることを明らかにした。
Senior Engineer Insight
> 基盤ライブラリのビルドオプションや、上位プロトコルの仕様を無視すると、標準ツールは機能しない。特にElectron等の複雑な環境では、データの物理構造だけでなく、アプリケーション層が定義した比較ロジックやシリアライズ形式まで考慮した深い洞察が不可欠である。自動化のコスト対効果を冷静に見極める判断力も、実戦では重要となる。