Mac用のHDDまたはデータリカバリラボ用のありふれたケース

診断のために、ロンバードファミリーからSeagateST4000DM000ドライブを受け取りました。クライアントの言葉から、ドライブがApple Macintoshコンピュータで使用され、その上でフォーマットされていること、および操作の全期間中に複数回であることが理解できました。ドライブの状態やファイルシステムの種類に関する質問には回答がありません。クライアントは、元のディレクトリ構造でファイルを復元する必要があるという一貫性のない説明しか提供しません。クライアントはまた、サービスの1つで、元の名前のないファイルが何らかのデータ回復プログラムを使用して取得されたことを明らかにしましたが、彼はこの結果に満足していません。







診断を開始する前の最初のステップは、ドライブの状態を評価することです。これはSeagateであるため、電源が投入された瞬間から端末ログを確認し、SMARTを実行して、さまざまな密度のゾーンでヘッドを読み取る機能を評価する必要があります。原則として、そのような短いテストは多くの欠点を明らかにします。



接続して電源を供給します。ターミナルでは、ドライブは開始手順が成功したことを簡単に報告し、DRDおよびDSCレジスタによって、コマンドを受け入れる準備ができていることを示します。





図：2 Seagate ST4000DM000 HDDの端末開始ログ



次に、SMARTの読み取り値を確認する必要があります（SMARTとは何か、その中で何を探すかについては、すでにメモで説明しています）。





図： 3 SMART読み取り値



最初に確認するのは動作時間（属性0x09）です。これは、ゼロに近いことが判明した場合、統計が誰かである可能性が高いため、SMART読み取り値に注意を払う意味がないためです。技術的なコマンドによってリセットされ、現在の読み取り値には、ドライブの動作中に記録されたすべてのイベントが表示されるわけではありません。私たちの場合、動作時間は3 696時間です。これは、SMARTの読み取り値に干渉がなかった可能性が高いことを示しています。



次に、RAW列の属性0x05、0xC5（197）、0xC6（196）の読み取り値に注意してください。ゼロ値は、ドライブの操作中に、表面からの読み取りに関する重大な問題が記録されておらず、再マップが実行されなかったことを示します。

属性0xC7（199）を読み取ると、高速モードでのデータ転送で発生する可能性のある問題が示唆されます。エラーの数が少ないという事実を考慮して、今のところ、時期尚早な結論を出すことはありません。



これはTiledRecorder （SMR）ではないため、次に、異なる密度のゾーンにあるすべてのヘッドを読み取る機能を簡単に評価できます。これを行うには、ヘッドの数、ミニバンドのおおよそのサイズ、およびドライブの論理空間を構築する際のそれらの交互の順序を知るだけで十分です。デモンストレーションにはDataExtractorを使用します。ミニスペースのマップを作成しましょう。





図： 4論理空間内のミニスペースのマップSeagateST4000DM000



リストは、ミニスペースを使用して論理空間を構築する順序を示しています：

0、1、2、3、4、5、6、7、7、6、5、4、3、2、1、0そして周期的な繰り返し。特定のドライブの1つのミニゾーンのサイズに基づいて、ドライブがフリーズせず、スキャン速度が急激に低下しないことを確認するには、約500,000セクターの長さの論理空間のいくつかのセクション（通常は論理範囲の最初、中間、および最後）を読み取るだけで十分であることは明らかです。表面の1つ。



データ転送中にエラーが発生するかどうかを同時に確認するために、検証ではなく、使用された表面から読み取りを行っていました。この場合、読み取りエラーは見つかりませんでした。この一連のアクションにより、ドライブを条件付きで正常であると見なし、ファイルシステムの構造の分析を開始できます。



最初に、ディスク上に現在パーティションが存在するかどうか、およびそこで使用されているファイルシステムを評価します。



セクター数が4,294,967,296セクターを超えるディスクでは、GPTを使用する必要があるという事実に注意を向けたいと思います。従来のパーティションテーブルは十分な幅ではない32ビット値を使用するため、全容量を使用します。この場合、ST4000DM000は4TBドライブであり、論理範囲は7,814,037,168の512バイトセクターで構成されています。



LBA0のコンテンツを見てみましょう。





図：5GPTの存在を説明するパーティションテーブル。



ここに、1つのボリュームの説明を含む従来のパーティションテーブルがあります。オフセット0x1C2では、パーティションタイプ0xEEは、ディスクの先頭から0x00000001セクターのオフセット、0x3A3817D5のサイズで示されます。



このエントリの目的は、クラシックパーティションテーブルで使用可能なディスクのすべてのコンテンツが占有されていることを示し、GPTについて知らないさまざまな古いディスクユーティリティがパーティションを作成できないようにすることです。ただし、セクター数が4,294,967,296を超えるディスクの場合、保護領域は0x3A3817D5ではなく0xFFFFFFFである必要があります。



値0x3A3817D5（976 754 645）は、ディスク上のセクターの総数である7 814 037168の約8分の1であることに注意してください。これにより、ディスクが512バイトではなく、4096バイトのセクターサイズのデバイスとして使用された可能性が高いと想定できます。仮定を確認して、正規式0x45 0x46 0x49 0x20 0x50 0x41 0x52 0x54（EFI PART）を検索してみましょう。セクター1にある場合、仮定は正しくありません。セクター8にある場合、仮定は確認されます。





図：6GPTヘッダー



このGPTにボリュームが記述されているかどうかも確認しましょう。セクター16に進みます。





図：で説明した7節GPT



二つのエントリがここで発見されました。



最初のレコードは、FAT32ファイルシステムを使用した76,800（614,400）セクターボリュームです。このボリュームは、EFIのニーズのために予約されています。



2番目のレコードは、HFS +ファイルシステムを使用した976644 858（7 813 158 864）セクターのボリュームです。



ディスクが4096バイトのセクターサイズのデバイスとして使用されたという事実のバージョンが確認されたので、次のステップはDataExtractorを使用して分析を続行することです。



タスクを作成したら、セクターサイズパラメーターを512から4096に変更して、次の図を取得します。





図： 8パラメータHFS +



正しいファイルシステムを持つディスク上の2つのボリュームが表示されます。役割とサイズに基づく最初のボリュームは、私たちに興味がありません。しかし、第2巻はすでに興味深いものです。



タイムスタンプから、このボリュームは2020年10月19日に作成されたと結論付けることができます。これは、ディスクが到着した時刻に比較的近い日付です。



CatalogFile + Journal（HFS +構造）をスキャンすると、ディスクが99.9％空であり、このファイルシステムによって記述されたユーザーデータの兆候がないことがわかります。



ここで、おそらく、このディスクには、現在提示されているものだけでなく、他のボリュームとファイルシステムがあったという仮定を確認する必要があります。これを行うには、ファイルシステムおよびファイルのさまざまな構造に固有のさまざまな正規式の検索ツールを使用します。





図： 9正規式検索結果。



2分未満続く約2GBの領域の分析は、既存のFAT32とHFS +に加えて、ExFATファイルシステムを備えたボリュームの存在の兆候があることを示しています。最初に関心があるのは、ボリュームのExFATルートディレクトリを表示することです。





図： 10ExFATルートディレクトリ



「トランセンド」ボリュームラベルが印象的です。奇妙なことに、このメーカーの外付けドライブは、3.5インチではなく2.5インチのフォームファクターで普及しています。また、ユーザー自身が同様のボリュームラベルを付けることを決定した可能性はほとんどありません。



ルートディレクトリに記述されているディレクトリの名前を書き留めて、それらが必要な情報であるかどうかについてクライアントに質問しましょう。



そのため、10分強が経過した後、クライアントとの会話を続けます。その間、クライアントは情報の所有者ではなく、ディスクに含まれているデータを明らかにすることができず、タスクを明確にするためにマネージャーに電話をかける必要があることがわかりました。 ..。



対話の過程で、クライアントはデータ回復サービス市場の仲介組織の宅配便業者であると想定することができます。クライアントが情報を発表した後、一時停止が彼のマネージャーに続くので、さらなる交渉はこのバージョンを確認します。どうやら、マネージャーはディスク上に正確に何があるべきかについても認識していません。しかし、約15分後、クライアントは、これが正確に抽出する必要のあるデータであり、そのボリュームは約2TBである必要があることを通知する呼び出しを受信します。また、WinHexを使用して作成された元のメディアのセクターごとのコピーが分析用に提供されていることも通知されます。



最後に、タスクが明確になり、正しい方向に進んでいることがわかります。顧客からドライブを再度取り出して、診断アクティビティを続行できます。もちろん、最初からこれらすべての情報があれば、エクスプレス診断手順ははるかに短くなります。



ExFATを再構築するには、このファイルシステムのクラスターのサイズを把握し、ゼロクラスター（参照ポイント）の位置を決定する必要があります。次に、ファイル割り当てテーブルの残りと占有スペースのビットマップ（ビットマップ）を探します。



ExFAT開発者については、別の不愉快な言葉を言う必要があります。ファイルシステムのパフォーマンスのために、テーブルにはフラグメント化されたチェーンに関する情報のみが含まれることが決定されました。インラインデータはテーブルに表示されません。空でないディスクにこのファイルシステムを作成しても、ファイルの場所のテーブルはクリアされず、ガベージデータが含まれている可能性があります。残念ながら、このイデオロギーは、データ回復の複雑さに最善の方法で影響を与えるわけではありません。



最初の2GBを分析すると、ExFATディレクトリの一部が見つかりました。これらの構造のサイズを推定し、他のデータを開始する前にさらにゼロを入力すると、クラスターサイズを簡単に確立できます。いくつかのディレクトリを参照した後、256（2048）セクターの顕著な間隔が表示されます。これにより、クラスターサイズが1,048,576（0x100000）バイトまたは1MBであると想定できます。



開始点を決定するために、近くのディレクトリの位置を見てみましょう。図10に戻って参照してください。特に、$ RECYCLE.BINディレクトリはほぼ最初にあるため、関心があります。そのクラスター番号はオフセット0x94で示され、値0x00000005が書き込まれるダブルワード（DW）です。つまり、ディレクトリはクラスター5にあります。また、オフセット0xF4で示された値に従って、ディレクトリ「Xxxxxxxxxxxxxxxx.photoslibrary」にも注意してください。 、クラスター7にあります。これらのディレクトリは、予測可能なディレクトリまたはファイルのセットがそこに期待される可能性が高いため、適切です。



0x100000バイトまたは256（2048）セクターのステップでルートディレクトリからさらに、アドレススペースを前方にスクロールします。





図：11 ExFATディレクトリ、場合によっては$ RECYCLE.BIN



内容は、「desktop.ini」ファイル以外は何も記述されていない空のごみ箱フォルダに似ています。オフセット0x34のファイルの場所は、クラスター6およびサイズ0x81（129）バイトを示します。もう1つのクラスターを前に進めましょう





図：12 Desktop.iniファイルの



内容内容は、ファイル「desktop.ini」に通常見られるものと非常によく似ており、サイズは0x81（129）バイトです。図11、$ RECYCLE.BINフォルダー、および図11を信じる理由があります。そこに記載されている12ファイル。仮定が正しければ、次のクラスターにディレクトリが表示され、その内容はおそらくAppleMacintosh上のMacOSの一般的なフォトライブラリフォルダのようになります。





図： 13ディレクトリExFAT、おそらくXXXXXXXXXXXXX.photoslibrary



ご覧のとおり、仮定は正しいことが判明し、予想されるディレクトリの名前が表示されました。この領域での一致の数は十分であると見なされ、かつて存在していたボリュームのゼロ点とルートディレクトリの位置を計算できます。

ルートディレクトリはクラスター4にあります。クラスター番号が5の$ RECYCLE.BINディレクトリの前にあるためです。



$ RECYCLE.BINを基準にしたゼロ点は、マイナス5クラスターの距離にある必要があります。 $ RECYCLE.BIN 37 888（303 104）セクターを配置します。 5つのクラスターは1280（10 240）セクターです。単純な減算を実行することにより、目的の位置を取得します：37,888（303104）-1,280（10240）= 36,608（292864）またはバイト単位の論理空間の先頭からのオフセットは292,864 * 512 = 149,946,368（0x8F00000）です。



さらに、参照の開始点、クラスターサイズ、およびルートディレクトリの位置を使用して、非常に多くのチェックで仮定の正しさを確認しようとします。



Data Extractorツールを使用すると、ExFATパーティションに対してこれを行うのはそれほど速くないため、ディスクをOSにマウントします（書き込みを無効にします）。





図： 14 PC3000 Win 7ディスクユーティリティのOSにディスクをマウントするためのメニュー



ソフトウェアセンターから無料のイメージエクスプローラーを使用します。ディスクを開くと、仮想ファイルシステムのパラメーターをすばやく記述し、仮定の正しさを評価できます。





図。 15展開されたExFATディレクトリツリー



スクリーンショットでわかるように、ディレクトリとファイルはそれらの場所にあり、ファイルシステムパラメータが正しく定義されていると結論付けることができます。



この時点で、診断アクティビティを停止して、次の作業リストをクライアントと合意できます



。1。論理空間全体で正規式を検索して、さまざまなタイプのデータの可能な場所を確立します。



2.1つのExFATセクションの少なくとも再構築。



3.新しい上書きされたデータとの交差の分析。



4.4。ビットマップとの交差点内の再構築されたファイルシステム上の既存のデータに関連して反転マップを作成し、これらの領域でユーザーデータを検索してから、見つかったものを並べ替えます。



仲介会社の場合、いつものように電話が始まり、最終的な所有者（私たちの研究室で彼のデータが復元されることをほとんど疑わない）の同意の後にのみ、作業を実行するための同意が与えられます。



サービス可能なディスクを使用する場合でも、作業は、別のドライブへのセクターごとのコピーの作成から始まります。この対策は、クライアントのドライブが変更されないままであり、OSイニシアチブが取り返しのつかないデータの破損につながることがないようにするために必要です。 4TBディスクの場合、PC3000Expressポートを介したコピーには約10〜12時間かかります。



コピーを作成した後、論理空間でのデータの分散を把握し、このディスクに他のパーティションやファイルシステムの兆候があるかどうかを確認するために、さまざまな正規表現の検索を開始します。





図： 16ドライブ全体での正規式の検索結果



スキャン結果は、ディスク上のユーザーデータがクライアントによって宣言された2TBよりもはるかに少ないことを示しています。最後のregexはセクター539877 376にあり、ディスクの終わりまで、新しく作成されたHFS +の終了マーカーを除いて、ユーザーデータに似たものは何も見つかりませんが、ディスクは最後まですべてゼロではありません。 ExFATパーティションがディスク上に作成される前に、ドライブに暗号化されたボリュームが含まれていた可能性があります。 「ノイズの多い」データのみの存在を説明するものは他にありません。



このような場合、regex検索結果をビットマップに一致させることが重要です。





図： 17ルートディレクトリExFATのセクターのフラグメント



オフセット0x34で、クラスター番号が2で示されます。これはExFATセクションのビットマップの位置です。オフセット0x38は、構造0x0746F1のサイズ（476,913バイトまたは3,815,304ビット）を示します。この構造を分析したところ、カードの隆起したビットは最初の270GBのみであり、カードによると、セクションは空であることがわかりました。つまり、ビットマップは通常の式の検索結果と一致しますが、どちらもクライアントの言葉と対立しています。



もちろん、そのような深刻な不一致が見つかった場合、作業は中断され、仲介クライアントに再度連絡して、質問への回答を得る必要があります



。1。分析のために提供された完全なセクターごとのコピーを実際に作成しましたか？



2.2。所有者は、このディスクに2TBのデータが含まれていることを本当に確信していますか？



3.確かに、270GBを超えるデータをこのディスクで受信できないことを認識して、データ回復の作業を続行することに同意しますか？



元のディスクへのリモートアクセスを通じて、最初の質問に対する答えを得ました。そして、ディスクエディタで、大きなステップでスクロールして、私たちが持っているコピーと比較しました。コピーが完了したことが判明しました。



2番目の質問に対する答えは、情報の所有者は、ディスクが2 TBでいっぱいになっていることを確認したと信じていたが、これについてはあまり確信が持てなかったというものでした。



しかし、より多くのデータがあったというクライアントのすべての自信を持って、それでも作業を継続することに同意が与えられます。



ファイルシステムを再構築する前に、断片化されたディレクトリがいくつあるかを把握しておくことをお勧めします。これを行うには、大まかな分析の結果を取得し、見つかったディレクトリのサイズを表示します。レコードのサイズがクラスターのサイズと等しいディレクトリがある場合、断片化が発生する可能性があります。レコードのサイズがクラスターのサイズよりも小さい場合、タスクは著しく単純化されており、ディレクトリフラグメントを手動でスプライシングする必要はないと見なすことができます。





図： 18見つかったExFATディレクトリのリスト



この場合、追加の問題は見つかりませんでした。ディレクトリ内のエントリの最大サイズは629,984バイトで、クラスターサイズよりも著しく小さくなっています。



また、新しく作成されたファイル構造が占めるすべての領域をマークする必要があります。これを行うために、FAT32およびHFS +パーティション上のすべての構造とファイルの場所のマップを作成します。





図： 19 HFS +ボリューム上の構造とデータのマップ



コピーのこれらの場所に、ユーザーデータと区別しやすいパターンを入力します。また、これらの領域のコピータスクで、凡例を正常な読み取りからエラーのある読み取りに変更します。これは、上書きによって破損したファイルをさらに検出するために必要になります。



Data Extractor分析ツールをさらに便利に使用するには、パーティションテーブルにセクションを記述し、ExFATパーティションのブートセクターを作成する必要があります。





図： 20



ExFATボリュームが登録されているパーティションのテーブルオフセット0x1D2で、ボリュームタイプ0x07を入力します。このタイプは、NTFSとExFATの両方に使用されます。

オフセット0x1D6で、ExFATボリュームの先頭へのポインター。 32セクター（0x20）とします。

オフセット0x1DAで、クラシックパーティションテーブルの最大許容ボリュームサイズを書き込みます（ただし、この値は実際のボリュームサイズよりも小さいですが、この破損したボリュームをどのOSにもマウントする予定がなく、次の場合にのみゼロ以外の値が必要なため、この場合は許容されます。データ抽出ツールの通常の操作）。





図： 21ExFATブートセクターDataExtractorはExFATブートセクター



の内容に非常に敏感であるため、重要なフィールドのみに入力するだけでは不十分な場合が多く（これはあまり論理的ではありません）、イメージエクスプローラーの診断の場合とは異なり、内部エクスプローラーでセクションを表示するのは簡単です。いい結果になる。したがって、ExFATブートセクターの場合は、標準のテンプレートを使用して正しい値を入力することをお勧めします。



便宜上、ドライブが512バイトのセクターを持つデバイスとして使用された場合の形式でブートセクターを記述します。これにより、不必要なマップの再構築なしで、複合体のすべてのツールの正しい操作が可能になります。



フィールドに入力します：

ブロックあたりのバイト数-セクターのバイト数。 ExFATは、サイズを取得するために2を上げる必要があるパワーを指定します。

クラスターごとのブロック-クラスター内のセクターの数。また、数量を取得するために2を上げる必要がある度合いも示します。

合計クラスターボリュームで使用可能なクラスターの数。値3815 304を入力します。これは、ビットマップのサイズに8を掛けることによって得られます。

合計ブロック数-セクター数。この値は、クラスターの合計にクラスターサイズを掛けることによって得られます（これは、ブロックあたりのバイト数にクラスターあたりのブロック数を掛けることによって得られます）

FATオフセット-ブートセクターからファイル割り当てテーブルへのオフセット。空の構造を作成し、セクター64から配置しましょう。標準のタイトルを追加します。

FATごとのブロック-FATテーブルが占めるセクターの数。そのサイズは、クラスターの数に基づいて簡単に計算できます。 FATあたりのブロック=合計クラスター/（ブロックあたりのバイト数/ 4）、さらに最も近い整数に切り上げます。 3815 304 /（512/4）= 29 807、0625 =29808。

（一部のソースがExFATを64ビットファイルシステムと呼ぼうとしても、ファイル割り当てテーブルは32ビットですが、FAT32とは異なり、アドレス指定には、28ビットではなく32ビットが使用されます。）

FATの数-テーブルコピーの数。残念ながら、パーティションを作成する場合、通常は1です。

クラスターヒープオフセット-ビットマップへのオフセットをセクター単位で示します。

ルートディレクトリクラスター-ルートディレクトリのクラスター番号。



セクションがDataExtractorエクスプローラーで使用可能になったら、ビットマップを使用して占有スペースのマップを作成します。





図：22ビットマップによるExFAT構造とユーザーデータによる占有スペースのマップ。



また、既存のファイルレコードに基づいてファイルの場所のマップを作成し、ファイルがディスク上にある順序で並べ替えて、ビットマップデータと比較します。





図： 23 ExFATボリュームで使用可能なファイルの場所のマップのフラグメントファイルの場所のマップを作成



した結果に基づいて、718528から57131 008までの論理範囲にかなり広範な「穴」が観察されます。この領域がユーザーデータによって占められていることは、ビットマップ上で明らかです。また、ディスク全体で規則的な表現を検索すると、この領域にデータの兆候が見つかりました。



この場合、このファイルシステムの損傷の事実と、さらなる分析アクションの必要性が確認されます。



ファイルの場所のマップを反転して、既存のファイルレコードで記述されていないスペースのチェーンのリストを取得します。サイズがクラスターのサイズよりも小さいすべてのチェーンを削除します。これらは、書き込まれたユーザーデータによって完全に占有されていない空きクラスターフラグメントになるためです。ビットマップにマップし、これらの範囲から重複する文字列のみを残します。



残りの結果は、さらに分析の対象となります-ExFATディレクトリを検索します。エントリを形成するディレクトリを作成しましょう。見つかったディレクトリへのポインタと、見つかったディレクトリのフラグメントからのエントリを入力します。見つかったディレクトリは、使用可能なディレクトリと交差するエントリの内容をチェックし、それらの関係を確立し、これらのディレクトリのエントリが指すファイルヘッダーの対応をチェックして、無関係なディレクトリを除外する必要があります。ディレクトリの損失は、ディスクの悪用中のファイルシステムのエラーと、ディスクに書き込まれた新しいデータの部分的なオーバーラップの両方が原因である可能性があります。





図： 24親オブジェクトを持たない見つかった構造へのポインターを持つディレクトリ。



さらに、失われたディレクトリで見つかったオブジェクトでファイルの場所のマップを補足したので、ビットマップとの交差を考慮して反転マップを作成する手順を繰り返します。このようにして得られたチェーンでは、さまざまなタイプのユーザーファイルの正規表現を検索する必要があります。



これは分析作業の最終段階であり、その結果はユーザーデータの残りになり、ファイルシステムの場所を説明する要素はありません。これらの対策により、ユーザー自身が以前に削除した可能性のあるデータからのさまざまなゴミを最終結果に含めないようにしたことに注意してください。



これらの操作が完了すると、「エラーで読み取られた」ファイルセクターの場所のマップ内の存在を考慮して、見つかったデータのコピーを開始し、新しいデータで一意に上書きされたファイルを削除できます。FAT32およびHFS +機能マップを作成した後、「エラー付き読み取り」マークを作成しました。



これで作業は完了です。断片化されていないファイルの可能な最大の結果は、元のディレクトリ階層を維持しながら得られ、ほとんどすべての可能な失われたファイルは、この結果に自動回復プログラムに典型的なさまざまなガベージデータを含めずに見つかりました。



前の投稿：ハードドライブの自己診断とデータ回復