这实际上是一个 ctf 游戏：hackcenter.com 的 Enigma 2017 练习 我们必须在 ext3 上恢复已删除的文件。我正在关注本教程。
inode 为 1036。 istat 给出 Group 0
fsstat undelete.img
Group: 0:
Inode Range: 1 - 1280
...
Inode Table: 24 - 183
...
从这里开始，节点表的大小为 160 个块，每个块有 8 个 inode。索引节点 1036 位于块 153 中，是第 4 个条目。
这得到了证实
debugfs -R 'imap <1036>' undelete.img
debugfs 1.43.4 (31-Jan-2017)
Inode 1036 is part of block group 0
located at block 153, offset 0x0180
jls undelete.img | grep 153$
46: Unallocated FS Block 2153
206: Unallocated FS Block 153
214: Unallocated FS Block 153
224: Unallocated FS Block 153
680: Unallocated FS Block 4153
jcat undelete.img 8 206 | dd bs=128 skip=3 count=1 | xxd
1+0 records in
1+0 records out
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
128 bytes copied, 0,00719467 s, 17,8 kB/s
jcat undelete.img 8 214 | dd bs=128 skip=3 count=1 | xxd
1+0 records in
1+0 records out
00000000: a481 0000 2000 0000 4d70 8b58 4d70 8b58 .... ...Mp.XMp.X
00000010: 4d70 8b58 0000 0000 0000 0100 0200 0000 Mp.X............
00000020: 0000 0000 0100 0000 ef08 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 17ea 60e7 0000 0000 0000 0000 ......`.........
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
128 bytes copied, 0,00714798 s, 17,9 kB/s
jcat undelete.img 8 224 | dd bs=128 skip=3 count=1 | xxd
1+0 records in
1+0 records out
00000000: a481 0000 0000 0000 4d70 8b58 4d70 8b58 ........Mp.XMp.X
00000010: 4d70 8b58 4d70 8b58 0000 0000 0000 0000 Mp.XMp.X........
00000020: 0000 0000 0100 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 17ea 60e7 0000 0000 0000 0000 ......`.........
128 bytes copied, 0,00556548 s, 23,0 kB/s
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
我得到的唯一直接块指针位于0x8efoffset 处40。块大小由 报告fsstat。但
dd bs=1024 skip=2287 count=1 if=undelete.img | xxd
只给出零。
我不知道出了什么问题。
答案1
您恰好忘记提及文件系统映像的 URL，但在 hackcenter.com 上注册后，找到它并不难。（我不会在这里重复 URL）。
让我们看看图像并弄清楚会发生什么，而不是盲目遵循食谱。fls显示有很多名为 等的文件filler-0，filler-1直到filler-1023，然后有一个文件key已被删除。
寻找提交
jls undelete.img | grep Commit
...
228: Unallocated Commit Block (seq: 9, sec: 1485533263.2387673088)
...
发现这9是最后一次提交。让我们看看提交之前发生了什么（我已经注释了块号）
205: Unallocated FS Block 3112
206: Unallocated FS Block 153 # our inode
207: Unallocated FS Block 3113 # data
208: Unallocated FS Block 3114 # data
209: Unallocated FS Block 3115 # data
210: Unallocated Commit Block (seq: 7, sec: 1485533262.1970733056)
211: Unallocated Descriptor Block (seq: 8)
212: Unallocated FS Block 23 # inode bitmap
213: Unallocated FS Block 2 # group desc
214: Unallocated FS Block 153 # our inode blk
215: Unallocated FS Block 24 # first inode blk
216: Unallocated FS Block 5118
217: Unallocated FS Block 22 # data bitmap
218: Unallocated FS Block 3116 # data
219: Unallocated Commit Block (seq: 8, sec: 1485533262.2227109888)
220: Unallocated Descriptor Block (seq: 9)
221: Unallocated FS Block 5118
222: Unallocated FS Block 24 # first inode blk
223: Unallocated FS Block 1 # super blk
224: Unallocated FS Block 153 # our inode blk
225: Unallocated FS Block 22 # data bitmap
226: Unallocated FS Block 2 # group desc
227: Unallocated FS Block 23 # inode bitmap
228: Unallocated Commit Block (seq: 9, sec: 1485533263.2387673088)
229: Unallocated FS Block Unknown
因此，在提交 #7 中，写入了我们的索引节点块和三个数据块。在提交 #8 中，正在进行一些索引节点分配和接触，并写入单个数据块。在提交 #9 中，几乎相同，但没有写入数据块。
所以猜测是，在提交 #7 中，我们看到最后一个filler文件被创建，在提交 #8 中，key被创建和写入，而在提交 #9 中，它再次被删除。
现在让我们看看日志中索引节点块 153 的副本。 224（删除后的inode）和206（创建前的inode）有一个空的直接块指针列表。我不知道当你查看 214 时发生了什么，但我确实得到：
$ jcat undelete.img 8 214 | dd bs=128 skip=3 count=1 | xxd
00000000: a481 0000 2000 0000 4e70 8b58 4e70 8b58 .... ...Np.XNp.X
00000010: 4e70 8b58 0000 0000 0000 0100 0200 0000 Np.X............
00000020: 0000 0000 0100 0000 2c0c 0000 0000 0000 ........,.......
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 8682 a674 0000 0000 0000 0000 .......t........
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
因此，在 的直接块列表中0x28，我们在0x0c2c或处有一个块3116，正如之前猜测的那样。
让我们通过查看一些内容来验证我们是否没有偏离：
$ fcat filler-1022 undelete.img
f1755813fae6d0f542f962f50ff37184
$ dd if=undelete.img bs=1024 skip=3114 count=1 2> /dev/null ; echo
f1755813fae6d0f542f962f50ff37184
$ fcat filler-1023 undelete.img
aa08cba3462555833ffed443474bd133
$ dd if=undelete.img bs=1024 skip=3115 count=1 2> /dev/null ; echo
aa08cba3462555833ffed443474bd133
是的，正如猜测的那样，这就是书面数据filler。那么块中有什么3116？结果只是零，这意味着该块从未被更新。但我们确实在杂志上有副本。对于我们的两个filler文件：
$ jcat undelete.img 208
f1755813fae6d0f542f962f50ff37184
$ jcat undelete.img 209
aa08cba3462555833ffed443474bd133
现在找到钥匙应该很容易（出于显而易见的原因，我不会公开这样做）。