이번 글에서는 파일시스템 참조 모델 중 내용 참조 모델에 해당 하는 것들에 대해서 알아 보도록 하겠다.

[블록]
Ext 파일시스템의 블록은 NTFS와 FAT 파일시스템의 클러스터와 아주 유사한 개념으로, 보통 1024, 2048, 4096 byte의 크기를 가진다. 모든 블록에는 주소가 주어지며, 모든 블록들은 블록 그룹에 속해야만 한다.

 * 참고 : 예약 영역(부트 섹터와 부트코드가 있는 영역)의 블록들 블록 그룹에 속하지 않는다.

어떤 그룹에 속한 블록인지를 결정 하기 위해서는 아래와 같은 계산을 수행해야 한다.

 - 그룹  = (해당 블록 - 첫번째 데이터 블록) /  그룹 별 블록 수

 * 참고 : 그룹 별 블록 수는 슈퍼블록에 정의되어 있다.


[할당 상태]
블록의 할당 상태는 각 블록 그룹에 존재하는 블록 비트맵에 의해서 결정 된다.  블록 비트맵의 위치는 그룹 기술자 테이블에 정의되어 있다.  블록 비트맵의 내용은 비트로 구성되어 있는데 이 비트는 각 블록과 맵핑 관계이다. 어떠한 특정 비트가 어떠한 블록과 맵핑 관계에 있는지 확인하려면  블록 비트맵이 포함되어 있는 블록 그룹의 시작에서 확인하고자 하는 블록의 상대적 주소를 계산해야 한다. 상대적 주소를 계산하려면 블록 그룹의 첫 번째 블록을 확인해야 하는데 확인하는 방법은 아래 계산을 수행하면 된다.


 - 첫 번째 블록 = 블록 그룹 * 그룹 별 블록 수 + 첫 번째 데이터 블록

 * 참고 : 기본적으로 그룹 별 블록 수는 32768개 이다.

Ext 파일시스템은 관리목적으로 파일시스템에 할당 된 많은 블록들이 있는데 이 블록들 때문에 NTFS 처럼 파일에 모든 블록을 할당하지 않는다. 관리목적으로 파일시스템에 할당 된 블록들은 아래와 같은 것들이 있다.

 - 슈퍼 블록
 - 그룹 기술자 테이블
 - 블록과 inode의 비트맵 블록
 - inode 테이블 

 

 

[할당 알고리즘]
Ext 파일시스템의 할당 알고리즘은 OS에 따라 달라 질 수 있다. 리눅스의 경우 블록을 블록 그룹에 기초해서 할당 하며, inode를 블록에 할당하려고 할 때 '첫 번째 적용' 정책을 사용한다. 또 inode와 동일한 그룹 내의 블록을 할당한다.
이는 하드디스크의 헤드가 불필요한 동작을 하지 않게끔 하기 위해서이다. 또 리눅스는 파일의 크기가 일정 크기보다 크면 '다음 적용' 정책을 사용하여 현재 파일의 다음 블록부터 할당 할 블록을 찾는다.

 * 참고 : 리눅스는 블록에 데이터를 저장 할 때 사용되지 않는 공간은 0으로 덮어 씌운다.


[분석 시 주의 사항]
Ext 파일시스템의 경우 블록 그룹의 순서에 따라 데이터가 덮어 씌어지는 시간이 다르다. NTFS와 FAT의 경우 클러스터에 데이터가 덮어 씌어지는 기회가 동일한 반면, Ext 파일시스템은 그렇지 않다. 또 Ext 파일시스템은 블록 그룹을 기초로 하기 때문에 키워드 검색 시 파일시스템 전체가 아닌 블록 그룹 단위로 키워드 검색을 할 수 있다.



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

File System - Ext (5)  (0) 2012.02.22
File System - Ext (4)  (0) 2012.02.21
File System - Ext (3)  (0) 2012.02.21
File System - Ext (2)  (0) 2012.02.20
File System - Ext (1)  (0) 2012.02.20
이번 글에서는 NTFS에서 내용 참조 모델에 해당하는 것에 대해 알아 볼 것이다.

[클러스터]
NTFS에서 파일은 속성의 집합이라고 말 할 수 있는데, 일부 속성은 거주 속성으로 MFT 엔트리에 존재하게 되고, 나머지 속성들은 비거주 속성으로 MFT 엔트리가 아닌 클러스터에 그 내용이 존재하게 된다.
NTFS에서 클러스터는 다른 파일시스템과 마찬가지로 연속적인 섹터의 그룹을 의미한다. 클러스터 수는 2의 제곱이어야 한다. 
FAT 파일시스템과는 다르게 NTFS에서는 클러스터 주소가 0으로 시작하며, 클러스터 0은 파일시스템의 첫 번째 섹터를 포함한다. 클러스터 주소를 섹터 주소로 변환하기 위해서는 아래와 같은 공식을 적용한다.

 - 섹터 = 클러스터 * 클러스터 별 섹터 수

NTFS에서는 클러스터가 어떠한 파일이나 속성에도 할당 될 수 있지만, $Boot 파일은 예외이다. $Boot 파일은 부트 섹터를 포함하기 때문에 무조건 첫 번째 클러스터에 할당되기 때문이다. 


[$Bitmap]
해당 파일은 클러스터의 할당 상태를 결정한다. 해당 파일 $DATA 속성은 파일시스템 내 모든 클러스터와 매칭되는 1개의 비트를 가지고 있다. 비트가 1로 설정되면 해당 클러스터는 할당 상태인 것을 의미하며, 비트가 0으로 설정되면 해당 클러스터는 비 할당 상태인 것을 의미한다. 


[$BadClus]
해당 파일은 불량 클러스터를 관리하는 메타데이터 파일로, MFT 아홉 번째 엔트리이다. 해당 파일에는 $DATA 속성이 2개 있는데 하나는 기본적인 $DATA 속성으로 크기가 0이다. 나머지 하나는 $Bad라고 불리는데 sparse 파일이며, 클러스터가 손상되었다고 보고 될 시 클러스터 주소가 해당 속성에 포함된다.
처음에 $Bad 라고 불리는 이 $DATA 속성에는 아무것도 포함되어 있지 않다. 


NTFS는 할당 알고리즘으로 "best-fit" 을 사용한다. 

간단하게 best-fit 알고리즘을 설명하자면, 해당 알고리즘은 할당 가능한 클러스터 크기 중 제일 작은 클러스터 크기에 할당하는 알고리즘이다. 다른 알고리즘에 비해 공간 효율성이 제일 좋은 알고리즘이다.

[파일시스템 레이아웃]
NTFS의 레이아웃은 윈도우 버전마다 조금씩 다르지만 기본 개념은 동일하다. NTFS를 사용하는 윈도우 버전 모두 MFT 예약 영역이라는 것을 사용하는데, MFT 예약 영역이란, 파일 할당으로 인해 MFT 엔트리가 생성되고 MFT가 확장되면 MFT가 파일에 할당 되고 난 이후 해당 영역이 쉽게 단편화 될 수 있는 것을 막기 위해 파일시스템에 MFT만을 위한 클러스터 집합을 정해놓은 것을 말한다. 영역의 크기는 파일시스템의 12.5%이다.
만약 파일시스템이 모든 영역을 파일과 디렉토리 할당에 사용했다면 추후 파일과 디렉토리를 할당 할 시 MFT 예약 영역을 사용하게 된다. 그리고 모든 윈도우 버전들은 $Boot 파일을 첫 번째 클러스터에 할당한다.
위 조건을 제외하면 각 윈도우 별 레이아웃이 조금씩 다르다. 아래는 window 2000 과 XP를 비교한 그림이다.
 

[그림 1 - 윈도우 버전 별 NTFS 레이아웃]

Windows 2000의 경우 파일시스템 1/2 지점에 $Boot, $AttrDef, $MFT 파일을 제외한 다른 메타데이터 파일들이 위치하고, Windows XP의 경우 1/3 지점에 메타데이터 파일이 위치한다. 


[분석 시 주의사항]
해당 참조 모델의 분석을 수행 할 경우 주의해야 할 사항은 다른 파일시스템과 대부분 동일하며, 특이점이라면 해당 파일시스템은 모든 섹터에 클러스터가 할당 되기 때문에 키워드 검색 기술인 논리적 볼륨 검색과 논리적 파일시스템 검색의 결과 차이가 없다. 한가지 참고로 수행해야 할 것은 불량 클러스터들을 검사하는 것이다. 대부분의 불량 클러스터들은 파일시스템이 처리하기전에 디스크에서 먼저 처리하여 다시 할당되기 때문이다. 

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

File System - NTFS (10)  (0) 2012.02.13
File System - NTFS (9)  (0) 2012.02.10
File System - NTFS (8)  (0) 2012.02.09
File System - NTFS (7)  (0) 2012.02.09
File System - NTFS (6)  (0) 2012.02.09
이번 글에서는 FAT 파일시스템에서 내용 참조 모델과 비슷한 데이터를 포함하고 있는 데이터 영역에 대해서 알아 볼 것이다.

데이터 영역은 클러스터로 구성되어 있다.

클러스터 란, 연속적인 섹터의 그룹을 말하며, 섹터의 개수는 2의 제곱(1, 2, 4, 8, ...) 이어야만 한다. 

MS 명세서에 따르면 클러스터의 크기는 최대 32KB이어야 한다.

클러스터는 주소가 있는데 주소가 0이나 1이 아닌 2라는 주소부터 시작한다.(= 첫 번째 클러스터는 클러스터 2)

이제부터 클러스터와 분석 방법을 알아보자.

[첫 번째 클러스터 찾기]
FAT 파일시스템은 첫 번째 클러스터인 클러스터 2부터 시작하지 않아 위치를 쉽게 찾지는 못한다.
FAT 파일시스템은 모든 논리적 볼륨 주소가 논리적 파일시스템 주소로 맵핑되지 않기 때문에 FAT 파일시스템의 예약영역과 FAT 영역은 클러스터 주소를 사용하지 않는다.
첫 번째 클러스터를 찾는 방법은 FAT 12/16과 FAT 32가 서로 다르다. 
FAT 12/16 파일시스템의 경우 파일시스템이 생성 될 때 데이터 영역 첫 번째 섹터에 루트 디렉토리가 부트섹터에서 정의된 고정된 크기를 갖고 할당 된다. 그래서 FAT 12/16 파일시스템의 클러스터 2는 루트 디렉토리 다음 섹터를 포함하게 된다.
아래는 FAT 12/16 파일시스템의 클러스터 2 위치를 도식화 한 것이다.

[그림 1 - FAT 12/16]

이와 다르게 FAT 32 파일시스템의 경우 루트 디렉토리의 유동성 때문에 데이터 영역의 첫 번째 섹터를 클러스터 2가 포함한다. 즉, 데이터 영역 첫 번째 섹터가 클러스터 2이다.

 [그림 2 - FAT 32]

 

[클러스터와 섹터 주소 변환]
클러스터와 섹터 주소간에 변환을 위해서는 클러스터 2의 주소를 알아야 한다. 또 클러스터 당 몇 개의 섹터를 포함하고 있는지도 파악하여야 한다. 아래는 클러스터 X(계산하고자 하는 클러스터)의 섹터 주소를 계산하는 기본 공식이다.
 
 - (X - 2) * (클러스터 당 섹터 수) + (클러스터 2의 섹터 수)

역으로 섹터 S(계산하고자 하는 섹터)가 포함되어 있는 클러스터를 계산하는 공식은 아래와 같다.

 - ((S - 클러스터 2의 섹터 수) / (클러스터 당 섹터 수)) + 2


[클러스터 할당 상태]
클러스터의 할당 상태는 FAT 구조체를 통해 알 수 있다. 보통 두 개의 FAT 구조체 복사본이 있는데 하나는 파일시스템 예약 영역 이후에 존재한다. FAT 구조체는 파일시스템 클러스터마다 하나의 테이블 엔트리를 가지고 있다. 테이블 엔트리에는 각 클러스터 번호들이 데이터로 포함되어 있다. 테이블 엔트리 포함되어 있는 번호들의 최대 값은 아래와 같다.

 - FAT 12 : 12bit
 - FAT 16 : 16bit
 - FAT 32 : 32bit(하지만 28bit만 사용한다.)


만약 테이블 엔트리에 포함되어 있는 값이 0이라면 해당 엔트리가 할당 된 클러스터는 파일에 아직 할당되지 않은 것을 의미한다. FAT 종류마다 테이블 엔트리가 가지고 있는 값 중 할당 되지 않은 상태를 표시하는 값들이 있는데 아래와 같다.

 - FAT 12/16 : 0xFF7
 - FAT 32 : 0xFFF FFF7


만약 어떠한 테이블 엔트리가 위의 값을 가지고 있다면 해당 테이블 엔트리의 클러스터는 파일에 할당되지 않음을 의미한다. 


[할당 알고리즘]
운영체제는 할당 가능한 클러스터를 찾기 위해 FAT 구조체의 테이블 엔트리를 참조하여 테이블 엔트리 값이 0인 것을 검색한다. 클러스터를 비 할당 상태로 만드는 방법은 테이블 엔트리의 값을 0으로 바꾸는 방법을 사용하면 된다.
대부분의 운영체제는 위 방법을 사용하여 클러스터를 비 할당 상태로 만드는데 그 클러스터의 내용은 삭제하지 않는다.

 * 참고 : Win 98과 XP의 경우 '다음 적용' 알고리즘을 사용하여 클러스터를 할당 한다. 


[분석]
FAT 파일시스템의 경우 첫 번째 클러스터 주소가 파일시스템 시작 주소와 맞지 않아 다른 파일시스템 보다 데이터 영역을 분석하는 것이 복잡하다. 만약 데이터 영역이 시작하기 전 주소에 특정 데이터를 찾기 원한다면 섹터 주소를 이용해서 찾아야 한다. 데이터 영역에 있는 데이터를 찾으려고 한다면 클러스터 주소나 섹터 주소를 이용하면 된다.
또 비 할당 클러스터에 데이터가 있을 수도 있어 비 할당 클러스터를 분석해 봐야 한다. 비 할당 클러스터는 FAT 구조체의 테이블 엔트리 값이 0인 것을 검색하여 찾으면 된다.
데이터 영역을 분석 할 때에는 클러스터에 할당 되지 않은 섹터를 주의깊게 살펴봐야 한다.
클러스터가 포함하는 섹터의 개수는 짝수로 만약 데이터 영역의 섹터 수가 홀수라면  클러스터에 할당되지 못한 섹터 가 데이터 영역 끝에 남아 있을 수도 있기 때문이다.
아래는 클러스터에 비 할당 된 섹터가 있는지 검증하는 공식이다.

 - (데이터 영역의 전체 섹터 수 - 클러스터 2의 섹터 수) / (클러스터 당 섹터 수) 

또 히든 데이터가 있는지 살펴 봐야 한다. 히든 데이터가 있을 만한 공간은 아래와 같다.

 - FAT 구조체 마지막 엔트리와 백업본 시작 사이 공간
 - 백업 FAT 마지막 엔트리와 데이터 영역 시작 사이 공간 


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

File System - FAT (5)  (0) 2012.02.02
File System - FAT (4)  (0) 2012.02.01
File System - FAT (3)  (0) 2012.01.31
File System - FAT (2)  (0) 2012.01.31
File System - FAT (1)  (0) 2012.01.30
이번 글에서는 파일시스템 참조 모델 중 하나인 내용 참조 모델에 대해서 알아 볼 것이다.

내용 참조 모델은 데이터를 저장 할 수 있는 파일과 디렉토리를 할당하는 저장 공간이 있다.

보통 해당 참조 모델의 데이터 할당 공간은 같은 크기의 그룹들로 구성되며, 각 파일시스템들은 이러한 그룹들을 클러스터 또는 블록이라고 지칭한다.

해당 참조 모델의 분석은 지워진 데이터를 복구하고, 로우 레벨(low level)의 검색을 수행하는 것으로 이루어진다.

이제부터 분석을 위한 클러스터 처리 방법을 하나씩 알아보도록 하겠다.

[논리적 파일시스템 주소]
파일시스템들은 논리적 볼륨 주소를 사용한다. 또 클러스터를 구성하기 위해 연속적인 섹터들을 그룹화 해야 하기 때문에 논리적 파일시스템 주소를 할당한다. 대부분의 파일시스템들은 볼륨의 모든 섹터에 논리적 파일시스템 주소를 부여한다.

 * 참고 : FAT 파일시스템은 논리적 파일시스템 주소를 할당하지 못함 

파일시스템은 논리적 볼륨 주소의 두 섹터당 1개의 클러스터를 할당하며, 논리적 볼륨 주소 네 번째 섹터까지는 주소를 할당하지 않는다.

[그림 1 - 논리적 볼륨 주소와 논리적 파일시스템 주소의 관계]

위 이미지에서 14번 섹터(열 다섯 번째 섹터)부터는 볼륨 슬랙 공간이다.


[클러스터 할당 정책]
클러스터는 두가지 상태가 있는데, 하나는 할당 된 상태이고 또 하나는 할당 되지 않은 상태이다.
기본적인 할당 정책으로는 새로운 파일을 생성하거나 이미 존재하는 파일에 내용을 추가할 때 운영체제는 비 할당 클러스터를 찾고 해당 파일에 비 할당 클러스터를 할당하는 정책이 있다.
대부분의 운영체제들은 연속적인 클러스터를 할당하지만 항상 그렇지만은 않고, 또 운영체제마다 클러스터 할당 정책이 다를 수 있다.
할당 정책에는 다음과 같은 것들이 있다.

 - 첫 번째 적용 할당 정책 : 파일시스템 첫 클러스터부터 검색하여 할당 가능한 클러스터를 찾는 정책, 이 정책
                                  을 사용하면 하나의 클러스터를 할당 후 다시 클러스터를 할당하려고 할 때 파일
                                  시스템의 첫 번째 클러스터부터 다시 검색하여 할당 가능한 클러스터를 찾게 된다.
 - 다음 적용 할당 정책 : 최근에 할당 되었던 클러스터 다음부터 검색을 시작하여 할당 가능한 클러스터를 찾는
                              정책이다
 - 자동 맞춤 할당 정책 : 파일 데이터 크기에 맞는 연속적인 클러스터를 검색하는 정책, 하나의 파일이 몇 개의
                              클러스터를 필요로 하는지 안다면 좋은 정책이지만, 파일의 크기가 증가할 때나 새로운
                              클러스터를 어딘가에 할당할 때에는 단편화가 생길 수 있다.


각 운영체제는 위와 같은 정책을 파일시스템을 위해 선택 할 수 있다. 일부 파일시스템은 어떤 정책을 사용할지 지정되지만, 강제적인 것은 아니기 때문에 조사 시 해당 파일시스템의 구현 방식을 테스트 해봐야 한다. 


[손상된 클러스터]
많은 파일시스템에는 손상된 클러스터를 표시 할 수 있는 기능이 있다. 이 표시를 운영체제가 확인하여 해당 클러스터는 할당 하지 않도록 하였는데, 최근에는 하드디스크들이 자동으로 불량 섹터를 탐지하여 남은 공간으로 해당 섹터를 교체하기 때문에 별도로 표시하는 기능이 필요 없어졌다. 이러한 기능을 무시하고 파일시스템에서 데이터를 숨기는 일은 쉬운일이 아니다. 많은 무결성 도구들이 파일시스템 손상을 보고 하지만 실제로 손상되었는지에 대한 증명은 할 수 없다. 이러한 점을 이용하여 악의적인 사용자나 프로그램들은 자신이 숨기고자 하는 클러스터를 직접 손상된 클러스터 목록에 추가하여 데이터를 숨긴다. 만약 무결성 도구의 결과만을 전적으로 믿는다면 이는 악의적인 행위로 인해 손상된 클러스터로 둔갑한 클러스터의 중요 데이터를 놓치는 셈이 된다. 


이제부터는 분석 기술들에 대하여 알아보도록 하겠다.

[클러스터 보기]
해당 기술은 특정 파일에 클러스터가 할당 되었거나, 특별한 의미가 있는 증거의 주소를 알려고 할 때 사용하는 기술이다.
많은 FAT32 파일시스템에서 섹터 3은 사용하지 않아 0이 되어야 하는데, 만약 0이 아니라 다른 값이 있다면 악의적인 사용자나 프로그램이 데이터를 숨겼을 가능성이 있으므로 섹터 3의 내용을 확인하여야 한다.
기술의 방법은 간단하다. 논리적 파일시스템 주소로 접근하여 섹터의 길이를 계산 한 후 자신이 읽고자 하는 섹터의 번호를 곱하면 읽고자 하는 섹터의 오프셋이 계산된다. 그 후 도구로 해당 섹터의 내용을 읽어들이면 된다.
예를 들어 클러스터의 길이가 10byte인 파일시스템의 열 번째 섹터(9번)를 읽고자 한다면 10 * 9 = 90 이라는 오프셋이 나오게 된다.

[그림 2 - 클러스터 계산]


[논리적 파일시스템 수준에서의 검색]
이 기술은 증거의 위치를 찾는 기술이다. 해당 기술은 특정 문구나 값을 각 클러스터에서 검색한다. 이 기술은 물리적인 섹터 순서를 이용하며, RAID나 디스크 스패닝과 같은 파일시스템에서는 정확하지 않은 결과를 보여줄 수도 있다. 


[클러스터 할당 순서]
위에서 알아봤듯이 클러스터 할당 정책에는 몇 가지가 있었다. 만약 두 개 이상의 클러스터를 할당하는 순서가 중요하다면, 할당 정책을 결정하는 운영체제를 조사 해 볼 필요가 있는데 이것은 운영체제에서 사용하는 정책을 직접 확인해야 하므로 어렵고, 수사관은 클러스터 상태에 따라 발생 할 수 있는 시나리오들을 조사할 필요가 있다. 해당 기술은 증거로서 클러스트를 인식 하고 발생한 사건을 재구성하는데에 사용 된다.


[일관성 검사]
이 기술은 모든 참조 모델에 중요한 분석 기술이다. 이 기술은 파일시스템이 의심스러운 상태인지 파악하게 도와주는 기술이며, 내용 참조 모델의 일관성 검사는 메타데이터 참조 모델의 데이터를 사용하고 모든 할당된 클러스터가 정확하게 하나의 메타데이터 참조 모델 엔트리를 갖는지 검증한다. 만약 하나의 클러스터가 엔트리를 한 개도 가지고 있지 않거나 두 개 이상의 엔트리를 가지고 있다면 사용자가 클러스터 할당 상태를 직접 설정한 것을 의미한다.
클러스터가 한 개도 메타데이터 엔트리를 가지고 있지 않은 것은 고아 클러스터라고 지칭한다.
일관성 검사의 또 다른 방법으로는 클러스터를 조사하는 방법이다. 많은 수집 도구들은 손상된 클러스터를 0으로 채우는데 만약 손상된 클러스터 목록 중 0이 아닌 다른 값을 가지고 있는 클러스터가 있다면 해당 클러스터는 사용자가 직접 손상된 클러스터 목록에 추가한 클러스터로 볼 수 있어 해당 클러스터를 조사해 봐야 한다.


위 분석 방법들을 어렵게 하는 "영구 삭제 기술" 이라는 것이 있다. 이 기술은 파일에 할당된 클러스터나 모든 비 할당 클러스터에 0이나 난수 데이터를 덮어 씌우는 기술이다.

만약 이 기술이 찾고자 하는 파일의 클러스터에 사용되었다면 파일을 찾기란 불가능하다. 하지만 조사관은 해당 파일의 임시 파일본이라도 찾으려고 노력해야 한다.





 

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

File System (5)  (0) 2012.01.28
File System (4)  (0) 2012.01.27
File System (3)  (0) 2012.01.26
File System (2)  (0) 2012.01.26
File System (1)  (0) 2012.01.26

+ Recent posts