[FileSystem Forensics] 8. FAT32#6_Data Area

* 들어가기에 앞서 본 스터디에 사용 된 OS 종류 및 VMware 종류에 대해 기술하고 시작하고자 한다. 다른 버전이어도 상관은 없으나, 사용 상 불편한 부분까지 본 블로그에서 일일히 다루어 주지는 않는다. 물론, 질문을 남겨줄 경우, 따로 확인해서 답변을 드리긴 하겠다.

  - 필자 E-Mail : wotmd9408@naver.com

  - 가상머신 : VMWare WorkStation 12

  - OS : Window7 Enterprise K 64bit

  - RAM : 1GB

  - 나머지 사항은 기본적인 세팅으로 설정하였다.

  - 추가 필요 Tool : Hxd(https://mh-nexus.de/en/downloads.php?product=HxD)

여기까지 따라온 독자들에게 깊은 감사의 인사를 드린다. 되도록이면 하나의 포스팅을 짧게 끝내려고 생각은 하고 있으나, 쓰다보니 그게 마음대로 되지 않아 전반적으로 내용이 길어져 읽는데 힘들었을 독자들을 생각하면 조금 죄송스러운 마음이 드는건 사실이다. 이 이야기를 여기에 쓰는 이유는 앞으로 만들어질 실습을 제외하면(물론 정확히 언제 완성될지는 모르겠지만..) 마지막 포스팅이 될 예정이기 때문이다. 

[그림 1. FAT32 구조]

위 그림을 기억하겠는가? 포스팅을 잘 따라온 독자라면 "이제는 그만좀 올려도 되지 않을까?"하는 생각을 할만한 그림일 것이다. 우리는 MBR을 시작으로 [그림 1]의 순서대로 공부를 진행해 왔다. 이제 대망의 마지막인 Data Area(데이터 영역)을 보려고 한다.

사실 Data Area는 앞서 포스팅했던 Root Directory Entry를 포함한다. [그림 1]에서는 조금 더 보기 쉽도록 표시되어 있지만, 예약영역(Reserved Area)의 가장 앞 섹터에 존재하는것과 마찬가지로 FAT32에서 Root Directory Entry는 데이터 영역의 가장 앞 섹터에 위치한다. 즉, Root Directory Entry부터 해당 파티션이 갖는 마지막 섹터까지가 데이터 영역이 된다. 

먼저 데이터 영역에 존재하는 내용이 무엇인지 살펴보자. 가장 먼저 앞서 확인한 Directory Entry가 있다. 이때 데이터 영역의 가장 앞에 존재하는 디렉터리 엔트리가 Root Directory Entry이고, 나머지가 그냥 Directory Entry이다. 이 Root Directory Entry에 포함하는 파일/디렉터리는 우리가 파티션에 해당하는 드라이브에 접근했을 경우 보이는 가장 상단 경로의 디렉터리 혹은 파일을 의미한다. 그리고 그 Root Directory Entry에서 우리는 해당 디렉터리 엔트리에 존재하는 파일과 디렉터리의 각종 정보를 확인 할 수 있다.

디렉터리 엔트리에서 특정 파일에 대한 정보를 수집했다면 이제 그 파일에 대한 데이터가 있는 부분으로 이동할 수 있다.(이 부분에 대해서는 이후에 자세히 설명하도록 한다.) 물론, Root Directory Entry에서 확인한 정보가 '파일'에 대한 정보라면 해당 파일의 데이터 정보에 접근할 수 있다. 그러나 파일이 아닌 디렉터리에 대한 정보라면 해당 디렉터리가 가지고있는 디렉터리 엔트리 부분으로 향하게 된다. 이번 포스팅에서는 파일을 분석해 파일의 데이터를 확인하고, 실제로 정보들을 역 이용해 데이터를 생성하는 과정을 진행해 볼 것이다.

[그림 2. Directory Entry내 파일 정보]

파일의 데이터 영역에 접근하기 위해서는 디렉터리 엔트리 내에 있는 파일의 정보를 읽어 낼 수 있어야 한다. 사실 데이터 영역에 접근하기 위해서 [그림 2]에 있는 모든 정보를 구할 필요는 없다. 결론부터 이야기하면 3가지(First Cluster High, First Cluster Low, File Size)만 알면 데이터 정보를 찾아오는데는 아무런 문제가 없다. 그러나 복습을 위해서, 하나하나 분석 해 보도록 하자.

  - File Name / Extender : KOALA.JPG

  - Attribute : 0x20 => 일반적인 File을 지칭

  - Create Time : 0x1B38 => ‭0001 1011 0011 1000‬

    Time값이니 5/6/5로 나누면 ‭00011 011001 11000 가 되고, 이를 다시 10진수로 변환하면 ‬3시 25분 48(시간값은 계산값에 *2)초 가 된다.

  - Create Date : 0x4B3B => ‭0100 1011 0011 1011‬

    Date값이니 7/4/5로 나누면 ‭0100101 1001 11011‬ 가 되고, 이를 다시 10진수로 변환하면 2017(년도 값은 기본 1980년에 계산값을 더한다)년 9월 27일이 된다.

  - Last Access Date : 0x4B3B => 위의 Create Date와 값이 같으니 계산은 생략한다.

  - First Cluster High : 0x0000

  - Write Time : 0x7410 => ‭0111 0100 0001 0000‬

    Time 값이니 5/6/5로 나누면 ‭‭01110 100000 10000‬‬ 가 되고, 이를 다시 10진수로 변환하면 14시 32분 32(시간값은 계산값에 *2)초가 된다.‬

  - Write Date : 0x3AEE => ‭0011 1010 1110 1110‬

    Date값이니 7/4/5로 나누면 ‭0011101 0111 01110 가 되고, 이를 다시 10진수로 변환하면 ‬2009(년도 값은 기본 1980년에 계산값을 더한다)년 7월 14일이 된다.

  - First Cluster Low : 0x03

  - File Size : 0x000BEA1F => ‭780,831‬

    여러분이 FAT32 또는 NTFS에서 "유일"하게 이 부분만이 추가적인 계산 없이 바로 용량을 표기하게 된다.(다른 부분에서는 사용하는 Sector 수 로 확인되는 경우가 많다)

    또한 디렉터리의 경우 용량이여기 존재하지 않기 때문에 File Size 값이 0으로 되어있다.

 * 지난 포스팅에서 소개한 NT Resource 및 Create Time Tenth의 경우 중요하지 않아 따로 표기하지 않았다. 추가적으로 필자가 적은 결과와 독자가 계산한 결과는 다를 수 있다. 과정을 동일하게 진행했더라도 생성 시간 등은 같을 수 없기 때문에 반드시 본인이 작성한 환경에서 계산을 진행해야 한다.

 * 당시 포스팅에서 제대로 소개하지 않았지만, FAT32 구조에서는 Access Time을 표기하지 않는다. 해당 내용을 표기하지 않는 이유는 32byte 안에 해당 내용을 다 기입 할 수 없기 때문이다.

이 Koala.jpg 파일을 기준으로 파일의 데이터가 위치한 곳으로 접근해 보도록 하자. 우선 파일의 데이터 영역으로 가기 위해서 중요한 부분은 First Cluster High, First Cluster Low 그리고 File Size이다. 사실 First Cluster High의 경우 항상 0을 가지니 결국엔 First Cluster Low와 File Size만 중요하다고 보면 된다. 방금 설명한 세가지에 대한 계산은 [그림 2]를 분석하며 확인했으니 다시 기입하지는 않겠다.

데이터로 가기 위해서는 First Cluster High와 First Cluster Low를 순서대로 결합한 뒤 2을 빼 주면 된다. 이는 FAT32에서 0번과 1번 클러스터는 이미 시스템에서 예약 후 사용하고 있기 때문이다. 이를 토대로 계산을 해보도록 하자.

  - First Cluster High + First Cluster Low = 0x00000003 = 3

  - FAT32에서 0번과 1번 클러스터는 이미 사용중이니 빼면 3-2 = 1

여기서 우리가 한가지 알아야 할 내용이 있는데, 1개의 클러스터는 8개의 섹터를 가진다는 점이다. 이를 토대로 Root Directory Entry인 16512 섹터에서 8 섹터를 이동한 16520으로 가면 우리가 찾던 Koala.jpg 파일의 데이터를 확인 할 수 있다.

[그림 3. Koala.jpg 파일의 Data 부분]

여러분이 필자와 동일하게 구성을 했거나, 아니면 각자의 세팅에 맞게 찾아 갔다면 위와 같이 정상적인 koala.jpg 파일의 데이터를 확인 할 수 있다. 여기서 문제는 여러분이 찾아간 16520 섹터에 있는 내용이 정말로 koala.jpg 파일의 데이터가 맞냐는 점이다. 물론 File Size를 이용해 데이터를 복사해서 따로 저장한 뒤 확인 하는 방법도 있을것이다. (그리고 그게 가장 정석적인 방법이기는 하다.) 그 방법은 잠시 후에 확인 해 볼 예정이며 지금은 File Signature를 이용해 확인하는 방법을 알아보자.

File Signature란 문자 그대로 해석하면 '파일의 서명'이 되는데 보다 자세히 풀이하면 '파일이 가지고 있는 고유한 문자열'이라고 봐도 무방하다. 파일은 일부 확장자를 제외하면 대부분의 확장자가 각기 다른 시작 문자열을 가지고 있다.(여기서 말하는 시작 문자열은 확장자 명이 아닌 해당 파일을 Hex Editor로 열었을 때 보이는 Hex 값 및 String 값을 의미한다.)

  * DLL 과 EXE 확장자처럼 서로 다른 확장자를 가지고 있으나 동일한 시그니처를 가지고 있는 경우도 존재한다. 

시그니처는 보통 파일의 시작 문자열부터 일정 부분까지를 의미하는데 평균 4Byte 정도에서 많게는 16Byte까지 되는 경우가 있다. 우리가 확인한 JPG 확장자의 File Signature는 FF D8 값을 시그니처로 가지고 있으며 데이터의 가장 끝은 항상 FF D9로 끝나게 되어있다. 그러나 보통 JPG/JPEG 파일을 확인 할 경우에는 FF D8 FF E0 와 JFIF 부분을 확인한 뒤 JPG 파일임을 확인하는 경우가 대부분이다.

  * 파일 별 시그니처 정보를 확인하고 싶은 경우 이 URL에 접속해 검색하면 확인 해 볼 수 있다.(http://www.garykessler.net/library/file_sigs.html)

이제 시그니처를 통한 확인이 아니라 데이터 영역을 복사해 파일을 생성함으로써 실제 koala 파일이 맞는지 확인 해 보도록 하자. 만약 koala.jpg 파일의 데이터 섹터에서 벗어났다면 다시 계산을 통해 해당 섹터로 이동하도록 하자. 이후 데이터의 가장 앞부분에 커서를 놓고 마우스를 우클릭한 뒤 [블록 선택]을 누르도록 하자. 

[그림 4. koala.jpg 파일 크기 입력]

이후 [그림 2]를 통해 계산한 File Size 값을 길이에 입력한 뒤(10진수로 변환한 뒤 780,831‬를 입력해도 상관없다.) 수락을 누르면 가장 해당 데이터의 마지막으로 이동되며 그 이전까지가 블록 선택이 된다. 그 내용을 복사해 새로 파일을 만들어 test.jpg로 저장하면 koala.jpg와 동일한 그림이 나타나는 것을 볼 수 있다.

폴더의 경우도 계산하는 방법은 파일과 동일하다. 다만 파일과 달리 폴더는 용량을 가지고 있지 않다. 따라서 동일하게 계산한 섹터로 이동하면 폴더의 데이터 영역이 있는게 아니라 해당 폴더에 저장된 파일들의 디렉터리 엔트리로 이동하게 된다. 그리고 해당 디렉터리 엔트리 내에 있는 파일의 내용을 기준으로 다시 들어가면 파일의 실제 데이터 영역으로 이동하게 되는 것이다. 한번 실습을 통해 확인 해 보도록 하자.

[그림 5. Forensics 폴더의 Directory Entry 정보]

우리가 실습해 볼 폴더는 [그림 5]에 입력 된 forensics라는 폴더이다. 폴더명이 8자를 넘어 LFNs(Long File Names) 방식으로 입력되어 있는 것을 확인할 수 있으며 폴더는 File Size가 0이므로 First Cluster High 와 First Cluster Low만 확인 후 계산하면 된다.

  - First Cluster High + First Cluster Low = 0x000000C2 = 0xC2

  - FAT32에서 0번과 1번 클러스터는 이미 사용중이니 빼면 0xC2 - 2 = 0xC = 192

위에서 파일의 데이터 영역 주소를 찾을 때도 설명했듯이 하나의 클러스터는 8개의 섹터를 가지고 있다. 즉 16,512 섹터로부터 1,563 섹터 뒤로 이동하면 이 폴더의 디렉터리 엔트리로 이동 할 수 있다. 계산 값인 18,048로 이동해 결과를 확인해 보도록 하자.

[그림 6. Forensics 폴더 계산 후 결과 비교]

Foreniscs 폴더의 디렉터리 엔트리 정보를 통해 계산한 결과. Forensics 폴더 안에는 Jellyfish.jpg라는 파일이 있는것을 확인 할 수 있었으며 실제 Windows 탐색기를 통해 확인한 결과 실제로 Jellyfish.jpg 파일을 확인 할 수 있었다.

지금까지 배워온 내용들을 잘 이용하면 Hex Editor를 이용해 실제로 파일을 생성해 내는게 가능하다. 단순히 생성하는 것 뿐만 아니라 MAC Time을 조작한 데이터를 생성할 수 있고 원하는 데이터를 밀어 넣을 수도 있다. 관련된 실습은 추가적인 실습 포스팅을 통해 진행할 예정이다.

이 포스팅을 마지막으로 FAT32에 대한 설명을 마무리 하려고 한다. 필자도 실무에서 포렌식 업무를 수행하지 않고 있어 실제 어떻게 업무가 진행되는지는 정확히 알려줄 수는 없으나 여태까지 진행해온 이론이 실제 업무에 도움이 될 수 있을 것으로 생각한다. 파일 시스템에 대해 공부하다보면 Web Hacking이나 모의해킹과는 다르게 조금 지루함을 느끼기가 쉽다. 아무래도 모의해킹이나 다른 여러가지 분야에 비해서는 실제로 보여지는 퍼포먼스나 결과가 그렇게 화려하거나 크지 않기 때문이다.

그러나 여러분이 실제로 Encase나 FTK(Forensics ToolKit)를 이용해 보면 모의해킹이나 기타 다른 보안 공부를 할때와 같은 기분을 느낄 수 있을 것이다. 지금까지 진행 된 포스팅은 그 밑바탕이 되기 위한 이론을 다지는데 그 목적을 두었다.

길고 긴 FAT32에 대한 포스팅을 따라온 독자분들께 감사의 인사를 남긴다. 다음 포스팅부터는 NTFS를 진행하게 될텐데, 아마 FAT32보다는 조금 어렵고 복잡한 부분이 있기때문에 조금은 더 각오를 하고 들어오는 것을 추천한다. 그동안 고생많았고, 부디 진행된 포스팅들이 여러분의 앞날에 도움이 되었기를 바란다.

* 참고 : 임베디드 개발자를 위한 파일시스템의 원리와 실습(정준석, 정용원 공저), 한빛미디어

* 참고 : http://www.garykessler.net/library/file_sigs.html