MBR - NTFS($DATA, Non-Resident Header)

그동안 디지털포렌식 2급 필기 시험 공부하느라 공부를 못 했다...

이제 드디어 파일시스템 공부를 다시 잡을 수 있겠구나 기쁘다.

오랜만에 보니까 가물가물 기억이 나긴한데 다시 봐보자.

지난번까지는 $FILE_NAME 속성에 대해서 분석했다.

$DATA의 속성타입ID 값은 0x80이다.

지난번 포스팅을 보아하니, Attribute들이 연속적으로 이어져서 나왔고,

이번에 $DATA도 마찬가지로 가장 최근에 포스팅한 $FILE_NAME 이후에 바로 나타났다.

기존에 공부했던대로 공통 속성 헤더부터 차근차근 분석해보자.

$DATA에서 하나 더 주의해야할 점은 이전의 포스팅에서 다룬 속성들은 Resident 속성들이지만, 

$DATA는 Non-Resident 속성 값이라는 것이다.

그러면 이번 포스팅의 개요는

1. 공통 속성 헤더

2. Non-Resident 헤더

3. Attr Content

순으로 분석하겠다.

이제 슬슬 숙달이 되었으니 캡처는 최소화하고 빠르게 진행하겠다.

이건 공통 속성 헤더이다.

이전에도 설명했듯이 16바이트로 구성된다.

---

1. 0x80 00 00 00

속성 타입 값이다. 0x80이므로 $DATA를 의미한다.

2. 0x48 00 00 00

속성의 길이이다. 0x48의 값이므로 4.5줄을 차지한다.
그러므로 0x11aa100부터 0x11aa147까지의 영역을 $DATA가 차지한다는 뜻이다.

3. 0x01

Non-Resisdent Flag로 이전에 포스팅한 $FILE_NAME이나 $STAND_INFORMATION 에서는 0x0으로 설정되어서 

Resident임을 알았다. 이번에는 0x01로 설정되었으므로 $DATA 속성은 Non-Resident 속성임을 알 수 있다.

4. 0x00

Length of Name으로 이름의 길이이다.

속성에 대한 이름이 없다. 그러므로 추후에 나올 가변적 길이의 이름 속성 이름이 없을 것이라고 유추할 수 있다.

5. 0x40 00

Offset to Name 으로 Name이 나오는 곳의 오프셋이다.

이는 공통 속성 헤더의 시작 지점이 기준을 삼으므로, 0x11aa100에서 0x40만큼 멀어진

0x11aa140에서 이름이 나올 것으로 유추할 수 있다.
(하지만 속성의 길이가 앞에서 0x48인데 이름의 오프셋이 0x40인데 이름의 길이가 0이므로 속성 내부에 이름이 나타나는 지점인 0x11aa140부터 0x11aa147까지인 공간은 사용하지 않는 영역일 가능성이 있다.)

6. 0x00 00

Flag로 속성의 상태 플래그다.
이건 뭐 맨날 0 값으로 되어있는데 0이 뭔지 진짜 궁금하네 뭘까

암호화도 아니고, Sparse 속성도 아니고, 읽기 전용도 아니고.

7. 0x06 00

속성 ID 값으로 고유 식별 ID 값이다.
(이전에는 $STANDARD_INFORMATION은 0x0
$FILE_NAME은 0x03 값을 가졌다. 그러면 $DATA가 속성 식별 값이 0x6이라면 다음에 나타날 속성은 속성 식별 값은 0x9 일 듯하다.)

 

이제부터는 Non-Resident 헤더 값이다.

Non-Resident 헤더는 총 3.5줄
0x38의 크기를 가진다.

이만큼이다.

차근차근 알아보자.

 

0x00 00 00 00 00 00 00 00

Start VCN of Runlist로 Runlist의 시작 VCN이라고 한다.
여기서 VCN을 알아봐야한다.

LCN vs VCN

Logical Cluster Number 와 Virtual Cluster Number의 차이점은 대충 생각만해도 알만하다.
LCN은 볼륨에서 클러스터 단위로 순차적으로 세는 방법이고, VCN은 볼륨에서 파일시스템에 의해서 논리적 순서를 갖게된 방법이다.

여기서 디지털 포렌식 2급 공부 중에 나왔었던 클러스터 런의 개념이 나온다.

클러스터의 시작 값은 LCN 방식 기준이고
클러스터의 길이 값은 VCN 방식 기준으로 삼는다.

LCN의 시작 값을 기준으로 VCN의 길이만큼의 공간을 할당한다.
사진처럼 200을 시작 값, 2를 길이 값으로 갖는 경우는 200번째 클러스터부터 2개의 클러스터를 할당 받으므로

200번째와 201번째 클러스터가 할당된다.

그러므로 위에서의 시작 VCN은 0번째를 시작으로 본다는 것이다.

 

0x3F 00 00 00 00 00 00 00

End VCN of the runlist로 마지막 VCN 기준 마지막 클러스터의 번호이다.
0x3F번째의 클러스터까지 $DATA 속성은 사용한다는 것이다.

0x0~0x3F 이므로 0x40의 개수를 가진다는 것.

이때 1개의 클러스터는 몇 개의 섹터를 가지는지는

https://wintersnowaaa.tistory.com/9

MBR - NTFS(VBR, MFT Header)

여기 포스팅에 있었다.
NTFS의 부트레코드인 VBR에서의 값을 살펴보면 1클러스터는 8개의 섹터를 가졌다.
사실 통상적으로 NTFS는 8개의 섹터를 1개의 클러스터에 할당하는듯하다.

그러므로 0x3F개의 클러스터는 0x40 * 8의 섹터를 가진다.
이는 512개의 섹터이고, 1개의 섹터는 512바이트이므로 262,144 바이트를 차지한다.
총 262KB의 크기를 가진다. 엄청 적다...물론 디스크를 직접 이미징 도구로 눈으로 확인하며 비교하면서 분석한다면 엄청나게 큰 크기이지만 일상에 쓰이는 파일의 크기와 비교하면 진짜 작다...

0x40 00

Offset to runlist 으로 오프셋 값이다.
속성의 헤더로부터 0x40만큼의 위치에서부터 클러스터를 할당했다.
$DATA의 속성 헤더는 공통 속성부터 시작점으로 여기므로 0x11aa100부터 0x40만큼의 위치이므로
0x11aa140부터 512개의 섹터는 모두 클러스터 할당 영역이라고 보는듯하다.
근데 이러면 겁나 커지잖아

 

0x00 00

Compression unit size으로 압축 단위 크기를 나타낸다.
0이므로 압축은 하지 않는다.

?) 근데 이게 단위가 얼마인지가 궁금하다 나중에 알아봐야겠다.

0x00 00 00 00

Unused 사용하지 않는 영역이다.

0x00 00 04 00 00 00 00 00

Allocated Size of attribute content
속성 컨텐츠의 할당된 크기이다. 즉 속성에서 헤더를 빼고 실질적인 데이터 값인 content의 값이다.
0x04 00 00의 크기를 갖는데 10진수로 바꾸면 262144 = 262KB 으로 바이트 단위로 속성 컨텐츠의 크기를 나타내는 것을 볼 수 있다. (아까 위에서 이미 계산했던 내용이다.)

0x00 00 04 00 00 00 00 00

Real size of attribute content
속성 컨텐츠의 실제 사용하는 크기이다. 할당된 크기와 같다.

0x00 00 04 00 00 00 00 00

Initialized size of attribute content
속성 컨텐츠의 초기화된 클러스터 크기이다. 할당된 크기와 같다.

 

※ 여기서 많이 헷갈렸다.

할당된 속성 컨텐츠 크기 = 데이터를 저장하기 위해 파일 시스템이 할당해준 공간의 크기

실제로 사용하는 속성 컨텐츠 크기 = 데이터를 저장하기 위해 만들어낸 파일의 크기

초기화된 속성 컨텐츠 크기 = 그 파일에 값을 넣을 때 사용한 크기

이렇게되므로 Allocated Size > Read size > Initialized size 을 기억해놓으면 더 이해하기 쉽다.

 

아 근데 왜 책에는 명시한 값이랑 사진이랑 다 다르다.

심지어 사진도 종류가 2개이다.

할당된 클러스터 영역 값

실제 클러스터 영역 값

초기화된 클러스터 영역 값

모두 다르게 나오는데 책에서는 같다고 설명하고

0xFE80000 값이라고 다 같게 나온다고해도

그런 값은 애초에 사진에도 없다...

내가 뭔가 놓친게 있는건가? 하...

.

.

새벽까지 고민하다가 자고 일어나서 계속 생각나서 구글링 더 하고 런리스트 구조에 대해서 이것저것 알아보다가
이해가 잘 안되었는데

[ Forensic ] NTFS

이 분의 포스팅을 보고 이해가 되었다.

0x21 40 AA 10 00 00 00 00

Attribute name으로 속성 이름이여야하지만? 이름의 길이는 0이였으므로
클러스터 런의 런리스트이다.

런리스트의 구조는 이러하다.

1. 첫 바이트를 4비트 씩 쪼개어준다.
그러면 2와 1로 값이 나온다.

2. 앞의 값은 Run의 오프셋 값을 몇 바이트로 표현했는지를 나타내고
뒤의 값은 Run의 길이 값을 몇 바이트로 표현했는지를 나타낸다.

3. 여기서 중요한건 첫번째 바이트 이후로 나타나는 연속된 바이트 값들 중 순차대로 설명하면
Run의 길이 값 - Run의 오프셋 순서대로 나타난다는 것이다.

4. 그러므로 뒤의 40 AA 10 00 00 00 00 의 값들 중에
40 값은 Run Cluster의 길이 (사용하는 클러스터의 개수로 VCN과 관련있다.)
AA 10 값은 Run Cluster의 오프셋 (시작하는 클러스터의 주소로 LCN과 관련있다.) 이다.

근데 궁금한건 여기서 Run Cluster의 오프셋 값이 현재 내가 보고 있는 $DATA의 헤더 시작부터의 오프셋인지
아니면 디스크의 시작부터의 값인지는 모르겠지만 포스팅에서는 파일시스템의 시작부터라고한다.

그리고 추가적으로 궁금한건 저 오프셋의 단위는 바이트인가? 아니면 섹터인가? 아니면 클러스터인가?이다.
근데 포스팅을 보면 클러스터 단위이다.

전체 디스크를 디스크 브라우저에서 눌러서 보면 디스크 내부의 운영체제가 여러개 일 수도 있고,
그러한 경우에는 각 운영체제의 파일시스템마다 클러스터의 단위가 다르므로 
클러스터 단위의 오프셋 이동이 불가능하다.
그러므로 현재 살펴보는 NTFS 파일 시스템의 디스크를 눌러주고 클러스터 단위의 오프셋 이동을 해야한다.

한번 해보면...

0xaa10000부터는 $MFT라는 MFT Entry의 $DATA 속성이 사용하는 Content 영역이다.
1개의 클러스터 = 8개의 섹터 = 512바이트 * 8 인데
이건 16*16*16이다.
그러면 1개의 줄은 0x10이고, 16개의 줄은 0x100,이고 256개의 줄은 0x1000이므로
첫번째 클러스터의 끝은 0xaa10fff라고 유추해볼 수 있다.

그러면 첫 번째 클러스터는 0xaa10000~0xaa10fff의 구간만큼을 차지한다고 볼 수 있다.

이후에는 이렇게 연속된 클러스터들이 0x40 (64) 개가 할당된다.

1개의 클러스터당 0x0001000만큼 늘어나므로 64개가 늘어난다면 0x0040000만큼 늘어난다.

그러면 마지막 클러스터는 0xaa50000이라고 유추해볼 수 있다...

아...근데 책에는 

VBR 주소값 + Run Offset * 클러스터당 섹터 = 클러스터런 위치로 계산해서
전체 물리디스크 주소값으로부터 저 방식대로하면 다른 주소값이 나온다...뭐지...?

진짜 이거 혹시 제대로 알고 계신분 제발 도와주시면 감사하겠습니다....
.
.
.
.
.
이거 뒤늦게 알아서 다시 수정.
7월2일 현재 디지털포렌식 실기 공부하면서 이런저런 질문을 통해서 답을 받았었따.

클러스터런 구조를 사용하는 NTFS 파일 시스템에서 VBR의 시작부터 (즉 볼륨의 시작부터) 클러스터 단위로 숫자가 매겨진다.
0,1,2,3....이런식으로말이다.
그러면 Run list 구조에 있는 VCN 주소는 클러스터 번호에 해당하는 곳에 데파일의 데이터가 위치해 있는 것이다.

파일시스템 4_3 NTFS 속성

NTFS 파일 시스템 - (2)MFT

 

NTFS – $DATA 속성 | FORENSIC-PROOF