이번 글에서는 마지막으로 남은 메타데이터 파일들을 알아보도록 하겠다.

[$LogFile]
해당 메타데이터는 MFT 엔트리 세 번째에 위치하며, NTFS 저널링에 사용된다. 속성은 표준 속성을 가지고 있고 로그 데이터를 내용으로 가지고 있는데 이 내용은 $DATA 속성에 포함되어 있다. 하지만 오프셋 구조는 아직 정확히 알려진 바가 없어 애매한 내용을 언급하면 혼란만 초래하므로 해당 메타데이터 파일 분석은 조금 더 정확한 분석이 되면 그때 언급 하도록 하겠다.


[$UsrJrnl]
해당 메타데이터 파일은 변경 저널링에 사용되며 파일에 변경이 발생하면 해당 메타데이터 파일에 관련 정보가 기록된다.
해당 파일도 $ObjId, $Quota 등의 파일과 마찬가지로 MFT 예약 엔트리에 있지 않고 $Extend 메타데이터 파일에 포함되어 있다. 해당 메타데이터 파일에는 두가지 $DATA 속성이 존재한다.

 - $J : $J라는 이름을 가지고 있는 $DATA 속성으로 이 속성은 sparse 속성이며, 다른 크기로 된 데이터 구조체 목록을 포함하고 있다. 
 - $Max : $Max라는 이름을 가지고 있는 $DATA 속성으로 이 속성은 사용자 저널링 최대 설정의 대한 정보가 포함하고 있다.

 * 참고 : $J는 변경 저널 엔트리라고 부른다.


해당 파일은 응용 프로그램 참조 모델에 속하는 파일이다 보니 해당 파일들의 데이터는 비 필수 데이터들이다.

 * 참고 : 본래 저널링 기술은 기본 설정이 비 활성화인데 필자가 가지고 있는 NTFS image 모두 저널링 기술이 활성화 되어 있지 않아 해당 메타데이터 파일이 없다. 이러한 이유로 오프셋 구조는 표로 대체한다.
 

[그림 1 - $J 속성의 오프셋]


 - 변경 유형 플래그 : 해당 오프셋의 값은 변경 저널 엔트리 생성 이유를 의미하기도 한다. 아래 목록의 플래그 값들이 하나 이상 설정 될 수 있다.
 

[그림 2 - 변경 유형 플래그 목록]


아래는 $Max 속성의 오프셋 구조이다.

[그림 3 - $Max 속성의 오프셋]


오프셋 구조를 보면 포렌식적 의미를 가진 정보는 없는 것을 볼 수 있다.


위 설명을 끝으로 NTFS의 분석이 끝이 났다. NTFS는 여러가지 기능과 복합적인 구조로 인해 분석이 어려운편에 속하는 파일시스템이다. 또 아직까지 알려지지 않은 데이터 구조체 필드로 인해 또 어떠한 포렌식적 의미의 정보가 있는지 알 수 없다.



'[+] Forensic' 카테고리의 다른 글

File System - Ext (2)  (0) 2012.02.20
File System - Ext (1)  (0) 2012.02.20
File System - NTFS (20)  (0) 2012.02.19
File System - NTFS (19)  (0) 2012.02.19
File System - NTFS (18)  (0) 2012.02.18
이번 글에서는 NTFS의 메타데이터 파일 중 $Volume, $ObjId, $Quota 파일에 대해서 알아 볼 것이다.

[$Volume]
해당 메타데이터 파일은 두 개의 속성으로 이루어져 있으며 이 속성을 중점적으로 해당 메타데이터 파일을 분석 할 것이다.
해당 메타데이터 파일은 MFT 엔트리 네 번째에 위치하고 있다. 가지고 있는 속성으로는 $VOLUME_NAME과 $VOLUME_INFORMATION이 있다.

[$VOLUME_NAME]
해당 속성은 $VOLUME 파일이 할당 되었을 경우만 사용되는 속성이며, 타입 식별자는 96이고 파일 내용으로는 파일시스템의 볼륨 이름을 저장하고 있다.

[그림 1 - $VOLUME_NAME 속성의 내용]

 

[$VOLUME_INFORMATION]
해당 속성은 $VOLUME 파일의 두 번째 속성이며 내용으로는 파일시스템 버전을 포함한다. 타입 식별자는 112이다.
오프셋 구조는 아주 간단하고 그 구조는 아래와 같다.

[그림 2 - $VOLUME_INFORMATION 속성의 오프셋]

 - 플래그 : 해당 오프셋에 저장 될 수 있는 값의 목록은 다음과 같다.

[그림 3 - 플래그 값 목록]

 

 

[$ObjId]
NTFS에서는 다른 파일시스템과 달리 파일이름 말고도 오브젝트 ID를 사용하여 파일을 구별 할 수 있다고 앞 글에서 언급한 적이 있었다. 어떠한 파일을 포함하는 인덱스는 $INDEX_ROOT 속성과 $INDEX_ALLOCATION 속성을 일반적으로 가지며, 파일을 직접적으로 포함하고 있는 인덱스 엔트리는 특정 데이터 구조체를 가지고 있다. 그 구조는 아래와 같다.

 * 참고 : $ObjId 메타데이터 파일은 MFT 엔트리에서 특정 위치에 존재하지 않고 $Extend 메타데이터 파일안에 포함되어 있다.

[그림 4 - $ObjId 파일의 오프셋]

 - 플래그 : 여기에 들어갈 플래그 목록은 아래와 같다.
                1) 0x01 : 자식 노드가 존재한다.
                2) 0x02 : 목록에서 마지막 엔트리이다. 


[$Quota]
해당 메타데이터 파일은 $INDEX_ROOT와 $INDEX_ALLOCATION 속성을 일반적으로 사용하며, 두 개의 인덱스를 가지고 있다.

 - $O 인덱스 : 하나의 SID와 소유자 ID를 연결시키는 역할을 한다.
 - $Q 인덱스 : 할당 정보에 자신의 ID를 연결시키는 역할을 한다.


 * 참고 : $Quota 파일 또한 MFT 엔트리 내의 존재하는게 아닌 $Extend 파일안에 포함되어 있다.

아래는 $O 인덱스의 오프셋 구조이다.
 

[그림 5 - $O 인덱스의 오프셋]

 - 소유자 ID 오프셋 : 해당 오프셋의 값은 $O 인덱스 시작으로부터 상대적이다.

 - 플래그 : 여기에 들어갈 플래그 목록은 아래와 같다.
                1) 0x01 : 자식 노드가 존재한다.

                2) 0x02 : 목록에서 마지막 엔트리이다. 

 - SID : 해당 오프셋의 범위는 16 바이트 오프셋부터 16 + SID 크기 오프셋 - 1 만큼이다.

 - 소유자 ID : 해당 오프셋은 소유자 ID 오프셋을 참조하고 해당 바이트 오프셋부터 소유자 ID 길이 만큼까지가 범위이다.


아래는 $Q 인덱스의 오프셋 구조이다.

[그림 6 - $Q 인덱스의 오프셋]

 - 소유자 ID 크기 : 해당 오프셋의 값은 언제나 "0x0004" 이다.

 - 플래그 : 
여기에 들어갈 플래그 목록은 아래와 같다.
                1) 0x01 : 자식 노드가 존재한다.

                2) 0x02 : 목록에서 마지막 엔트리이다. 


 - 할당 플래그 : 플래그 목록은 아래와 같다.


[그림 7 - 플래그 목록]


'[+] Forensic' 카테고리의 다른 글

File System - Ext (1)  (0) 2012.02.20
File System - NTFS (20)  (0) 2012.02.19
File System - NTFS (19)  (0) 2012.02.19
File System - NTFS (18)  (0) 2012.02.18
File System - NTFS (17)  (0) 2012.02.17
이번 글부터는 NTFS의 메타데이터 파일들을 분석 할 것이다.

[$MFT]
해당 메타데이터 파일은 앞 글에서도 여러번 언급하였기 때문에 해당 메타데이터 파일의 일반적인 속성은 분석하지 않고 고유 속성인 $BITMAP 속성만 분석하여 볼 것이다.
$BITMAP 속성은 NTFS의 MFT 엔트리 할당 상태를 관리하는 속성으로 각 비트가 MFT 엔트리와 맵핑되어 MFT 엔트리가 할당되면 해당 MFT 엔트리와 맵핑 관계인 비트가 1로 설정된다.

 [그림 1 - $MFT 파일의 $BITMAP 속성 오프셋]

위 이미지를 보면 F로 설정된 오프셋과 0으로 설정된 오프셋이 있는데 F로 설정된 오프셋이 할당 상태를 뜻하고 0으로 설정된 오프셋이 비 할당 상태를 뜻한다.
MFT 엔트리 맵핑 관계는 각 오프셋을 비트로 변환하면 알 수 있다.현재 위 이미지의 MFT 엔트리 할당 상태는 다음과 같다.

 - 0 오프셋(FF) : FF -> 1111 1111(MFT 엔트리 0~7 할당)
 
- 1 오프셋(FF) : FF -> 1111 1111(MFT 엔트리 8~15 할당)

 - 2 오프셋(00) : 00 -> 0000 0000(MFT 엔트리 16~23 비 할당) 
 - 3 오프셋(FF) : FF -> 1111 1111(MFT 엔트리 24~31 할당)
 - 4 오프셋(7B) : 7B -> 0111 1011(MFT 엔트리 32~33 할당, 34비 할당, 35~38 할당, 39 비 할당)
 - 5 오프셋(00) : 00 -> 0000 0000(MFT 엔트리 40~47 비 할당)
 - 6 오프셋(00) : 00 -> 0000 0000(MFT 엔트리 48~55 비 할당)
 - 7 오프셋(00) : 00 -> 0000 0000(MFT 엔트리 56~63 비 할당) 

 

[$Boot]
해당 메타데이터 파일은 MFT 엔트리 여덟 번째에 위치하며, 부트 섹터와 부트코드를 포함한다. 부트 섹터는 항상 섹터0에서 시작하며, 부트섹터를 제외한 섹터들은 부트코드를 위하여 사용된다. 부트섹터에서 관심있게 봐야 할 부분들은 섹터와 클러스터의 크기를 정의하는 부분이다. 이 부분이 없다면 어떠한 것도 위치를 파악 할 수 없다. 그 다음으로 중요하게 봐야 할 부분은 MFT 엔트리의 크기를 정의하는 부분이다. 보통은 1024byte 이지만 이 값은 언제든지 수정 될 수 있기 때문이다.

 * 참고 : MFT 엔트리와 인덱스 레코드를 의미하는 필드들은 모두 특별한 형식을 가지고 있다. 만약 MFT 엔트리나 인덱스 레코드를 의미하는 필드들의 값이 0보다 크면 각 데이터 구조체에서 사용하는 클러스터 수를 값으로 가지게 된다. 또 0보다 작다면 각 데이터 구조체에 있는 바이트 수 밑이 2인 로그 값을 저장한다. 이러한 현상은 클러스터 크기가 단일 MFT 엔트리나 인덱스 레코드보다 클 경우 일어난다.

아래는 부트 섹터의 오프셋 구조이다.

 [그림 2 - $Boot 파일의 오프셋]

 * 참고 : 반드시 0이라고 표시 해 둔 필드는 반드시 0 값이 아니면 안되는 필드이기 때문이다. XP의 경우 해당 필드들이 0이 아닐 경우 파일시스템이 마운트 되지 않는다.

 위 이미지에서 MFT 엔트리 크기 필드를 보면 "0x02" 값이 저장되어 있다. 이럴 경우 0보다 크므로 클러스터 수를 뜻하게 된다. 클러스터의 크기는 섹터 별 바이트 수(0x0200, 512byte) * 클러스터 별 섹터 수(0x01)을 계산하면 512byte로 계산되어 512byte 인 것을 알 수 있다. 해당 필드는 MFT 엔트리의 크기 값이 클러스터 2개의 값이라는 의미를 뜻하게 되어 결과적으로 크기는 1024byte가 된다.


[$AttrDef]
해당 메타데이터 파일은 MFT 엔트리 다섯 번째에 위치하며, 파일시스템 속성들의 이름과 식별자를 정의한다.
아래는 해당 메타데이터 파일의 오프셋이다.

[그림 3 - $AttrDef 파일의 오프셋]

 - 플래그 : 아래의 값들을 가진다.
    1) 0x02 : 인덱스에서 속성이 사용된다.
    2) 0x40 : 항상 거주 속성이다.
    3) 0x80 : 비거주 속성이다.


[$BITMAP]
해당 메타데이터 파일은 클러스터 할당 상태를 관리하는 파일이다. 해당 비트맵의 내용은 $DATA 속성에 저장된다.
각 비트별로 클러스터와 맵핑되어 있는데 어떠한 클러스터의 할당 상태를 알고자 할 때 해당 메타데이터 파일해당 클러스터의 비트를 찾아야 한다. 하지만 무작정 찾기에는 너무 시간이 오래 걸린다. 이러한 시간 낭비를 줄이기 위해 아래와 같은 공식을 적용한다.

 - $BITMAP 내의 바이트 오프셋 = 클러스터 번호 / 8 
 - $BITMAP 내의 클러스터 비트 오프셋 = 클러스터 번호 - 8 * $BITMAP 내의 바이트 오프셋 


한가지 예를 들어 클러스터 7과 80을 찾는다고 가정한 후 위 공식을 적용하면 아래와 같이 찾을 수 있다.

[그림 4 - $BITMAP 파일 내에서 원하는 클러스터의 비트 찾는 방법]



'[+] Forensic' 카테고리의 다른 글

File System - NTFS (20)  (0) 2012.02.19
File System - NTFS (19)  (0) 2012.02.19
File System - NTFS (18)  (0) 2012.02.18
File System - NTFS (17)  (0) 2012.02.17
File System - NTFS (16)  (0) 2012.02.16
이번 글에서는 간단히 인덱스 엔트리에 대해서 알아 볼 것이다.

[표준 인덱스 엔트리]
표준 인덱스 엔트리는 따로 설명 할 것이 없다. 말 그대로 인덱스 엔트리의 표준 레이아웃을 가진 인덱스 엔트리이며, 어떠한 내용도 가질 수 있는 엔트리이다. 아래는 인덱스 엔트리의 오프셋 구조이다.

[그림 1 - 표준 인덱스 엔트리 오프셋]

 - 플래그 : 플래그 오프셋에 올 수 있는 값은 두가지로 위 이미지에 있는 값은 쓰레기 값이다.
                1) 0x01 : 자식 노드가 존재한다.
                2) 0x02 : 인덱스 엔트리 목록에서 마지막 엔트리


 * 참고 : 엔트리 마지막 8바이트는 $INDEX_ALLOCATION에 있는 자식 노드의 VCN 값을 가지고 있는데, 위 이미지는 $INDEX_ROOT 속성의 인덱스 엔트리이다. 또 VCN 값이 저장되기 위해서는 플래그의 값이 "0x01" 이어야만 한다. 


[디렉토리 인덱스 엔트리]
파일 이름을 사용하는 디렉토리 인덱스는 자신만의 데이터 구조체를 가지고 있다. 아래는 이것의 오프셋 구조이다. 

 [그림 2 - 디렉토리 인덱스 엔트리 오프셋]

 - 파일 이름 MFT 엔트리 번호 : 위 이미지에서는 MFT 엔트리 25번을 참조하고 있다.

 - 플래그 : 표준 인덱스 엔트리의 플래그와 동일하다.

 * 참고 : 엔트리 마지막 8바이트는 $INDEX_ALLOCATION에 있는 자식 노드의 VCN 값을 가지고 있는데, 위 이미지는 $INDEX_ROOT 속성의 인덱스 엔트리이다. 또 VCN 값이 저장되기 위해서는 플래그의 값이 "0x01" 이어야만 한다. 

'[+] Forensic' 카테고리의 다른 글

File System - NTFS (19)  (0) 2012.02.19
File System - NTFS (18)  (0) 2012.02.18
File System - NTFS (17)  (0) 2012.02.17
File System - NTFS (16)  (0) 2012.02.16
File System - NTFS (15)  (0) 2012.02.16
이전글에서는 모든 파일에 할당 되는 속성을 알아봤다면 이번 글부터는 인덱스 속성의 데이터 구조체를 알아 볼 것이다.

[$INDEX_ROOT]
해당 속성은 타입 식별자 144를 가지며, 항상 거주 속성이다. 해당 속성은 항상 인덱스 트리의 루트이며, 오직 인덱스 엔트리들의 작은 목록만 포함한다. 해당 속성의 레이아웃은 아래와 같다.

 [그림 1 - $INDEX_ROOT 속성의 레이아웃]

$INDEX_ROOT 속성 헤더는 16바이트의 크기를 가지며, 노드헤더 또한 16바이트의 크기를 가진다. 

 * 참고 : 노드헤더는 $INDEX_ROOT와 $INDEX_ALLOCATION에 모두 동일하게 적용되므로 두 속성을 분석한 후 따로 분석 할 것이다.

아래는 $INDEX_ROOT 속성 헤더 오프셋이다.

 [그림 2 - $INDEX_ROOT 속성 헤더 오프셋]

 - 인덱스 내의 속성 타입 : 인덱스에 포함되어 있는 엔트리의 속성 타입을 포함하는 오프셋인데, 엔트리가 속성을 사용하지 않는 경우 0으로 설정된다.

 - 수집 정렬 규칙 : $INDEX_ALLOCATION 속성에서 정렬되는 규칙이다.

 - 인덱스 레코드 크기(byte) : 인덱스 레코드의 바이트 크기를 포함하는 오프셋이다.

 - 인덱스 레코드 크기(클러스터) : 인덱스 레코드 크기만큼 필요한 클러스터 수

 * 참고 : $INDEX_ROOT 속성 헤더 바로 다음 바이트부터 노드헤더가 시작된다. 

 

[$INDEX_ALLOCATION]
큰 디렉토리일 경우 인덱스 엔트리가 $INDEX_ROOT 속성에 적합하지 않는다. 이러한 경우 비 거주 속성인 해당 속성이 사용된다. 해당 속성의 내용은 인덱스 레코드로 이루어져 있는데, 인덱스 레코드의 크기는 고정이며, 정렬된 트리의 노드 하나를 포함하고 있다. 인덱스 레코드의 크기는 $INDEX_ROOT 속성 헤더에 정의되어 있으며, 보통 4096byte 이다.
해당 속성의 타입 식별자는 160이며 해당 속성의 내용인 인덱스 레코드는 특별한 헤더 데이터 구조체로 시작한다. 헤더 다음으로 노드 헤더와 인덱스 엔트리의 목록이 온다.
아래는 해당 속성의 레이아웃이다.

 [그림 3 - $INDEX_ALLOCATION 속성의 레이아웃]

 아래는 인덱스 레코드 헤더의 오프셋이다.

 [그림 4 - 인덱스 레코드 헤더의 오프셋]

 - 시그니처 : 인덱스 레코드에는 시그니처가 존재하며 시그니처는 "INDX" 이다.

 - Fixup 배열 오프셋 : 해당 오프셋의 값은 Fixup 배열의 오프셋 주소로 인덱스 레코드 헤더 시작부분에서 상대적이다. 


 * 참고 : 인덱스 레코드 헤더 바로 다음 바이트부터 노드헤더가 시작된다. 


[$BITMAP]
해당 속성은 인덱스 레코드의 할당 상태를 관리하는 속성이다. 모든 인덱스 레코드가 할당 되는 것은 아니며 운영체제 판단에 의해 필요시 할당 된다.

 * 참고 : $BITMAP 속성은 MFT 엔트리 할당 추적을 위해 $MFT에 의해서 사용 된다.

해당 속성은 타입 식별자 176을 가지며 각 바이트를 비트로 변환하여 인덱스 레코드와 맵핑한다.

[그림 5 - $BITMAP 속성의 오프셋]

위 이미지를 분석하여 보면 첫 바이트가 0x01인데 비트로 변환 시 0000 0001 이다. 이건 인덱스 레코드 0이 할당되었다는 것을 의미한다.
만약 0x02 바이트이어서 0000 0010 이라면 인덱스 레코드 1에 할당 되었다는 것을 의미한다. 


[인덱스 노드 헤더 데이터 구조체]
앞서 말한 노드헤더를 여기서 분석하여 볼 것이다. 노드 헤더는 각 속성의 헤더가 끝나고 바로 다음 바이트부터 시작이 되는데 그 크기는 16byte 이다.

 [그림 6 - 노드헤더 오프셋]

 - 인덱스 엔트리 목록의 시작 오프셋 : 해당 값은 노드 헤더 시작에서 상대적이다.

 - 인덱스 엔트리 목록의 마지막 오프셋 : 해당 값은 노드 헤더 시작에서 상대적이다.

 - 플래그 : 플래그는 설정되지 않거나 0x01로 설정되는 경우 밖에 없으며, 0x01로 설정되는 경우 인덱스 엔트리 목록에 있는 엔트리에 의해 지정된 자식 노드가 있다는 것을 의미한다. 



 

'[+] Forensic' 카테고리의 다른 글

File System - NTFS (18)  (0) 2012.02.18
File System - NTFS (17)  (0) 2012.02.17
File System - NTFS (16)  (0) 2012.02.16
File System - NTFS (15)  (0) 2012.02.16
File System - NTFS (14)  (0) 2012.02.15

+ Recent posts