Notice
Recent Posts
Recent Comments
Link
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tags more
Archives
Today
Total
관리 메뉴

Piki's Play

Ext 2, Ext 3 개념과 분석 - 내용 범주 본문

포렌식/파일시스템 (파일시스템 포렌식분석)

Ext 2, Ext 3 개념과 분석 - 내용 범주

Pikigod 2020. 3. 19. 15:43

- 내용범주는 파일과 디렉토리의 내용을 포함한다. 이 절에서는 ExtX 내용 범주와 해당 범주의 분석방법에 대해 알아본다.

 

 

개요 

- ExtX는 데이터 유닛으로 '블록'을 사용하고 한 블록은 연속적인 섹터의 그룹이다. 이 절은 블록크기와 주소, 그리고 그것들의 할당 상태를 어떻게 결정하는지를 설명한다. 

 

 블록

한 ExtX 블록은 1024, 2048, 4096 바이트이고, 그 크기는 슈퍼블록에서 주어진다.

- ExtX의 기초가된 UFS는 조각(fragment)로 한 블록을 나누었다. 조각크기를 문서화해서 알려주는 슈퍼블록 필드가 존재함에도 불구하고, ExtX의 리눅스 코드는 이것을 지원하지 않는다. 따라서 따로 명세가 없고, 이 책에서는 조각 크기가 블록 크기와 같다는 것으로 추측하고 있다. 

- 모든 블록에는 주소가 주어지며 블록 0은 파일시스템의 첫 섹터에 위치한다. 모든 블록은 한 블록 그룹에 포함이 되어야 하는데 슈퍼블록이 파일시스템 시작 부분에 예약공간을 정의한 경우는 제외한다. 예약된 블록은 블록 그룹에 포함되지 않고, 블록 0은 예약된 블록 바로 다음에 시작한다.

- 어떤 블록에 속한 그룹인지 결정하기 위해 다음 계산을 사용한다.

group = (block - FIRST_DATA_BLOCK) / Blocks_Per-Group

예를들어 예약공간이 없고, 그룹 당 32768 블록들이 있다면 그룹 1에는 블록 60000개가 있다.(?!!!!)

 

 

 할당상태

- 블록의 할당상태는 그룹의 블록 비트맵에 의해 결정되며, 그 블록(블록비트맵) 위치는 그룹 기술자에서 제공한다. 블록 비트맵은 할당된 전체 블록을 가지며, 각 비트는 그룹 내 한 블록에 해당한다. 특정 비트가 어떤 블록에 해당하는지 결정하기 위해서 먼저 그룹의 시작에서 상대적인 블록 주소를 결정할 필요가 있다.

- 이것은 블록의 논리적 그룹 주소로서 생각할 수 있다. 그룹의 첫 블록을 결정하기 위한 계산은 다음과 같다.

first_block = group * BLOCKS_PER_GROUP + FIRST_DATA_BLOCK(아마 예약공간)

-> 블록 주소에서 그룹의 첫 블록 주소를 뺀다. 예를들어 그룹1이 32768에서 시작한다면 블록 60000은 27232의 비트 오프셋을 갖는다. 그래서 비트맵에서는 바이트 3404(27232/8)에 있다. ExtX 비트맵 예는 다음 장에서 설명한다.

 

- 리눅스에서는 블록 비트맵이 오직 한개의 블록을 사용하도록 블록 그룹의 크기를 생성한다. 그래서 4096바이트 블록을 사용하는 파일시스템들은 기본적으로 그룹 별 32768 블록들을 갖는다.

- NTFS와 달리 모든 블록에 파일을 할당하지 않는다. 관리적 파일시스템에 할당된 많은 블록들이 존재하고 그것들은 파일에 할당되지 않는다. 예로 슈퍼블록, 그룹 기술자 테이블, 블록과 inode를 위한 비트맵, inode테이블 같은 것들이 있다.

 

- TSK dstat 도구는 블록의 할당상태와 그것이 속한 블록 그룹을 보여준다. 이 도구로 예제 이미지를 분석한 결과를 알 수 있다.

# dstat -f linux-ext3 ext3.dd 14380

Block : 14380                         

Allocated                              

Group : 0                              

-> 블록 14380은 블록 그룹 0에 위치하고 있으며 그것은 할당되었다. 이 블록은 '메타데이터'절에서 설명할 예제 이미지의 inode에 할당될 것이다.

 

 

할당 알고리즘

- 리눅스는 블록을 그룹에 기초해서 할당하지만 다른 운영체제들은 다른 방법을 선택할 수 있다. 리눅스는 블록에 inode를 할당할 때 '첫 번째 적용'을 사용하고 inode처럼 동일한 그룹에 블록을 할당한다. 이것은 디스크 헤드의 이동을 줄인다. 만약 파일이 크면 리눅스는 '다음 적용' 정책을 사용하고 현재 파일 끝 다음 블록을 찾는다. 거기에는 디렉토리들을 위해 블록을 사전에 할당하는 파일시스템 기능이 있어서 디렉토리에 블록들이 필요할 때 단편화 되지 않도록 한다. 

- 그룹에 공간이 부족하면 다른 그룹의 블록을 사용한다. 이것은 응용프로그램에 종속적이고, 모든 운영체제가 할당을 위해 이 기능을 사용하지 않는다. 예를들어 어떤 운영체제는 그룹들을 무시하고 파일시스템 시작을 기준으로 '첫 번째 적용' 알고리즘을 사용한다. 

- ExtX는 대체적으로 파일시스템 내 모든 블록을 할당하지 못하도록 한다. 슈퍼블록에는 특정 사용자, 루트 사용자를 위해 얼마나 많은 블록이 예약되어 있는지를 정의하는 값이 있다. 이는 일반사용자들이 파일을 생성하지 못할 때 루트 사용자 특정사용자는 생성이 가능하다. 

- 리눅스가 블록에 데이터를 쓸 때 사용하지 않는 바이트들은 0으로 만든다. 그래서 블록의 슬랙공간에는 어떠한 데이터도 남지 않는다.

 

 

▶ 분석기술

-ExtX의 내용 범주를 분석할 때 특정 블록 위치를 확인하고, 내용을 읽어 할당 상태를 결정할 필요가 있다. 첫 블록은 파일시스템 첫 섹터에서 시작하고, 블록크기는 슈퍼블록에서 주어주기 때문에 특정 블록 위치를 확인하는 것은 쉽다. 

- 블록의 할당상태를 결정하는데 3가지 과정을 거친다.

첫 번째는 블록이 속한 블록 그룹을 확인해야 한다. 그 다음 그룹 기술자 테이블의 그룹엔트리 위치를 확인하고, 블록 비트맵이 저장되어있는 위치를 확인해야 한다. 마지막으로 블록 비트맵을 처리하고, 찾으려는 블록과 관련있는 비트를 조사한다. 만약 그 비트가 설정되어 있으면 그 블록은 할당되어 있는 것이다. 

- 위 과정으로 비트맵에 0인 것들을 검색해서 비트가 0인 블록들을 추출한다. ExtX를 위해 슈퍼블록, 그룹 기술자, inode 테이블, 그리고 비트맵은 모두 할당된 데이터가 있다. 심지어 이것들이 파일에 할당되지 않았더라도 말이다. 만약 파일시스템 시작에 예약된 섹터들이 있다면, 그것들의 할당상태는 무엇인지는 그것들을 위한 ㅍ비트맵 엔트리가 없기 때문에 명확하지 않다. 이것은 도구에 의존할 수 밖에 없다.

 

 

▶ 분석 고려사항

- 만약 운영체제가 inode처럼 같은 그룹에 블록들을 할당 한다면, 키워드 검색은 일반적으로 전체 파일시스템 대신 그룹으로 제한 할 수 있다. 그룹 할당은 TSK에 fsstat결과를 사용해서 확인할 수 있고, 다른 도구들도 동일한 정보를 제공한다. 

- 지워진 데이터가 덮어 써지는데 걸리는 시간은 FAT나 NTFS와 다르다. 쓰는 활동이 많은 그룹은 그렇지 않은 그룹보다 덮어 써지는 시간이 바를것이다. NTFS와 FAT는 어떤 클러스터던지 덮어써지는 기회가 동일한 반면, ExtX는 블록이 위치한 그룹에 따라 다르다.

 

 

▶ 분석 시나리오

- 파일시스템 마지막 블록에 루트킷 패스워드가 저장되어있어 그 블록의 내용을 읽어야 하는 시나리오를 생각해보자 이것은 파일시스템 블록크기블록 수를 결정하는 것이 필요하다. 이 둘다 슈퍼블록에 있다. 이 작업을 할 수 잇는 수단으로 512바이트 섹터들에서 작업하는 헥사 편집기만 있다고 가정하자.

- 파일시스템의 섹터 2인 슈퍼블록을 읽는다. 블록크기는 바이트 24~27에 위치하고 값은 2이다.(아마 뒤에 데이터 구조체에 나올 것 같다) 이 값은 블록크기 1024(0x0400)을 몇번 옮겨야 하는지를 나타내고, 파일시스템은 왼쪽으로 두번 이동해야 한다. 한번 이동하면 2048(0x0800)이 되고, 두번 이동하면 4096(0x1000)이 된다. 잘 이해가 안된다면 바이트 0x04는 바이너리로 0100이고, 0x8은 1000이다. 0x0400을 왼쪽으로 1번 자리옮김 하면 0x8로 이동한다. 

- 다음은 파일시스템의 마지막 블록을 결정하는게 필요하다. 이것은 바이트 4~7에 저장되고 가상적인 계산은 요구되지 않는다. 파일시스템에는 512064개의 블록들이 있어 앞에 512063블록들을 구하는게 필요하고, 각 블록은 4096바이트나, 8개의 섹터들이 있다. 그래서 헥사편집기에서 4096504에서 4096511 섹터를 보는 게 필요하다. 

- 이 시나리오에서 특정 블록 위치를 확인하는 기본 과정을 수행했다. 모든 분석도구는 이러한 방법으로 위치를 찾고, 이것은 도구가 어떤 방법으로 위치를 찾는지 알려고 할 때 유용할 수 있다.

 


p.s 내용은 적고 그림도 없다... 요즘 눈이 뻐근하다