ext3에서 파일 복원

Question

혹시 파일 시스템 이미지의 URL을 언급하지 않으셨는데, hackcenter.com에 등록하신 후 찾는 것은 어렵지 않습니다. (여기서 URL을 반복하지 않겠습니다).

맹목적으로 레시피를 따르는 대신, 이미지를 보고 무엇을 기대하는지 알아봅시다. fls등의 이름을 가진 파일이 여러 개 있다는 것을 알 수 있는데 filler-0, 이후에는 하나의 파일이 삭제되었습니다.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 블록과 세 개의 데이터 블록이 기록됩니다. 커밋 #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? 결과는 0입니다. 이는 블록이 업데이트되지 않았음을 의미합니다. 하지만 우리 잡지에는 사본이 있어요. 두 filler파일의 경우:

$ jcat undelete.img 208
f1755813fae6d0f542f962f50ff37184

$ jcat undelete.img 209
aa08cba3462555833ffed443474bd133

이제 키를 찾는 것이 쉬울 것입니다(명백한 이유로 공개적으로 이 작업을 수행하지는 않겠습니다).

Answer 1