직접찾아보자

 NTFS File System을 공부하며 직접 MFT 엔트리를 찾아보고 싶었다. 그렇기에 간단한 실습을 준비해보았다. 우선 바탕화면에 찾기 쉽도록 독특한 이름의 파일을 생성해야 한다 생각했으며 파일의 이름은 ^^%%&&.txt이며 $DATA의 내용도 찾기 쉽도록 ^&*^&*^&*....과 같이 하였다.

 우선 해당 MFT 엔트리를 찾기 위해 HxD를 관리자 권한으로 열어 C: 드라이브를 연다. 그러면 OEM ID - NTFS와 함께 나타나는 것을 확인할 수가 있다. 그 다음 해당 제목인 ^^%%&&.txt를 유니코드 문자열로 찾도록 한다. 그리고 검색을 시작한다. 조금 시간이 걸리기도 하며 FILE 시그니처가 아닌 다른 부분에서도 몇 번 같은 문자가 확인이 된다. 계속 지나가 FILE 시그니처와 2섹터를 가지며 해당 이름을 포함한 부분을 찾아보았다. 그렇게 찾은 주소가 063f490800 이였다. 아래의 그림을 보자.

 속성 식별 값과 속성 크기를 통해 4개의 속성 식별 값이 존재하는 것을 확인할 수가 있다. $SIA, $FN, $OBJECT_ID, 그리고 이번 포스팅의 포인트인 $DATA (Non-resident)가 있다. 다른 부분은 대체로 일반 적인 모습을 띄고 있다.

 이제 $DATA 부분을 보면 Non-resident 속성이기 떄문에 클러스터 런이 존재하는 것을 확인할 수가 있고 위의 그림과 같이 0x41이 클러스터 런의 첫 바이트이다. 이에 대한건 이전에 포스팅하였으므로 설명은 생략하고 바로 해석을 해보자.

 뒷자리가 1이므로 해당 클러스터는 1개가 있다는 것을 알 수가 있고 해당 위치는 드래그한 부분과 같이 0x01D39E47이라는 것을 알 수가 있다. 여기서 원래는 0x01D39E47에 해당 데이터가 존재하는 줄 알았는데 아니였다. 바로 볼륨의 시작에서부터 1D39E47 번째 클러스터에 위치하고 있다는 것이였다. 따라서 뒤에 000을 붙여주면 해당 오프셋이 나온다. 0x01D39E47000을 보면 위의 그림과 같이 제대로 해당 $DATA의 내용이 출력되는 것을 확인할 수가 있다. 만약 파일의 크기가 작다면 클러스터런이 아니라 $DATA의 속성헤더 뒤에 내용이 나왔을 것이다.

 이러한 NTFS에선 하나의 파일이 여러 곳에 분산되어 저장되어 있더라도 해당 파일의 MFT엔트리를 참고하여 $DATA 클러스터런을 통해 각 각 떨어진 데이터들이 연속된 곳에 저장된 것처럼 보이게 한다. 분산된 데이터를 HxD로 열면 하나로 쭉이어져있는 것처럼 출력되는 것은 운영체제가 이를 클러스터 런을 따라 출력을 해주므로 가능한 것이다. 따라서 비연속적으로 저장된 데이터는 이러한 MFT엔트리를 통해 따라가야할 것이다.

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가지 중요한 내용이 있다. 

 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    ; 시스템 예약 파티션 관련 내용

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