[Digital Forensic] EXT 파일 시스템 (1)

[Digital Forensic] EXT 파일 시스템 (1)

 

EXT 파일 시스템

---

(1) EXT 파일 시스템?

• Minix라는 리눅스 초기 파일 시스템의 문제점 해결을 위해 고안된 파일 시스템

• UFS(Unix File System)을 기초로 만들어져, 현재 Ext 4까지 업데이트 됨

• UFS에서 쓸모 없는 기능들을 제외하여 구조를 이해하는데 어려움은 크게 줄음

• 파일과 관련된 모든 데이터들을 한 곳에 모아 두어 하드 디스크 헤드가 데이터를 읽을 때 불필요한 동작을 하지 않도록 설계

 

1-1. Ext 레이아웃

 

Ext의 레이아웃은 다음 그림과 같다.

 

[그림 1] Ext 파일 시스템 레이아웃

 

위 [그림 1]을 보듯이 구조는 간단하다.

 

블록 그룹들의 개수는 시스템 환경에 따라 달라지지만, 마지막 블록 그룹을 제외한 나머지 블록 그룹들은 같은 블록 수를 가진다.

 

블록 그룹에는 Super Block, Inode Table 등이 존재한다.

 

 

1) Super Block (Block 1개의 크기)

• Block의 크기 (1KB, 2KB, 4KB)

• 블록 총 개수

• 블록 그룹 개수

• Inode 개수

• 블록 그룹 내의 블록 / Inode 개수

 

Super Block은 블록 크기가 2KB, 4KB이어도 고정적으로 1KB만 사용한다.

 

즉, 4KB의 블록을 할당 받아도 3KB는 쓰지 않는다.

 

 

2) Inode Table

• inode라는 데이터 구조체를 포함하고 있는 테이블

• 각 블록 그룹에 1개씩만 존재

 

3) inode

• 파일과 디렉토리의 메타데이터를 포함하는 데이터 구조체

• 고정된 크기를 가짐

 

[그림 2] 블록 내의 관계

 

디렉토리 엔트리는 파일 이름과 파일 inode 포인터를 포함하는 데이터 구조체이다.

---

(2) 기능

 

 

Ext에는 여러 가지 기능이 존재한다.

 

이 중 주의깊게 보아야 할 기술은 호환성 기능이다.

 

2-1. 호환 기능

• 마운트 하려는 파일 시스템에 저널링, 확장 속성 등 운영체제에서 지원하지 않는 기능이 있더라도 해당 파일 시스템을 마운트하는 기능

 

2-2. 비호환 기능

• 마운트 하려는 파일 시스템에 압축, 암호 등 기능이 포함되어 있으면 해당 파일 시스템을 마운트하지 않는 기능

 

2-3. 읽기 전용 호환 기능

• 비호환 기능처럼 운영체제가 지원하지 않는 기능을 가진 파일 시스템을 강제적으로 마운트 한다면 읽기 전용으로 마운트하는 기능

---

(3) 슈퍼 블록

• 파일 시스템의 시작(부트 섹터 제외)으로 부터 1024Byte에 위치

• 크기는 1024Byte이지만 실제로는 이보다 조금 더 작음

• 설정 값만 포함하고 있고 부트 코드는 포함하고 있지 않음

• 복사본은 보통 블록 그룹의 첫 블록(슈퍼 블록)에 저장 

 

슈퍼 블록에 저장되는 정보는 다음과 같다.

 

• 각 블록의 크기

• 전체 블록의 수

• 블록 그룹별 블록 개수

• 예약 블록 수

• inode 전체 개수

• 블록 그룹별 inode 개수

• 볼륨 이름

• 마지막 수정 시간

• 마지막 마운트 시간

• 마지막 마운트 경로

• 무결성 식별 실행 여부 값

 

많은 정보들이 포함되어 있지만 마지막 수정 시간부터의 값들은 부가적 데이터이다.

 

또 슈퍼 블록은 비 사용중인 inode 블록들의 전체 개수에 대한 데이터를 기록하기도 하는데 이것의 이유는 inode와 블록들을 할당할 때 참고하기 위해서다.

 

슈퍼 블록에는 앞 글에서 설명한 세 가지의 호환성 기능 말고도 sparse 슈퍼 블록 기능이라고 있는데 이 기능에 대해서 다음과 같이 설명할 수 있다.

 

 

스파스 슈퍼 블록

• 해당 기능은 기본적으로 Ext 파일 시스템이 리눅스에 생성될 때 활성화 되어 있는 기능

• 슈퍼 블록과 그룹 기술자 테이블의 복사본을 일부 블록 그룹에 포함되도록 함

• 이 기능으로 인해 파일 시스템의 시작 위치를 판별하는데 어려움이 생길 수 있음

• 슈퍼 블록 볼륨 레이블이라는 것이 존재하는데, 이것은 파일 시스템을 구분하기 위해 사용

---

(4) 그룹 기술자 테이블 블록

• 슈퍼 블록 다음으로 오는 블록

• 해당 테이블의 복사본은 sparse 슈퍼 블록 기능이 활성화되어 있지 않으면 각 블록 그룹에 존재하게 됨

• 해당 테이블에는 파일 내용 이외에 슈퍼 블록, 그룹 기술자 그룹, inode 테이블, inode 비트맵, 블록 비트맵의 설정 데이터에 대한 정보들이 포함되어 있음

---

(5) 부트 코드

• 슈퍼 블록 이전에 위치

• 크기는 1024Byte

• 즉 MBR 영역과 첫 번째 블록 그룹의 슈퍼 블록 영역 사이에 존재하는 것

---

(6) 블록

• Ext 파일 시스템의 블록은 NTFS와 FAT 파일 시스템의 클러스터와 아주 유사한 개념

• 보통 1024, 2048, 4096 Byte의 크기를 가짐

• 모든 블록에는 주소가 주어지며, 모든 블록들은 블록 그룹에 속해야만 함

• 예약 영역(부트 섹터와 부트 코드가 있는 영역)의 블록들은 블록 그룹에 속하지 않음

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

 

 

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

 

 

블록 할당

• 각 블록 그룹에 존재하는 블록 비트맵에 의해서 결정

• 위치는 그룹 기술자 테이블에 정의되어 있음

• 블록 비트맵 내용은 비트로 구성되어 있는데 이 비트는 각 블록과 맵핑 관계

• 어떠한 특정 비트가 어떠한 블록과 맵핑 관계에 있는지 확인하려면 블록 비트맵이 포함되어 있는 블록 그룹의 시작에서 확인하고자 하는 블록의 상대적 주소를 계산해야 함

상대적 주소를 계산하려면 블록 그룹의 첫 번째 블록을 확인해야 하는데 확인 방법은 다음 계산식을 수행하면 된다.

 

 

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

 

 

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

 

관리 목적으로 파일 시스템 할당된 블록들은 다음과 같은 것들이 있다.

 

• 슈퍼 블록

• 그룹 기술자 테이블

• 블록과 inode의 비트맵 블록

• inode 테이블

---

(7) inode

• Ext 파일 시스템의 메타데이터들은 모두 inode에 저장

• Ext 파일 시스템에서 inode는 모두 동일한 크기를 가지며, 슈퍼 블록에 정의

• inode Table이라는 집합체에 저장되어 있음

• 이 테이블은 각 블록 그룹에 존재하며 크기는 슈퍼 블록에 정의되어 있음

• inode 테이블 위치는 그룹 기술자 테이블에서 정해줌

 

보통 inode의 1 ~ 10번은 예약되어 있고, 할당 된 상태이다.

 

슈퍼 블록은 이런 예약 inode들을 제외한 첫 번째 inode를 값으로 가지고 있다.

 

각 inode 필드 중에는 고정된 번호를 가지는 필드가 있고 추가 정보로는 확장 속성과 간접 블록 포인터가 있다.

 

또 inode의 할당 상태는 각 그룹에 존재하는 inode 비트맵이 결정한다.

 

 

소유권

• 해당 정보는 사용자, 그룹 ID로 인해 저장

• 유닉스에서는 모든 사용자에게 ID를 할당하고 사용자 ID를 사용자 이름으로 변화하는데 /etc/passwd 파일을 사용

• inode에 사용자 ID는 chown 등의 명령어를 통해 충분히 변경 가능하기 때문에 해당 사용자가 해당 파일을 생성 했다고 전적으로 신뢰하여서는 안 됨

 

타임스탬프

• inode는 일시적인 정보로 타임스탬프 값을 가짐

• 한 가지 특이한 점은 기존의 타임스탬프라고 하면 변경, 수정, 접근 시간이 있는데 inode는 여기에 삭제 시간까지 포함

• 타임스탬프 값은 1970년 1월 1일 UTC를 시작으로 현재 시간까지 경과된 초를 값으로 가짐

• 하지만 타임스탬프 정보 또한 전적으로 신뢰하여서는 안 됨

• 이유는 Touch 명령어로 수정이 가능하기 때문

 

모드 필드

• 파일 타입, 기본 허가권 등의 값이 포함

• 유닉스에서는 모든 것이 파일로 취급되는데 그 취급되는 유형에는 무수히 많은 유형들이 있음

• 파일 타입은 이러한 유형들을 말하는 것

• 기본 허가권은 퍼미션(Permission)에 해당하는 것으로, 이는 운영체제가 다루는 데이터가 아닌 사용자가 다루는 데이터이므로 부가 데이터에 속함

• 모드 필드는 파일이나 디렉토리가 갖는 특별한 속성을 포함하고 있음

• 'sticky bit'라는 것이며, 해당 속성이 파일이나 디렉토리에 설정되면 오직 소유주만이 파일이나 디렉토리의 내용을 지울 수 있음

그리고 SUID, GUID라고 하는 것도 있으며, 이 두 가지 속성은 권한이 없는 사용자가 특정 권한을 가지고 프로그램을 실행토록 하는 권한이다.

 

 

링크 카운트

• 링크 카운트 값은 inode를 가리키는 파일 이름의 개수를 뜻함

 

블록 포인터

• inode에는 파일에 할당할 12개의 블록 주소가 저장되어 있는데 이것들을 직접 포인터라고 부름

• 하지만 요즘은 파일 용량이 커져 12개의 블록 가지고는 부족할 때가 있음

• 이럴 때 하나의 블록을 나머지 블록들의 주소를 저장할 공간으로 할당하여 해당 블록에 나머지 블록들의 주소를 저장하며, 이를 간접 포인터라고 함

• 만약 간접 포인터를 사용하고도 블록이 더 필요하면 직접 포인터와 간접 포인터를 혼합한 이중 간접 포인터를 사용해야 함

• 또 더 많은 공간이 필요하다면 삼중 간접 포인터를 사용해야 함

 

[그림 3] inode 포인터

 

파일을 강제로 특정 크기를 갖게 끔 생성하거나 블록 내용이 모두 0일 때는 스파스 블록이라고 부른다.

 

스파스 블록에는 어떠한 데이터도 쓸 수 없으며, 스파스 블록이 블록 포인터에 포함될 경우 블록 주소가 0으로 표시된다.

 

 

타임 스탬프 업데이트

 

 

Ext에는 4개의 시간 값이 있으며, 각 시간 값이 언제 업데이트 되는지 알아보도록 하자.

 

대부분의 지워진 파일들은 수정 시간, 변경 시간, 삭제 시간이 동일하다.

 

 

1) 접근 시간

• 파일이나 디렉토리 내용을 읽을 때 업데이트 됨

• 복사, 새로운 볼륨으로 이동할 때에도 업데이트 됨

2) 수정 시간

• 파일이나 디렉토리 내용이 변경될 때 업데이트

• 복사할 때에도 결국 새로운 파일 내용을 생성하는 경우가 되어 현재 시간으로 업데이트 됨

• 또 네트워크로 전송할 때에도 네트워크에서 전송받는 시스템의 현재 시간으로 업데이트 됨

3) 변경 시간

• 파일이나 디렉토리의 메타데이터가 변경될 때 업데이트 됨

• 예를 들어 파일이나 디렉토리 생성, 퍼미션 변경, 소유권 변경 등의 정보가 변경될 때 업데이트 됨

4) 삭제 시간

• 파일이 삭제될 때 업데이트 됨

• 이 시간 값은 inode가 새롭게 할당 되면 삭제

---

(8) 디렉토리 엔트리

• Ext 파일 시스템에서는 파일과 디렉토리의 구분을 inode에 있는 특별한 타입 값으로 구분 지음

• 디렉토리들은 디렉토리 엔트리 데이터 구조체의 목록을 포함하는 블록들을 할당받게 됨

• 디렉토리 엔트리는 파일 이름과  메타데이터가 어디 있는지 설명하는 데이터 구조체

모든 디렉토리는 자신과 부모를 나타내는 . 과 .. 디렉토리 엔트리를 포함하고 또 이 두 개를 엔트리 시작으로 삼는다.

 

. 과 .. 다음으로는 디렉토리 내의 파일과 하위 디렉토리의 엔트리들이다.

 

모든 파일 이름은 동적이어서 디렉토리 엔트리의 길이 또한 동적이다.

 

이러한 이유로 디렉토리 엔트리에는 이름 길이를 식별하는 디렉토리 엔트리 레코드 값이 존재한다.

 

디렉토리 엔트리의 길이는 이름 이외에 고정된 8Byte가 있어 4의 배수로 반올림 된 레코드 값과 8Byte를 더하여 결정한다.

 

레코드 값은 이름의 길이만큼 값이 주어져 다음 디렉토리 엔트리의 위치를 판별하는데 사용될 수 있다.

 

[그림 4] 디렉토리 엔트리 기본

 

마지막 디렉토리 엔트리의 레코드 값은 블록의 마지막을 가리키며, 마지막 디렉토리 엔트리 이후의 공간은 비할당 공간으로 남겨 둔다.

 

[그림 4]의 경우 이름 길이대로 레코드 값이 설정되어 다음 디렉토리 엔트리 바로 앞을 가리키고 있다.

 

하지만 파일이 삭제되면 파일의 이름이 변경되는데 운영체제는 그러한 파일을 화면상으로 출력하지 못한다.

 

또 운영체제는 삭제 파일 이전의 디렉토리 엔트리의 레코드 값을 삭제 파일 다음 디렉토리 엔트리가 위치한 곳까지의 거리로 값을 증가시켜 삭제된 파일을 숨긴다.

 

하지만 말 그대로 숨겼을 뿐 데아터는 지워지지 않아 복구가 가능하다.

 

[그림 5] 파일을 삭제한 경우

 

[그림 5[의 경우 file2.txt를 삭제한 경우인데 이렇게 하면 사용자는 파일이 지워진 것으로 인식하게 될 것이다.

 

하지만 데이터는 그대로 블록에 남아 있다.

 

만약 이름의 길이와 레코드의 길이를 비교했을 때 레코드의 길이가 필요 이상으로 크다면 현재 디렉토리 엔트리와 다음 디렉토리 엔트리 사이에 파일이 존재했던 것으로 볼 수 있다.

---

(9) 링크

• Ext 파일 시스템에서 제공하는 링크는 하드 링크와 소프트 링크가 있음

• 하드 링크는 같은 파일 시스템에 있는 파일이나 디렉토리에 추가적인 이름을 정의하는 것

• 소프트 링크는 다른 파일 시스템에 있는 파일이나 디렉토리에 추가적인 이름을 정의하는 것

• 하드 링크는 링크가 생성되면 원본 이름인지 링크 이름인지 구분할 수 없는 특징이 있음 

[그림 6] 하드 링크

 

[그림 6]처럼 원본 inode를 하드 링크가 같이 가리키고 있기 때문에 같은 파일 시스템에 존재해야 하며 또 원본 파일 이름이 어떤 것인지 구분할 수 없는 것이다. (하드 링크가 모두 해제 되지 않는 이상 파일은 삭제되지 않음)

 

소프트 링크는 심볼릭 링크 파일 타입으로 인해 생성된다.

 

파일이 하나 생성되었기 때문에 소프트 링크 파일만의 inode가 존재하며 해당 inode의 블록 또한 할당된다.

 

소프트 링크 파일이 가리키고자 하는 파일의 전체 경로가 60 글자를 넘지 않으면 목적 파일이나 목적 디렉토리의 전체 경로는 소프트 링크 파일에 할당된 inode나 블록에 저장된다.

 

 

소프트 링크 파일의 블록은 블록 포인터로서 목적 파일을 가리키게 되는데 이와 같은 과정은 다음과 같다.

 

[그림 7] 소프트 링크

---

(10) 마운트

• 디렉토리들은 파일과 볼륨을 마운트하는데 사용될 수 있음

• 어떠한 파일 시스템이 디렉토리에 마운트되면 해당 디렉토리가 가지고 있던 파일들은 보이지 않게 됨

• 이 방법은 파일을 숨기는데 사용될 수 있음

[그림 8] 마운트

---

(11) 해시 트리

• NTFS의 b-tree와 비슷한 개념

• 그 정렬 기준이 파일 이름이 아닌 해시 값

• 파일 시스템이 생성될 때 사용자에 따라 사용 여부가 달라짐

• 만약 사용자가 사용하낟고 설정하면 슈퍼 블록에서 호환 플래그 기능을 설정해 줌

• 해시 트리를 사용하게 되면 블록은 트리 구조에서 노드가 되며 그 노드는 각 파일들을 포함하게 됨

Ext 파일 시스템에도 b-tree가 있지만 아직 표준은 아니다.

---

(12) 저널링

• 파일 시스템의 손상을 대비하여 복구를 위해 파일 시스템의 변경 사항을 기록해 두는 기능

• Ext에서 저널은 슈퍼 블록에서 그 위치를 지정하여 주기 때문에 파일 시스템 어느 곳이든 위치할 수 있지만 보통 inode 8을 사용

슈퍼 블록에는 저널을 위한 호환 설정 필드가 있는데 이 값을 어떻게 설정하는가에 따라 로컬 저널 기능의 활용 여부를 결정할 수 있다.

 

만약 로컬 저널 기능을 비활성화로 설정하면 외부 저널을 사용할 수 있다.

 

하지만, 이 저널의 데이터는 로컬에 저장되지 않으며, 저널에는 두 가지 동작 모드가 있다.

 

첫 번째로는 메타 데이터의 업데이트만을 기록하는 모드이고, 두 번째는 파일 시스템의 모든 업데이트를 기록하는 모드이다.

 

그리고 메타데이터 업데이트만을 기록하는 모드가 바로 default 이다.

 

 

Ext3의 저널링은 블록 수준에서 수행되는데 만약 어떠한 inode가 1비트 변경된다면 해당 inode를 포함하고 있는 블록 모두 저널에 업데이트된다.

 

저널의 첫 번째 블록은 슈퍼 블록은 위한 것이며, 전체적인 정보를 저장하는데 사용된다.

 

그 뒤로 이어지는 블록들은 저널 엔트리를 위해 사용되고 만약 저널 업데이트가 마지막 블록까지 진행되었다면 다시 처음 블록으로 돌아온다. (저널의 블록 크기는 파일 시스템 블록 크기와 동일)

 

 

업데이트는 하나의 묶음을 기준으로 처리되는데, 각 묶음은 순서 번호를 가지고 있다.

 

이 순서 번호는 같은 블록에 대해서는 동일하다.

 

각 묶음은 기술자 블록을 시작으로 하며, 기술자 블록은 묶음의 순서 번호와 어떤 파일 시스템 블록이 업데이트 되었는지 나타내는 목록을 포함한다.

 

만약 새로운 블록에서 업데이트가 발생하면 기존에 있던 묶음 뒤 블록에 기록된다.

 

또, 저널에 기록되었던 파일 시스템 블록은 취소가 가능하며, 취소를 할 경우 취소 블록이라는 곳에 그 목록이 순서 번호와 함께 저장이 된다.

---

# Reference

 

http://www.yes24.com/Product/Goods/8511539