[Digital Forensic] EXT 파일 시스템 (3)
(16) Ext4 파일 시스템 분석
최근에 Ext 파일 시스템은 Ext4 버전으로 업그레이드 되었다.
기본 개념에 새로운 기능들이 추가된 Ext4 파일 시스템은 최근 빠르게 Ext3 파일 시스템을 대체하고 있다.
이러한 변화에 당연히 포렌식 전문가들은 적응을 해야 한다.
Ext4 파일 시스템은 Ext3 파일 시스템의 개선 버전으로 현재 대부분 리눅스에서 사용 중이며, 포렌식 분석 도구들도 대부분 해당 파일 시스템 분석을 지원하고 있다.
16-1. Ext4 특징
대용량 파일 시스템
-
Volume 크기는 1EiB, 파일 용량은 16TB까지 지원
Extents
-
이전 Ext 파일 시스템은 Block mapping을 지원하였는데, Ext4 파일 시스템부터는 Extents 방식을 지원하여 블록 단편화 현상을 줄임
-
Ext4 파일 시스템에서 Block mapping 대신 Extents를 사용한다면 Ext4 이전 파일 시스템에 마운트 될 수 없음
호환성
-
Ext4 이전의 파일 시스템을 Ext4 형식으로 변경하여 Ext4 파일 시스템에 마운트하여 성능 향상 상태로 사용할 수 있음
-
또 Ext4 파일 시스템을 Ext4 이전 파일 시스템에 마운트하여 사용할 수도 있음
저널 체크섬
-
이전 Ext 파일 시스템에는 없던 저널 체크섬이 추가 됨
64000개 서브 디렉토리
-
Ext4 파일 시스템 이전 버전들은 서브 디렉토리의 최대 개수가 32000개 였음
-
하지만 이번 버전에서는 64000개로 늘어나 조금 더 많은 디렉토리를 생성할 수 있게 됨
온라인 조각 모음
-
Ext4 파일 시스템에서 새로 생긴 기능
파일 시스템 검사 속도 향상
-
파일 시스템에서 사용하지 않는 부분을 건너띄고 검사하여 검사 속도가 향상 됨
타임스탬프
-
Ext4 파일 시스템 이전 버전에서는 초 단위로 1901년 12월 14일 ~ 2038년 1월 18일까지 시간을 기록할 수 있었음
-
Ext 파일 시스템부터는 나노초로 계산되며 1901년 12월 14일 ~ 2514년 4월 25일까지 기록할 수 있게 됨
지연 할당
-
해당 기능은 Ext4 파일 시스템에서 새로 생긴 기능
-
어떤 파일에 대한 블록 할당을 최대로 지연하여 가능한 연속 블록에 할당되게끔 하는 기능
멀티 블록 할당
-
Ext4 파일 시스템 이전 버전에서는 파일 기록에 여러 블록이 필요하면 보통 떨어져 있는 블록들을 할당하여 파일을 기록
-
Ext4 파일 시스템 버전부터는 멀티 블록 할당자를 통해 블록 여러 개를 동시에 할당하여 블록이 연속되어 할당되게끔 함
-
이러한 기능으로 인해 블록 호출 횟수가 줄어들어 할당 속도도 빨라짐
Ext4도 결국 파일 시스템 전체 레이아웃은 Ext4 파일 시스템 이전 버전들과 동일하다.
하지만 블록 그룹의 레이아웃이 약간 다르다.
-
Group 0 Padding : 32(x86)bit 시스템 부트 섹터 등을 위한 영역이며, 크기는 1024byte
-
Reserved GDT Block : 파일 시스템의 확장을 위해 예약되어 있는 영역
보통 슈퍼 블록, 데이터 블록 비트맵, inode 비트맵은 블록 1개 크기이다.
16-2. 슈퍼 블록
-
Ext4에서도 슈퍼 블록의 역할은 대부분 비슷
-
슈퍼 블록에는 sprase_super라는 플래그 기능이 있으며, 이 플래그가 설정되면 슈퍼 블록 및 그룹 기술자 백업본은 그룹 번호, 0, 3, 5, 7에 존재하게 됨
-
플래그가 설정되어 있지 않으면 모든 그룹에 존재하게 됨
다음 표는 Ext4 파일 시스템의 슈퍼 블록 오프셋 구조에 대한 내용이다.
[표 1] 슈퍼 블록 오프셋 구조
|
범위(Byte) |
설명 |
범위(Byte) |
설명 |
|
0~3 |
inode의 총 개수 |
252~252 |
디렉토리 해시에 사용할 해시 알고리즘 |
|
4~7 |
블록의 총 개수 |
253~253 |
???? |
|
8~11 |
사용 가능한 블록 개수 |
254~255 |
그룹 기술자의 크기 |
|
12~15 |
사용 가능한 블록 개수 |
256~259 |
마운트 옵션 |
|
16~19 |
사용 가능한 inode 개수 |
260~263 |
Meta_bg 기능 활성화 경우에 첫 번째 메타 블록의 블록 그룹 |
|
20~23 |
첫 번째 데이터 블록 |
264~267 |
파일 시스템 생성 시간(s) |
|
24~27 |
블록 크기 연산의 피연산자 |
268~335 |
첫 번째 저널 inode의 68byte 복사본 |
|
28~31 |
조각 크기(사용 X) |
336~339 |
블록 개수의 상위 32bit |
|
32~35 |
그룹별 블록 개수 |
340~343 |
예약 블록 개수의 상우 32bit |
|
36~39 |
그룹별 조각 개수(사용 X) |
344~347 |
예약되지 않은 블록 개수의 상위 32bit |
|
40~43 |
그룹별 inode 개수 |
348~349 |
inode 최소 예약 크기 |
|
44~47 |
마운트 시간(s) |
350~351 |
새로운 inode의 최소 예약 크기 |
|
48~51 |
쓰기 시간(s) |
352~355 |
기타 플래그 |
|
52~53 |
fsck 이후 마운트 횟수 |
356~357 |
다음 디스크로 이동하기 전 디스크 논리 번호(RAID) |
|
54~55 |
fsck 이후 최대 마운트 횟수 |
358~359 |
다중 마운트 검사 최소 수행 시간 |
|
56~57 |
시그니처(0xEF53) |
360~367 |
다중 마운트 보호가 적용되는 블록 |
|
58~59 |
파일 시스템 상태 플래그 |
368~371 |
현재 디스크 논리 번호(RAID) |
|
60~61 |
오류 감지 후 행위 플래그 |
372~372 |
블록 그룹 크기 |
|
62~63 |
마이너 레벨 |
373~373 |
????? |
|
64~67 |
마지막 체크 시간(s) |
374~375 |
????? |
|
68~71 |
최대 시간과 체크 시간의 차이 |
376~383 |
파일 시스템 생성 후 파일 시스템에 기록된 KB 개수 |
|
72~75 |
OS 종류 |
384~387 |
활성 스냅샹 inode 번호 |
|
76~79 |
레벨 플래그 |
388~391 |
활성 스냅샷 순차 번호(ID) |
|
80~81 |
예약 블록 UID |
400~403 |
디스크 스냅샷 목록의 첫 번째 inode 번호 |
|
82~83 |
예약 블록 GID |
404~407 |
오류 개수 |
|
84~87 |
예약되지 않은 첫 번째 inode |
408~411 |
처음 오류가 발생한 시점으로부터 지난 시간(s) |
|
88~89 |
inode 크기(byte) |
412~415 |
첫 번째 오류와 관련된 inode |
|
90~91 |
해당 슈퍼 블록이 포함된 블록 그룹 차단 |
416~423 |
첫 번째 오류와 관련된 블록 |
|
92~95 |
호환 기능 플래그 |
424~455 |
오류가 일어난 함수 이름 |
|
96~99 |
비호환 기능 플래그 |
456~459 |
오류가 일어난 라인 번호 |
|
100~103 |
읽기 전용 호환 기능 플래그 |
460~463 |
가장 최근 오류가 일어난 시간(s) |
|
104~119 |
128bit 볼륨 UUID |
464~467 |
가장 최근 오류가 일어난 inode |
|
120~199 |
파일 시스템이 마지막으로 마운트 된 디렉토리 |
468~471 |
가장 최근 오류가 일어난 라인 번호 |
|
200~203 |
압축 |
472~479 |
가장 최근 오류가 일어난 블록 개수 |
|
204~204 |
???? |
480~511 |
가장 최근 오류가 일어난 함수 이름 |
|
205~205 |
???? |
512~575 |
마운트 옵션의 ASII 문자열 |
|
206~207 |
예약 GDT 엔트리 개수 |
576~579 |
사용자 할당량 파일 inode |
|
208~223 |
저널 Super Block UUID |
580~583 |
그룹 할당량 파일 inode |
|
224~227 |
저널 파일의 장치 번호 |
584~587 |
오버헤드 블록 |
|
228~231 |
저널 파일 inode |
588~591 |
SuperBlock 체크섬 |
|
232~235 |
삭제되지 않은 inode 목록 시작 위치 |
592~1023 |
블록 끝 Padding |
|
236~251 |
해시 트리 |
Ext4로 업그레이드 되면서 슈퍼 블록 또한 많은 것이 추가되었다.
블록 크기 계산에 필요한 필드
-
블록 크기는 2**(10+해당 필드 값)으로 계산
파일 시스템 상태 플래그
-
파일 시스템 상태를 나타내는 필드
-
Ext4 파일 시스템 이전 버전들과 동일
오류 감지 후 행위 플래그
-
오류 감지 후 어떠한 조치를 취해야 할지 결정 해주는 플래그가 설정되는 필드
-
Ext4 파일 시스템 이전 버전들과 동일
OS 종류
-
해당 파일 시스템을 생성한 OS 종류를 나타내는 필드
-
Ext4 파일 시스템 이전 버전들과 동일
레벨 플래그
-
파일 시스템 버전을 나타내는 필드
-
Ext4 파일 시스템 이전 버전들과 동일
호환 기능 세트 플래그
-
0x01 : 단편화를 줄이기 위하여 디렉토리 블록을 사전에 할당
-
0x02 : AFS 서버 inode 지원
-
0x04 : 파일 시스템 저널 지원
-
0x08 : 확장 속성 지원
-
0x10 : 파일 시스템 확장을 위한 GDT 블록 예약
-
0x20 : 디렉토리가 해시 인덱스를 사용
-
0x40 : ????
-
0x80 : ????
비호환 기능 세트 플래그
-
0x01 : 압축
-
0x02 : 디렉토리 항목을 파일 형식으로 기록
-
0x04 : 파일 시스템 복구
-
0x08 : 파일 시스템 별도의 저널 장치
-
0x10 : 메타 블록 그룹
-
0x40 : 해당 파일 시스템의 extents 기능을 사용하는 파일
-
0x80 : 블록으로 파일 시스템 파일 크기를 결정
-
0x100 : 다중 마운트 보호(아직 구현 X)
-
0x200 : Flevible 블록 그룹
-
0x400 : inode의 매우 큰 확장 속성을 사용
-
0x1000 : 디렉토리 엔트리 내의 데이터
읽기 전용 호환 기능 세트 플래그
-
0x01 : Sparse SuperBlock
-
0x02 : 해당 파일 시스템은 대용량 파일을 포함(2GB 이상)
-
0x08 : 해당 파일 시스템의 크기가 블록이 아닌 섹터로 표현
-
0x10 : 그룹 기술자의 체크섬
-
0x20 : 디렉토리를 제한
-
0x40 : 매우 큰 inode 존재
-
0x80 : 해당 파일 시스템의 스냅샷
디렉토리 해시에 사용할 해시 알고리즘
-
0x0 : Legacy
-
0x1 : Half MD4
-
0x2 : Tea
-
0x3 : 서명되지 않은 Legacy
-
0x4 : 서명되지 않은 MD4
-
0x5: 서명되지 않은 Tea
마운트 옵션 (파일 시스템이 마운트 될때의 옵션을 결정하는 필드)
-
0x0001 : 마운트 시 디버깅 정보를 인쇄
-
0x0002 : 새로운 파일을 포함하는 디렉토리의 GID 획득
-
0x0004 : UserSpace에서 확장 속성 지원
-
0x0008 : POSIX ACL 지원
-
0x0010 : 32비트 UID를 지원하지 않음
-
0x0020 : 모든 데이터와 메타 데이터를 저널 대상에 포함
-
0x0040 : 저널 기능이 메타데이터를 저널하기 전 모든 데이터를 디스크로 Flush
-
0x0080 : 요청 데이터는 메타데이터 기록 후 기록
-
0x0100 : Flush 기록 해제
-
0x0200 : 파일 시스템의 블록 메타데이터 위치 추적
-
0x0400 : 미사용 블록에 대한 저장장치 지원을 취소
-
0x0800 : 지연 할당 해제
기타 플래그(비필수 플래그를 나타내는 필드)
-
0x0001 : 사용 중인 디렉토리 해시 서명
-
0x0002 : 사용 중인 서명되지 않은 디렉토리 해시
-
0x0004 : 개발 코드 테스트
블록 그룹 크기
-
블록 그룹의 크기를 결정하는 필드
-
2**해당 필드 값 계산식을 이용하여 블록 그룹의 크기를 구할 수 있음
16-3. 그룹 기술자 테이블
-
Ext4 파일 시스템의 그룹 기술자 테이블은 Ext4 파일 시스템 이전 버전들의 내용과 크게 다르지 않음
-
32bit 시스템과 64bit 시스템 모두 파일 시스템이 적용될 수 있도록 그룹 기술자가 명시해야 하는 블록 비트맵, inode 비트맵 / 테이블 등의 주소를 가지고 있어야 할 오프셋 필드 크기를 8byte(64bit)로 늘림
-
32bit 시스템에 Ext4 파일 시스템이 적용된다면 하위 bit 오프셋 필드만 사용될 것이고, 64bit 시스템에 Ext4 파일 시스템이 적용된다면 상/하위 오프셋 필드 모두 사용될 것
다음 표는 그룹 기술자 오프셋 구조에 대한 내용이다.
[표 2] 그룹 기술자 오프셋 구조
|
범위(Byte) |
설명 |
범위(Byte) |
설명 |
|
0~3 |
블록 비트맵 주소 하위 32비트 |
32~35 |
블록 비트맵 주소 상위 32비트 |
|
4~7 |
inode 비트맵 주소 하위 32비트 |
36~39 |
inode 비트맵 주소 상위 32비트 |
|
8~11 |
inode 테이블 주소 하위 32비트 |
40~43 |
inode 비트맵 주소 상위 32비트 |
|
12~13 |
예약되지 않은 블록 개수 하위 16비트 |
44~45 |
예약되지 않은 블록 개수 상위 16비트 |
|
14~15 |
예약되지 않은 inode 개수 하위 16비트 |
46~47 |
예약되지 않은 inode 개수 상위 16비트 |
|
16~17 |
디렉토리 개수 하위 16비트 |
48~49 |
디렉토리 개수 상위 16비트 |
|
18~19 |
그룹 플래그 |
50~51 |
사용하지 않은 inode 개수 상위 16비트 |
|
20~23 |
????? |
52~55 |
????? |
|
24~27 |
????? |
56~59 |
????? |
|
28~29 |
사용하지 않은 inode 개수의 하위 16비트 |
60~63 |
Padding |
|
30~31 |
그룹 기술자 체크섬(64bit 기능 활성화 시 설정) |
그룹 플래그
그룹 기술자에 대한 플래그 필드로 아래와 같은 플래그 목록들이 설정될 수 있다.
오프셋 필드의 크기와 체크섬 필드가 추가된 것을 제외하고는 Ext4 파일 시스템 이전 버전들과 다른 점이 없다.
-
0x1 : inode 테이블 및 비트맵 초기화를 수행하지 않음
-
0x2 : 블록 비트맵 초기화를 수행하지 않음
-
0x4 : inode 테이블을 0으로 초기화
16-4. inode
-
이전 버전들과 마찬가지로 inode 테이블의 각 엔트리로 존재
-
inode 위치는 그룹 기술자 테이블에 정의되어 있음
-
그룹별 inode는 슈퍼 블록에 정의되어 있음
-
Ext4 파일 시스템 이전 버전들의 inode 표준 크기는 128byte이었는데 Ext4 파일 시스템에서는 256Byte로 늘어남
다음 표는 inode 오프셋 구조에 대한 내용이다.
[표 3] inode 오프셋 구조
|
범위(Byte) |
설명 |
범위(Byte) |
설명 |
|
0~1 |
모드 타입 |
100~103 |
파일 버전(NTFS) |
|
2~3 |
소유자 UID 하위 16비트 |
104~107 |
확장 속성 블록의 하위 32비트 |
|
4~7 |
inode의 크기(Byte) 하위 32비트 |
108~111 |
파일 크기의 상위 32비트 |
|
8~11 |
마지막 접근 시간(s) |
112~115 |
조각 주소(사용 X) |
|
12~15 |
마지막 변경 시간(s) |
116~128 |
????? |
|
16~19 |
마지막 수정 시간(s) |
129~130 |
inode 크기 |
|
20~23 |
삭제 시간(s) |
131~131 |
????? |
|
24~25 |
GID 하위 16비트 |
133~135 |
추가 변경 시간 bit(초 단위보다 더 정밀) |
|
26~27 |
하드 링크 개수 |
136~139 |
추가 수정 시간 bit(초 단위보다 더 정밀) |
|
28~31 |
블록 개수의 하위 32비트 |
140~143 |
추가 접근 시간 bit(초 단위보다 더 정밀) |
|
32~35 |
플래그 |
144~147 |
생성 시간(s) |
|
36~39 |
????? |
148~151 |
추가 생성 시간 bit(초 단위보다 더 정밀) |
|
40~99 |
블록 맵 또는 extents tree 해시 설정 플래그 |
152~155 |
버전 번호 상위 32bit |
모드 타입
-
inode가 할당된 파일이나 디렉토리의 타입과 권한을 나타내는 필드
-
Ext4 파일 시스템 이전 버전들과 동일
플래그 (inode의 플래그를 나타내는 필드)
-
0x00000001 : 해당 파일을 안전하게 삭제해야 함 (아직 구현 x)
-
0x00000002 : 파일이 삭제되지 않게 보존되어야 함 (아직 구현 x)
-
0x00000004 : 파일 압축 (아직 구현 x)
-
0x00000008 : 파일과 디렉토리 모두 할당 가능
-
0x00000010 : 특정 파일에 할당
-
0x00000020 : 파일에만 할당 가능
-
0x00000040 : 해당 inode가 할당된 파일의 덤프 불가
-
0x00000080 : 접근 시간 업데이트 불가
-
0x00000100 : 불필요한 파일 압축 (사용 X)
-
0x00000200 : 파일 저장 영역 중 압축 영역이 하나 이상 있음
-
0x00000400 : 파일 압축 금지 (사용 X)
-
0x00000800 : 압축 오류 (사용 X)
-
0x00001000 : 디렉토리 인덱스 해시
-
0x00002000 : AFS 디렉토리
-
0x00004000 : 파일 데이터 저장은 항상 저널링을 사용하여 수행되어야 함
-
0x00008000 : 파일 병합 불가
-
0x00010000 : 모든 디렉토리 계층에서 상위에 해당
-
0x00020000 : 디렉토리 계층에서 상위에 해당
-
0x00040000 : 대용량 파일
-
0x00080000 : 해당 inode는 extents를 사용
-
0x00200000 : 해당 inode는 큰 확장 속성을 사용
-
0x00400000 : 해당 파일은 파일보다 큰 블록을 가지고 있음
-
0x00800000 : Ext4 라이브러리 예약
-
0x004BDFFF : 사용자 표시 플래그
-
0x004B80FF : 사용자가 수정할 수 있는 플래그
오프셋 구조를 보면 156byte까지만 나와 있는데 앞서 설명할 때에는 inode 크기가 256byte라고 하였다.
현재로서는 정확하지 않지만 나머지 오프셋 필드들은 확장 속성이나 또 다른 용도로 쓰일 것으로 추측된다.
16-5. Extents Tree
-
Ext4 파일 시스템에서 새로 추가된 기능
-
이전 버전들의 블록 맵을 대체하는 기능
-
제일 중요한 점은 블록 할당을 연속으로 하려 한다는 점
-
Extents tree에는 다른 tree들처럼 인덱스 노드와 리프 노드가 존재하고 공통적인 헤더(12byte)가 존재
다음 표는 헤더 오프셋 구조에 대한 내용이다.
[표 4] 헤더 오프셋 구조
|
범위(Byte) |
설명 |
|
0~1 |
시그니처(0xF30A) |
|
2~3 |
헤더의 유효 항목 개수 |
|
4~5 |
헤더 항목 최대 개수 |
|
6~7 |
인덱스/리프(leaf) 노드 구별 |
|
8~11 |
????? |
만약 헤더의 6~7 오프셋의 값이 0이 아니라면 인덱스 노드라는 의미이다.
인덱스 노드의 몸통, 즉 헤더 다음에 오는 구조이다.
인덱스 노드 오프셋 구조는 다음과 같다.
-
0~3 : 블록을 가리키는 리프(leaf) 노드
-
4~7 : 하위 노드 번호의 하위 32bit
-
8~9 : 이전 필드 상위 16bit
-
10~11 : ?????
헤더에서 6~7 오프셋 필드의 값이 0이라면 리프(leaf) 노드라는 의미이다.
리프 노드의 오프셋 구조는 다음과 같다.
-
0~3 : 해당 노드가 할당된 파일의 첫 번째 블록 주소
-
4~5 : 하위 노드 번호의 하위 32bit
-
8~9 : 첫 번째 블록 번호 상위 16bit
-
10~11 : 첫 번째 블록 번호 하위 16bit
[그림 2]는 Extents Tree의 전체적인 흐름을 그림으로 표현한 것이다.
완전하게 데이터를 연속적으로 할당하는 것은 아니지만 동일한 리프 노드 데이터의 경우 디스크에 조금의 거리는 있지만 가까운 블록에 연속 할당하는 것을 볼 수 있다.
이런 점은 포렌식적으로 아주 유용하다.
뿔뿔이 흩어져 있는 조각난 데이터는 다시 모아 복구하기가 쉽지 않지만 이렇게 연속적은 블록들은 복구하기가 비교적 쉽기 때문이다.
이렇게 Ext4 파일 시스템이 어떻게 이전 버전들과 다른지 알아보아다.
업그레이드 버전이어서 전체적 구조나 기술 등의 원리가 바뀌었다고는 볼 수 없었다.
그렇기에 중복되는 기술이나 그 기술의 원리 또는 개념 등은 Ext4 파일 시스템 분석을 하면서 제외하였다.
(17) 포렌식 측면에서의 관점
Ext 파일 시스템 또한 FAT, NTFS와 크게 다르지 않다.
Ext 파일 시스템의 경우 디렉토리 엔트리에 숨겨진 데이터가 있는지 확인해 볼 필요가 있다.
마지막 디렉토리 엔트리와 블록 사이 공간은 일반적으로 사용되지 않는 공간이기 때문이다.
만약 사용된다면 해시 트리에 사용될 것인데, 그마저도 모두 사용되지는 않고 첫 블록만 관리 데이터로 쓰여지고 나머지 블록들은 사용되지 않는 채로 남겨지게 된다.
파일 시스템의 여러 구조들을 보며 사용되지 않거나, 사용되지 않는 공간이나 슬랙 공간일 것으로 추측되는 공간들이 있었을 것이다.
이러한 공간에는 충분히 데이터가 숨겨져 있을 수 있으므로 한번쯤 분석해보는 것이 좋다.
# Reference
'Digital Forensics > Forensic Theory' 카테고리의 다른 글
| [Digital Forensic] PE(Portable Executable) 구조 (0) | 2020.05.09 |
|---|---|
| [Digital Forensic] Registry 분석 (0) | 2020.05.08 |
| [Digital Forensic] EXT 파일 시스템 (2) (0) | 2020.04.02 |
| [Digital Forensic] EXT 파일 시스템 (1) (0) | 2020.04.01 |
| [Digital Forensic] NTFS 파일 시스템 (4) (0) | 2020.04.01 |