IT 전반에 애플(Apple) 열풍이 불고 있다. 아이폰, 아이패드뿐만 아니라 노트북 분야에서도 마찬가지이다. 맥북 에어의 활약에 힘입어 애플 노트북의 판매량이 급증하고 있다. 기존에 윈도우(Windows)를 사용했던 사용자들이 MAC을 접하게 되면서, MAC OS에 대한 관심도 높아졌다.
이에 따라 MAC OS에 대한 사건사고 또한 급증할 것으로 예상된다. 기업의 보안 관리자에게 MAC OS와 관련된 사건사고를 처리해야 하는 업무가 들이닥칠 일이 머지 않았다는 것이다.
이 글에서는 사용자들과 보안 관리자들을 위한 MAC OS에 대한 분석 방법인 ‘MAC 포렌식(Forensics)을 소개하고자 한다. MAC 포렌식은 월간 ‘안’을 통해 2부에 걸쳐 소개될 예정이다. 이번 2011년 2월호에서는 HFS+의 파일 시스템과 파일 복구에 대해 알아보고, 다음 호에서는 MAC에서 정보를 수집하는 방법에 대해 살펴보자.
연재 목차 1. HFS+의 파일 시스템과 파일 복구(2011년 2월호) 2. MAC에서 정보 수집(2011년 3월호) |
포렌식을 위한 분석을 진행할 경우, 가장 먼저 하는 것이 정보 수집이다. 정보 수집 즉, 라이브 데이터 수집이란 네트워크 연결 정보, 동작중인 프로세스 등 분석에 필요한 데이터를 수집하는 행위를 말한다. 하지만, 분석 과정에서 파일이 삭제되거나 이미지에서 파일을 불러와야 할 경우에는 속수무책인 경우가 많다. 이러한 문제를 해결하기 위해서 윈도우의 경우, 이를 지원해주는 도구가 여러 가지가 있다. 그에 반해 MAC 이미지를 분석할 수 있는 툴은 그리 많지 않아 분석가들이 어려움을 겪게 된다. 이러한 어려움을 해결하고 더 깊이 있는 분석을 진행하기 위해서는 파일 시스템에 대한 이해가 반드시 필요하다. 지금부터 본격적으로 HFS+의 파일 시스템과 파일 복구에 대해 심층적으로 소개한다.
HFS + 파일 시스템이란? HFS 플러스(HFS Plus, HFS+)는 애플이 개발한 파일 시스템이다. 계층 파일 시스템(Hierarchical File System, HFS)을 대체하기 위해 개발되었다. - 위키피디아 - |
1. MAC Mount 정보 및 이미지 생성
HFS+와 파일 복구를 진행하기 위해서는 파일 시스템의 이미지(Image)를 생성해야 한다. 이 때 가장 먼저 현재 시스템에 마운트(Mount)되어 있는 정보를 확인한다. 마운트 정보를 확인하는 명령어는 아래와 같다.
[예시 1] 마운트 정보를 확인하는 명령어 수행
이를 통해 다음의 결과를 확인할 수 있다.
[예시 2] 마운트 정보 확인 명령어 수행 후 결과값
※ df 명령어: 마운트되어 있는 디스크의 사용량을 보여주는 도구
마운트되어 있는 장비 중 /dev/disk1s1과 /dev/disk2s1은 이미지 생성에 사용된다. 또한 /dev/disk1s1의 이미지를 /dev/disk2s1에 저장하기 위해 아래와 같은 명령어를 수행한다.
[예시 3] 이미지 저장을 위한 명령어
※ dd 명령어: 옵션에 따라 파일을 덤프, 변환 및 포맷이 가능한 도구
※ if => input file, of => output file bs => block size to n bytes
이 명령어를 수행하면 /dev/disk1s1이 사용 중이라는 에러 구문을 만나게 된다. 이와 같은 에러 구문을 만날 경우, disk1s1을 Eject한 후 명령어를 수행하면 된다.
[예시 4] 에러 구문에 대처하는 명령어 수행
DD 명령어로 만들어진 이미지를 파일(file) 명령어를 사용하여 확인해 본 결과, 파일의 블록 사이즈는 4096이며, 블록의 개수는 131062이다. 이 값을 곱하면 536829952가 나오게 되며, 실제 하드 디스크 용량이 512M라는 것을 알 수 있다.
[예시 5] DD 명령어로 확인할 수 블록 사이즈 및 블록 개수
2. 엔케이스(Encase)로 이미지 확인
미국 가디언스 소프트웨어(Guidance Software)사의 포렌식 소프트웨어인 엔케이스(Encase)를 사용하여 만들어놓은 이미지를 확인한 결과, 디스크에 존재했던 디렉터리 내용을 확인할 수 있다. 확인한 내용은 [그림 1]과 같다.
[그림 1] 엔케이스를 이용하여 디스크에 존재했던 디렉터리 내용 확인
[그림 1]과 같이 테스트 목적으로 웹쉘(cmd.php), 실행 파일(nc.exe), 그림파일(ahnlab.jpg)을 각각 1개씩 총 3개를 이미지에 넣어두었다. 엔케이스를 사용하여 복구하는 방법은 [그림 2]와 같다.
[그림 2] 엔케이스를 이용한 복구 방법
엔케이스만을 사용해서 해당 파일들을 살려낼 수 있다. 하지만 엔케이스의 경우, 유료 소프트웨어이기 때문에 기업에서 쉽게 도입해서 사용할 수가 없다. 그렇다면, 지금부터 본격적으로 무료 툴을 사용하여 파일을 복구하는 방법을 알아보자.
3. HFS+ 파일 시스템과 파일 복구
파일을 복구하는 방법을 알아보기 위해 가장 선행되어야 하는 것은 HFS+ 파일 시스템의 전반적인 구조를 이해하는 것이다. HFS+ 파일 시스템의 구조는 [그림 3]과 같다.
[그림 3] HFS+ 파일 시스템의 구조
3-1. 헥스에디터(HexEditor)로 이미지 확인
우선 헥스에디터(HexEditor)로 이미지를 점검해보자. 헥스에디터는 파일을 헥스(Hex) 형식으로 오픈하여 편집하거나 생성할 수 있는 프로그램이다. 확인한 결과를 보면, 1024 오프셋(offset)에서부터 볼륨 헤더(Volume Header)가 시작되는 것을 알 수 있다. 볼륨 헤더의 처음에는 H+라는 시그니처가 존재한다. 이 H+ 시그니처는 HFS+(Hierarchical File System)라는 파일 시스템임을 알려주는 것이다.
[그림 4] 헥스에디터(HexEditor)로 이미지를 점검한 결과
볼륨 헤더에는 파일의 오프셋과 위치 등을 기록하고 있는 카탈로그(Catalog) 파일에 대한 정보를 가지고 있다. Volume Header에서 카탈로그 파일에 대한 정보는 [그림 5]와 같이 확인 가능하다.
[그림 5] 볼륨 헤더에서 확인할 수 있는 카탈로그 파일 정보
[그림 5]에서 카탈로그 파일의 위치는 37EF이며, 크기는 3FF임이 확인되었다. 37EF는 실제 이미지에서 37EF000이다. 또한 크기로 확인된 3FF는 3FF000이다.
[그림 6] 카탈로그 파일의 위치 및 크기
3-2. 파일 시스템
HFS+에는 카탈로그 파일을 제외하고 여러 파일들이 존재한다. 그러나 이번 주제는 이미지에서의 파일 복구이므로 HFS+에서 필요한 정보만을 확인하도록 하겠다. 앞서 ‘3-1. 헥스에디터로 이미지 확인’에서 언급한 것과 같이 파일 복구에 필요한 내용은 볼륨 헤더와 카탈로그 파일에서 확인할 수 있다. 파일 시스템의 레이아웃(Layout)과 카탈로그 파일의 위치에 대한 정보는 [그림 7]과 같다.
[그림 7] 파일 시스템의 레이아웃과 카탈로그 파일의 위치 정보
※ dataFork는 data에 대한 장소와 크기에 대한 정보를 가지고 있음.
※ resourceFork는 data의 메타데이터 정보를 가지고 있음(시간정보, 삭제여부 등).
카탈로그 파일을 찾아가게 되면 아래 [그림 8]과 같이 B-Tree로 이루어진 구조체를 확인할 수 있다. 수동으로 파일을 복구하기 위해서는 B-Tree에 대한 이해가 어느 정도 필요하다.
[그림 8] 카탈로그 파일의 B-Tree 구조
3-3. B-Tree
앞서 살펴본 바와 같이, HFS+안에 카탈로그 파일은 B-Tree구조로 이루어져 있다. B-Tree구조는 여러 개의 노드(node)들로 이루어져 있으며, 크게 헤더 노드(Header node), 인덱스 노드(Index node), 리프 노드(Leaf node)가 있다. 노드의 구조는 [그림 9]와 같다.
[그림 9] 노드(node)의 구조
헤더 노드는 First leaf node pointer, root node pointer, Last leaf node pointer를 가지고 있다. 하나의 노드 크기는 노드 사이즈에 기입되어 있다. 이는 [그림 10]의 오프셋(offset) 0x20에서 확인이 가능하다. 진행 중인 이미지의 노드 크기는 0x1000(4096)이다. [그림 10]에서 빨간 화살 표는 해당 노드의 개수를 의미한다.
[그림 10] 노드(node)의 상세 구조
[그림 10]과 같이 결과적으로 파일의 정보를 확인하기 위해서는 리프(Leaf nodes)를 확인해야 한다. 노드들은 위의 헥스(hex) 값으로 확인한 것과 같이 0x1000이므로 0x1000만큼씩 이동하여 B-Tree 구조를 확인하면 된다. 리프 노드를 확인하는 방법은 노드의 가장 처음에 위치하고 있는 14byte의 노드 디스크립터(node descriptor)에서 kind 값을 확인하는 것이다. kind 값을 확인하는 방법은 [그림 11]과 같다.
[그림 11] kind 값 확인하는 방법
리프 노드를 찾았으면 노드 사이즈를 더해 ‘offset to record 0’이 있는 장소로 이동한다. 그 결과, [그림 12]와 같은 헥스 값들을 확인할 수 있다. 2byte 값은 각각의 오프셋을 나타낸다. 만약 노드의 8000이면 가장 뒤에 있는 0xE를 더하여 800E를 확인한다. 확인 결과, 노드 디스크립터의 시작과 끝이라는 것을 알 수 있다.
[그림 12] 노드의 offset to record 확인
※ 뒤에서부터 차례대로 0x800E, 0x807E, 0x80A0 ………. 등으로 이동하면서 node의 offset을 확인할 수 있음.
단, 실제 이미지에서의 위치는 0x037F7FFF부터 “0x00 0x0E”이다(그림 13 참조).
[그림 13] 실제 이미지의 위치
3-4. 이미지에서 파일 복구
지금까지 B-Tree 구조를 확인하면서 실제 오프셋을 찾아가는 것을 진행했다. 이제부터 실제 이미지에서 데이터의 정보를 확인하여 파일을 복구해보도록 하자.
먼저 복구가 진행되는 오프셋으로 이동한다. 이동 후 노드 사이즈를 더한 후 오프셋을 확인한 다음 복구한 파일의 정보를 확인한다.
[그림 14] 복구 파일의 정보 확인
확인된 정보 중 복구하고 싶은 파일을 선택한 후 startBlock과 BlockCount를 확인한다. startBlock과 BlockCount를 확인하는 방법은 아래와 같다.
0x02(속성 + 이름의 길이) + 0x1A(2byte에 쓰여있는 값) + 0x6A |
위의 식을 이용하여 StartBlock(0x6EAD)과 BlockCount(0x0A)를 확인했다. 확인한 값을 이용하여 파일을 복구하기 위해서는 0x6EAD * 0x1000을 하여 이동한 후 0x0A * 0x1000만큼 덤프(dump)해야 한다.
[그림 15] 복구할 파일의 StartBlock과 BlockCount
덤프하기에 앞서 해당 오프셋으로 이동 후 실제 파일 내용을 확인해보자. 확인 결과 파일명(ahnlab.jpg)과 마찬가지로 jpg 시그니처를 가지고 있는 것으로 확인되었다.
[그림 16] 복구할 파일의 시그니처 확인
이제 이미지에서 dd 명령어를 사용하여 파일 복구를 진행해보자. 사용된 명령어는 [그림 16]과 같다.
[그림 17] dd 명령어를 이용한 파일 복구
※ bs=4096(0x1000 block size), skip=28333(0x6EAD) count=10(0x0A)
복구한 파일을 확인한 결과, 아래와 같이 JPG의 시그니처를 정상적으로 확인할 수 있다. .
[그림 18] 파일 복구 후 JPG 시그니처 확인
이 모든 과정을 거치면 [그림 19]와 같이 완벽히 복구된 이미지 파일(ahnlab.jpg)을 확인할 수 있다.
[그림 19] 복구가 완료된 JPG 파일
지금까지 HFS+의 파일 시스템과 파일복구에 대해 알아보았다. 다음 호에서는 MAC이 가지고 있는 정보를 수집하는 방법에 대해 자세히 소개할 예정이다.@
보안정보의 저작권은 저자 및 ㈜AhnLab에 있으므로 무단 도용 및 배포를 금합니다.
이 정보에 대한 저작권은 AhnLab에 있으며 무단 사용 및 도용을 금합니다.
단, 개인이 비상업적인 목적으로 일부 내용을 사용하는 것은 허용하고 있으나, 이 경우 반드시 출처가 AhnLab임을 밝혀야 합니다.
기업이 이 정보를 사용할 때에는 반드시 AhnLab 의 허가를 받아야 하며, 허가 없이 정보를 이용할 경우 저작권 침해로 간주되어 법적인 제재를 받을 수 있습니다. 자세한 내용은 컨텐츠 이용약관을 참고하시기 바랍니다.
정보 이용 문의 : contents@ahnlab.com
