EXT4 파일 시스템 파일 복구

2025.02.24 - [Forensic/File System] - EXT4 파일 시스템 파일 삭제 원리

EXT4 파일 시스템 파일 삭제 원리

해당 글을 먼저 보고오시는것을 추천합니다. 

---

 

이번 과정은 Kali Linux 환경에서 진행되었으며, 사용한 도구는 다음과 같습니다.

사용 툴

Linux: fls, istat, e2fsck, extundelete
Windows: HxD
 
먼저 fls 명령어를 사용해 삭제된 파일 목록을 확인합니다.
fls는 EXT4 파일 시스템에서 디렉터리 및 파일 목록을 출력하는 도구입니다.

 
 
 

• d/d 11: lost+found
  • d/d :디렉터리(directory)를 의미함.
  • 11 : inode 번호 (파일 시스템에서 파일을 식별하는 고유 번호).
  • lost+found : 파일 시스템 복구 시 손상된 파일을 저장하는 디렉터리.
    • fsck 같은 도구가 실행되면 복구된 파일이 여기에 저장될 수 있다.
• V/V 64001: $OrphanFiles
  • V/V : 특수한 파일 또는 가상 파일을 의미.
  • 64001 : inode 번호.
  • $OrphanFiles : 고아 파일 (Orphan Files) 을 관리하는 특수한 구조.
    • 파일 시스템에서 참조되지 않는 파일들이 여기에 포함될 가능성이 있다.

파일 시스템의 inode 정보를 확인하기 위해 istat 명령어를 실행합니다.
istat은 특정 inode의 상세 정보를 출력하는 명령어이다.

하지만 오류가 뜬다. 해당 오류는
ext2/ext3/ext4 파일 시스템에서 잘못된 inode 주소를 조회하려 할 때 발생하는 문제이다. 
하지만 나중에 생각해보면 64001을 inode로 넣은 것이 이상한 행위였다.
이후 삭제 파일을 찾지 못해 이게 정상적인 파일 시스템인가를 의심했다. 손상된 파일시스템일 수 있으니 
이것을 e2fsck 툴을 이용해 확인했다.
e2fsck는 EXT 계열 파일 시스템을 검사하고 복구하는 도구이다.

 

• clean
  • 파일 시스템이 정상적으로 마운트 및 사용되고 있으며, 손상되지 않았음을 의미한다.
• 11/64000 files
  • 이 파일 시스템은 최대 64,000개의 파일(inodes) 저장 가능.
  • 현재 11개의 파일이 사용 중.
• 8748/256000 blocks
  • 전체 블록 수: 256,000개.
  • 사용 중인 블록 수: 8,748개.

손상되지 않았기에 extundelete 툴을 사용하기로 했다. 

하지만 그전에 마지막으로 자동화 도구를 사용하지 않고 복구 할 수 있게 시도를 해보았다.

일단 EXT4 파일 시스템의 슈퍼블록 내용을 출력하기 위해 dumpe2fs 명령어를 사용했다.

내용이 많아 요약해 설명을 하면 아래와 같다.

• EXT4 파일 시스템은 정상적인 상태이며(Filesystem state: clean), 손상되지 않았음
• Block size: 4096 (각 데이터 블록 크기: 4KB)
• Inode size: 256 (각 inode의 크기: 256 바이트)
• Inode count: 64000 (총 64,000개의 inode)
• Free inodes: 63989 (현재 사용되지 않는 inode 개수 → 거의 모든 inode가 비어 있음)

Free blocks: 247252 (파일 데이터가 저장될 수 있는 블록 중 많은 블록이 비어 있음)

이후 debugfs에서 lsdel을 통해 삭제된 파일의 inode를 찾을 수 없었다.
결국 자동 복구 도구를 사용했고, 이후 HxD를 통해 카빙을 진행하기로 했다.

extundelete 은 EXT 계열 파일 시스템에서 삭제된 파일을 복구하는 리눅스 도구이다.

 
--restore-all은 복구 가능한 모든 파일을 RECOVERED_FILES/ 디렉토리에 저장한다는 의미이다.
RECOVERED_FILES 디렉토리를 확인해보니 복구 가능한 파일이 나열된 것을 볼 수 있다.

 
이제 해당 파일들에 대한 상세정보를 알기 위해 file 명령어를 사용해줄 것이다.

위부터 순서대로  PE32+ 실행파일 즉 윈도우 실행파일(.exe), MS word 2007+ 로 문서파일, GIF 이미지, JPEG 이미지, PNG 이미지인것을 확인할 수 있다.
해당 파일을 그럼 각각의 확장자를 붙여 변경해주었다.

이후 GIF, JPEG, PNG 파일들만 확인해주니 잘 복구 된 것을 확인 할 수 있었다.

나머지 exe 파일과 문서파일은 윈도우 환경에서 열어주었다.

exe 파일은 HxD를 통해 exe 파일 시그니처를 통해 확인해 주었다.
지금은 extundelete 툴을 통해 파일 삭제 복구가 가능했지만 파일이 손상됐거나 특정 파일만 복구를 해야한다면 HxD를 통해 직접 카빙을 진행할 수 있다.
조건은 아래와 같다

•  파일이 삭제되더라도 파일 데이터(내용)는 그대로 존재할 가능성이 큼
•  EXT4에서 파일이 삭제되면 파일 이름과 inode 정보가 사라질 수 있음
•  하지만 파일의 헤더(시그니처)를 찾으면 삭제된 파일을 직접 복구 가능

그렇기에 방금과 같은 경우도 시그니처를 통해 HxD에서 찾을 수 있다.

먼저 HxD를 통해 삭제된 파일이 무엇인지 파악해주어야 한다. 

리눅스나 FTK Imager를 통해 ext4.bin의 구조를 살펴 보았을 때 lost+found 안에 파일들이 삭제된 것으로 추측했다.

그래서 HxD를 통해 해당 부분을 찾아냈고 아래 사진과 같은 파일들이 삭제된 것을 알 수 있었다.

calc.exe, test.docx, test.gif, test.jpeg, test.png, test.zip, 텍스트 파일 

이 파일들은 위 조건과 같이 파일 테이터는 그대로 존재할 가능성이 크다.

그렇다면 HxD를 통해 데이터를 확인 할 수 있다는 뜻이 된다.

그럼 데이터를 추출하기 위해 시그니처를 검색해보았다.

 

 

파일 유형	파일 이름	파일 시그니처	푸터 시그니처
실행 파일 (EXE)	calc.exe	4D 5A (MZ)	50 45 00 00 4C 01 또는 00 00 00 00
MS Word 문서	test.docx	50 4B 03 04 14 00 06 00 (PK)	50 4B 05 06 (PK..)
GIF 이미지	test.gif	47 49 46 38 37 61 (GIF87a) 47 49 46 38 39 61 (GIF89a)	00 3B
JPEG 이미지	test.jpeg	FF D8 FF (JPEG SOI)	FF D9 (JPEG EOI)
PNG 이미지	test.png	89 50 4E 47 0D 0A 1A 0A (.PNG....)	49 45 4E 44 AE 42 60 82 (IEND)
ZIP 압축 파일	test.zip	50 4B 03 04 (PK..)	50 4B 05 06 또는 50 4B 07 08
텍스트 파일	(일반 텍스트)	없음 (ASCII 또는 UTF-8 인코딩)	없음

해당 PNG 파일 시그니처를 HxD를 통해 검색하면 검색이 나온것을 확인할 수 있다.
그렇다면 푸터 시그니처까지 복사해 새로운 파일을 만들면 된다.
 

docx 파일도 추출을 해주었다. 하지만 계속 오류가 났고 이 부분은 공부를 더 해봐야 할 것 같다.

계속 gif도 시도해줬다.

잘 복구된 것을 볼 수 있다.

다음은 JPEG파일

 

zip 파일

이후 exe 파일 또한 카빙을 진행하려 했지만 exe 파일은 직접 파일 크기를 계산 해야했고 그 부분에 대해 공부를 했지만 계속 제대로 복구가 안됐다. 파일 크기에 대한 부분은 앞으로 더 공부를 해야할 것 같다.