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

2020. 4. 2. 00:11

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

(13) 파일 생성 / 삭제

해당 시나리오에서 블록 크기는 1024Byte, 블록 그룹의 블록 개수는 8192개, 블록 그룹별 inode 개수는 2016개이다.

또 해당 시나리오에서는 inode 테이블 시작 블록이 5라고 가정하며, 루트 디렉토리 엔트리가 블록 260에 있다고 가정한다.

13-1. 파일 생성 과정

이 과정에서는 dir이라는 디렉토리가 있다고 가정, File.txt 파일을 생성한다는 가정 상황을 시나리오로 한다.

일단 파일 시스템 1024byte 오프셋에 위치 하는 슈퍼 블록을 참조하여 블록 크기와 블록 그룹의 블록 개수, 블록 그룹 내의 inode 개수를 파악
슈퍼 블록의 분석이 끝나면 그룹 기술자 테이블을 참조하며, 이 테이블은 각 블록 그룹의 레이아웃을 설명하며 블록 2 ~ 3에 위치

위 과정은 다음 [그림 1]과 같다.

파일을 생성할 디렉토리인 dir을 찾으려면 먼저 루트 디렉토리를 찾아야 함
루트 디렉토리는 보통 inode 2를 사용하며, inode 2의 위치는 슈퍼 블록을 참조하여 파악해 둔 블록 그룹별 inode 개수를 이용하면 쉽게 위치를 파악할 수 있고, 해당 시나리오에서는 블록 그룹 0에 위치
블록 그룹 0의 그룹 기술자 테이블을 참조하면 inode 테이블의 위치응 알려주는 엔트리가 있고 그 엔트리를 참조하면 inode 테이블의 위치를 파악할 수 있음

위 과정은 다음 [그림 2]와 같다.

블록 5에서 inode 테이블을 읽고, 두 번째 엔트리(inode 2)를 분석하면 루트 디렉토리의 디렉토리 엔트리가 어떤 블록에 위치하는지 알 수 있음

위 과정은 다음 [그림 3]과 같다.

블록 260의 디렉토리 엔트리를 읽고, 디렉토리 엔트리의 내용을 해석
디렉토리 엔트리의 첫 번째와 두 번째 엔트리는 . 과 .. 을 위한 엔트리이고, 각 엔트리 레코드를 참고하여 다음 엔트리 위치를 파악
엔트리 위치 파악이 모두 되었다면 dir 디렉토리를 검색

해당 시나리오에서는 inode 5444를 할당 받았다고 가정하며, 이 때 dir 디렉토리의 접근 시간은 업데이트 된다.

위 과정은 다음 [그림 4]와 같다.

이번에는 dir 디렉토리의 위치를 알아야 함
dir 디렉토리의 inode를 그룹별 inode 수로 나누면 어떤 블록 그룹에 위치하는지 알 수 있음

dir 디렉토리 inode(5444) / 슈퍼 블록에서 알아낸 블록 그룹별 inode 수(2016) = 2

dir 디렉토리는 계산 결과 블록 그룹 2에 위치하며, 또 블록 그룹 2의 그룹 기술자 테이블을 참조하여 inode 테이블이 어디에 위치하는지 알 수 있다.

이 시나리오에서는 블록 그룹 2의 inode 테이블이 17889 블록에서 시작한다고 가정한다.

inode 테이블을 읽고 inode 5444의 엔트리를 참조
엔트리를 분석하면 dir 디렉토리의 디렉토리 엔트리가 어떤 블록에 위치하고 있는지 파악할 수 있음
엔트리는 블록 그룹 0에서부터 계산해보면 알 수 있음

해당 시나리오에서는 dir 디렉토리의 디렉토리 엔트리가 블록 18556에 있다고 가정한다.

위 과정은 다음 [그림 5]와 같다.

dir 디렉토리의 디렉토리 엔트리를 읽고 디렉토리 엔트리의 목록을 파악
그 후 디렉토리에서 사용되고 있지 않은 공간을 찾음
생성 할 파일이 필요 공간을 계산하면(고정 8byte + 파일 이름 길이(7byte), 4의 배수로 반올림) 총 16바이트가 필요
만약 해당 디렉토리에 다른 파일이 있다면 파일 이름을 비교하여 그 파일들의 이름과 해당 파일의 이름 순서를 고려해 할당

이 때 디렉토리에는 수정 시간과 변경 시간이 업데이트된다.

그리고 .. 가 dir 디렉토리의 마지막이라고 가정한다.

아직 파일이 완전히 생성된 것은 아님
파일에 할당할 inode가 있어야 하는데 하드 디스크 헤더에 부담을 덜어주기 위해 Ext 파일 시스템은 부모와 동일한 그룹 블록에 inode를 할당
inode의 할당 상태를 관리하는 inode 비트맵을 찾기 위해 그룹 기술자 테이블을 참조
inode 비트맵을 찾아 참조하고 비할당 inode를 검색
그 후 검색이 완료된 inode를 할당하기 위해 해당 inode 비트맵 값을 0에서 1로 변경

해당 시나리오에서는 inode 비트맵은 17880 블록에 존재하며, 비할당 inode는 inode 5576이 있다고 가정한다.

inode 테이블에 inode 5576을 초기화하고 타임스탬프 값을 현재 시간으로 업데이트
또 링크 수는 디렉토리 엔트리 링크에 해당하는 1로 설정 (링크는 선으로 표시)

위 과정은 다음 [그림 6]과 같다.

이제 파일 내용을 저장하기 위한 블록을 할당해야 함
블록의 할당 상태는 블록 비트맵에서 관리하는데 inode 비트맵을 찾았던 것처럼 그룹 기술자 테이블을 참조하여 블록 비트맵의 위치를 파악하고 비할당된 블록을 찾음
검색이 완료되면 찾은 블록을 할당하기 위해 비트맵 값을 0에서 1로 변경

이 때 슈퍼 블록과 그룹 기술자 테이블에 있는 블록 개수 현황들이 업데이트 되며, 해당 시나리오에서는 블록 비트맵은 블록 17881에 위치하고, 할당 할 블록들은 총 5개이며, 20004 ~ 20007, 20010 블록이라고 가정한다.

할당이 되면 블록 포인터를 설정해야 하는데 블록 게수가 12개를 넘지 않으므로 직접 포인터로 설정되어 inode에 블록의 주소들이 저장된다.

위 과정은 [그림 7]과 같다.

파일 내용이 할당된 블록에 저장됨

13-2 파일 삭제

파일 삭제는 위 과정과 거의 동일하며 후반부 과정이 조금 다를 뿐이다.

위 생성 과정에서 다시 File.txt를 삭제한다고 하였을 때 다음과 같은 과정을 거친다.

dir 디렉토리의 디렉토리 엔트리를 찾고 그 내용을 분석하여 목록을 파악하는 과정까지는 동일
그 후 File.txt를 삭제하게 되면 File.txt 파일 이전에 존재하는 .. 디렉토리 엔트리의 레코드 값이 증가되어 만약 File.txt를 삭제하게 되면 File.txt가 삭제되어 .. 가 마지막 디렉토리 엔트리라면 블록 끝을 가리키게 됨

해당 시나리오에서는 블록의 끝을 1500이라고 가정하고, 이때 dir 디렉토리의 수정 시간과 변경 시간이 업데이트 된다.

위 과정은 [그림 8]과 같다.

inode 테이블의 inode 5576은 파일이 삭제되었다는 것을 표시하기 위해 링크 값을 1에서 0으로 변경

위 과정은 다름 [그림 9]와 같다.

inode 5576의 할당 상태를 비할당 상태로 변경하기 위해 inode 비트맵의 inode 5576 비트맵을 1에서 0으로 변경
이때 슈퍼 블록과 그룹 기술자 테이블에 있는 비할당 inode 개수 현황이 업데이트 됨

또 할당된 파일 내용의 블록을 할당 해제하기 위해 해당 블록의 블록 비트맵 값을 1에서 0으로 변경
블록 포인터 또한 inode에서 제거
이때 해당 inode의 수정 시간, 변경 시간, 삭제 시간이 업데이트 됨

위 과정은 다음 [그림 10]과 같다.

위처럼 삭제된 후 inode나 블록이 재할당만 되지 않으면 다시 파일을 복구할 수 있다.

(14) 파일 복구

Ext 파일 시스템은 Ext4 파일 시스템까지 버전이 출시되어 있는데, Ext2와 Ext3의 파일 삭제 방식이 조금 달라 파일 복구 방법도 조금 다르다.

Ext2에서는 파일 복구가 대체로 수월한 편이며, 이유는 파일이 삭제될 때 inode에 블록 포인터 값이 지워지지 않고 계속 남아 있기 때문이다.

또 삭제 시간이 업데이트 되어 파일이 언제 삭제되었는지 안다면 그에 맞는 inode를 찾는 일은 좀 더 쉬워짐하지만 블록 포인터 값이 inode에 남아 있다고 하여 100% 해당 파일의 내용을 복구하는 것은 아니다.

inode가 가리키고 있는 블록이 재할당되면 그 내용은 전혀 다른 내용이 되기 때문이며, 또 디렉토리 엔트리와 inode의 연결은 영구적으로 삭제가 되서 삭제된 inode를 찾으려면 비할당 inode 엔트리를 검색해야 한다.

Ext3에서는 디렉토리 엔트리와 inode 연결이 삭제 되지 않지만, 블록 포인터가 삭제되기 때문에 카빙 기술을 이용하여 파일 복구를 시도해야 한다.

카빙을 시도할 때의 정보 수집 범위는 보통 같은 블록 내에 할당하기 때문에 블록 그룹 단위이지만 어떤 OS는 파일 시스템 전체를 할당 대상으로 하기 때문에 OS에 따라 그 정보 수집 범위를 달리해야 한다.

만약 파일이 최근에 삭제된 것을 알고 싶다면 저널을 분석하는 것이 좋으며, 이유는 inode의 복사본이 저널 블록에 포함되어 있을지도 모르기 때문이다.

(15) 데이터 구조

15-1. 슈퍼 블록

슈퍼 블록의 파일 시스템에서 1024byte 오프셋에 위치하고, 그 크기 또한 1024byte

다음 표는 슈퍼 블록 오프셋 구조에 대한 내용이다.

[표 1] 슈퍼 블록 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
0~3	파일 시스템에 있는 inode 개수	76~79	주 버전
4~7	파일 시스템에 있는 블록 개수	80~81	예약 블록 사용 가능 UID
8~11	예약 블록 개수	82~83	예약 블록 사용 가능 GID
12~15	비할당 블록 개수	84~87	예약되지 않은 첫 번째 inode
16~19	비할당 inode 개수	88~89	inode 크기
20~23	블록 그룹 0 시작 블록	90~91	슈퍼 블록의 블록 그룹
24~27	블록 크기	92~95	호환성 가능 플래그
28~31	단편 크기	96~99	비호환성 기능 플래그
32~35	각 블록 그룹의 블록 개수	100~103	읽기 전용 속성 플래그
36~39	각 블록 그룹의 단편 개수	104~119	파일 시스템 ID
40~43	각 블록 그룹의 inode 개수	120~135	볼륨 이름
44~47	마지막 파일 시스템 마운트 시간	136~199	마지막 마운트 지점 경로
48~51	마지막 파일 시스템 수정 시간	200~203	비트맵 사용 알고리즘
52~53	파일 시스템 마운트 횟수	204~204	미리 할당된 블록 개수 (파일)
54~55	마운트 가능한 파일 시스템 최대 개수	205~205	미리 할당된 블록 개수 (디렉토리)
56~57	시그니처(0xEF53)	206~207	사용 X
58~59	파일 시스템 상태	208~223	저널 ID
60~61	오류 처리	224~227	저널 inode
62~63	부 버전	228~231	저널 장치
64~67	일관성 검사 간격	232~235	고아 inode 목록의 헤드
72~75	파일 시스템 생성 운영체제	236~1023	사용 X

블록 크기

이 값은 직접적인 값이 아닌 간접적인 값
1024를 해당 오프셋의 값만큼 왼쪽으로 쉬프트 연산하여 블록 크기를 구해야 함

단편 크기

이 값 또한 블록 크기와 동일한 방법으로 구함

파일 시스템 상태

0x0001 : 정상
0x0002 : 오류
0x0004 : 고아 inode 복수

오류 처리

1 : 정상
2 : 파일 시스템을 읽기 전용으로 다시 마운트해야 함
3 : 패닉

파일 시스템 생성 운영체제

0 : 리눅스
1 : GNU hard
2 : Masix
3 : FreeBSD
4 : Lites

주 버전

파일 시스템의 버전을 나타내는 값
일반 버전(0), 동적 버전(1) 두 가지 버전이 존재
값이 1로 설정되어 있지 않으면 84byte 오프셋 앞에 있는 값들은 정확하지 않을 수 있음

호환성 기능 플래그

0x0001 : 디렉토리 블록을 미리 할당 (단편화 예방)
0x0002 : AFS 서버 inode 지원
0x0004 : 파일 시스템 저널 지원 (Ext3)
0x0008 : inode가 확장된 속성을 가짐
0x0010 : 파티션 크기 다시 설정
0x0020 : 디렉토리가 해시 인덱스를 사용

비호환성 기능 플래그

0x0001 : 압축
0x0002 : 디렉토리 엔트리가 파일 타입 필드를 포함
0x0004 : 파일 시스템 복구 필요
0x0008 : 저널 장치 사용

읽기 전용 속성 플래그

0x0001 : Sparse 슈퍼 블록과 그룹 기술자 테이블
0x0002 : 대용량 파일을 포함
0x0004 : B-Tree 알고리즘 사용

15-2. 그룹 기술자 테이블

파일 시스템 블록에 위치하는 그룹 기술자 그룹의 목록을 뜻함
슈퍼 블록 다음 블록에 위치
그룹 기술자 테이블의 엔트리는 각 블록 그룹의 정보를 가지고 있으며, 테이블의 크기는 32byte

테이블 파일 시스템 블록의 크기가 4096byte일때는 슈퍼 블록이 0에 위치하고, 그룹 기술자 테이블은 블록 1에 위치한다.

또 파일 시스템 블록의 크기가 1024byte 일때는 슈퍼 블록이 1에 위치하고, 그룹 기술자 테이블은 블록 2에 위치한다.

다음 표는 그룹 기술자 테이블 오프셋 구조에 대한 내용이다.

[표 2] 그룹 기술자 테이블 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
0~3	블록 비트맵 시작 블록 주소	14~15	그룹에 할당되지 않은 inode 개수
4~7	inode 비트맵 시작 블록 주소	16~17	그룹의 디렉토리 개수
8~11	inode 테이블 시작 블록 주소	18~31	사용 X
12~13	그룹에 할당되지 않은 블록 개수

블록 비트맵의 시작 블록 주소

해당 오프셋의 값은 오프셋이 아니라 단순히 블록 번호에 불과

inode 비트맵의 시작 블록 주소

블록 비트맵의 시작 블록 주소 오프셋과 의미가 동일

15-3. 블록 비트맵

파일과 디렉토리의 내용이 저장되는 블록의 할당 상태를 관리하는 부분
각 비트와 블록은 맵핑 관계
시작 위치는 그룹 기술자 테이블에 정의되어 있음

각 바이트를 비트로 변환하면 할당 상태를 알 수 있다.

15-4. inode

inode 데이터 구조체는 파일이나 디렉토리의 메타 데이터를 저장
inode들은 각 블록 그룹에 위치하는 inode 테이블에 위치
inode 테이블 위치는 그룹 기술자 테이블에 정의되어 있고, 그룹별 inode 개수는 슈퍼 블록에 정의되어 있음

다음 표는 inode 오프셋 구조에 대한 내용이다.

[표 3] inode 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
0~1	파일 크기	88~91	단일 간접 블록 포인터
2~3	사용자 ID 하위 16bit	92~95	이중 간접 블록 포인터
4~7	파일 크기(byte)	96~99	삼중 간접 블록 포인터
8~11	접근 시간	100~103	생성 번호(NFS)
12~15	변경 시간	104~107	확장 속성 블록(파일 ACL)
16~19	수정 시간	108~111	크기 상위 32bit
20~23	삭제 시간	112~115	단편 블록 주소
24~25	그룹 ID 하위 16bit	116~116	블록 단편 인덱스
26~27	링크 개수	117~117	단편 크기
28~31	섹터 개수	118~119	사용 X
32~35	플래그	120~121	사용자 ID 상위 16bit
36~39	사용 X	122~123	그룹 ID 상위 16bit
40~87	직접 블록 포인터 (12개)	124~127	사용 X

기본적인 inode의 크기는 128byte이며, 만약 파일 시스템 버전이 동적 버전으로 설정되면 inode의 크기 또한 동적으로 변한다.

파일 모드

타입과 허가권을 나타냄
오프셋이 2byte 크기인데 bit로 변환하여 3개의 구역으로 나누어 플래그 값들이 설정

해당 오프셋의 값을 bit로 변환하여 구역을 나눈 모습을 다음 [그림 12]에서 볼 수 있다.

각 구역에는 다음 목록과 같은 플래그 값이 2진수로 변환되어 들어갈 수 있다.

[표 4] 접근 권한 플래그 목록

값	설명	값	설명
0x001	기타 사용자 - 실행 권한	0x020	그룹 - 읽기 권한
0x002	기타 사용자 - 쓰기 권한	0x040	사용자 - 실행 권한
0x004	기타 사용자 - 읽기 권한	0x080	사용자 - 쓰기 권한
0x008	그룹 - 실행 권한	0x100	사용자 - 읽기 권한
0x010	그룹 - 쓰기 권한

계산은 간단하다.

[그림 12]에 나와 있는 값을 예로 들어보자.

값을 각 자리 별로 분리하여 hex로 변환 후 플래그 목록 값에서 해당하는 값을 찾으면 된다.

만약 리눅스의 권한을 숙지하였다면, 해당 2진수 값을 8진수로 변환하여 권한을 바로 파악하는 것도 좋다. (110100100 > 644)

110100100 > 100000000, 10000000, 100000, 100
100000000 > 0x100 > 사용자 - 읽기 권한
10000000 > 0x80 > 사용자 - 쓰기 권한
100000 > 0x20 > 그룹 - 읽기 권한
100 > 기타 사용자 - 읽기 권한

[표 5] 실행 속성 플래그 목록

값	설명
0x200	Sticky bit
0x400	Set GID
0x800	Set UID

[표 6] inode 파일 타입 플래그 목록

값	설명	값	설명
0x1000	FIFO	0x8000	일반 파일
0x2000	문자 장치	0xA000	심볼릭 링크
0x4000	디렉토리	0xC000	유닉스 소켓
0x6000	블록 장치

타임스탬프(접근, 변경, 수정, 삭제 시간)

해당 오프셋 값들은 UTC 1970년 1월 1일을 기준으로 현재 시간까지의 초 값
이 값들은 2038년 1월부터는 계산이 불가능

플래그

inode가 할당된 파일에 설정되어 있는 속성들을 표시한 오프셋 필드

다음 표는 inode 플래그 목록에 대한 내용이다.

[표 7] inode 플래그 목록

값	설명
0x00000008	동시 업데이트(업데이트 데이터를 디스크에 바로 씀)
0x00000010	고정 파일(내용 수정 불가)
0x00000020	덮어쓰기 불가, 이어쓰기 가능
0x00000040	Dump 불가능 파일
0x00001000	해시 트리 사용 디렉토리
0x00002000	저널링(Ext3)

15-5. 확장 속성

Ext 파일 시스템에서 파일이나 디렉토리에 존재
우리가 흔히 알고 있는 권한도 확장 속성에 해당
확장 속성 또한 다른 영역들과 마찬가지로 구조체 형식으로 정의되어 있음

확장 속성은 기본적으로 다음의 3가지 영역으로 나누어져 있다.

헤더 영역
이름 엔트리 영역
데이터 영역

헤더 영역 다음에 이름 엔트리 영역이 오는데 일반적으로 영역들은 붙어 있지만, 데이터 영역은 나머지 두 영역과 다르게 블록 마지막에 존재하여 두 영역과 붙어 있지 않다.

더군다나 데이터 영역은 블록 마지막에서 블록 처음을 향하여 데이터가 점차 쌓인다.

데이터 영역에 있는 데이터들은 속성에 이름 엔트리와 대응되는 데이터들이지만, 이름 엔트리 순서와 데이터 순서가 동일하게 매칭되는 것은 아니다.

헤더 영역

확장 속성의 헤더 영역은 32byte 크기
시그니처를 가지고 있고 블록의 0byte 오프셋부터 시작

다음 표는 헤더 영역 오프셋 구조에 대한 내용이다.

[표 8] 헤더 영역 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
0~3	시그니처(0xEA020000)	12~15	해시 값
4~7	참고 횟수	16~31	예약 영역
8~11	블록 개수

참고 횟수 : 확장 속서의 블록은 여러 파일이나 디렉토리에 공유되어 참고 카운트는 해당 블록을 공유 받아 사용 중인 블록이 몇 개인지 판별해 주는 필드
블록 개수 : 확장 속성을 가진 블록이 몇 개의 확장 속성을 가졌는지 판별해 주는 필드 (현재까지는 사용되지 않음)
해시 값 : 중복 속성을 구별할 때 사용되는 해시 값

이름 엔트리 영역

헤더 영역 바로 다음에 위치
이름 엔트리와 매칭되는 데이터의 정보와 이름 정보가 포함되어 있음

다음 표는 이름 엔트리 오프셋 구조에 대한 내용이다.

[표 9] 이름 엔트리 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
0~0	이름 길이	8~11	데이터 크기
1~1	속성 타입	12~15	데이터 해시
2~3	데이터의 위치 오프셋	16~	이름(ASCII)
4~7	데이터가 포함되어 있는 블록 위치

속성 타입

1 : 사용자 공간 속성
2 : POSIX ACL
3 : POSIX ACL 기본
4 : 신뢰성이 있는 공간 속성
5 : LUSTRE
6 : 보안 공간 속성

값 중 3이라는 값을 가지는 속성은 디렉토리에만 해당하며, 5라는 값을 가지는 속성은 현재 리눅스에서는 사용되지 않고 있다.

POSIX ACL 속성은 헤더와 엔트리로 구성되어 있다.

[표 10] POSIX ACL 헤더 오프셋 구조

범위(Byte)	설명
0~3	버전

[표 11] POSIX ACL 엔트리 오프셋 구조

범위(Byte)	설명
0~1	타입
2~3	접근 권한
4~7	사용자 / 그룹 ID

POSIX ACL 엔트리의 첫 번째 오프셋인 타입 필드는 POSIX ACL 속성이 설정된 엔트리의 허가된 종류를 의미한다.

POSIX ACL 허가 타입 목록은 다음과 같다.

0x01 : 사용자 - inode에서 지정
0x02 : 사용자 - 속성에서 지정
0x04 : 그룹 - inode에서 지정
0x08 : 그룹 - 속성에서 지정
0x10 : 효과적인 권한 마스크
0x20 : 기타

0x01, 0x04, 0x20의 경우 inode에서 복사된 정보들이다.

그렇기에 따로 접근 권한을 설정해 줄 필요가 없다.

나머지 값들의 접근 권한 플래그는 엔트리 목록에 있는 필드 중 접근 권한 필드에서 설정해 주어야 한다.

접근 권한 필드의 플래그 목록은 다음과 같다.

0x01 : 실행
0x02 : 쓰기
0x03 : 읽기

데이터의 위치 오프셋

해당 이름 엔트리와 대응 되는 데이터의 오프셋 위치

데이터가 포함되어 있는 블록 위치

해당 이름 엔트리와 대응 되는 데이터의 블록 위치
현재 리눅스에서는 하나의 블록만 사용하기 때문에 해당 필드에 설정 되어 있지 않을 수도 있음

데이터 크기

해당 엔트리와 대응 되는 데이터의 크기

15-6.디렉토리 엔트리

파일이나 디렉토리의 이름을 저장하고, 파일이나 디렉토리에 할당된 inode의 주소를 저장
자신과 맵핑 관계인 디렉토리에 할당 된 블록에 위치
디렉토리 엔트리 데이터 구조에는 두 가지 유형이 존재
하지만 이 두 유형의 크기는 동일하며 차이점은 파일 타입의 유무
디렉토리 엔트리에 어떤 유형이 사용되는지는 슈퍼 블록에서 정의
현재는 파일 타입 필드가 포함된 디렉토리 엔트리 유형을 사용

먼저 파일 타입이 없는 데이터 구조를 확인해보자.

[표 12] 예전에 사용되었던 디렉토리 엔트리 오프셋 구조

범위(Byte)	설명
0~3	inode 번호
4~5	해당 엔트리 길이
6~7	이름 길이
8~	이름 (ASCII)

[표 13] 현재 사용 중인 디렉토리 엔트리 오프셋 구조

범위(Byte)	설명
0~3	inode 번호
4~5	해당 엔트리 길이
6~6	이름 길이
7~7	파일 타입
8~	이름 (ASCII)

inode 번호

우리가 흔히 보는 inode 번호를 나타냄

해당 엔트리 길이

해당 구조체를 포함하고 있는 엔트리 길이

이름 길이

해당 디렉토리 엔트리가 할당된 파일(디렉토리)의 이름 길이

이름

이름 길이에 따라 이름 필드의 크기는 달라짐

파일 타입

해당 디렉토리 엔트리가 할당된 것이 파일인지 디렉토리인지를 구분하여 주는 필드

파일 타입은 다음과 같은 목록 갑들에 따라 구분

0 : 정의되지 않은 타입
1 : 정규 파일
2 : 디렉토리
3 : 문자 장치
4 : 블록 장치
5 : FIFO
6 : 유닉스 소켓
7 : 심볼릭 링크

두 번째 디렉토리 엔트리들을 찾으려면 해당 엔트리의 크기를 해당 디렉토리 시작 오프셋에서 더하면 두 번째 디렉토리 엔트리를 찾을 수 있다.

이러한 식으로 계속 다음 디렉토리 엔트리를 찾으면 되는데 만약 디렉토리 엔트리 크기가 이름 길이에 비해 볼 필요할 정도로 크다면 그 디렉토리 엔트리와 다음 디렉토리 엔트리 사이에 파일이 삭제되었음을 의미한다.

15-7. 해시 트리

Ext 파일 시스템에서 디렉토리의 엔트리들을 정렬하기 위해 사용하는 알고리즘
각 노드는 디렉토리의 각 블록
노드에는 노드 기술자라는 데이터 구조체가 있는데 노드 기술자는 다음 계층의 블록을 알려주는 역할을 함
노드 기술자는 헤더와 엔트리로 나누어 지는데, 헤더는 디렉토리 엔트리 다음에 위치

다음 표는 노드 기술자 헤더 오프셋 구조에 대한 내용이다.

[표 14] 노드 기술자 헤더 오프셋 구조

범위(Byte)	설명
0~3	사용 X
4~4	해당 버전
5~5	해당 구조체 길이
6~6	리프(leaf) 레벨
7~7	사용 X

노드 기술자 엔트리는 노드의 해시 값 중 가장 작은 해시 값과 노드의 디렉토리 블록을 저장하고 있다.

[표 15] 노드 기술자 엔트리 오프셋 구조

범위(Byte)	설명
0~3	노드의 가장 작은 해시 값
4~7	블록 주소

첫 번째 노드 기술자 엔트리의 경우 최소 해시 값이 0이어야만 해서 해시 값이 설정되지 않는다.

이러한 이유로 첫 번째 노드 기술자 엔트리의 구조는 [표 15]와 조금 다른데 그 형태는 [표 16]과 같다.

[표 16] 첫 번째 노드 기술자 엔트리 오프셋 구조

범위(Byte)	설명
0~1	노드 기술자 최대 번호
2~3	노드 기술자 번호
4~7	첫 번째 노드의 블록 위치

저널

저널링은 파일 시스템이 손상되었을 때 복구를 하기 위하여 평상시에 메타데이터 업데이트 사항을 기록해 두는 기술
Ext3 파일 시스템에는 저널을 위한 4개의 블록이 존재
저널 슈퍼 블록, 기술자 블록, 적용 블록, 취소 블록이 4가지 블록에 해당
이 4개의 블록의 데이터 구조체는 모두 동일한 헤더를 가짐

다음 표는 저널 블록들의 표준 헤더 오프셋 구조에 대한 내용이다.

[표 17] 저널 블록들의 표준 헤더 오프셋 구조

범위(Byte)	설명
0~3	시그니처(0xC03b3998)
4~7	블록 타입
8~11	순서 번호

블록 타입 (4개의 블록들을 구분하는데 사용)

1 : 기술자 블록
2 : 적용 블록
3 : 슈퍼 블록 버전 1
4 : 슈퍼 블록 버전 2
5 : 취소 블록

블록 타입이 기술자 블록 값을 가지면 해당 저널 블록은 다음 표와 같은 구조를 가진다.

[표 18] 기술자 블록 오프셋

범위(Byte)	설명	범위(Byte)	설명
0~11	표준 헤더	16~19	엔트리 플래그
12~15	파일 시스템 블록	20~35	UUID

엔트리 플래그 (어떤 상태인지를 나타내주는 플래그)

0x01 : 저널 블록 취소
0x02 : 엔트리는 이전 UUID를 보유
0x04 : 이번 트랜젝션으로 블록이 삭제
0x08 : 기술자 블록의 마지막 엔트리

기술자 블록의 20~35 오프셋 필드인 UUID는 SAME_UUID 플래그가 설정되지 않으면 존재하지 않는 필드이다.

엔트리 플래그의 UUID 또한 마찬가지이며, 엔트리 플래그의 트랜젝션 블록 삭제 플래그는 현재 사용되지 않고 있다.

슈퍼 블록 버전 1과 2는 구조가 조금 다르기 때문에 값 또한 다른 것이다.

버전 1과 2는 다음과 같은 공통 구조체를 가진다.

[표 19] 슈퍼 블록 버전 1과 2의 공통 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
0~11	표준 헤더	24~27	첫 번째 트랜젝션 순서 번호
12~15	저널 블록 크기	28~31	첫 번째 트랜젝션 저널 블록
16~19	저널 블록 개수	32~35	오류 번호
20~23	저널의 실제 시작위치 블록

버전 1이라면 [표 19]의 36byte만 사용하지만, 버전 2일 경우 추가적인 오프셋 구조를 가진다.

추가적인 오프셋 구조는 [표 20]과 같다.

[표 20] 버전 2일 경우의 사용하는 추가적인 오프셋 구조

범위(Byte)	설명	범위(Byte)	설명
36~39	호환 기능	68~71	슈퍼 블록 복사본 위치
40~43	비호환 기능	72~75	트랜젝션별 저널 블록 최대 개수
44~47	읽기 전용 호환 기능	76~79	트랜젝션별 파일 시스템 블록 최대 개수
48~63	저널 GUID	80~255	사용 X
64~67	저널을 사용하는 파일 시스템 개수	256~1023	저널을 사용하는 파일 시스템 ID(16byte)

취소 블록은 포쥰 헤더를 기본적으로 가지고 있고, 독자적인 정보로는 취소된 파일 시스템 블록들의 목록을 가지고 있다.

취소 블록의 구조는 다음과 같다.

[표 21] 취소 블록의 오프셋 구조

범위(Byte)	설명
0~11	표준 헤더
12~15	취소 데이터의 크기(Byte)
16~	파일 시스템 블록 주소(4Byte) 목록

# Reference

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

저작자표시

'Digital Forensics > Forensic Theory' 카테고리의 다른 글

[Digital Forensic] Registry 분석 (0)	2020.05.08
[Digital Forensic] EXT 파일 시스템 (3) (0)	2020.04.02
[Digital Forensic] EXT 파일 시스템 (1) (0)	2020.04.01
[Digital Forensic] NTFS 파일 시스템 (4) (0)	2020.04.01
[Digital Forensic] NTFS 파일 시스템 (3) (0)	2020.04.01

Yum_Yum