모두의 dream
NTFS 삭제된 파일 복원 본문
NTFS 파일시스템에 대한 내용은 아래 링크 참고
NTFS File System
I. NTFS 파일시스템 FAT 파일시스템의 한계점을 개선하기 위해 개발된 파일시스템. * 클러스터는 여러개의 섹터로 이루어져 있다. II. NTFS 파일시스템 구조 VBR은 파티션의 첫번째 섹터에 있다. 부트
roklcw.tistory.com
I. 파일 복구가 가능한 이유
파일을 삭제하면 파일의 메타데이터만 변경 되고 실제 데이터는 남아있다.
MFT Header Entry를 보면 Flags라는 값이 있는데 이 값만 변경하여 파일의 상태를 변경한다.
추후 시스템 복원 등에 사용되기 위해서는 데이터 자체를 삭제하지는 않게 된다.
II. MFT
MFT 영역에 있는 정보를 통해 삭제된 파일을 복구할 수 있다.
각 파티션의 MFT는 파티션 안에 존재한다.
MFT 영역을 이용해 삭제된 파일 복원이 가능하다.
Flags: 0x00은 사용 안하는 중(ex.파일 삭제), 0x01은 사용 중, 0x02는 디렉토리
현재 복원하고자 하는 파일은 삭제한 상태였으므로 Flags 값이 0x00 이다.
offset to first attribute: attribute(속성) 의 주소 값
현재 0x38이므로 MFT Header의 가장 앞에서 0x38 만큼 이동해주면 첫 속성의 주소로 이동할 수 있다.
Allocated size of MFT Entry 값은 할당된 엔트리의 크기로 보통 1,024(두 개의 섹터, 512 * 2) bytes로 고정되어 있다.
III. Cluster Runs
용량이 큰 파일이 클러스터에 할당될 때 연속적으로 되지 않고 비 연속적으로 할당되는 경우 Cluster Runs를 이용해서 효과적으로 관리한다. 관리할때는 클러스터 런을 표현하는 runlist를 이용한다.
$MFT 파일의 MFT Entry를 분석해서 Cluster Runs를 학습 해보려고 한다.
Data 속성의 크기는 0x70 이다.
Non-resident flag 값이 1이므로 Non-resident 방식의 속성이다.
런리스트 시작 VCN: 0x00
런리스트 끝 VCN: 0x43CBF
런리스트 시작 위치: 0x40 ($DATA 속성 시작 시점에서 0x40)
해당 속성 헤더 시작주소에 0x40을 더해주면 최종 runlist 주소가 된다.
runlist를 해석하는 방법은 다음과 같다.
데이터가 비 연속적으로 할당되어 있으므로 여러개의 runlist를 갖는다.
첫 번째 runlist를 예시로 들어보면 다음과 같다.
파일이 할당된 클러스터 개수: 0x12C00
파일이 위치한 오프셋: 0xC0000
파일의 위치: ( 0xC0000(786,432) * 8(클러스터 당 섹터 수)) + 현재 VBR 섹터
현재 VBR 섹터는 239,616 섹터이다.
결과값은 6,531,072 섹터이므로 이동해보면 $MFT 파일을 확인할 수 있다.
IV. 파일 복구
$DATA 속성에서 파일 복원에 대한 단서를 찾을 수 있음.
Non-resident 플래그 값이 1이므로 Non-resident 방식의 속성임.
런리스트 시작 VCN: 0x00
런리스트 끝 VCN: 0x0C
런리스트 시작 위치: 0x40 ($DATA 속성 시작 시점에서 0x40)
해당 속성 헤더 시작주소에 0x40을 더해주면 최종 runlist 주소가 된다.
이동한 주소는 위와 같다.
runlist를 해석해보면 다음과 같다.
0x21: 1은 현재 byte를 지나 다음 자리에서 1byte 만큼을 가리키고 파일이 할당된 클러스터의 개수(크기)를 뜻한다. 2는 파일이 위치하고 있는 오프셋의 bytes 수를 뜻한다.
위 예시에서는 runlist가 1개밖에 없다.
파일의 위치: 0x9C6 → (0x9C6(2,502) * 8(클러스터 당 섹터 수)) + 현재 VBR 섹터
복원원하고자 하는 파일의 크기는 다음과 같다.
0xC800
MFT가 속해 있는 현재 VBR 섹터는 아래와 같다. (34,670,592 섹터)
파일의 위치: 0x9C6 → (0x9C6(2,502) * 8) + 34,670,592
계산을 해보면 34,690,608 섹터에 내가 복원하고자 하는 파일이 존재하는 것을 확인할 수 있다.
파일명 복원
$FILE_NAME 속성을 확인해보면 파일이 생성된 시간과 수정시간, 접근시간, 파일명, 파일명 길이 등을 확인할 수 있다.
파일명의 길이의 경우 0x46210A0F0 주소에 있는 0x0B 값이 길이인데 utf-16 방식이므로 한 글자에 2bytes 이므로 0xB 에 2를 곱해준 값인 11이 파일명의 길이가 된다.
(파일명이 존재하는 $FILE_NAME 속성은 Resident 속성이다.)
세부적인 내용은 아래와 같다.
VI. 한계
C드라이브(윈도우 설치 파티션)에서 삭제한 파일들은 MFT 에서 찾아볼 수 없다.
이유를 모르겠어서 현재 찾아보고 있다.
2023.09.13
txt 파일에 한글로 내용을 적고 저장한 후 다시 카빙해보니 정상적으로 복원이 된다.
다만 ANSI 방식으로 저장되어 한글이 다 깨지는데 이걸 다시 한글로 복원하는 방법은 미지수다.
다운로드 폴더에서 삭제된 파일도 복원되지 않았다.
그리고 동시에 이전에 복원된 txt 파일이 복원되지 않았다.
C드라이브가 20GB로 용량이 작아서 인지, 사용자 폴더에서 삭제된건 따로 저장되는건지 등등 해소되지 않은 의문점이 여럿 존재한다.
2023.09.14
C드라이브에서 삭제된 파일의 행방은 아직 찾지 못했다.
MFT FLAG가 한번의 재부팅으로는 설정이 안된건가 싶기도 해서 전체 MFT 내용을 복원해보려고 했다.
그러던 중 MFT 에서 0x80 속성이 2번 나오는 케이스를 확인했다.
전체 MFT 내용을 복원해보려고 코드를 돌렸을 때 이상한 내용이 저장되어 확인해보니 위 문제점을 발견했다.
이에 따라 코드도 수정해야 될 것으로 보인다.
다음 공부를 위해 일단 잠시 보류하기로 했다.
VII. Reference
$FILE_NAME 속성 구조
'분야 > Digital Forensics' 카테고리의 다른 글
| Ext4 File System (0) | 2023.09.12 |
|---|---|
| 윈도우 아티팩트 정리 (0) | 2023.09.07 |
| 파일시스템 분석 실습 준비 (vmdk & 이미징) (0) | 2023.08.28 |
| NTFS File System (0) | 2023.08.28 |
| h.264 영상 복구 (with 블랙박스) (0) | 2023.08.15 |
