[ccibomb@CRG]# _bykim

Case ③ MBR의 Partition Entry가 전혀 없는 경우

-      복원 전 MBR : Partition Table Layout

-      하드 전체 Layout

-      하드디스크 정보 (229,824 Sectors, 112.2MB) 

-      인식 오류 발생 원인

MBR에 Partition Entry가 전혀 기록되어 있지 않다. 즉, Encase에서는 아무런 파티션도 인식하지 못하였다.

-      복원 과정

a.       MBR의 Partition Entry를 고의적으로 삭제하였을 경우, 실제 파티션의 시작 지점에 위치하는 VBR은 남아있는지를 우선적으로 확인한다. 이때, 첫 Primary Partition은 63번 섹터에서 시작하게 되므로 63번 섹터를 확인. 

           // OEM String 으로 보았을 때, NTFS 파일 시스템을 갖는 파티션이 존재함 확인

b.       첫번째 파티션(Primary, NTFS) 추가

c.       하지만, 이때 파티션이 여러 개 존재하는지 여부 및 파티션의 크기와 시작 위치 등은 MBR이 삭제 되었으므로 더 이상 알 수 없다.

따라서 다른 파티션을 찾아보기 위하여 Keyword로 Search 한다.

                        c-1. 먼저 OEM String 을 키워드로 등록한다.

c-2. Unused Disk Area와, OEM String 키워드를 체크하고 Search

d.       검색 결과 확인

// 총 4개가 검색되었다. 이때, VBR의 백업본도 함께 검색되므로, 선별 작업이 필요하다. 보통 NTFS의 경우 VBR 백업본은 가장 마지막 섹터이고, FAT32의 경우 VBR로부터 6번째 섹터에 기록되므로 이 하드 디스크의 총 파티션 수는 2개이며, NTFS와, FAT32 파일 시스템을 사용하고, 각각 파티션 시작 위치(VBR)은 63 과 128520 임을 알 수 있다.

e.    두 번째 파티션(FAT32) 인식

e-1.  시작 지점인 128520섹터로 가 본다.

(첫 번째 파티션의 마지막 섹터 바로 다음이다.)

// 바로 VBR이 위치하는 것을 알 수 있다. 첫 번째 파티션이 128519 에서 끝났으므로 두 번째 파티션 또한Primary Partition인 것을 알 수 있다. (BR이 없으므로, MBR에 등록되어있는 Primary임을 의미함)

 e-2. Add Partition

-      파티션 복원 완료

새로 추가된 E 드라이브의 Messages.txt 파일 내용 확인

-      추가 연구가 필요한 사항

추가하려는 E 드라이브 외에 D 드라이브(C와 E전부를 가리킴)가 생성되는 이유와 이를 포렌식적으로 제거하는 방법에 대한 연구가 필요하다.

c.f) 최종 복구 후 모습

Case ② MBR의 Partition Table 일부 및 확장 파티션의 BR이 손상된 경우

-      복원 전 MBR : Partition Table Layout

-      하드 전체 Layout

-      하드디스크 정보 (229,824 Sectors, 112.2MB)

-      손상여부 확인

a.       Disk 전체 섹터와 인식된 파티션의 섹터 크기 확인

전체 섹터 크기      : 229824 sector

첫 번째 파티션 크기 : 128457 sector

b.       전체 섹터 중에서 거의 반만 가진 하나의 파티션만을 가졌다고 하기는 의심스럽다. 첫 번째 파티션 후에도 새로운 파티션이 있는지 찾아봐야 한다.

-      인식 오류 발생 원인

MBR 에는 파티션 하나만 기록이 되어 있었으나, Unused Disk Space가 약 52MB로 나타나, 한 개의 파티션이 더 있을 것을 의심. 첫 번째 파티션의 끝 지점을 확인하였더니 다음 섹터(128520)의 마지막 부분에 55 AA의 Signature가 확인됨. 그로부터 63섹터 떨어진 128583 섹터를 확인하였더니 VBR로 판단됨. 즉, MBR 손상 및 확장 파티션의 BR 손상.

-      복원 과정

a.       첫 번째 파티션은 NTFS임을 확인(Signature : OEM String – NTFS)

b.       마지막 섹터에 VBR 백업본 확인

c.       다음 섹터를 확인

c-1.  MBR 정보 확인한 두 번째 파티션 시작위치 : Starting LBA 값 08 F6 01 00 와 일치

c-2. 새로운 파티션이 시작되어야 함.

MBR확인 결과 2번째 파티션 시작주소(128520 섹터)

d.       마지막 2 Bytes에 “55 AA” Signature 뿐으로, OEM String없음

d-1.  2번째 파티션이 Primary partition인 경우, 이 섹터는 VBR로서 OEM String이 삭제되고 File System의 Meta Data 등이 삭제된 것임

d-2.  2번째 파티션이 Extended partition인 경우, 이 섹터는 BR로서 이 파티션의 시작위치(다음 Container가 존재하는 경우, 다음 Container의 시작위치도 존재)를 가리키는 Partition Table이 삭제된 것임

e.       Extended Partition 인지 여부를 알기 위해 63 sector 이후 (125883 sector) 확인 :

// OEM String 확인, FAT 확인(File System의 Meta Data) : VBR

Extended Partition임, 즉 BR 정보가 조작된 것임

f.        2번째 파티션의 시작지점(VBR)인 128583sector에서 새로운 파티션 추가(Add Partition)

-      파티션 복원 완료 : 기존의 C 드라이브 외에 추가로 D 드라이브 생성

-      복원 과정

a.       MBR 정보 확인하여 두 번째 파티션 시작위치(Starting LBA 값 08 F6 01 00 : 128454 sector)로 이동

b.        마지막 2 Bytes에 “55 AA” Signature 뿐으로, OEM String이 없음

b-1.  2번째 파티션이 Primary partition인 경우, 이 섹터는 VBR로서 OEM String이 삭제되고 File System의 Meta Data 등이 삭제된 것임

b-2.  2번째 파티션이 Extended partition인 경우, 이 섹터는 BR로서 이 파티션의 시작위치(다음 Container가 존재하는 경우, 다음 Container의 시작위치도 존재)를 가리키는 Partition Table이 삭제된 것임 

c.f) Partition Layout (Primary Partition 2개, Extended Partition 2개인 경우)

c.       Extended Partition 인지 여부를 알기 위해 63 sector 이후 (125883 sector) 확인

           // OEM String 이 MSDOS5.0이므로 파일 시스템의 유형은 FAT32로 확인

d.        2번째 파티션의 시작지점(VBR)인 128583sector에서 새로운 파티션 추가(Add Partition)

//  확장 파티션이므로 ‘Unused Sectors before VBR = 63’

-      파티션 복원 완료 : 기존의 C 드라이브 외에 추가로 D 드라이브 생성

Case ① Boot Record의 VBR위치 정보 손상된 경우

-      복원 전 MBR : Partition Table Layout

-      하드 전체 Layout 

-      하드디스크 정보 (229,824 Sectors, 112.2MB)

-      손상여부 확인

a.       Unused Disk Area의 크기 확인

// 약 50 MB로 나타나, 파티션이 삭제되거나 인식되지 않았을 가능성 있음

b.       MBR 확인

Partition Table 확인 결과 총 2개의 Partition 정보가 수록되어 있으나, Encase에서는  C 드라이브 1개만 인식하고 있음

// Partition Table 해석 : 총 229824 섹터 중 첫 번째 파티션은 128457개의 섹터의 용량 차지, 시작 LBA는 63섹터. 두 번째 파티션은 96390섹터의 용량을 차지, 시작 LBA는 128458 섹터.

-      인식 오류 발생 원인

두 파티션 모두 Master Boot Record의 Partition Table에는 제대로 정보가 나타나 있었고, 첫 번째 파티션 (Primary Partition)은 VBR 또한 이상 없었지만, 두 번째 파티션의 경우 Extended Partition 으로 보이는데, BR에 VBR 위치 정보가 기록되어 있지 않아(손상) 인식이 되지 않음.

0. 증거 이미지 (Evidence File)
Encase 방법론의 가장 중요한 요소는 바로 증거 이미지 (Evidence file)이다. 이 파일은 세 가지 기본 요소(헤더, 체크섬, 데이터 블록)로 구성되는데, 이들은 분석시 컴퓨터 디스크의 상태를 Self-checking하여 제공한다.

1. CRC (Cyclical Redundancy Check)
CRC는 체크섬과 매우 비슷한 방식으로 동작하는데, 체크섬과 달리 Order-sensitive 특성을 지닌다. 즉, 문자열 "1234"와 "4321"은 같은 체크섬을 갖지만, 서로 다른 CRC를 가진다. 대부분의 Hard drive는 각 섹터마다 하나의 CRC를 저장한다. 디스크에서 Read 에러가 발생하였다는 것은 디스크 섹터의 CRC와 해당 섹터가 읽어진 후 drive hardware에 의해 재계산된 값이 서로 일치하지 않음을 의미한다.

2. 증거이미지 포맷 (Evidence File Format)
각각의 파일은 정확하게 섹터 대 섹터 사본이다. 파일이 생성될 때, 사용자는 조사와 관렦된 정보를 제공하게 된다. Encase는 이러한 정보 및 증거이미지 안에 있는 다른 정보들을 아카이브에 넣는다. 각 파일은 Data block마다 32-bit CRC를 이용하여 인증받음으로써, 조사관은 법정에 해당 증거를 제출할 수 있다.

Encase는 디스크 이미지 전체에 대한 CRC 값이 아닌, 개개의 블록마다 CRC를 계산하여 그 무결성과 속도를 높인다. 어느 파일이나 어느 섹터에서 에러가 발생하였는지 그 위치 확인도 가능하다.

또한, Encase는 Physical drive나 Logical drive 의 이미지 생성시, MD5 해쉬값을 계산하여 증거이미지에 그 일부로서 기록한다. 증거이미지를 Case 파일에 추가할 경우, CRC 값과 Hash 값을 통해 변경여부를 확인한다.

3. 압축 (Compression)
Encase는 압축기술로 데이터를 상대적으로 작은 크기로 저장한다. 평균 50%의 압축률을 보이는 산업표준 알고리즘을 이용하며, 디스크의 대부분이 Text인 경우, 그 압축 비율을 보다 높아진다. 그러나 JPG 파일과 같이 이미 압축된 파일들이 많은 경우에는 그 효율이 낮다. 압축을 위한 시간이 더 소모되긴 하지만, 압축과정은 증거이미지에 전혀 영향을 끼치지 않으며, 압축 블록은 비압축 블록과 동일한 과정으로 검증된다. 즉, 서로의 Hash Value는 동일한 값을 가진다.

4. Case 파일
Case 파일은 하나의 Case에 대한 구체적인 정보(하나 또는 그 이상의 증거이미지에 대한 포인터, 북마크, 검색 결과, 정렬, 해쉬 분석 결과, Signature 분석 결과 등)를 포함한다. Encase를 통해 증거이미지를 분석하기 위해서는 그 이전에 Case 파일이 생성되어야 한다.

5. Case 백업 파일
백업 파일은 Encase가 설치된 폴더의 Backup이라는 하위폴더 내에 자동으로 기본 10분마다 저장되며, .CBAK 이라는 확장자를 지닌다. .CASE 파일에 에러가 발생핚 경우, .CBAK 파일이 열릴 수 있으며, .CBAK 파일을 .CASE 파일로 바꿀 수 있다.

6. 환경 설정 파일
Encase 환경설정 파일은 일련의 초기화 파일(.INI)들이라고 할 수 있다. Signature 테이블, 파일 유형, 파일 viewer, 필터, Global Keyword 등 Global setting 정보들은 모든 Case와 모든 증거이미지에 적용된다. 일반적으로 Encase 설치 폴더의 Config라는 하위폴더에 위치한다.

0.    Unallocated Cluster

-      Encase가 제대로 파일 시스템을 인식하지 못한 상태

1.    MBR의 복원

-      Bootcode는 깨끗한 MBR의 Bootcode를 복사하여 붙여넣고,

-      Partition Table이 깨진 경우 각각의 파티션 정보를 수집하여 직접 Partition Table Layout에 맞춰 입력해주도록 한다.

-      Forensics 관점에서는 MBR을 완전히 복원할 필요 없이(부팅이 목적이 아니므로), Partition Table만 복원하는 것으로 충분하다.

2.    VBR 의 복원

-      VBR은 수작업으로 복원하기가 어렵다. 각 필드 하나하나를 채우기가 어렵기 때문이다.

-      일반적인 경우 백업본을 활용하는 것이 좋다.

-      NTFS인 경우 파일 시스템의 맨 마지막 섹터에 백업본이 있다.

(파티션 매직 같은 프로그램을 사용했을 경우 백업본을 정상적으로 놔두지 않은 경우가 많아 복원이 어렵기도 하다.)

-      FAT인 경우 FAT12나 FAT16은 백업본이 없고, FAT32의 경우 백업본이 존재하나 위치가 고정되어 있지 않다. (아이러니하게도 VBR에 백업본의 위치가 기록되어 있다.)

-      따라서, VBR이 손상되었을 경우, 문자열 Search를 하거나(하지만 결국 Reserved영역 안에 있으므로, 섹터 사이즈가 크지 않기 때문에 시간은 얼마 걸리지 않는다.), MS의 경우에 대체로 VBR로부터 6섹터만큼 떨어진 곳에 있으므로 이를 확인해본다.

-      Encase Forensic Training버전의 경우, 복구할 VBR 위치에서 'Add Partition' Option 중 'Backup Boot Record'를 체크하면 자동으로 VBR 백업본을 활용하여 Partition을 인식하는 기능을 가진다.

-      Encase LE(Law Enforcement) 버전의 경우에는 위의 Option이 존재하지 않으므로, 수작업으로 직접 백업본을 원래 VBR에 덮어써주어야 한다.

-      그러나 Encase는 이미지의 직접 Data 수정이 불가하므로, Encase Prosuite(인증서 필요) 중 PDE 기능을 활용하여 실제 디스크로 인식시키면 된다. 이 또한 없는 경우, 해당 이미지 파일을 Winhex에서 열어 백업본 위치의 Block을 복원할 위치에 복사하면 된다.

c.f) Encase Prosuite

- PDE(Physical Disk Emulator, 실제 디스크로 인식시켜서 활용가능),

- VFS(Virtual File System),

- EDS(Encase Decryption Suite) 기능 활성화.

c.f) PDE 활용

- Mount as Emulated Disk : Encase가 Server 역할을 하고, Client에서

수정여부 기록 가능 (Disable Caching uncheck)

3.    Encase가 인식한 파티션 외에 다른 파티션이 존재하는지 여부 확인 (Keyword Searching)

-      하드 전체를 선택 한 다음 Unused 공간의 Report를 확인하여, 공간이 너무 많이 남은 경우 다른 파티션이 있었는데 삭제 된 경우로 의심해 볼 수 있다. (또는 MBR 손상을 의심할 수 있다.)

-      이 때 Unused space에서 'OEM String'을 Keyword Searching을 통해 VBR을 찾아서 확인해 볼 수 있다.

-      Keyword Searching 방법

New Keyword           : 키워드 생성

GREP (check)            : 정규식 사용

Search expression       : (NTFS)|(MSWIN4.1)|(MSDOS5.0)

Name                  : VBR OEM String

Case Sensitive (check)    : 대소문자 구별하는 경우

Unused Disk Area (check) : 인식하지 못한 디스크 공간에서 VBR 검색

Selected entries only – Search each entry for keywords.

Selected keywords only (check) : 선택한 키워드만 검색

-      결과는 'Search Hits' 탭에 나오며. Backup Boot Record여부를 섹터 번호를 확인한다. Encase는 Sector 단위로 검색을 하지 않아 오탐이 많으므로 주의한다.

-      이후 VBR 시작 위치가 확인되면, 직접 해당 위치에 가서 Add partition 을 해주면 된다.

(이때 Unused sectors before VBR 에서 Primary Partition의 경우, 앞에 Boot Record가 없이 바로 붙어있으므로 '0', Extended Partition의 경우, VBR의 63섹터 앞에 Boot Record가 존재하므로 '63'을 입력한다.)

c.f) Keyword 는 Global Keyword와 Local Keyword로 나뉜다.

Global Keyword : Case 탭 옆의 Keyword. 모든 케이스에서 사용가능.

Local Keyword : Home 옆의 Keyword. 해당 케이스에서만 사용가능.

(1) 볼륨 분석 (Volume Analysis) – Volume Layout 파악

0.     우선 MBR을 찾은 다음 partition의 합이 맞는지 점검

(숨어있는 파티션 -저장되지 않은 파티션- 이 있는지 확인하는 절차이다.)

// MBR : 적색으로 표시된 Sector

// MBR의 510, 511번째 byte가 55 AA라는 것을 확인

// 위의 분석 결과, 파티션 크기의 합과 전체 크기가 불일치.
(안 쓰는 공간이 있거나 기존 사용 한 후 삭제한 파티션이 있는 경우,
혹은 파티션 테이블이 깨졌거나 예전에 포맷하고 남은 영역으로 의심할 수 있다.)

1.    Partition Table 해석 (Entry size : 16 bytes)

-      Partition Table Layout

 

-      Bookmark 기능 : 데이터를 분석하다가 나중에도 다시 보아야 할 데이터를 표시해두는 기능인데,  이 과정 중에 데이터를 해석하게 할 수 있다.

            // MBR의 Signature 앞 64byte가 바로 Partition Table이다.

여기에서 Bookmark는 마우스 오른쪽 버튼 클릭 -> Bookmark Data

// Encase의 기본 템플릿 중 Windows - Partition Entry를 선택하면 분석결과가 Bookmark된다.
(Data Filetype : Partition Entry)

2.    Partition 위치 확인

// Size값을 통해 Partition 위치 확인

3.    첫 번째 파티션 확인

-      NTFS 가 시작하는 곳은 MBR로부터 63 sector만큼 떨어져 있는 곳이다.

(File System은 MBR로부터 63 sector 떨어진 곳에 위치한다.)

// Ctrl + G (Go to Sector : 63)

4.    다음 파티션 확인

-       Ext DOS가 시작하는 곳은 NTFS 파티션의 Size 이후이다.

NTFS 파티션이 10,233,405 라고 사용한다고 하였으나 Sector 가 0번으로 시작하므로 새로운 파티션은 10,233,405부터 사용되는 것이다.

// Ctrl + G (Go to Sector : 10233405)

-      해당 파티션이 Primary Partition인 경우 이 섹터는 VBR이 위치해야하고, 해당 파티션이 Extended Partition인 경우 MBR이 아닌 보통의 Boot Record가 확인되어야 하는데 (Extended Partition의 경우, MBR의 Partition Table에 Entry로 등록되지 않으므로 별도의 Boot Record를 지니게 된다.) Signature 55 AA를 제외한 나머지 부분은 모두 빈 공간으로 나타나 있음을 볼 수 있다. 원래 BR에는 Bootable Partition이 아닌 경우, Boot Code는 제외하더라도 자기 파티션의 시작 위치와 다음 파티션의 BR 시작 위치를 기록하는 Partition Table이 존재하여야 하나, 모두 빈 공간으로서 0 으로 채워져 있음은 해당 BR이 깨졌음을 의미한다.

-      해당 섹터로부터 63 sector 떨어진 곳에 파일시스템의 Signature가 존재하는 것으로 보아, Extended Parition이며, 해당 섹터는 Boot Record이며 Partition Table이 깨져있었음을 확인할 수 있다.

 이 때, MBR의 Partition Table을 분석한 파일시스템과 해당 파일시스템의 VBR OEM String Signature가 불일치하는 경우, 의심스러우므로 다시 확인해보아야 한다.

1.     증거파일을 Encase의 tree pane에 끌어다 놓는다.

2.     New case로 등록한다.

3.     Password가 걸려있는 경우, 해당 Password 입력

 4.     화면 구성 : tree pane, table pane, filter pane, view pane (왼쪽 위부터 시계방향)

• Table pane(우상) - 선택한 파일들의 속성, 등등의 정보
• tree pane(좌상) - 파일들을 tree 모양으로 보여줌
• view pane(좌하) - 데이터를 자세히 보는 데 쓰임
• filter pane(우하) - 자동화 작업, Keyword Searching, 스크립트

케이스를 생성했다면, 실제로 증거물을 분석해 보아야 한다.

 Encase에서 증거물의 추가는 굉장히 쉽다. 그냥 툴 바에 있는 Add Device 를 선택하면 증거물의 추가가 가능하다. (케이스를 생성해야만 Add Device 가 가능하다.)

여기서 일단 Local Drives 를 선택한다. (팜 파일럿이나 네트웍 연결도 가능하다.) 밑을 보면 증거 이미지를 추가할 수 있는 디렉토리도 보인다. 

Locals

 - 실제로 하드웨어에 물려있는 장치들

Evidence Files

 - Locals 을 증거이미지로 만든것

그러면 이제 실제로 디스크를 추가할 수 있는 창이 뜨게 된다. 이중에서 알파벳으로 된것은 Logical Drive 들이고 0, 1, 2 숫자는 Physical Drive 를 말한다.

해당 디스크에 대한 정보가 나오게 된다. 마침을 누르면 실제로 파일 시스템을 분석하기 시작한다. 이게 모두 끝나면 이제 실제 파일 시스템의 내용을 볼 수 있다.

Encase의 가장 강력한 기능 중 하나는 다른 타입의 매체들(usb memory, hard drive, palm, network drive 등)을 함께 구성할 수 있다는 점이다.

이를 통해, 개개의 독립적인 검색이 아니라 각각을 하나의 단위로서 검색이 가능하다.

이러한 과정은 시간을 절약하게 해주며, 조사관이 증거의 조사에 집중할 수 있도록 해준다.

Encase 에서 Case 라는 것은 어떤 사건 하나를 관리하는 단위이다. 실제로 작업을 저장하면 ".Case" 파읷이 생기게 되는데 현재 상황, 검색된 결과들, 북릴크 결과들, 파일 캔 결과들이 저장되게 된다.

조사를 시작하고 매체를 획득하기 전에, Case생성 후 어떻게 접근할 것인지 고려해야 한다. 동시에 수 명의 조사관이 해당 정보를 보아야 할 필요가 있을 수 있다. 이러한 경우, 증거이미지(evidence files)은 중앙 파일 서버에 위치시키고, Case 사본 파읷들을 각 조사관들의 컴퓨터에 위치시켜야 한다(Case 파일은 한 번에 한 명 이상의 접근을 거부하기 때문이다).

Encase 에서의 모든 작업은 일단 Case 를 생성한 다음에 실행하게 된다.

위의 그림을 보면 먼저 Name 을 지정하는 것이 보이는데, 이것은 이 Case의 이름을 지정하는 것이다. 예를 들면, "김보안", 이런식으로 말이다. 그 다음은 분석관의 이름이다. "ccibomb", 이 두 개는 간단하다. 그리고 이제 나머지 세 개의 폴더에 대해서 궁금중을 가져야 한다. Default Export Folder, Temporary Folder, Index Folder 각각 무엇을 말하는 것일까?

 - Default Export Folder

Encase 에서 삭제된 파일을 복구하거나, 증거이미지 안에서 필요한 파일을 실제 파일로 추출하여 저장할 때, 이를 기본적으로 어디에 생성할 것인가를 지정하게 된다.

 - Temporary Folder

   Encase 에서 압축 파일을 보여준다거나, 어떤 내용을 임시로 보여주기 위해서 Temp 폴더로 사용하는 공간이다. 윈도우의 Temp 라고 생각하면 된다.

 - Index Folder

   Encase V6 부터는 문서 타입의 파일에 대해서 Index Search 를 지원한다. 예를 들어 Txt 나, 오피스 종류의 문서의 텍스트를 추출해서 이것에 대한 단어들에 인덱스를 만들고 나중에 키워드로 검색할 때, 이 인덱스에서 찾아주는 것이다.

위의 폴더 들이 구분되어 있는데, 사실 이 폴더들의 의미보다 더 중요한 것은, 바로 왜 이렇게 폴더들이 나뉘어져 있는가, 그리고 왜 공통적으로 지정할 수 도 있는데(기본 설정은 되어있다.) 왜 Case 생성시에 설정하게 되어있는가 라고 생각한다. 포렌식이라는 것은 원본의 훼손을 막아야 하므로, 혹시나 윈도우 임시폴더에 어떤 데이터를 저장하게 됨으로써 사용자 PC의 데이터 훼손이 되지 않도록 고려하는 것이다. 즉, 사용자가 지정한 부분에만 데이터를 쓰게 하는 것이다. 그래서 Encase 의 경우 Registry 도 전혀 쓰지 않는다.

또한 Encase Forensic 방법론에서는 조사관이 2nd Hard drive를 사용하거나, 적어도 디지털 증거로 사용하려는 부트 Hard drive와는 별도의 2nd Partition을 이용핛 것을 추천한다.

더불어, 개개의 폴더나 범죄와 관련되는 것으로 보이는 데이터만이 아니라 Hard drive 전체 또는 Partition 전체를 이미지 뜨기를 추천하는데, 이는 사건 조사시 Cross-contamination을 방지하고 조사 이후 필요한 Data가 부재를 방지하기 위함이다.