4-3.5) MFT Entry 찾기(인덱스2, $ATTRIBUTE_LIST)

아래 실습은 NTFS 가상디스크를 만들어서 분석하였습니다.

실습을 직접 따라 해보고 싶으신 경우 NTFS 분석 처음부터 따라오시는 것을 추천 드립니다. > 4-3) NTFS 기초 분석

2-10) 폴더에서 MFT Entry Number를 찾아보자.

1. 우선은 루트 디렉토리에서만 접근하는 것을 확인하였습니다. 이제 하위 디렉토리의 접근도 살펴봅시다. Directory 를 만들고 해당 디렉토리에 파일도 소수로 만들어 봅시다. 위에 공부한 대로라면 파일 개수가 몇 개 안되서 Directory 1의 MFT Entry 에 Index node를 가리키는게 resident로 있을 수 있을거 같은데 맞을지 살펴보도록 합시다.

   

2. 분석용 프로그램을 새로 재기동 한 뒤 루트디렉토리의 $INDEX_ALLOCATION의 DATA runlist인 36번 클러스터로 가봅시다. 128 + 36 X 8 = 416 / 416 섹터로 가봅시다. INDEX_ALLOCATION을 살펴보다보면 우리가 폴더명으로 했던 Directory 1을 볼 수 있습니다. Directory 1의 Index Node Header를 보면 해당 파일의MFT Entry number을 확인할 수 있습니다. 참고로 $FILE_NAME 속성을 보면 부모 디렉토리 MFT Entry Number를 확인 할 수 있는데 루트디렉토리인 5번 MFT Entry Number를 저장하고 있는것을 확인할 수 있습니다.

   

   다시 Index Node Header 구조를 되새겨봅시다.

   

   - MFT Entry Number (=File Reference Address for File name) > 38 00 00 00 00 00 (MFT Entry 넘버) / 01 00 (시퀀스 넘버) -> 38 (16진수) => 56 56번 MFT Entry 가 Directory 1의 MFT Entry Number입니다.

3. $MFT 에서 56번 엔트리로 가봅시다. 이번엔 섹터로 이동해봅시다. $MFT 파일 시작 섹터 + MFT Entry Number X 2 (MFT Entry 크기 1,024 = 2섹터) > 128 + 68,264 + (56 X 2) = 68,504 섹터 Active Disk Editor에는 NTFS MFT Entry를 보기 쉽게 NTFS MFT File Record 템플릿으로 설정해서 해당 내용을 분석해볼 수 있습니다. 그런데 여기 MFT Entry를 살펴보면 $INDEX_ALLOCATION이 없고 $INDEX_ROOT 속성만 있고, 우리가 폴더내 저장한 파일들의 Index node Entry를 바로 확인할 수 있습니다.

   
4. 속성을 다시 살펴보도록 합시다. 다 잊어버렸을 수 있으니 중요한것만 다시 살펴봅시다.

   

   속성 구조 Hedaer

   

   Index Header

   

   Index Node Header

   위 헤더+ Index Node Entries가 모두 연결되어 있는 상태입니다. 우선 이 속성은 Resident 속성인 것을 알 수 있습니다.

   
5. Index Node Entry를 살펴봅시다.

   

   Index Node Entry

   

   [abcdefghijklmnopqrstuvxyz.txt] - MFT Entry Number (File Reference Address) : 3B 00 00 00 00 00 (59) -> 59번 - $NAME 속성의 부모 디렉토리 MFT Entry Number : 38 00 00 00 00 00 (56) -> 56번 [test.txt] - MFT Entry Number (File Reference Address) : 3A 00 00 00 00 00 (58) -> 58번 - $NAME 속성의 부모 디렉토리 MFT Entry Number : 38 00 00 00 00 00 (56) -> 56번 *Directory 1의 MFT Entry 가 56번 입니다.

6. 음 그렇다면 파일이 많아지면 56 MFT Entry가 가득 차겠죠? 파일명이 늘어나고, 파일명이 길어져 MFT Entry의 $INDEX_ROOT의 용량이 모자르게 된다면 이미 보았던 $INDEX_ALLOCATION 이 생기게 될 것입니다. 한번 살펴볼까요? > e: (NTFS 가상 디스크가 논리드라이브 명) > cd "Directory 1" > for /l %i in (1,1,50) do echo This is file %i > file%i.txt *file1.txt ~ file50.txt 만들기

   

   

7. 분석 도구를 재시작 한 뒤 Directory 1의 MFT Entry(56번)를 다시 살펴 봅시다. > 128 + 68,264 + (56 X 2) = 68,504 섹터 전반적으로 살펴보면 여러가지 흔적들을 발견할 수 있습니다. 파일이 생성되는 과정에 해당 MFT Entry가 쓰였던 것을 발견할 수는 있으나 일단 우리는 저장된 INDEX_ROOT 부분을 다시 살펴봅시다. 실제 $INDEX_ROOT의 마지막 범위를 정확히 파악해봅시다. 그 뒤에는 새로 생긴 $INDEX_ALLOCATION 속성이 시작 됩니다.

   

8. Attirbute A0 ($INDEX_ALLOCATION)속성을 살펴봅시다. 중요한 것만 빠르게 체크해봅시다.

   

   Non-Residetn Attribtue Header

   

   - Non-Resident : 01 -> Non-Resident 속성 - Data Run Offset : 48 -> 72 / Attribute Header에서 72 byte 뒤에 Data Runlist 위치 - Run list : 21 02 92 09 -> 클러스터 수 : 02 / 시작 클러스터 위치 : 92 09 -> 09 92 (16진수) =>2,450 > 2,450 클러스터에 Index Allocation 위치

9. 2,450 클러스터로 가봅시다. 시작 파티션 + 클러스터 번호 X 클러스터 당 섹터 수 = 클러스터 위치 128 + 2,450 X 8 = 19,728 섹터 루트 디렉토리의 $INDEX_ALLOCATOIN($I30)과 동일한 구조로 Index Record Header + Index Node Header + Index Entry + Index Entry ... 구조가 이어지고 있습니다.

   

   FTK Imager에서도I30이 생겼네요!

   

$INDEX_ROOT와 $INDEX_ALLOCATION을 통한 검색 관련, 대량 파일 생성[참고]

• 이건 친해지기 시리즈에서는 참고로만 알아두도록 합시다!

  Directory 1의 MFT Entry (56번) 속성 중 INDEX_ROOT를 다시 살펴 봅시다. > 128 + 68,264 + (56 X 2) = 68,504 섹터

  

  

  - 인덱스 속성 타입 : 30 ($FILE_NAME) - Collation rule : 01 / 01 => 파일이름 대소문자 구분없이로 정렬 - 인덱스 할당 크기 : 00 10 00 00 -> 00 00 10 00 (16진수) => 4,096 (10진수) 이어서 Index Node Header 가 이어집니다.

  

  

  - Off set to First Index Entry : 10 00 00 00 -> 00 00 00 00 10 (16진수) => 16 (10진수) > Index node 기준 16 bytes 뒤에 Index Entry 시작 - Total Size of The Index Entries : 98 00 00 00 -> 00 00 00 98 (16진수) => 152 (10진수) > Index Node Header 부터 152 bytes까지 Index Node 크기 이어서 Index Node Entry 입니다.

  

  

  - File Reference Address for File name : 5E 00 00 00 00 00 02 00 > MFT Number : 5E 00 00 00 00 00 00 ->00 ~~ 5E => 94 MFT Entry 넘버 > Sequence Number : 02 00 - Length of this Index Entry : 70 00 -> 00 70 => 112 bytes - Length of $FILE_NAME : 56 00 -> 00 56 => 86 bytes $FILE_NAME 부분은 중요한것만 바로 봅시다. - Parent Directory MFT Entry number : 38 00 00 00 00 00 -> 00 ~ 38 => 56 번 MfT Entry - FILE NAME : file25.txt (환경마다 파일명이 다를 수 있다.) $INDEX ROOT에는 file25.txt(MFT Entry 94번)를 가리키고 있습니다. 그렇다면, $INDEX ALLOCATION의 FILE25.TXT는 어떻게 되어 있을까? $INDEX_ALLOCATION의 데이터 Runlist에서 클러스터 번호가 2,450로 가보도록 합시다. 128 + 2,450 X 8 = 19,728 섹터 해당 Index Entries 를 살펴보면서, file25.txt를 찾아봅시다. 그런데 이상한게 발견됩니다. file25.txt 의 MFT Entry Number를 나타내는 부분이 비어 있습니다.

  

  여기서 추가로 테스트를 하나 더 해보도록 하겠습니다. file51~file80.txt를 추가로 생성 해보도록 하겠습니다. > for /l %i in (51,1,80) do echo This is file %i > file%i.txt

  

  Directory 1의 MFT Entry (56번) 속성 중 INDEX_ROOT를 다시 살펴 봅시다. > 128 + 68,264 + (56 X 2) = 68,504 섹터 Index Node Header 를 보면 - Total Size of The Index Entries 가 152 (10진수) 에서 376으로 늘어나있고 Index Node Entry 가 2개 더 늘어났습니다. file43.txt, file 61.txt

  

  $INDEX_ALLOCATION의 데이터 Runlist에서 클러스터 번호가 2,450로 가보도록 합시다. 128 + 2,450 X 8 = 19,728 섹터 여기서 file43.txt, file61.txt 도 동일한 증상을 보입니다.

  

  왜이러는 걸까요? NTFS에서는 파일검색을 빠르게 하기 위해 약간은 변형된 B(Binary)-Tree구조를 사용합니다. (예)간단하게 Index_Root에 있는 파일들의 파일명으로 정렬하였을 때 file25보다 작은거, file25-43사이, file43-61사이, file61보다 큰거 순으로 검색하여 검색을 보다 빠르게 하기 위함입니다. 사실 정확하게 file1~file100을 정렬하였을 때 우리가 이해하기 쉽게 숫자로 썻지만 문자형식에 따라 정렬상태가 조금은 다를 수는 있으나 대략적으로 이런 원리로 구성되게 됩니다.

  

  음 그렇다면 $INDEX_ROOT가 넘치도록 엄청나게 많은 파일을 생성해보겠습니다.

  

  오잉 갑자기 file25, file43, fil61이 사라졋군요. Index Node Entry를 다시 살펴보겠습니다.

  

  Index Node

  

  - MFT Entry Number : 00 00 00 00 00 00 00 00 - Length of this Index Entry : 40 bytes (Index Node Header 부터 치면 없습니다.) - Leng of $FILE_NAME : 00 00 - Flag : 03 00 00 00 >> 01 (하위노드 있음) + 02 (인덱스 레코드 끝) = 03 (하위노드 있으면서 인덱스 끝) 결론은 모두 사라졌습니다. 그렇다면 다시 확인 해봐야겠네요 $INDEX_ALLOCATION의 데이터 Runlist에서 클러스터 번호가 2,450로 가보도록 합시다. 128 + 2,450 X 8 = 19,728 섹터 *아쉽게도 Acitve Disk Eidtor의 경우 아쉽게도 $I30 내 문자 검색이 어려워서 FTK Imager에서 검색해보도록 하겠습니다. [Directory 1 폴더내에 있는 $I30 파일 선택 후 검색기능을 사용해 보겠습니다.]

  

  file25.txt, file43.txt, file61.txt 를 찾아보면 위에서 $ROOT_INDEX에서만 보이던 MFT_ENTRY 넘버가 이제는 보이기 시작하네요!

  

  그리고.. 전반적으로 원래는 초반에 test.txt가 있었는데 file1~로 시작하는게 다시 정렬되었네요

  

2-11) Attribute_list 속성

• MFT Entry의 속성이 너무 많아지면 MFT Entry 안에 다 담을 수 없기에 여러개의 MFT Entry 를 나눠 저장합니다. 이때 $ATTRIBUTE_LIST 속성 내에 MFT Entry 를 담게 됩니다. $ATTRIBUTE_LIST Type ID : 20

1. 여러 파일들을 저장한 경우 루트디렉토리에 이렇게 Attribute_list가 설정되어 있을 수 있습니다. 루트 디렉토리,바로 하위 디렉토리에 많은 파일을 생성하면 루트디렉토리는 Attribute_list 속성을 갖게 됩니다. (아래 실습 화면은 Directory1의 폴더에 약 300개의 파일을 생성 후 진행하였습니다.) 먼저 루트디렉토리 5번 MFT Entry 로 이동해봅시다. ($MFT) 68,392 섹터에서 5 X 1,024 = 5,120 오프셋 이동

2. $ATTRIBUTE_LIST 속성은 기본적으로 아래의 특성을 갖습니다. - $STANDARD_INFORMATION 시작하며, 자동적으로 base MFT Entry에 존재하게 된다. - $ATTRIBUTE_LIST 속성은 반드시 base MFT Entry에 위치해야 한다. - $ATTRIBUTE_LIST 속성은 크기가 가변적이며 Resident 형식과 non-Resident 형식 모두 가능 - Non-Resident 형식이라면 속성의 Run List의 크기가 base MFT Entry를 넘어서는 안된다. - $ATTRIBUTE_LIST 이후 $FILE_NAME 속성이 위치한다.

   

3. 속성 헤더를 한번 살펴보면,

   

   

   - Attribute Type ID : 20 00 00 00 -> 00 00 00 20 - Non-Resident : 00 으로 Resident 속성을 가집니다.

4. $ATTRIBUTE_LIST 구조를 살펴봅시다.

   

   $ATTRIBUTE_LIST 구조

   

   - Attribute Type ID : 10 00 00 00 -> 00 00 00 10 -> $STANDARD_INFORMATION ($10) - Entry Size : 20 00 -> 00 20 (16진수) => 32 bytes - 이름 길이 : 00 - 이름 위치 : 1A => 26 오프셋 - 속성 시작 VCN : 00 00 00 00 00 00 00 00 - 속성이 위치한 File MFT Entry Address : 05 00 00 00 00 00 / 05 00 -> MFT Entry number : 5 / Sequence Number : 5 => 루트 디렉토리의 MFT Entry Number - 속성 ID : 00 00

   속성이 위치한 MFT Entry Address를 보면 자기 자신인 5번 MFT Entry 를 가리키고 있네요!

5. 루트 디렉토리니까 폴더 내 파일 목록을 확인하기 위해 Index Root($90), Index Allocation($A0)의 Attribute_list Record를 살펴봅시다.

   

   - 속성이 위치한 File MFT Entry Address : 70 00 00 00 00 00 / 01 00 > 00 00 00 00 00 70 -> 112 MFT Entry Number 즉, 112번 MFT Entry 에 속성들이 있는지 살펴보도록 합시다.

6. $MFT 파일에서 112번 MFT Entry 로 이동해봅시다. 68,392($MFT) 섹터에서 112 X 1,024 = 114,688 오프셋 이동

   

   - File Reference to Base MFT Entry : 05 00 00 00 00 00 / 05 00 => 5번 MFT Entry > 부모 MFT Entry 번호를 표시해주는 것을 알 수 있습니다!

7. $INDEX_ALLOCATION($A0)의 속성을 살펴보면 Non-Resident 루트 디렉토리의 파일 Index가 있는 INDEX_ALLOCATION 데이터 영역이 몇 번 클러스터인지 살펴보면 36번 클러스터에 해당 합니다.

   
8. 36번 클러스터에 가서 확인을 해봅시다. 128 (파티션 시작 위치 ) + 36 X 8 (클러스터 당 섹터 수) = 416 섹터 확인 되네요!

   

   즉, 이러한 방식으로 Attribute_list 를 통해 다른 MFT Entry로 확장하여 사용하고 있습니다.