- 파이썬으로 파일시스템 깊이 있게 분석하기 -1-(http://maj3sty.tistory.com/1115)


이전 글에서는 이미지(Raw 포맷)에 접근하여 볼륨 정보 등을 얻어내는 작업을 해보았다. 이번에는 실제 파이썬 스크립트가 실행되는 로컬 환경 볼륨에 접근하는 방법을 살펴보자.


이미지 파일은 파일이기 때문에 파일 오픈 핸들을 pytsk3 모듈에 입력해 주면 됐지만 로컬 환경은 장치 핸들을 pytsk3 모듈에 입력을 해주어야 한다. 장치와 파일의 차이는 크지만, 코드는 이전 코드와 많이 다르지 않다. 아래 코드는 글쓴이의 가상환경에서 작성한 파이썬 스크립트와 실행 결과이다.




이번에는 NTFS 파일시스템 2개 존재하는 것을 확인할 수 있다. 로컬 환경과 이미지 파일은 접근하는 대상만 다를 뿐 다루는 방법은 동일하다는 것을 알 수 있다. 위 소스코드는 아래 첨부해 두었으니 한번 확인해 보기 바란다.


Day2.zip


디지털 포렌식에서는 기본으로 다뤄야 할 부분이 파일시스템이다. 휘발성 데이터 뿐만 아니라 비휘발성 데이터까지 모두 파일시스템에 저장되기 때문에 실제 업무에서나 챌린지 문제 풀이에서나 파일시스템 분석은 중요하다고 볼 수 있다.


그래서, 시간이 되는대로 파이썬으로 파일시스템을 다뤄보는 글을 쓸 예정이다. 언어는 사람들이 쉽게 가장 많이 쓰는 파이썬(파이썬 언어 자체의 설명은 생략한다.)으로 하여 파일시스템 이미지 포맷인 E01과 Raw 포맷을 대상으로 여러가지 분석을 할 수 있는 코드를 작성해보고 해당 소스코드는 제공할 생각이다.


일단 먼저, 파이썬 모듈이 필요하다. 우리가 주로 사용할 모듈은 파일시스템을 분석해 주는 'pytsk' 모듈이다. 각 모듈에 대한 설명은 다음과 같다.


 - pytsk : pytsk 모듈은 SluethKit과 Autopsy의 파이썬 버전이라고 생각하면 된다. 여러 운영체제의 파일시스템 분석을 지원하는 아주 유용한 툴이다. 분석 기능이 많아 사용법은 조금 까다롭다. 해당 모듈의 사용법 또한 소스코드를 작성하며 알아보도록 하자.


pytsk3-4.1.3-20140506.win32-py2.7.msi


각 모듈의 설치는 쉬우므로 설명을 생략하도록 하겠다.



소스코드 작성 환경은 다음과 같다.

 - 운영체제 : Windows 7 / 8 32/64bit

 - 파이썬 버전 : Python 2.7 32bit

 - 에디터 : PyCharm 4.x


[이미지 파일 접근 해보기]

이미지 파일은 이미지 대상 크기와 이미지 파일 포맷에 따라 처리하는 방법이 다르다. 일단 처음이니 만큼 용량이 작은 Raw 포맷을 대상으로 처리 방법을 알아보자. 모듈이 설치 되었다면 아래와 같이 'pytsk3' 모듈을 import 하여 사용하면 된다.



볼륨 파싱이 완료되면 볼륨 정보를 가지고 있는 클래스 개체 하나를 반환하며, 각 클래스 개체는 Property 함수로 필요한 데이터를 반환하도록 되어 있다. 소스코드에 나온 정보 말고도 다양한 정보가 있으니 각자 확인해보도록 하자. 스크립트를 실행하면 결과는 다음과 같다.




출력을 보면 4개의 결과가 나왔지만, "Primary Table"과 "Unallocated" 항목을 제외하면 "NTFS" 파일시스템 하나만 있는 것을 확인할 수 있다. 그러므로 해당 파일시스템을 타겟팅하여 분석을 진행해 나가면 된다.


해당 소스코드와 프로젝트는 아래에 첨부하여 두었다.


Day 1.zip


이번 글에서는 Attributes File 영역과 Startup File 영역에 대해서 알아 볼 것이다.

[Attributes File]
해당 영역은 카탈로그 파일의 속성 정보를 담고 있는 영역으로 b-tree 구조에서 노드의 크기 등을 정의하고 있는 영역이다.
해당 영역은 세 가지의 레코드 타입을 가지는데 이 레코드 타입들에 따라 길이가 달라지는 가변길이특징을 지니고 있다. 또 특이한 점은 해당 영역이 없어도 된다는 점이다. 아래는 해당 영역의 레코드 타입들이다.

[그림 1 - 레코드 타입 목록]

 - 노드 속성 : b-tree 노드들에 해당하는 속성 레코드 타입이다.

[그림 2 - 노드 속성 구조]

 - extents 기반의 속성 : fork 구조체로 정의되며 extents overflow file 영역의 노드 정보가 정의되어 있다.

[그림 3 - Extents 기반의 속성 구조]

 - 확장 속성 : 해당 타입은 별다른 것은 없고 속성의 크기만 더 늘려주는 타입이다.

[그림 4 - 확장 속성 구조]

[Startup File]
해당 영역은 부팅을 위해 사용되는 영역으로 HFS+ 부팅에 필요한 정보가 저장 되어 있다. 이러한 정보들로 부트 로더는 HFS+ 에 대한 레이아웃등 아무런 정보가 제공되지 않아도 해당 영역만을 참조하여 부팅을 수행한다.


 * 참고 : Mac OS X는 해당 영역을 참조하지 않고 HFS Wrapper 영역을 참조하여 부팅한다.



'[+] Forensic' 카테고리의 다른 글

디지털 포렌식과 하둡에 관한 고찰  (0) 2012.04.09
이메일 헤더 분석  (0) 2012.04.02
File System - HFS+ (5)  (0) 2012.03.24
File System - HFS+ (4)  (0) 2012.03.23
File System - HFS+ (3)  (0) 2012.03.23
이번 글에서는 HFS+ 에서 제일 핵심적인 Catalog File 영역에 대해서 알아 볼 것이다.

[Catalog File]
해당 영역은 파일의 주요 메타데이터들을 저장하고 있는 영역으로 b-tree 구조이다. 각 노드는 최소 4KB의 크기를 가지고 있으며 Mac OS X에서 파일이나 디렉토리에는 Catalog ID가 할당 되는데 각 ID 숫자 별 의미는 다음과 같다.

[그림 1 - CatalogID 목록]

앞서 말했듯이 카탈로그 파일 영역은 b-tree 구조라고 하였다. 그렇기에 모든 노드와 인덱스들은 키를 가지고 있으며 또 노드들의 레코드들은 네 가지 종류로 나뉘어져 있다.

[그림 2 - CatalogKey 오프셋 구조]

다음은 카탈로그 노드들의 레코드 종류이다.

[그림 3 - 레코드 종류]

각 레코드 별로 다른 구조를 가지고 있는데 그 구조는 아래와 같다.

 - 폴더 레코드 : 폴더의 정보를 기록하며 88byte의 크기를 가지고 있다.

[그림 4 - 폴더 레코드 구조]

 - 파일 레코드 구조 : 파일의 정보를 기록하며 248byte의 크기를 가지고 있다.

[그림 5 - 파일 레코드 구조]

 - 스레드 레코드 : 폴더와 디렉토리 구별 없이 스레드 레코드 구조는 동일하며, 크기는 264byte이다.

[그림 6 - 스레드 레코드 구조]

파일과 디렉토리 레코드를 보면 플래그 필드가 존재하는데 두 플래그는 동일한 플래그 목록을 지닐 수 있으며 그 목록은 다음과 같다.

[그림 7 - 플래그 목록]

이제 노드와 b-tree의 구조를 알아보자. b-tree는 크게 세 가지 구성 된다. 헤더 노드, 인덱스 노드, 리프 노드로 구성이 되는데 헤더 노드는 첫 번째 리프 노드와 루트노드, 마지막 리프 노드의 포인터를 가지고 있으며 인덱스 노드는 리프노드의 포인터를 가지고 있고 리프 노드가 실질적인 데이터를 가지고 있다. 간단하게 그림으로 표현하면 아래와 같다.

 

[그림 8 - b-tree의 노드 관계]

노드는 다음과 같은 구조이며 노드의 구분은 노드의 노드 기술자에서 정의하고 있다.

[그림 9 - 노드 구조]

다음은 노드 기술자의 구조이다.

[그림 10 - 노드 기술자 구조]

 - 노드 종류 : 헤더 노드, 인덱스 노드, 리프 노드를 구별 지어주는 필드이다. 각 노드들은 아래와 같은 값들로 구별지어진다.

[그림 11 - 노드 종류 목록]

노드 기술자 다음으로는 헤더 레코드가 위치한다. 헤더 레코드에는 노드의 여러가 정보가 기록되어 있다. 헤더 레코드 구조는 다음과 같다.

[그림 12 - 헤더 레코드 구조]

 - 속성 : 속성 목록은 아래와 같다.

[그림 13 - 속성 목록]

카탈로그 파일은 데이터를 가지고 있는 파일로 HFS+ 파일시스템에서 포렌식적으로 의미있는 파일이다. b-tree 구조를 파악하여 헤더 레코드를 통해 첫 번째 리프 노드를 확인 한 후 각 노드의 헤더 기술자를 확인하여 리프노드인지 계속 확인해 나가면서 삭제 된 데이터를 검색 할 수 있다. 

'[+] Forensic' 카테고리의 다른 글

이메일 헤더 분석  (0) 2012.04.02
File System - HFS+ (5)  (0) 2012.03.24
File System - HFS+ (4)  (0) 2012.03.23
File System - HFS+ (3)  (0) 2012.03.23
File System - HFS+ (2)  (0) 2012.03.22
계속해서 HFS+의 각 영역에 대해서 알아보자.

[Allocation File]
해당 영역은 현재 블록이 할당 되어 있는지 판단하게 도와주는 비트맵 영역이다. 해당 영역에서 비트가 설정되어 있다면 비트에 해당하는 블록은 할당 되어 있는 것을 뜻하며, 비트가 설정되어 있지 않다면 할당 가능한 상태의 블록을 뜻한다. 


[Extents Overflow]
해당 영역은 하나의 B-tree가 데이터를 모두 저장하지 못하면 남은 데이터들을 저장하는 영역이다. 해당 영역의 오프셋 구조는 다음과 같다.

[그림 1 - Extents Overflow 영역 오프셋 구조]

 - fork 타입 : fork의 타입을 정의하는 필드로 00으로 설정되어 있으면 data fork 타입이며, FF로 설정되어 있으면 resource fork 타입이다.

 * 참고 : fork란, HFS+ 에서 어떠한 파일이나 디렉토리의 크기, 블록 개수, 시작 주소 등을 저장하는 집합이다.
data fork는 data의 위치와 크기에 대한 정보를 가지고 있고 resource fork는 data의 메타데이터 정보를 가지고 있다. 









'[+] Forensic' 카테고리의 다른 글

File System - HFS+ (5)  (0) 2012.03.24
File System - HFS+ (4)  (0) 2012.03.23
File System - HFS+ (3)  (0) 2012.03.23
File System - HFS+ (2)  (0) 2012.03.22
File System - HFS+ (1)  (0) 2012.03.22

+ Recent posts