Ext4 삭제된 파일 복구

* 직접 실험을 하며 작성한 내용으로 틀린 내용이 매우매우 있을 수 있음. (직접 분석시 케이스 참고용으로만 사용할 것.)

I. 휴지통 분석

baseball.jpg 는 shift+delete, Flag_of_South_Korea.svg.png는 휴지통으로 집어넣은 후 삭제했다.

 

휴지통에 있는 파일은 삭제된 파일이라고 보기는 어렵지만.. 아무튼 별도의 포스팅을 할 정도는 아니라 여기에 작성했다.

휴지통 삭제

Ext4 파일시스템을 사용하는 우분투에서는 다음 경로에 삭제된 파일이 저장된다. (휴지통)

~/.local/share/Trash/files

(Ext4를 사용하는 모든 운영체제가 동일하다고 볼 순 없다.)

삭제된 파일

삭제된 파일을 복원할 때 원래 있던 경로를 확인하는 방법 무엇일까?

다음 경로에 파일의 원래 경로를 저장해 놓고 복원시 참고하게 된다.

~/.local/share/Trash/info

 

삭제된 파일 원래 경로

inode 변화

휴지통에 옮겼을 때 inode 값은 그대로 유지될까?

(작성중)

II. 영구적으로 삭제된 파일 복구하기

아래 포스팅에서 /home/user/Downloads 경로에 있는 Flag_of_South_Korea.svg.png, baseball.jpg 파일을 모두 삭제했다.

https://roklcw.tistory.com/66

Ext4 파일 데이터 접근 (with Directory Entry)

 

삭제된 파일 중 Flag_of_South_Korea.svg.png의 삭제 전, 후를 비교해봤다.

파일 삭제 후 변화

디렉토리 엔트리

삭제 전 / 후

/home/user/Downlods를 확인해보니 기존에 존재하던 Flag_of_South_Korea.svg.png의 디렉토리 엔트리가 사라진 것을 확인할 수 있었다. 따라서 당장 Root directory에서 파일을 복구할 수 있는 경로를 찾기는 어려워 보인다.

파일 데이터

Flag_of_South_Korea.svg.png 파일의 데이터는 동일한 경로에 잘 남아있다.

삭제 전 / 후

파일 삭제 실습 1

2개의 실습파일 Flag_of_South_Korea.svg.png, baseball.jpg 삭제 후 재부팅을 최소 3회 진행했다.

삭제 전 / 후 비교

Flag_of_South_Korea.svg.png 파일의 inode를 조사해봤다.

삭제 전 / 후

offset	이름	삭제 전	삭제 후
0x00 ~ 0x01	i_mode	파일의 권한과 소유자를 나타냄. 구조: type(4bit) + setuid/setgid/sticky bit + user 권한 (3bit) + group 권한 (3bit) + other 권한 (3bit) 0x81B4 → 1000 000 110 110 100 1000 (0x8000) : Regular file 000: NULL 110 110 100 : rw-rw-r-- 결과: Regular file, -rw-rw-r--
0x04 ~ 0x07	i_size_lo (Size in bytes)	0x61C8	0x05
0x14 ~ 0x17	i_dtime (Deletion Time)	0x0000	0x0000
0x6C ~ 0x6F	i_size_high / i_dir_acl	0x0000	0x0000

 

inode i_block 값을 비교해본 결과는 다음과 같다.

분류	offset	이름	삭제 전	삭제 후
Header	0x06 ~ 0x07	Header의 eh_depth	0 → 따라서 Leaf nodes	0 → 따라서 Leaf nodes
Leaf nodes 1	0x00 ~ 0x03	Leaf nodes ee_block	0	0
	0x04 ~ 0x05	Leaf nodes ee_len	7	1
	0x06 ~ 0x07	Leaf nodes ee_start_hi	0x0000	0x0000
	0x08 ~ 0x0B	Leaf nodes ee_start_lo	0x20BCA7	0x3A880

 

삭제 후 i_block에 존재하는 Leaf nodes의 offset이 변경되었으며 d_time이 반영이 되지 않았다.

하지만 데이터는 동일한 경로에 잘 남아있으므로 inode가 다른 파일을 가리키도록 재할당 된 것 같다.

파일 삭제 실습 2

사실 2번 실습은 예정에 없던 실습이었다.

1번 실습을 한 결과를 보면 inode 값 자체가 달라진 모습을 볼 수 있는데, 이 부분에서 며칠을 소비한 것 같다.

 

그러다가 재부팅을 최소 3번 이상 했던게 기억이 났다.

혹시 그 이유 때문인가 싶어 파일 한 개를 삭제한 후 재부팅 없이 프로그램 종료만 하는 방식으로 재실습했다.

파일 삭제

사용한 파일은 newjeans_minji.png 파일이다.

Downloads 디렉토리 엔트리

newjeans_minji.png 파일의 inode 정보는 다음과 같다.

inode

newjeans_minji.png inode의 i_block 정보는 다음과 같다.

분류	offset	이름	값
Header	0x06 ~ 0x07	Header의 eh_depth	0 → 따라서 Leaf nodes
Leaf nodes 1	0x00 ~ 0x03	Leaf nodes ee_block	0
	0x04 ~ 0x05	Leaf nodes ee_len	0x151 → 337
	0x06 ~ 0x07	Leaf nodes ee_start_hi	0x0000
	0x08 ~ 0x0B	Leaf nodes ee_start_lo	0x453400

 

최종 : 블록번호 (ee_start_hi + ee_start_lo) *  한 블록의 크기 4096 bytes (0x1000)

ee_start_hi + ee_start_lo = 0x453400

 

(ee_start_hi + ee_start_lo) * 0x1000 = 0x453400000

PNG 파일

 

모든 과정이 증명됐으니 삭제를 진행한다. (재부팅이 아닌 프로그램 종료만 진행.)

디렉토리 엔트리가 사라졌다.

삭제 전, 후 비교

삭제 전 / 후 inode 값은 다음과 같다.

삭제 전 / 후

offset	이름	삭제 전	삭제 후
0x00 ~ 0x01	i_mode	파일의 권한과 소유자를 나타냄. 구조: type(4bit) + setuid/setgid/sticky bit + user 권한 (3bit) + group 권한 (3bit) + other 권한 (3bit) 0x8181 → 1000 000 010 000 001 1000 (0x8000) : Regular file 000: NULL 010 000 001 : -w- --- --x 결과: Regular file, -w------x
0x04 ~ 0x07	i_size_lo (Size in bytes)	0x150643	0
0x14 ~ 0x17	i_dtime (Deletion Time)	0	0x6703B871 (2024-10-07 19:31:13 UTC+9)
0x6C ~ 0x6F	i_size_high / i_dir_acl	0	0

i_block 값을 비교한 결과는 다음과 같다.

삭제 전 / 후 i_block 값

분류	offset	이름	삭제 전	삭제 후
Header	0x06 ~ 0x07	Header의 eh_depth	0 → 따라서 Leaf nodes	0 → 따라서 Leaf nodes
Leaf nodes 1	0x00 ~ 0x03	Leaf nodes ee_block	0	0
	0x04 ~ 0x05	Leaf nodes ee_len	7	0
	0x06 ~ 0x07	Leaf nodes ee_start_hi	0x0000	0
	0x08 ~ 0x0B	Leaf nodes ee_start_lo	0x20BCA7	0

 

결론: 재부팅 몇번 하는 사이에 inode가 다른 파일을 가리키도록 재할당 됐다.

시스템의 전체 용량, 실행 환경 등에 따라 영향을 받을 수 있겠지만 생각보다 inode가 빠르게 재할당 되는 모습은 조금 충격이었다.

III. 파일 복구하기

파일 삭제 실습 1, 2 어떤 상황인지에 따라 파일을 복구하는 방법은 다르다.

inode가 재할당되지 않은 경우

파일 삭제 실습 2번에 해당하는 케이스다.

 

(1) inode 번호를 아는 경우

inode 번호를 안다면 inode table에서 해당하는 inode로 접근한 후 파일의 데이터로 접근한다.

 

(2) 파일명을 아는 경우

inode 에는 파일명이 적혀있지 않다. 하지만 Journal 은 다르다.

Journal에는 메타데이터의 변경 내용이 저장되어 있으므로 파일명도 함께 남아 있을 수 있다.

따라서 파일명을 검색해주면 inode를 확인할 수 있다.

삭제된 사진이 저장되어 있던 Downloads 디렉토리 엔트리

 

(3) 파일에 대한 정보가 전혀 없을 경우

inode table, inode bitmap, journal 영역에서 삭제된 파일들의 메타데이터를 전부 수집한 후 복구한다.

inode가 재할당된 경우

파일 삭제 실습 1번에 해당하는 케이스다.

 

inode는 재할당 되었고, journal 영역에서 메타데이터를 확인하더라도 재할당 된 inode 때문에 데이터 위치로 접근할 수 없다. 따라서 시그니처 기반 파일 카빙이 이루어져야 되지 않을까 생각한다. (물론 정답이 아닐 가능성과 파일 카빙이 가능한 연구결과가 있을 수도 있다.)

IV. Reference

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

ChatGPT 검색