NTFS의 모든 MFT 엔트리는 순서에 따라 고유한 값을 가진다. 이 주소를 보통 MFT 엔트리 주소(Entry Address)라고 한다. MFT 엔트리 주소는 단순히 $MFT 내의 MFT 엔트리 순서에 따라 값을 1씩 증가시키면서 부여한 주소이다. 단, 첫 번째 엔트리의 주소는 0이다. 따라서, 특성 MFT 엔트리에 접근하고 싶다면 MFT 엔트리 주소에 MFT 엔트리 크기 값인 1,024를 곱하면 된다.
MFT 엔트리 주소는 MFT 엔트리를 접근하는데 큰 문제가 없어 보이지만 NTFS에서는 내부적으로 MFT 엔트리를 지정할 때 MFT 엔트리 주소가 아닌 파일 참조 주소(File Reference Address)라고 불리는 좀 더 확장된 주소 형식을 사용한다. 파일 참조 주소는 MFT 엔트리 주소에 엔트리 할당 상태 값을 추가한 주소이다. 할당 상태 값이란 무엇을 의미하는 것일까?
다음은 파일 참조 주소의 형식이다.
MFT 엔트리의 순서에 따라 1씩 증가된 값인 MFT 엔트리 주소를 48비트로 구성하고, 상위 16비트에는 엔트리 할당에 따라 변하는 순서 번호가 온다. 순서 번호는 해당 MFT 엔트리가 할당 될때마다 1씩 증가하는 값이다. 예를 들어, 어떤 파일이 NTFS 파일시스템 상에서 생성이 되면 MFT 엔트리가 하나 생성된다. 이때 순서 번호는 1이 된다. 하지만 해당 파일이 삭제되고, 그 위치에 새로운 파일의 MFT 엔트리가 할당된다면 그때는 순서 번호가 2가 된다. 이렇듯 MFT 엔트리 순서를 나타내는 MFT 엔트리 주소 외에 엔트리 할당 값을 나타내는 순서 번호를 추가한 주소를 파일 참조 주소라 한다.
그렇다면 MFT 엔트리 주소 외에 순서 번호를 추가한 이유는 무엇일까? 그 이유는 안정성에 있다. 일반적으로 NTFS 상에서 파일을 탐색할 때, 인덱스 구조를 사용한다. 윈도우 탐색기를 사용할 경우라고 이해하면 쉬울 것이다. 윈도우 탐색기를 이용해 각 디렉터리 간의 이동이나 파일 목록과 속성을 빠르게 볼 수 있는 이유는 B 트리 구조를 사용한 인덱스 구조 덕분이다.
인덱스 구조를 통해 탐색한 파일을 이동, 복사, 실행 등의 작업을 할 경우 인덱스 구조에 포함된 $FNA 속성의 파일 참조 주소를 통해 $MFT 파일의 MFT 엔트리에 접근할 것이다. 이 경우 단순히 MFT 엔트리 주소만으로 접근할 경우 인덱스 구조에서 탐색한 파일의 MFT 엔트리가 해당 파일의 엔트리라고 단정지을 수 없다. 왜냐하면 새롭게 다른 파일에 의해 할당되었을 수도 있기 때문이다. 물론 $MFT에 새로운 파일이 할당되면 인덱스 구조의 관련 내용도 갱신이 되어 동기화가 되어야 하겠지만 서로 다른 구조인 만큼 동기화가 적절히 되었는지 확인할 수 있어야 한다.
이를 위해 순서 번호를 사용한다. 물론, MFT 엔트리의 헤더 구조에도 순서 번호를 표시하는 필드가 존재한다. http://forensic-proof.com/archives/584 만약, 파일 탐색을 통해 어떤 파일을 사용하고자 할 때, 인덱스 구조의 $FNA 순서 번호와 MFT 엔트리의 순서 번호가 일치하지 않는다면 적절한 오류가 발생될 것이다.
인덱스 구조의 $FNA 내의 파일 참조 주소를 예로 들었지만 파일 참조 주소는 $FNA에서만 사용하는 것은 아니다. 특정 파일의 MFT 엔트리에 접근이 필요한 구조라면 모두 파일 참조 주소를 사용해 접근한다.
다음은 MFT 엔트리 헤더의 순서 번호와 파일 참조 주소와의 관계를 그림으로 표현한 것이다.
Categories
- 0×00 News (18)
- 0×01 Fundamentals (18)
- 0×02 Live Forensics (3)
- 0×03 Incident Response (15)
- 0×04 Storage Forensics (27)
- 0×05 File System Forensics (36)
- 0×06 Windows Forensics (44)
- 0×07 *nix Forensics (3)
- 0×08 Mac Forensics (1)
- 0×09 Web Forensics (8)
- 0x0A Data Forensics (8)
- 0x0B Forensic Challenges (15)
- 0x0C Forensic Education (9)
- 0x0D EnCase (16)
- 0x0E Forensic Tools (10)
- 0x0F Slides (26)
- 0×11 Forensic Articles (10)
- 0×12 Forensic Interview (5)
artifacts CEIC challenge Codegate conference Data recovery defcon DFRWS ENCASE EnCE encoding FAT File System FTK hardware imaging index.dat interview Live Forensics live response malware mbr memory forensics network ntfs padocon practitioner prefetch process RAID Recycle Bin SCSI signature Slack slide SSD timeline timestamp USB usb artifacts virtual forensics WDFS web browser windows 8 writeup
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
Archives
- May 2013 (2)
- April 2013 (3)
- March 2013 (9)
- February 2013 (1)
- January 2013 (7)
- December 2012 (1)
- November 2012 (3)
- October 2012 (4)
- September 2012 (10)
- August 2012 (1)
- July 2012 (4)
- June 2012 (7)
- May 2012 (5)
- April 2012 (5)
- March 2012 (2)
- February 2012 (2)
- January 2012 (5)
- December 2011 (1)
- November 2011 (5)
- October 2011 (2)
- September 2011 (2)
- August 2011 (5)
- July 2011 (3)
- June 2011 (6)
- May 2011 (2)
- April 2011 (7)
- February 2011 (11)
- December 2010 (3)
- November 2010 (4)
- October 2010 (8)
- September 2010 (5)
- August 2010 (6)
- July 2010 (4)
- June 2010 (1)
- May 2010 (12)
- April 2010 (4)
- March 2010 (14)
- February 2010 (16)
- December 2009 (3)
- November 2009 (9)
- October 2009 (10)
- September 2009 (7)
- August 2009 (9)
- July 2009 (7)
Last referers
- - cappleblog.co.kr/
- - mobileyde(...)-305.html
- - codeengn.com
- - mobileyde(...)5230.html
- - mobileyla(...)roid.html
Visitors Online
- 09 visitor(s) online
- powered by WassUp





Pingback: NTFS – $FILE_NAME 속성 | FORENSIC-PROOF (Digital Forensics Community)