Latte의 보안이야기

* 들어가기에 앞서 본 스터디에 사용 된 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

* 들어가기에 앞서 본 스터디에 사용 된 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)

이제 FAT32 파일시스템도 어느정도 마무리 단계에 접어 들었다. 물론 이번 포스팅이 끝이 아니고 몇가지가 더 남아있긴 하지만(간단하게 풀어볼 수 있는 문제도 제작 해 보려고 하고있다.) 그래도 칠부능선을 넘은건 사실이다. 이론만 따지면 두번이나 세번 정도의 포스팅이면 간략하게나마 마무리 될 것으로 보인다.

지난 포스팅을 통해 Root Directory Entry의 구조와 각각의 디렉터리 엔트리가 어떤식으로 구성되어있는지 세부적인 내용들을 알아보았다. 그러나 해당 포스팅에서 다루지 않은 내용이 남아있다. 그것이 이번 포스팅에서 다룰 Short File Name과 Long File Names 이다.

파일 및 디렉터리는 생성할 때 각각의 고유한 이름을 가진다. 물론 이 고유한 이름이 절대적으로 Unique 하지는 않다. 동일한 확장자에 대해서만 고유한 이름을 갖고 있으니 오해 없기를 바란다. 그리고 각각의 파일명은 몇가지 규칙을 가지고 있으며, 해당 규칙을 위반할 경우 파일이 정상적으로 생성되지 않는다. 이 규칙은 SFN(Short FIle Name) 과 LFN(Long File Name)이 조금씩 다른 부분이 있기 때문에 따로 나누어 설명 하도록 하겠다.

먼저 알아볼 내용은 SFN(Short File Name)이다. 의미 그대로 짧은 파일명을 의미하고, FAT32기준에서는 8Byte (영문 8자, 한글 4자)이하, 3Byte이하의 확장자 파일 혹은 디렉터리일 경우 Short File Name으로 표기된다. 그림을 통해 예시를 들어보도록 하자.

[그림 1. Short File Name의 예시]

[그림 1]은 지난번 Root Directory Entry에서도 봤던 코알라 사진이다. 위에서 말한 Short File Name의 조건과 일치하는지 한번 확인해 보도록 하자. 먼저 파일명이 8Byte인지 확인하면 K,O,A,L,A로 총 5개의 알파벳으로 파일명이 구성되어 5Byte 값을 가진다. 그리고 확장자 역시 JPG로 3Byte 값만 가지기 때문에 Short File Name의 조건이 된다고 볼 수 있다.

그러면 Short File Name에 만족한다는 가정하에 어떤 규칙을 지켜야 파일이 생성되는지 확인해 보도록 하자.

  - 영어 대문자 A ~ Z (소문자는 대문자로 바꾸어 저장)

  - 해당 운영체제가 지원하는 언어의 문자( ex : 한글 MS-DOS라면 한글 파일명 가능)

  - 아라비아 숫자 0 ~ 9

  - 특수문자 중 $, %, ', -. _, @, ~, !, (), {}, ^, #,&

위에서 가장 첫번째 조건의 경우, 실제 파일을 만들때는 소문자로 만들어도 문제가 없지만, Root Directory Entry에 저장될 때는 대문자로 저장하기에 저렇게 기입하였다. 또한 따로 적혀있지 않지만, Short File Name 작성 규칙에서 파일 명 사이에 스페이스(0x20)을 입력하는 것은 가능하다. ( ex : MY NAME.HWP) 그러나 일부 프로그램의 경우 파일명 중간에 Space가 포함될 경우 파일을 제대로 인식 못할 수 있기 때문에 Under Bar( _ )를 지향하는 것이 좋다. 또한 영어가 아닌 외래어의 경우 한 글자당 2Byte로 인식하기 때문에 그 또한 알아두면 좋다. 그리고 마지막으로, 전 포스팅에서 이야기 했듯이 파일명 가장 앞에 스페이스(0x20)이 들어갈 수 없다.

SFN(Short File Name)은 이정도로만 설명해 두도록 하자. 이후 추가적으로 필요한 부분이 있으면 필자가 더 채워 두도록 하겠다. 이제부터는 이 포스팅에서 본격적으로 다뤄 볼 LFNs(Long File Names)에 대해 알아보도록 한다.

Window 95가 나오기 이전, 그러니까 MS-DOS와 Window 3.x버전이 PC의 기본 OS였던 시절에는 FAT 파일시스템이 나올 때부터 쓰이던 8.3 Naming, 즉 우리가 위에서 SFN(Short File Name)으로 알고있는 방식만이 사용되었다. 그러한 이유로 많은 유저들은 매킨토시(MAC OS)나 Unix, Linux 계열처럼 긴 파일명을 사용 할 수 있기를 원했다. 그래서 나온 기능이 Window 95와 함께 나온 LFNs(Long File Names)이다.

LFNs의 자세한 구조를 알기전에, LFNs의 특징들에 대해 먼저 짚고 넘어가도록 하자.

  - 유니코드(UTF-16)방식으로 인코딩되어 있기 때문에 다국어 지원이 가능

  - 최대 255자까지 저장 가능

  - 3자리 이상의 확장자도 저장 가능

  - 기존의 SFN(Short File Name)과 호환 됨

  - SFN보다 사용할 수 있는 특수문자 폭이 넓어짐

MircroSoft는 LFNs를 설계하면서 하위 호환의 개념을 버리지 않으려고 노력했다. 앞으로 우리가 보게 될 Long File Name Entry는 전 포스팅에서 보았던 Directory Entry를 변형해서 구성하여 하위 호환성을 유지했다. 물론, 억지로 비틀어(?)만든 방식이니 만큼 구조가 어색하고 상당히 불편하다. 

LFNs의 가장 큰 특징중 하나는 바로 유니코드를 지원한다는 점이다. 이는 Microsoft의 큰 밑그림(빅픽처??)으로 인해 지원하는 부분인데 Windows가 여러 나라에 사용될 것을 대비해 추가 된 기능이다. 물론 이 기능으로 인해 저장 공간이 2배이상 늘어나 버린 단점은 분명히 존재하지만, 현재의 상황으로 따지고 보면 미래를 정확히 내다 본 좋은 선택이었음에는 틀림없다.

[그림 2. Long File Names 표기의 예시]

[그림 2]는 필자가 예시로 만든 Forensics라는 디렉터리를 Root Directory Entry에서 확인한 것이다. [Forensics] 이라는 단어는 총 9자로 Short File Name 방식인 8/3(8자리 파일명, 3자리 확장자명)법칙으로는 만들어 낼 수 없다. 따라서 [그림 2]처럼 LFNs(Long File Names)로 표기된다. [그림 2]를 보면 동일한 Forensics가 2가지 방식으로 표현된 것을 볼 수 있는데, 붉은색 네모칸과 초록색 네모칸이 바로 그것이다. LFNs의 특징 중 하나는 표기 할 수 있는 부분까지 표기해준 뒤 모자란 부분에 대해서 ~1로 표현하여 LFNs로 표현됐음을 알려주는 것이다. 앞으로 여러분이 보게 될 디렉터리 엔트리 중 ~1이 있으면 LFNs로 표기되었다고 보아도 좋다.

위 그림에 대해 자세히 알아보도록 하자. 먼저 초록색 네모를 보면 SFN(Short File Name)처럼 기록되어있다. 최대 6자까지 파일명을 표기하고 남은 부분을 ~1로 표기하여 LFNs(Long File Names)로 표현되었음을 지칭한 뒤. 파일의 나머지 정보(생성시간, 파일 용량 등)을 표기한다. 여기까지는 [그림 1]에서 본 SFN(Short File Name)과 비슷하다. 그런데 LFNs(Long FIle Names)는 어찌됐든 File명을 전체를 표시해 줘야 하기 때문에, 해당 디렉터리 엔트리 상단 32Byte를 추가로 할당하여 파일명을 마저 표기한다. 이 부분이 붉은색 네모에 해당하는 부분이며 Short Directory Entry와 구분되게 Long Directory Entry라 지칭한다.

아래 정리를 통해 [그림 2] 중 붉은색 영역(Long Directory Entry)에 해당하는 부분에 대하여 자세히 알아보도록 하자.

위 표들을 자세히 살펴보면 한가지 특이한 점을 알 수 있다. Long File Name Entry 하나 당 13개의 문자열을 저장할 수 있으며, 문자열을 저장할 때 2Byte 당 1개의 문자열을 저장한다는 점이다. 이는 LFNs가 문자열 지정 방식을 유니코드(UTF-16)으로 하고 있기 때문인데, 이 부분에 대해서는 차후에 기회가 되면 따로 정리해보도록 하겠다. 

여기서 의문점 하나. 만약 파일명, 혹은 디렉터리 명이 13자를 넘어갈 경우에는 어떻게 되겠는가? 간단하다. 필요한 숫자만큼 Long Directory Entry를 생성하게 되며 최대 255자 까지 생성이 가능하기 때문에 255/13을 해보면 최대 20개의 Long Directory Entry가 생성되게 된다.

그러면 Short Directory Entry 와 Long Directory Entry가 저장되는 형태에는 어떠한 규칙이 존재하는지 아래표를 통해 알아보자.

위 표대로 Short Directory Entry가 가장 하단에 위치하고 그 위로 Long Directory Entry가 순서대로 시작되어서 맨 위쪽에 마지막 문자열의 Long File Name Entry가 위치한다. 마지막 Long File Name Entry에는 해당 Entry가 마지막임을 알려주기 위해 Order 항목에 마지막 Entry 번호와 0x40번 비트를 OR시키게 된다. 만약 7번째가 Long File Name Entry라면 Order 값은 0x47이 되는 것이다. 아래 예시를 통해 Short Directory Entry 및 Long Directory Entry를 정리 해 보도록 하자.

[그림 3. Short/Long Directory Entry 예시]

실습을 위해 제목이 긴 파일 하나를 만들었다(필자가 매우 좋아하는 영국 드라마 "Doctor Who"에서 주인공이 타고다니는 우주선 이름이다). [그림 3]을 통해 하나하나 확인 하도록 하자. 먼저 가장 하단의 Short Directory Entry부터 확인해 보도록 하겠다. 기준은 전 포스팅에서 설명했던 디렉터리 엔트리 설명과 이번 포스팅에서 설명한 Long File Name Entry 설명을 기준으로 작성하도록 하겠다.

 - Name  : TIMEAN~1 

   -> 해당 파일명으로만 봤을 때는 TIMEAN~1로 보일 수 있으나 위의 내용들을 함께 봤을 때 이 파일은 LFNs로 표현되어 있음을 알 수 있다.

 - Extender : TXT

 - Attribute : 0x20

   -> 0x10은 디렉터리, 0x20은 파일을 의미한다. 따라서 이 디렉터리 엔트리는 파일임을 알 수 있다.

 - Create Time : 0xB61A => 1011 0110 0001 1010

    5/6/5로 변환하면 10110 110000 11010 가 되는데 이를 다시 10진수로 변환하면 22시 48분 26초가 되는데 마지막 Seconds 부분은 최대 31까지밖에 표기하지 못하므로 2를 곱해야 해서 22시 48분 52초가 된다.

[그림 4. Create Time 확인]

 - Create Date : 0x4B47 => 0100 1011 0100 0111

    7/4/5로 변환하면 0100101 1010 00111 가 되는데 이를 다시 10진수로 변환하면 37년 10월 7일이 된다. 전 포스팅에서 연도를 계산할 때는 기본 1980에 앞에서 구한값을 더하라고 했으므로 최종 값은 2017년 10월 7일이 된다. [그림 4]를 통해 맞는 결과인지 확인하도록 하자.

 - Last Access Date : 0x4B47 => 마지막 접속 날짜는 날짜 변경 이후에 따로 접속한 이력이 없기 때문에 생성 날짜와 동일한 값을 가진다.

 - First Cluster High : 0x00

 - Write Time : 0xB623 => 1011 0110 0010 0011

    5/6/5로 변환하면 10110 110001 00011 이 되는데 이를 다시 10진수로 변환하면 22시 49분 3초가 된다. 위의 Create Time과 마찬가지로 마지막 seconds 값은 2를 곱해줘야 하므로 최종 결과는 22시 49분 6초가 된다. [그림 4]에서 수정한 날짜의 시간을 확인해 보도록 하자.

 - Write Date : 0x4B47 => Create Date와 같은 값이 표기되어 있다.

 - First Cluster Low : 0x00C4 => 다음 포스팅에서 실제로 사용 할 수 있을 것이다.

 - File Size : 0x00000E => 10진수로 변환하면 14Byte가 나온다. [그림 4]에서 크기를 확인해 보도록 하자.

위에서는 Short Directory Entry에 대해서 알아보았다. 전 포스팅의 복습이 되었길 바라며 이제 이번 포스팅에서 다루었던 Long Directory Entry 내용을 확인 해 보도록 하자.

먼저 32Byte 씩 잘라서 총 몇개의 Long File Name Entry가 있는지 확인해보자.

[그림 5. 예제 파일의 Long File Name Entry 종류]

조금 그림자체가 복잡하게 되어있지만 [그림 5]는 에제 파일의 Long Directory Entry 내에 Long File Name Entry를 하나하나 나눈 것이다. Long File Name Entry의 수를 세는것은 생각보다 간단하다. Short Directory Entry에서 LFNs 타입을 확인 한 후 해당 디렉터리 엔트리 위로 32Byte씩 잘라가면서 가장 앞 바이트 값을 확인하면 된다.(마지막 엔트리가 0x01, 0x02 등이 아닌 0x41~ 0x60 사이의 값이 오면 마지막 엔트리가 된다.)

앞서 위의 표에서 봤던 내용을 토대로 Long File Name Entry 값을 확인해 보도록 하자.(내용이 길어지는 관계로 본 포스팅에서는 1번 Long Directory Entry만 함께하도록 하겠다. 이후 내용은 스스로 실습 해 보도록 하자)

 - Order : 0x01 => 첫번째 Long Directory Entry

 - Name1 : T.i.m.e. . => Time 과 스페이스(0x20)이 해당 Name1에 포함된 이름 값으로 되어있다.

 - Attribute : 0x0F => 이 값은 반드시 고정되어야 한다.

 - Type : 0x00 => LFNs의 항목중 하나

 - Check Sum : 0xA3 => 계산법은 추후에 따로 설명하도록 한다.

 - Name2 : A.n.d. .R.e. => And와 스페이스(0x20), 그리고 Re가 Name2에 포함되어 있다.

 - First Cluster Low : 0x00

 - Name3 : l.a. => la가 name3에 포함되어 있다.

위 내용으로 봤을 때 첫번째 Long Directory Entry에 포함된 파일의 이름은 Time And Rela가 된다. 이후 나머지 Long Directory Entry값은 독자분들이 실습을 통해 확인해 보기 바란다. 파일명은 [그림 4]에 나와있으니 최종 결과는 그곳에서 확인하면 되겠다.

생각보다 짧게 끝날것으로 예상했던 포스트였는데 실습이 포함되면서 생각보다 길어진 감이 있다. 이해가 잘 안될수도 있고, 이론만으로 진행하다보니 학습에 지루함이 있을 수 있다. 실제 업무에 들어가서는 이렇게 Hex Editor를 사용하는 일보다는 Encase나 FTK Editor를 이용하는 일이 더 많을 것이다.(필자로 실제로 실무를 하지 않아서 확신할 수는 없지만..) 그러나 이렇게 이론을 알아가는 것이 실제 업무를 하는데 상당한 도움이 될 것이니 소홀히 하지 말기 바란다.

다음 포스팅에서는 FAT32 의 마지막 단계인 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)

우리는 MBR을 시작으로 FAT32 구조의 순서대로 정리를 진행하고 있다. 앞에서도 지겹게 설명한 내용이지만 이 블로그의 내용일 본 포스팅부터 접한 독자도 있을테고 혹은 기억하지 못한 독자도 있을테니 한번 더 확인하고 넘어가도록 하자.

[그림 1. FAT32 구조]

우리는 지난 포스팅을 통해 FAT 영역에 대해 알아보았다. 이제 오늘 포스팅을 통해 알아 볼 영역은 Root Directory Entry이다. 먼저 Root Directory Entry의 모습을 그림을 통해 보도록 하자.

[그림 2. Root Directory Entry 구조]

[그림 2]는 Root Directory Entry의 구조를 보여주고 있다. 앞에서 보던 FAT 또는 BR 구조와는 다르게 이 Root Directory Entry에서는 우리가 확실히 구분할 수 있는 것들이 보인다. 바로 KOALA JPG와 같은 파일을 의미하는 것 같은 내용들이다. 이를 통해 우리는 Root Directory Entry가 어떤 역할을 하는지 유추 할 수 있을 것 같다.

Rood Directory Entry는 위에서 보는것과 같이 볼륨에 존재하는 파일과 디렉터리의 정보를 가지고 있는 영역이다. 데이터 영역의 가장 앞 섹터에 존재하는 영역으로 데이터 영역과 함께 설명해도 전혀 상관없는 영역이지만, 포스팅의 글이 너무 길어 질 경우 가독성이 떨어져 제대로 보지 않게 되어 나누어 설명하고자 한다.(현재까지는 정상적인 실습을 진행하지 않고 이론적으로 설명만 했는데, 데이터 영역부터는 어느정도 실습이 포함되며, File System 에 대한 전반적인 설명이 끝난후에는 여러분이 실습을 해 볼 수 있도록 어느정도 실습 문제 또는 파일도 제공하려고 하니 참고하기 바란다.)

본격적으로 Root Directory Entry에 들어가기 전에 독자 여러분들이 제대로 해당 영역까지 찾아 갈 수 있는지 확인해 보도록 하자. [그림 2]에 Root Directory Entry의 섹터 위치가 나와있긴 하지만, 이 포스팅을 보는 독자들은 양심적으로 안 보고 계산 할 수 있을 거라 본다. 계산이 되었는가? 혹시 기억이 나지 않는다면, 과거 포스팅들을 보는 방법도 있을 것이지만, 시간을 단축하기 위해서 계산에 참고 할 수 있는 내용을 아래에 적어 드릴테니 기억을 더듬어 보도록 한다.

  - BR 영역의 위치

  - 예약된 영역(Reserved Area)의 크기

  - FAT32 의 수

  - FAT32 영역이 가지고 있는 크기

위의 내용으로 계산이 되었는가? 정확히 Root Directory Entry에 도달했다면 정상적으로 계산을 잘 한것이다. 만약 제대로 도달하지 못했다면 기본 세팅에서 잘못 세팅했거나, 어딘가에서 잘못 계산했을 가능성이 있으니 다시 한번 신중하게 계산 해 보기 바란다.

[그림 3. Root Directory Entry 출력 화면]

앞서 여러분이 봤던 [그림 2]와는 거의 비슷한 내용의 출력화면이다. 달라진게 있다면 확장자가 없는 무언가가 추가 된 것이다. Root Directroy Entry는 Directory Entry라 불리는 구조치들의 집합이며 그들의 가장 상위에 있는 엔트리이다. 데이터 영역에는 두가지 형태의 구조체가 저장되는데 그것이 우리가 알고있는 디렉터리와 파일이다.  파일은 말 그대로 해당 파일의 정보를 가지고 있으며, 디렉터리의 경우 자신의 정보와 하위 디렉터리 및 파일의 정보를 가지고 있다.

[그림 3]의 경우 Root Directory Entry에 들어있는 출력 형태 중 많이 볼 수 있는 내용을 약 3가지로 구분해서 표시한 내용이다. 각각의 파일 혹은 디렉터리는 디렉터리 엔트리에서 32Byte 단위로 표기되며, 이로 인해 한 섹터당 16개의 디렉터리 엔트리를 담을 수 있다. 

가장 먼저 빨강색 테두리 부분을 보도록 하자. 굉장히 눈에 익숙한 모습이다. 여러분이 예상 하듯이 저 빨강색 테두리는 파일 형태의 디렉터리 엔트리이다. 앞쪽에 파일명과 확장자 명이 보이며, 나머지 모양은 아직 해석하기 어려운 내용들로 구성되어 있다. 그다음으로 아래쪽의 파란색 테두리를 먼저 보도록 하자. 저 파랑색 테두리는 빨강색 테두리와는 다르게 확장자가 표시되지 않았다. 즉, 저런 형태로 되어있다면 디렉터리라는 표시이다.(물론 32Byte 중 디렉터리와 파일을 구분할 수 있도록 따로 입력되어있다)마지막으로 가운데 갈색 테두리 역시 디렉터리이다. 다만 파란색 테두리와는 다르게 ~1로 표기되어 있는데, 이는 뒤에서 설명할 Long File Names로 표기 할 수 있는 이름보다 길게 파일 혹은 폴더명이 생성 될 경우 저런식으로 표기된다.

이제 각각의 디렉터리 엔트리를 표기하는 32Byte의 상세 내역을 확인 해 보도록 하자.

  * Name의 경우 첫번째 바이트에 오는 내용에 따라 특별한 의미를 가지고 있는 경우가 있는데 이는 아래를 참고하도록 하자.

 * 여기서 주의할 점이 하나 있다면 파일명의 첫번째 바이트에는 0x20(스페이스)이 올 수 없다. 또한 0x05를 제외하고는 0x20보다 작은 값이 올 수 없다.