クイックフォーマット後のNTFSメタデータ：WinHexによる分析
クイックフォーマット後のNTFSメタデータは、新たに初期化されたファイルシステムを表していますが、その下層には、以前のファイルシステムに由来する一部のレコードやファイルの内容が読み取り可能な状態で残っている場合があります。Windowsは新しいマスターファイルテーブル（MFT）とディレクトリ構造を作成しますが、単に古いファイル名をすべて非表示にするわけではありません。元のメタデータとそのメタデータが指すデータが十分に保存され、アクセス可能な状態であれば、復元は成功します。.
WinHex は、ブートセクタのフィールド、MFT レコード、およびデータ領域のマッピングを表示することで、これらの状況を区別するのに役立ちます。この記事では、NTFS から NTFS へのクイックフォーマットの事例と、別の MFT フラグメントの再構築例について検討します。 これらの計算は、すべての Windows ボリュームではなく、記録されたレイアウトに適用されるものです。SSD のディスクカード動作やその後の書き込みによって、結果が大きく異なる場合があります。.
目次
1. NTFSにおけるクイックフォーマットの変更点
について NTFSファイルシステム メタデータファイル、ディレクトリインデックス、およびクラスタマッピングを通じてファイルを整理します。クイックフォーマットを実行すると、これらの構造の新しいインスタンスが作成されます。.
構造 | クイックフォーマット後の役割 | 回復への影響 |
ボリュームのブートセクタとそのバックアップ | 新しくフォーマットされたボリュームについて説明してください | 現在のMFTポインタでは、古いテーブルを特定できなくなる可能性があります |
$MFT とルートディレクトリ | 新しいファイルシステムとその初期オブジェクトについて説明してください | 通常の閲覧では、以前のファイル名やディレクトリ間の関係が表示されなくなる |
| 新しいMFTに割り当てられたレコードを追跡する | そのテーブル以外の現存する記録はインデックスに登録されません |
$Bitmap | 新しいボリュームに割り当てられたクラスタを追跡します | 以前に使用されていたクラスターは、再利用可能になる場合があります |
$MFTMirr およびその他のシステムメタデータ | 新しく初期化されたファイルシステムをサポートする | 書き込み操作によって、古いメタデータやファイルの内容が上書きされる可能性があります |
以前のファイルデータの保存場所 | 上書きまたは破棄された範囲の外側に、読み取り可能なコンテンツが残っている場合があります | 生存は、当然のこととして想定するのではなく、確認しなければならない |
について マスターファイル表 それ自体がファイルです。その名前のない $DATA ストリームにはファイルレコードが含まれており、そのビットマップはレコードの割り当てを記述しています。別の $Bitmap ファイルは、ボリューム全体にわたるクラスタの割り当てを記述しています。これら 2 つのビットマップを混同すると、何が残っていたかについて誤った結論に至ってしまいます。.
既存のパーティションをフォーマットすることも、そのパーティションテーブルのエントリを削除することとは異なります。ボリュームのフォーマット処理では、選択したボリューム内部のファイルシステムが再構築されますが、パーティションの削除は、その外部のディスクレイアウトに関わるものです。.
2. WinHexで元のブートセクタを読み込む
NTFSフォーマット前後の16進数比較を行うには、フォーマット前にセクタイメージを保存し、フォーマット後に取得したイメージと比較してください。すでにフォーマット済みのソースについては、イメージおよび入手可能な以前のキャプチャデータに基づいて作業を行ってください。事象を再現するために、フォーマットを繰り返し行わないでください。.
について ボリューム・ブート・レコード クラスタアドレスを解釈するために必要なパラメータを提供します。.
WinHexのケース記録から抜粋した、元のブートセクタの16進数データ。赤い枠で囲まれた部分は、セクタサイズ、クラスタサイズ、およびMFTの位置を示すフィールドです。.
ブートセクタのオフセット | 記録されたバイト数 | 通訳 |
|
| 論理セクタあたり512バイト |
|
| クラスタあたり8つのセクター |
|
| $MFTはLCN 175,724,968から始まります |
|
| $MFTMirrはLCN 167,336,228から始まります |
|
| 符号付き値 −10：レコードサイズは 2¹⁰ = 1,024 バイト |
マルチバイト整数はリトルエンディアンのバイト順を使用します。その 割り当て単位サイズ したがって、次のようになります：
- 1クラスタあたり 512 × 8 = 4,096 バイト
LCNとは、ボリュームに対するクラスタ番号を指します。したがって：
- 元のMFTのボリューム相対セクタ = 175,724,968 × 8
- = 1,405,799,744
- 元の MFT のボリューム相対バイトオフセット = 175,724,968 × 4,096
- = 719,769,468,928
ディスク全体のイメージを解析する場合は、ボリュームの開始バイトオフセットを加算してください。ボリュームのみのイメージを解析する場合は、再度加算しないでください。WinHexに表示されるアドレス指定のコンテキストは、この計算結果と一致している必要があります。.
ブートセクタは、最初のMFTエクステントを特定します。ただし、テーブル内のすべてのフラグメントについて記述しているわけではありません。.
3. 元のMFTの非居住者データをデコードする
元のMFTの場所で、レコード0を検証し、その名前のない$DATA属性を特定します。次のコマンドを入力してください。 0x80. 非居住者属性は、レコード内の内容全体ではなく、マッピング情報を格納します。.
ケースノートでは、この属性はレコードのオフセット位置に配置されています 0x100. これにより、そのフォームバイトが 0x108; その値 01 は「非居住者」を意味します。これらの絶対オフセットはこのレコードに固有のものです。他のレコードでは、この属性を別の場所に配置することも可能です。.
別のレコードを解釈する際は、属性の開始位置を基準とした相対オフセットを使用してください：
相対オフセット | フィールド |
| 居住者・非居住者用フォーム |
| 最小の仮想クラスタ番号（VCN） |
| VCNが最も高いもの（これを含む） |
| mapping-pairs 配列に対するオフセット |
| 割り当て長 |
| 論理ファイルサイズ |
| 有効なデータ長 |
3つのサイズフィールドを個別に読み取ってください。「割り当て長」はストレージの予約量を表し、「論理サイズ」はストリームの長さを定義し、「有効データ長」は初期化されたデータの長さを表します。これらは必ずしも等しい必要はありません。.
VCN 0～98,431 の範囲において、クラスタ数は 98,431 ではなく 98,432 です。記録された 2 ランのレイアウトは次のようになります：
走る | クラスタ数 | 署名付き LCN デルタ | LCNの起動 | 各1,024バイトの論理レコードスロット |
1 | 75,096 | +175,724,968 | 175,724,968 | 0–300,383 |
2 | 23,336 | +83,118,309 | 258,843,277 | 300,384–393,727 |
2番目のアドレスは、直前の実行の 開始 LCN：
- 175,724,968 + 83,118,309 = 258,843,277
- (75,096 + 23,336) × 4,096 = 403,177,472 バイト
- 403,177,472 ÷ 1,024 = 393,728 レコードスロット
これらはアドレス指定可能なスロットであり、有効なファイルの数ではありません。一部のレコードは未使用の場合があり、1つのファイルに複数のレコードが必要となる場合もあります。.
記録された実行ヘッダー 43 そして 42 フィールドの幅を記述します。例えば、 43, 、長さは3バイト、LCNデルタは4バイトを占める。 42, 、長さは2バイト、デルタは4バイトを占めます。LCNのデルタは符号付きとして解釈してください。これは、後のフラグメントがボリューム上のより早い位置にある可能性があるためです。.
その結果、エクステントの長さは 384.5 MiB となりました。「385 MB」という丸め表示だけでは、異なる割り当てサイズを独自に立証することも、余分なクラスタが確保されていたことを証明することもできません。.
4. 新しいMFTと従来のレイアウトを比較する
ケースノートには、LCN 786,432 から始まり、エクステントが 180 クラスタであるポストフォーマット MFT が記録されています。記録されているクラスタサイズが 4,096 バイトであると仮定すると：
- 新しいMFTの開始バイトオフセット = 786,432 × 4,096
- = 3,221,225,472
- 新しいエクステントサイズ = 180 × 4,096 = 737,280 バイト
新しい開始位置は、ボリュームの3 GiB地点にあります。このアドレスは、この事例に基づく観察結果であり、NTFSにおける必須の位置ではありません。.
プロパティ | 元のレイアウト | メモに記録された投稿形式のレイアウト |
MFT LCNの起動 | 175,724,968 | 786,432 |
記録されたMFTエクステント | 2 | 1 |
補償範囲 | 98,432個のクラスター | 180のクラスター |
記録されたレコードサイズにおける容量 | 393,728スロット | 720スロット |
注記には、レコード0～717についても言及されている。これは718レコード、つまり735,232バイトに相当する。これは720スロット分を確保できる十分な割り当て容量と整合するが、718という数値が論理長、初期化長、あるいは検査されたレコード数を指すのかは定かではない。 これらのフィールドには、基となる属性バイトが必要です。.
重要な変更点は、Windowsが新しいテーブルに従うようになったことです。新しいMFTのサイズが小さくなったことで、 ない これは、古いテーブルがその場で物理的に切り捨てられたことを意味します。その元の保存場所については、個別に確認する必要があります。.
NTFSのMFTがフォーマットによって上書きされたかどうかを判断するには、元のMFTエクステントと、新たに書き込まれたすべてのメタデータおよびそれ以降の割り当てを比較します。ポインタが変更されていれば参照が変更されたことを示し、バイト単位の比較によって特定の位置で上書きが行われたことが確認できます。位置の変更だけでは、データが完全に残っていることも、完全に失われていることも証明できません。.
5. 残存する記録から断片化したMFTを再構築する
MFTの断片化は、テーブルが拡大し、連続した空き領域がなくなると発生します。NTFSでは、断片化を軽減するためにMFTゾーンを予約していますが、これにより単一のエクステントが確保されることは保証されません。テーブルの拡大に伴い、現在のエクステントの前または後に断片が割り当てられる可能性があります。.
本資料内の別の再構成例では、この3行レイアウトが示されています。これは、前の2行レイアウトと、あたかも両者が同じ表について記述しているかのように混同してはなりません。.
走る | 論理レコードスロット | LCNの起動 | 前回の実行開始時点からのデルタ | クラスター |
1 | 0–204,927 | 786,432 | +786,432 | 51,232 |
2 | 204,928–248,587 | 9,274,281 | +8,487,849 | 10,915 |
3 | 248,588–376,391 | 8,858,108 | −416,173 | 31,951 |
各4,096バイトのクラスタには、1,024バイトのスロットが4つ収まります。これにより、両方の境界が説明されます：
- 51,232 × 4 = 204,928 スロット
- 204,928 + (10,915 × 4) = 248,588
- 9,274,281 − 416,173 = 8,858,108
これらすべての実行を合わせると、94,098個のクラスタ、つまり385,425,408バイトに相当します。最終的なVCNは94,097です。.
候補者レコードの検索と検証
再構築のメモには、レコード204,928の検索、1つの候補を無効として除外したこと、および有効と認められた別の候補を特定したことが記載されている。一致する番号、あるいは ファイル 署名だけでは不十分です。.
読み取り専用イメージの場合：
- 検索
ファイル現在のMFT外の場所を含むシグネチャ。新しいテーブルのみに限定してスキャンを行うと、切り離されたレコードが見落とされます。. - レコードの境界、レコードの長さ、属性のオフセット、および属性の長さを確認してください。.
- 保護されたレコードのバイトを解釈する前に、更新シーケンス配列の妥当性を検証してください。記録された1,024バイトのレコードにおいて、そのチェックは2つの512バイトのストライドの末尾を網羅しています。.
- それらの境界をまたいで属性を解析する前に、パーサーのメモリに保存されたトレーラーワードを復元してください。エビデンスイメージにはパッチを適用しないでください。.
- 隣接するレコード、記録番号（ある場合）、名称、親レコードへの参照、およびシーケンス番号を比較する。不自然または古くなった関係は除外する。.
現存する古いレコード 0 が有効なランリストを提供している場合は、そのマッピングを使用する。それが欠落している場合、レコードのシーケンスからエクステントを再構築することは、追加の確認を必要とする仮説のままである。ある領域内に空白のレコードが存在するだけでは、それ以降のフラグメントが存在しないことを証明するものではない。.
論理テーブルを個別に再構築する
検証済みのエクステントを、VCN順で別の解析ファイルにコピーします。LCNの昇順で並べ替えないでください。上記の3回目の実行結果は、ディスク上では2回目の実行結果よりも前にありますが、論理的にはその後に続きます。.
記録番号について n, レコードサイズ R, 、およびクラスタサイズ C:
- VCN = floor(n × R ÷ C)
- クラスタ内のオフセット = (n × R) mod C
- LCN = ラン開始時のLCN + (VCN − ラン開始時のVCN)
3ランの例におけるレコード204,929の場合、VCNは51,232であり、そのクラスタ内オフセットは1,024バイトです。したがって、そのボリューム相対アドレスは次のようになります：
- 9,274,281 × 4,096 + 1,024 = 37,987,456,000 バイト
このマッピングでは、ファイルではなくアドレスが復元されます。レコードおよびその参照先データについては、引き続き検証が必要です。.
6. 古い属性を利用してファイルの内容を復元する
残存するファイルレコードの内容が把握できたら、その$DATA属性に基づいて抽出方法が決定されます。.
居住者データ： 属性の値のオフセットと長さを読み取り、検証済みでフィックスアップ処理が適用されたレコードからその値をエクスポートします。小さなファイルの場合、その内容がMFTレコード内に格納されているため、MFTレコードが上書きされると内容が失われることがあります。.
通常の非居住者に関するデータ： ファイル独自のランリストをデコードし、元のボリュームイメージから各エクステントを読み取り、バイトをVCN順に組み立て、出力を論理ファイルサイズに合わせて切り詰めます。MFTのランリストはファイルレコードの位置を特定するものであり、各ユーザーのファイルとデータの対応関係を置き換えるものではありません。.
属性が他のレコードにまたがる場合は、$ATTRIBUTE_LIST の参照に従ってください。スパースストリームおよび圧縮ストリームには、それぞれに対応するデコードルールが必要です。暗号化されたコンテンツについては、依然として適切な復号用素材が必要です。これらのケースでは、単純な連結だけでは不十分です。.
ディレクトリの復元には、特に注意が必要です。親ディレクトリが存在しなくなっても、ファイル名は残っている場合があります。参照とシーケンス番号が一致する場合にのみパスを再構築し、そうでない場合は、フォルダ間の関係を勝手に作り出すのではなく、孤立したファイルのままにしておくようにしてください。.
抽出したファイルを別の物理デバイスに保存してください。新しいブートセクタを編集して古いMFTを指すようにしても、ファイルの復元にはなりません。割り当てマップ、インデックス、システムレコード、その他のメタデータは、異なるファイルシステムインスタンスに属している可能性があるためです。.
7. 回復が成功する理由――そして失敗する理由
メタデータに基づく復元が成功するのは、古いレコードにはファイルの識別情報、論理サイズ、およびデータのマッピング情報が保持されており、マッピングされたコンテンツは読み取り可能なままであるためです。Windows のアクティブなネームスペースにはもはやこれらの情報が含まれていない場合でも、復元ツールはこれらの関係を追跡することができます。.
レコードが欠落している場合、署名ベースのカービングによってファイルの内容を直接特定できることがあります。通常、この方法では元のファイル名やディレクトリ構造が失われてしまうため、断片化されたファイルに対しては信頼性が低くなります。X-Waysでは、これらの異なる復元方法を反映し、現在のMFT外にあるNTFSレコードの検索を、ファイルヘッダーの検索とは別に行っています。.
新しいメタデータが元のレコードと重複したり、後のファイルが古いクラスタを再利用したり、断片化のマッピング情報が欠落したりすると、復元はより困難になります。有効なファイル名があるからといって、その内容が完全であるとは限りません。また、認識可能な最初のページや動画ヘッダーがあるからといって、その後の断片が保存されているとは限りません。.
SSDにはもう1つ条件があります。Windowsでのフォーマット処理により、TRIM/削除通知が送信される場合があります。マイクロソフトの フォーマット ドキュメントには以下が含まれます /NoTrim それらを消去するためです。これはフォーマット時のオプションであり、データ損失後の復旧手段ではありません。デバイスや保存先によっては、削除された領域は、WinHexなどで確認できるような従来の上書き処理が行われていなくても、元のバイトを返さなくなる場合があります。したがって、クイックフォーマットは、必ずしもデータの復旧を保証するものではありません。.
8. ディスクを再利用する前に、抽出したデータを確認する
検証が完了するまで、元の画像と範囲マップを保存しておいてください。実用的なスキャンおよびエクスポートのワークフローについては、以下を参照してください。 フォーマットされたハードドライブからファイルを復元する.
可能であれば、復元されたファイルをフォーマット前のインベントリと照合してください。ファイル名、サイズ、フォルダ構造、およびハッシュ値を既知のオリジナルと比較してください。ベースラインとなるハッシュ値がない場合は、ドキュメントを開いてページを確認し、アーカイブをテストし、画像をフル解像度で表示し、動画ファイルを最後まで再生してください。.
破損または欠落しているファイルは、検証済みのファイルとは別に記録してください。解析エラーのない状態で再構築されたMFTにより、読み取り可能なメタデータが確立され、エクスポートされた内容が利用可能であれば、ファイルの復元が成立します。完全な復元には、想定されるデータセットを考慮に入れる必要があります。.
よくあるご質問
クイックフォーマットを行うと、NTFSのMFT全体が上書きされますか？
MFTレコードが失われても、ファイルは残っているのでしょうか？
MFTミラーは、すべてのファイルレコードを復元できますか？
新しいボリュームビットマップのビットが「0」になっている場合、古いデータは消去されたことを意味するのでしょうか？
古いMFTレコードでも、まだ「使用中」フラグが設定されていることはありますか？
古いブートセクタを復元すれば、フォーマットは元に戻りますか？
