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


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


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




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


Day2.zip


계속해서 ReFS를 알아보자.

이번 글에서는 ReFS의 주요 설계 개념과 특징에 대해서 알아 볼 것이다.

[코드 재사용]
ReFS는 NTFS에서 사용하던 파일시스템 API등을 그대로 다시 재사용 하여 NTFS와의 호환성을 유지하였는데, 코드 재사용에서 해당 코드들을 사용하는 엔진은 이번에 새롭게 개발 된 엔진으로 ReFS의 주요 혁신 기술들이 포함되어 있어 ReFS에서 지원하는 주요 혁신 기술과 NTFS와의 호환성 두가지 모두를 해결 하였다.


[확장이 용이하고 신뢰성 있는 온디스크 엔진]
ReFS는 온디스크 엔진 위에서 디렉토리나 파일등을 구현하는데 저장소 엔진은 구현에 B+tree 알고리즘을 사용한다.
B+tree는 다른 tree 알고리즘에 포함될 수도 있어 확장성이 용이하고 단일 구조에서는 시스템이 간소화 되고 코드도 줄어든다. 이러한 온디스크 엔진 구조에는 '테이블' 이라는 개념이 포함되는데 해당 테이블 개념에는 참조 수단으로 Object ID가 사용 된다. 테이블은 아래와 같이 디렉터리라고 이해 할 수 있으며, B+tree 구조를 사용하기 때문에 조금 효율적이고 확장에 대해 용이 하다. 아래는 온디스크 엔진에서의 디렉토리와 파일 구조이다.

[그림 1 - 온디스크 엔진 위에서의 디렉토리와 파일 구조(출처 : MSDN Blog)]


[디스크 업데이트]
ReFS에서는 디스크 업데이트하는 방식을 설계하기 위하여 여러가지 측면에서 설계고민을 했다고 한다. 그 중 채택한 방식이 AOW(Allocate On Write) 방식인데, 이 방식은 메타데이터 업데이트를 원본 위치에서 하지 않고 다른 위치에 메타데이터 업데이트 내용을 기록하는 방식으로 이 방식을 통해 안정성을 극대화 하였다. NTFS는 디스크의 일관성을 유지하기 위해 트랜잭션 저널에 의존하는데 이 트랜잭션은 AOW를 기반으로 하고 있다. 


[복원력]
ReFS는 손상 된 데이터를 발견하면 자동적으로 해당 데이터를 검사하고 수정하는데, 이러한 행위들이 이루어짐으로써 데이터에 대한 무결성 보증과 시스템 가용성이 향상 되었다. ReFS의 모든 메타데이터는 B+tree page 수준에서 체크섬이 진행 되는데 이 체크섬은 해당 페이지와는 별개로 저장되어 디스크의 모든 데이터 오류들을 검출 해 낼 수 있다.
또 ReFS는 모든 디스크의 데이터를 복사하여 관리한다. 이 복사본들은 원본에 오류가 발생 했을 시 대체 데이터나 원본 데이터 오류 수정의 기준이 될 수 있다. 


[무결성 스트림]
무결성 스트림은 파일의 데이터를 오류로부터 보호 하는것이 주 목적이다. 무결성 스트림은 파일이나 디렉토리의 한가지 속성으로 분류 할 수 있으며 디렉토리에 무결성 스트림 속성이 설정 될 경우 해당 디렉토리 하위 파일이나 디렉토리에는 모두 무결성 스트림 속성이 설정 된다.

 * 참고 : 무결성 스트림 속성은 format 명령어로 설정이 가능하다. 


[Bit rot]
Bit rot이란 디스크의 데이터가 한순간 손상되지 않고 시간에 따라 서서히 손상되어 디스크 검사등에 걸리지 않는 것을 말한다. 대부분 Bit rot 데이터를 발견하게 되면 해당 복사본 까지 손상되어 있다. ReFS는 지속적인 스크러빙을 통해 원본과 복사본의 체크섬이 동일하지 않으면 복사본을 기준으로 원본을 수정토록 하였다. 파일 속성 중 FILE_ATRIBUTE_NO_SCRUB_DATA 속성이 있는데 해당 속성이 설정된 파일이나 디렉토리는 스크러빙 작업을 건너띄게 된다.

 * 참고 : Integrity.exe 프로그램은 무결성과 스크러빙 정책 관리를 하는데 사용 된다. 


[볼륨 가용성]
일반적으로 미러링 볼륨은 오류가 일어나지 않지만, 가끔 오류나 손상이 일어날 때가 있다. ReFS는 이러한 경우를 위해 볼륨에서 손상 된 데이터를 제거하고 나머지 삭제된 데이터의 나머지 부분들을 복원하는 기능을 지원한다. 그리고 일반적으로 파일시스템에 데이터가 손상되면 관리자조차 접근을 하지 못하는데 ReFS의 경우 앞서 언급했듯이 손상 된 데이터를 복구 할 수 있어 관리자가 접근 할 수 있게 하였다. 


[저장소 호환성]
ReFS와 저장소 스택의 유연성과 호환성을 극대화 하였다. 하지만 이 둘은 서로 상호작용은 하나 독립적으로 실행되는데, 이렇게 하는 이유는 유연성 관점에서 서로에게 제한되지 않게 하기 위해서이다. ReFS와 저장소 스택의 연결로 인하여 암호화, 볼륨 스냅샷 등의 기능을 완벽하게 사용 할 수 있으며, 다른 파일시스템과의 연결도 완벽하게 연동 된다. 하지만 NTFS에서 NTFS의 물리적 구조에 의존하던 응용 프로그램들은 ReFS에서는 정상적으로 작동을 하지 않을지도 모른다. 


이 특징들 외에 ReFS가 지원 가능한 용량등은 아래 이미지를 참고하도록 한다.

[그림 2 - ReFS 지원 가능한 크기 등]
 
지금까지 ReFS에 대해서 알아보았다. 아직 ReFS는 완벽하게 개발 된 단계는 아닐 뿐더러 명세도 나와 있지 않아 좀 더 시간을 두고 연구, 분석해야 할 파일시스템이다. 일단은 이러한 파일시스템이 있고 이러한 특징들을 가지고 있구나 라는 정도만 알아두었으면 하여 이렇게 언급하였다. 앞으로 NTFS를 대체할 파일시스템으로 꼭 알아두어야 할 파일시스템 중 하나가 될 것이다.

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

File System - HFS+ (1)  (0) 2012.03.22
e-discovery ?  (0) 2012.03.13
File System - ReFS (2)  (0) 2012.03.13
File System - ReFS (1)  (0) 2012.03.12
File System - Ext4 (5)  (0) 2012.03.11
이번 글부터는 windows 8에서 사용될 ReFS(Resilient File System)에 대해서 알아 볼 것이다.(NTFS도 그렇지만 MS의 경우 정확한 파일시스템의 명세를 내놓지 않는다. 그렇기에 정확한 오프셋 구조 분석등은 하지 않고 해당 파일시스템의 정보등을 알아 볼 것이다.)

사실 MS사에서 개발한 NTFS와 이번에 새롭게 개발 된 ReFS 사이에는 Protogon(windows 8 개발자 프리뷰 버전) 이라는 파일시스템이 있었다. 

하지만 금방 ReFS로 대체되어 잘 알려지지 않았다. 사라진건 알아볼 필요가 없으니 앞으로 사용 될 ReFS에 대해서 알아 볼 것이다.

ReFS는 NTFS를 기반으로 하고 있어 NTFS와의 호환성을 가지고 있다. 이런 ReFS는 현재 Windows server 8에만 시험적으로 탑재한다고 한다.

그렇기에 개인용 Windows 8은 NTFS를 아직까지 유지할 계획이다.

ReFS를 설계한 의도는 무엇이며 목표는 무엇일까?

[ReFS 목표]
 1. NTFS의 장점과 호환성을 유지하고, 시스템의 복잡성을 야기하면서 불필요한 부분은 제외
 2. 다양한 원인으로 오류가 일어날 경우 자동적으로 그 데이터를 검증하고 수정
 3. 최고의 확장성 유지
 4. 데이터의 손상이나 오류가 발생하면 해당 데이터는 따로 분리하고 나머지 데이터에 접근 할 수 있도록 하며 따로 분리한 데이터는 실시간으로 복구
 5. 완벽한 복구 기술 지원 


이번에는 ReFS의 특징을 알아보자.

[ReFS 특징]
 1. 메타데이터의 체크섬을 이용하여 무결성 검증
 2. 선택적 사용자 데이터 무결성 검증
 3. 강력한 디스크 업데이트를 위한 "쓰기 시 할당"
 4. 대용량 볼륨, 파일, 디렉토리 지원
 5. 저장소의 가상화로 파일시스템 생성과 관리의 용이성 개선
 6. 성능 개선을 위한 데이터 스트라이핑, 장애복구를 대비한 이중화
 7. 숨겨진 디스크영역으로부터의 오류를 보호해 주는 디스크 스크러빙
 8. 완벽에 가까운 복원 지원과 볼륨의 최대 가용성 보장
 9. 시스템에 여러개의 공유 저장소를 운영하여 장애 복구 능력과 부하 균형 조절 능력을 개선 

 
위에서 언급한 특징 말고도 NTFS의 여러가지 특징들(암호, 압축 등)도 ReFS에서 지원한다. 또 새롭게 추가 된 기능들로는 아래와 같은 것들이 있다.

 - BitLocker 암호화
 - USN 저널
 - 변경 알림
 - 볼륨 스냅샷
 - etc..

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

e-discovery ?  (0) 2012.03.13
File System - ReFS (2)  (0) 2012.03.13
File System - ReFS (1)  (0) 2012.03.12
File System - Ext4 (5)  (0) 2012.03.11
File System - Ext4 (4)  (0) 2012.03.11
이번 글 부터는 Ext4 파일시스템에 대하여 알아 볼 것이다.

Ext4 파일시스템은 Ext3 파일시스템의 개선버전으로 현재 대부분 리눅스에서 사용중이며 포렌식 분석 도구들도 해당 파일시스템 분석을 지원하고 있다.

많은 부분이 앞서 설명하였던 Ext 파일시스템과 동일하여 따로 파일시스템의 참조모델별로 분류하여 설명하지 않고 달라진 부분과 특징 등에 대해서 다루어 볼 것이다.

일단 Ext4 파일시스템에 특징 부터 알아보자.

[Ext4 특징]

 - 대용량 파일시스템 : Volume 크기는 1EiB, 파일 용량은 16TB까지 지원한다.

 - Extents : 이전 Ext 파일시스템은 Block mapping을 지원하였는데 Ext4 파일시스템 부터는 Extents 방식을 지원하여 블록 단편화 현상을 줄여준다.

 - 호환성 : Ext4 이전의 파일시스템을 Ext4형식으로 변경하여 Ext4 파일시스템에 마운트 하여 성능향상 상태로 사용 할 수 있다. 또 Ext4 파일시스템을 Ext4 이전 파일시스템에 마운하여 사용 할 수도 있다.

 * 참고 : Ext4 파일시스템에서 Block mapping 대신 Extents를 사용한다면 Ext4 이전 파일시스템에 마운트 될 수 없다.

 - 저널 체크섬 : 이전 Ext 파일시스템에는 없던 저널 체크섬이 추가되었다.

 - 64000개 서브 디렉토리 : Ext4 파일시스템 이전 버전들은 서브 디렉토리의 최대 개수가 32000개 였다. 하지만 이번 버전에서는 64000개로 늘어나 조금 더 많은 디렉토리를 생성 할 수 있게 되었다.

 - 온라인 조각 모음 : Ext4 파일시스템에서 새로 생긴 기능이다.

 - 파일시스템 검사 속도향상 : 파일시스템에서 사용하지 않는 부분을 건너띄고 검사하여 검사 속도가 향상되었다.

 - 타임스탬프 : Ext4 파일시스템 이전 버전에서는 초 단위로 1901년 12월 14일 ~ 2038년 1월 18일까지 시간을 기록 할 수 있었지만 Ext4 파일시스템부터는 나노초로 계산되며 1901년 12월 14일 ~ 2514년 4월 25일 까지 기록 할 수 있게 되었다.

 - 지연할당 : 해당 기능은 Ext4 파일시스템에서 새로 생긴 기능으로 어떤 파일에 대한 블록 할당을 최대로 지연하여 가능한 연속블록에 할당 되게끔 하는 기능이다.

 - 멀티블록할당 : Ext4 파일시스템 이전 버전에서는 파일 기록에 여러 블록이 필요하면 보통 떨어져 있는 블록들을 할당하여 파일을 기록하곤 했는데 Ext4 파일시스템 버전부터는 멀티블록할당자를 통해 블록 여러개를 동시에 할당하여 블록이 연속되어 할당 되게끔 한다. 또 이러한 기능으로 인해 블록 호출 회수가 줄어들어 할당 속도도 빨라졌다. 

 

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

File System - Ext4 (3)  (0) 2012.03.11
File System - Ext4 (2)  (0) 2012.03.09
File System - Ext4 (1)  (0) 2012.03.09
File System - UFS (9)  (0) 2012.03.08
File System - UFS (8)  (0) 2012.03.07
이번 글에서는 NTFS 인덱스의 속성에 대해서 알아 볼 것이다.

NTFS에서 b-tree를 사용한다고 앞 글에서 언급 했었는데 해당 트리에서는 노드에서 값을 저장하기 위해서 "인덱스 엔트리(Index Entry)" 라는 데이터 구조체를 사용한다.

인덱스 엔트리는 많은 타입들을 가질 수 있고, 모두 표준 헤더 필드를 사용한다.

인덱스 엔트리는 노드의 구성원이며, 비어 있는 인덱스 엔트리는 노드의 마지막을 뜻한다.

인덱스 엔트리의 구조는 단순하다. 헤더와 속성으로 이루어져 있는데 정확한 것은 아래 이미지에서 확인 할 수 있다.

 [그림 1 - 인덱스 엔트리 구조]

인덱스 엔트리를 구성원으로 가지고 있는 노드들은 MFT 엔트리 속성 두 개에 따라 저장방식이 달라진다.

만약 속성이 $INDEX_ROOT 속성이라면 항상 거주 속성을 가져 노드는 한개만 MFT 엔트리에 저장된다.

만약 노드가 여러개라면 $INDEX_ALLOCATION 속성이 할당 되는데 이 속성은 비거주 속성이다.


이 속성의 내용은 하나 또는 그 이상의 인덱스 레코드를 포함하는 버퍼(클러스터)인데, 인덱스 레코드 인덱스 엔트리의 집합이다.

 * 참고 : 트리의 노드와 인덱스 레코드가 비슷한 개념이라고 생각하면 된다.

인덱스 레코드의 크기는 4096byte 이며, 고정된 크기이다. 또 인덱스 레코드는 인덱스 엔트리들의 목록을 포함하고 있다.

인덱스 레코드의 주소는 0으로 시작한다. 아래는 두 속성에 대한 정보를 도식화 한 것이다.

 [그림 2 - 속성 별 저장 방식]

위 이미지에서 보면 인덱스 레코드에 할당되지 않은 영역들이 있는데 이 영역들은 할당이 가능한 상태이다.

인덱스의 레코드 할당 상태는 $BITMAP 속성에서 관리하는데, 새로운 노드를 트리에 할당하려고 할 때 $BITMAP 속성은 사용 가능한 인덱스 레코드를 찾게 된다.

인덱스 엔트리에는 자식 노드가 있는지를 판별하게 도와주는 플래그 값이 포함되어 있다.

자식 노드가 있다면 자식 노드의 인덱스 레코드 주소가 부모 인덱스 엔트리에 포함된다. 

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

File System - NTFS (8)  (0) 2012.02.09
File System - NTFS (7)  (0) 2012.02.09
File System - NTFS (6)  (0) 2012.02.09
File System - NTFS (5)  (2) 2012.02.08
File System - NTFS (4)  (0) 2012.02.08

+ Recent posts