모두의 dream
NTFS File System 본문
I. NTFS 파일시스템
New Technology File System
FAT 파일시스템의 한계점을 개선하기 위해 개발된 파일시스템.
* 클러스터는 여러개의 섹터로 이루어져 있다.
II. NTFS 파일시스템 구조
- VBR은 파티션의 첫번째 섹터에 있다.
- 부트섹터는 VBR 첫 번째 섹터에 존재한다.
- 현재는 MBR을 개선한 GPT가 존재한다.
컴퓨터(NTFS) 부팅 절차
BIOS(POST 진행) → MBR(GPT) → VBR → 메모리(RAM)에 커널 로딩 → 운영체제 실행 및 제어권 이동
GPT (MBR)
실습 파일을 GPT 방식으로 만들어서 GPT 를 설명한다.
GPT는 기존 MBR의 한계를 해결하기 위해 만들어졌다.
운영체제에 대한 정보가 담겨있는 영역으로, 이 영역이 손상될 경우 운영체제가 정상적으로 부팅되지 않는다.
따라서 GPT(MBR) 영역을 파괴시키거나 암호화 시키는 악성코드가 존재한다.
GPT 구조의 첫 번째 섹터는 호환성을 위해 MBR과 동일하다.
LBA(Logical Block Addressing)는 논리적인 주소로 섹터에 접근하는 방법이다. 섹터 1개를 LBA n 으로 부르게 된다.
(참고: https://velog.io/@markyang92/partition)
MBR은 Boot code, Partition table entry, signature로 구성되어 있다.
BR의 마지막 2byte는 Signature로 0x55 0xAA로 끝난다.
Partition table entry는 위 사진처럼 16bytes 씩 4개로 구성되어 있다.
Partition table은 부팅이 가능한 파티션의 정보가 있는 곳이다. (멀티 부팅을 하게 되면 총 4개의 파티션 까지 가능)
이 엔트리의 값은 하드디스크를 추가하는 등 물리적으로 연결되어 있을때만 추가되는 것 같다.
Partition table entry의 데이터 구조는 다음과 같다.
Partition table entry 에서 유심히 본 곳은 부트 식별자(Boot indicator) 와 파티션 타입, 파티션의 시작위치를 가리키는 LBA 주소값과 파티션 전체의 섹터 개수였다.
| offset (bytes) | 내용 | 해석 |
| 0x04 (1 bytes) | Partition Type | 0xEE, GPT 파티션 |
| 0x08 (4 bytes) | LBA 주소값 | 0x01(리틀엔디안) → 1번 섹터(주소: 1 * 512 = 0x200) |
| 0x0C (4 bytes) | 섹터 개수 | 0xFFFFFFFF (디스크 크기가 너무 커서 이 필드에 표시할 수 없는 경우 0xFFFFFFFF로 설정) |
섹터 개수의 경우 41,943,039개로 4,294,967,295(0xFFFFFFFF) 보다 작았으나 0xFFFFFFFF로 설정되어 있었다.
이유는 잘 모르겠다. (GPT는 고정값 0xFFFFFFFF 을 가진다고 한다.)
부트 식별자가 0x00 이라 찾아봤는데 GPT(UEFI 펌웨어)에서는 사용되지 않는다는 것 같다.
https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html
부트 코드는 모든 MBR이 똑같아 보였다.
두 번째 섹터는 MBR과 구조가 달라진다.
이 부분 때문에 처음에는 MBR 구조만 검색해보며 헤맸다.
LBA는 섹터를 이용한 주소값이라고 판단했다. (자세하게 이해는 아직 못했다)
GPT Header
GPT에 대한 설정 정보를 저장하고 있으며 92bytes로 구성되어 있다.
Header 에서 유심히 본 곳은 Backup LBA, Starting LBA for partition, Ending LBA for partitions, Number of partition entries, Size of each entry 이었다.
Backup LBA: 0x27FFFFF → 41,943,039 섹터
위 섹터에 가보면 GPT Header 가 백업 되어있다.
| offset | 내용 | 해석 |
| 0x20 (8 bytes) | Backup LBA | 0x27FFFFF → 41,943,039 섹터 |
| 0x28 (8 bytes) | Starting LBA for partition | 0x22 → 34섹터 |
| 0x30 (8 bytes) | Ending LBA for partitions | 0x27FFFDE →41,943,006 섹터 |
GPT Partition Entry
각 파티션의 정보를 저장하고 있다.
Partition Entry는 GPT Header의 백업된 섹터에서 32섹터 앞에 백업되어 있다.
총 5개의 파티션이 있다고 파악된다. (최대 128개까지 가능)
실제로도 5개의 파티션이 있다.
GPT Partition entry의 구조는 다음과 같다.
| offset | bytes | 내용 |
| 0 (0x00) | 16 bytes | 파티션 타입을 표현하는 고유한 정보 |
| 16 (0x10) | 16 bytes | 파티션마다 할당하는 고유한 값 |
| 32 (0x20) | 8 bytes | 파티션 시작 주소 |
| 40 (0x28) | 8 bytes | 파티션 끝 주소 |
| 48 (0x30) | 8 bytes | 파티션 속성 (플래그) |
| 56 (0x38) | 72 bytes | 파티션 이름 |
아래 사진으로 자세히 분석해보겠다.
E 드라이브로 파티션 분할을 진행한 파티션으로 추정된다.
| First LBA | 0x2110800 → 34,670,592 섹터 |
| Last LBA | 0x26EBFFF → 40,812,543 섹터 |
34,670,592 섹터로 이동해보면 VBR을 확인할 수 있다.
VBR
VBR은 파티션의 제일 앞 부분에 위치하는 영역이다.
VBR의 백업본은 "현재 VBR이 속해 있는 파티션의 전체 섹터 개수 + VBR 주소 - 1"을 해준 섹터에 존재한다.
여기서 말하는 파티션은 GPT Partition Entry에 있는 값이 아닌 MBR에 있는 파티션을 말한다.
VBR의 첫 번째 섹터는 부트섹터이다. (한 개 이상의 섹터가 존재할 수도 있다.)
$MFTMirr는 MFT 백업본이 저장되어 있다.
BR의 마지막 2byte는 Signature로 0x55 0xAA로 끝난다.
VBR의 BPB 영역(BIOS Parameter Block)을 보면 MFT 영역에 대한 정보를 확인할 수 있다.
BPB 영역은 파일 시스템 정보를 담고 있는 영역을 뜻하며 구조 사진에서 색이 칠해져 있는 부분이 BPB 영역이다.
MFT 주소 구하는 법
어떻게 이미징을 진행했는지, 섹터와 주소 어떻게 접근할 것인지에 따라 계산 방법에 차이가 존재한다.
MFT LBA는 VBR 구조 사진에서 Start Cluster for $MFT 부분이다.
MFT
VBR 까지가 부팅을 위한 영역, Data Area는 데이터만 있는 영역.
MFT 영역을 통해 NTFS 의 모든 기능들을 사용할 수 있다. (ex. 파일접근·관리)
| 이름 | 내용 |
| MFT Entry Header | 엔트리의 기본적인 정보 저장 |
| Fixup Array | 오류나 비정상적인 변경을 찾아내서 신뢰성을 높임. |
| Attributes | 파일의 메타 데이터 저장. |
| End Marker | Attributes 의 끝을 나타냄. |
MFT Entry Header
MFT Entry Header의 구조는 다음과 같다.
Used Size of MFT Entry를 통해 MFT에서 사용된 크기를 확인할 수 있다.
Allocated size of MFT Entry는 할당된 크기로 일반적으로 0x400(1024 bytes) 값을 가진다.
이 부분이 MFT Entry Header 부분이다.
20(0x14) 번째 값을 통해 Attributes 의 주소를 확인할 수 있다.
현재 위 사진에서는 0x38 이므로 0x38 부터 Attributes 구조이다.
Attributes
common header, resident/non-resident header, attribute value 영역으로 구성.
하나의 MFT entry에는 여러 정보를 갖고 있는 여러개의 속성값을 가지고 있다.
common header
근데 분석하다 보니 속성 길이값이 4~7이 아니고 4~5가 아닌가 싶다..
어쨋든 속성 길이값을 통해 다음 속성으로 계속 넘어갈 수 있다.
복구하던 중 몇 개의 파일이 4~7로 길이 값을 가져오면 속성의 end값인 0xFFFFFFFF가 있는 위치로 가지 못했다.
resident header
속성은 크게 Resident 와 Non-Resident 형식으로 나눠진다.
둘을 구분하는 방법은 위에 보이는 Non-resident Flag 이며 0x01의 값을 가진다면 Non-resident 방식이다.
두 형식이 나눠지는 기준은 속성의 크기이며 속성의 내용이 커서 MFT 엔트리의 크기인 1,024 bytes 를 초과하는 경우 Non-Resident 형식이 된다. 대부분의 속성은 Resident 속성이며 크기가 큰 $DATA, $ATTRIBUTE_LIST 속성은 크기가 큰 경우가 존재하므로 Non-Resident가 될 수 있다.
두 형식 모두 헤더가 존재하는데, Non_resident 헤더가 좀 더 많은 내용을 담고 있다.
둘이 공통적으로 가지고 있는 헤더의 구조는 다음과 같다.
Resident Header는 위 공통헤더에 추가적으로 8byte가 더 붙게 된다.
Non-Resident Header구조는 위 공통헤더에 추가적으로 48bytes가 더 붙게 된다.
attribute value
속성의 종류들은 다음과 같다.
가장 앞에 속성 식별값이 존재하고, 속성별로 사이즈 값을 함께 가지고 있다.
파일 이름 속성은 utf-16으로 인코딩 되어있다.
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 파일을 확인할 수 있다.
NTFS 파일시스템에서 삭제된 파일은 복구(카빙)하는 방법은 아래 포스팅을 확인하면 된다.
NTFS 삭제된 파일 복원
NTFS 파일시스템에 대한 내용은 아래 링크 참고https://roklcw.tistory.com/60 NTFS File SystemI. NTFS 파일시스템 FAT 파일시스템의 한계점을 개선하기 위해 개발된 파일시스템. * 클러스터는 여러개의 섹터로
roklcw.tistory.com
IV. Reference
all
파티션 타입
https://twoicefish-secu.tistory.com/153
MBR 과 GPT
https://www.easeus.co.kr/partition-manager-software/mbr-vs-gpt.html
MBR
https://present4n6.tistory.com/16
https://blog.forensicresearch.kr/11
GPT
https://present4n6.tistory.com/112
VBR
https://blog.forensicresearch.kr/15
MFT
'분야 > Digital Forensics' 카테고리의 다른 글
| 윈도우 아티팩트 정리 (0) | 2023.09.07 |
|---|---|
| NTFS 삭제된 파일 복원 (0) | 2023.08.29 |
| 파일시스템 분석 실습 준비 (vmdk & 이미징) (0) | 2023.08.28 |
| h.264 영상 복구 (with 블랙박스) (0) | 2023.08.15 |
| 컨테이너와 코덱 (with avi, mp4) (1) | 2023.01.02 |
