☰

手動 NTFS 回復の健全性チェック

tag-icon • tag-icon ntfs hard-drive-recovery file-recovery
手動 NTFS 回復の健全性チェック

これまでのところ、手動​​の NTFS 回復プロセスが行き詰まってしまったので、妥当性チェックをしてくれる人が必要です。

背景：

  • 私は主に写真が保存されている 1TB の NTFS 外付けドライブ (WD Elements) を持っていました。
  • 何らかの理由で破損しており、Windows 上では未加工のディスクとして表示されます。
  • これは Linux システムでは/dev/disk/by-path(およびby-idなどby-uuid) ディレクトリ内に表示され、 として表示されます/dev/sdb。
  • EaseUS は、クイックスキャン（重労働のディープスキャンではありません）で、（ほぼ？）すべての写真を見つけることができます。
  • EaseUS は約 70 GB のファイル (主に写真) を検出しました。
  • NTFS レコードが破損していると思われます。つまり、機械的な故障ではありません。
  • 楽しみと利益のために自分で回復を試みたいと思います。
  • 破損したドライブの完全なイメージを作成するのに十分な大きさの別のドライブがありません。

次の理由により、NTFS MFT $File レコードを解析する必要があります。

  • 元のファイル名とディレクトリ構造に戻したいと思います。
  • イメージが連続したクラスターに書き込まれていない場合、イメージ ファイルの署名を探すだけでは正常に復元できません。

計画は次のとおりです。

  1. 破損したディスクの一部をイメージ化します。
  2. 解析して MFT $File レコードを識別し、読み取ります。
  3. $File レコード (具体的にはその $Data 属性) を使用して、各ファイルのデータ実行を決定します。
  4. ファイルのデータ実行がわかっているので、 を使用して作成したイメージからファイルのバイトを選択できますddrescue。
  5. 終わるまで繰り返します。

まず、それは合理的な計画のように思えますか?

私がやったこと:

  1. 多数の$Fileレコードが見つかりました
  2. 1つを解析してデータ実行を取得
  3. データ実行によって指定された場所にある生のバイトを読み取ります。

具体的には：

  1. ddrescue破損したディスクの 100 GB (0 から開始) をイメージ化するために 使用されます。
    1. 対象データの合計容量が 70 GB なので、実際に必要なデータのほぼすべてが最初の 100 GB 内に書き込まれていると考えられます。必要に応じて、このプロセス全体を後続の 100 GB の部分に対して繰り返すことができます。
    2. 最初の 100GB をイメージ化するために使用したコマンドは ですddrescue /dev/sdb ~/mydisk.img ~/mydisk.map --size=100G。
    3. ddrescueI/O エラーが発生し、約 99.57% しか回復しなかったと報告されました。
    4. イメージの先頭部分 (最初の 20 MB 程度) は空っぽのようですので、これがドライブ障害の原因である可能性があります。今のところは無視します。
  2. 100 GB のイメージを読み取り、MFT 内の $File レコードの開始を示す ASCII 文字列「FILE」のすべてのインスタンスを特定しました。
    1. これは、任意のファイルの途中に「PROFILE」という単語があるなどの誤検知でもトリガーされます。
    2. したがって、"FILE" の 1 つの出現と次の出現の間の距離が 1024 バイト以下である結果のみを検討します。これは、これが最大 MFT レコード サイズだからです。"FILE" の 1 つの出現と次の出現の間に 3MB がある場合、$File レコードである可能性は低くなります。
  3. 推定される $File レコード (サイズ <= 1024 バイト) と抽出された $Data 属性を反復処理します。
  4. データ実行のために解析しました (常駐属性と非常駐属性に関する議論は無視しました。この議論は理解していると思いますが、私の質問の一部ではありません)。

そこで、上記のプロセスを実行して、$File レコードの 1 つを選択し、そのデータ実行を特定しました。$Data 属性 (ヘッダーと内容) は次のとおりです。

80 00 00 00 48 00 00 00  01 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00  FA 03 00 00 00 00 00 00
40 00 00 00 00 00 00 00  00 B0 3F 00 00 00 00 00
F4 AC 3F 00 00 00 00 00  F4 AC 3F 00 00 00 00 00
32 FB 03 ED C8 11 00 00  FF FF FF FF 82 79 47 11

FF FF FF FFデータ実行の詳細は、属性マーカーの終了直前の最後の行の前半です。

  • 長さバイト:32
  • クラスター実行数: FB 03(リトルエンディアン) = 実行中のクラスター数は 1019
  • クラスター開始番号: ED C8 11= 1165549 は実行の最初のクラスターです
  • 次は、00これ以上実行がないことを示します。

ここで、セクターあたり 512 バイト、クラスターあたり 128 セクターがあることを考慮すると、(1165549 * 128 * 512) から始まる 100 GB イメージから (1019 * 128 * 512) バイトを読み取ります。

残念ながら、その結果、66.8 MB のファイル (ほとんどが 0x00 ですが、最後の方にデータがありました) が残りました。何か間違っていて、偶然データを見つけただけだと思います (ただし、JPG のファイル終了マーカー (DD F9) で終了しました)。

このタスク全体に対する私のアプローチは妥当であり、どこかで小さな間違いを犯しただけでしょうか?

それとも、NTFS に関する基本的なことを私が誤解していて、これが完全に間違った考えなのでしょうか?

答え1

まず、それは合理的な計画のように思えますか?

いいえ。デコード実行の方法を詳しく調べたわけではありませんが、開始クラスターはファイル システムの開始 (NTFS の場合はボリューム/パーティションの開始) を基準にしています。したがって、クラスター番号を指す MFT エントリは、ボリュームの任意の 100 MB 部分を基準にしているのではなく、パーティションの開始を基準にクラスター番号を指しています。

また、MFTは「自己参照」なので、まずはMFTの始まりを見つけてそこから導出するようにしてください。全てMFT エントリ。MFT の開始が見つからない場合は、代わりに MFT のミラーを探してみてください。

したがって、MFT エントリを適切にデコードし、参照しているデータを取得するには、次のものが必要です。

  • パーティションの先頭までのオフセット。
  • 正しいクラスターサイズ

したがって、開始クラスターをデコードすると、次のようになります: (クラスター番号 * セクター / クラスター) + オフセットパーティション

クラスターあたり 128 セクターをどうやって決定したのですか? これはまったく正しくないようです! デフォルトはここで参照してください:https://www.disktuna.com/default-cluster-sizes-for-fat-exfat-and-ntfs/。

答え2

損傷したディスクを、あなたが説明したような読み取り負荷にさらすのは、プロらしくありません。まず必要なのは、そのドライブを安定した正常なドライブに複製して、追加のセクターの損失を防ぎ、読み取り不能なセクターをなくすことです。読み取り不能なセクターをコピーできなかったのは残念ですが、重要なのは、読み取りエラーを処理するために、ユーザーや回復プログラムを使用しないようにすることです。

回復の試みによって、すでにそのドライブにさらなる損傷が生じている可能性があります。

メタデータ構造とデータは必ずしも直線的にレイアウトされているわけではないため、100 GB のスライスを後でどこかの空きドライブ ストレージに読み込んでも、十分な大きさのドライブを少なくとも 1 つ所有していないことを補うことはできません。ランダム アクセスが必要です。残念ながら、このケースでは、構造が次の 100 GB スライスを指すと、100 GB のストレージ領域を空にする必要があります。

すでに好みのプログラミング言語で構造を解析している場合は、コピー ジョブに dd などの Unix コマンドを実行する必要はありません。ddrescue は、回復試行の開始時に 1 回だけ必要です。

NTFS の内部構造を学習したいだけなら、それはそれで結構ですし、素晴らしいことですが、USB スティックなどのストレージで既に学習できます。大容量のドライブは必要ありません。

Easeus がファイル名やフォルダ構造などの必要なメタデータを回復できなかった理由について考えてください。

答え3

ドライブは、クラスター 0 のセクター 0 のバイト 0 から始まり、物理ドライブの最後まで線形であると考えていました。

はい、またいいえです。ストレージ アドレスは、バイト 0 から始まる線形です。セクター アドレスも線形です。

クラスター アドレスは線形で、クラスター番号 0 から始まりますが、それぞれのパーティションに対して相対的です。ディスク全体のクラスター ラベルはなく、0 から始まるパーティション全体のクラスター ラベルのみです。

つまり、ddrescue のようなツールを使用してバイト 0 - 1000000 を読み取る場合、レイアウトを記述する NTFS メタデータが読み取られているとは期待できないということですか?

NTFS メタデータには、ブート セクターだけでなく、マスター ファイル テーブルやその他のファイルも含まれます。ドライブの先頭から 1 MByte を読み取る場合、マスター ファイル テーブルがそこに配置されている場合は、その一部のみが読み取られます。その位置は固定されておらず、デフラグ時に変更される可能性があります。

ここで、この戦略を使用してファイル システムについて実験し、学習します。 https://forum.cgsecurity.org/phpBB3/viewtopic.php?p=31304#p31304

NTFS を解読しようとする場合、意図した結果をすでに知っている方がはるかに有利です。これは、プレーンテキスト全体がわかっている「既知プレーンテキスト攻撃」のような一種の解読プロセスです。

誰かが私の回答に低評価を付けました。それがあなたなら、理由を説明してください。どこかに間違いがあるのでしょうか? 知りたいです! ありがとうございます。

関連情報