Где найти этот toolchain?
Вы случайно забыли указать URL-адрес образа файловой системы, но после регистрации на hackcenter.com его было нетрудно найти. (Я не буду повторять URL здесь).
Вместо того, чтобы слепо следовать рецепту, давайте посмотрим на изображение и выясним, что происходит. fls показывает, что есть много файлов с именами filler-0, filler-1 и т. д. до filler-1023, затем есть файл ключ, который был удален.
При поиске коммитов
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 был записан наш блок inode и три блока данных. В коммите № 8 происходит некоторое выделение и касание индексного дескриптора, и записывается один блок данных. В коммите №9 почти то же самое, но блок данных не записывается.
Таким образом, можно предположить, что в коммите №7 мы видим, что последний из наших заполнителей создается, в коммите №8 создается и записывается ключ, а в коммите # 9, он снова удален.
Теперь давайте посмотрим на копии блока 153 inode в журнале. 224 (инод после удаления) и 206 (инод до создания) имеют пустой список указателей прямого блока. Я не знаю, что произошло, когда вы посмотрели на 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
Да, это данные в филлере записаны, как и предполагалось. Так что же находится в блоке 3116? Оказывается, это только нули, что означает, что блок никогда не обновлялся. Но у нас есть копии в журнале. В случае с нашими двумя файлами filler:
$ jcat undelete.img 208
f1755813fae6d0f542f962f50ff37184
$ jcat undelete.img 209
aa08cba3462555833ffed443474bd133
Теперь найти ключ будет несложно (публично я этого делать не буду по понятным причинам).