Você convenientemente esqueceu de mencionar a URL da imagem do sistema de arquivos, mas depois de se registrar no hackcenter.com não foi tão difícil de encontrar. (Eu não vou repetir a URL aqui).
Em vez de seguir cegamente uma receita, vamos ver a imagem e descobrir o que acontece. fls mostra que há muitos arquivos chamados filler-0 , filler-1 etc. até filler-1023 , depois há um arquivo key e que foi excluído.
Procurando por commits
jls undelete.img | grep Commit
...
228: Unallocated Commit Block (seq: 9, sec: 1485533263.2387673088)
...
descobre que 9 é o último commit. Vamos ver o que acontece antes desse commit (anotei os números de bloco)
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
Então, no commit # 7, nosso bloco de inode e três blocos de dados foram escritos. No commit # 8, alguma alocação e toque de inode está acontecendo e um único bloco de dados é gravado. No commit # 9, é quase o mesmo, mas nenhum bloco de dados está escrito.
Então, o palpite é que no commit # 7, vemos o último dos nossos filler arquivos sendo criados, no commit # 8, key é criado e escrito, e no commit # 9, é deletado novamente. / p>
Agora vamos ver as cópias do bloco de inode 153 no diário. 224 (inode após deleção) e 206 (inode antes da criação) possuem uma lista vazia de apontadores de blocos diretos. Eu não sei o que aconteceu quando você olhou para o 214, mas eu entendo:
$ 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 ................
Portanto, na lista de bloqueio direto em 0x28 , temos um bloco em 0x0c2c ou 3116 , conforme adivinhado antes.
Vamos verificar que não estamos fora olhando para alguns conteúdos:
$ 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
Sim, são os dados em filler escritos, conforme adivinhado. Então, o que está no bloco 3116 ? Acaba por ser apenas zeros, o que significa que o bloco nunca foi atualizado. Mas nós temos cópias no diário. No caso de nossos dois arquivos filler :
$ jcat undelete.img 208
f1755813fae6d0f542f962f50ff37184
$ jcat undelete.img 209
aa08cba3462555833ffed443474bd133
E agora, encontrar a chave deve ser fácil (não vou fazê-lo publicamente, por razões óbvias).