@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

メモリダンプ イメージの整合性

米国ではすでにどこかで議論された話題なのかもしれませんが、物理メモリのダンプイメージについては、最近気になっている点があります。
ファイルシステムのイメージを作成する場合、物理セクタ 0 から順番にといった具合にデータを読み込んでイメージファイルに書き出すので、windd などのメモリダンプツールについても似たような、メモリの上位or下位?などのアドレスから順番にデータを読み込んでいるのかなと推測しています。詳しくは確認していませんが、恐らくカーネルメモリ空間がある領域から先にダンプされイメージファイルに書かれていくことになるのではないかと勝手に想像しています。
搭載メモリ容量が大きな場合にはイメージの取得に少し時間がかかるかと思いますが、その場合にダンプしたメモリのイメージファイルの解析段階で矛盾が発生しないのか?という懸念が個人的にあります。

1.プロセスAがメモリ1234番地辺りの空間を使用中
2.メモリのダンプが開始される
3.カーネル空間がイメージファイルに出力される(プロセスAは1234使用という情報を含む)
4.プロセスAが終了しメモリ1234番地を解放する
5.プロセスBがメモリ1234番地辺りの空間を使用する
6.ダンププロセスがメモリ1234番地辺りをイメージファイルに出力する
7.メモリダンプが完了する
8.解析ツールでイメージファイルを読み込む
9.プロセスAがメモリ1234番地を使用していると解析結果をツールが表示する
10.しかしメモリ1234番地のデータはプロセスBが書き込んだデータとなっているがツールは識別できない

実際にこのような流れになりえるのか十分には理解できていないのですが、いずれにしても OS を STOP してメモリダンプするわけではないとすると、管理情報と実際のデータとの整合性が取れない可能性がある気がしますが、どうなんでしょうかね?
実はかねてからの疑問なので、今度 id:xna さんとかにお会いする機会があればぜひ詳しく伺ってみたいと思っていることだったりもします。
128MBとかであれば一瞬でダンプできるかもしれませんが、数ギガとかの世界ではメモリダンプにはそこそこお時間かかりますし、イメージファイルを書き出す先のメディアが遅いと悲劇的かもしれません。
メモリについてもスナップショットを作成し、変更による矛盾が発生しないようにスナップショット経由でイメージを取得する方法が取れるのであれば、この手の問題は発生しないかもしれませんが、その手のオプションなどを見かけたことがないんですよね。
仮想環境上の OS ならいざしらず、物理メモリに対するスナップショットというのがどの程度現実的なものなのか謎ですが...