본문 바로가기

[+] Forensic

File System - Ext (5)

이번 글에서는 파일 이름 참조 모델에 해당하는 데이터에 대해서 알아 보도록 하겠다.

[디렉토리 엔트리]
Ext 파일시스템에서는 파일과 디렉토리의 구분을 Inode에 있는 특별한 타입 값으로 구분 짓는다. 디렉토리들은 디렉토리 엔트리 데이터 구조체의 목록을 포함하는 블록들을 할당 받게 되는데, 디렉토리 엔트리는 파일 이름과 메타데이터가 어디 있는지 설명하는 데이터 구조체이다. 

 * 참고 : 디렉토리 크기는 디렉토리 엔트리 구조체 목록을 포함하는 블록의 크기와 관련이 있다.

모든 디렉토리는 자신과 부모를 나타내는 ".', ".." 디렉토리 엔트리를 포함하고 또 이 두개를 엔트리 시작으로 삼는다. ".", ".." 다음으로는 디렉토리 내의 파일과 하위 디렉토리의 엔트리들이다.

 * 참고 : 루트 디렉토리는 항상 Inode 2에 위치한다.

모든 파일 이름은 동적이어서 디렉토리 엔트리의 길이 또한 동적이다. 이러한 이유로 디렉토리 엔트리에는 이름 길이를 식별하는 디렉토리 엔트리 레코드 값이 존재한다. 디렉토리 엔트리의 길이는 이름 이외에 고정된 8byte가 있어 4의 배수로 반올림 된 레코드 값과 8byte를 더하여 결정한다. 레코드 값은 이름의 길이만큼 값이 주어져 다음 디렉토리 엔트리의 위치를 판별하는데 사용 될 수 있다. 

[그림 1 - 디렉토리 엔트리의 기본]

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

[그림 1]의 경우 이름의 길이대로 레코드 값이 설정되어 다음 디렉토리 엔트리 바로 앞을 가리키고 있다. 하지만 파일이 삭제 되면 파일의 이름이 변경되는데 운영체제는 그러한 파일을 화면상으로 출력하지 못한다. 또 운영체제는 삭제 파일 이전의 디렉토리 엔트리의 레코드 값을 삭제 파일 다음 디렉토리 엔트리가 위치한 곳까지의 거리로 값을 증가시켜 삭제 된 파일을 숨겨버린다. 하지만 말 뜻대로 숨겼을 뿐 데이터는 지워지지 않아 복구가 가능하다.

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

[그림 2]의 경우 file2.txt를 삭제한 경우인데 이렇게 하면 사용자는 파일이 지워진 것으로 인식하게 될 것이다. 하지만 데이터는 그대로 블록에 남아 있다.

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


 

[링크]
Ext 파일시스템에서 제공하는 링크는 하드 링크와 소프트 링크가 있다. 하드 링크는 같은 파일시스템에 있는 파일이나 디렉토리에 추가적인 이름을 정의하는 것이고, 소프트 링크는 다른 파일시스템에 있는 파일이나 디렉토리에 추가적인 이름을 정의하는 것이다. 하드 링크는 링크가 생성되면 원본 이름인지 링크 이름인지 구분 할 수 없는 특징이 있다. 그 이유는 아래 그림과 같다.

[그림 3 - 하드 링크]

위 그림처럼 원본 Inode를 하드 링크가 같이 가리키고 있기 때문에 같은 파일시스템에 존재해야 하며 또 원본 파일 이름이 어떤 것인지 구분 할 수 없는 것이다.

 * 참고 : 하드 링크가 모두 해제 되지 않는 이상 파일은 삭제되지 않는다. 

소프트 링크는 심볼릭 링크 파일 타입으로 인해 생성 된다. 파일이 하나 생성 되었기 때문에 소프트 링크 파일만의 Inode가 존재하며 해당 Inode의 블록 또한 할당 된다. 소프트 링크 파일이 가리키고자 하는 파일의 전체 경로가 60 글자를 넘지 않으면 목적 파일이나 목적 디렉토리의 전체 경로는 소프트 링크 파일에 할당 된 Inode나 블록에 저장된다.
소프트 링크 파일의 블록은 블록 포인터로서 목적 파일을 가리키게 되는데 이와 같은 과정은 아래 그림을 참조하기 바란다.

[그림 4 - 소프트 링크]


[마운트]
디렉토리들은 파일과 볼륨을 마운트 하는데 사용 될 수 있다. 어떠한 파일시스템이 디렉토리에 마운트 되면 해당 디렉토리가 가지고 있던 파일들은 보이지 않게 되는데 이 방법은 파일을 숨기는데 사용 될 수 있다. 아래는 두 파일시스템이 한쪽 파일시스템 디렉토리로 마운트 되었을 때의 상황을 표현 한 것이다.

 [그림 5 - 마운트]


[해시 트리]
해시 트리는 NTFS에서의 b-tree와 비슷한 개념인데 그 정렬 기준이 파일 이름이 아닌 해시 값이다. 또 해시 트리는 파일시스템이 생성 될 때 사용자의 결정에 따라 사용 할 수 도 있고 사용하지 않을 수도 있는 기능이다. 만약 사용자가 사용한다고 설정을 하게 되면 슈퍼 블록에서 호환 플래그 기능을 설정하여 준다.

 * 참고 : Ext 파일시스템에도 b-tree가 있긴 하지만 아직 표준은 아니다.

해시 트리를 사용하게 되면 블록은 트리 구조에서 노드가 되며 그 노드는 각 파일들을 포함하게 된다. 디렉토리가 해시 트리를 사용 할 경우 어떤 구조가 되는지는 아래 그림에서 확인 해 보자.

 [그림 6 - 해시 트리 디렉토리]

노드 기술자는 기준이 되는 해시 값과 블록 주소를 포함하고 있다.

 * 참고 : 만약 해시 트리를 인식하지 못하는 OS라면 해시 트리로 인해 정렬된 순서를 무시한다. 


[할당 알고리즘]
리눅스의 경우 "첫 번째 적용" 정책을 사용하여 디렉토리 시작 부분부터 디렉토리 엔트리를 검색한다. 이름 길이를 파악하여 엔트리의 적당한 길이를 계산하고 엔트리 길이와 실제 레코드 길이를 비교하여 엔트리 길이보다 실제 레코드 길이가 더 길다면 해당 디렉토리 엔트리가 블록의 마지막이거나 삭제 된 파일의 이전 디렉토리 엔트리라고 판단한다. 그 후 새로운 디렉토리 엔트리를 할당 할 때 레코드의 길이가 엔트리 길이보다 큰 디렉토리 엔트리에 새로운 디렉토리 엔트리를 할당하여 이전 데이터를 지운다. 만약 해시 트리가 적용되어 있다면 해당 해시 값 블록에서 이러한 과정이 일어난다.


[분석 시 주의 사항]
Ext3 파일시스템의 경우 Inode 번호가 리눅스에 의해 지워지지 않는다. 이로 인해 파일을 복구 할 수 있다. 리눅스는 디렉토리 엔트리 구조체의 새로운 파일 이름 길이가 같거나 더 작은 경우 디렉토리 엔트리를 비 할당 상태로 남겨두는데 이러한 이유로 긴 이름의 파일 디렉토리 엔트리가 짧은 이름의 디렉토리 엔트리보다 더 빨리 덮어 씌어진다. 삭제 된 파일을 복구 할 때 파일이름을 찾았어도 Inode가 재 할당 되면 파일 복구는 불가능하다. 하지만 Inode가 재 할당 되었다는 결정은 쉽게 내리지 못한다. 한가지 방법이 있다면 Inode 타입과 디렉토리 엔트리 타입을 비교하여 타입이 다르면 재 할당 되었다고 판단하는 것이다. 또 분석 시 히든 데이터를 주의 해야 한다. 마지막 디렉토리 엔트리와 블록 마지막 사이에는 비 할당 된 공간이 있다. 이 공간에 히든 데이터가 있을 수 있다. 하지만 이 경우는 해시 트리를 사용 했을 때 적용되는 사항이다. 


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

File System - Ext (7)  (0) 2012.02.23
File System - Ext (6)  (0) 2012.02.22
File System - Ext (5)  (0) 2012.02.22
File System - Ext (4)  (0) 2012.02.21
File System - Ext (3)  (0) 2012.02.21