【问题标题】:How to get the offset in a block device of an inode in a deleted partition如何获取已删除分区中inode的块设备中的偏移量
【发布时间】:2015-10-11 16:08:30
【问题描述】:

在全新安装期间,我不小心格式化了包含数据的磁盘。我尝试过使用一些工具:首先是testdisk,但我没有得到好的结果。 (查看超级用户的my unsuccessful post)。

所以我决定阅读一些关于ext2 filesystem structure 的文档,我可以得到一些结果:

删除的分区有这样的目录树:

dev
|-scripts
|-projects
|-services
|-...
Medias
|-downloads
|-Musique
|-...
backup
...

所以,基于ext2目录项格式:

Directory Entry
Starting_Byte Ending_Byte Size_in_Bytes Field_Description
0   3       4   Inode
4   5       2   Total size of this entry (Including all subfields)
6   6       1   Name Length least-significant 8 bits
7   7       1   Type indicator (only if the feature bit for "directory entries have file type byte" is set, else this is the most-significant 8 bits of the Name Length)
8   8+N-1   N   Name characters

我试图找到一些与此结构匹配的数据。
我使用了这个脚本:

    var bindexOf = require('buffer-indexof');

    var currentOffset=0;
    var deviceReadStream = fs.createReadStream("/dev/sdb");

    deviceReadStream.on('error',function(err){
        console.log(err);
    });

    deviceReadStream.on('data',function(data){

        var dirs = ["dev","scripts","services","projects","Medias","downloads","Musique","backup"];
        dirs.forEach(function(dir){

            dirOctetFormat = new Buffer(2);
            dirOctetFormat.writeUInt8(dir.length,0);
            dirOctetFormat.writeUInt8(2,1);// type is directory
            dirOctetFormat= Buffer.concat( [dirOctetFormat, new Buffer(dir)]);

            var offset = bindexOf( data, dirOctetFormat );
            if( offset >= 0 ){    
                console.log( dir + " entry found at offset " + (currentOffset + offset) );
            } 

        });
        currentOffset += data.length;
    });
}

我发现数据似乎是 dev 目录的目录条目:

 ===== Current offset: 233590226944 - 217.5478515625Gio ====== 
scripts entry found at offset 233590227030
services entry found at offset 233590227014
projects entry found at offset 233590228106

如果是这样,我得到了它的子目录的 inode 编号:脚本、项目、服务……

但我不知道该怎么办! 我试图根据this guide推断出这些inode的位置, 但由于我无法找到已删除文件系统的超级块,我只需要猜测块大小、块数…… 这对我来说似乎有点模糊,希望能得到结果。

那么您能否为获得 inode 偏移量所需的所有值设置一些间隔,以及获得该偏移量的更正式的公式?

【问题讨论】:

    标签: linux filesystems data-recovery ext2


    【解决方案1】:

    如果您只删除了分区表(或修改了它),您仍然可以获取您的数据,如果数据没有被重新用于其他用途。

    ext2 文件系统在超级块中有一个 MAGIC 编号,因此要恢复您的分区,您只需搜索它。我在一台机器上执行此操作,并且能够在一个磁盘中恢复的不是一个,而是七个分区。你有一些机会得到无效的数字,但只要寻找那个魔法。幻数在include/uapi/linux/magic.h 中定义,值为#define EXT2_SUPER_MAGIC 0xEF53(它位于偏移量#define EXT2_SB_MAGIC_OFFSET 0x38 ---来自文件include/linux/ext2_fs.h

    要搜索超级块,只需尝试在磁盘的一个扇区中的偏移量0x38 处找到0xef53,它将标记该分区的第一个块。请注意,该超级块在一个分区中被复制了多次,因此您会找到它的所有副本。

    祝你好运! (当它发生在我身上时我有)


    编辑(举例说明)

    只需在我自己的一个分区中查看幻数:

    # hd /dev/sda3 | head -20
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00000400  40 62 08 00 00 87 21 00  26 ad 01 00 f6 30 15 00  |@b....!.&....0..|
    00000410  1d 31 08 00 00 00 00 00  02 00 00 00 02 00 00 00  |.1..............|
    00000420  00 80 00 00 00 80 00 00  90 1f 00 00 cf 60 af 55  |.............`.U|
    00000430  fc 8a af 55 2d 00 ff ff  53 ef 01 00 01 00 00 00  |...U-...S.......|<- HERE!!!
    00000440  36 38 9d 55 00 00 00 00  00 00 00 00 01 00 00 00  |68.U............|
    00000450  00 00 00 00 0b 00 00 00  00 01 00 00 3c 00 00 00  |............<...|
    00000460  46 02 00 00 7b 00 00 00  5a bf 87 15 12 8f 44 3b  |F...{...Z.....D;|
    00000470  97 e7 f3 74 4d 75 69 12  72 6f 6f 74 00 00 00 00  |...tMui.root....|
    00000480  00 00 00 00 00 00 00 00  2f 00 61 72 67 65 74 00  |......../.arget.|
    00000490  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000004c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 18 02  |................|
    000004d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000004e0  08 00 00 00 00 00 00 00  00 00 00 00 93 54 99 ab  |.............T..|
    000004f0  aa 64 46 b3 a6 73 94 34  a3 79 46 28 01 01 00 00  |.dF..s.4.yF(....|
    00000500  0c 00 00 00 00 00 00 00  e5 61 92 55 0a f3 02 00  |.........a.U....|
    00000510  04 00 00 00 00 00 00 00  00 00 00 00 ff 7f 00 00  |................|
    00000520  00 80 10 00 ff 7f 00 00  01 00 00 00 ff ff 10 00  |................|
    

    记住它在偏移量0x38 从块原点开始计数,并假设超级块是第二个块(块 0 为引导代码保留,因此它将是块 1,每个块有两个扇区,以形成 1k 块大小) 在分区中,因此您必须从幻数的开头倒回 0x438 字节以获得分区原点。

    我已在整个磁盘上运行该命令,得到以下结果:

    # hd /dev/sda | grep " [0-9a-f][0-9a-f]  53 ef" | sed -e 's/^/    /' | head
    006f05f0  ee 00 00 11 66 0a 00 00  53 ef 00 00 11 66 2d 00  |....f...S....f-.|
    007c21d0  55 2a aa 7d f4 aa 89 55  53 ef a4 91 70 40 c1 00  |U*.}...US...p@..|
    20100430  fc 8a af 55 2d 00 ff ff  53 ef 01 00 01 00 00 00  |...U-...S.......|
    2289a910  0f 8f 4f 03 00 00 81 fe  53 ef 00 00 0f 84 ce 04  |..O.....S.......|
    230d4c70  0a 00 00 00 1c 00 00 00  53 ef 01 00 00 00 00 00  |........S.......|
    231b7e50  a0 73 07 00 00 00 00 00  53 ef 0d 00 00 00 00 00  |.s......S.......|
    23dbd230  d5 08 ad 2b ee 71 07 8a  53 ef c2 89 d4 bb 09 1f  |...+.q..S.......|
    25c0c9e0  06 00 00 00 00 4f 59 c0  53 ef 32 c0 0e 00 00 00  |.....OY.S.2.....|
    25d72ca0  b0 b4 7b 3d a4 f7 84 3b  53 ef ba 3c 1f 32 b9 3c  |..{=...;S..<.2.<|
    25f0eab0  f1 fd 02 be 28 59 67 3c  53 ef 9c bd 04 30 72 bd  |....(Yg<S....0r.|
    

    显然,此列表中无趣的行比我们需要的要多得多。为了在这里找到有趣的,我们必须对这些数字进行一些计算。我们已经看到扇区有 512 字节长(这是十六进制的 0x200),我们可以在偏移量 0x438 处获得超级块魔法,因此我们预计有效偏移量仅在 0xXXXXXX[02468ace]38 处。只需选择偏移量以该表达式结尾的行,您将在偏移量0x20100430 处获得第一个有效的超级块(在第三行中)。 减去0x430得到分区的字节偏移量(0x20100000,然后将结果除以0x200,得到0x1008001050624

    # fdisk -l /dev/sda | sed -e 's/^/    /'
    
    Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: gpt
    Disk identifier: DF97DAD4-727D-4BB3-BD7B-3C5A584A2747
    
    Device         Start        End    Sectors   Size Type
    /dev/sda1       2048     526335     524288   256M EFI System
    /dev/sda2     526336    1050623     524288   256M BIOS boot
    /dev/sda3    1050624   18628607   17577984   8.4G Linux filesystem  <-- HERE!!!
    /dev/sda4   18628608   77221887   58593280    28G Linux filesystem
    /dev/sda5   77221888   85035007    7813120   3.7G Linux filesystem
    /dev/sda6   85035008  104566783   19531776   9.3G Linux filesystem
    /dev/sda7  104566784  135817215   31250432  14.9G Linux swap
    /dev/sda8  135817216  155348991   19531776   9.3G Linux filesystem
    /dev/sda9  155348992 1953523711 1798174720 857.4G Linux filesystem
    

    【讨论】:

    • 感谢您的回答。我已经搜索了 ext2 签名没有结果。
    • 如果卷很大,您至少会得到超级块副本.... 或者您可能已经格式化了磁盘并选择了擦除所有磁盘。
    • 我在想新分区已经覆盖了所有的超级块副本。但是因为序列是小端写的,所以我不得不搜索0x53EF。我得到了很多结果!
    • 超级块副本分布在整个分区(每个块组有一个),因此您可能丢失了超过 80% 的卷。小端问题在我的示例中进行了说明。看看#define 和要搜索的 grep 模式(我已经包含了深入说明的命令)
    • 我还检查了 magid 编号的前一个字段是允许的最大安装数。默认情况下,该字段初始化为 -1 (0xff 0xff) 所以尝试使用grep 'ff ff 53 ef' 进行搜索,你会找到很多。如果您没有更改最大装载限制,这可能会有所帮助。
    猜你喜欢
    • 2015-02-03
    • 2015-05-18
    • 2016-09-12
    • 1970-01-01
    • 2020-11-10
    • 2019-04-23
    • 2017-03-14
    • 2013-12-09
    • 2016-05-27
    相关资源
    最近更新 更多