前回の記事「何故、上書きされたデータは復元できないのか?」では、MFT内に収まる小さなファイルで上書きのテストを行いました。 では、MFT内に収まらない大きなファイルではどうでしょう。 さっそく、試してみました。 ■テスト方法 1. 小さいファイルを作成し、MFT内のFRS(File Record Segment)セクタを確認する。 2. そのファイルを上書き保存し、大きなファイルにする。 3. FRSセクタを確認し、インデックスに記されたデータセクタを確認する。 4. ファイルをさらに上書きし、データセクタの変化を調べる。 今回のテストで Disk Probe は、Physical Drive でなく Logical Volume で開いています。 というのは、FRSのインデックスはクラスタで記されているからです。 ■テスト結果 テストファイル名:vvvvwwwwxxxx.txt 最初の小さいサイズの状態です。データがFRSに収まっています。 セクタは、347244 。この番号は、ボリューム内での番号です。 [図1 - 最初の状態] テスト1 - 大きなファイルにするvvvvwwwwxxxx.txtをメモ帳で開き、文字列を増やして上書き保存します。 "vvvvwwwwxxxx"をたくさん追加しました。 増やした後のFRSです。 [図2 - 大きなファイル] データは他のクラスタに保存され、代わりにインデックスが作られました。 インデックスは、01D0行のこの部分です。
細かく分けると、こんな感じです。
このデータは、2箇所に断片化していることがわかります。 「番号」はまちまちで、どんなルールでつけられているのかよくわかりません。 さて、さっそくデータ部分を見てみます。 セクタ数をクラスタ数から求めるには、次のようにします。 セクタ数 = クラスタ数 * ( クラスタサイズ / セクタサイズ ) まず、クラスタ数を16進数から10進数に変換します。 例によって、リトルエンディアンで後ろから格納されています。 一つ目:0x083172 → 536946 二つ目:0x00261F → 9759 それぞれ、セクタ数に変換します。 テストに使ったマシンでは、Cドライブのクラスタサイズは 512 バイトでした。 (クラスタサイズは、デフラグツールの分析やチェックディスクのログなどで知ることができます) 一つ目:536946 * (512 / 512) = 536946 二つ目:9759 * (512 / 512) = 9759 さて、このセクタ数をどこから数えれば良いのかちょっとわからなかったので、とりあえずFRSのセクタ数に加えてみました。347244 + 536946 = 884190 です。 さっそく覗いてみると、なんだか関係ないところです。 そこで、単純に 536946 を覗いてみました。すると、ありました。 [図3 - 最初のデータのセクタ 536946] さて、次に二つ目のデータ部分です。 セクタ数が 9759 と小さいので、これはたぶん一つ目のデータのセクタ数に足すに違いないと思い、 9759 + 536946 = 546705 を覗いてみました。 すると、やはりありました。 [図4 - 二つ目のデータのセクタ - その1] このデータ部分は、セクタ 546705 から 546706 までの2セクタを使用しています。 546706 は、以下のようにデータが途中まであり、残りは 00 で埋められています。 [図5 - 二つ目のデータのセクタ - その2] テスト2 - ファイルをちょっと小さくする次にファイルのサイズを小さくしたらどうなるか試してみました。 メモ帳で数行削り、代わりに"notepad notepad"と書き込みました。 書き込んだ後のセクタ 546705 がこれです。 [図6 - 変更後の二つ目のデータのセクタ] 見ての通り、セクタ内の余った部分は、全て 00 で埋め尽くされていました。 その次のセクタ 546706 には、変更前のデータの残骸が残っていました。 [図7 - 変更前のデータの残骸] 以上、MFT内にデータが収まらない大きなファイルの場合も、「上書き保存」とはハードディスクのデータそのものを上書きするものだということが確認できました。 また、上書き内容が小さい場合は、前の残骸が残ることも確認できました。 関連記事: 参考サイト: 資料: |
<< 前記事(2005/02/15) | トップへ | 後記事(2005/02/22)>> |
タイトル (本文) | ブログ名/日時 |
---|
内 容 | ニックネーム/日時 |
---|
<< 前記事(2005/02/15) | トップへ | 後記事(2005/02/22)>> |