* 들어가기에 앞서 본 스터디에 사용 된 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)
지난 포스팅에 이어 이번에는 FAT 영역에 대해 정리해 보도록 하겠다. 먼저 앞서 설명했던 FAT32의 구조에 대해서 기억하는지 살펴보자.
[그림 1. FAT32 구조]
[그림 1]은 FAT32#1 포스팅에서 보았을 것이다. FAT32 볼륨 가장 앞에는 Boot Record가 오며, 그 뒤를 이어 예약영역, FAT 영역, 데이터 영역 등으로 이루어져 있다. Boot Record는 앞선 포스팅에서 설명을 했고, 이번에 설명할 영역은 FAT #1과 #2로 이루어진 FAT 영역에 대해서 설명하고자 한다.
위 구조대로라면 우리가 원하는 FAT 영역으로 가기위해서는 Boot Record와 예약영역을 지나야 갈 수 있다. 앞에 내용을 복습하기 위해, MBR부터 FAT#1까지 가기위한 계산을 수행해 보도록 하자.
[그림 2. MBR 영역 구조]
가장 먼저 볼륨의 Boot Record의 위치부터 확인해야 한다. BR 영역의 시작을 가르키는 Start LBA Address는 파티션 테이블 영역의 시작에서 8번째 offset ~ 11번쨰 offset에 위치하고 있으며, [그림 2]에서는 0x80 (Dec = 128)을 기록하고 있다. 이를 따라 128번 Sector로 가면 우리가 찾던 BR 영역이 존재함을 확인 할 수 있다.
[그림 3. Boot Record 영역]
[그림 3]은 바로 지난 포스팅에 설명했던 Boot Record 영역이다. BR영역의 전체적인 구성이나 세부적인 내용은 바로 전 포스팅을 참조하도록 하자. 우리가 이번 포스팅을 통해 공부해야 할 내용은 BR영역이 아니라 FAT 영역이니까 말이다.
위 FAT 영역의 위치를 잘 모르겠다면 화면을 위로 올려 [그림 1]을 다시 보고 오기 바란다. FAT 영역으로 가기 위해서는 BR영역까지의 섹터와 예약 영역의 섹터 수를 더하면 FAT 영역의 시작 섹터가 나오게 된다. Boot Record에는 예약 영역이 갖는 전체 섹터 수(Reserved Sector Count)를 표기하고 있는데 offset 주소로 000E ~ 000F가 Reserved Sector Count가 된다. 값은 0x2A10으로 기록되어있으나, *리틀엔디언 표기법에 따라 0x102A로 계산하면 4,138이 나온다.
* 앞서 설명했어야 하나, 미처 설명하지 못해 본 포스팅에서 '리틀 엔디언'에 대해 설명하고자 한다. 엔디언은 쉽게말하면 바이트를 배열하는 순서인데, 큰 단위가 앞에오는 빅 엔디언, 작은 단위가 앞에오는 리틀 엔디언으로 나뉜다. 예를 들어 0x1234를 입력할 경우, 빅 엔디언 기반의 구조에서는 12 34로 입력되고 리틀 엔디언 기반에서는 34 12로 기록되는 것이다. 우리가 사용하는 Intel 기반에서는 리틀 엔디언 기반으로 사용하고 있으니 섹터 수를 계산할 때 특히 햇갈리지 않도록 한다. 특별한 경우가 없다면 앞으로는 리틀 엔디언 기반으로 설명할 예정이며 빅 엔디언 기반으로 설명해야 할 경우에는 따로 언급 하도록 한다.
혹시라도 4,138 섹터로 간 독자가 있는가? 혹시 가봤다면 어떤 결과가 나오는가? 필자랑 동일하게 앞의 과정부터 수행했다면, 나오지 않아야 정상이다. Reserved Area는 말 그대로 시스템에서 나중에 사용하기 위해 '예약한' 영역이기 때문이다.
[그림 4. FAT Area]
[그림 4]는 [그림 1]에서 FAT#1에 해당하는 영역이다. 우리가 예전에 봐왔던 MBR이나 BR과는 사뭇 다르게 굉장히 심플하게 구성되어있다. 하지만 저 심플하게 구성된 부분이 파일 시스템에서는 굉장히 중요한 역할을 한다. FAT는 이름 그대로 File Allocation Table로 파일 할당 테이블을 의미한다. 윈도우 기반의 파일시스템(현재 주로 사용하는 FAT32, NTFS)은 파일의 용량을 할당할 때 클러스터 단위로 할당 한다.
따라서 FAT 영역에는 별다른 구조체가 존재하지 않고 클러스터의 상태값만을 보여주는 모습이다. 아래 구조를 보고 FAT 영역의 내용에 대해 조금 더 자세히 알아보도록 하자.
[그림 5. FAT Area Structure]
[그림 5]는 [그림 4]에서 보인 FAT 영역을 구조화 한 표이다. 위에서 볼 수 있는 것과 같이 하나의 클러스터는 4byte를 가지고 있다. 자세히 보면 클러스터의 시작이 0번이 아닌 2번부터 시작하는 것을 볼 수 있다. 이는 파일시스템이 FAT 영역의 0번과 1번 클러스터를 Media Type 과 Partition Status의 용도로 사용해버렸기 때문이다. 이는 다음 포스팅에서 다룰 Root Directory에서의 파일 생성 / 복구 등에서 꽤나 중요하게 작용하니 반드시 기억하기 바란다.
별다를게 없어 보이는 이 FAT 영역을 굳이 포스팅을 통해 정리하는 이유는 이 영역이 파일의 생성, 삭제 등에 있어서 매우 중요하기 때문이다. FAT32 파일시스템은 생성 된 파일의 용량을 정할 때 Cluster 단위로 저장한다. 예를 들어, 5kbyte의 파일을 생성한다고 가정하자. 파일은 생성 될 때 아무리 작은 용량의 파일이라도 1개 이상의 클러스터를 할당 받는다. 기억할지 모르겠지만, 여러분은 BR영역에서 클러스터 당 섹터 수에 대해 정의한 내용을 보았다.
[그림 6. Boor Record Structure]
앞의 포스팅으로 돌아가서 관련 내용을 확인하고 와도 좋지만, 시간을 낭비하기 싫은 독자들을 위해 [그림 6]을 통해 BR의 구조를 확인하도록 하자. 0x0D를 보면 'Sector Per Cluster' 라는 영역을 볼 수 있는데 이 부분이 우리가 이 포스팅에서 중요하게 봐야 할 부분이다. 실제 여러분의 환경에서 'Sector per Cluster'의 값을 보면 '0x08'로 표기되어있는 것을 볼 수 있는데, 아마 여러분이 앞으로 보게 될 거의 모든 FAT32 환경에서는 동일하게 표기되어 있을 것이다.
FAT32영역에서 'Sector Per Cluster'는 사용자가 임의로 조정하지 않는 한 Defualt 값으로 0x08을 갖는다. 하나의 Sector는 512byte의 값을 갖는데 이를 볼 때 하나의 클러스터는 4Kbyte ( 512Byte * 8 = 4096Byte)의 크기를 갖는 것을 알 수 있다. 다시 위로 올라가서, 5kbyte의 파일을 예를 들면, 1개의 클러스터로는 용량이 부족하기 때문에 2개의 클러스터를 필요로 한다. 아래에서 파일이 있을 떄의 FAT Area의 상태에 대해 자세히 알아 보도록 하자.
[그림 7. 파일이 존재하는 FAT 영역]
[그림 8. VHD 내 존재하는 파일 List]
[그림 7]은 필자의 FAT 영역 내용 중 일부이다. 또한 [그림 8]은 현재 필자의 가상 환경 내 VHD에 존재하는 파일의 List 이다. 각각의 파일은 jpg 파일이 826kbye, txt 파일은 각각의 6자리의 영문을 담고 있는 파일이다. 지금부터 [그림 8]의 파일 List를 기준으로 [그림 7]에 존재하는 내용들을 정리하는 시간을 갖고자 한다.
먼저 [그림 4]로 다시 한번 올라가보자. [그림 4]는 [그림 8]에서 'Desert.jpg'만 존재하지 않는 상태이다. 앞서 [그림 5]에서 우리는 각각의 클러스터의 구조가 어떤식으로 구성되어있는지 확인했다. FAT 영역에서 각각의 클러스터는 파일이나 디렉터리가 저장 된 위치를 Linked List 방식으로 표현하고 있다. 즉, 각각의 FAT Entry는 자신의 다음 Cluster 값을 담고 있다는 의미이다. 즉, 파일이 1개 이상의 클러스터를 가지고 있을 경우 클러스터에는 다음 클러스터의 위치를 갖게 된다는 의미이다.
[그림 7]을 보면 자세히 알 수 있다. 다만 여기서 주의할 게 하나 있다. [그림 7] 의 1번 클러스터를 보면 앞 뒤로 있는 0, 2번 클러스터와는 조금 다른 것을 알 수 있다. 0번은 [F8 FF FF F0], 1번은 [FF FF FF F7] 그리고 2번은 [FF FF FF F0]으로 되어있다. 여기서 0번 클러스터는 [그림 5]에서 설명한것과 같이 시스템이 Media Type으로 사용하고 있다.
그러면 [그림 7]의 1번 클러스터가 [그림 5]의 Partition status가 되어야 한다. 근데 그렇게 되면 [그림 4]의 내용이 맞지 않게된다. 결론부터 이야기하자면 1번 클러스터는 Bad Cluster로 인식되어 있다. 즉 잘못된 클러스터로 인식되어 사용하지 못해 시스템이 1번 대신 2번 클러스터를 Partition Status으로 설정 한 것으로 보인다. (정황 사정상 그래보이며, 필자도 추가적인 확인을 하게 될 경우 수정하도록 하겠다.) 추가적으로 Bad Cluster의 경우 [FF FF FF F7]로 표기 된다.
이제 실제 데이터 파일이 포함된 3번 Cluster부터 이야기를 해 보도록 하자. 앞서 말했듯이 윈도우 시스템에서는 파일에 용량을 부여할 때 클러스터 단위로 부여하며, 최소 1개 이상의 클러스터를 가진다. 하나의 클러스터는 8개의 섹터를 가진다.(자세한 설명은 필자의 다른 포스팅인 Boot Record 부분을 참고하라. / http://jh8992.tistory.com/entry/FileSystem-Forensics-4-FAT322)
[그림 7]처럼 파일이 하나의 클러스터만 가질 경우 [FF FF FF 0F] 로 표기된다. 이는 해당 클러스터가 파일이 갖는 마지막 클러스터이며 더이상 Link 되는 클러스터가 없음을 의미한다. 그리고 클러스터가 하나 이상의 클러스터를 가질 경우 앞 클러스터의 가장 앞부분에 다음 클러스터의 위치를 담게 된다. [그림 7]을 보면 5번째 클러스터에서 새로운 파일이 시작됨을 알 수 있다. 그리고 그 클러스터 부터 다음 클러스터들을 쭈욱 보면 하나의 공통점을 알 수 있는데 그것은 바로 클러스터의 가장 앞에 다음 클러스터의 번호가 쓰여있으며 나머지는 0으로 채워져 있다는 점이다.
이는 클러스터가 항상 연결된 Link를 갖지 않기 때문이다. 완전히 포멧된 깨끗한 파일 시스템의 경우 FAT 영역이 꺠끗하기 때문에 순서대로 채워지겠지만 파일이 생성되고 지워짐을 반복함에 따라 모든 클러스터가 순서를 유지할 수 없게 된다. 이러한 경우를 대비해서 모든 클러스터는 자신의 위에 다른 클러스터가 연결 될 경우 다음 클러스터를 명시하도록 되어있다. 물론 파일의 용량이 작아 단일 클러스터만 가지고 있거나 더이상 연결될 클러스터가 없는 마지막 클러스터일 경우 [FF FF FF 0F] 값을 가지게 된다.
어떻게 보면 앞에서 설명한 Boot Record 부분보다는 단순한 구조를 가지고 있는 영역임에도 상당히 길게 서술된 느낌이 있다. 그림이 많이 포함됐거나 하는 여러 이유등이 있을 수 있지만 가장 큰 이유는 이후 포스팅 할 파일 수동 생성 부분에서 이 FAT 영역이 상당히 중요하기 때문이다. Root Directory 영역에 대해 공부하거나, Data 영역에 파일을 수동으로 생성 할 때 다른 곳을 모두 정상적으로 적용했다고 하더라도 FAT 영역의 클러스터가 맞지 않으면 정상적으로 파일이 열리지 않기 때문이다.
그렇기 때문에 상당히 단순한 구조임에도 확실하게 알고 갈 필요가 있다. 여러분이 공부하는데 이 포스팅이 쉽게 이해되길 빌어본다.
* 참고 : 임베디드 개발자를 위한 파일시스템의 원리와 실습(정준석, 정원용 공저), 한빛미디어
'보안 > Forensics_With_간서치' 카테고리의 다른 글
| [FileSystem Forensics] 7. FAT32#5_FileName Type (0) | 2017.10.03 |
|---|---|
| [FileSystem Forensics] 6. FAT32#4_Root Directory Entry (0) | 2017.09.27 |
| [FileSystem Forensics] 4. FAT32#2_Boot Record (0) | 2017.07.09 |
| [FileSystem Forensics] 3. FAT32#1_환경구성 (2) | 2017.06.09 |
| [FileSystem Forensics] 2. MBR 기초 (0) | 2017.06.05 |
