NTFS 분석 - 파일이름 범주

12.4 파일이름 범주

- 파일이름 범주는 파일이름과 내용을 연결하는데 사용되는 데이터를 포함한다. 이제까지 NFTS의 저장밥법과 어떤 메타데이터가 저장되는지 알아보았다. 이 절에서는 파일 이름이 어떻게 연결되어 있는지 자세히 알아보자. NTFS는 인덱스를 사용해 디렉토리를 구성한다. 트리는 한개 이상의 노드를 포함하고 노드는 $INDEX_ROOT와 $INDEX_ALLOCATION 속성에 저장이 된다. $INDEX_ROOT 속성은 항상 트리의 루트이고 $INDEX_ALLOCATION은 다른 노드들을 저장하는데 사요오디는 인덱스 레코드들을 포함한다. $BITMAP 속성은 레코드들의 할당상태를 표현한다. 트리의 각 노드들은 인덱스 엔트리들의 목록을 포함한다.

 

 

▶ 디렉토리 인덱스

- NTFS 디렉토리는 헤더, $STANDARD_INFORMATION, $FILE_NAME 속성에 특별한 플래그가 있는 일반적인 MFT엔트리를 갖는다. 디렉토리 인덱스의 인덱스 엔트리들은 파일 참조 주소와 $FILE_NAME 속성을 포함한다. $FILE_NAME 속성은 파일의 이름, 비필수 정보, 크기 , 기본 플래그들을 가지고 있다. 윈도우에서 이 비필수 정보와 크기를 업데이트 한다. 그래서 정확한 정보를 가진다. 윈도우가 도스 이름공간을 요구하면 동일 파일에 여러개의 $FILE_NAME 속성이 인덱스에 존재한다. $INDEX_ROOT와 $INDEX_ALLOCATION, $BITMAP 속성들은 이름 $I30을 할당한다.

 

-> 위 그림은 두 레벨의 디렉토리 구조를 보여주며 루트노드는 $INDEX_ROOT에 존재하고, $INDEX_ALLOCATION에는 두개의 인덱스 레코드가 존재한다. 인덱스 레코드 0에 있는 엔트리들은 hhh.txt 보다 작은 이름들을 갖고, 인덱스 레코드 1에있는 엔트리들은 hhh.txt보다 큰 이름들을 가지고 있다. eeeeeee.txt 파일은 도스 이름 공간에 있지 않고 그것을 위한 두번째 엔트리가 있다. (아 이게 파일이 그냥 여기 저장되어 있는건가보다.)

- 디렉토리에 파일이 더해지거나 지워질때 트리는 재구성되어 모두 정렬된다. 이는 11장에서 다루었다. 

 

 

▶ 루트 디렉토리

- 파일시스템에서 전체 경로로 한개의 파일을 찾으려면 루트 디렉토리의 위치를 아는 것이 상당히 중요하다. 루트디렉토리는 항상 ':' 이름을 갖는 MFT엔트리 5에 위치한다. 그 엔트리는 표준 $INDEX_ROOT, $INDEX_ALLOCATION 그리고 $BITMAP 속성을 갖는다. 모든 파일시스템 메타데이터 파일들은 이 디렉토리에 위치한다.

 

 

▶ 파일과 디렉토리 연결

- NTFS는 하드링크(Hard Link)를 이용해서 파일이 한개 이상의 이름을 갖도록 한다. 하드링크는 원래의 파일 이름 연결 방식과 차이가 없고, 원본과 동일한 엔트리를 가리키도록 부모 디렉토리 인덱스 엔트리에 할당된다. MFT 헤더에 있는 링크카운트는 하드링크가 생성될 때마다 하나씩 증가하고, 엔트리는 링크카운트가 0이되어야 비할당 된 것이다. 

- 다른 말로하면 원본파일 이름이 지워졌지만 하드링크가 여전히 존재한다면 그 파일은 지워진 것이 아니다. MFT 엔트리는 각 하드링크 이름을 위한 한개의 $FILE_NAME속성을 갖는다. 하드링크들은 오직 같은 볼륨에서만 생성될 수 있다.

- NTFS 3.0+ 버전에서는 파일 디렉토리 볼륨을 연결하는데 사용되는 재파싱 지점이라는 기능이 있다. 재파싱 지점은 무엇을 연결하고 있는지에 대한 정보를 포함하는 특별한 파일이나 디렉토리이다. 재파싱 지점은 같은 볼륨, 다른 볼륨, 다른 원격 서버의 파일들과 디렉토리들을 링크할 수 있다. 재파싱 지점은 드라이브에 마운트하는 대신 볼륨을 마운트 하기 위해 사용될 수 있다. 심볼릭 링크(Symbolic Link)는 두 파일을 연결하는 재파싱 지점이고, 접합은 두 디렉토리를 연결하는 것이다. 마운트 지점은 디렉토리와 볼륨을 연결하는 것이다. 윈도우 원격 저장서버 기능은 파일이나 디렉토리의 서버위치를 설명하기 위해 재파싱 지점을 사용한다. 

- 재파싱 지점은 특별한 파일들이고 $STANDARD_INFORMATION과 $FILE_NAME속성들의 플래그 세트를 갖는다. 또 그것들은 대상이나 디렉토리 위치에 대한 정보를 포함하는 $REPARSE_POINT 속성을 갖는다. 이 $REPARSE_POINT 속성은 13장에서 확인해보자. 

- NTFS는＼$Extend＼$Reparse 파일시스템 메타데이터 파일의 인덱스를 이용해 경로의 기록을 남긴다. 이 인덱스는 대상경로를 포함할 수 없다. 

- NTFS는 REPARSE 외에 MFT 엔트리 5, 루트 디렉토리 $DATA 속성에서 마운트 지점의 경로를 관리한다. $MountMgrRemoteDatabase라 부르는 $DATA 속성은 마운트 지점에서 가리키는 대상 볼륨을 포함한다. 이 $DATA 속성은 마운트 지점이 파일시스템에 존재할때 생성된다. 

 

 

▶ 오브젝트 식별자

- NTFS 3.0+버전에서 파일이름, 디렉토리이름, MFT 엔트리 주소를 사용하는 것 외에 이것들을 주소화하는 두번째 방법이 있다. 운영체제나 응용프로그램들은 각 파일에 고유한 128비트 오브젝트 식별자를 할당하고, 이는 파일이름이 변경되거나 다른 볼륨으로 이동할 때 파일을 참조하기 위해 사용된다. 

- ＼오브젝트 ID를 갖는 파일이나 디렉토리들은 $OBJECT_ID 속성이 있고, 그 속성은 원본 도메인과 생성되었던 볼륨에 관한 정보를 포함한다. 오브젝트 ID로 파일을 찾는다면, ＼$Extend＼$ObjId 인덱스를 참고할 수 있다. 이 인덱스는 할당된 오브젝트 ID에 대한 엔트리를 포함하고, 엔트리에 파일참조 주소를 부여한다.

- 이 주소지정 방법은 수사관에게 도움이 될 수 있지만, 아직까지 오브젝트 ID를 통해 파일을 검색하는 도구는 없다.(2011년기준)

 

 

▶ 할당 알고리즘

- NTFS는 B-Tree를 이용하고 할당하는 방법이 다양하다. 너무 많은 노드가 존재하면 트리를 나누고, 새로운 레벨을 생성한다. 파일을 삭제할 때 엔트리는 트리에서 제거되고 노드에 남아있는 엔트리는 비워진다. 노드에 엔트리들이 거의 없다면 다른 노드에서 엔트리들을 빌려와 균형을 유지한다. 

- 작은 디렉토리는 1개의 노드를 가지고 이는 $INDEX_ROOT 속성에 할당된다. 엔트리들이 늘어나면 그 엔트리들을 $INDEX_ALLOCATION 속성에 이동시키고 $INDEX_ROOT는 비워둔다. 단지 자식노드를 가리키게 된다. 인덱스 레코드가 다 차게되면 두번째 레코드를 할당하고 $INDEX_ROOT는 루트노드로서 사용된다. 자식들은 두개의 인덱스 레코드를 갖는다. 

- 그 시스템에서 $FILE_NAME 속성의 비필수 값들과 크기 값들은 파일의 MFT엔트리 $STANDARD_INFORMATION 속성에 그 값과 같은 비율로 업데이트 된다. 

 

 

▶ 분석 기술

- 파일이름 범주 분석은 파일 이름을 통해 파일과 디렉토리 위치를 파악하는 것이다. 이 과정은 디렉토리 위치를 확인하고 내용을 분석하여 파일과 관련이 있는 메타데이터 위치를 확인하는 것을 포함한다.

- 이 과정의 첫 단계는 MFT 5번 엔트리에 있는 루트 디렉토리 위치를 확인하는 것이다. 그 후 $INDEX_ROOT와 $INDEX_ALLOCATION 속성들의 내용을 조사하고, 인덱스 엔트리들을 해석하는 것이다. 이러한 속성들의 트리의 노드에 해당하는 인덱스 레코드 목록을 포함한다. 인덱스 레코드는 한개 또는 그 이상의 엔트리들이 있고, 비할당된 엔트리를 가질 수 있고 그 헤더는 마지막으로 할당된 엔트리들이 어디있는지 식별한다. 디렉토리의 $BITMAP 속성은 인덱스 레코드들의 할당상태를 판단한다. 할당된 파일은 할당된 엔트리 뿐 아니라 비할당된 엔트리도 가지는데 이는 파일이 추가되고 삭제될 때 디렉토리가 B-Tree에 저장되고 재할당 되어야 하기 때문이다. 

- 파일 이름은 포인터나 마운트 지점인 재파싱 지점에 해당한다. 재파싱 지점 대상은 $REPARSE_POINT 속성에 정의되어있다. 마이크로소프트에서 지정한 재파싱 지점은 일부이고 나머지는 응용프로그램에 종속적이다. 마이크로소프트에서 지정한 재파싱 지점은 유니코드로 되어있기 때문에 쉽게 읽을 수 있다. 

 

 

▶ 분석 고려사항

- 파일들이 더해지거나 지워질때 트리는 재정렬되고 엔트리는 다른 노드로 이동된다. 트리 노드 비할당 공간에 삭제된 데이터가 있을 수 있다. 

- 일부 인덱스 비할당 공간은 같은 파일의 데이터 복사본을 포함할 수 있다. 파일이 정말 지워졌는지 확인하기 위해서 비할당 공간에서 파일이름 복사본이 있는지 검색해야 한다. 

- 지워진 파일이름을 찾을 때 NTFS는 다른 파일 시스템들에 비해 여러가지 이점이 있다. 파일 참조 순서 번호는 MFT엔트리가 지워진 후 재할당 되어있는지 보여준다. 다른 파일 시스템과 마찬가지로 파일이름이 데이터와 동기가 맞는지 확인해야 한다. 

- 지워진 파일이 디렉토리에 존재하는지 점검하고자 할때, 분석 도구는 두 위치를 확인한다. 

첫번째는 디렉토리 인덱스 트리 각 노드의 비할당 영역이다. 

두번째는 비할당 MFT엔트리이다, 

만약 파일이름이 인덱스에서 지워졌지만 파일 MFT엔트리가 여전히 존재한다면 $FILE_NAME 속성을 통해 부모 디렉토리 MFT 주소를 확인할 수 있고 어떤 디렉토리 일부분인지 확인할 수 있다. 분석도구가 특정 지워진 파일 이름을 보여줄 때 앞에 두 절차를 이용하는지 확인해야 한다.

 

 

▶ 분석 시나리오

- 두개의 분석도구를 테스트해보자. DI4K와 FSA1K이다. 또한 대상은 NTFS 파일시스템이다.

 

1. 삭제된 파일 a.txt는 DI4K결과에는 없지만 FAS1K에는 있다.

2. 두 결과에서 m.txt파일의 시간이 다르다. DI4K에서 보여주는 시간이 FSA1K에서 보여주는 시간보다 늦다.

3. 삭제된 파일 w.txt는 DI4K 결과에는 있지만 FSA1K결과에는 없다.

 

- 두 도구에서 할당된 파일들의 결과는 같다. 그 $INDEX_ROOT와 $INDEX_ALLOCATION 속성들을 처리해보면 이덱스 구조는 아래 (A)와 같다.

두 도구에서 다른 결과를 보여주는 하나의 디렉토리

-> 위 레이아웃을 사용해서 왜 첫번째 문제가 발생했는지 알 수 있다.

1번 문제는 삭제된 a.txt를 찾는 것이다. 하지만 (A)에서 a.txt를 발견할 수 있다. 아마 a.txt가 할당된 엔트리는 이전 파일이 삭제되고 a.txt가 재할당된 엔트리 일 것이다. 그래서 엔트리에서 a.txt를 찾은 DI4K는 비할당 엔트리로 출력하지 않았다.  

2번 문제는 FSA1K는 루트인덱스의 $STANDARD_INFORMATION을 처리했을 것이고, DI4K는 (B)의 MFT엔트리 31의 $FILE_NAME 날짜를 보여주었을 것이다. 여기서 (B)의 순서번호가 더 뒤이므로 더 시간이 늦다. 

3번 문제는 w.txt에 관한 문제이지만 인덱스에서는 그것을 볼 수 없다. 삭제된 이름이 덮어씌워졌기 때문이다. MFT엔트리에서 논리적 파일시스템 검색을 통해 w.txt를 검색한다. 즉, DI4K는 인덱스에 있는 비할당 엔트리를 보여줄 뿐 아니라 고아 파일을 검색하는 것을 알 수 있다. 

 

 

---

p.s 오늘은 짧았다!!! (그제 생일이라 많이 못했다ㅜㅜ 다시 달리도록 하겠습니다.)