《数据恢复案例》由会员分享，可在线阅读，更多相关《数据恢复案例（26页珍藏版）》请在金锄头文库上搜索。
1、案例 1.佳能相机 EOS5D CF 卡 提示格式化 恢复成功今天客户拿来相机说 卡提示格式化 想要里面的视频，插在电脑上一看 的确提示格式化，按着杜老师教的用 Winhex 打开一看 MBR 还在 DBR 全部变成 FF 了 搜索 F8FF 只找到 FAT 表 2 FAT1 只剩下后面部分了 分析了一下 FAT 表 2 很完整 并得知为 FAT32文件系统。接着搜索 2E20 到根目录看一下 有一个名为 DCIM 的文件目录项 且没有损坏接着到 3 号簇 和 4 号簇 5 号簇看一下 都没发现问题 计算簇大小为 64Sec , 接着计算FAT 表大小 为 3811Sec 利用 FAT 表大小
2、得知 分区扇区总数为 31219584 好了 接着从别的硬盘 Copy 一个 FAT32 分区的 DBR 分别填入以上参数 簇大小 64Sec FAT 大小 3811Sec 和分区大小 31219548Sec 保存弹出 从新插拔一下 进我的电脑 已经可以打开了 数据恢复成功。总结：需要对分区结构、基础知识牢固。利用 winhex 软件案例 2. 加 1 减 1，数据恢复有时就是这么简单！昨日去办事情，偶遇一客户。手机 8GB 卡由于热插拔导致提示 “未格式化”。找了一台电脑下了一个 WINHEX。打开 U 盘，发现分区开始位置没有 DBR，而 DBR 却被向下移动了一个扇区。这个很简单，我并没
3、有把 DBR 向上复制，而是把分区的开始扇区号加了一个“ 1”，把 DBR里的保留扇区减去一个“1 ”。好了，点保存，WINHEX 提示 IO 错误。最终解决了 IO 错误，弹出卡，然后再插入，分区正常打开，数据很完整。IO 问题是 tf 卡有保护总结：灵活利用知识案例 3 最近流行的 U 盘病毒，导致 WORD 打不开的恢复方法最近接到几个 U 盘.问题基本都是一样 ,里面的 WORD 文件基本是打不开的,原本以为是什么大问题,可能想着要设计到重组碎片 ,价格就报了几百元 ,打算不弄,后来我就随便用WINHEX 打开看了一下,发现文件头的前面每 6 个字节都破坏 .我就打开个好的 WORD
4、把前面 6 个字节覆盖到坏的里面.文件就可以正常打开. 我运气还是算好，去年老遇到前面的扇区很有规律的被覆盖。虽然这个没有什么技术含量.希望可以对其他人有帮助。总结：文件损坏，分析文件结构损坏规律案例 4实际数据恢复案例-手工修复 FAT32 文件系统找来的一篇好文章，拿出来跟大家分享！今天接到一个朋友的客户做数据恢复，原来是 4 个分区 CDEF。客户由于觉得 C 盘小，利用 PQ 分区大师将 D 盘部分区域划分给 C 盘，重启系统后，原 C D F 三个分区数据正常，E 盘分区找不到。朋友用 R-Studio 扫描全盘，E 盘数据始终找不到。拿到盘后看到情况如下，用 Winhex 查看发现
5、分区 4 只是联想硬盘中的隐藏分区（用来还原系统的，不在客户所说的四个分区中）。分区 3 文件结构和磁盘大小都正常正常。分区 2 的 DBR 显示大小和实际大小不一致只有 80GB，所以初步判断客户需要的 E 盘应该是和原来 D 盘合并成了现在的分区 2。但如果仅仅是简单的合并 利用 R-Studio 应该可以直接扫描出来，现在却没能正常扫描到，需要进一步分析。磁盘分区分布图根据分区 2DBR 显示大小找到实际结束位置，在 194579343 扇区发现了一个 NTFS的 DBR，但是这只是个孤立的 DBR 没有紧接着并没有 NTLDR，可能是个备份。而且继续向下查找，发现一个 FAT32 分区
6、的 DBR。 继续向下分析，在 194579351 位置发现了 NTFS INDX 文件，并且向下发现了更多的 NTFS 分区信息。本来以为这只是个孤立的事件。但在向下查找过程中意外发现了类似 FAT 表的数据，找到头部，发现居然然是 一个完整 FAT 表，而表后是目录项。然后对刚刚发现的那个 FAT32 DBR 进行解析，如果把这个 FAT32 DBR 当成备份的话，刚刚看到的这个 FAT 应该是 FAT2。而且显示的分区大小和到分区 3 之间的扇区数相等。而且从分区 3 开始的位置，从后向前找 NTFS 分区备份，也未能找到，说明丢失的 E 盘应该是 FAT32 分区。通过以上分析我猜测，
7、丢失的分区正是个 FAT32 分区，分区 DBR 和 FAT1 在 PQ 移动过程中被覆盖掉，现在盘上发现 NTFS DBR 的位置正好是原来 FAT32DBR 的位置。根据这个想法，把备份 FAT32 DBR 贴回，计算 FAT1 的实际位置，将 FAT2 还原到 FAT1，如表 恢复后 所示。用 Winehx 展开当前恢复的分区，数据正常访问，用工具恢复数据，恢复完成。总结：1、不能盲目相信恢复工具，在文件系统关键信息丢失的情况下，恢复工具无法智能分析出文件系统结构；2、使用 PQ 工具是一定要注意备份当前数据；3、对文件系统结构要非常熟悉。案例 6 硬盘在电脑上无法识别到盘符故障 1硬盘
8、检测不到有很多问题：就先讲一个很常见的问题。对新手很有用今天接到一个 ST 80G 的台式机硬盘，把故障盘接到电脑上，电脑就好像死机一样，故障盘拔了电脑有可以正常使用，原本一般我遇到这样的问题大部份是坏道导致，当然也有其他问题也会导致以后案列中会讲到, 我用 MHDD 检测没有发现任何坏道，用指令看也是正常的，然后又用SPFDISK 查看分区表也是正常的，后来没有办法，我就在 DOS 下用 SPFDISK 这个命令把分区给删除。在插到电脑上，电脑没有死机了。winhex 打开后，分区都看不见。当然要做的是把分区表信息填好，分区表出来以后直接用 WINHEX 拷数据出来就可以。如果不用WINHE
9、X 把数据拷出来。重新启动电脑一样会卡死。所以这个方法是很使用的。数据拷完重新分下区硬盘就可以正常使用了。案例 7 通过查找 $MFT 反推 DBR 位置手工构建 DBR一次手工恢复误 GHOST 严重损坏的分区实例两天前下午，我在淘宝店（）接到一个客户，他介绍说他用 GHOST 安装系统，结果安装两三次系统都不能正常启动，然后用他原来系统的 GHOST 备份恢复，系统起来了，但系统中就只有一个 C 分区了，还有两个分区 D 和 E 不见了，让我给他恢复原来 E 分区中的数据。想到这种问题一般都很简单，就是恢复一下分区表就完事了，所以也没有先远程看一下，就接了下来。远程连接到客户电脑上，打开事
10、先让客户下载好的 Winhex，再在Winhex 中打开待恢复的硬盘，硬盘在 Winhex 显示就只有一个分区。根据经验，这种情况在 Winhex 中是看不到原来的分区的，于是决定先用 PTDD 扫描一遍看看再说。用 PTDD 扫描分区信息，扫描完成后，只在硬盘的后面部分有一个原来的分区信息，大小为 99.7G，这个分区可能就是原来的 E 分区。根据客户的描述，原来的三个分区是 C 分区 45G 左右，D 分区 25G左右，E 分区 230G 左右。显然 PTDD 扫描出来的分区并不是原来的分区。但还是不死心，万一是客户记错了呢？于是重建这个分区。接下来在 Winhex 中打开硬盘，此时在目录
11、浏览器中显示出了刚才重建的那个分，但单击这个分区，跳转到它的起始扇区，结果发现这个扇区数据全是 0，现在很明显重建的这个分区并不是客户的 E 分区。看来用软件扫描不到原来的分区了，只得手工恢复了。通常情况下，XP 在分区时会将第一个分区分为主分区，其余分区分为逻辑分区，D、E 两分区很有可能是逻辑分区，于是首先尝试查找扩展分区表。在 Winhex 中打开待恢复硬盘，根据客户所说 C 分区大约 45G，于是从 40G 位置开始，设置搜索条件为 512508，向下查找 000055AA。通过一翻搜索，倒是搜索到一个扩展分区表，但经查看，却是 PTDD 中搜索到的那个分区，看来没有这两个分区的扩展分
12、区表项。搜索扩展分区表失败，接下来想到直接搜索 DBR。搜索了一部分扇区后，想到 PTDD 都没能搜出来，这两个分区的 DBR 扇区应该是已被破坏没有了，于是停止了搜索。由于客户要的是 E 分区的数据，E 分区大小为 230G 左右，应该是 NTFS 文件系统。由于客户不清楚这个分区是什么文件系统，因此只有先按 NTFS 文件系统尝试。是 NTFS 文件系统就一定有$MFT 这个原文件（当然前提是$MFT 没被损坏），于是去搜索这个原文件的文件名的十六进制值 24004D0046005400，这次从 50G 位置开始向后搜索，搜索到若干个 24004D0046005400 后，终于在 1556
13、98795 扇区找到了一个$MFT 的文件记录。接下来要确认这个扇区是$MFT 还是$MFTMirr 的起始扇区。由于$MFTMirr 只是前四个 MFT 项的备份，因此只要确定一下 155698795扇区之后的若干个连续扇区中的 MFT 项是不是超过四个就能基本确定155698795 扇区是$MFT 的起始扇区还是$MFTMirr 的起始扇区了。于是搜索 NTFS 文件记录的特征字节值 46494C45，结果在 155698795扇区后的部分连续扇区中找到找到了二三十个 MFT 项，可以确定 155698795 扇区就是 $MFT 的起始扇区了，没再往下搜索了。在这些 MFT项中随便找了几个
14、文件名给客户看，确定了那就是原 E 分区的文件。找到了$MFT 的起始扇区，接下来的工作便是确定 E 分区的起始扇区号了。而 E 分区的起始扇区号只有通过$MFT 的起始簇号和簇大小扇区数去反推。首先计算簇大小。分别查看 80 属性 182F 字节处的 8 个字节的值（属性结束 VCN）和 282F 字节值（属性内容分配大小）再用“属性内容分配大小/（属性结束 VCN+1）/512”得到簇大小扇区数为 8（其实 NTFS 文件系统的簇大小一般都是 8，这里只是为了确认一下）。这里对属性结束 VCN 和属性内容分配大小这两个值没做记录，只记得计算出来的簇大小扇区数了。接下来需要根据$MFT 的
15、80 属性中记录的$MFT 起始簇号和从簇大小扇区数去反推 E 分区的 DBR 位置了。查看 80 属性的第一个运行，得出起始簇号为 3754787（这个与常见的$MTF 起始簇号 786432还不一样）。由于 NTFS 文件系统的 0 号簇是从 DBR 开始的，因此用 3754787*8 得到 E 分区的$MFT 距 DBR 的扇区总数为 30038296（3754787*830038296），再用$MFT 所在扇区号 155698795 减去 30038296 得出 E 分区的 DBR 扇区应在 125660499（155698795 30038296125660499）。跳转到 1256
16、60499 扇区，这个扇区有数据，但显然不是原来 E 分区的 DBR，看来只有在这个扇区把写一个 DBR。为以防万一，先把 125660499 扇区做一个备份。首先拷贝一个正常的 NTFS 的 DBR 到 125660499 扇区，接下来要修改的几个参数有：簇大小（前面已计算为 8）、隐藏扇区数（即该分区前的扇区数，就为 125660499），分区大小扇区数，$MFT 起始簇号（为 3754787），$MFTMirr 起始扇区号。现在还差两个参数：分区大小扇区数和$MFTMirr 起始扇区号不知道。先查$MFTMirr 起始扇区号。$MFTMirr 的文件记录项是$MFT 的后面一个 MFT 记录项，跳转到 155698797 扇区查看该扇区中的文件记录项，从文件名属性（30 属性）可看到它确是$MFTMirr 的文件记录项，查看 80 属性运行列表
