이번에 분석할 파일은 exFAT File System 입니다.
exFAT 이라고 불리지만 FAT64 라고 불리기도 합니다.
exFAT 파일 시스템을 다른 파일 시스템과 볼륨 크기 및 파일의 최대 크기를 비교 해 보겠습니다.
exFAT 파일의 구조를 한번 알아 보겠습니다.
- Main Root Region : 주 부트 영역
- Backup Boot Region : 백업 부트 영역
- FAT Region : FAT 영역(일반 적으로 FAT #1 만 있지만 TFAT15로 설정된 경우에는 FAT #2 가 존재 합니다.)
- Data Region : Data 영역
위의 exFAT 파일의 구조 중에서 Main Root Region 인 Volume Boot Record(VBR) 을 자세히 알아 보면 아래와 같습니다.
1. Volume Boot Record
보통 VBR 이라고 불리는 영역인 Volume Boot Record 영역은 위의 구조 레이아웃과 같이 exFAT File System 에서는 총 12개의 섹터를 가지게 됩니다.
Sector 0 : Boot Sector
Sector 1~8 : Extended Boot Sector
Sector 9 : OEM Parameter Record Sector
Sector 10 : Reserved Sector
Sector 11 : CheckSum Sector
Boot Sector : BIOS Parameter Block(BPB), 부트 코드, 시그니처
Extended Boot Sector : 추가적인 부트 코드
OEM Parameter Record Sector : 공장에서 매체 제조사에 의해 기록된 내용
Reserved Sector : 정의되어 있지 않은 예약된 영역
Checksum Sector : 이전 11 섹터에 대한 체크섬 값
Sector 9 ~ Sector 11 까지는 Boot Signature 인 0x55AA 가 존재 하지 않습니다.
0번섹터에 존재하는 Boot Sector를 먼저 살펴 보겠습니다.
1.1 Boot Sector - 0번 Sector
아래의 표는 Boot Sector 에서 크게 보았을때 아래와 같이 구조가 나뉘게 됩니다.
Boot Sector 에서는 세부적으로 어떤 값들을 가지고 있는지 확인해 보겠습니다.
1.1.1 Jump Command to Boot Code(0x00 ~ 0x02 3Byte)
FAT16 File System 관련해서 글을 작성했을때 언급한 적이 있는 내용입니다.
Jump Command to Boot Code는 CPU Jump Command 라고도 불립니다.
해당 코드는 CPU의 명령 실행 분기를 Boot Code 로 옮기는 역할을 하는 영역입니다.
아래의 표는 FAT12/16, FAT32, NTFS, exFAT 의 CPU Jump Command를 비교한 표입니다.
exFAT 파일 시스템의 Hex 데이터는 아래와 같습니다.
1.1.2 File System Name(OEM ID)(0x03 ~ 0x0A 8Byte)
해당 파일 시스템의 이름이 들어가는 자리 입니다.
1.1.3 Must Be Zero(0x0B ~ 0x3F 53Byte)
FAT 간의 오류가 발생하는 것을 막기 위해서 53바이트가 전부 0x00으로 채워져 있습니다.
1.1.4 BPB(BIOS Parameter Block)(0x40 ~ 0x77 53Byte)
위의 블록처리된 부분의 영역을 BIOS Parameter Block이라고 이야기 합니다.
0x40~0x77 까지 BPB 라고 불리는 영역에는 아래와 같은 다양한 데이터를 담고 있습니다.
모든 데이터가 다 중요하지만 하이라이트 되어 있는 데이터가 매우 중요합니다.
1.1.5 Boot Code(0x78 ~ 0x 1FDByte)
BPB 영역 바로 다음 부터는 Boot Code 가 들어 있습니다.
위의 데이터 중에서 하이라이트 된 부분이 Boot Code 이며 부트 프로그램 이라고도 이야기 하는 영역 입니다.
1.1.6 Signature(0x1FE ~ 0x 1FFByte)
Volume Boot Record Sector 에서 0번 섹터를 시작으로 8번 섹터 까지 해당 위치에 같은 시그니처가 존재 합니다.
1.2 Extended Boot Sector - 1번~8번 Sector
Extended Boot Sector 는 1번 섹터부터 8번 섹터 까지를 의미 합니다.
추가 적인 부트 코드가 들어가는 영역이며, 8번 섹터까지 전부 기록되지 않은 경우 빈 섹터는 0x00으로 채워져 있다.
또한 1.5 에서 언급한 시그니쳐인 0x55AA가 전부 기록 되어 있다.
1.3 OEM Parameter Record - 9번 Sector
OEM Parameter Record 는 공장에서 매체 제조사에 의해서 작성된 기록 내용이 들어 있습니다.
하드 디스크 에서는 현재 사용되고 있지 않습니다.
포맷 종류 중에서 완전 삭제가 아닌 일반 삭제의 포맷일 경우 해당 영역은 지워 지지 않습니다.
한 필드당 48바이트를 차지 하기 때문에 총 10개의 필드를 입력할 수 있습니다.
16바이트 GUID + 32바이트 파라미터 = 48바이트
1.4. Checksum Sector - 11번 Sector
Checksum Sector는 4개의 바이트가 반복적으로 1섹터를 채워져 있는 영역입니다.
해당 값은 이전 11섹터에 대한 체크섬 값이 들어있습니다.
예제 파일 시스템에서는 0x06E8CBA3(Little Endian) 이라고 적혀 있습니다.
2. Backup Volume Boot Record
앞에서 확인한 Volume Boot Record에 들어있는 데이터 들이 총 12개의 섹터 에 들어가 있습니다.
12섹터 부터 23섹터 까지 Volume Boot Record 순서 대로 값이 들어 있습니다.
3. FAT
FAT 영역은 아래와 같이 FAT#1 과 FAT#2 로 나뉘어 집니다.
2개의 영역으로 나뉘어 지는데 FAT#1 에는 일반적인 데이터가 들어가 있고 FAT#2에는 FAT#1에 들어가 있는 데이터의 백업 용으로 똑같은 값이 들어가 있습니다. 그렇기 때문에 크기도 동일하게 같습니다.
FAT#2 는 TexFAT 에서만 지원을 하고 있습니다.
버전 1.0 에서는 TexFAT 인 Transactional exFAT 를 지원하고 있지 않습니다.
FAT12/16/32 에서의 FAT의 역할을 클러스터 체인과 할당 상태를 표시하기 위해서 존재 했었습니다.
하지만 exFAT 에서는 할당 상태의 역할이 사라지고 비트맵을 이용한 관리를 적용 했습니다.
=> I/O의 성능이 향상
연속적인 클러스터일 경우에 FAT를 사용하지 않고, 비연속적인 클러스터일 경우에는 클러스터 체인만 사용합니다.
FAT 영역의 시작 섹터 위치는 0x50~0x53 에 있습니다.
Value가 0x80 섹터 라고 되어있기 때문에 128번섹터에 존재 할 것입니다.
FAT 구조는 아래와 같은 구조를 가지고 있습니다.
Media Type 과 Parition Status 에는 아래와 같은 데이터가 들어가게 됩니다.
앞에서 본 FAT 영역을 다시 확인해 보면 아래와 같습니다.
Cluster2~Cluster4 까지 전부 0xFFFFFFFF 으로 덮여 있는 것을 확인 할 수 있습니다.
각각의 Cluster 에는 어떤 데이터가 들어가야하는지 정해져 있습니다.
Cluster 2 : Allocation Bitmap
Cluster 3 : UP-Case Table
Cluster 4 : Root Directory
위와 같이 정해져 있는데 전부 0xFFFFFFFF 를 덮고 있는 이유는 각각의 섹터가 EOF(End of File) 를 의미하기 때문입니다.
클러스터 값에 들어갈 수있는 데이터들을 확인해 보겠습니다.
위와 같이 전부 0xFFFFFFFF 을 담고 있다면 각각의 데이터가 들어있는 섹터로 가서 확인하면 그만이지만, 하나의 섹터로 EOF 를 확인 하지못하고 데이터가 방대 하다면 클러스터를 보고 연결되는 섹터를 확인 해야 합니다.
위의 구조처럼 존재 한다면 그냥 바로 0xFFFFFFFF 를 만나서 파일 끝을 확인 하게 됩니다.
하지만 아래의 구조 처럼 0xFFFFFFFF 가 바로 나오지 않고 방대한 데이터로 인해서 클러스터가 필요 할때는 아래와 같이 참조를 하게 됩니다.
Directory Record 의 클러스터 값이 20일때 20클러스터로 가서 해당 값을 확인해서 Linked List 로 연결되는 것을 확인 할 수 있습니다.
4. Data Region
Data Region은 주요 데이터가 들어있는 영역입니다.
- Cluster Heap Area
- UP-Case Table Area
- Volume label Directory Entry
- Allocation Bitmap Directory Entry
- UP-Case Table Directory Entry
- Volume GUID Directory Entey
- File Directory Entry
- Stream Extension Entry
- File Name Extension Entry
- Windows CE Access Control Table Directory Entry
위의 내용을 Data Region에서 전부 확인 할수 있습니다.
앞에서 언급한 Data Region 영역을 확인해 보기 위해서 구조를 확인해 보겠습니다.
먼저 Data Region의 첫 섹터를 찾아 보겠습니다.
데이터 영역의 섹터 주소는 앞서 확인한 VBR에 존재 합니다.
VBR의 0x58~0x5B에 있습니다.
0x280 (640 섹터)라는 값을 가지고 있습니다.
640 섹터에 가보면 Cluster Heap 영역을 확인 할수 있습니다.
Data Region 영역에서는 클러스터 단위로 나눠져 있기 때문에 1클러스터가 몇 섹터인지 계산해 보면 아래와 같습니다.
1클러스터에 대한 섹터 값과 1섹터에 대한 바이트 값은 앞서 확인한 VBR에 같이 존재 합니다.
섹터당 바이트 수 : 0x6C
클러스터당 섹터수 : 0x6D
2^n승으로 계산 하기 때문에 섹터당 바이트 수는 2^9 = 512바이트, 클러스터당 섹터 수는 2^6 = 64바이트 입니다.
2번 클러스터가 Cluster Heap [640 섹터] 였으니까 3번 클러스터인 UP-Case Table은 704섹터에 존재 합니다.
704 섹터를 확인해 보면 아래와 같이 출력합니다.
UP-Case Table를 간략하게 설명을 해보자면 일련의 유니코드 문자를 mapping 해둔 테이블 이라고 보면 좋습니다.
4번 클러스터의 위치는 768섹터이며, 파일시스템에서 가장 중요한 Directory Entry 가 있는 클러스터입니다.
다른 FAT 파일과 달리 exFAT 파일은 앞서 언급한것 처럼 Directory Entry가 다양합니다.
- Volume label Directory Entry
- Allocation Bitmap Directory Entry
- UP-Case Table Directory Entry
- Volume GUID Directory Entey
- File Directory Entry
- Stream Extension Entry
- File Name Extension Entry
- Windows CE Access Control Table Directory Entry
위의 Directory Entry 순서대로 구조를 분석해 보도록 하겠습니다.
현재 포맷한 이후로 hello.txt 파일을 생성해둔 상태 입니다.
4.1 Volume Label Directory Entry
Volume Label Directory Entry 를 확인해 보면 아래와 같습니다.
구조 레이아웃을 확인해 보면 아래와 같습니다.
각각의 요소는 아래와 같은 값을 가지고 있습니다.
볼륨 레이블은 총 11글자가 최대 이며 볼륨 레이블이 없다면 entry type은 0x03 입니다.
4.2 Allocation Bitmap Directory Entry
Allocation Bitmap Directory Entry 를 확인해 보면 아래와 같습니다.
구조 레이아웃을 확인해 보면 아래와 같습니다.
각각의 요소는 아래와 같은 값을 가지고 있습니다.
할당 비트맵 테이블은 최대 2개 (TexFAT 사용 시)
2번 클러스터는 Cluster Heap 영역을 의미합니다.
0x01인 Bitmap Flags에 0이들어가면 1st Bitmap 을 의미하고 1이 들어가면 2st Bitmap 을 의미합니다.
4.3 UP-Case Table Directory Entry
UP-Case Table Directory Entry 를 확인해 보면 아래와 같습니다.
구조 레이아웃을 확인해 보면 아래와 같습니다.
각각의 요소는 아래와 같습니다.
파일명을 대문자로 변환할때 UP-Case Table Directory Entry 를 사용합니다.
4.4 Volume GUID Directory Entey
Volume GUID Directory Entry 를 확인해 보면 아래와 같습니다.
해당 GUID Directory Entry는 있을 수도 있고 없을 수도 있는데 해당 예제 파일에서는 없습니다.
구조 레이아웃을 살펴 보겠습니다.
각각의 요소는 아래와 같습니다.
4.5 File Directory Entry
File Directory Entry 를 확인해 보면 아래와 같습니다.
구조 레이아웃을 확인해 보면 아래와 같습니다.
각각의 요소는 아래와 같습니다.
- 생성시간, 마지막 수정시간, 마지막 접근시간 DOS TimeStamp 형식으로 저장
- 10ms 단위의 생성 및 마지막 수정시간 저장
- 윈도우 XP 환경에서 10ms 단위의 시간 필드 이상 동작 (확인 필요)
Entry Type 에 들어갈 수 있는 값은 아래와 같습니다.
└ 0x00 : 파일이름이 사용된 적이 없음
└ 0xE5 : 파일이 이미 삭제 되었지만 파일의 이름은 확인이 가능한 상태
└ 0x05 : 파일명의 첫번째 문자가 'σ'인 경우 ('σ' 의 아스키 코드 값이 0xE5 이기 때문에 0x05로 표기됨.)
파일 속성에 들어가는 값은 아래와 같습니다.
└ 0x01 : ReadOnly
└ 0x02 : Hidden
└ 0x04 : System
└ 0x10 : Directory
└ 0x20 : Archive
Timezone 위치는 파일을 생성한 위치가 사용하고 있는 Timezone에 해당하는 값이 입력됩니다.
└ 0x80 : UTC+00:00 : GreenwichStandardTime
└ 0x84 : UTC+01:00 : CentralEuropeTime
└ 0x88 : UTC+02:00 : EasternEuropeStandardTime
└ 0x8C : UTC+03:00 : MoscowStandardTime
└ 0x90 : UTC+04:00 : ArabianStandardTime
└ 0x94 : UTC+05:00 : WestAsiaStandardTime
└ 0x98 : UTC+06:00 : CentralAsiaStandardTime
└ 0x9C : UTC+07:00 : NorthAsiaStandardTime
└ 0xA0 : UTC+08:00 : NorthAsiaEastStandardTime
└ 0xA4 : UTC+09:00 : TokyoStandardTime
└ 0xA8 : UTC+10:00 : WestPacificStandardTime
└ 0xAC : UTC+11:00 : CentralPacificStandardTime
└ 0xB0 : UTC+12:00 : NewZealandStandardTime
└ 0xB4 : UTC+13:00 : TongaStandardTime
└ 0xD0 : UTC-12:00 : DatelineStandardTime
└ 0xD4 : UTC-11:00 : SamoaStandardTime
└ 0xD8 : UTC-10:00 : HawaiiStandardTime
└ 0xDC : UTC-09:00 : AlaskaStandardTime
└ 0xE0 : UTC-08:00 : PacificStandardTime
└ 0xE4 : UTC-07:00 : MountainStandardTime
└ 0xE8 : UTC-06:00 : CentralStandardTime
└ 0xEC : UTC-05:00 : EasternStandardTime
└ 0xF0 : UTC-04:00 : AtlanticStandardtime
└ 0xF2 : UTC-03:30 : NewfoundlandStandardTime
└ 0xF4 : UTC-03:00 : GreenlandStandardTime
└ 0xF8 : UTC-02:00 : Mid-AtlanticStandardTime
└ 0xFC : UTC-01:00 : AzoresStandardTime
4.6 Stream Extension Entry
Stream Extension Entry 를 확인해 보면 아래와 같습니다.
구조 레이아웃을 확인해 보면 아래와 같습니다.
각각의 요소는 아래와 같습니다.
2차 플래그에 들어가는 값은 아래와 같습니다.
└ 0x00 : Allocation Possible
=> 0 : No , 1 : Yes
└ 0x01 : No FAT Chain
=> 0 : Valid , 1 : Invalid
No FAT Chain 플래그가 1일때 클러스터가 연속적으로 할당 되어 있음을 의미, 시작 클러스터부터 파일 용량 만큼 획득
4.7 File Name Extension Entry
File Name Extension Entry 를 확인해 보면 아래와 같습니다.
구조 레이아웃을 확인해 보면 아래와 같습니다.
각각의 요소는 아래와 같습니다.
HxD 에서 확인 할 수 있는 데이터를 보면 32바이트 보다 파일명이 길어진다면 하나의 구조가 더 붙는 것을 확인 할 수 있습니다.
또한 파일 이름으로 사용이 불가능한 문자가 존재합니다.
[ 0x00~0x1F , " , * , / , : , < , > , ? , \ , | ]
4.8 Windows CE Access Control Table Directory Entry
Windows CE Access Control Table Directory Entry 를 확인해 보면 아래와 같습니다.
이 구조도 마찬 가지로 해당 예제 파일에는 존재 하지 않습니다.
그래서 구조 레이아웃만 확인해 보겠습니다.
각각의 요소는 아래와 같습니다.
버전 1.0 에서는 지원하지 않습니다.(윈도우 CE만 지원)
여기까지가 구조를 다룬 내용이고 이제 2가지의 경우를 만들어서 파일 내용을 찾아 보겠습니다.
1. 루트디렉터리에 파일생성.
2. 루트디렉터리에 디렉터리 생성후 그 안에 파일 생성.
1번 방법으로 파일을 만들어보면 루트 디렉터리에서 구조를 확인 할 수 있습니다.
해당 Directory Entry를 확인해 보면 hello.txt 라는 이름을 가지고 있는 것을 확인 할 수 있고, 해당 파일 내용은 8번 클러스터에 있는것을 알 수 있습니다.
파일 속성이 0x20 인것으로 보아 아카이브로 일반적인 파일이라는 것을 알 수 있습니다.
640섹터(2클러스터) + 64*6(6클러스터) = 1024섹터(8클러스터) 로 가면됩니다.
2번 방법으로 파일을 만들어 보면 루트 디렉터리에서 구조를 확인 할 수 있습니다.
해당 Directory Entry를 확인해 보면 해당 폴더가 Hello Directory 라는 이름을 가지고 있는 것을 확인 할 수 있고, 파일 속성을 확인해 보면 0x10 으로 디렉터리라는 것을 알 수 있습니다.
해당 디렉터리에 들어있는 파일 은 9번 클러스터에 있는것을 알 수 있습니다.
9번 클러스터는 1088 섹터에 있습니다.
파일이름은 Hello File.txt 인것을 알 수 있으며 파일 내용은 10번 클러스터인 1152섹터입니다.
'File System' 카테고리의 다른 글
| FAT32(File Allocation Table) File System Structure Analysis (0) | 2020.03.29 |
|---|---|
| GPT(GUID Partition Table) Partition Structure Analysis (2) | 2020.03.16 |
| MBR(Master Boot Record) Partition Structure Analysis (0) | 2020.03.16 |
| 디렉터리 엔트리 분석 [Directory Entry Analysis] - SFN, LFN (0) | 2020.02.11 |
| FAT16(File Allocation Table) File System Structure Analysis (2) | 2020.02.07 |
