ext3からファイルを復元する

Question

もしファイルシステムイメージのURLを言及していませんでしたが、hackcenter.comに登録した後に見つけることは難しくありません。（ここではURLを繰り返しません）。

盲目的にレシピに従うのではなく、イメージを見て何を期待するのか見てみましょう。flsなどの名前を持つファイルが複数あることがわかりますがfiller-0、以降は 1 つのファイルが削除されました。filler-1filler-1023key

提出物を探しています

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ブロックと3つのデータブロックが書き込まれます。コミット＃8では、いくつかのinode割り当てとタッチが行われ、個々のデータブロックが記録されます。コミット＃9ではほとんど同じですが、データブロックは書き込まれません。

fillerしたがって、コミット＃7では最後のファイルが作成され、コミット＃8ではファイルが作成され記録keyされ、コミット＃9では再び削除されると推測されます。

それでは、ログ内のinodeブロック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あります。0x0c2c3116

いくつかの点を見て、私たちが離脱していないことを確認しましょう。

$ 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

これで、キーを見つけるのは簡単です（明らかな理由から、公にこれを行うことはありません）。

Answer 1