[Case Study] 파일 찾기, 모래밭에서 바늘 찾기?

- EXT2 파일 마운트를 활용한 파일 추적
 
컴퓨터를 이용해 업무를 하다 보면 종종 내가 저장했던 파일이 도대체 어디에 있는지 기억나지 않을 때가 있다. 저장한 파일이 어디에 위치하는지에 대한 도움말을 얻을 수 있는 문서도 흔치 않을뿐더러, 설사 그런 문서가 있다 해도 제대로 풀이한 내역을 찾기 어렵다. 이 글에서는 수많은 파일이 존재하는 컴퓨터에서 원하는 파일을 정확히 찾아낼 수 있는 방법에 대해 알아본다.

 

일반적으로 어떤 물건을 택배로 주문하면 택배 기사 아저씨는 주문자의 주소를 확인하여 정확한 장소로 물건을 배달한다. 이와 유사하게 파일은 파일 시스템에서 오프셋(Offset)이라는 값을 가지며, 그 값을 파일 시스템이 해석하여 내용을 화면에 출력함으로써 사용자가 손쉽게 파일을 찾을 수 있게 해준다.

이와 관련해 이 글에서는 파일 시스템이 어떻게 오프셋을 확인하여 어떻게 사용자에게 알려주는지 알아본다. 이를 위해 헥스에디터(HexEditor)를 활용하며 Sleauth kit과 분석 OS로는 리눅스(Linux)를 사용한다. Sleauth kit은 아래 링크에서 다운로드 할 수 있다.
▶ Sleuth Kit 다운로드: http://www.sleuthkit.org/sleuthkit/download.php

 

한편 OS를 리눅스로 이용하지 않는 사용자는 가상 머신을 이용할 수 있다. 가상 머신에 리눅스를 설치한 후 작업하면 마찬가지로 이후의 내용을 진행할 수 있다. 가상 머신으로는 VMware나 버추얼 박스(Virtual Box) 같은 도구들이 있으며, 리눅스는 우분투(Ubuntu)를 사용할 수 있다. 우분투에서 Sleauth Kit을 설치하려면 ‘apt-get install sleuthkit’ 명령어를 이용하면 된다.
▶ 우분투(Ubuntu) 다운로드: http://www.ubuntu.com/download
▶ 버추얼 박스(Virtual Box) 다운로드: https://www.virtualbox.org/wiki/Downloads

 

해당 킷을 설치한 후 EXT2 포맷 형태의 파일을 만들어 분석해본다. 분석 방법은 다음과 같다.
①  리눅스에서 EXT2 파일 만들기
②  EXT2 파일에 파일 생성(그림 파일)
③  EXT2 파일 이미징(Imaging)
④  EXT2 파일 시스템(File System) 구조 확인
⑤  헥스에디터(HexEditor)로 이미징(Imaging) 분석
⑥  오픈소스로 EXT2에 생성한 파일 덤프(Dump)

 

1. 볼륨 이미징(Volume Imaging)
파일 시스템의 구조를 확인하기 위해 0으로 채워진 더미(dummy) 파일을 생성한 후, 해당 파일을 EXT2 파일 시스템으로 포맷한다. 포맷된 더미 파일은 마운트(mount) 명령어를 사용하여 EXT2 파일 시스템으로 사용할 수 있다.
▶ EXT2 참고: http://ko.wikipedia.org/wiki/Ext2

 

이 글에서는 마운트 명령어로 EXT2 파일을 마운트한 뒤, 임의의 파일을 생성하고 생성된 내역을 헥스 코드(Hex Code)로 따라갈 것이다. 이러한 방법은 파일 시스템의 동작 방법을 이해할 수 있도록 도와준다. 파일 시스템의 동작 방법을 이해하면 포렌식 도구를 더욱 효과적으로 사용할 수 있으며, 도구에 관계없이 분석이 가능하다.

 

(1) 더미(Dummy) 파일 생성
0으로 채워진 더미(Dummy) 파일을 생성하기 위해 /dev/zero라는 파일을 이용한다. /dev/zero는 output으로 0으로 채워진 파일을 생성할 수 있게 해준다. 0으로 채워진 파일을 만들기 위해 dd명령어를 사용하며, 명령어는 [그림 1]과 같다.

[그림 1] 더미 파일(Dummy File) 생성

 

더미 파일(Dummy File) 생성에 사용된 dd명령어는 원하는 데이터를 인풋(input)으로 넣을 수 있으며, 크기를 지정하여 파일을 자르거나 붙일 수 있다.

 

# dd if=/dev/zero of=/dorumugs/zero.dd bs=4096 count=100

 

0으로 채워진 더미 파일을 마운트하기 위해 리눅스가 해석할 수 있는 파일 시스템으로 포맷해야 하다. 포맷에 사용되는 명령어는 mkfs이며, 사용된 명령어는 [그림 2]와 같다. 리눅스 파일 시스템은 EXT2~4까지 다양하다. 이 글에서는 EXT2를 사용하였지만 EXT2 대신 EXT3나 EXT4로 포맷하여도 무방하다.

 

# mkfs –T ext2 zero.dd

 

[그림 2] EXT2 파일 포맷

 

포맷을 완료하고, 포맷된 상태를 확인하기 위해 ‘file’이라는 명령어를 사용하였다. 파일(file) 명령어를 사용하면 파일 상태를 확인할 수 있으며, 해당 파일이 어떤 파일인지 알 수 있다. 사용된 명령어는 [그림 3]과 같다.

 

# file zero.dd

 

[그림 3] 파일 타입 확인
 

파일 시스템에 파일이 어떻게 존재하는지 확인하기 위해 포맷된 EXT2파일에 임의의 파일을 넣는다. 임의의 파일을 넣기 위해서는 먼저 포맷된 EXT2 파일을 마운트해야 하며, 마운트하는 방법은 [그림 4 ]와 같다.

 

마운트된 내역을 확인하는 방법은 다양하며, 이 글에서는 편의상 [그림 4]와 같이 df명령어를 사용하였다. df 명령어를 사용할 경우, 마운트된 내역을 확인할 수 있을 뿐 아니라 마운트된 장치나 파일 등의 사용 내역 또한 확인할 수 있어 편리하다.

 

# mount -o loop /dorumugs/zero.dd /mnt/dorumugs/
 

[그림 4] 파일 마운트(mount) 및 확인

 

정상적으로 포맷이 완료된 파일을 마운트할 경우, ‘lost_found’라는 디렉터리가 생성된다. ls 명령어로 마운트된 폴더를 확인할 수 있다. [그림 5]에서 해당 명령어가 사용된 것을 확인할 수 있다.

 

 
[그림 5] lost+found 및 복사된 그림 파일 확인

 

[그림 5]의 다음과 같은 경로에 [그림 6]의 파일명인 ahnlab.jpg를 넣는다. 

 

# mv /dorumugs/ahnlab.jpg /mnt/dorumugs/

 

이때 그림 파일이 아닌 다른 파일을 디렉터리에 넣어도 문제되지 않는다. 해당 그림 파일에 대해서는 다음의 ‘3. 수작업으로 파일시스템 확인하기’에서 헥스 코드(Hex Code)를 통해 파일 위치를 조사할 것이다.

 

[그림 6] ahnlab.jpg라는 이름의 그림 파일

 

(2) 디스크 이미징
EXT2에 그림 파일을 넣은 뒤, 파일의 위치 확인을 진행해도 문제가 되지는 않는다. 다만, 여기에서는 실제 서버를 분석하는 것처럼 디스크 이미징을 진행한다. 디스크를 이미징하는 방법은 여러 가지가 있지만 CLI(Command line interface, 명령 줄 인터페이스) 지원과 해시(hash) 값을 확인할 수 있는 dc3dd를 사용한다.
▶ CLI 참고 : http:// http://ko.wikipedia.org/wiki/CLI

 

이미징 작업을 수행할 때, 하드를 추가로 마운트하여 이미징을 할 수 있지만, 네트워크 통신이 가능할 경우 분석가 PC와 대상 서버의 통신을 통해 이미징 할 수도 있다. 이 글에서는 후자인 네트워크 작업을 수행한다.

[그림 7]의 ‘Suspect’는 대상 리눅스 시스템을 의미하며 ‘Evidence’는 네트워크를 통해 이미지를 전송 받을 분석가의 PC이다.

 

[그림 7] 네트워크 이미징 구성도

 

[그림 7]에서 볼 수 있듯이 대상 서버와 분석가의 PC를 같은 네트워크에 구성한 후 이미징을 진행하였다. 대상 리눅스(Suspect)에서 사용한 명령어와 분석가의 PC(Evidence)에서 사용된 명령어는 [표 1]과 같다.

 

[표 1] 이미징 명령어

 

이미징 작업이 완료되면 화면에 해시값(hash value)을 출력하며, dc3dd에서 사용한 hashlog옵션에 입력한 경로에 해시 파일이 생성된다. 두 해시 값을 비교하면 같은 값을 가지고 있는 것을 알 수 있다. 해시값 확인은 [그림 8]을 참고할 수 있다.

 

[그림 8] 이미지 해시 확인

2. EXT2파일 시스템
네트워크로 전송 받은 이미지를 분석하기 전에 분석에 필요한 파일 시스템 구성 요소를 확인한다. EXT2의 전체 그림은 [그림 9]와 같다.

 

EXT 파일 시스템은 데이터를 저장할 때 블록(Block)이라는 단위를 사용한다. 블록 단위는 1024 / 2048 / 4096 단위로 지정되며, 해당 단위를 바탕으로 데이터를 저장한다. 데이터는 1byte를 사용하더라도 기본 단위인 블록 크기만큼 할당된다. 이러한 단위를 윈도우(Windows)에서는 클러스터(cluster)라고 한다.

 

파일들은 EXT 파일 시스템에서 Group으로 쪼개져서 메타데이터(Metadata)와 데이터를 저장한다.
▶ 메타데이터 참고: http:// http://ko.wikipedia.org/wiki/메타데이터

[그림 9] EXT2 파일 시스템

 

Group은 SuperBlock에 정의되어 있는 크기에 맞춰 나뉘어지며, 마지막 Group이 SuperBlock에 정의되어 있는 크기보다 작을 경우, 해당 Group의 크기는 작은 크기에 맞게 구성된다. 각각의 Group에 대한 모양은 [그림 10]과 같다.

 

[그림 10]  Group

Group의 내용은 6가지로 분류할 수 있으며, 그 분류 내용은 다음과 같다.
①  Super Block: Group에 대한 메타데이터(Metadata)를 갖고 있다.
② Group Descriptor Table : Block Bitmap, Inode Bitmap, Inode Table의 위치에 대한 정보를 갖고 있다.
③ Block Bitmap : 어느 블록에 데이터가 할당되어 있는지 표시해준다.
④ Inode Bitmap : 어느 Inode에 데이터가 할당되어 있는지 표시해준다.
⑤ Inode Table : Group에서 사용하는 Inode를 담고 있다.
⑥ Data Blocks : Group에서 사용하는 데이터(Data)를 담고 있다.

3. 수작업으로 파일시스템 확인하기
네트워크로 전송 받은 이미지는 위의 내용을 바탕으로 파일(ahnlab.jpg)의 위치를 분석한다. 수작업 분석을 위해 헥스에디터(HexEditor)를 사용한다. 다양한 헥스에디터가 있으며, 이 글에서 사용하는 헥스에디터는 ghex2이다.
▶ HexEditor 참고: http://ko.wikipedia.org/wiki/HexEditor

 

ghex2를 사용하여 전송 받은 이미지를 오픈(Open)한다. 오픈한 파일에서 1024(0x400)만큼 이동한다. 파일의 시작점인 0x0에서부터 0x400만큼 이동하면 Super Block을 만날 수 있다.
 
Inode는 128byte의 크기를 가진다. 0x400에서 4byte는 Inode의 개수를 말하며, 0x38(56)이니 전체 Inode의 크기는 128 x 56 = 7168(0x1C00)이 된다.

 

7168을 block(1024)으로 나눠보면 7이 나온다. 그러므로 Inode는 7개의 블록을 사용한다는 것을 알 수 있다.
 
Super Block에서 확인할 수 있는 정보는 [그림 11]과 같다.

 

[그림 11] Super Block

 

0x800의 위치로 이동하면 Bitmap과 Inode가 어디에서 시작하는지 알 수 있는 Group Descriptor Table을 만날 수 있다. Group Descriptor Table의 정보는 [그림 12]에서 확인할 수 있다.

 

해당 위치로 이동하여 확인하게 되는 내용은 [표 2]에서 참고할 수 있다.
   

[표 2] Bitmaps과 Inode table 위치

 

[그림 12] Group Descriptor Table

 

Block Bitmap x Block Size를 계산하면 Block Bitmap의 위치를 계산할 수 있으며, Inode Bitmap x Block Size를 계산하면 Inode Bitmatp의 위치를 계산할 수 있다. 또한 Inodes Table x Block Size를 계산하면 첫 번째 Inode의 위치를 알 수 있다.

 

첫 번째 Inode의 위치를 계산하기 위해 0x809부터 4byte 크기의 값인 0x00000006값에 Block Size 1024를 곱했다. 계산 결과, 첫 번째 Inode의 위치는 0x1800인 것을 알 수 있었다. 계산 내용은 [표 3]에서 확인할 수 있다.

  

[표 3] 첫 번째 Inode 위치

 

[그림 13] Bitmaps의 위치와 첫 번째 Inode위치 및 Inode의 블록 크기

 

Inode는 0번부터 시작하며 0부터 5, 즉 총 6개는 예약되어 있다. Inode 하나의 크기는 128(0x80)이며, 예약된 크기는 128 x 6 = 768(0x300) 이다.

 

예약된 내역은 [표 4]와 같다.

  

[표 4] 예약된 Inode

 

하나의 Inode는 [그림 14]와 같이 다양한 속성을 가지고 있으며, 그 중 Directory Entry의 블록 위치를 갖고 있는 속성이 존재한다.
 

[그림14] Inode 속성

 

Directory Entry는 Inode를 갖고 있는 디렉터리(Directory) 안의 내용들을 엔트리(Entry) 형식으로 저장하고 있다. 저장한 내용은 디렉터리 안에 있는 파일명, Inode, 타입(Type) 등이 있다. 자세한 속성은 [그림 15]를 참고할 수 있다.

 

[그림 15] Directory Entries

 

1800이 첫 번째 Inode지만 Root Directory안에 있는 파일의 위치를 확인하기 위해서는 Root Inode를 확인한 후 블록 넘버(block number)를 확인해야 한다.

 

확인 결과, 0x0D이다. block number x block size를 하면, 디렉터리 엔트리(Directory Entry)를 확인할 수 있다. 실제 이미지 파일에서 확인한 블록 넘버는 [그림 16]에서 참고할 수 있다.

 

[그림 16] Root Inode의 블록 넘버(Block Number)

 

실제 이미지에서 Root Inode의 블록 넘버는 0x0D이다. 이 값에 블록 크기인 1024를 곱하면 디렉터리 엔트리로 이동할 수 있다. 13(0x0d)x1024(0x400) = 13312(0x3400) 이다. 해당 오프셋으로 이동하면 디렉터리 엔트리를 확인할 수 있다.

 

0x3400으로 이동하면, 루트 디렉터리(Root Directory)에 있는 파일명과 그 외 속성을 확인할 수 있다. 속성 중 Inode Number를 확인해야 하며, Inode Number는 찾고자 하는 파일명 앞 8byte에 위치한다. 찾아야 하는 파일은 이미지를 만들 때 복사한 ‘ahnlab.jpg’이다. 실제 이미지 파일에서 확인한 내용은 [그림 17]과 같다.

 

[그림 17] Root Inode의 Directory Entry

 

ahnlab.jpg의 8byte의 값을 확인한 결과, Inode Number가 0x0C인 것을 알 수 있다. 확인한 ‘Inode 값 + 첫 번째 Inode위치’를 하여 ahnlab.jpg의 Inode로 이동할 수 있다. 계산 내역은 [표 5]를 참고할 수 있다.

 

 

[표 5] Root Inode의 Block Number

 

[표 5]에서 계산한 ahnlab.jpg의 Inode로 이동하면 0x2C만큼 떨어진 지점에서 4byte크기의 블록 넘버를 확인할 수 있다. 실제 이미지에서 확인한 내용은 [그림 18]에서 볼 수 있다.

 

[그림 18] ahnlab.jpg의 Block Number

 

블록 넘버의 값을 블록 사이즈(Block Size)만큼 곱하게 되면 실제 ahnlab.jpg의 데이터를 확인할 수 있다. 계산 내역은 [표 6]과 같다.

 

 

[표 6] ahnlab.jpg 위치 계산

 

[표 6]에서 확인한 값만큼 이동하면 [그림 19]와 같이 jpg파일의 헤더(Header) 0xFFD8을 만날 수 있다. 해당 파일을 덤프하는 방법은 다음의 ‘4. 오픈소스를 사용한 파일 확인’에서 살펴본다.

 

[그림 19] ahnlab.jpg의 헤더(Header)

4. 오픈소스를 사용한 파일 확인
이미지에서 파일을 확인하기 위해 찾고자 하는 파일의 경로를 확인한 후, Inode정보를 사용하여 파일을 복구한다.
 
fls 명령어를 사용하여 디렉터리 구조와 찾고자 하는 파일의 Inode 정보를 확인한다. 그 후 icat 명령어를 사용하여 해당 Inode에 대한 데이터를 덤프한다. ahnlab.jpg의 Inode가 12라는 값을 나타내는데, 이 값은 디렉터리 엔트리에서 확인한 0x12라는 것을 알 수 있다. Inode값은 [그림 20]에서 확인할 수 있다.
 

[그림 20] fls으로 확인한 ahnlab.jpg

 

ahnlab.jpg의 Inode를 사용하여 복구하는 방법으로 icat을 사용하였다. 명령어를 사용한 내용은 [그림 21]을 참고할 수 있다.
 

[그림 21] icat을 사용한 ahnlab.jpg Dump

 

이렇게 덤프한 파일을 확인해보면 [그림 22]와 같이 처음에 이미지에 저장했던 ahnlab.jpg인 것을 확인할 수 있다.
 

[그림 22] 덤프한 파일에서 확인한 ahnlab.jpg