MBR - NTFS($FILE_NAME)

이번에는 $FILE_NAME이다.

이전의 $STANDARD_INFORMATION은 공통속성헤더 이후에 나타났으며, 0x10의 값을 시작 지점에 갖고 있었다.

이번에 알아볼 $FILE_NAME은 0x30의 값을 시작 지점에 갖게 된다.

$STANDARD_INFORMATION은 0x10을 포함한 데이터의 크기가

Common Attr Header(0x10) + Attr Header(Resident) (0x8) (속성 이름이 있다면 0x10) + Attribute Content (0x48)

으로 0x10 + 0x8 + 0x48 = 총 0x60의 크기를 가졌었다.

이번에 알아볼 $FILE_NAME 또한 Resident 속성에 해당하며,

구조는 위와 같다.

이렇게 구성되는듯하다. (뒤의 Name은 나중에 계산하려고 뺏다.)

근데 대충 보면 뒤에 MFT라고 나온 문자열부분이 Name에 어느정도 연관 있다는 것을 알 수 있다.

그리고 중요한건 0x11aa11aa0a0의 값이 0x0으로 Resident 속성임을 알 수 있으므로 제대로 표기한 듯하다.

이제 $FILE_NAME의 구조를 살펴보자.

$FILE_NAME은 $STANDARD_INFORMATION 처럼 

4개의 시간 정보가 있다.

위의 사진을 다시 가져와서 확인해보면

앞의 0x10은 공통 속성 헤더

0x8은 Resident 헤더

0x42 + @ 의 크기가 Attr Content 이다.

일단 먼저 공통 속성 헤더부터 확인하자.

 

0x30 00 00 00

Attribute Type ID로 0x30 값은 $FILE_NAME을 뜻한다.

0x68 00 00 00

Length of Attribute로 속성의 길이를 나타낸다.

표시한 부분이 $FILE_NAME 속성의 크기이다.

0x0

Non - Resident Flag로 0값을 가져서 Resident 속성임을 확인할 수 있다.

0x0

속성 이름 길이이다. 0이므로 Resident Header의 마지막 요소인 Attr Name이 없으므로, Resident Header의 크기가 0x8임을 알 수 있다.

0x18 00

Offset of Name으로 이름의 오프셋이다.

하지만 속성의 이름은 없으므로 이 오프셋은 Attr Content의 오프셋일 것이다.

Common Attr Header에서의 오프셋이므로 0x11aa098 + 0x18으로 0x11aa0b0부터 Attr Content라고 유추할 수 있다.

이 부분이 결국엔 Attr Content이라고 추측해본다.

0x00 00

이 부분은 Flag 값이다. 속성의 상태에 대해서 표기하는 부분인데

지난번 포스팅에서도 https://wintersnowaaa.tistory.com/10 에서 플래그 값이 0으로 설정되어있는데 구글링해도 안나와서 아직도 모르겠다...

그냥 0은 아무런 설정이 되어 있지 않는 상태인가?

0x03 00

Attribute ID로 각 속성에 대한 고유한 ID 값이다.

이전의 $STANDARD_INFORMATION은 0x0의 값을 지녔는데

이건 0x3의 값을 지닌다.

그러면 0x1, 0x2는 어디 있는거지...?

여기까지 일단 공통 속성 헤더에 대해서 봤고...

이후에 나오는게 뭔지 이제는 표나 다른 포스팅을 안봐도 반사적으로 나올만하다

다음은 속성 헤더 Attr Header이다.

0x4A 00 00 00

Size of Content로 0x4A의 값이다.

Content의 크기가 0x4A이라면 

Content는 위와 같은 크기를 가진다.

내 예상보다 크진 않네...

근데 저러면 그 뒤에 6바이트는 사용하지 않는 영역인가?

음...일단 넘어가자.

0x18 00

Offset of Content로 속성 컨텐츠의 위치이다.

공통 속성 헤더부터 0x18 멀어진 곳에서 Content 시작함.

위의 사진처럼 시작지점이 일치하게 나옴.

0x01

Indexed Flag이다. 이전 $STANDARD_INFORMATION 에서는 0으로 설정되어있었는데,

여기에서는 1로 설정되어있다.

Index로 사용하는 것은 NTFS 인덱스에서 사용이 되는지를 말하는듯하다.

이건 나중에 NTFS 인덱스에 대해 공부할 때 알 수 있을듯하다.

파일시스템 4_4 NTFS 인덱스 분석 : 네이버 블로그 (naver.com)

파일시스템 4_4 NTFS 인덱스 분석

이 분 포스팅 나중에 봐보면서 공부할 때 기억하자.

0x0

사용하지 않는 영역이다.

여기까지 일단...Attr Header...

이제 마지막으로 Attr Content

속성 컨텐트이다.

요 부분이 Attr Content이다.

앞에서 설명한 구조대로 짚어보자.

0x05 00 00 00 00 00 05 00

부모 디렉터리 파일 참조주소로 proof라는 블로그 포스팅에 따로 설명해준게 있어서 좀 봤다.

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

NTFS – 파일 참조 주소 (File Reference Address) | FORENSIC-PROOF

요거인데...

이전에 배운대로라면 MFT Entry는 $MFT, $MFTMirr, $LogFile 등 여러개이다.

$MFT부터 시작하며, 1024바이트 (2개의 섹터) 분량의 크기를 가지며, $MFT는 0이라는 엔트리 할당값을 가진다.

이후부터 순차대로 $MFTMirr는 1, $LogFile은 2의 주소를 가지며 각각 MFT Entry를 주소에 따라, 순서에 따라서 구별할 수 있는데,

이것 외에도 파일 참조 주소라는 확장된 개념이 도입되어 있다.

 상위 16비트는 이전에 나온 MFT Entry의 할당값이 들어온다. $MFT같은 경우는 0이 들어간다.

그리고 뒤에 나오는 48비트는 MFT Entry의 주소 값이 들어오게된다.

A라는 파일이 생성되어서 MFT Entry에 새롭게 MFT Entry가 추가되면,

그에 해당하는 할당값이 따라붙게 되는데,

A라는 파일이 삭제되고, B라는 파일이 추가되면 할당값이 바뀌어야한다.

Only 할당값, Only 주소값으로만 파일 시스템을 관리하기가 힘들어지므로,

파일 참조 주소를 할당값 + 주소값로 합쳐서 Entry에 붙여준다.

0x05 00 00 00 00 00 05 00 은 6바이트와 2바이트로 쪼개서 구분하는듯하다.

0x05 00 00 00 00 00 은 0x5로 MFT 엔트리 주소를 나타내고,

0x05 00 은 0x5로 할당값(순서 번호) 를 나타내는듯하다.

0x98 9B 6E CD 6F 4B DA 01

Creation Time으로 생성시간이다.

2024년 01월 20일 오후 4시 10분 52초

이건 지난번 $STANDARD_INFORMATION의 시간정보에서 나온 값과 정확히 일치한다.

0x98 9B 6E CD 6F 4B DA 01

Modified Time으로 수정 시간이다. $FILE_NAME에 대해서 수정한 적이 없으므로 생성시간과 일치한 값이다.

0x98 9B 6E CD 6F 4B DA 01

MFT Modified Time으로 MFT 수정 시간이다.

MFT 레코드 업데이트 시간인데...MFT 레코드는 MFT Entry을 말한다.

MFT Record = MFT Entry 임 ㅇㅇ

0x98 9B 6E CD 6F 4B DA 01

Accessed Time으로 접근시간이다.

마지막으로 MFT Entry에 접근한 시간인듯하다.

0x00 40 00 00 00 00 00 00

Allocated size of file 해당 파일이 할당된 클러스터 크기

0x40 00으로 10진수로는 16384...

16384개의 클러스터를 사용하고, 1개의 클러스터는 통상적으로 8개의 섹터를 차지한다.

0x00 40 00 00 00 00 00 00

Real size of file 해당 파일 실제 크기이다.

위와 같은 값으로 일반적인 디스크에 NTFS 파일 시스템을 사용하면, 8개의 섹터를 사용한다.

그러면 16384개의 클러스터 = 8개의 섹터 * 16384 = 8*512*16384bytes

67108864 bytes = 64MB

되게 많아보이지만 기껏해봐야 64메가바이트밖에 안된다.

0x06 00 00 00

Flags 파일 속성을 일컫는다.

https://wintersnowaaa.tistory.com/12

MBR - NFTS($STANDARD_INFORMATION)

이전 포스팅에서 나온 $STANDARD_INFORMATION의 플래그 값에서

0x10 00 00 00 디렉터리

0x20 00 00 00 인덱스 뷰 라는 값이 추가된 것말고는 똑같다.

그러므로 0x6 = 0x4 + 0x2 이므로

(숨긴파일 + 시스템 파일) 이라는 뜻이다.

0x00 00 00 00

Peparse value 으로 해당 속성의 Reparse point 이다.

자세한 내용은

NTFS reparse point - Wikipedia

NTFS reparse point - Wikipedia

여기에 있다.

값은 0x0이니까 넘어가자.

0x04

Length of name 이름의 길이이다.

뒤에 나오는 Name 값은 유니코드16으로 인코딩되어있으므로 한글자당 2바이트씩 차지한다.

이름은 총 4*2 = 8바이트 만큼의 크기를 갖는다는 뜻이다.

0x03

Namespace로 이름 표현방식이다

0일 경우는 POSIX

1일 경우는 WIN32

2일 경우는 DOS 3

3일 경우는 WIN32 & DOS 이다.

POSIX, WIN32, DOS는 대략적으로 운영체제 간의 어플리케이션 호환성을 위해 사용되는 유형들이라고 생각하는게 편하다.... 자세한건 나중에 알아봐야할듯.... 사실 나도 잘은 모르겠음.

0x24 00 4D 00 46 00 54 00

Name으로 유니코드로 인코딩된 이름이다.

앞에서 6바이트만큼이 이름 길이라고 했다.

$는 빼고 MFT만 세서 6바이트로 취급한다.

$MFT라고 적혀있다.

그렇다는건 다른 MFT Entry로 가서 확인하면 $(해당 이름) 이 존재할 것이라고 예측할 수 있다.

0x00 00 00 00 00 00

사용하지 않는 영역으로 유추된다.

책이나 다른 포스팅에서는 $MFT의 $FILE_NAME에 대해서 다룬 것을 보질 못해서

그렇게 예상이된다.

왜냐하면 추후에 다룰 $Data의 공통 속성 헤더 첫번째 데이터가 0x80으로 시작하므로

$FILE_NAME이후에 $Data가 오는데, 중간에 낀 6바이트의 0x0 값들은 사용하지 않는다고 밖에 생각이 안든다.

pg. 114~116

 

추후는 $Data

출처)

NTFS reparse point - Wikipedia

NTFS reparse point - Wikipedia

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

NTFS – 파일 참조 주소 (File Reference Address) | FORENSIC-PROOF

파일시스템 4_4 NTFS 인덱스 분석 : 네이버 블로그 (naver.com)

파일시스템 4_4 NTFS 인덱스 분석