手工恢复主分区表的过程新手教程

jsyzwfff · 发表于 2008-12-12 14:33:21

这里我解释一下：
1、剩余扇区是什么：剩余扇区有分区内的剩余扇区和整个磁盘的剩余扇区。
先说分区内的扇区：描述磁盘容量的单位是扇区，分区内部又是采用簇来管理的。通常情况下，扇区的容量是512b,簇的单位容量大于等于扇区的容量。以具体事例来讲，一个7gb的fat32分区，其簇的大小是4k,相当于8个扇区，而分区内的存储单位是4k,分区的扇区总数如果不是8的倍数，那余下来的扇区便是剩余扇区了。
整个磁盘的剩余扇区与上述原理相似，不同的是，每个分区的结束必须以254头，63扇为结束（也应该是老的磁盘管理模式留下的弊端吧！虽然分区内是以线性逻辑扇区为首要参数的）也就是说，如果磁盘的总容量正好分不净一个柱面的容量(1*254*63*512b=8193024b),那么，剩下的容量便是整个磁盘的剩余扇区了，其最大也就是大约7.8m。这也是通常情况下，分区的最小容量是7.8m，分区容量是8193024b倍数的原因。（简图并未画出整个磁盘的剩余扇区，大家理解吧!)
2、对于fat32的保留扇区的数目，一般来说是32个，但也不肯定是，有时候可能会是38个或其他数目，当然也可以在dbr中的bpb（bios parameter block）参数表中更改，后面要讲到在数据恢复中了解他的重要性。
3、在小容量的磁盘分区中也存在fat16的分区格式，原理吗？和软盘的存储原理相，下面我们进入实战：
第一种情况，分区被格式化。如果格式化以后，当然可以用现成的数据恢复软件来恢复，但软件毕竟是软件，并不能应对多变的复杂的情况。而手工不同，如果对磁盘结构了解，是可以最大程度的恢复的。我们抛开数据恢复软件来看和通过手工来恢复被格式化的磁盘分区。
对于fat格式的分区（包括fat16)，format命令会重建dbr扇区，清空两个fat表，清空分区的第一个簇（存放原根目录）。不管是快速格式化还是完全格式化（快速格式化和完全格式化的区别在于他们是否对所涉及到的磁盘扇区进行检测扫描，清除上面的数据事都要做得)。对于dbr，分区只要正确格式化就会生成正确的dbr,故而重点是fat表和原根目录（如果原根目录大于一个簇，这仅仅是第一个簇，为了方便，以后就以原根目录称）的问题。如果你格式花前备份了此分区的fat表和根目录。那么，只要将dbr初始化，恢复fat表和根目录即可完全恢复数据。不过，既然是被格式化，那一定没有fat表和根目录的备份（废话！！！）。继续：
先说根目录，跟目录的第一扇一但清空，别无法找回了。所以，格式化前存储在根目录的文件就会因其在第一扇存储的文件特征描述表丢失而很难找回了，除非你知道文件中包含的特征字符串，根据其在整个分区内查找，又确定文件的大小，而恰好要恢复的文件又是在磁盘内连续存储的。
再说fat表，fat表的丢失对交叉存储的文件来说是几乎毁灭的灾难。原则上如果丢失，就只能恢复从文件第一簇开始的连续几簇了。但一般如要恢复的文件较小或分区并未经过频繁的文件删增的话，还是有希望的。
手动填写fat表是不现实的，我们只好先让原来的目录结构重现，再想办法。windows的磁盘文件格式是tree型的，格式化只是将tree的根折，在根折断以后，其实就象生成了多颗tree（想想数据结构）。如果我们要恢复的文件全部位于一个子目录当中。那好了，我们只要将这颗子树的树根放入原tree的根位置上，即可生成一颗新树。推介使用winhex,下面以winhex为例具体而言，首先，若磁盘未格式化或格式化格式不太正确，先格式化，以生成可参照的dbr和fat表。接着我们在分区中寻找相关的字符串来确定此子树的'根'位置。，如记得原目录中有sjhfnet.txt的文件（选择其他目录没有或很少有此文件名的文件），可在整个分区内查找'sjhfnet txt',再根据相关特征确定。这时候注意一下，我们需要目录中提供的'.'目录来推测原分区的一些特性，主要是dbr中的bpb参数，如保留扇区的数目。（一般是不不会错的，但如果有那怕一个扇区的出入，整个分区中目录的映射将不能套用，还是看看吧！），是不是要问，'.'目录是什么？学过dos的人都知道，目录'.'表当前所在目录，'..'表上级目录，在32个子节的目录项中，包含有和其他目录项相同的特征，我们关心目录的位置（在原分区格式的第几个簇中），他应该是等于他所在的簇号的！也就是看一下偏移量为15h 14h 1bh 1ah的数值是否等于现在簇号。在winhex中格式化后的磁盘可清楚的列出当前簇的簇号，可比较一下（可能需要16进制与10进制的转换）。
相同不说了，如果不相同，也应该相差不多。计算一下相差的簇的数目，然后在本分区dbr扇区的0eh~0fh作相应增减，是保留扇区的数目回到原来的数目。重起一下计算机，是新的dbr生效，清空现fat表（根目录簇可以不清空，因后边讲到会覆盖的）。文件目录项的映射与实际地址便正确的结合了。（不明白吗？想想原理，努力消化一下）
接着将找到的簇复制----〉定位到现在的根目录----〉写入。
打开“资源管理器“，浏览，出来了吗？
慢！还没完，现在的目录结构是出来了，但还不能访问，因为fat表所记录的簇还是空闲的。怎么办？手动写，算一下，可能写完得30年吧！呵呵！哪。。。。，其实，如果要恢复的文件大小都在1簇范围内，可在win98下运行磁盘扫描程序，在出现修复的提示时选相应的选象修复即可（别选“删除涉及到的文件”选项，另外，win2000下不行，扫描程序会直接删除文件的）。这样，大小在1簇范围的文件别完全恢复了（包括文件）。那如何在这种情况下恢复大于1个簇的文件呢？一是你可以写一个小的程序来实现涉及到的簇的连续。如果你不会，那么也不难，得一个一个文件的来。打开winhex,使用它的目录模板跳转到文件的存储区，从当前簇复制大小为文件大小的一块连续数据，写入新文件中（记得写在其他分区中），即可！当然，如果簇数较少，可直接在fat1中改动。
另外，这样恢复的文件也不一定正确。要看当初文件的存储是否连续了？如果恢复后的文件不能用，那。。。。听天由命吧！！！（要么你在磁盘中在查找，分析，自己把它连接起来。不过，工作量吗？。。。）
这样恢复的是以前一个子目录的数据。如果有多个目录的数据要恢复，可用同样的方法替换根目录（第一个数据簇），也可以采用手动建立根目录的方法，不过，别在资源管理器中进行，手动在winhex中做吧！还有，要是恢复的目录中有多个簇，再用同样的方法，查找，作为根目录。
这是分区格式为fat32的情况，如fat16则不需考虑保留扇区的数目情况，fat16无保留扇区。
这是有目录项的情况。

再来说一下在无目录项参照的情况：
以下默认为欲恢复文件是存储在FAT32文件格式当中的文件。
假如你的磁盘已经被xxx破坏的一塌糊涂。或者已经经过了N位高手二次处理"加工"过了，什么工具软件都用过了！结果仍然没有看到你需要的数据的影子。或者你要恢复的数据本来就很少（若干源代码，或是若干论文，若干小的数据库，或是确认在数据丢失前正好做了磁盘碎片整理），不值得采用我上面采用的方法。你可以采用在磁盘内通过查找的方法，总结来找回数据（不要笑，有技巧的，况且，也许这是唯一的方法！）
可以通过磁盘文件的存储特征和文件固有的类型特征来考虑。看过《反黑行动之数据恢复》（风般的男人著）应该可以知道，文件在磁盘内至少是以扇区为单位的，也就是说，每个文件在磁盘内实际存储的开始，一定是某扇区的开始。这是其一，其二是每种类型的文件都有其特定的文件标志，可根据文件的特定标志（通常还是在文件的开头）与其在磁盘的位置来圈定。
如果是文本文件，可通过在磁盘内查找特征字串的方法来找到。不过，稍有知识的人是都知道的，不说了。（还是使用winhex吧！硬盘速度可以的话，应该查找1G的空间不超过1分钟)
我们来通过具体的例子看一看已加密或无明显特征字串的情况（这是最通常的情况）。以一Office文档的恢复为例。
Office文档的实际构成总是以
“00000000 D0 CF 11 E0 A1 B1 1A E1 00 00 00 00 00 00 00 00 邢.唷??.......”
开头，以下列二进制特征为尾：

[ 本帖最后由 jsyzwfff 于 2008-12-12 14:37 编辑 ]

jsyzwfff · 发表于 2008-12-12 14:37:34

(这是在winhex中显示的情况，此部分内容是最后扇区的中间部分的内容＃ê蟊咭话阄?舾?0h)
既然文件头尾标志已确定，即可在磁盘中搜索了。可搜索所有的“D0 CF 11 E0 A1 B1 1A E1 ”，保存其位置。在搜索特定的尾标志，保存其位置。观看在winhex“位置管理器”中的所保存位置。删除位置不是以"000H"，"002H"，"004H"，"006H"，"008H"结尾的文件头标志（因为扇区容量512B=200HB)。删除不合位置特征的尾标志（通过对200H取余的结果看）。再删除多出来的头或尾标志。（应该成对出现）
此例以Word 2000文档为例。通常情况下，word文档的大小不可能太大。在winhex的位置管理器当中，所有的位置是以地址来排序的。所以，看一下成对的头尾标志其偏移是否合逻辑。如不合，删了！
那么，剩下来的便是最有可能的了。剩下的，不用说了吧！将每一对头尾地址之间的数据保存即可。（成不成功看命吧！）
这是以Office文件为例说明。其实大多数文件都有特征标志，可参看相关资料或自己研究。对于没有特定尾标志的文件，它的结构也有特征，结合头标志和结构看吧！(不过可能稍难点!) 还有，恢复的文件当中可能有你删除了的文件，没有办法。只好一视同仁了。不过一般情况下，已删除文件的开头是最先被系统的其他文件覆盖的，可能也能降低工作量吧！