Digital Forensics/EnCase2010. 11. 29. 01:57
반응형

 

10.    Shortcut Analysis

 

10-1.    Link Files 분석 개요

-      바탕화면, 최근문서, 시작메뉴, Send to 폴더 등에는 shortcut 형태의 증거들이 있다. Shortcut 파일들은 타겟 파일(어플리케이션, 디렉토리, 데이터 파일, 프린터 등)에 대한 정보를 가지고 있다. 이를 분석하여 필요한 정보를 추출해낼 수 있다.

 

10-2.    Link File 생성 시기

-      사용자가 의도적으로 생성시

-      프로그램 설치시

-      (explorer)이나 OS가 파일 실행시

 

10-3.    Link File 골라내기 (Condition 기능 이용)

Conditions - Extention - Match – lnk

Conditions - FileType - equal to - LINK 로 등록하여 확인

 

 

 

 

10-4.    Link File 활용 (Link File MAC Time 정보)

Link파일 안에는 Link file 생성 당시의 타겟 파일의 MAC Time 정보(CAM 정보)가 기록되어 있다.

a.     Windows : Created, accessed, modify

b.    Linux : Modify, accessed, changed

 

 

 

Windows에서 개개의 날짜/시간 정보는 8bytes, Link File에서 MAC Time 정보는 Offset 28번에서부터 24bytes에 표현된다.

File Created Time (타겟 파일 생성 시각)Last Written (마지막 수정 시각)이 몇 초 차이나는 경우에는 해당 파일의 '다운로드' 가능성을 의심해볼 수 있으며, 이 두 시각이 동일할 경우 '복사' 가능성이 있다.

 

  

 

USB PC에 꽂아 어떤 파일을 설치 또는 사용하였는지 여부를 확인하여 인지사실에 대한 증거로 사용하려는 경우, Link File의 시간정보를 가지는 Volume Serial Number (타겟 파일의 위치를 나타내는 값 앞 10을 찾고 그 전 4바이트) USB 파일시스템 내부의 Volume Serial Number를 비교하여 찾을 수 있다. 해당 Target 파일이 들어있는 파일시스템의 Volume Serial NumberLink File에 부여되기 때문이다.

 

                        // Hex ‘10’을 찾은 후, 그 앞 4 bytesVolume Serial Number (Unicode)

 

 

// Encase Report 탭으로 확인한 Link File Volume Serial Number

 

이를 USB 파일시스템 내부의 Volume Serial Number와 동일한지 비교하여 추출한다.

 

 

 

 

 

11.    참고문헌

-      File System Forensic Analysis, Carrier  ,|Addison-Wesley, 2005.01.01

-      Encase Computer Forensics--the Official Ence (Paperback / 2nd Ed.)   (Encase Certified Examiner Study Guide), BuntingSteve  John Wiley & Sons Inc, 2007.09.12

-      Encase Forensic Academic Program Students Guide, Guidance

 

 

 

12.    도움주신 분들

-      이지스원 시큐리티 보안팀장 김 태 일

-      이지스원 시큐리티 연구원   이명수, 주한익

-      경찰수사연수원 사이버 교수 유   

-      국립 경찰 대학 사이버 교수 장 윤 식

-      육군 사관 학교 사이버 교관 유 정 호

 

 

 

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 11. 29. 00:25
반응형

 

9.   Hash Analysis

 

9-1.       Hash 함수

-      임의의 메시지를 입력 받아 고정된 사이즈의 결과값을 출력한다. 고정된 사이즈는 어떤 알고리즘을 사용하느냐에 따라 달라짐 MD5 128비트이다.

-      h=H(M)    :   Hash value 또는 Message Digest(메시지 요약)를 사용하는

이유는 대체로 메시지 사이즈보다 Hash 사이즈가 작고, 동일한 메시지에 대해 항상 같은 결과가 나오기 때문이다.

-      h가 주어졌을 때 메시지 M의 내용이나 M과 관련된 어떠한 정보도 계산해 내거나 추출할 수 없는 단방향성을 지니고 있다. , 역함수가 없다.

-      Collision-resistance(메시지는 다른데 결과값이 같은 경우)는 거의 없다.

eg.  MD5) 1 / 340,282,366,920,938,463,463,374,607,431,768,211,456

 

 

9-2.       Digital Forensic 에서 Hash 함수의 용도

-      증거의 무결성을 검증하기 위해 사용한다.

디지털 증거는 조금이라도 조작되었을 경우 크게 다른 결과를 가져올 수 있으므로 무결성을 검증하는 것이 매우 중요하다.

 

 

9-3.       Hash 분석의 방식

  Negative Hash analysis

      1. 의의
        • Known-good hash set을 이용하는 hash 분석 방법
      1. 조사방법
        • 증거이미지에 포함된 파일의 hash값을 모두 발생
        • Known-good hash set과 비교하여 매칭되는 파일을 조사 목록에서 제거

 

  Positive Hash analysis

      1. 의의
        • Known-bad hash set을 이용하는 hash 분석 방법
      1. 조사방법
        • 증거이미지에 포함된 파일의 hash값을 모두 발생
        • Known-bad hash set과 비교하여 매칭되는 파일을 모두 조사

 

9-4.       Hash set

의의  : 선택한 파일의 해쉬값을 모아놓은 DB

종류

      1. Known-good Hash set

·         정상적인 파일의 hash 값 집합

·         조사할 필요가 없는 파일의 hash값의 Data Base

·         OS의 버전이 다양하기 때문에 만들기 힘들다.

·         c.f) NSRL(National Software Reference Library) : 미국의 NIST 산하에서 프로젝트로 만든 known-good hash set으로서, 우리나라 환경에는 잘 맞지 않지만 매우 유용하게 사용될 수 있다. 우리나라도 환경에 맞는 known-good hash set이 필요하다. (참조 : http://www.nsrl.nist.gov/)

                                     ii.        Known-bad Hash set

·         해킹에 사용된 툴, 악성코드 등 조사할 필요가 있는 파일의 hash값의 Data Base

 

9-5.       Empty파일(size 0인 파일) 제거

-      컴퓨터 상에는 size 0인 파일이 많은데, 이는 특정 파일이 특정 프로그램의 존재여부와 관련된 경우와 같이 조사가 필요한 특별한 경우가 아니면 조사할 필요가 없다.

-      Encase는 기본적으로 비어있는 파일에 대한 Hash값을 가지고 있다.

-      Hash 분석을 하면 기본적으로 Hash set에서 Empty file으로 분류한다. Category known으로 분류되어 있다.

-      c.f) Size 0인 파일 만들기 : (Windows) Fsutil file createnew [파일명] [size]

(Linux) touch [파일명]

 

 9-6.       Hash set 생성 실습 (Hash set은 생성 후 Rebuild 필요)

① View - hash set 에서 hash sets 탭을 만든다.

 

 

② Cases entry에서 해시 값 만들 파일들을 선택한 후 Search 기능 이용하여 hash값 만들어낸다.

// Selected items only  : 선택된 파일만

Compute hash value  : hash값 생성

 

// 다음과 같이 선택된 파일에 한해서 Hash Value가 도출된 것을 볼 수 있다.

 

 

③ Hash set 탭에서 New 기능을 통해 Hash set 추가

   (도출된 Hash값을 Known으로 등록)

      1. New hash set에서 Category Notable, Known 두 가지만 사용하는 것이 좋다. 이는 Guidance 권고사항으로, Enscript가 이 두 가지 Hash set을 가정하고 작성된 것이 많기 때문에 이를 활용하기 위함이다.

                                     ii.        Known  : Known-good Hash set

Notable : Known-bad Hash set

 

 

             // Hash Set이 만들어졌다.

Encase가 설치된 폴더의 Hash Sets 폴더에 저장되며, 복사 가능하다.

 

 ④ Rebuild 필요

Hash set 생성 후 당장은 사용이 안 된다. 해당 Hash set을 체크한 후 Rebuild 하거나(우클릭- Rebuild Library) 다시 껐다 켜야 한다.

 

 

9-7.       Hash set을 이용한 조사 실습 (Conditions 활용)

필요한 Hash set 선택 후, Search- Compute hash value 체크 -> Search!

 

우측 하단의 필터 pane을 이용하여 조사 파일의 양을 줄일 수 있다.

예를 들어, Hash category known인 것은 제거할 수 있다.

 

Condition : 해당 조건에 맞는 데이터만 보는 것이 가능하다.

(Enscript로 이루어짐. C++ 문법과 유사함)

 

 ③ Known Files 는 제외하고 필터링한 결과

 

 

④ Query 버튼을 누르면 조건이 적용된다.

 

선택적 적용은 Display 탭에서 체크한다.

 

  

 

참고 : Hash 카테고리 Known 인 파일을 제외시키는 Condition 만들기

                                      i.        New Condition (Name : Remove Known Files)

 

                                     ii.        함수 추가 New

(Properties : Hash Category, Operator : equal to, Value : Known)

 

 

                                   iii.        Not 적용

 

                                    iv.        직접 입력하여 생성된 Condition

 

                                     v.        이를 Run 해보면, Known Files는 제외되는 것을 볼 수 있다.

 

           // 적용 전

 

                     // 적용 후  : Known Files 가 보이지 않음

 

 

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 11. 25. 11:53
반응형

 

8.   Signature Analysis

 

8-1.       개요

Signature Analysis는 확장자가 변경된 파일 식별이 주 목적이다.

대부분의 프로그램에서 확장자를 보고 파일 타입을 결정하는 것이 문제의 소지가 될 수 있으므로, 기록된 확장자와 파일의 실제 Signature 를 분석하여 일치하는 지를 확인하는 작업이다.

 

8-2.       Signature

어떠한 파일타입인지를 나타내는 코드

보통 파일의 앞 부분

JPG 의 경우 FF D8 , MP3 의경우 ID 3 로 시작함.

 

Encase View 메뉴에 가면 File Signatures 메뉴가 있다.

 

 

8-3.       Encase에서 Search (Verify file signatures 체크) 후 결과 표시

!Bad Signature

Signiature 손상

확장자 등록, Signatre 등록 X

Match

정상적인 파일

Signature와 확장자 일치

* [Alias]

확장자 변경

등록된 확장자, Signature 불일치 (명확한 조작)

Unknown

등록 X 파일

확장자, Signature 둘다 등록 X

 

 

8-4.       Signature Search 시 필터링

Signature contains [*]    :  *포함한 것

or Signature contains [!]  : 복합조건 (조건을 더 만든다.)

 

c.f) 복합조건 생성시 논리연산자가 자동으로 or 로 됨.

and 로 바꾸려면 ‘change logic’을 하면 된다. (우클릭 – logic)

 

 

8-5.       새로운 File Signature 등록 (Multimedia - new) : Rebuild 불필요함

 

 

                      예시 : Mp3 파일 등록

         // Option

Search expression - '\x49\x44\x33'

GREP - 16진수, 정규식 사용시

Case Sensitive - 대소문자 구별, Signature : ID3

 Extentions : mp3

 Name : mp3 Audio file

 

 

c.f) File Type DB가 별도로 있어 별도 등록 필요함. Viewer는 개별설정 가능함

 

 

 8-6.       File Signature 분석하는 방법

파일 표준이 있을 경우 분석자료를 참고한다.

파일 샘플을 여러 개 가져다 놓고 비교 분석한다.

파일 signature를 분석해놓은 사이트를 참조한다.

(eg. http://www.garykessler.net/library/file_sigs.html/)

 

 

8-7.       File Signature 확인 실습

 

Search Verify file signatures

 

② Searching



 

Finish

 

④ Result

 

 

 

8-8.       Signature 위치에 따른 파일 인식 여부

① Signature File의 시작이 아닌 중간에 위치한 경우 인식 여부 확인

  정상적인 JPG 파일 (VMware.jpg)

 

Signature를 중간으로 옮긴 경우 (VMware2.jpg)

 



 

File 내 여러 개의 Signature가 있는 경우 인식 여부 확인

정상적인 JPG 파일의 중간에 png 파일의 Signature 삽입 (VMware3.jpg)



 

Encase에서 인식 결과



-      Signature 를 중간으로 옮긴 (VMware2.jpg)의 경우 “! Bad signature

, Signature는 각 파일의 맨 앞에 위치하여야 함

-      Signature 가 중복된 (VMware3.jpg)의 경우 정상적인 JPG 파일로 인식함

, Signature는 각 파일의 맨 앞에 위치한 하나만 인식함

 

 

8-9.       MS Office File Signature

① 2003 ver. 이하 문서 (xls, doc, ppt)

-      Password 유무 상관 없이 동일한 Signature 지님 : 구분 불가능!

Signature : D0 CF 11 E0 A1 B1 1A E1

 

 



-      Encase에서는 세 개 파일 모두 동일한 File Signature에 등록되어 있음

Encase 에서는 xls, doc, ppt 모두 Compound Document File에 등록됨

따라서 이 세 개의 확장자 중에서 서로 바꾸는 경우에도 Match 로 인식됨

 



 

2007 ver. 문서 (xlsx, docx, pptx)

-      암호 유무에 따라 서로 다른 Signature 지님

암호가 없는 경우 공통 Signature : 50 4B 03 04

암호가 걸린 경우 공통 Signature : D0 CF 11 E0 A1 B1 1A E1 (2003과 동일)

 


-      Encase File Signature Table 에서 확인

암호가 없는 경우 공통 Signature : 50 4B 03 04 ZIP Compressed에 ‘zip, docx, pptx, xlsx’ 확장자와 함께 등록되어 있음. 따라서 상호간 확장자를 바꾸어도 Encase Match로 인식함

 



암호가 걸린 경우 D0 CF 11 E0 A1 B1 1A E1 2003의 경우와 동일하게 Compound Document File File Signature로는 등록되어 있으나, 확장자(xlsx, docx, pptx)는 등록되어 있지 않으므로 Encase * (Alias) 로 인식함

 



 

결론

Office 2003 문서(암호 유무 상관 X) Signature

= Office 2007 문서(암호 O) Signature

= ZIP 파일(암호 유무 상관 X) Signature

 

 

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 11. 25. 11:37
반응형

 

7.   Web History Analysis

 


Web History 라는 것은 피의자가 어떤 웹사이트에 언제 접속했는가를 찾기 위한 중요한 단서가 된다. (웹히스토리는 사용자가 브라우저를 통해 웹을 방문할 때, 그 방문 접속 기록을 가지고 있는 파일들이다.) 그리고 실제 수사에서도 가장 많이 사용되는 기록 중에 하나이다.

 

 

예를 들어 특정 사용자의 웹 히스토리 중 위와 같은 폴더를 확인했을 때, 이 데이터로부터 조사관은 사용자가 gmail hotmail 이메일 주소를 가지고 있고, tdbanknorth라는 온라인 뱅킹을 이용하며, 디지털 포렌식 웹사이트에 관심이 있고, 아마도 Champlain에 있는 대학을 다니고, 그 지역 아파트에 대해 알아보고 있다는 추측이 가능하다.[i]

또한 다운로드 받은 파일을 마지막으로 저장한 폴더를 보여주는 경우, 조사관은 사용자가 파일들을 어디에 저장하는지 알 수 있으며, 이 밖에도 로그로 활용하기 위한 정보가 담겨있기도 하며, 이에는 웹 브라우져의 자동 로그온 아이디와 비밀번호, 검색어 등이 날짜, 시각 정보와 함께 저장되어 있다. 자동 완성 비밀번호 웹 페이지가 인코딩되어 저장되기도 한다.

 

Encase 에서 웹 히스토리를 분석하는 것은 간단하다.

   툴바의 Search 를 선택한다.

 

 

이 때 오른쪽 아래에 Search for internet history 를 체크해주면, 현재 추가된 증거들에서 자동으로 웹 히스토리 파일들을 찾아서 분류해준다.

 

 

결과는 Entries 탭이 아닌 Record (View->Cases->Records)에서 볼 수 있다.

 

 

Encase에서는 다음과 같은 웹히스토리 파일이 분석 가능하다.

-       Internet Explorer - Windows, Mac

-      Mozilla( Netscape, Firefox ) - Windows, Mac

-       Opera - Windows, Mac and Linux

-       Safari - Mac

 

 

 

  참고사항 : Index.dat

 Internet Explorer의 경우 Index.dat 파일을 이용하여 브라우져의 사용에 관한 정보를 유지하는데, Index.dat 파일은 Cookies, History, Temporary Internet Files 폴더 등의 정보가 위치한다. 다양한 Index.dat 파일은 그 구조는 유사하지만, 서로 다른 타입의 데이터를 저장한다.

   Cookies – 웹사이트에 의해 컴퓨터 시스템에 저장된 데이터.

.TXT 파일들이 실제 쿠키들을 나타내며,

Index.dat 파일은 각 쿠키 기록을 따른다.

Temporary Internet Files Index.dat – Internet Explorer를 통해 접근한 웹페이지에

나타난 파일들을 포함한다. 캐쉬 파일들은 컴퓨터에 저장될 때, 이름이 변경되는데 Index.dat는 이러한 변경 정보를 기록한다.

  Main History Index.dat – 전반적인 현재 히스토리

  Daily History Index.dat – 날짜 범위를 포함하는 폴더 저장.

예를 들어, ‘MSHist012010050420100505’ 2010 5 4일 하루의 히스토리를 의미한다.

   Weekly History Index.dat – 날짜 범위를 포함하는 폴더 저장.

예를 들어, ‘MSHist012010050220100508’의 경우 2010 5 2~8일 주를 의미한다.

   위의 Main, Weekly, Daily History Index.dat Internet Explorer 외에도 Windows Explorer를 통해 접근한 Local 파일에 대한 히스토리도 기록한다.



[i] Derrick J. Farmer. “A FORENSIC ANALYSIS OF THE WINDOWS REGISTRY”, 2008

: http://www.eptuners.com/forensics/Index.htm

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 11. 25. 01:26
반응형

 

Case  각각의 Partition VBR이 모두 손상된 경우

 

-      복원 전 MBR : Partition Table Layout

Bootable Flag

Starting CHS

Partition Type

Ending CHS

Starting LBA

Size in sector

00

01 01 00

07

FE 3F 07

3F 00 00 00

C9 F5 01 00

00

00 01 08

05

FE 3F 0D

08 F6 01 00

86 78 01 00

 

-      하드 전체 Layout

MBR

Primary 1

Primary 2

 

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

Type

Name

Status

Start

Stop

Relative

size

07

NTFS

00

000101

073FFE

63

128457

05

FAT32

00

080100

0D3FFE

128520

96390

 

-      인식 오류 발생 원인

Encase로 불러왔을 때, 아무런 파티션도 인식하지 못한 상태이다.

해당 디스크의 MBR을 확인해 보았다. MBR에는 2개의 파티션 정보가 나타나 있다. 해당 정보에 따르면, 첫 번째 파티션 시작 위치는 63섹터, 두 번째 파티션 시작 위치는 128520 섹터이다. 그러나 해당 섹터(VBR)는 모두 손상되었다.

, MBR은 손상되지 않았지만, 각각 파티션들의 VBR이 손상되었다.

a.       MBR Partition table을 보고, Partition의 시작 위치 확인



b.       첫 번째 파티션의 시작 위치인 63 sector에서 VBR 손상 확인

 

c.       두 번째 파티션의 시작 위치인 128520 sector에서 VBR 손상 확인

 

 

-      복원 과정

VBR이 손상되었을 때에는, VBR 백업본을 이용하여 복원할 수 있는 가능성이 존재한다. NTFS의 경우 파티션의 가장 마지막 섹터에 백업 되며, FAT32의 경우 보통 VBR에서 6번째 섹터에 기록되어 있다. 각각 파티션의 백업 VBR의 존재를 확인 후 손상된 VBR의 위치에 덮어쓰는 방법으로 복원할 수 있다.

 

a.     첫 번째 파티션의 VBR (63 sector) 바로 다음 섹터 확인

// NTLDR 관련 정보가 있는 것으로 보아 NTFS인 것으로 추측.

NTFS의 경우 VBR의 백업본이 맨 마지막 sector에 저장되어 있음

  

b.    첫 번째 파티션의 맨 마지막 섹터 (128519 sector) 확인

// NTFS 파일시스템 파티션 VBR 이 백업되어 있음

 

c.     두 번째 파티션의 시작위치(128520 sector)로부터 6 sector 뒤 확인

// FAT32 파일시스템 파티션 VBR이 백업되어 있음

 

d.    WinHex dd 이미지를 읽음

(Encase Forensic Training버전에서는 Disk Emulate 기능 없으므로 직접 수정이 불가하므로 WinHex를 이용하여 VBR 백업본을 직접 손상된 VBR에 덮어써서 복원 후 마운트해야 함)



 

e.     Encase를 통해 이미 확인한 VBR 백업본을 원래의 VBR 위치에 덮어씌움

   // NTFS VBR 백업본

 

                  // FAT32 VBR 백업본 

 

 

-      복원 완료

a.       Encase로 확인

Winhex에서 저장 후 Encase에서 Raw Image로 불러들여 읽음

 // 정상적으로 C, D 드라이브가 인식된 것을 확인

  

b.       Linux Loop Device Mount하여 정상 인식되는지 확인

b-1.  dd 파일의 정보 확인 (Encase로 확인한 바와 동일함)

 



           c.f) MMLS filesystemrecovery.dd 를 이용하여도 Partition 정보 확인 가능

MMLS Sleuthkit Tool 중 하나로, 분석할 디스크 레이아웃과 전체 파티션 스키마 취득, 물리적 디스크만 분석 가능 (스냅샵으로 획득한 이미지 파일에서는 사용 못함)

img_stat도 스냅샷 작성한 파일과 원본 디스크 또는 파티션 정보 확인 가능

 

b-2. 첫 번째 파티션의 offset(시작위치sector byte로 환산)을 지정하여 Mount 시킴

 



c.f) 파일 시스템을 마운트하는 것이므로, offset을 지정하지 않는 경우 해당 이미지는 하나의 파일 내에 두 개의 파일시스템이 존재하게 되어 마운트 자체가 불가능함

“dd if=filesystemrecovery.dd of=recovery.dd bs=512 start=63 size=128457”와 같이 offset을 지정하지 않고, 첫 번째 파티션만 따로 dump하여 mount 가능

 

                            b-3. 마운트된 첫 번째 파티션 확인 (정상 인식)

 

 

b-4. 두 번째 파티션 Mount 후 확인 (정상 인식)

 

 

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 11. 25. 01:11
반응형

 

Case  MBR Partition Entry가 전혀 없는 경우

 

-      복원 전 MBR : Partition Table Layout

Bootable Flag

Starting CHS

Partition Type

Ending CHS

Starting LBA

Size in sector

.

 

-      하드 전체 Layout

MBR

Primary 1

Primary 2

 

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

Type

Name

Status

Start

Stop

Relative

size

07

NTFS

00

000101

073FFE

63

128457

05

FAT32

00

080100

0D3FFE

128520

96390

 

-      인식 오류 발생 원인

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) 최종 복구 후 모습

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 11. 25. 00:54
반응형

 

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

 

-      복원 전 MBR : Partition Table Layout

Bootable Flag

Starting CHS

Partition Type

Ending CHS

Starting LBA

Size in sector

00

01 01 00

07

FE 3F 07

3F 00 00 00

C9 F5 01 00

 

-      하드 전체 Layout

MBR

Primary 1

BR

Extended 1

 

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

Type

Name

Status

Start

Stop

Relative

size

07

NTFS

00

000101

073FFE

63

128457

05

FAT32

00

080100

0D3FFE

128520

96390

 

-      손상여부 확인

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 드라이브 생성



 

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 5. 12. 13:35
반응형

-      복원 과정

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 드라이브 생성

 

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 5. 12. 13:29
반응형

 

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

 

-      복원 전 MBR : Partition Table Layout

Bootable Flag

Starting CHS

Partition Type

Ending CHS

Starting LBA

Size in sector

00

01 01 00

07

FE 3F 07

3F 00 00 00

C9 F5 01 00

00

00 01 08

05

FE 3F 0D

08 F6 01 00

86 78 01 00

 

-      하드 전체 Layout 

MBR

Primary 1 (NTFS)

BR

Extended 1 (FAT32)

 

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

Type

Name

Status

Start

Stop

Relative

size

07

NTFS

00

000101

073FFE

63

128457

05

FAT32

00

080100

0D3FFE

128520

96390

 

-      손상여부 확인

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 위치 정보가 기록되어 있지 않아(손상) 인식이 되지 않음.

반응형
Posted by CCIBOMB
Digital Forensics/EnCase2010. 5. 10. 20:45
반응형


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라는 하위폴더에 위치한다.

반응형
Posted by CCIBOMB