Proneer | Security is a people problem...
이전에 MFT 엔트리 내의 속성에 대해 간략하게 살펴보았다. 이번에는 각 속성들에게 공통으로 존재하는 속성 헤더에 대해서 살펴보겠다. MFT 엔트리도 엔트리의 메타정보 표현을 위해 엔트리 헤더가 존재하는 것을 이미 살펴보았다. 이와 같이 각 속성에도 속성의 기본적인 메타정보를 표현하기 위해 속성 헤더를 사용한다.
속성 헤더 이후에는 앞서 살펴본 여러 가지 속성들($STANDARD_INFORMATION, $FILE_NAME, $DATA 등)이 따라온다. 그럼 속성 헤더의 구조가 어떻게 되는지 살펴보자.
공통된 헤더
앞서 속성은 크게 Resident와 Non-resident 형식으로 나눠진다고 언급했다. 속성 헤더 역시 각 속성 형식마다 다른 헤더를 가진다. 하지만 앞의 16바이트 영역은 두 형식 모두 동일하다. 먼저, 두 형식 모두 공통된 헤더 항목을 살펴보자. 다음은 16바이트의 공통된 헤더의 데이터 구조이다.
16 바이트의 공통된 헤더 이후에는 Resident 인지 Non-resident 인지에 따라 나머지 속성 헤더의 내용이 달라진다. 결국, Resident 인지 Non-resident 인지에 따라 속성 헤더의 길이도 달라지게 된다. 하지만 공통된 헤더 항목에 속성 길이 필드가 주어지므로 걱정할 필요 없다. 만약 원하는 속성을 찾고 싶다면 Fixup 배열 이후에 속성 길이만큼 이동하면서 속성 타입 식별자를 확인하여 원하는 속성을 찾으면 된다. 원하는 속성을 찾은 경우 필요한 작업을 수행하면 된다.
Resident 속성 헤더
Resident 속성일 경우, 속성 헤더의 데이터 구조는 다음과 같다.
다음은 $MFT 파일의 MFT 엔트리 속성 중 Resident 속성인 $FILE_NAME 속성이다.
위의 Resident 속성 헤더 데이터 구조대로 해석해보면 다음과 같다.
Non-Resident 속성 헤더
Non-Resident 속성일 경우, 속성 헤더의 데이터 구조는 다음과 같다.
Non-resident는 속성 내용이 외부 클러스터에 저장되어 있으므로 해당 클러스터 정보를 담고 있는 런리스트 정보가 필요하다.
다음은 $MFT 파일의 MFT 엔트리 속성 중 Non-resident 속성인 $BITMAP 속성이다.
위의 Non-resident 속성 헤더 데이터 구조대로 해석해보면 다음과 같다.
$MFT 파일의 MFT 엔트리의 항목 중 $BITMAP은 뭘 의미하는 것일까? 이것은 $MFT 파일에 연속되어 있는 1,024 바이트의 MFT 엔트리 중 현재 사용 중인 엔트리("1")와 사용하지 않는 엔트리("0")를 비트맵으로 표현한 것이다. $MFT 의 전체 MFT 엔트리를 비트맵으로 표현하기 위해 45,064 바이트를 사용한 것이다. 0으로 표기된 MFT 엔트리를 모으면 모두 현재 사용되지 않는 삭제된 MFT 엔트리거나 아직 할당 대기 중인 엔트리이다.
그리고 런 리스트 끝 VCN이 "11"의 값을 가지는 것으로 보아 $BITMAP 속성 내용을 표현하기 위해 12개의 클러스터를 사용하고 있는 것을 알 수 있다. 현재 파티션의 클러스터 크기가 4,096 바이트이므로 12개의 클러스터 크기는 49152 바이트이다. 이 크기는 속성 내용 할당 크기와 일치하는 것을 알 수 있다.
꼭 기억해야 할 점은 속성 이름의 경우, 속성 이름이 존재하는 경우에만 해당 헤더 영역이 할당된다는 점이다. 속성 이름이 없는 경우에는 해당 영역을 제외하고 바로 속성 내용이 뒤따라온다. 그리고 이후에 다시 살펴보겠지만 초기화된(initialized) 크기의 의미는 잊지 않도록 하자.
속성 헤더 (Attribute Header)
이전에 MFT 엔트리 내의 속성에 대해 간략하게 살펴보았다. 이번에는 각 속성들에게 공통으로 존재하는 속성 헤더에 대해서 살펴보겠다. MFT 엔트리도 엔트리의 메타정보 표현을 위해 엔트리 헤더가 존재하는 것을 이미 살펴보았다. 이와 같이 각 속성에도 속성의 기본적인 메타정보를 표현하기 위해 속성 헤더를 사용한다.
 |
속성 헤더 이후에는 앞서 살펴본 여러 가지 속성들($STANDARD_INFORMATION, $FILE_NAME, $DATA 등)이 따라온다. 그럼 속성 헤더의 구조가 어떻게 되는지 살펴보자.
공통된 헤더
앞서 속성은 크게 Resident와 Non-resident 형식으로 나눠진다고 언급했다. 속성 헤더 역시 각 속성 형식마다 다른 헤더를 가진다. 하지만 앞의 16바이트 영역은 두 형식 모두 동일하다. 먼저, 두 형식 모두 공통된 헤더 항목을 살펴보자. 다음은 16바이트의 공통된 헤더의 데이터 구조이다.
| 범위(10진수) | 범위(16진수) | 설명 |
| 0 - 3 | 0x00 - 0x03 | 속성 타입 식별자 |
| 4 - 7 | 0x04 - 0x07 | 속성 길이 (N) |
| 8 - 8 | 0x08 - 0x08 | Non-resident 플래그 |
| 9 - 9 | 0x09 - 0x09 | 속성 이름 길이 |
| 10 - 11 | 0x0A - 0x0B | 속성 이름 시작 위치 |
| 12 - 13 | 0x0C - 0x0D | 상태 플래그 |
| 14 - 15 | 0x0E - 0x0F | 속성 식별자 |
- 속성 타입 식별자 : 각 속성 타입에 대한 고유한 식별자로 이전 설명을 참조
- 속성 길이 : 속성 헤더를 포함한 속성의 전체 길이
- Non-resident 플래그 : "1" 값을 가진다면, 해당 속성은 Non-resident 속성
- 속성 이름 길이 : 자신의 속성 이름 길이
- 속성 이름 시작 위치 : 속성 이름이 저장된 곳의 시작 위치
- 상태 플래그 : 속성의 상태 표현
- 0x0001 : 압축 속성
- 0x4000 : 암호화된 속성
- 0x8000: Sparse 속성
- 속성 식별자 : 속성의 고유한 식별자로 MFT 엔트리에 같은 속성이 여러 개일 때 서로 다른 값을 가짐
16 바이트의 공통된 헤더 이후에는 Resident 인지 Non-resident 인지에 따라 나머지 속성 헤더의 내용이 달라진다. 결국, Resident 인지 Non-resident 인지에 따라 속성 헤더의 길이도 달라지게 된다. 하지만 공통된 헤더 항목에 속성 길이 필드가 주어지므로 걱정할 필요 없다. 만약 원하는 속성을 찾고 싶다면 Fixup 배열 이후에 속성 길이만큼 이동하면서 속성 타입 식별자를 확인하여 원하는 속성을 찾으면 된다. 원하는 속성을 찾은 경우 필요한 작업을 수행하면 된다.
Resident 속성 헤더
Resident 속성일 경우, 속성 헤더의 데이터 구조는 다음과 같다.
| 범위(10진수) | 범위(16진수) | 설명 |
| 0 - 15 | 0x00 - 0x0F | 공통된 헤더 |
| 16 - 19 | 0x10 - 0x13 | 속성 내용 크기 |
| 20 - 21 | 0x14 - 0x15 | 속성 내용 시작 위치 |
| 22 - 22 | 0x16 - 0x16 | Indexed 플래그 |
| 23 - 23 | 0x17 - 0x17 | 사용되지 않음 |
| 24 - 24+2N | 0x18 - 0x18+2N | 속성 이름(유니코드) 단, 이름이 존재할 경우만 사용 |
| 24+2N+1 - | 0x18+2N+1 - | 속성 내용 |
- 속성 내용 크기 : 헤더 뒤에 오는 속성 내용의 크기
- 속성 내용 시작 위치 : 속성 내용이 시작하는 시작 위치
- Indexed 플래그 : "1" 값을 가진다면, Index 정보로 사용(검색에 사용됨, 보통 $FILE_NAME 속성은 "1"로 설정됨)
- 사용되지 않음 : 말 그래도 사용되지 않음
- 속성 이름 : 속성 이름이 있을 경우(속성 타입에 따라 이름이 없는 경우도 존재)에만 존재
다음은 $MFT 파일의 MFT 엔트리 속성 중 Resident 속성인 $FILE_NAME 속성이다.
 |
위의 Resident 속성 헤더 데이터 구조대로 해석해보면 다음과 같다.
- 공통된 헤더
- 속성 타입 식별자 : 0x00000030 (48) => $FILE_NAME
- 속성 길이 : 0x00000068 (104); 현재 하이라이트된 부분의 크기
- Non-resident 플래그 : 0x00
- 속성 이름 길이 : 0x00
- 속성 이름 시작 위치 : 0x0018 (속성 이름 길이가 0이므로 속성 이름은 존재하지 않음)
- 상태 플래그 : 0x0000
- 속성 식별자 : 0x0003
- Resident 헤더
- 속성 내용 크기 : 0x0000004A
- 속성 내용 시작 위치 : 0x0018 (속성 이름 시작 위치랑 동일; 속성 이름이 없기 때문)
- Indexed 플래그 : 0x01
- 속성 이름 : 존재하지 않음
Non-Resident 속성 헤더
Non-Resident 속성일 경우, 속성 헤더의 데이터 구조는 다음과 같다.
| 범위(10진수) | 범위(16진수) | 설명 |
| 0 - 15 | 0x00 - 0x0F | 공통된 헤더 |
| 16 - 23 | 0x10 - 0x17 | 런리스트 시작 VCN(Virtual Cluster Number) |
| 24 - 31 | 0x18 - 0x1F | 런리스트 끝 VCN |
| 32 - 33 | 0x20 - 0x21 | 런리스트 시작 위치 |
| 34 - 35 | 0x22 - 0x23 | 압축 단위 크기 |
| 36 - 39 | 0x24 - 0x27 | 사용되지 않음 |
| 40 - 47 | 0x28 - 0x2F | 속성 내용 할당 크기(클러스터 크기) |
| 48 - 55 | 0x30 - 0x37 | 속성 내용 실제 크기 |
| 56 - 63 | 0x38 - 0x3F | 속성 내용 초기화된 크기 |
| 64 - 64+2N | 0x40 - 0x40+2N | 속성 이름(유니코드) 단, 이름이 존재할 경우만 사용 |
| 64+2N+1 - | 0x40+2N+1 - | 속성 내용 |
Non-resident는 속성 내용이 외부 클러스터에 저장되어 있으므로 해당 클러스터 정보를 담고 있는 런리스트 정보가 필요하다.
- 런리스트 시작 VCN : 런리스트의 시작 VCN
- 런리스트의 끝 VCN : 런리스트의 끝 VCN
- VCN은 특정 파일의 첫 번째 클러스터부터 순차적으로 부여한 번호이다.
- $DATA 속성의 경우, 데이터가 매우 많이 조각이 난 경우 클러스터 런의 정보를 저장하기 위해 하나 이상의 MFT 엔트리를 사용하게 된다. 이때, 런리스트의 시작과 끝을 표현하기 위한 정보이다.
- 런리스트 시작 위치 : 런리스트의 시작 위치
- 압축 단위 크기 : 만약, 압축 속성일 경우 압축 단위 크기
- 속성 내용 할당 크기 : 속성 내용이 할당된 클러스터 크기(클러스터의 배수)
- 속성 내용 실제 크기 : 순수한 속성 내용만의 크기
- 속성 내용 초기화된(initialized) 크기
- 일반적으로 NTFS에 존재하는 초기화된 크기의 의미는 파일이 할당될 때, 파일이 더 커질것을 예상하고 추가적인 공간을 할당한 경우가 있을 수 있다. 이 경우 순수한 파일 데이터의 크기는 초기화된 크기이고, 추가적인 공간까지 포함한 크기가 논리적(logical) 크기이다. 대부분의 경우 초기화된 크기와 논리적 크기는 동일하다.
- 속성 이름 : 속성 이름이 있을 경우(속성타입에 따라 이름이 없는 경우도 존재)에만 존재
다음은 $MFT 파일의 MFT 엔트리 속성 중 Non-resident 속성인 $BITMAP 속성이다.
 |
위의 Non-resident 속성 헤더 데이터 구조대로 해석해보면 다음과 같다.
- 공통된 헤더
- 속성 타입 식별자 : 0x000000B0 (176) => $BITMAP
- 속성 길이 : 0x00000050 (80); 현재 하이라이트된 부분의 크기
- Non-resident 플래그 : 0x01
- 속성 이름 길이 : 0x00
- 속성 이름 시작 위치 : 0x0040 (속성 이름 길이가 0이므로 속성 이름은 존재하지 않음)
- 상태 플래그 : 0x0000
- 속성 식별자 : 0x0005
- Non-resident 헤더
- 런리스트 시작 VCN : 0x00000000 00000000
- 런리스트 끝 VCN : 0x00000000 0000000B (11)
- 런리스트 시작 위치 : 0x0040 (64)
- 압축 단위 크기 : 0x0000
- 속성 내용 할당 크기 : 0x00000000 0000C000 (49152)
- 속성 내용 실제 크기 : 0x00000000 0000B008 (45064)
- 속성 내용 초기화된 크기 : 0x00000000 0000B008 (45064)
- 속성 이름 : 존재하지 않음
$MFT 파일의 MFT 엔트리의 항목 중 $BITMAP은 뭘 의미하는 것일까? 이것은 $MFT 파일에 연속되어 있는 1,024 바이트의 MFT 엔트리 중 현재 사용 중인 엔트리("1")와 사용하지 않는 엔트리("0")를 비트맵으로 표현한 것이다. $MFT 의 전체 MFT 엔트리를 비트맵으로 표현하기 위해 45,064 바이트를 사용한 것이다. 0으로 표기된 MFT 엔트리를 모으면 모두 현재 사용되지 않는 삭제된 MFT 엔트리거나 아직 할당 대기 중인 엔트리이다.
그리고 런 리스트 끝 VCN이 "11"의 값을 가지는 것으로 보아 $BITMAP 속성 내용을 표현하기 위해 12개의 클러스터를 사용하고 있는 것을 알 수 있다. 현재 파티션의 클러스터 크기가 4,096 바이트이므로 12개의 클러스터 크기는 49152 바이트이다. 이 크기는 속성 내용 할당 크기와 일치하는 것을 알 수 있다.
꼭 기억해야 할 점은 속성 이름의 경우, 속성 이름이 존재하는 경우에만 해당 헤더 영역이 할당된다는 점이다. 속성 이름이 없는 경우에는 해당 영역을 제외하고 바로 속성 내용이 뒤따라온다. 그리고 이후에 다시 살펴보겠지만 초기화된(initialized) 크기의 의미는 잊지 않도록 하자.
'File Systems' 카테고리의 다른 글
| NTFS - 속성 헤더 (Attribute Header) (0) | 2010/09/06 |
|---|---|
| NTFS - 속성 (Attributes) (3) | 2010/09/02 |
| NTFS - MFT 엔트리 구조 (MFT Entry Structure) (0) | 2010/09/01 |
| NTFS - MFT 엔트리 소개 (MFT Entry Introduction) (0) | 2010/05/20 |
| 숨긴 볼륨/파티션 (Hidden Volumes/Partitions) (6) | 2010/04/24 |
| NTFS - MFT 소개 (MFT Introduction) (2) | 2010/04/09 |
댓글을 달아 주세요