在开始诊断之前，第一步是评估驱动器的状态。由于这是希捷（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）表示在高速模式下数据传输可能存在问题。考虑到错误数量很少的事实，目前我们不会过早得出结论。
由于这不是切片记录器（SMR），那么很容易评估读取不同密度区域中所有磁头的能力。为此，在构建驱动器逻辑空间时，只要知道磁头的数量，微带的大概大小及其交替顺序就足够了。我们将使用数据提取器进行演示。让我们建立一个小空间的地图。
数字： 4逻辑空间中的微型空间映射Seagate ST4000DM000
列表显示了使用微型空间构建逻辑空间的顺序：
0、1、2、3、4、5、6、7、7、6、5、4、3、2、1、0然后循环重复。根据给定驱动器的一个迷你区域的大小，很明显，读取大约500,000个扇区的逻辑空间的多个部分（通常是逻辑范围的开始，中间和结尾）足以确保驱动器不会冻结并且扫描速度不会急剧下降。表面之一。
它是从所使用的表面读取而不是验证，以便同时检查数据传输期间是否会发生错误。在这种情况下，没有发现读取错误。这组操作使您可以将驱动器视为有条件的运行状况，并开始分析文件系统的结构。
最初，我们将评估磁盘上当前是否存在任何分区以及在磁盘上使用了哪些文件系统。
我想提请您注意以下事实：在扇区数大于4,294,967,296的磁盘上，必须使用GPT要使用全部容量，因为经典分区表使用的32位值不够宽。在我们的案例中，ST4000DM000是一个4TB驱动器，其中逻辑范围包括7,814,037,168个512字节扇区。
让我们从查看LBA 0中的内容开始。
数字： 5分区表描述了GPT的存在。
在这里，我们找到一个经典的分区表，其中包含一个卷的描述。在偏移量0x1C2处，分区类型0xEE的指示位置是距磁盘开头的偏移量0x00000001扇区，大小为0x3A3817D5。
此项的目的是指示所有可用于经典分区表的磁盘内容均已被占用，以使各种不了解GPT的旧磁盘实用程序都无法创建该分区。但是，对于扇区数大于4,294,967,296的磁盘，保护区域必须为0xFFFFFFF，而不是0x3A3817D5。
请注意，值0x3A3817D5（976 754 645）大约比7 814 037 168（磁盘上的扇区总数）小8倍。这使我们可以假设磁盘最有可能用作扇区大小为4096字节而不是512字节的设备。让我们检查一下假设并尝试搜索正则表达式0x45 0x46 0x49 0x20 0x50 0x41 0x52 0x54（EFI PART）。如果在扇区1中，则该假设是不正确的；如果在扇区8中，则该假设将被确认。
数字：6 GPT标头
还让我们检查一下该GPT中是否描述了任何卷，为此我们转到扇区16
数字： 7 GPT中描述的部分
此处找到两个条目。
第一条记录是使用FAT32文件系统的76,800（614,400）个扇区。该卷是为EFI需求保留的。
第二个记录是使用HFS +文件系统的976 644 858（7 813 158 864）扇区的数量。
由于已确认使用该磁盘作为扇区大小为4096字节的设备的版本，因此下一步将是使用Data Extractor继续分析。
创建任务后，将扇区大小参数从512更改为4096，并得到以下图片。
数字： 8参数HFS +
我们在磁盘上看到两个具有正确文件系统的卷。基于角色和规模的第一卷对我们不感兴趣。但是第二卷已经引起人们的兴趣。
从时间戳记中，我们可以得出结论，该卷是在2020年10月19日创建的，这是相对于光盘到达我们的时间而言相对较近的日期。
扫描CatalogFile + Journal（HFS +结构）显示磁盘为99.9％空，并且没有文件系统描述的用户数据迹象。
现在，有必要检查以下假设：也许在该磁盘上还有其他卷和文件系统，而不仅仅是现在显示的那些。为此，我们将使用搜索工具查找各种特定于文件系统和文件结构的正则表达式。
数字： 9正则表达式搜索结果。
对持续时间不到2分钟的大约2 GB区域的分析表明，除了现有的FAT32和HFS +外，还有迹象表明ExFAT文件系统存在卷。我们感兴趣的第一件事是查看该卷的ExFAT根目录。
数字： 10 ExFAT根目录
“ Transcend”卷标引人注目。奇怪的是，该制造商的外部驱动器以2.5英寸（而非3.5英寸）的尺寸广泛使用。而且，用户自己不太可能决定贴上类似的卷标。
让我们写下根目录中描述的目录的名称，并询问客户机有关它们是否是必需信息的问题。
因此，经过10多分钟后，我们继续与客户进行对话，结果表明他不是信息的所有者，无法说明磁盘上包含的数据，并且他需要打电话给经理以澄清任务...
在对话过程中，可以假定客户是数据恢复服务市场中中介组织的快递员。进一步的协商确认了该版本，因为在客户宣布信息后，经理会停顿一下。显然，管理器也不知道磁盘上到底应该包含什么。但是大约15分钟后，客户端会收到一个呼叫，通知您这正是需要提取的数据，并且其容量应约为2TB。我们还获悉，我们已获得使用WinHex制作的原始媒体的逐扇区副本进行分析的信息。
最终，任务变得清晰，我们处于正确的轨道上。您可以再次从客户那里获取驱动器，然后继续进行诊断活动。当然，如果我们从一开始就拥有所有这些信息，那么快速诊断过程将大大缩短。
要重建ExFAT，我们需要知道该文件系统的簇大小，并确定零簇的位置（参考点）。接下来，查找文件分配表的剩余部分以及已占用空间的位图（Bitmap）。
关于ExFAT开发人员，需要说一个单独的恭维。为了提高文件系统的性能，已决定该表仅包含有关碎片链的信息。内联数据不会以任何方式出现在表中。在非空磁盘上创建此文件系统不会清除文件位置表，并且可能包含垃圾数据。不幸的是，这种意识形态并没有以最佳方式影响数据恢复的复杂性。
分析前2GB时，发现了部分ExFAT目录。在估计了这些结构的大小并在其他数据开始之前进一步填充了零之后，很容易确定簇的大小。浏览几个目录后，我们看到256（2048）个扇区的明显间隔。这使我们可以假定群集大小为1,048,576（0x100000）字节或1 MB。
为了确定起点，让我们看一下附近目录的位置。再次参考图10。特别地，我们对$ RECYCLE.BIN目录感兴趣，因为它几乎位于最开始。它的群集号在偏移量0x94处指示，并且是一个双字（DW），其中写入了值0x00000005，即该目录位于群集5中。此外，请注意目录“ Xxxxxxxxxx Xxxx.photoslibrary”，该目录根据偏移量0xF4中指示的值，位于群集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个文件。如果假设是正确的，则在下一个群集中，我们应该看到一个目录，其内容可能看起来像是Apple Macintosh上MacOS的典型照相馆文件夹。
数字： 13目录ExFAT，可能是Xxxxxxxxxxxxxxx.photoslibrary
如您所见，事实证明该假设是正确的，并且我们看到了预期目录的名称。可以认为该区域中的匹配数目足够，并且可以计算曾经存在的卷的零点和根目录的位置。
根目录位于群集4中。因为它位于群集号为5的$ RECYCLE.BIN目录之前。
相对于$ RECYCLE.BIN的零点必须位于负5个簇的距离处。位置$ RECYCLE.BIN 37888（303104）扇区。 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中安装磁盘的菜单我们
使用软件中心提供的免费Image Explorer，在其中通过打开磁盘，我们可以快速编写虚拟文件系统的参数并评估假设的正确性。
图。 15扩展的ExFAT目录树
如屏幕截图所示，目录和文件位于其位置，这使我们可以得出结论，文件系统参数已正确定义。
此时，可以停止诊断活动，然后可以与客户端达成以下工作清单：
1.在整个逻辑空间内搜索正则表达式，以建立各种数据的可能位置。
2.至少重建一个ExFAT部分。
3.分析具有新覆盖数据的交叉点。
4。在与Bitmap相交的位置上，相对于重建文件系统上的现有数据构建一个倒置地图，并在这些区域中搜索用户数据，然后对找到的内容进行排序。
对于中介公司，通常会开始通话，只有在最终所有者（几乎不怀疑他的数据将在我们的实验室中恢复）的同意之后，才能进行这项工作。
即使使用可维修的磁盘，任何工作仍然都始于创建一个扇区到另一个驱动器的逐个副本。此措施是必需的，以便客户端的驱动器保持不变，并且没有任何操作系统措施会导致不可逆的数据损坏。对于4TB磁盘，通过PC3000Express端口复制大约需要10到12个小时。
创建副本后，我们开始搜索各种正则表达式，以便了解逻辑空间中数据的分布，并查看该磁盘上是否有其他分区和文件系统的迹象。
数字： 16在整个驱动器中
的正则表达式搜索结果扫描结果表明，磁盘上的用户数据肯定比客户端声明的2TB小得多。最后一个正则表达式位于扇区539 877 376处，直到磁盘末尾为止，除了新创建的HFS +的结束标记外，再没有其他类似于用户数据的数据，尽管磁盘直到最后都不都是零。在磁盘上创建ExFAT分区之前，驱动器可能包含加密的卷。没有什么可以解释仅存在“嘈杂”数据的了。
在这种情况下，将正则表达式搜索结果与位图进行匹配非常重要。
数字： 17根目录ExFAT的扇区片段
在偏移量0x34处，簇号表示为2-这是位图在ExFAT节上的位置。偏移量0x38表示结构0x0746F1的大小（476,913字节或3,815,304位）。分析此结构时，发现卡中的凸起位仅用于前270GB，然后根据卡，该部分为空。也就是说，该位图与正则表达式搜索结果匹配，但是两者都与客户的单词不一致。
当然，如果发现了如此严重的不一致之处，那么工作将被暂停，您必须再次联系中介客户并尝试获得以下问题的答案：
1 .他们是否真的创建了他们提供给我们进行分析的完整的逐个部门的副本？
2。所有者真的确定此磁盘包含2TB的数据吗？
3.并且，如果您确定，您是否知道在此磁盘上无法接收到超过270GB的数据，是否同意继续进行数据恢复工作？
通过远程访问原始磁盘，我们得到了第一个问题的答案。然后，在磁盘编辑器中进行了很大的滚动之后，他们将其与我们拥有的副本进行了比较。原来，副本已完成。
第二个问题的答案是，信息的拥有者认为他可以肯定地看到磁盘已满2TB，但是对此不再十分确定。
但是，尽管客户对所有数据都充满信心，但仍然同意继续进行工作。
在重建文件系统之前，建议先了解有多少个碎片目录。为此，请进行粗略分析的结果并查看找到的目录的大小。如果目录的记录大小等于集群的大小，则很可能发生碎片，如果记录的大小小于集群的大小，则我们可以假定任务已显着简化，并且不需要手动拼接目录片段。
数字： 18找到的ExFAT目录列表
在这种情况下，未发现其他复杂情况，该目录中条目的最大大小为629,984字节，明显小于群集大小。
还必须标记新创建的文件结构所占用的所有区域。为此，我们将在FAT32和HFS +分区上构建所有结构和文件位置的地图。
数字： 19 HFS +卷上的结构和数据图
让我们在图样上的这些位置填充一个易于与任何用户数据区分开的模式，在这些区域的复制任务中，我们还将图例从成功读取更改为错误读取。这对于进一步检测被覆盖破坏的文件很有必要。
为了更方便地使用Data Extractor分析工具，有必要在分区表中描述该部分，并为ExFAT分区创建启动扇区。
数字： 20具有已注册ExFAT卷的分区表
在偏移量0x1D2处，输入卷类型0x07。此类型用于NTFS和ExFAT。
在偏移量0x1D6处，指向ExFAT卷开始的指针。使其为32个扇区（0x20）。
在偏移量0x1DA处，写入经典分区表的最大允许卷大小（尽管该值小于实际卷大小，但是在这种情况下是可以接受的，因为我们不打算在任何操作系统中挂载此损坏的卷，因此仅需要一个非零值即可）数据提取工具的正常运行）。
数字： 21 ExFAT引导扇区
由于Data Extractor对ExFAT引导扇区的内容非常敏感，因此仅填充重要字段通常是不够的（这不是很合逻辑），并且很容易在内部资源管理器中显示该部分，就像在Image Explorer中的诊断中一样，而不是锻炼。因此，在使用ExFAT引导扇区的情况下，最好采用标准模板并在其中输入正确的值。
为了方便起见，我们将以驱动器用作具有512字节扇区的设备的形式来写引导扇区。这将为我们提供综合大楼所有工具的正确操作，而无需不必要的地图重建。
填写字段：
每块字节数-扇区中的字节数。 ExFAT指定必须增加2的幂才能获得大小。
每个群集的块数-群集中的扇区数。它还指示您需要提高2才能获得数量的程度。
总群集数卷上可用的群集数。我们输入值3 815304。它是通过将位图的大小乘以8来获得的。
总块数-扇区数。该值被由簇大小（其又是通过每块群集乘以每块中的字节而获得）总集群相乘得到
FAT偏移-从引导扇区到文件分配表的偏移量。让我们创建一个空结构，并将其放在扇区64中。为其添加一个标准标题。
每个FAT块-FAT表占用的扇区数。它的大小很容易根据群集数进行计算。每个FAT块=总簇数/（每个块的字节数/ 4），并进一步舍入到最接近的整数。 3815 304 /（512/4）= 29807，0625 =29808。
（无论某些来源尝试用多大的努力将ExFAT称为64位文件系统，文件分配表都是32位，但是与FAT32不同， 32位用于寻址，而不是28位。）
FAT数量-表副本的数量。不幸的是，在创建分区时，通常为
1。Cluster Heap Offset-表示扇区中位图的偏移量。
根目录群集-根目录的群集号。
在“数据提取器”资源管理器中可用该部分之后，我们将使用位图构建占用空间的地图。
数字：22 ExFAT结构占用的空间图和根据位图的用户数据。
我们还将基于现有文件记录构建文件位置图，按文件在磁盘上的排列顺序排序，并将它们与位图数据进行比较。
数字： 23 ExFAT卷
上可用文件位置图的片段基于构建文件位置图的结果，我们在718 528至57 131 008的逻辑范围内观察到一个相当大的“空洞”。在位图上很明显，该区域已被用户数据占用。另外，在整个磁盘上搜索正则表达式时，在此区域中发现了数据符号。
在这种情况下，可以确定该文件系统已损坏，并且需要采取进一步的分析措施。
反转文件位置图以获得现有文件记录未描述的空间链列表。我们删除所有链的大小小于群集大小的所有链，因为这些链将是群集的自由片段，不会被写入它们的用户数据完全占据。我们映射到位图，仅保留这些范围内的重叠字符串。
其余结果有待进一步分析-搜索ExFAT目录。让我们创建一个目录，在该目录中我们将形成条目-指向找到的目录的指针，并从找到的目录片段中输入条目。应该检查找到的目录中与可用目录相交的条目的内容，建立它们之间的关系，并检查这些目录中条目所指向的文件头的对应关系，并过滤掉不相关的目录。目录的丢失可能是由于磁盘利用过程中文件系统中的错误，也可能是由于写入磁盘的新数据的部分重叠所致。
数字： 24目录，其中包含指向没有父对象的已找到结构的指针。
此外，在文件位置图上添加了丢失目录中找到的对象后，我们将考虑与位图的相交处，重复构建反向图，以重复此过程。在以这种方式获得的链中，有必要搜索各种类型的用户文件的正则表达式。
这是分析工作的最后阶段，其结果将是用户数据的残留，为此，文件系统中没有描述其位置的元素。请注意，这些措施帮助我们不在最终结果中包括来自用户本来可以删除的数据的各种垃圾。
完成这些操作后，您可以开始复制找到的数据，并考虑到映射中存在“读取错误”的文件扇区的位置，从而淘汰了唯一被新数据覆盖的文件。在构建FAT32和HFS +功能图之后，我们创建了“读取错误”标记。
这样就完成了工作。在保持原始目录层次结构的同时，获得了无碎片文件的最大可能结果，发现了几乎所有可能丢失的文件，而该结果中未包含自动恢复程序通常具有的各种垃圾数据。
上一篇：硬盘自我诊断和数据恢复