no image
NTFS File System (8) $LogFile
개요$LogFile? 지금까지의 과정은 $MFT를 위주로 진행되어왔다. 이제 MFT Entry 2번($MFT가 0번)에 위치하는 $LogFile에 대하여 알아보자. 추후에 학습할 $UsnJrnl이 변경 로그라면 $LogFile은 트랜젝션 로그이다. 이 역시 각 볼륨마다 하나씩 존재하며 만약 NTFS가 정전이나 기타 오류로 인해 갑작스럽게 중단되면 운영체제는 $LogFile에 저장된 로그를 바탕으로 현재 진행되는 작업의 이전 상태로 파일 시스템을 복구한다. 파일이나 디렉터리의 생성, 삭제, 데이터 작성, 파일명 변경 등 트랜잭션 작업 내용은 레코드 단위로 기록되며, $LogFile의 작업 레코드에 저장된다. 각 작업 레코드는 고유의 LSN($LogFile Sequence Number)를 가지며 이는 순차적..
2016.01.13
no image
NTFS & Python - $MFT Acquisition
1. 개요 포렌식을 공부하면서 점차 데이터 복구나 수집한 증거를 분석하는 방법에 대하여 점차 관심이 많아지기 시작하였다. 이를 위해선 공통적으로 파일 시스템에 대한 이해가 필요하다고 생각하였고, 그렇기에 현재 사용하고 있는 NTFS에 대하여 먼저 학습해보자 생각하였다. 파일 시스템이나 NTFS에 대하여 이론적으로 더 잘 정리된 많은 문서들이 있으므로, 나는 Python을 통해 접근을 하기 위함을 목적으로 학습을 진행하였다. 이렇게 접근을 한 다음 최종적으로는 $MFT 수집 도구를 만드는 것이 목적이다. 학습을 위한 준비사항은 아래와 같다. 도구 이름도구 버전다운로드Python2.7https://www.python.org/HxD.http://mh-nexus.de/en/hxd/Py2exe.http://www..
2016.01.07
no image
NTFS File System (6) MFT $SIA & $FN $DATA
MFT - Attribute$STANDARD_INFORMATION ($SIA) 모든 파일에 기본적으로 존재하는 속성이다. 기본적으로 존재하는 속성인 만큼 파일의 시간정보, 파일 특성, 소유자 및 보안 ID 등의 기본적인 속성 정보를 가지고 있다. 속성 타입 번호는 0x10(16)임을 이전에 확인할 수가 있었다. 속성의 크기는 윈도우 버전에 따라 조금 상이한데 윈도우2000,XP이상(72바이트), 윈도우NT(48바이트)를 갖는다. 이제 구조에 대해서 한번 살펴보자. 속성 헤더가 먼저 나온 뒤 $STANDARD_INFORMATION의 속성내용들이 나오는 것을 확인할 수가 있다. 각 항목에 대한 설명은 아래의 표와 같다. 위의 그림은 실제 내 PC $MFT의 내용이다. 이를 해석하면 다음과 같다. 우선 생성 ..
2015.12.31
no image
NTFS File System (5) MFT -Attribute
MFT - Attribute속성 종류 MFT Entry Header, Fixup Array에 이어 이번에는 Attributes에 대하여 알아보자. Attributes는 각 파일의 메타정보를 표현하고 있으며 Attribute Header + Attribute Content로 구성되어 있다. 크기에 따라 Resident와 Non-Resident 속성으로 구분하며 총 17가지의 속성이 있다. 이러한 속성은 각 각 다른 Header를 가지며 기본적으로는 $STANDARD_INFORMATION, $FILE_NAME, $DATA를 가진다. 아래의 그림과 같다. 이러한 속성은 Fixup 배열 이후 End Marker가 올 때까지 연속적으로 오며 각 속성은 위에서 말한 바와 같이 속성헤더와 속성 내용으로 나뉘어진다. ..
2015.12.30
no image
NTFS File System (4) MFT
4. MFT NTFS File System (1) ~ (3)을 통해 MBR(혹은 EBR)을 지나 해당 파티션의 VBR을 찾을 수가 있었다. 이러한 VBR에서 BPB를 참고하여 $MFT의 위치까지 찾아보았다. 이제 이러한 MFT에 대하여 설명을 하고자 한다. MFT는 Mater File Table의 약자로 NTFS에선 파일이나 디렉터리, 메타 정보를 모두 파일의 형태로 관리하고 있다. 이러한 각 파일의 위치나 속성, 이름, 크기 등의 메타정보는 MFT Entry라는 특별한 구조로 저장된다. MFT는 NTFS 상에 존재하는 모든 파일의 MFT Entry의 모음으로 아래의 그림과 같이 나타낼 수 있다. 위의 표와 같이 각 엔트리의 번호와 기능에 대하여 설명할 수가 있다. 이러한 각 각의 엔트리는 MFT Ent..
2015.12.29
no image
NTFS File System (3) VBR
3 .NTFS - VBR 이전 포스팅에선 MBR의 파티션 테이블(혹은 EBR)을 참고하여 해당 파티션의 위치를 찾을 수가 있었다. 여기서 필자는 NTFS를 학습하기 위함으로 FAT16, FAT32 외 다른 것들은 일단 제외하겠다. 우선 NTFS의 구조는 아래의 그림과 같다. VBR(Volume Boot Record)와 MFT가 있으며 그리고 Data 영역이 존재하고 있는 것을 확인할 수가 있다. 우선 VBR에 대하여 먼저 이야기를 해보자. VBR은 그 크기가 고정된 것이 아니라 클러스터의 크기에 의존한다. 아래의 표와 같다. 하지만 이전에 말했듯이 대부분의 NTFS는 클러스터의 크기가 4KB이므로 VBR의 크기는 8 Secotr(== 1cluset)가 된다. VBR의 구조에 대해선 아래의 그림과 같다. ..
2015.12.29
no image
NTFS File System (2) MBR & EBR
2. MBR 하드디스크를 용도에 따라 여러 개의 파티션으로 나눌 수가 있다. 예를 들어 이전 (1)에 했던 포스팅에서 필자의 PC는 4개의 파티션으로 나뉘어져 있는 것을 확인할 수가 있었다. 하지만 스왑을 위한 파티션이나 윈도우 시스템 예약을 제외하면 칼리 리눅스와 윈도우가 있는 파티션 2개가 존재한다고 볼 수 있다. 이러한 각 파티션은 하나의 물리 디스크로부터 관리가 필요한데, 이러한 파티션을 MBR 구조로 관리한다. MBR은 저장 매체(물리 디스크)의 첫 번째 섹터에 위치하며 512Byte의 크기를 갖는다. 이는 446Byte의 Boot Code와 Partition Table 64 Byte, 그리고 Signature 2 Byte로 총 512Byte(0x200)의 크기를 갖는다. 여기서 64 Byte에..
2015.12.29
no image
NTFS File System (1) 개요
1. 개요 파일 시스템이란 디지털 데이터를 효과적으로 관리하기 위해 파일을 체계적으로 기록하는 방식으로, 사용자에게 계층 구조로 데이터를 저장하도록 하는 방식을 말한다. 파일이 어디에 저장되어 있는지 조직화하고, 사용자의 데이터를 구조적으로 정의하도록 한다. 이는 파일을 빠르게 읽기, 쓰기, 삭제 등 기본적인 기능을 원활히 수행하도록 도와주며 사용자 영역이 아닌 커널 영역에서 동작한다. 이론적인 내용을 먼저 설명하기 전에 직접 어떻게 생겼는지 확인해보자. 여기선 HxD를 통해 확인해볼 것이며, 관리자 권한을 통해 실행을 해야 디스크를 읽을 수가 있으므로 관리자 권한으로 HxD를 실행해보자. 위의 그림과 같이 나타나는 것을 볼 수가 있다. 여기서 필자는 컴맹이므로 하나 하나가 모두 새로웠기에 다들 아는 이..
2015.12.28

개요


$LogFile?

  지금까지의 과정은 $MFT를 위주로 진행되어왔다. 이제 MFT Entry 2번($MFT가 0번)에 위치하는 $LogFile에 대하여 알아보자. 추후에 학습할 $UsnJrnl이 변경 로그라면 $LogFile은 트랜젝션 로그이다. 이 역시 각 볼륨마다 하나씩 존재하며 만약 NTFS가 정전이나 기타 오류로 인해 갑작스럽게 중단되면 운영체제는 $LogFile에 저장된 로그를 바탕으로 현재 진행되는 작업의 이전 상태로 파일 시스템을 복구한다.


  파일이나 디렉터리의 생성, 삭제, 데이터 작성, 파일명 변경 등 트랜잭션 작업 내용은 레코드 단위로 기록되며, $LogFile의 작업 레코드에 저장된다. 각 작업 레코드는 고유의 LSN($LogFile Sequence Number)를 가지며 이는 순차적으로 증가한다. 이러한 각 레코드는 복구를 위해 작업 데이터(Redo)와 작업 전 데이터(Undo)를 갖는다.


$LogFile Size



  일반적인 하드 디스크 볼륨에서는 64MB인것을 알 수가 있으며 볼륨 용량에 따라 크기가 달라질 수는 있지만 기본적으로는 최대 64 MB 이하이다. 만약 이러한 $LogFile의 크기를 변경하고자 할 때는 chkdsk 명령의 /L 옵션에 따라 크기 조절이 가능하며 '/L:파일크기(KB 단위)' 형식의 옵션을 주면 $LogFile의 크기를 변경할 수 있으며 크기를 지정하지 않는다면 위의 그림과 같이 현재 크기를 나타낸다.




구조


$LogFile의 전체적인 구조

  $LogFile은 아래의 그림과 같이 재시작영역(Restart Area)과 로깅 영역(Logging Area)으로 나뉘어진다. 각 영역의 구성 단위는 0x1000(4096)바이트 크기의 페이지이다. 재시작 영역은 파일의 가장 첫 두 페이지(0x0000~0x20000)에 해당하고 가장 마지막 작업에 대한 정보를 가지고 있다.


  로깅 영역은 재시작 영역 외의 영역(0x2000~)을 말하며 실제 작업 레코드들이 기록된다. 로깅 영역은 다시 버퍼 페이지 영역과 일반 페이지 영역으로 구성된다. 이에 대한 건 좀 더 뒤에서 이야기할 것이다.



$LogFile 재시작 영역 구조



  위에서 말한 바와 같이 재시작 영역은 가장 마지막 작업 레코드를 가리키며 이는 현재 작업 중인 내용으로 0x0000부터 두 페이지(0x2000)로 구성이 된다. 여기서 두 번째 페이지는 백업용으로 사용되며 각 페이지는 매직넘버(RSTR)로 시작한다. 운영체제는 이 영역에서 마지막 레코드에 대한 정보를 가져와서 파일 시스템을 복구하는 것이다. 위의 그림은 재시작 영역의 페이지 헤더 구조이며 Cuurent LSN 필드에 마지막 작업 레코드의 LSN 정보를 저장하고 있다.



  위 그림은 실제 $LogFile을 Hex Editor로 열어서 확인한 것으로 상단의 그림은 첫 번째 페이지 영역으로 매직넘버 RSTR로 시작하는 것을 확인할 수가 있다. 하단의 그림은 두 번째 페이지 영역(0x1000~0x2000)의 시작 부분으로 위와 같은 구조를 가지고 있으며 백업을 위한 공간임을 알 수가 있다.


* 재시작 영역은 운영체제가 어떠한 파일 시스템의 정리를 수행할 경우 어떠한 트랜잭션을 참고해야 하는지 판단하는데 도움을 주는 구조체이며, 성공적인 마지막 트랜잭션을 위한 어떤 로깅 영역을 가리키는 포인터를 포함한다.



$LogFile 로깅 영역 구조


  로깅 영역에는 실제 작업 레코드들이 기록되며 버퍼 페이지 영역과 일반 페이지 영역으로 나뉘어진다. 여기서 버퍼 페이지 영역은 첫 두 페이지(0x2000~0x4000)가 존재하고 두 번째 페이지는 위와 같이 백업용이며 순차적으로 레코드가 기록된다. 여기서 만약 버퍼 페이지가 레코드로 가득 차게 되면 페이지 내용을 일반 페이지 영역으로 기록을 넘기는 형식으로 작업이 진행된다. 따라서 가장 최근의 작업 레코드들은 버퍼 페이지 영역에 남게 된다.


  일반페이지 영역은 버퍼 페이지를 제외한 나머지 영역(0x4000~)을 말하며 버퍼 페이지가 모두 채워지면 기록된 내용을 받는 역할을 한다. 만약 작업 레코드들이 파일 끝까지 가득 차게 되면 위의 그림과 같이 일반 페이지 영역 시작부분부터 다시 덮어쓰는 방식으로 진행된다.


* Redo 필드는 어떤 동작이었는지에 대한 정보를 저장하며, Undo 필드는 어떤 동작을 어떻게 원래대로 되돌리는지 설명하는 정보를 저장한다.



Page 구조



  페이지는 $LogFile의 기본 구성 단위이며 크기는 0x1000(4096 Bytes)로 고정되어 있다. 페이지는 하나의 헤더와 다수의 작업 레코드들로 구성되어 있으며 마지막 레코드가 페이지를 넘어가면 다음 페이지에 이어서 기록이 된다. 위의 그림은 이 구조를 나타낸 것으로, 페이지 헤더에 매직 넘버('RCRD')가 나오는 것을 확인할 수가 있으며 Last LSN 필드의 정보를 통해 페이지 내에서 가장 나중에 기록된 작업 레코드의 LSN 정보를 획득할 수 있다. Next Record Offset 필드의 정보를 통해 페이지 내에서 가장 나중에 기록된 작업 레코드의 위치를 알 수가 있다.


 Magic Number

 "RCRD" 

 Last LSN 

 페이지를 넘어가는 레코드를 포함해서 가장 큰 LSN 

 Next Record Offset  

 Last LSN에 해당 하는 레코드의 페이지 내 Offset 

 Last End LSN 

 페이지를 넘어가지 않는 레코드들 중에 가장 큰 LSN 


  결국 운영체제는 재시작 영역의 Currsnt LSN 필드에서 가장 마지막에 기록된 LSN 정보를 가져와서 해당 LSN 정보를 Last LSN 값으로 가진 페이지를 찾고, 그 페이지의 Next Record Offset을 가져와 실제 마지막 기록된 레코드의 위치를 찾는다.



작업 레코드 구조



  작업 레코드에는 실제 트랜젝션 작업의 내용이 기록되며 위의 그림과 같이 여러 작업 레코드가 순차적으로 모여서 하나의 트랜젝션 작업을 이룬다. 가장 첫 레코드를 Checkpoint 레코드라 하며 마지막 레코드를 Commit 레코드라 한다. 그 외 중간에 있는 레코드들은 Update 레코드라 한다.


  Checkpoint 레코드 외의 레코드들은 자신의 이전 작업 레코드의 LSN 값을 가지고 있다. 따라서 파일 시스템 복구 시, 운영체제는 트랜젝션 작업을 구성하는 레코드들을 역추적하면서 각 레코드들의 Undo 데이터를 사용하여 복구할 수가 있다.


[이미지 출처 - zrungee Blog]


  작업 레코드는 레코드 헤더와 데이터 영역으로 구성된다. 레코드 헤더는 고정된 0x58 크기를 가지며 데이터 영역은 Redo와 Undo 데이터가 들어가기 때문에 크기가 가변적이다. 따라서 작업 레코드의 크기도 가변적이며 큰 레코드는 여러 개의 페이지를 사용하기도 한다. 그리고 하나의 작업 레코드가 끝나면 바로 이어서 다음 작업 레코드가 이어진다. 상세한 작업 레코드 헤더 구조는 위의 그림과 같으며 각 필드에 대한 설명은 아래의 표와 같다.



  Redo Op 필드와 Undo Op 필드는 실제 레코드가 어떠한 작업을 수행하였는지에 대한 정보를 가진다. 각 Op가 가지는 연산 코드의 의미는 아래와 같다.




출처 및 참고

http://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?curPage=1&menu_dist=2&seq=19518

http://zrungee.tistory.com/206

'Forensic > Theory' 카테고리의 다른 글

Volume Shadow Copy 분석  (1) 2016.01.18
NTFS FIle System (9) $UsnJrnl  (0) 2016.01.16
NTFS File System (7) INDEX  (0) 2016.01.02
Cluster Run 직접 확인해보기 - MFT엔트리찾기  (0) 2015.12.31
NTFS File System (6) MFT $SIA & $FN $DATA  (0) 2015.12.31

  포렌식을 공부하면서 점차 데이터 복구나 수집한 증거를 분석하는 방법에 대하여 점차 관심이 많아지기 시작하였다. 이를 위해선 공통적으로 파일 시스템에 대한 이해가 필요하다고 생각하였고, 그렇기에 현재 사용하고 있는 NTFS에 대하여 먼저 학습해보자 생각하였다.

  파일 시스템이나 NTFS에 대하여 이론적으로 더 잘 정리된 많은 문서들이 있으므로, 나는 Python을 통해 접근을 하기 위함을 목적으로 학습을 진행하였다. 이렇게 접근을 한 다음 최종적으로는 $MFT 수집 도구를 만드는 것이 목적이다. 학습을 위한 준비사항은 아래와 같다.

도구 이름

도구 버전

다운로드

Python

2.7

https://www.python.org/

HxD

.

http://mh-nexus.de/en/hxd/

Py2exe

.

http://www.py2exe.org/

표 1. 사용한 도구

  학습은 윈도우 10을 통해 진행하였으며 전체적으로 학습을 하면서 Windows7이나 XP와의 별 차이를 느끼지 못하였다. Prefetch나 Web Artifact에 있어선 좀 상이한 부분이 있지만, 이번 문서에서 다루는 내용에 한해서는 큰 차이가 없었다.


그림 1. 부팅 과정

  컴퓨터의 전원을 누른 순간부터 사용자 모드로의 부팅 과정은 위의 그림과 같다. 여기서 BIOS는 ROM에 적재가 되어 있으므로 우리는 MBR부터의 과정을 구체적으로 확인할 수가 있다. 이를 토대로 학습을 진행해보자.



2. 디스크 접근


2.1 HxD 디스크 열기

  전체적인 진행을 하기 전에 직접 자신의 디스크를 확인해보자. HxD를 관리자 권한으로 실행을 한 다음, 아래의 버튼과 같이 디스크 열기를 누르면 대개 '논리 디스크'와 '물리 디스크'라 나뉘어 있는 것을 확인할 수가 있다.

그림 2. HxD 디스크 열기

  이 중 어떠한 것을 열어야 할 지 모른다면 직접 둘 다 열어서 확인해보자. 어떠한 차이가 있는지는 아래의 그림과 같다. '물리 디스크'를 먼저 확인해보면 알 수 있는 것이 아무것도 없다. 반면에 '논리 디스크'로 연다면 시작과 함께 NTFS라는 문자열이 있다.

그림 3. HxD 디스크 확인

  이는 기본적인 디스크를 어떻게 구분하느냐에 따른 것이다. 물리 디스크는 하나의 장치 그 자체를 말하는 것이며 논리 디스크는 하나의 파티션이나 볼륨과 같은 논리적인 부분을 말하는 것이다.


2.2 Python 디스크 열기

  Python을 통해 이러한 물리 디스크나 논리 디스크에 접근하는 방법에 대하여 알아보자. Python에는 기본적으로 open(filename, type) 함수가 존재하고 있다. 그렇다면 어떻게 이러한 시스템적인 부분에 접근하는가? 아래의 그림을 보자.

그림 4. Python – open()

* 여기서 CMD를 열 때Administrator 권한으로 열어야 권한 거부가 생기지 않는다.

 

  이렇게 Python에서 Drive에 접근하고자 할 땐 '\\\\.\\Drive'와 같이 나타내어야 한다. 이는 원래 \\.\Drive 인 것을 나타내기 위해 \를 두 번씩 표기하여 주는 것이다. 만약 두 번씩 하지 않으면 하나는 생략된 결과로 Python은 인식하게 된다. 접근 모드는 'rb'로 바이너리를 읽기 모드로 여는 것이다.

그림 5. Python – read()

  제대로 물리 드라이브를 읽는 것을 확인할 수가 있다. 그렇다면 물리드라이브엔 어떻게 접근을 해야 할까? 의문을 가질 수가 있다. 결국 최종적인 목표는 $MFT를 수집하는 것임을 잊지 말자. NTFS에서 부팅 가능한 영역을 MBR에서 찾아서 가는 것이 어찌 보면 부팅 과정처럼 정도의 길이라 할 수가 있다.

 

그림 6. Python – 논리 디스크 열기

  하지만 바로 논리 디스크로 접근하는 방법이 있다면 굳이 MBR에서부터 부팅 가능한 영역을 찾는 번거로움을 감수하고 싶지는 않을 것이다. 위의 그림과 같이 \\\\.\\ 뒷 부분에 열고자 하는 논리 디스크 'C:'와 같이 입력을 해주면 된다. 읽은 부분에서 NTFS 라는 그림 3에서 확인했던 문자열이 올바르게 출력되는 것을 확인할 수가 있다.


2.3 MBR 구조

  물리 디스크 영역은 앞 부분에 MBR(Mater Boot Record)가 있다. 코드 영역엔 부팅을 하기 위한 코드들이 포함되어 있으며, 붉게 표시한 부분은 바로 파티션 테이블로 64 Byte를 차지하고 있는 것을 확인할 수가 있다. 전체적인 구조는 아래와 같이 나타난다.

 

그림 7. MBR

  코드 영역은 별도의 구조가 없이 코드들로 이루어져 있지만 파티션 테이블의 경우에는 구조가 있기 때문에 그 구조에 맞게 해석을 할 수가 있어야 한다. 파티션 테이블은 부팅 가능한 디스크를 나타내기 위한 부분으로 아래의 구조와 같다.

그림 8. Partition Table

  여기서 중요한 것은 바로 앞 부분의 1바이트이다. Boot Flag로 부팅이 가능한 파티션인지를 나타내는 값으로 0x80은 부팅이 가능하다는 것을 뜻하며 0x00은 부팅이 불가능함을 뜻한다. 파티션 타입의 경우 어떤 타입(FAT, Unix, NTFS 등)을 나타낸다.

  그렇다면 부팅 가능한(Boot Flag = 0x80) 파티션이 있다면 그 위치는 어떻게 알 수 있을까? 예전엔 CHS Address를 사용했지만 점차 용량이 커지므로 표현의 한계가 있기에 현재는 LBA를 통해 해당 운영체제의 시작 지점을 알 수가 있다. 여기서 LBA란 Local Black Area의 약자로 흔히 섹터라 표현할 수가 있다. 위 그림 8의 Starting LBA Address란 결국 몇 번째 섹터에 운영체제가 시작하는 지 포함되어 있음을 의미한다. 이를 직접 확인해보자.

 

그림 9. HxD Partition Table

  위의 그림은 실제 내 PC의 파티션 테이블이다. 각 색에 맞게 4개의 파티션이 나타나 있는 것을 확인할 수가 있다. 세 번째 파란색 부분을 보면 부팅 플래그가 0x80으로 부팅이 가능함을 나타내며 7912000 LBA에 운영체제가 시작함을 나타낸다.

* 참고 : 섹터의 크기는 512 Bytes이므로 해당 LBA에 512를 곱해 Offset을 알 수 있다.

  단, 윈도우 7부턴 윈도우를 설치할 때 시스템 예약 파티션이 나뉘어 지는데, 해당 파티션은 BitLocker 암호화를 위한 예약된 공간이다. 특이한 점은 이전 XP와는 다르게 부팅 플래그가 바로 이 시스템 예약 파티션에서 설정이 되어 있다는 점이다. 다시 말해 위 그림 9의 부팅 플래그 0x80으로 되어 있는 부분이 시스템 예약 파티션이란 것이다. 정확한 이유는 알 수가 없지만, BitLocker 암호화는 지정된 보호 기능을 위해 동작하는 것으로, 해당 부분을 보호하기 위하여 먼저 이 곳으로 부팅이 되는 것이 어찌 보면 당연한 것이다. 컴퓨터의 전원을 켰을 때 장치에 이상이 없는 것을 POST에서 확인하는 것과 유사하다고 생각하자.

  그렇다면 그림9에서 NTFS는 어디에 있는 것일까? 바로 네 번째 부분에 존재하고 있다. 파티션 타입번호(0x07)을 통해 확인하거나 해당 LBA로 직접 가서 확인하는 방법이 있다. 물론 시스템 예약 파티션을 없애면 바로 NTFS로 부팅 플래그가 설정 될 것이다. 만약 파티션이 5개 이상이라면 MBR에 더해 EBR로 관리를 하는데 이는 파티션 테이블 부분에 EBR로 가는 16 Bytes 구조가 생기며 해당 LBA로 이동하면 다음 EBR과 자신이 가리키는 파티션의 LBA를 가지고 있다.

 

 

 3. NTFS


  2장의 과정을 통해 MBR을 통해 부팅 가능한 파티션과 해당 파티션의 위치를 찾아가는 방법에 대하여 알아보았다. HxD로 '물리 디스크'로 디스크를 열었지만 이 방법을 통해 NTFS가 있는 '논리 디스크' C:와 같은 부분을 찾을 수가 있다.

그림 10. 논리디스크 찾기

  이제 본격적으로 NTFS에 대하여 알아보자. Python을 통해선 2장의 과정이 없이 바로 C:와 같은 논리 디스크를 열 수 있음을 다시 한번 기억하자. 이제부터 다룰 내용은 NTFS의 구조에 대한 것으로 필수적으로 알아야 할 내용들을 주로 다룰 것이다.

 

그림 11. NTFS 구조

  위 그림은 NTFS에 대한 전체적인 구조를 나타낸 것이다. VBR을 시작으로 MFT가 존재하고 있으며 그 후 각 파일에 대한 Data가 존재하고 있는 Data Area가 있다. 이들에 대하여 알아보기 전에 클러스터(Cluster)에 대하여 간략히 설명하고자 한다.

   디스크는 기록을 할 때 Sector 단위로 한다. 하지만 NTFS 운영체제는 Cluster 단위로 기록을 하는 것으로 이 두 사이에 차이가 난다. 이러한 Cluster Size는 볼륨의 크기에 따라 주로 결정되며 기본적으로 2GB이상이라면 Cluster Size는 4 KB이다.

  

3.1 VBR

  VBR은 Volume Boot Record의 약자로 해당 볼륨의 부팅을 위한 영역이다. 여기서 우리가 주로 보아야 할 부분은 바로 보라색으로 나타나있는 BPB 부분이다. 해당 부분엔 많은 시스템에 대한 많은 정보들이 포함되어 있다. VBR의 구조는 아래의 그림과 같다.

그림 12. VBR 구조

 

  BPB엔 섹터의 크기나 클러스터의 크기를 포함하고 있으며 이 문서에서 가장 중요하게 다루는 MFT의 시작 위치가 있다. 그렇기에 이 부분의 몇 가지 항목만 올바르게 해석할 수 있다면 된다.

그림 13. BPB 구조

 

  우선 Bytes Per Sector와 sec per Clus라 되어 있는 부분은 각 각 섹터의 크기와 클러스터의 크기를 나타낸다. 만약 사용자가 그 값을 윈도우를 설치할 때 지정해주었다며 다를 수 있으므로 반드시 저 부분의 값도 확인을 해야 한다.

 그 다음 확인해야 할 중요한 사항은 바로 0x30에 위치한 Start Cluster for $MFT로 MFT의 첫 번째 Entry가 시작되는 클러스터의 번호를 담고 있다. 아래 예에선 MFT의 시작 위치가 C0000 Cluster임을 확인할 수가 있다. 따라서 해당 오프셋은 클러스터의 크기인 8 섹터와 섹터의 크기 512Bytes를 곱해주면 된다. 따라서 0xC0000000이 해당 오프셋이라는 것을 알 수가 있다.

그림 14. Start Cluster for $MFT

  해당 오프셋으로 이동하면 MFT의 Signature인 'FILE' 문자열을 확인할 수가 있다. 따라서 올바르게 값을 해석했다는 것을 알 수가 있다.

그림 15. $MFT Signature


3.2 VBR – Python

  그렇다면 Python을 통해서 VBR을 접근해보자. 그 뒤 필요한 항목을 어떻게 설정해야 하는지 확인해보자. 우선 '논리 디스크' C:를 위 그림 6에서의 방법과 동일하게 열어보자.

그림 16. Python – open C:

  여기서부턴 해당 디스크를 Bytearray를 통해서 읽을 것이다. 아까와 같이 올바르게 NTFS 문자열이 출력되는 것을 확인할 수가 있다. 이에 더해 한 가지 함수를 먼저 만들어보자. 만들고자 하는 함수는 Little Endian으로 되어있는 16진수 값을 10진수로 읽어 값을 반환해주는 함수로 이후에 계속 사용될 것이다.

그림 17. Python – LtoI()

 

  VBR에서 우리가 알아야 할 값은 총 3개이다. 섹터의 크기, 클러스터의 크기, 그리고 마지막으로 MFT Entry의 시작위치이다. 이 3개를 알아야 이후에 MFT에 대하여 Python을 통해 분석을 올바르게 할 수가 있다.

  섹터의 크기는 VBR에서 0x0B~0x0C에 위치해 있으며, 클러스터의 크기는 0x0D에 있는 것을 BPB구조에서 확인할 수가 있었고 MFT는 0x30에 해당 클러스터의 값이 있다. 이제 이를 Python으로 입력해보자.

그림 18. Python – Sector

  위의 그림과 같이 섹터의 크기는 512 Bytes(0x200)이며 클러스터의 크기는 8 섹터(4KB)임을 알 수가 있다. 이제 이 값을 가지고 MFT의 위치를 알맞게 해석할 수 있다. 아래의 그림을 보자.

그림 19. Python – MFT Offset

  MFT의 첫 번째 Entry의 Offset이 0xC0000000임을 Python을 통해 해석할 수가 있었다. 이제 VBR에서 우리가 더 확인해야 할 항목은 없으므로 이제 MFT에 대하여 학습해보자.



4. MFT


  VBR을 통해 MFT의 위치를 찾을 수가 있었다. MFR는 Master File Table의 약자로 NTFS에선 파일이나 디렉터리, 메타 정보들을 모두 파일의 형태로 관리하고 있다. 이러한 각 파일들의 위치나 속성, 이름, 크기 등의 메타 정보가 MFT Entry에 저장된다.

  따라서 이러한 많은 정보들이 저장된 MFT를 통해 Forensic 조사에 있어서도 많은 유용한 정보들을 제공한다. 그렇기에 MFT에 대하여 이해 한다는 것은 많은 이점을 갖게 되는 것과 같다. MFT가 갖는 각 Entry에 대한 설명은 아래와 같다.

그림 20. MFT Entry 정보

  많은 유용한 Entry들이 존재하지만, 모두 다루기엔 많은 분량이 나오므로 이 문서는 $MFT에 한정하여 설명할 것이며 추가적으로 필요한 내용에 한해서만 다룰 것이다. MFT Entry의 구조는 아래의 그림과 같다.

그림 21. MFT Entry 구조

    MFT Entry 헤더가 오고 그 다음 Fixup Array가 나온다. 그 다음 가장 중요한 속성이 나오고 End Marker와 함께 뒤 부분은 사용되지 않는다. 이에 대하여 알아보자.

  

4.1 MFT Entry Header

  MFT Entry 헤더는 Signature('FILE')로 시작하여 많은 정보들을 담고 있다. 이 문서는 MFT 수집 툴을 만드는 것이 목적이므로 많은 내용은 다루지 않을 것이다. 전체적인 구조는 아래의 그림과 같다.

그림 22. MFT Entry Header 구조

  여기서 우리가 알아야 할 항목은 0x14에 위치한 'Offset to File Attribute' 항목이다. 이 항목은 속성이 시작하는 위치를 나타내주는 값으로 MFT 수집 툴을 만들기 위해선 이러한 속성 중 $DATA에 접근하여야 한다. 이에 대해선 좀 더 뒤에서 다룰 것이다.

그림 23. HxD - MFT Entry Header

  위의 그림과 같이 0x14에 있는 값이 현재 0x38로 나타나는 것을 확인할 수 있다. 이는 0x38의 위치부터 속성이 시작된다는 것으로 그림에선 0x10이 존재하고 있다. 이는 $STANDARD_INFORMATION(이후 $SIA라 하자.)의 속성 ID 값으로 4.6에서 알아보자.

  

4.2 MFT Entry – Python

  MFT Entry 헤더의 구조에 대하여 알아보았다. 이제 이를 Python을 통해 접근하는 방법에 대하여 살펴보자. 우선 우리는 그림 19에서와 같이 VBR을 통해 MFT의 첫 번째 Entry 주소를 알 수가 있었다. 이제 이를 통해 포인터를 이동시켜보자.

그림 24. Seek(MFT_Offset)

  Seek()함수를 통해 파일을 읽을 위치를 이동 시킬 수가 있다. 우리는 현재 MFT Entry 정보를 읽을 것이므로 이전에 선언했던 mft_off 또는 그 위치 값인 0xc0000000으로 이동을 한 후 해당 부분을 512 Bytes 읽은 것이다.

 

그림 25. Attribute Offset

  512 Byte를 읽은 다음 속성이 위치한 곳의 주소를 얻기 위하여 mft_attribute_off를 선언해주고 0x14-0x15의 값을 읽는다. 또 MFT Entry의 크기를 확인하므로 속성의 시작과 끝을 알 수가 있고, 이러한 속성의 데이터를 attr_off로 지정해놓은 것이다.

  이제 속성의 시작 위치를 알 수가 있으므로 우리는 $DATA를 찾아야 한다. 이를 찾기 위해선 각 속성의 식별 값을 확인을 할 것이며 만약 $DATA의 식별 값인 0x80이 아니라면 해당 속성의 크기를 통해 다음 속성으로 넘어 갈 수가 있다.

그림 26. Find $DATA

  여기서 3번째 라인을 보면 속성 값이 아닌0x0000(NULL)이나 0xFFFF(EndMarker)가 읽히면 해당 루프를 빠져 나오는 것을 확인할 수가 있다. 속성 식별 값이 0x80이 아니라면 해당 속성의 size를 구해 그 만큼을 건너 띄는 것을 아래의 2줄을 통해 확인할 수가 있다. 만약 0x80($DATA)이라면 아직 지정하지 않은 Data_parse()라는 함수를 호출해 $DATA 속성을 분석할 것이다. 이에 대해선 속성에 대하여 알아본 뒤에 다시 해보자.

  

4.3 Attributes

  하나의 MFT Entry는 여러 개의 속성을 포함하고 있다. 이러한 속성엔 각 항목에 따라 유용한 정보들을 가지고 있으므로 이를 해석할 수 있어야 한다. 이러한 속성에 대한 설명은 아래의 그림과 같다.

그림 27. 속성 정보

  많은 속성 항목들이 있지만 모두가 중요한 것은 아니다. 크게 가장 많이 사용되는 항목은 $SIA와 $FILE_NAME(이후 $FN), 그리고 $DATA 항목이다. 우선 이러한 속성의 공통적인 구조 먼저 알아보자.

그림 28. 공통 속성 헤더

  속성의 구조는 거주 속성과 비거주 속성으로 나뉘어 지는데, 이에 대해 알기 전에 공통적을 포함되는 공통 속성 헤더에 대하여 알아보자. 구조는 위의 그림 25와 같이 되어 있다. 공통 속성헤더를 통해 어떠한 속성타입인지, 해당 속성의 길이가 얼마나 되는지, 만약 속성이 이름을 갖는다면 그 이름이 무엇인지 등이 있다. 여기서 속성 이름이란 $SIA나 파일 이름이 아닌, 속성 자체에 부여되는 이름을 뜻하는 것이다. 이러한 공통 속성 헤더 다음엔 거주 속성, 비거주 속성인지에 따라 다른 구조를 갖는다.

  

4.4 거주 속성 (Resident Attribute)

  거주 속성은 해당 속성의 내용이 크지 않기에 MFT Entry 구조에 모두 담을 수 있을 때의 갖는 상태이다. 속성 내용을 모두 담을 수 있기에 다른 곳을 보지 않아도 되며, 그 내용은 거주 속성 헤더 뒤에 나타난다. 이러한 거주 속성의 구조는 아래의 그림과 같다.

그림 29. 거주 속성 헤더

  속성 내용의 크기와 속성 내용의 위치, 인덱스 플래그, 마지막으로 속성의 이름이 있다면 그 속성의 이름이 나오며 없을 경우 바로 속성 내용이 나온다. 아래의 그림은 $MFT의 속성 부분을 나타낸 것이다.

그림 30. HxD - 거주 속성

  공통 속성 헤더를 제외하고 0x48부터 거주 속성 헤더가 존재하는 것을 확인할 수가 있으며 해당 속성은 이름이 존재하지 않기 때문에 바로 뒤에 속성내용이 따라오는 것을 확인할 수가 있다. 이렇게 거주 속성의 구조에 대하여 확인할 수가 있으며, 이러한 거주 속성은 대부분의 $SIA와 $FN에서 나타난다.

  

4.5 비거주 속성 (Non-Resident Attribute)

  속성 내용이 너무 커진다면 그것을 한곳에 모두 담을 수가 없다. 이러한 상태가 바로 비거주 상태라 하게 되며 이 경우 별도의 클러스터를 할당하여 그 곳에 내용을 담아 놓는다. 아래의 그림을 통해 구조를 확인해보자.

그림 31. 비거주 속성 구조

  공통 속성 헤더가 나온 뒤 VCN이나 런리스트, 속성 내용의 크기, 속성 이름과 속성내용 등 관련된 내용들이 기록되어 있다. 이 항목들 중 자세히 알아볼 내용은 런리스트에 관한 내용이다.

  비거주 속성은 속성 내용이 크기 때문에 외부 클러스터에 해당 내용들을 담고 있다. 하지만 이러한 클러스터들이 모두 연속적으로 존재할 수는 없기에 이러한 클러스터들에 대한 정보를 담고 있는 런리스트가 필요하다. 즉, 런리스트는 속성 내용을 담은 클러스터가 어디에 위치하였는지를 알려주기 위한 것이라 할 수 있다.

 

그림 32. Run List

  런리스트를 해석하는 방법의 위의 그림과 같다. 첫 바이트를 읽어 일의 자리 수와 십의 자리수로 나눈다. 그 다음 일의 자리 수만큼 뒤의 바이트를 읽고 이것이 해당 클러스터의 길이가 된다. 십의 자리 수만큼 바이트를 이어 읽으면 해당 클러스터의 위치 값을 알 수가 있다. 이해하기 쉽게 직접 해석해보자.

그림 33. Run List

  위의 그림은 내 PC의 MFT Entry 중 비거주 속성의 런리스트를 나타낸 부분이다. 검은색 동그라미가 첫 바이트이며, 붉은 색은 런의 길이, 파란 색은 런의 위치를 나타내기 위해 표시해놓은 것이다.

  첫 번째 런의 첫 바이트는 '33'이다. 이를 십의 자리와 일의 자리로 나누면 십의 자리는 각 각 '3'이 된다. 따라서 둘 다 3바이트씩 읽은 것이다. 이를 해석하면 C00000 클러스터에서부터 C820개의 클러스터가 할당되어 있음을 나타내는 것이다.

  두 번째 런은 앞과 유사하므로 생략하고 세 번째 런을 보자. 십의 자리가 '4' 일의 자리가 '2'임을 알 수가 있다. 따라서 런 길이는 2바이트를 읽어 0x308이며 런 위치는 4바이트를 읽어 124727B 클러스터이다. 이렇게 런리스트를 해석하면 비연속적으로 저장된 데이터를 올바르게 찾아갈 수가 있다.

  이를 찾아갈 때 고려해야 할 것은 2번째 런부턴 앞의 이전의 런위치를 더해야 한다는 것이다. 2번째 런을 예로 들면 런 위치가 57E23D 번째 클러스터에 있음을 알 수가 있는데, 정작 57E23D 클러스터를 확인해보면 올바르지 않게 되어 있다. 올바르게 찾아가기 위해선 57E23D에 C0000을 더해야 한다. 따라서 63E23D 클러스터에 올바른 속성 내용이 위치하고 있다는 것이다.

  이러한 비거주 속성은 보통 파일의 크기가700Bytes 보다 더 클 경우에 속하게 되며 이보다 작을 경우엔 거주 속성이 된다. 주로 $DATA의 경우 비거주 속성을 띄는 경우가 많으며 우리가 목적으로 하는 $MFT 또한 이러한 비거주 상태에 속하므로 클러스터 런을 올바르게 해석할 수 있어야 한다

  

4.6 Attribute - $SIA, $FN, $DATA

 

$STANDARD_INFORMATION

  $SIA는 $FN과 같이 모든 MFT Entry에 기본적으로 포함되는 속성으로 파일의 시간 정보와 파일에 대한 정보 등이 기록되어 있다. 전체적인 구조는 아래와 같다.

그림 34. $SIA 구조

 

$FILE_NAME

  $FN은 해당 MFT Entry가 가리키고 있는 파일에 대한 이름을 포함하여 $SIA에도 있었던 시간 정보들이 존재한다. 하지만 $SIA의 시간정보에 비해 상대적을 변경 되는 경우가 적다. 이에 대해선 나중에 더 자세히 학습하자. $FN의 구조는 아래와 같다.

그림 35. $FN 구조

 

$DATA

  마지막으로 알아볼 $DATA 속성에 대해선 조금 더 자세히 알아보자. 위의 두 가지 항목은 파일에 대한 정보를 나타내는 것이었다면 $DATA는 해당 파일의 실제 내용으로 앞의 두 개와 마찬가지로 중요한 속성이다. 우선 구조를 먼저 살펴보자.

그림 36. $DATA 구조

  구조가 상대적으로 매우 단조로워 보인다. 만약 $DATA 속성의 크기가 작다면 속성 헤더(공통헤더와 거주속성헤더) 뒤에 바로 속성 내용이 나오게 된다. 하지만 만약 속성의 크기가 커지면 비거주 상태가 되어 위에서 살펴본 바와 같이 클러스터 런을 통해 속성 내용을 관리한다.

 만약 $DATA 속성이 2개라면 어떻게 될까? 이것이 바로 ADS다. 기존의 메인 스트림 외에 대체 스트림이 하나 더 주어지는 것으로 이 경우 반드시 속성 이름이 주어진다. 이를 통해 추후에 $UsnJrnl:$J를 분석할 때 참고할 수가 있을 것이다.

  이번 문서의 목적은 Python을 통해 $MFT를 수집하는 것이므로 일반적으로 크기가 큰 $MFT가 많기 때문에 대부분 비거주 상태에 있다. 따라서 이러한 $DATA의 클러스터 런을 잘 해석할 수가 있어야 할 것이다.

  

4.7 $DATA - Python

  올바르게 속성 식별 값 0x80($DATA)를 찾았다면 이제 해당 부분을 분석하여 정보를 추출을 위한 정보를 알아내야 한다. 우선 Runlist의 위치와 해당 버퍼를 담아보자. 아래의 그림에서와 같이 $DATA의 구조를 읽어 런리스트의 위치와 런리스트부터의 버퍼를 담고 있는 것을 확인할 수가 있다.

그림 37. $DATA 분석 – Python

  $MFT의 $DATA 속성의 경우 비거주 속성을 가질 수 밖에 없다. $MFT가 700바이트 이하의 크기를 갖기는 많이 어렵기 때문이다. 런리스트를 반복문을 통해 분석하기 전에 필요한 변수들을 먼저 선언해주자.

그림 38. 변수 선언

  Count와 tmp, calc, add_offset 등은 반복문에서 대부분 첫 번째 런을 위하여 존재하는 것이며 clu_size와 clu_off, tmp_size와 tmp_offset은 런을 해석한 결과를 담기 위해 미리 리스트(배열)을 선언해놓은 것이다. 이제 반복문을 통해 분석을 진행해보자.

그림 39. 반복문 – 분석

  2번째와 3번째 라인은 이전에 선언해놓은 tmp='00'을 십의 자리와 일의 자리로 나누어 계산을 진행하는 것으로 이후에 tmp가 런의 첫 바이트를 읽어 다시금 자리 수를 나누기 위함이다.

  6번째 라인이 런의 첫 바이트틑 읽는 것으로 이후에 clu_size와 clu_off를 위해 몇 바이트씩 읽어야 하는지 나타내기 위해 존재한다. 그 후 tmp_들로 인하여 해당 바이트의 값을 읽고 있는 것이다. 그리고 add_offset을 통해 4.5에서 살펴본 것과 같이 클러스터 런의 오프셋을 더하기 위한 부분이다. 이렇게 반복문이 0x00을 만나 빠져나오면 tmp_에 담겨있는 값을 다시 정리하여야 한다. 이를 위한 코드는 아래와 같다.

그림 40. Tmp 정리

  이전에 tmp에 담겨있는 것을 정리하기 위해 각각 size와 offset을 선언해준다. 그 후 반복문을 통해 클러스터 단위가 아닌 바이트 단위로 나타내기 위하여 tmp의 값에 초반에 구했던 sec과 clu를 곱해준다.

  이렇게 얻어진 값을 통해 기록하고자 하는 파일을 연다. Seek() 함수를 통해 해당 클러스터의 오프셋으로 이동해 사이즈만큼 읽고 이를 기록한다. 이렇게 런의 수만큼 반복이 된다. 최종적으로 완성된 코드를 실행하면 결과는 아래의 그림과 같다.

그림 41. 실행 결과

 

 

 

5. 정리


간단하게 $MFT 수집 도구를 만들고 싶었지만, $MFT를 수집하기 위해선 결코 간단한 지식을 가지고는 수집할 수 없겠다는 것을 여러 번 느끼는 계기가 되었다. 이해했다고 생각했던 것들이 코드를 통해 직접 해보려 하니 낯설기도 하고 더 어렵게 느껴지기도 하였다.

 

그래도 직접 NTFS를 공부하면서 만들어보고자 했고, 결국 만들었음에 매우 흡족하다. 이후엔 $LogFile과 $Usnjrnl:$J까지 한번에 수집해주는 도구를 제작해보고자 한다. 이를 위해선 더 많은 것을 공부해야겠지만 분명 재미있는 공부가 될 것이라 생각한다.

 

 

 

 

참고 자료


해킹대회문제로 배우는 파일시스템.pdf

humanistcpu.blogspot.kr/2013/10/hxd-mbrmaster-boot-record.html ; HxD MBR 구조 분석

cappleblog.co.kr/40; MBR 구조

cappleblog.co.kr/590; MBR 해석

forensic-proof.com/archives/2975 ; 시스템 예약 파티션 관련 내용

forensic-proof.com/archives/357

forensic-proof.com/archives/431

http://home.sogang.ac.kr/sites/gsinfotech/study/study1702/Lists/b10/Attachments/17/20131212_%EC%B9%A8%ED%95%B4%EC%8B%9C%EC%8A%A4%ED%85%9C%EB%B6%84%EC%84%9D.pdf

http://ntfs.com/ntfs-partition-boot-sector.htm

(FP) NTFS.pdf

forensic-proof.com/archives/584



'Forensic > Analysis' 카테고리의 다른 글

문서파일 복사,복사 여부 확인  (3) 2016.01.23
노트북 하드 컴퓨터 연결  (2) 2016.01.03
Tigger Memory Analysis  (0) 2015.12.26
Black Energy 메모리 분석  (0) 2015.12.17
Memory Analysis - CoreFlood  (0) 2015.12.05

MFT - Attribute

$STANDARD_INFORMATION ($SIA)

 모든 파일에 기본적으로 존재하는 속성이다. 기본적으로 존재하는 속성인 만큼 파일의 시간정보, 파일 특성, 소유자 및 보안 ID 등의 기본적인 속성 정보를 가지고 있다. 속성 타입 번호는 0x10(16)임을 이전에 확인할 수가 있었다. 속성의 크기는 윈도우 버전에 따라 조금 상이한데 윈도우2000,XP이상(72바이트), 윈도우NT(48바이트)를 갖는다. 이제 구조에 대해서 한번 살펴보자. 

속성 헤더가 먼저 나온 뒤 $STANDARD_INFORMATION의 속성내용들이 나오는 것을 확인할 수가 있다. 각 항목에 대한 설명은 아래의 표와 같다.


 위의 그림은 실제 내 PC $MFT의 내용이다. 이를 해석하면 다음과 같다. 우선 생성 시간, 수정시간, MFT수정시간, 마지막 접근 시간이 모두 같은 것을 확인할 수가 있다. 이는 $MFT가 생성된 시점으로, 즉 포멧된 후의 시점이라는 것이다. 이를 통해서도 언제 포멧을 했는지 알 수가 있다.

 시간 값 8 바이트를 변환하면 Wed, 29 July 2015 11:41:01 +0900 이라는 것을 알 수가 있다. 플래그에 대해 알아보면 0x06임을 알 수가 있다. 이는 시스템 파일과 숨긴파일이라는 것을 알 수가 있다. 그외에 버전 최대값, 버전 번호, 클래스ID, 소유자 ID, Quota Charged는 사용하지 않는 것을 확인할 수가 있으며 보안 ID는 0x100임을 확인할 수 있고, 마지막으로 USN이 0임을 알 수가 있다.



$FILE_NAME ($FN)

 자주 쓰이는 속성 중 하나인 $SIA에 대해 위에서 알아보았다. 이제 또 다른 하나인 $FILE_NAME에 대하여 알아보자. $FN은 파일의 이름을 저장하기 위해 존재하며 다양한 부가 정보들이 저장되어 있다. NTFS에선 빠른 탐색을 위해 만들어 둔 인덱스 구조인 $I30에도 저장되며 일반적으로 파일 이름 변경을 제외하고는 $I30 인덱스의 $FILE_NAME 속성만 갱신한다. $FN의 구조는 아래의 그림과 같다.

 $MFT의 $FN 속성의 모습이다. 공통헤더와 Resident헤더가 존재하고 그 뒤부터 부모 디렉터리의 파일 참조 주소를 시작으로 속성내용이 시작 나온다. 우선 붉은 색의 8바이트 0x00050000000005는 루트 디렉터리의 MFT 엔트리 번호이며 생성, 수정, MFT수정, 마지막 접근 시간은 모두 같은 것을 확인할 수가 있으며 이는 변환하면 Wed, 29 July 2015 11:41:01 +0900 임을 알 수가 있다.

 해당 파일이 할당된 크기는 0x0000000000004000으로 크기는 4 KB로 할당되었던 것과 실제 사이즈도 4KB임을 확인할 수가 있다. Flags의 값은 $SIA에서 보았듯이 시스템파일과 숨긴파일이라는 것을 알 수가 있다. 해당 속성의 Reparsepoint는 없는 것을 확인할 수가 있으며 파일 이름의 길이가 4인 것과 표현 방식이 Win32&DOS인 것을 확인하고 마지막에 해당 이름의 16진수 값인 $MFT가 유니코드의 형태로 나타나는 것을 확인할 수가 있다.


$SIA & $FN - Time Stamp 

$SIA와 $FN 둘 다 4가지 시간 값을 갖는다. 생성시간, 수정시간, MFT Record 업데이트 시간, 최근접근시간이 존재하는데 이 두개의 속성은 약간의 차이를 갖는다. $SIA는 생성시간을 제외하고 모두 업데이트를 한다. 이에 반해 $FN은 폴더/파일 생성시 동일한 시간을 기록하고 다시 변경하지 않는다(단, 폴더 이름 변경 시 예외 - 폴더 이름 변경시 원래 $SIA의 시간과 같게 Update한다.).


$DATA

 $DATA는 파일의 데이터를 저장하는 속성이다. 파일의 데이터가 약 700 Byte 이상이면 Non-Resident로 저장된다고 이전 포스팅을 통해서 확인할 수가 있었다. 이 경우 별도의 클러스터를 할당 받아 데이터를 저장하며 이를 클러스터 런을 통해 관리한다는 것을 살펴보았다. 만약 Resident라면 속성 헤더 이후에 바로 속성 내용인 파일 데이터 스트림 위치가 나온다. 

 하나의 파일에서 $DATA 속성을 2 이상 가질 수가 있는데 이를 ADS라 한다. ADS에 대해선 이전에 http://kali-km.tistory.com/entry/ADS 에서 설명을 하였으므로 자세한 설명은 하지 않겠다. 다만 ADS는 반드시 속성 이름을 가지고 있어야하며, ADS 속성은 파일크기에 포함되지 않는다는점, ADS에 악의적인 데이터를 숨길 수가 있다는 점과 마지막으로 폴더가 $DATA를 갖는 경우도 일반적이지 않으므로 유의하여야 한다.


ADS

좌측의 그림은 XXX##xxx.txt라는 파일을 생성한 뒤 해당 MFT를 찾은 것이며, 우측은 해당 파일에 'ads-km'이라는 이름의 ADS를 추가한 것이다. 그림을 통해 차이를 확인할 수가 있다. 우선 차이나는 부분은 우측의 붉은 부분을 통해 표시하였으며 파란 상자는 속성 식별값이 위치한 것이다.

 그림에서와 같이 기존의 파일은 $SIA, $FN, $DATA와 같이 기본적인 3가지 속성을 가지고 있지만, 우측은 4개의 속성을 가지고 있는 것을 확인할 수가 있다. 우선 위에서부터 차이나는 점에 대해 하나 하나 짚어보자.

 MFT Entry Header에서는 $LogFile Sequence Number(LSN)의 값이 변한 것으로 이는 $LogFile에 존재하는 해당 파일의 트랜잭션 위치 값이 변화했음을 의미한다. 그 다음 0x168에서 0x1A0로 변한 것은 사용하는 MFT Entry 크기가 360 Byte에서 416 Byte로 증가했음을 의미한다. 다음 속성 ID 값도 변화한것을 볼 수가 있다. 이제 0x30 부분을 보면 0x05에서 0x0C로 변화한것은 데이터 무결성을 판단하기 위해 존재하는 Fixup Array이다. 이 Fixup Signature의 값 또한 변화하였음을 확인할 수가 있고 각 섹터의 마지막 2 Byte도 변화했다는 것을 알 수가 있다.

 이제 Attribute 부분에 대하여 알아보자. 우선 0x10인 $SIA에서 생성 시간과 접근시간은 그대로 인것을 확인할 수가 있다. 하지만 파일의 수정 시간과 MFT Entry 갱신 시간은 변화하였음을 알 수가 있다. 또한 USN의 값도 변화한 것을 확인할 수가 있다. $FN은 $SIA와는 다르게 시간 값에도 아무런 변화가 없음을 확인할 수가 있다.

 첫 $DATA 속성을 보면 별 다른 변화가 없지만, MFT Entry의 End Marker인 "0xFFFFFFFF"이 더 뒤로 밀려났다는 것을 확인할 수가 있다. 그 외에 $DATA 속성은 변화가 없다. 하지만 이제 새로 추가된 $DATA는 기존의 메인 스트림에 더해 추가적으로 생성된 것으로 새로운 속성 값을 갖는다. 정확히 첫 $DATA의 End Marker가 있던 곳부터 시작하는 것을 확인할 수가 있다.

 여기서 ADS는 반드시 속성 이름을 갖는다고 말하였다. 그렇기에 속성의 공통 헤더에서 속성의 이름 길이가 6으로 지정된 것을 볼 수가 있고, 실제 이 ADS의 이름은 'ads-km'과 같이 6글자로 지정되었다. 이름이 존재하기에 해당 이름이 나타나는 것을 확인할 수가 있고 이름이 끝난 뒤 해당 속성의 내용(ADS에 기록된 내용)인 'This is ADS'가 존재하는 것을 확인할 수가 있다. 이 뒤에 End Marker가 나오는 것 또한 확인할 수가 있다.



출처 및 참고

http://forensic-proof.com/archives/600



'Forensic > Theory' 카테고리의 다른 글

NTFS File System (7) INDEX  (0) 2016.01.02
Cluster Run 직접 확인해보기 - MFT엔트리찾기  (0) 2015.12.31
NTFS File System (5) MFT -Attribute  (0) 2015.12.30
NTFS File System (4) MFT  (0) 2015.12.29
NTFS File System (3) VBR  (0) 2015.12.29

MFT - Attribute

속성 종류

 MFT Entry Header, Fixup Array에 이어 이번에는 Attributes에 대하여 알아보자. Attributes는 각 파일의 메타정보를 표현하고 있으며 Attribute Header + Attribute Content로 구성되어 있다. 크기에 따라 Resident와 Non-Resident 속성으로 구분하며 총 17가지의 속성이 있다. 이러한 속성은 각 각 다른 Header를 가지며 기본적으로는 $STANDARD_INFORMATION, $FILE_NAME, $DATA를 가진다. 아래의 그림과 같다.

 이러한 속성은 Fixup 배열 이후 End Marker가 올 때까지 연속적으로 오며 각 속성은 위에서 말한 바와 같이 속성헤더와 속성 내용으로 나뉘어진다. 우선 속성 헤더와 속성내용에 대하여 알아보기 전에 속성의 종류에 대하여 먼저 알아보자.

일반적인 파일의 경우 위에서 말한 바와 같이 $STANDARD_INFORMATION, $FILE_NAME, $DATA를 가진다고 이야기 하였다. 따라서 3가지 속성에 대해서만 잘 알고 있어도 대부분의 파일을 분석할 수 있다. 아래의 그림을 보자.

현재 내 PC의 MFT를 나타낸 것이다. MFT Entry Header에서 속성이 시작되는 위치는 0x38이라 나타나있다. 해당 부분을 보면 속성 식별 값이 0x10으로 이는 $STANDARD_INFORMATION을 나타내고 있으며 뒤로 가다 보면 0x30으로 $FILE_NAME 속성 식별 값이 존재하는 것을 볼 수가 있다. 이러한 식별 값을 통해 어떤 속성인지 확인할 수가 있다.

Resident 속성과 Non-resident 속성

 이제 크기에 따른 분류로 Resident 속성과 Non-resident 속성이 있다하였는데 이에 대하여 조금 더 알아보자. Resident 속성은 속성의 내용이 Attribute Header (속성 헤더) 바로 뒤에 위치하는 속성이다. 이에 반해 Non-resident 속성은 Attribute Content(속성 내용)이 너무 크기 때문에 MFT엔트리(1024Byte) 내부에 넣지 못할 경우, 별도의 클러스터를 할당 받아 저장(클러스터 런으로 관리)하는 방식이다. 이때, 속성 내용 위치에는 할당 받은 클러스터의 위치 정보가 저장되어 있다.

 대부분의 속성은 모두 Resident 속성이고, $DATA, $ATTRIBUTE_LIST와 같은 속성은 Size가 크기 때문에 Non-resident가 될 수 있다. $DATA는 파일의 내용을 표현하는 속성인데, 파일의 내용이 MFT 엔트리 내에 저장되지 못한다면 Non-resident 속성이 된다. 대부분의 파일 크기가 크므로, 일반적으로 700바이트 이하가 아니라면 대부분 $DATA 속성은 Non-resident 로 존재한다.

위 그림은 3번째 속성이 Non-resident 인 것으로, 1,2번 속성과는 다르게 속성내용(Attribute Content)의 위치에 Cluster가 위치해 있다. 이러한 클러스터는 해당 속성 내용을 담고있는 부분을 별도의 곳에 놓아둔 것이다.

 같은 파일 2.txt이지만 690 바이트일때는 디스크에서 크기를 차지하지 않았지만 698 바이트가 된 뒤에는 1 Cluster 만큼의 크기를 차지하는 것을 확인할 수가 있다. 이는 기존의 2.txt는 $DATA에 모두 담을 수 있었지만, 크기가 커지며 별도의 클러스터를 할당하므로 이러한 데이터를 관리하려고 했기 때문에 하나의 클러스터가 할당된 것이다.

 다시 돌아와 속성에는 속성헤더와 속성내용이 있다하였다. 이제 이 중에서 속성헤더의 구조를 한번 살펴보자. 속성은 위에서 말한 바와 같이 크기에 따라 구분되는데 이 경우 구조가 서로 다르다는 점이다. 우선 Resident와 Non-resident 모두에 쓰이는 공통적인 속성 헤더를 살펴보자.


Attribute Header Format

 공통적으로 포함되는 구조는 아래의 그림과 같다. type ID와 속성의 길이를 나타내는 등의 정보가 있다.

 Attribute type ID는 속성 타입 식별 값으로 위에서 0x10이 $STANDARD_INFORMATION이였던것과 같은 값을 나타낸다. Length of attr은 속성 헤더를 포함한 속성 전체의 길이를 나타내며 Nreg Flag(Non-resident flag)는 해당 속성이 Non-resident 속성인지의 여부를 나타내며 0일 경우 Resident이며 1일 경우 Non-resident임을 알 수 있다. LenNam(Length of name)은 해당 속성 이름의 길이를 나타내고 이러한 속성 이름이 저장된 곳의 시작 위치를 Offset to name이 가지고 있다. 속성헤더 내에 있는 Flags는 속성의 상태를 표현하는데 0x0001은 압축된 속성, 0x4000은 암호화된 속성, 마지막 0x8000은 Sparse 속성을 나타낸다. 마지막 값인 Attr ID는 속성의 고유한 식별자로 MFT Entry에 같은 속성이 여러 개일 경우 구별하기 위해 사용한다.  

 위의 그림과 같이 MFT 엔트리 헤더에서 Offset to First attribute 값을 통해 0x38로 온 후다. 이를 해석해보면 우선 속성 식별 값이 0x10으로 이는 $STANDARD_INFORMATION 임을 알 수가 있다. 속성 헤더를 포함한 속성 전체의 길이는 0x60으로 0x98에선 다음 속성의 식별 값이 나와야 한다. 해당 속성은 현재 Resident이며 속성 이름이 존재하지 않기에 해당 위치 0x38 + 0x18 인 0x50부터 바로 속성 내용이 시작된다. 상태플래그는 0이며 속성 식별자 또한 0이다.


Resident Attr Header

 Resident(거주) 속성의 헤더는 위의 공통된 속성 헤더 뒤에 다음과 같은 구조를 가지고 있다. 아래의 그림을 보자.

Size of Content는 헤더 뒤에 오는 속성 내용의 크기를 나타내며 Offset to content는 속성 내용이 시작하는 곳의 위치를 나타낸다. idx flag(Indexed flag)는 값을 "1"로 가질 경우 인덱스된 속성임을 뜻하며 $FILE_NAME의 경우 "1"로 설정되어있다. 마지막 Attr Name은 속성 이름이 있는 경우 속성 이름을 나타내고 없는 경우엔 바로 속성 내용이 온다.


 공통된 헤더를 제외하고 0x48부터 resident attr header가 위치한 것을 볼 수 있다. 우선 속성 내용의 크기는 0x48이며 속성 내용의 시작 위치는 0x18로 공통 속성헤더를 기준으로 0x18뒤에 속성 내용이 시작된다는 것으로 보라색 박스와 같이 표시하였다. Index 플래그는 설정되어 있지 않으며 마지막 한 바이트는 사용되지 않는 값이다. 


Non-resident Attr Header

 Non-resident(비거주) 속성의 헤더 역시 공통된 속성 헤더를 지닌다. 그 뒤의 구조는 다음과 같으며 이에 대해선 표로 설명하겠다.

 Non-resident는 속성 내용이 외부 클러스터에 저장되어 있으므로 해당 클러스터 정보를 담고 있는 런리스트의 정보가 필요하다. 여기서 VCN은 특정 파일의 첫 번째 클러스터부터 순차적으로 부여한 번호로 $DATA 속성의 경우 데이터가 매우 많이 조각나 있을 경우 클러스터 런의 정보를 저장하기 위해 하나 이상의 MFT 엔트리를 사용하게 된다. 이때, 런리스트의 시작과 끝을 표현하기 위해 VCN을 쓴다.

* LCN : 볼륨의 첫 번째 클러스터부터 순차적인 번호 / VCN : 파일의 첫 번째 클러스터부터 순차적인 번호


우선 런리스트 시작VCN이 0임을 알 수가 있고, 끝 VCN이 0x02803F임을 알 수가 있다. 이러한 런리스트의 시작 위치는 0x0040이며 압축 속성이 아니기 때문에 압축 단위 크기는 0이된다. 속성 내용 할당 크기(클러스터크기)는 0x28040000(671350784)이며 속성 내용 실제 크기도 0x28040000(671350784), 그리고 속성 내용의 초기화된 크기도  0x28040000(671350784)인 것을 확인할 수가 있다. 이 경우 속성의 이름이 존재하지 않는 것 또한 같이 확인할 수가 있다.

런리스트 끝VCN이 0x02803F이라는 것은 현재 $MFT 속성 내용을 표현하기 위해 0x02803F + 1개의 클러스터를 사용하고 있다는 것이다. 0x028040에 클러스터 크기 4096을 곱해주면 0x28040000으로 이는 속성 내용 할당 크기와 일치하는 것을 알 수가 있다.

* 꼭 기억해야할 점은 속성 이름의 경우, 속성 이름이 존재하는 경우에만 해당 헤더 영역이 할당된다는 점이다. 속성 이름이 없는 경우 해당 영역을 제외하고 바로 속성 내용이 뒤따라 온다.


Cluster Runs (클러스터 런)

 속성이 Non-resident인 경우 별도의 클러스터를 할당 받아 내용을 저장한다고 했다. 할당 받는 클러스터가 내용의 크기에 따라 하나에서부터 수천개까지 될 수 있다. 이 클러스터들은 연속적으로 할당 될 수 있지만, 대부분 비연속적으로 할당된다. 이렇게 비연속적으로 할당된 클러스터들을 효과적으로 관리하기 위한 것이 클러스터 런이다. 다음은 클러스터 런을 표현하는 런리스트(Runlist)의 예를 그림으로 나타낸 것이다.

첫 바이트를 읽어 2개의 용도로 사용하는 것이다. 가령 첫 바이트가 '0x32'인 경우 런 길이는 2바이트를 읽어야하며, 런 오프셋은 3바이트를 읽어야 한다는 것이다. 말로만 해서는 어려우니 아래의 그림을 참고하자.

 첫 번째 클러스터 런의 첫바이트가 '33' 이므로, 오프셋 3바이트와 길이 3바이트를 읽어야 한다. 먼저 길이의 경우 바로 2번째 바이트부터 나오며 첫번째 바이트에서 뒷자리가 3이므로 총 3바이트 읽어 0x00C820이 된다. 오프셋은 첫바이트의 앞자리가 3이므로 3바이트를 읽어 0xC00000이 된다. 이는 Offset 0x0C0000번 클러스터부터 0xC820(51232)개의 클러스터가 할당되어 있음을 나타낸다.

 두 번째 클러스터 런은 첫바이트가 똑같이 33이므로 위와 같으며 이는 오프셋 0x57E23D 클러스터부터 0xEA1B(59931)개의 클러스터가 할당되어 있음을 나타낸다.

 세 번째 클러스터 런은 첫바이트가 '42'이다. 클러스터의 길이는 첫바이트의 뒷자리가 2이므로 2바이트를 읽어 0x0308이 되며 오프셋은 앞자리가 4이므로 4바이트를 읽어 0x0124727B가 된다. 이는 0x0124727B 클러스터에서부터 0x308(776)개의 클러스터가 할당되어있음을 알 수가 있다.

* 수정 : 첫 번째 클러스터위치인 C0000클러스터는 해당 오프셋 0xC0000000이 맞지만, 두 번째 클러스터 런인 57E23D는 0x57E23D000이 아닌 여기에 앞의 클러스터 값을 더해주어야 한다. 따라서 +0xC0000000을 해야한다. 세 번째부터는 마찬가지로 앞의 두개를 더해주어야한다.

 이렇게 총 5개의 클러스터 런이 형성되어 있는 것을 확인할 수가 있으며 각 클러스터 런의 길이를 모두 더해보자. 그러면 0x28040이 나오며 10진수로는 163,904개의 클러스터가 형성되어있다는 것이다. 여기서 하나의 클러스터는 크기가 4KB이므로 4를 곱해주면 655616이 된다. 이를 이제 1024로 나누어주면 640MB가 되며 이는 현재 $MFT 파일의 크기와 같음을 알 수가 있다.

 이렇게 대부분의 파일은 $DATA의 값이 크기 때문에 Non-resident이며, 이는 클러스터 런을 가지므로 각 각 떨어져 있는 클러스터들의 위치를 알 수가 있었다. 이해가 잘 안된다면 바로 위의 예제처럼 직접 파일의 크기와 함께 맞추어 보는 것도 하나의 좋은 방법인 것 같다.

 또한 클러스터 런을 활용하면 $MFT 파일을 쉽게 수집할 수가 있다. $MFT는 NTFS에 존재하는 모든 파일의 메타 정보를 가지고 있기 때문에 메타 정보만을 가지고 포렌식 분석을 수행하고자 할 경우, $MFT 파일을 수집하는 것이 필요하다. $MFT 파일의 MFT 엔트리도 $MFT에 있으므로, $MFT에서 $MFT 파일의 MFT 엔트리를 찾은 후, 해당 엔트리의 데이터 속성의 런리스트를 확인한다. 그리고 런리스트의 정보대로 데이터를 읽어서 연결하면 하나의 $MFT 파일이 된다.



출처 및 참고

http://forensic-proof.com/archives/590

http://forensic-proof.com/archives/596


'Forensic > Theory' 카테고리의 다른 글

Cluster Run 직접 확인해보기 - MFT엔트리찾기  (0) 2015.12.31
NTFS File System (6) MFT $SIA & $FN $DATA  (0) 2015.12.31
NTFS File System (4) MFT  (0) 2015.12.29
NTFS File System (3) VBR  (0) 2015.12.29
NTFS File System (2) MBR & EBR  (0) 2015.12.29

4. MFT


NTFS File System (1) ~ (3)을 통해 MBR(혹은 EBR)을 지나 해당 파티션의 VBR을 찾을 수가 있었다. 이러한 VBR에서 BPB를 참고하여 $MFT의 위치까지 찾아보았다. 이제 이러한 MFT에 대하여 설명을 하고자 한다.

 MFT는 Mater File Table의 약자로 NTFS에선 파일이나 디렉터리, 메타 정보를 모두 파일의 형태로 관리하고 있다. 이러한 각 파일의 위치나 속성, 이름, 크기 등의 메타정보는 MFT Entry라는 특별한 구조로 저장된다. MFT는 NTFS 상에 존재하는 모든 파일의 MFT Entry의 모음으로 아래의 그림과 같이 나타낼 수 있다.


 위의 표와 같이 각 엔트리의 번호와 기능에 대하여 설명할 수가 있다. 이러한 각 각의 엔트리는 MFT Entry Header, Fixup Array, Attributes, End Marker, Unused Space로 구분되는 구조를 갖는다. End Marker 이후의 값은 MFT Entry에서 사용되지 않는다. 이를 그림으로 나타내며 아래와 같다.


MFT Entry Header

이러한 각 항목 중 먼저 MFT Entry Header에 대하여 설명해보자. MFT Entry Header는 모든 MFT Entry의 앞 부분에 위치하는 48Byte의 정보로 그림과 표를 통해 좀 더 자세히 설명하겠다. 아래의 그림과 같이 첫 부분에 MFT 시그니처인 'FILE'로 시작하여 Fixup Array 전 까지의 구조를 갖는다.

이를 토대로 현재 PC의 $MFT의 MFT Entry Header를 확인해보자.

Fixup

 Fixup은 MFT Entry의 데이터 무결성을 판단하기 위해 존재한다. MFT 엔트리는 각 2개의 섹터(1024Byte)를 사용하는데 각 섹터 마지막에 2 Byte를 이용해 Fixup Array로 사용한다. 섹터의 내용이 비정상적으로 변경되었을 때 오류의 체크를 가능하게 한다.

 위의 그림과 같이 Fixup Array의 Offset을 통해 0x30에 가면 해당 Signature가 존재한다. 내 PC에선 시그니처가 0x0266임을 알 수가 있고 이 시그니처는 각 섹터의 마지막 2 Byte에 위치해있는 것을 볼 수가 있다. 시그니처 뒤의 첫 2바이트(파란색)은 첫번째 섹터의 마지막 2 Byte 값이며, 다음 2바이트는 두번째 섹터의 마지막 2 Byte 값이다. 만약 Fixup이 적용되지 않는다면 각 섹터의 마지막 2 바이트는 각 각 0xFFFF과 0x0000으로 채워져 있을 것이다.

* Fixup Array의 수가 3개 인 이유는 MFT Entry가 1 KB이므로 섹터 2개를 사용하며 이에 더해 Signature가 1개 항목을 사용하므로 총 3개인 것


추가 

Sequence Value : MFT Entry를 재할당하면 이 값이 바뀌므로 내용이 바뀌었다는 것을 추측할 수 있다.


출처 및 참고

(FP) NTFS.pdf

http://forensic-proof.com/archives/584


'Forensic > Theory' 카테고리의 다른 글

NTFS File System (6) MFT $SIA & $FN $DATA  (0) 2015.12.31
NTFS File System (5) MFT -Attribute  (0) 2015.12.30
NTFS File System (3) VBR  (0) 2015.12.29
NTFS File System (2) MBR & EBR  (0) 2015.12.29
NTFS File System (1) 개요  (0) 2015.12.28

3 .NTFS - VBR


 이전 포스팅에선 MBR의 파티션 테이블(혹은 EBR)을 참고하여 해당 파티션의 위치를 찾을 수가 있었다. 여기서 필자는 NTFS를 학습하기 위함으로 FAT16, FAT32 외 다른 것들은 일단 제외하겠다. 우선 NTFS의 구조는 아래의 그림과 같다.


VBR(Volume Boot Record)와 MFT가 있으며 그리고 Data 영역이 존재하고 있는 것을 확인할 수가 있다. 우선 VBR에 대하여 먼저 이야기를 해보자. VBR은 그 크기가 고정된 것이 아니라 클러스터의 크기에 의존한다. 아래의 표와 같다.

 하지만 이전에 말했듯이 대부분의 NTFS는 클러스터의 크기가 4KB이므로 VBR의 크기는 8 Secotr(== 1cluset)가 된다.

 VBR의 구조에 대해선 아래의 그림과 같다. 

- Jump instruction : EB 52 는 어셈블리어로 JMP 0x52이며 두의 90은 NOP로 52+2 바이트 뒤인 0x54에서 Boot Code가 시작됨을 알려준다.

- OEM ID : NTFS를 나타내고 있다.

- BIOS Parameter Block (BPB) : 클러스터의 크기, 루트 디렉터리 위치, 총 섹터 등 파일 시스템 정보가 기록되어 있다.

- Boot Code : 해당 볼륨의 운영체제를 로드하기 위한 명령어가 있다.

- Signature : 0xAA55가 위치해 있다.


파일 시스템의 정보를 나타내는 BPB에 대하여 좀 더 자세히 보면 아래의 그림과 같다.




위와 같이 정리할 수가 있으며 $MFT에 접근하기 위해선 0x30의 Start Cluster for $MFT의 값을 참고한다. 한번 직접 해보자. 아래의 그림은 이전에 MBR을 통해 찾은 VBR을 나타내고 있다. 0x30의 부분은 $MFT가 있는 클러스터의 위치를 나타내는 것으로 C0000의 클러스터(현재 VBR을 기준으로) 가 있는 곳에 위치해있다고 해석할 수가 있다.


C0000은 클러스터의 값이므로 이를 이동하기 편하게 Offset으로 나타내기 위해선 [해당 클러스터값 * 클러스터당 섹터 수* 섹터크기]와 같이 계산을 하면 된다. 이를 직접 해보면 C0000 * 8 * 0x200 = C0000000 이다. 이제 이를 현재 VBR이 있는 오프셋 F38200000에 더하면 FF8200000이다. 해당 위치는 아래의 그림과 같이 나오며 MFT 파일의 시그니처인 'FILE'가 있는 것을 확인할 수가 있다.




출처 및 참고

http://forensic-proof.com/archives/431

http://home.sogang.ac.kr/sites/gsinfotech/study/study1702/Lists/b10/Attachments/17/20131212_%EC%B9%A8%ED%95%B4%EC%8B%9C%EC%8A%A4%ED%85%9C%EB%B6%84%EC%84%9D.pdf

http://ntfs.com/ntfs-partition-boot-sector.htm

(FP) NTFS.pdf

'Forensic > Theory' 카테고리의 다른 글

NTFS File System (5) MFT -Attribute  (0) 2015.12.30
NTFS File System (4) MFT  (0) 2015.12.29
NTFS File System (2) MBR & EBR  (0) 2015.12.29
NTFS File System (1) 개요  (0) 2015.12.28
KDBG Structure  (0) 2015.11.08

2. MBR


 하드디스크를 용도에 따라 여러 개의 파티션으로 나눌 수가 있다. 예를 들어 이전 (1)에 했던 포스팅에서 필자의 PC는 4개의 파티션으로 나뉘어져 있는 것을 확인할 수가 있었다. 하지만 스왑을 위한 파티션이나 윈도우 시스템 예약을 제외하면 칼리 리눅스와 윈도우가 있는 파티션 2개가 존재한다고 볼 수 있다. 이러한 각 파티션은 하나의 물리 디스크로부터 관리가 필요한데, 이러한 파티션을 MBR 구조로 관리한다.

 MBR은 저장 매체(물리 디스크)의 첫 번째 섹터에 위치하며 512Byte의 크기를 갖는다. 이는 446Byte의 Boot Code Partition Table 64 Byte, 그리고 Signature 2 Byte로 총 512Byte(0x200)의 크기를 갖는다. 여기서 64 Byte에서 하나의 파티션 마다 16 Byte로 정보를 나타내기 떄문에 총 4 개의 파티션으로 구성된다. 4개 이상의 파티션은 EBR로 관리한다.

 대략적인 컴퓨터의 부팅과정이다. 여기서 우리는 BIOS 이후 디스크의 MBR을 확인하고 부팅 가능한 파티션을 찾은 다음에 부팅을 하기 위해 VBR로 넘어가는 것을 알 수 있다. 이를 위하여 MBR의 구조에 대하여 더 상세히 알아보자. 자세하게는 아래와 같이 나타낼 수가 있다. 하지만 대부분의 문서해서는 코드 영역을 0x1BE까지로 보고 있으며 그 뒤로 파티션 테이블이 64 Bytes 마지막 Signature (0xAA55) 2Bytes로 형성되어 있다고 볼 수 있다.

 코드 영역은 흔히 Boot Code라 하며 파티션 테이블에서 부팅 가능한 파티션을 찾아 해당 파티션의 부트섹터(NTFS-VBR)를 호출하는 역할을 한다. 이제 파티션 테이블은 위에서 간략히 설명했지만 다시 설명하자면 총 64 Bytes로 16 Bytes씩 4개로 나뉘어 진다. 아래의 그림을 보자.

 그림과 같이 총 16 Bytes임을 볼 수가 있다. 각 항목에 대하여 설명을 하면 다음과 같다.


- Boot Flag : 부팅이 가능한 파티션인지 나타내는 값으로 0x80은 부팅이 가능, 0x00은 불가능을 의미한다.

- Starting CHS Address : CHS 시작 주소 위치를 나타낸다.

- Partition Type : 파티션의 종류에 따라 서로 다른 값을 같는다. ( [0x07 : exFAT, Unix, NTFS], [0x81 : Linux], [0x86 : FAT16])

- Ending CHS Address : CHS 마지막 주소 위치를 나타낸다.

- Starting LBA Address : LBA 시작 주소 위치를 나타낸다. 즉 해당 파티션이 시작되는 섹터의 위치를 나타내는 것이다.

- Size in Sector(Total Sector) : 파티션의 크기로 섹터 개수를 의미한다.

* CHS는 오래 전 주소를 나타내는 방식으로 점차 용량이 커짐에 따라 한계가 있기에 LBA(Local Block Area)로 방식을 대체하고 있는 추세이다.


 위 그림은 내 PC의 파티션 테이블을 나타내는 것이다. 총 4개의 색상으로 각 파티션을 표시하였다. 우선 부팅이 되는 부분은 Boot Flag가 0x80으로 설정되어 있는 부분으로 바로 세번째 파티션이다. 3번 째 파티션에서 Starting LBA Address를 따라 해당 섹터로 이동하면 해당 파티션이 존재한다. 따라서 세번째 파티션이 C:\여야 정상인 것이다. 하지만 해당 섹터로 가니 시스템 예약 파티션이 존재하고 있었다.

 아래의 그림은 현재 내 PC의 파티션 상태를 보여준다. 여기서 무엇인가 이상한 점이 보인다. 위의 그림에서 부팅이 가능한 것은 3번째 파티션이지만 아래의 그림과 같이 이 부분은 시스템 예약 파티션이라는 것을 알 수가 있다. 또한 실제 C:\는 00으로 설정되어있는 4번째 파티션의 주소에 위치하는 것을 확인할 수가 있었다. 왜 그런걸까? 찾아보아도 답이 나오지 않았다. 

 예상 되는 이야기는 2가지이다. 현재 나의 컴퓨터가 이상하거나 아니면 이것이 정상이라는 것. 시스템 예약 파티션은 윈도우 7부터 생성되는 영역으로 주로 비트락커 암호화를 위한 공간으로 사용된다고 한다. 그렇다면 당연히 암호화가 중요한 것이므로 저 부분을 지난 다음에 원래의 C:\를 지나는 것도 이야기가 된다. 아, 물론 지극히 개인적인 생각이니 흘려보내는 것이 지식에 좋을 것 같다. 

 다시 본론으로 돌아와 LBA를 통해 해당 오프셋으로 이동해보자. 우선 LBA addr이 0x79C1000 이므로 1섹터는 512(0x200) Bytes이므로 이 값을 곱해준다. 그렇게 나온 값은 0xF38200000으로 해당 주소로 이동해보자.

좌측의 C:\와 우측의 0xF38200000에 위치한 하드 디스크1이 모두 같은 내용임을 알 수가 있다. 이렇게 해당 파티션을 찾아갈 수가 있다.



EBR


 위에서 파티션이 4개보다 많을 경우에는 EBR을 통해서 관리한다고 말하였다. 이러한 EBR에 대해서도 알아보자. 사실 보통 사람들은 파티션을 1~4개 정도로 갖는 것이 평범하다. 하지만 5개 이상 가지고 있는 경우 헤매는 일이 발생하면 안되므로 이에 대해 학습해보자. 이 부분은 cappleblog.co.kr/590 를 중점적으로 참고하였다.


 이 분의 PC에서는 MBR을 통해 볼 수 있듯이 3개의 엔트리가 기록되어있는 것을 확인할 수가 있다. 첫 번째와 두 번째 엔트리의 경우 일반적인 NTFS의 파티션으로 위에서 내가 하였던 것과 같은 방법으로 접근하면 된다. 여기서 이 PC의 경우 파티션이 5개로 3번째 엔트리에 EBR의 위치가 나타나있는 것이다. EBR의 LBA 시작 주소가 0x8C00800 LBA 이므로 이는 오프셋 0x1180100000이 된다.

 위의 그림과 같이 해당 EBR로 이동하였다. 2개의 엔트리가 보이는 것을 확인할 수가 있는데 하나는 바로 Current Entry 정보로 바로 해당하는 EBR과 연결된 논리 드라이브에 대한 정보를 나타내며 다른 하나는 Next Entry 정보로 다음 EBR의 위치를 나타내는 것이다.

 즉, 해당 PC에선 5개의 파티션이 위치하므로 MBR에서 보았던 2개를 제외한 3개가 EBR에 존재하고 있다. 그러므로 이러한 EBR은 각 각 다음 EBR의 위치를 가리키고 있으므로 총 3개의 EBR이 존재하며, 마지막 EBR은 Next Entry에 정보가 비어있다. 만약 새로운 파티션이 추가되면 해당 부분의 EBR을 새로 가리키게 된다. EBR의 정보를 해석할 때 알아야 할 2가지 중요한 내용이 있다. 

1. Current 엔트리에서 LBA 시작 위치는 현재 자기 자신(EBR)의 위치를 기준으로 한다.

2. Next 엔트리에서 다음 EBR의 위치는 확장 파티션의 시작 위치(처음에 나온 EBR의 위치)를 기준으로 한다. 

 EBR에서 Current 엔트리는 현재 위치한 EBR을 기준으로 하면 된다. 그렇게 따라간 LBA엔 찾고자 했던 파티션의 시작 부분을 볼 수가 있다. Next 엔트리는 MBR을 통해 따라가 나온 첫 번째 EBR을 기준(위에선 0x1180100000)으로 다음 EBR이 있는 LBA가 나온다.




출처 및 참고

http://humanistcpu.blogspot.kr/2013/10/hxd-mbrmaster-boot-record.html    ; HxD MBR 구조 분석

http://cappleblog.co.kr/40      ; MBR 구조

http://cappleblog.co.kr/590    ; MBR 해석

http://forensic-proof.com/archives/2975    ; 시스템 예약 파티션 관련 내용


'Forensic > Theory' 카테고리의 다른 글

NTFS File System (4) MFT  (0) 2015.12.29
NTFS File System (3) VBR  (0) 2015.12.29
NTFS File System (1) 개요  (0) 2015.12.28
KDBG Structure  (0) 2015.11.08
[번역] Acquisition and Analysis of Windows Memory  (0) 2015.11.06

1. 개요


 파일 시스템이란 디지털 데이터를 효과적으로 관리하기 위해 파일을 체계적으로 기록하는 방식으로, 사용자에게 계층 구조로 데이터를 저장하도록 하는 방식을 말한다. 파일이 어디에 저장되어 있는지 조직화하고, 사용자의 데이터를 구조적으로 정의하도록 한다. 이는 파일을 빠르게 읽기, 쓰기, 삭제 등 기본적인 기능을 원활히 수행하도록 도와주며 사용자 영역이 아닌 커널 영역에서 동작한다.

 이론적인 내용을 먼저 설명하기 전에 직접 어떻게 생겼는지 확인해보자. 여기선 HxD를 통해 확인해볼 것이며, 관리자 권한을 통해 실행을 해야 디스크를 읽을 수가 있으므로 관리자 권한으로 HxD를 실행해보자.

 위의 그림과 같이 나타나는 것을 볼 수가 있다. 여기서 필자는 컴맹이므로 하나 하나가 모두 새로웠기에 다들 아는 이더라도 공부하면서 새로 알게 된 점까지 모두 설명할 것이다. 우선 위의 디스크 열기를 통해 확인하면 '논리 디스크'와 '물리 디스크'가 있는 것을 확인할 수가 있다. 무슨 차이인지 모른다. 내 컴퓨터에는 리눅스가 존재하긴 하지만 윈도우는 C:만 있을 뿐인데 저 물리 디스크도 C:\겠구나라고 생각했었다. 일단 둘다 열어보자.


 좌측은 위에서 '논리 디스크'라 되어 있던 '제목 없음(C:\)'를 나타내며 우측은 '물리 디스크'라 되어 있던 '하드 디스크 1'이다. 어떤 차이가 있는지를 확인해보자. 좌측은 흔히 윈도우에서 사용되는 NTFS라고 친절히 나와 있다. 우측은 왜 내가 알아 먹을 수 있는 문자열이 없는 것일까. 맨 끝으로 가서 확인해보자.


 좌측은 2C662FEFF0 까지 있지만 우측의 물리 디스크는 3B9E655FF0 까지 있는 것을 확인할 수가 있다. 즉 우측이 더 큰 용량을 가지고 있는 것이다. 이를 10진수로 변환하여 GB의 형태로 나타내면 좌측은 약 177GB, 우측은 약 238GB이다. 본인의 노트북은 256GB SSD를 사용하고 있다는 점과 약 60GB정도는 듀얼 부팅을 위한 리눅스에 사용되고 있는 용량이므로 이를 차감하면 딱 윈도우에 할당된 177GB가 나온다.

 따라서 논리 디스크라 함은 정말 C:\와 같은 부분을 나타내며, 물리 디스크는 정말 하드디스크를 통째로 나타내는 것이다. 그러므로 물리 디스크가 논리 디스크를 포함하고 있다고 볼 수가 있다. 이는 WinHex를 통해서도 확인이 가능했다.

 물리 디스크를 인식 했을 경우 HxD보다 더 상세하게 출력해주는 것을 확인할 수가 있다. 위의 그림을 보면 Start sectors부터 리눅스가 포함된 총 4개의 파티션을 볼 수가 있다. WInHex를 통해 추가로 알게 된 사실은 하나의 섹터(Sector)는 512Byte(0x200)는 것을 알 수가 있었다.

* 참고로 클러스터란 섹터를 여러 개 모아 만든 논리적인 저장 단위로, 윈도우는 파일을 저장할 때 이 클러스터 단위로 파일을 저장한다. 그렇기에 슬랙이 형성된다. 다시 말해, 디스크의 최소 저장 단위인 섹터와 운영체제의 최소 저장 단위인 클러스터의 차이로 인해 드라이브 슬랙이 발생한다.


 위의 그림은 forensic-proof.com에서 캡쳐한 것으로 이에 따르면 대부분의 NTFS에서는 4KB = 4096 Byte가 하나의 클러스터 크기이다. 위에서 한 섹터에 512Byte인 것을 확인했으므로 이를 통해 나누면 8이므로, 하나의 클러스터에 8개의 섹터가 위치하고 있는 것을 알 수가 있다.



출처 및 참고

http://forensic-proof.com/archives/357



'Forensic > Theory' 카테고리의 다른 글

NTFS File System (3) VBR  (0) 2015.12.29
NTFS File System (2) MBR & EBR  (0) 2015.12.29
KDBG Structure  (0) 2015.11.08
[번역] Acquisition and Analysis of Windows Memory  (0) 2015.11.06
How to Use Volatility  (0) 2015.10.14