破損した PCAP ファイルの修復は、ブラインド変換ではなく証拠から始まります

PCAP ファイルが破損していると、最悪のタイミングで調査が中止される可能性があります。キャプチャは、顧客サイト、研究室での再現、または生産インシデントからの唯一の証拠である可能性があります。ツールがファイルを開くことを拒否した場合、最も早い衝動は、ファイルを変換したり、トリミングしたり、別のパーサーで実行したりすることです。

それはうまくいきます。また、何が問題だったかを説明する手がかりが破壊される可能性もあります。修復は証拠から始める必要があります。

障害境界を特定する

ファイルを変更する前に、どこで問題が発生したかを特定してください。

• グローバルヘッダーを読み取れません
• リンクタイプが予期せぬものです
• パケットヘッダーが不完全です
• キャプチャされた長さが残りのファイル サイズを超えています
• 元の長さとキャプチャされた長さが矛盾しています
• タイムスタンプフィールドが無効に見える
• パケットデータが切り捨てられる
• 最後の有効なパケットの後に後続バイトが残る

それぞれの障害は、異なる修復戦略を意味します。不正なグローバル ヘッダーは、切り詰められた最後のパケットと同じではありません。間違ったリンク タイプは、チェックサム オフロードの混乱とは異なります。

オリジナルのキャプチャを保存する

元のキャプチャを決して上書きしないでください。修復ワークフローでは、新しいファイルを作成し、変更内容を記録する必要があります。元のファイルがサポート案件、法的調査、またはベンダーのエスカレーションの証拠である場合、元のバイトが重要になります。

規律あるワークフローにより、次のことが維持されます。

• 元のファイルのハッシュ
• パーサー障害の場所
• 失敗するまでの有効なパケットの数
• トリミングまたは書き換えられたバイト
• 影響を受けるパケットインデックス
• 出力ファイルのハッシュ
• 編集が安全である理由を説明するメモ

これは官僚主義ではありません。これは、エンジニアがキャプチャの信頼性を低下させることを回避する方法です。

一般的な破損パターン

PCAP の破損ケースの多くは単純です。

• キャプチャプロセスが書き込み中に中断されました
• ファイルはライターが閉じる前にコピーされました
• ディスク容量が不足しました
• ツールが無効なパケット長を書き込みました
• 間違ったファイルタイプの名前が「.pcap」に変更されました
• リンク層の期待値がペイロードと一致しません

修復はパターンと一致する必要があります。最後のパケットのみが不完全な場合は、最後の部分レコードをトリミングすると、有用なプレフィックスが回復される可能性があります。ファイル全体でパケット長が一貫していない場合は、再書き込みの前にキャプチャをより詳細に検証する必要がある場合があります。

修復を正規化として扱わないでください

修復とは、可能な限り有効な証拠を保存することを意味します。正規化とは、データを望ましい形状に書き直すことを意味します。それらは別の仕事です。

たとえば、タイムスタンプの変更、チェックサムの再計算、またはリンク層ヘッダーの書き換えは、後で役立つ可能性がありますが、これらの操作を最初の回復ステップに混ぜるべきではありません。まずは信頼できるものを回収します。次に、管理された手術が適切かどうかを判断します。

PCAP 手術が適している場所

PCAP Surgery は、慎重なキャプチャ証拠のレビューと制御された書き換えワークフローを実現するために構築されています。広範なパケットプレーヤーになったり、あらゆる分析ツールの代替になったりしようとしているわけではありません。その役割は、エンジニアがキャプチャのメタデータを検査し、ファイルの失敗箇所を特定し、証拠が操作をサポートする場合にのみ編集を適用できるように支援することです。

破損したファイルの場合、貴重な出力は次のとおりです。

• ファイルのどの部分が有効ですか
• 解析が失敗する場所
• どのような修復アクションが適用されたか
• どのパケットまたはバイトが影響を受けたか
• 結果のファイルをダウンストリーム ツールで開けるかどうか

それが、「コンバーターを動かしたこと」と「修理について説明できること」の違いです。