HFS

파일시스템 역사

HFS+ 파일시스템은 MAC OS 8.1버전(1998년)부터 도입된 파일시스템으로 기존의 HFS(Hierarchical File System)을 대체, 개선하기 위해 개발되었다. HFS는 유닉스 파일 시스템인 UFS를 기반으로, 매킨토시 전용 파일시스템으로 저널링을 사용하지 않았지만 여러 가지 한계점이 판단되어 저널링 기능을 선택적으로 포함할 수 있도록 발달되면서 HFS+ 혹은 HFSX 파일시스템이라 불리게 되었다. HFS+ 파일시스템은 MAC OS Extended 라고도 부른다. HFS+는 이전 버전인 HFS와 구조가 거의 비슷하나, HFS보다 더 큰 파일과 용량을 지원하고 Unicode, 긴 파일 이름(255자)을 지원하는 등 기능이 크게 개선되었다. 아래의 표는 HFS와 HFS+ 세부 비교표이다.

HFS와 HFS+ 비교

특 징	HFS	HFS+
파일시스템 명칭	Mac OS Standard	Mac OS Extended
할당블록 수	16 bits worth	32 bits worth
파일이름 길이	31 characters	255 characters
파일이름 인코딩	MacRoman	Unicode
파일/폴더 속성	Support for fixed size attributes	Allows for future meta-data Extensions
OS 부팅 지원	System Folder ID	Also supports a dedicated startup file
카탈로그 노드 크기	512 Bytes	4 KB
최대 파일 크기	2GB(231Bytes)	8EB(263Bytes)

HFS 파일 시스템은 1998년 1월 19일 MAC OS 8.1에 적용되며 처음 출시되었고 2002년 11월 11일 10.2.2 버전이 처음으로 저널링 기능을 사용 가능하게끔 출시되어 현재의 HFS+ 파일 시스템이 개발되었다. HFS+ 파일 시스템은 유닉스 파일 시스템인 UFS를 기반으로 제작되어 다른 유닉스 및 리눅스 계열의 파일 시스템과 비슷한 구조를 띄고 있다.

파일시스템 특징

HFS+ 파일시스템을 디자인할 때 중점을 둔 개선 목표는 효율적인 디스크 공간 사용, 유니코드 파일 이름 지원, Named Forks 지원, Mac OS가 아닌 OS에서의 부팅 지원에 있다. HFS는 볼륨 전체 크기를 동일한 크기의 조각으로 나누는데 이를 할당 블록이라고 한다. 특정 할당 블록을 가리키기 위해서 16비트를 사용하는데 이것은 할당할 수 있는 블록의 개수가 2¹⁶(65,536)개라는 것을 의미한다. 보통 볼륨에서 섹터(512바이트)의 배수를 블록으로 지정하는데 가리킬 수 있는 블록의 개수가 정해져 있으므로 큰 용량의 볼륨에서는 블록 크기가 커질 수밖에 없다. 따라서 볼륨 크기가 클수록 HFS는 사용하지 않는 용량 공간이 증가하여 효율성이 떨어지게 된다. HFS+는 할당 블록을 가리키는 데 32비트를 사용한다. 따라서 2³² (4,294,967,296)개의 블록을 가리킬 수 있다. 큰 용량의 볼륨에서 블록 크기를 작게 지정하여 디스크 공간을 효율적으로 사용할 수 있고 더욱 많은 파일 개수를 저장할 수 있다. HFS는 파일이름을 저장하는데 31바이트를 사용하며 파일 이름에서 어떤 종류의 언어를 사용하는지 알 수 있는 정보를 포함하지 않는다. 또한 파일이름이 로마자 외에 다른 문자는 고려하지 않았기 때문에 문제가 발생한다. HFS+는 유니코드로 255자까지 파일이름으로 사용할 수 있다. 긴 파일이름은 파일 명을 세부적으로 만들 때 도움이 되고 시스템에서 자동으로 생성되는 파일(예: 자바 클래스 파일 이름)의 경우 특히 유용하다. HFS+가 긴 파일 이름을 지원하여 catalog B-Tree 노드에서 파일이름으로 512byte까지 사용할 수 있으므로 HFS+는 catalog B-Tree의 노드 크기가 4KB로 커졌다. (HFS의 catalog B-tree 노드 크기는 512Byte) HFS 볼륨에서 파일들은 data fork와 resource fork 두 가지 종류의 fork를 가진다. 파일과 디렉터리는 수정시간, finder info 같은 추가적인 정보(catalog information 또는 메타데이터)를 가진다. 개발자들은 종종 특정 파일이나 디렉터리와 관련된 정보를 저장할 필요가 생긴다. 파일의 커스텀 아이콘 같은 경우는 resource fork와 관련이 되어 있으나 저장하려는 정보가 기존의 data fork, resource fork와 관련이 없어 저장하기 어려운 경우가 생긴다. 다수의 소프트웨어들이 파일이나 폴더와 관련된 추가 정보를 저장하기 위해 특별한 솔루션을 구현한다. 그러나 이런 것들은 파일시스템에 관리되는 것이 아니기 때문에 파일, 디렉터리 구조와 조화롭지 못하다. HFS+는 속성 파일(Attribute file)을 가지고 있어서 파일이나 디렉터리와 관련된 부가적인 정보를 저장할 때 사용할 수 있다. 이것은 볼륨 포맷의 한 부분이기 때문에 파일, 디렉터리가 지워지거나 이동되거나 할 때 연관 지어서 동작한다. 속성 파일(Attribute file)의 내용은 아직 전부 다 정해지지는 않아서 나중에 임의적으로 지정하여 사용 가능하다. HFS+에서는 Startup file이라는 개념을 포함한다. 부팅 시에 ROM에서 HFS, HFS+를 지원하지 않는 시스템의 경우 부팅할 때 Startup file을 참조하여 부팅을 할 수 있다.

구조분석

HFS+는 서로 연관성이 있는 다수의 구조체를 사용한다. HFS+의 구조는 아래와 같다.

볼륨헤더(Volume header)는 볼륨의 생성시간, 볼륨 내 파일 개수 등 볼륨과 관련된 정보뿐 만 아니라 볼륨의 중요한 구조의 위치 및 크기 등의 정보를 가지고 있다. 볼륨 헤더는 볼륨의 시작부터 1,024byte 위치에 있다. Alternate volume header는 볼륨헤더의 복제본으로써 볼륨 마지막 위치에서 1,024byte 위치에 저장되어 있다. 볼륨 처음에서 1,024byte(볼륨 헤더 이전)와 마지막 512byte(alternate volume header 이후)는 다양한 상황을 고려하기 위한 reserved 영역으로 비워져 있다. HFS+ 볼륨은 5개의 특별한 파일(special files)로 구성된다. special file은 파일시스템 내부(파일들, 디렉터리, 속성 등)에 접근하기 위한 파일시스템 구조를 저장하고 있다. Special file은 Catalog file, Extents overflow file, Allocation file, Attributes file, Startup file이 있다. Catalog file은 볼륨의 파일과 디렉터리의 계층구조를 저장하고 있으며 Catalog file은 B-tree구조로 구성되어 있어 빠르고 효과적인 검색이 가능하다. Extents Overflow File은 B-tree 노드에 데이터를 모두 저장하지 못하였을 경우 남은 데이터를 저장하는 영역이다. Allocation file은 Allocation block이 할당되어 있는지 비워져 있는지에 대한 정보를 가지고 있다. Attributes file은 파일과 폴더에 대한 추가적인 속성 정보를 가지고 있다. Startup file은 Mac OS가 아닌 OS에서 HFS+를 사용할 때 부팅이 가능하게 해주는 파일이다.

메타데이터

대부분의 파일시스템이 디렉터리 표현을 위해 트리 구조를 사용하듯이 HFS+ 파일시스템에서는 볼륨에 있는 파일과 폴더들의 계층 구조를 Catalog File을 통해 유지 및 관리하고 있다. Catalog File은 B-tree 구조를 사용하여 데이터를 저장하고 있다. B-tree는 헤더 노드(Header node), 인덱스 노드(Index node), 리프 노드(Leaf node)로 구성되어 있으며 필요할 경우 맵 노드(Map node)도 사용된다.

파일 추출 기법

파일 접근 과정은 카탈로그에서 루트 노드로 접근해 원하는 파일이 존재하는 리프 노드까지 접근 한다. 리프 노드에서 실제 데이터의 위치를 알 수 있으며 실제 데이터가 존재하는 위치를 계산하여 파일을 추출할 수 있다. 카탈로그파일 접근 방법은 볼륨헤더의 카탈로그 헤더에 존재하는 StartBlock 값을 통해 카탈로그 파일의 위치를 알 수 있다. 카탈로그 파일의 시작 위치는 StartBlock * BlockSize 이다. Volume 헤더에 존재하는 BlockSize 값과 볼륨헤더의 카탈로그파일 속성에 존재하는 StartBlock 값을 곱하면 카탈로그 헤더 오프셋이 된다. 카탈로그 헤더의 Nodesize Rootnode 의 값을 곱해준 값이 루트 노드의 오프셋이 된다. 아래의 그림과 같이 카테고리 시작 위치는 0x5C09000 이다.

다음의 그림과 같이 카테고리 파일 헤더에서 루트 노드 시작 번호와 노드 사이즈 값을 알 수 있다. 루트 노드 시작 위치는 ((Nodesize * Rootnode / Blocksize) + StartBlock) * Blocksize한 값이다. 루트 노드 시작 위치를 계산하여 접근하면 아래와 같이 타입이 00인 인덱스 노드인 것을 확인할 수 있다.

리프 노드까지 Child Pointer를 통해 ((Nodesize * Childpointer / Blocksize) + StartBlock) * Blocksize한 값으로 Child 노드에 접근할 수 있다. 아래의 그림과 같이 루트노트에 접근하여 원하는 위치의 파일을 추출할 수 있다.

위의 그림과 같이 파일명과 그에 해당하는 실제 데이터 시작 주소를 알 수 있다. 0xAE4B * nodesize를 구한 위치는 아래와 같다. 위와 같은 과정으로 메타데이터 정보를 가지고 실제 데이터 위치에 접근하여 파일을 추출할 수 있다.

파일 삭제

HFS+ 파일 시스템은 메타 파일인 Catalog File에 파일의 데이터 위치를 포함한 메타정보를 담고 있다. 따라서 HFS+ 파일 시스템에 파일이 생성되면 데이터 영역에 데이터가 생성되며 동시에 Catalog File에 파일의 메타정보가 생성된다. 파일을 삭제하였을 때 HFS+ 파일 시스템에 파일의 메타정보와 데이터 영역에 어떠한 변화를 주는지 알아보기 위해 다음과 같은 실험을 하였다. OS X의 디스크를 이미징(TEST1.dd)하고, 추적할 몇 가지 파일을 삭제한 후 곧바로 다시 이미징(TEST2.dd)하여 생성된 두 개의 이미지 파일을 비교하여 삭제된 파일에 가해지는 변화를 살펴보았다. 실험 대상 파일은 ‘Lion.png’, ‘MALGUN.TTF’, ‘PSY.jpg’, ‘readme.txt’ 등 총 4개이며, TEST1.dd는 4개 파일이 모두 저장돼있는 디스크 이미지 파일이고, TEST2.dd는 ‘Lion.png’ 외에 3개 파일을 삭제한 후 이미징한 파일이다.

각 파일의 메타정보 변화

위의 그림과 같이 Catalog File에 존재하는 각 파일별 메타정보는 삭제하지 않은 ‘Lion.png’파일을 제외하고는 삭제 후 모두 다른 데이터로 바뀌어 있는 것을 확인할 수 있다. 그 형식이 비슷한 것으로 보아 삭제 후 존재하는 데이터는 다른 파일에 대한 메타정보인 것을 짐작할 수 있다. HFS+ 파일 시스템은 B-Tree로 모든 파일을 관리하기 때문에 파일이 삭제되면 트리 구조를 재조합해야 한다. 따라서 삭제된 파일의 메타정보가 위치하던 공간의 트리의 재조합 과정에서 다른 파일의 메타 정보가 위치하게 된다. 아래의 그림과 같이 ‘Lion.png’ 파일을 제외하고는 3개 파일을 삭제한 직후 디스크를 이미징 했음에도 불구하고 데이터 영역이 ‘00’으로 채워진 것을 확인할 수 있다. 이번 실험에서는 나타나지 않았지만 간혹 삭제한 파일의 메타영역은 사라졌지만 데이터 영역에는 데이터가 남아있는 경우가 있을 때도 있다. 이러한 결과를 종합하여 보았을 때, HFS+ 파일 시스템에서는 파일이 삭제될 경우 Catalog File의 파일 메타 레코드들의 트리구조를 재조합함으로 인해 삭제된 파일의 메타 정보가 덮어 쓰여 지게 된다고 할 수 있다. 또한 데이터 영역은 의도적으로 손상되진 않지만 주 파티션의 경우 운영체제의 활동으로 인해 일부 삭제된 파일의 데이터 영역은 짧은 시간 안에 덮어 쓰여 질 가능성이 있다는 것을 알 수 있다.

각 파일의 데이터 영역 변화

데이터 복구

HFS+ 파일시스템은 Allocation File에 블록의 할당 정보를 관리하고 Catalog File에 파일의 메타정보와 데이터 위치 등을 관리한다. HFS+ 파일시스템에서 파일을 삭제하였을 경우에는 Catalog File에 B-Tree로 관리되는 메타정보가 0으로 초기화 되거나 B-Tree가 재조합되면서 다른 데이터로 덮여 쓰여 지게 되어 파일의 메타정보는 복구하기 어렵다. 하지만 HFS+ 파일 시스템은 저널링 기반의 파일 시스템이기에 파일 시스템에서 일어나는 일련의 변화를 저널 영역에 기록하는데, 이 정보를 이용한다면 일부 삭제된 데이터에 대한 메타정보도 어느 정도 확인이 가능하지만 이와 같은 방법을 이용하는 도구는 존재하지 않고 또한 연구 역시 완전하지 않기 때문에 실제 수사 시 적용이 가능한 부분이 아니다. 따라서 HFS+파일 시스템에서 삭제된 파일에 대한 정보를 얻기 위해서는 비 할당 영역에 대한 데이터 카빙이 가장 적합한 방법이다. Encase와 같은 파일 시스템 분석도구에서도 이와 같은 특성으로 인해 HFS+ 파일 시스템의 경우 삭제된 파일을 복원하지 못한다.

위의 그림과 같이 파일 삭제 시 Catalog File 내용 변화를 보면 파일 삭제 후 에 Catallog File의 Leafnode 정보가 0x00으로 초기화 된 것을 확인 할 수 있다. 반면 아래의 그림을 보면 삭제 전후에 변동이 없음을 확인할 수 있다.

로그 & 저널 분석

저널의 목적은 모든 변경 사항에 대해 실제로 변경되었는지 혹은 변경이 반영되지 않았는지에 대해 보장하기 위함이다. 이를 위해 모든 변경 사항을 수집하고 저널이라는 별도의 장소에 저장하여 처리한다. 모든 변경 사항들이 저널에 완전히 기록되면 변경사항을 실제 디스크의 정상 위치에 반영한다. 이 과정에서 에러가 발생되면 완료된 항목에 대해서만 반영되고 그 이후의 변경사항에 대해서는 무시되는 특성이 있다.

은폐 대응

HFS+ 파일시스템도 다른 파일시스템과 마찬가지로 슬랙 공간과 Reserved 영역에 데이터를 숨길 수 있다. 대표적인 Reserved 영역은 Volume Header 앞의 1024바이트, 뒤의 512바이트가 있으며 Catalog File에서의 각 노드정보를 저장하는 위치에도 일부 Reserved 영역이 존재한다. 슬랙 공간과 Reserved 영역 이외에도 파일의 확장자를 변경하거나 숨김으로 설정할 수 있으며 이는 시그니처 분석 등을 통해 은폐한 파일을 확인하여 분석을 진행할 수 있다.

HFS+와 HFSX 비교 분석

Apple의 모든 모바일 장치는 HFSX 파일 시스템을 사용한다. HFSX는 HFS+로부터 변형된 주요 파일 시스템이며, HFS+ 파일 시스템과 달리 파일명의 대소문자를 구분한다. 예를 들어, 아래의 그림과 같이 HFS+ 파일시스템에서는 apple.jpg 파일과 Apple.jpg 파일처럼 대소문자명이 다른 두 파일을 생성할 경우 같은 파일명으로 인식하기 때문에 에러가 발생한다. 그러나 HFSX 파일 시스템에서는 동일한 파일명을 가지더라도 대소문자명이 다르면 각각의 파일명으로 인식하기 때문에 같은 공간에 존재할 수 있다.

HFS+ 파일 시스템에서의 에러 메시지