Linux
在 ext3 上恢復文件
這實際上是一個 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。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 ................我得到的唯一直接塊指針
0x8ef位於 offset40。塊大小由 報告fsstat。但dd bs=1024 skip=2287 count=1 if=undelete.img | xxd只給出零。
我不知道出了什麼問題。
您很方便地忘記提及文件系統映像的 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 中，我們的 inode 塊和三個數據塊被寫入。在送出 #8 中，對 inode 進行了一些分配和接觸，並寫入了一個數據塊。在送出 #9 中，幾乎相同，但沒有寫入數據塊。
所以猜測是，在送出 #7 中，我們看到最後一個
filler文件被創建，在送出 #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，我們在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現在找到密鑰應該很容易（出於顯而易見的原因，我不會公開這樣做）。