Ext2文件恢复实例分析

为了使问题简单化，在根目录下创建文件dnfs-server.conf，由于根目录的inode节点为2（ls –i –l –d /），且第一个块组的inode table起始块号为483），查看根目录的索引节点信息。

（参考http://blog168.chinaunix.net/space.phpuid=20196318&do=blog&id=31362）

hexdump /dev/sda1 -C -s 1978624 -n 256

001e3100  ed 41 00 00 00 10 00 00  b6 26 e2 4c 18 5a d1 4c  |.A.......&.L.Z.L|

001e3110  18 5a d1 4c 00 00 00 00  00 00 17 00 10 00 00 00  |.Z.L............|

001e3120  00 00 00 00 00 00 00 00  e3 03 00 00 00 00 00 00  |................|

001e3130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

通过直接索引得出其第一数据块的块号为03e3（995），查看第995个数据块的内容。

hexdump /dev/sda1 -C -s 4075520 -n 4096  （4075520 = 995*4096+256）

003e3000  02 00 00 00 0c 00 01 02  2e 00 00 00 02 00 00 00  |................|

003e3010  0c 00 02 02 2e 2e 00 00  0b 00 00 00 14 00 0a 02  |................|

003e3020  6c 6f 73 74 2b 66 6f 75  6e 64 00 00 01 20 07 00  |lost+found... ..|

003e3030  0c 00 03 02 64 65 76 00  01 20 00 00 0c 00 04 02  |....dev.. ......|

003e3040  70 72 6f 63 01 e0 06 00  0c 00 03 02 73 79 73 00  |proc........sys.|

003e3050  01 80 01 00 0c 00 03 02  76 61 72 00 01 20 03 00  |........var.. ..|

003e3060  0c 00 03 02 74 6d 70 00  01 a0 04 00 0c 00 03 02  |....tmp.........|

003e3070  65 74 63 00 01 40 05 00  0c 00 04 02 72 6f 6f 74  |etc..@......root|

003e3080  01 00 02 00 10 00 07 02  73 65 6c 69 6e 75 78 00  |........selinux.|

003e3090  01 60 01 00 0c 00 03 02  75 73 72 00 01 40 06 00  |.`......usr..@..|

003e30a0  0c 00 03 02 62 69 6e 00  01 e0 01 00 0c 00 04 02  |....bin.........|

003e30b0  62 6f 6f 74 01 c0 01 00  0c 00 04 02 68 6f 6d 65  |boot........home|

003e30c0  01 c0 06 00 0c 00 03 02  6c 69 62 00 01 40 03 00  |........lib..@..|

003e30d0  10 00 05 02 6d 65 64 69  61 00 00 00 01 00 01 00  |....media.......|

003e30e0  0c 00 03 02 6d 6e 74 00  01 80 04 00 0c 00 03 02  |....mnt.........|

003e30f0  6f 70 74 00 01 20 02 00  0c 00 04 02 73 62 69 6e  |opt.. ......sbin|

003e3100  01 40 02 00 0c 00 03 02  73 72 76 00 0e 00 00 00  |.@......srv.....|

003e3110  14 00 09 01 2e 61 75 74  6f 66 73 63 6b 64 5f 63  |.....autofsckd_c|

003e3120  58 00 00 00 1c 00 10 01  64 6e 66 73 2d 73 65 72  |X.......dnfs-ser|

003e3130  76 65 72 2e 63 6f 6e 66  63 74 00 00 38 a0 00 00  |ver.confct..8...|

003e3140  10 00 05 02 2e 64 62 75  73 00 00 00 59 00 00 00  |.....dbus...Y...|

003e3150  18 00 0d 01 2e 70 75 6c  73 65 2d 63 6f 6f 6b 69  |.....pulse-cooki|

003e3160  65 00 00 00 68 c0 00 00  9c 0e 06 02 2e 70 75 6c  |e...h........pul|

003e3170  73 65 00 00 5a 00 00 00  8c 0e 12 01 2e 72 65 61  |se..Z........rea|

003e3180  64 61 68 65 61 64 5f 63  6f 6c 6c 65 63 74 00 00  |dahead_collect..|

003e3190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

 

根目录的内容为多个目录项，目录项的结构如下：

Inode号（4B）

本目录项的长度（2B）

名字长度字节数（1B）

文件类型 （1B）

名字ASCII码串（不定长）

 

 最开始的两项为.和..对应的目录项，接下来依次为lost+found，dev等的目录项。

02 00 00 00 0c 00 01 02  2e 00 00 00 （.目录项对应的数据）

前面4个字节（00000002）代表目录项“.”对应的inode号为2；

接下来的两个字节（000c）代表本目录项的长度为12个字节；

接下来的1个字节（01）代表目录项名字的长度为1个字节（.的长度）；

接下来的1个字节（02）代表文件类型（目录）；

接下来的1个字节（2e）代表目录项名字（.的ASCII码为0x2e）；

 

02 00 00 00 0c 00 02 02 2e 2e 00 00（..目录项对应的数据）

前面4个字节（00000002）代表目录项“..”对应的inode号为2；

接下来的两个字节（000c）代表本目录项的长度为12个字节；

接下来的1个字节（02）代表目录项名字的长度为2个字节（..的长度）；

接下来的1个字节（02）代表文件类型（目录）；

接下来的2个字节（2e2e）代表目录项名字（.的ASCII码为0x2e）；

 

58 00 00 00 1c 00 10 01  64 6e 66 73 2d 73 65 72  

76 65 72 2e 63 6f 6e 66  63 74 00 00   （dnfs-server.conf目录项对应的数据）

前面4个字节（00000058）代表目录项“dnfs-server.conf”对应的inode号为88；

接下来的两个字节（001c）代表本目录项的长度为28个字节；

接下来的1个字节（10）代表目录项名字的长度为16个字节（dnfs-server.conf的长度）；

接下来的1个字节（01）代表文件类型（普通文件）；

接下来的16个字节（...）代表目录项名字dnfs-server.conf；

 

ext2文件系统数据恢复原理：

当文件被删除时，其实际的inode信息，数据块信息仍然保留（只要对应的inode，数据块没有分配给新建的文件），删除文件只是修改了文件所在目录的信息，即修改被删除文件前一项目录的目录项长度信息，使其越过被删除的目录项。

 

dnfs-server.conf目录项的前一项为.autofsck

0e 00 00 00 14 00 09 01 2e 61 75 74  6f 66 73 63 6b 64 5f 63

（.autofsck目录项对应的数据）

前面4个字节（00000058）代表目录项“.autofsck”对应的inode号为14；

接下来的两个字节（0014）代表本目录项的长度为20个字节；

接下来的1个字节（09）代表目录项名字的长度为9个字节（.autofsck的长度）；

接下来的1个字节（01）代表文件类型（普通文件）；

接下来的9个字节（...）代表目录项名字.autofsck；

 

接下来执行删除文件dnfs-server.conf的操作 rm /dnfs-server.conf

再查看根目录第一个块的内容

# hexdump /dev/sda1 -C -s 4075520  -n 4096

003e3000  02 00 00 00 0c 00 01 02  2e 00 00 00 02 00 00 00  |................|

003e3010  0c 00 02 02 2e 2e 00 00  0b 00 00 00 14 00 0a 02  |................|

003e3020  6c 6f 73 74 2b 66 6f 75  6e 64 00 00 01 20 07 00  |lost+found... ..|

003e30b0  62 6f 6f 74 01 c0 01 00  0c 00 04 02 68 6f 6d 65  |boot........home|

......

003e30f0  6f 70 74 00 01 20 02 00  0c 00 04 02 73 62 69 6e  |opt.. ......sbin|

003e3100  01 40 02 00 0c 00 03 02  73 72 76 00 0e 00 00 00  |.@......srv.....|

003e3110  30 00 09 01 2e 61 75 74  6f 66 73 63 6b 64 5f 63  |0....autofsckd_c|

003e3120  58 00 00 00 1c 00 10 01  64 6e 66 73 2d 73 65 72  |X.......dnfs-ser|

003e3130  76 65 72 2e 63 6f 6e 66  63 74 00 00 38 a0 00 00  |ver.confct..8...|

 

从结果可以发现，dnfs-server.conf目录项的内容（58 00 00 00 1c 00 10 01  64 6e 66 73 2d 73 65 72  76 65 72 2e 63 6f 6e 66  63 74 00 00）完全没有改变，而其前一目录项.autofsck的数据（0e 00 00 00 30 00 09 01 2e 61 75 74  6f 66 73 63 6b 64 5f 63）的长度由原来的14（20）变成了30（48），刚好跳过了dnfs-server.conf目录项（长度为28）。

 

也就是说，被删除的dnfs-server.conf目录项的信息仍然存在，可以从其前一个目录项的信息获得起始地址，前一个目录项实际的长度为（8 + 9  = 17 提升为4的倍数为20），后面的48-20=28个字节即为dnfs-server的信息。

 

通过目录项信息可获取inode的信息，然后获取实际数据的位置（inode值为88），访问inode及通过inode访问文件实际数据的过程参考（http://blog168.chinaunix.net/space.php?uid=20196318&do=blog&id=31362）。