파일시스템, FAT32

권한·2026년 3월 6일

Digital Forensic

목록 보기

5/6

File System

파일시스템에 대해서는 여기를 참고

💡 파일시스템과 디지털 포렌식
1. 파일시스템에 대한 정보 없이는 데이터의 저장 위치 알아내기 어려움
2. 데이터의 위치를 알아냈더라도, 메타데이터는 파일의 데이터와 따로 저장됨
→ 메타데이터를 알아내기 위해 파일시스템 구조에 대한 이해가 필요
3. 파일의 변경 이력을 가져오거나 삭제된 파일 복구하는 일이 가능해짐
→ 대부분의 파일시스템은 저널링 기능을 지원. 저널링 과정에서 생성된 로그는 디지털 포렌식의 주요분석대상

💡 파일시스템 공부의 필요성
1. 새 공격기법에 대한 심츠적 분석 가능
2. 도구를 온전히 신뢰할 수 없음. 파일시스템 분석을 통해 도구에서 찾아내지 못한 흔적을 발견할지도
3. 다른 아티팩트를 분석할 때에도 큰 도움이 될 수 있음

파일 시스템 종류

운영체제	파일시스템	특징
Windows	NTFS	Windows NT 3.1 이후부터 현재까지 사용중
	ReFS	NTFS 대체 위한 차세대 파일시스템
Linux	EXT4	Linux에서 2006부터 사용중
Unix	UFS	Unix계열 운영체제에서 사용
macOS	HFS+ / APFS	Apple 구형 / 신형 파일시스템
공통	FAT / FAT32	초기 Windows가 사용. 현재는 USB에 주로 씀
	exFAT	FAT32의 크기 단점 개선

NTFS (New Technology File System)
ReFS (Resilient File System)
EXT4 (Extended File System4)
UFS (Unix File System)
HFS+ (Hierarchical File System Extended)
APFS (Apple File System)
FAT32 (File Allocation Table)
exFAT (Extended File Allocation Table)

MBR과 VBR

볼륨의 가장 기본을 이루는 구조
컴퓨터 부팅 과정에서 사용되는 데이터.
메인보드의 BIOS가 POST(Power On Self-Test) & 기본적인 하드웨어 점검 끝내면 MBR내 부트코드 호출

MBR

Master Boot Record. 디스크의 가장 첫 섹터(512바이트)에 저장되는 데이터

💡 섹터 : 디스크 최소 기억 단위. 전통적 HDD에서 512바이트
저장장치 파티션 정보, 각 파티션에 설치된 볼륨 정보 가지고있음
- MBR부트코드는 이 정보를 바탕으로 부팅가능한 볼륨 식별, 해당 볼륨의 부트코드로 실행흐름 넘김
- VBR부트코드는 실행 흐름 넘겨받아 해당 볼륨에서 컴퓨터 부팅되도록 부트로더&커널 로드
```
               ↑ → → → → → → → → ↓
BIOS - POST → MBR | MBR Slack | VBR | Volume Data 
```
  💡Slack 슬랙
  : 파일시스템/데이터 구조의 빈 공간을 의미. 파일슬랙, RAM슬랙 등 다양한 슬랙 존재

MBR 구조

*HxD를 관리자 권한으로 실행 후 도구 > 디스크 열기 로 확인가능

부트코드 0x0 - 0x1BD : 부팅과정에서 이용되는 코드
파티션 테이블 엔트리 #1 ~ #4 0x1BE - 0x1CD, 0x1CE - 0x1DD, 0x1DE - 0x1ED, 0x1EE - 0x1FD : 각 파티션 정보(16바이트)
- 부트플래그 0x0 - 0x0 (1) : 부팅불가0x00, 부팅가능0x80
- CHS 시작주소 0x1 - 0x3 (3) : CHS방식 기반 시작 주소(섹터)
- 파일시스템 타입 0x4 - 0x4 (1) : NTFS0x07, FAT320x0C...
- CHS 끝 주소 0x5 - 0x7 (3) : CHS방식 기반 끝 주소(섹터)
- LBA 시작주소 0x8 - 0xB (4) : LBA방식 기반 시작 주소(섹터)
- 파티션 총 섹터 개수 0xC - 0xF (4) : 섹터개수 * 512 = 전체 섹터 크기
시그니처 0xFE - 0x1FF : 0x55 0xAA

💡 CHS(Cylinder-Head-Sector)와 LBA(Logical Block Addressing)
HDD 안에서 주소 표현 방식.

CHS : HDD의 실린더, 헤드, 섹터라는 물리적 특성 이용해 표기 (현재는 거의 사용X)

LBA : 저장장치 내의 모든 섹터들을 일차원적으로 배열해 순서대로 숫자 지정해 주소 계산

VBR

Volume Boot Record. 볼륨의 가장 첫 섹터에 저장되는 데이터. 하나 이상의 섹터로 구성
파일 시스템마다 구조가 모두 다르다

FAT32

File Allocation Table : 파일이 저장되는 위치를 기록한 테이블

Reserved Area

32개의 섹터
구성
- Boot Sector : 0번섹터(원본), 6번섹터(백업)
  - Jump Command 0x0 - 0x2 : 부트코드로 점프
    - FAT32 파일시스템을 가진 것이 USB밖에 없어서, 저장용도로 사용하던 USB를 사용했다.
      0x00-0x03값이 EB 00 90인데, 이는 굳이 점프해서 부트코드를 실행하지 않아도 된다는 뜻이다. 운영체제 부팅을 위한 용도는 EB 58 90으로 시작할텐데, 이는 현재위치에서 0x58만큼 즉 88바이트만큼 점프하라는 소리이다.
  - BPB(Bios Parameter Block) 0x3 - 0x5A : 볼륨 전반적인 설정 저장. 디스크의 신분증
    - OEM ID : 포맷을 수행한 운영체제나 도구의 이름 적는 옵션 영역. FAT32의 경우 MSDOS5.0으로 고정(윈도우 탐색기로 포맷)
      *공장 출고시 자체툴로 초기화하거나, 서드파티 둘, 리눅스, AOS에서 포맷 시 다른 값이나 공백일 수도 있다.
    - Reserved Sector : 0x12. FAT영역 이전에 존재하는 섹터 수. FAT영역은 0x12 * 0x200 = 0x2400에 위치
    - Total Sector 32 : 0x394DFE0. 볼륨 총 섹터 수
    - FAT Size 32 : 0x3947. FAT Area 1개의 크기. 0x3947 * 0x200 = 0x728E00
    - Volume Serial Number :0xEED5492B. 볼륨 식별하는 4바이트로 구성된 숫자
    - Voulme Label : NO NAME. 사용자가 볼륨에 붙인 이름
    - File System Type : FAT32
  - 부트코드 :0x5B - 0x1FD : 볼륨 부트 코드
  - 시그니처 0x1FE - 0x1FF : 0x55 0xAA
- FSINFO : 1번섹터(원), 7번섹터(백)
- Boot Strap : 2번섹터(원), 8번섹터(백)
- Reserved Sector : 일반적으로 빈 공간. 나머지 섹터들에 해당

FAT Area

FAT Table 2개(FAT#1, FAT#2)가 연속으로 존재하는 영역. FAT Table은 파일시스템에 존재하는 파일 및 폴더에 대한 메타데이터를 저장하는 공간이다.
*2개인 이유는 원본과, 백업

FAT Area 오프셋 = VBR 오프셋 + Reserved Sector * 섹터크기(FAT#1)

(FAT#2는 FAT#1섹터 + FAT Size로 이동해 접근할 수 있음)

여러개의 엔트리로 구성되며, 각각의 엔트리는 Data Area 클러스터의 할당상태를 나타냄
💡 엔트리 Entry
- '항목'이나 '기록' (사전적 정의)
- 디스크의 각 방(클러스터)이 현재 어떤 상태인지 적어놓은 장부의 한 칸
4바이트마다 1개의 엔트리를 구성. 0, 1번 엔트리는 사용하지 않는다(시스템에 의해 사용되는 특별한 엔트리).
Data Area의 클러스터는 0x1000바이트 크기를 가지고, FAT Area의 하나의 엔트리가 하나의 클러스터와7 1:1대응 (FAT에서는 엔트리번호 == 클러스터 번호)
0x00 00 00 00 : Unassigned
0x(Entry Number) : Allocated (다음에 읽을 엔트리 넘버)
0xFF FF FF 0F : End of Marker
0xFF FF FF F7 : Bad Cluster

Data Area

FAT Area 주소에서 FAT크기 2개를 더한 값

Data Area Offset 
= VBR Offset + Reserved Sector * Sector size + FAT size * Sector size * 2

→ FAT32의 루트 디렉토리가 위치. 2번 클러스터이며, FAT 테이블의 2번 엔트리에 대응 0 + 0x12 * 0x200 + 0x3947 * 0x200 * 2 = 0xE54000

Root Directory에는 Directory Entry라는 구조가 반복되어 저장된다. 이미지는 Directory Entry의 구조이다.
- SFN에서 Attributes의 역할은 속성을 의미한다. ＊LFN의 경우 0, 1, 2, 3번 비트를 모두 켜 0x0F 고정이다. LFN조각이라는 신호가 된다.
- Reserved영역의 0x0D오프셋은 Creation Time ms의 역할을 하기도 한다. 즉 파일 생성 시간을 10ms 단위로 기록. (0x82 = 130이므로 1300ms = 1.3s시점에 생성됨을 뜻함)
- Create Time 영역의 값은 2진수로 변환하여 Hour(5), Minute(6), Second(5) 순서로 잘라 10진수로 계산한다. 5비트로는 0~31을 저장할 수 있기에 FAT파일 시스템은 초를 2초 단위로 저장한다. 따라서 초는 * 2를 해주어야한다.
- Create Date 영역의 값은 2진수로 변환하여 Year(7), Month(4), Date(5)로 잘라서 계산한다. 년도는 1980년을 기준으로 더해서 계산한다.
- Accessed Date, Written Time, Written Date도 위와 동일하게 계산하면 된다.
- FAT에서는 마지막 접근에 대해 날짜 정보만 유지하기에 MAC시간(Modified, Accessed, Created) 정보는 완벽히 표현하지 못한다.
디렉토리 엔트리는 이름을 표현할 수 있는 필드가 8바이트이다. 첫번째 바이트는 파일이 파일시스템 상에 존재할 경우 이름을 표현하기 위해 사용되고, 삭제되었을 경우 0xE5로 파일이 삭제되었음을 나타낸다.
- 파일의 이름이 8바이트를 초과할 경우 Long File Name(LFN) 엔트리라는 구조를 사용해 표현한다. 하나의 LFN엔트리는 13문자까지 표현가능하기에, 13문자를 초과한다면 하나 이상의 LFN이 사용된다.
  → 여러개의 엔트리가 사용될 경우 Offset 0번의 Seq Num으로 순서를 구분한다.
  - 긴 파일이름을 저장할 때 LFN아래에 SFN이 반드시 붙는다. LFN엔트리가 SFN엔트리와 관련 있는 것이 맞는지 확인해야하는데, 그 방법이 체크섬 Checksum(Chesum)이다. 모든 LFN엔트리의 0x0D 위치에 똑같이 적어둔다.
    💡 체크섬 생성은 SFN의 11바이트(이름8+확장자3)을 이용한다.
    1. sum = 0
    2. sum의 비트를 오른쪽으로 비트 회전하여 한 문자의 아스키값을 더한다.
    3. 2번을 반복하며 11개를 다 돌리고 남은 최종 1바이트가 체크섬이 된다.
Data Area 찾아가기
```
원본 데이터 주소 : Root Directory + 클러스터 크기 * (클러스터 번호 - 2)
```
💡 Ctrl + G : 오프셋 이동
- CAN0226 폴더 - First Cluster High&Low가 각각 0x001B, 0x1863이므로 원본은 0x1B1863번째 클러스터에 있다. (상위2바이트가 0x0000인 경우 클러스터 번호가 작아 하위2바이트만으로 충분히 표현 가능한 것이다.)
  0xE54000 + 0x4000 * (0x1B1863 - 2) = 0xE54000 + 0x6C6184000 = 0x6C6FD8000
  
  forensic-LFNname.txt 파일 - 0x50006번 클러스터에 위치.
  0xE54000 + 0x4000 * (0x50006 - 2) = 0xE54000 + 0x140010000 = 0x140E64000

❓
1. 왜 SFN엔 무조건 대문자로 저장이되는가?
-> SFN은 옛날방식, LFN은 최근방식을 따른다. 옛날 방식에서는 대소문자를 굳이 구별해서 저장할 여유가 없었기에 시스템적으로 파일 이름은 무조건 대문자로 처리했다. (대소문자를 구분하려면 'a'인지 'A'인지 매번 검사해야함)
2. 0x00이 왜 사이사이에 존재하는가?
-> 유니코드를 이용하기 때문에 U+0066을 저장해 둔 것이다. 반면 SFN은 아스키를 사용하기에 빈틈없이 붙어서 보인다.
3. 왜 SFN위에 LFN이 위치하지?
-> OS가 디렉토리를 읽을 때 SFN바로 위에 있는 LFN들을 역순으로 수집하여 이름을 완성하기 때문이다.
4. 두번째 LFN의 값이 0x42인 이유?
-> 두번째라는 0x02에 마지막 조각이라는 신호인 0x40이 합쳐진 것이다.

❓ 한글 이름의 파일명일 경우 파일 추가해줬다.
0xE543C0이 추가한 한국어 파일인듯 하다... (확장자:TXT, 두줄위에 01, 두줄위에 42)
디렉토리 엔트리에서는 완성형 한글코드 값을 사용한다。
안 0xBEC8, 녕 0xB3E7, 하 0xC7CF, 세 0xBCBC, 요 0xBFE4, 반 0xB9DD, 갑 0xB0A9, 습 0xBDC0, 니 0xB4CF, 다 0xB4D9 완성형 한글코드 안녕하～TXT 로 저장되는 것 같다.(리틀엔디언 아님. 기본적으로 1바이트씩 순서대로읽음) LFN은 유니코드다. (리틀엔디언 적용된다. 48 C5는 U+C548로 해석) 유니코드 디코더