정보보안 엔지니어링

이전 포스팅에서 데이터를 추출하는 실습을 했다.

이번에 할 실습은 변조된 vhd를 복구시키는 실습이다.

* 실습파일( LINK )

다운로드 한 실습파일을 압축풀면 FAT32_2_1 파일이 만들어진다.

해당 파일을 FTK Imager로 열어보면 다음과 같이 나타난다.

파티션이 하나 있지만 어떠한 데이터도 존재하지 않는 것을 알 수 있다.

해당 파일을 HxD 에디터를 이용해 열어보면 다음과 같다.

빨간 박스로 표시된 부분을 보면 FAT32로 파티션 되어있는 것을 알 수 있다.

하지만 FTK Imager로 열었을 때 해당 파티션에서 데이터를 확인할 수 없었다.

FAT32의 VBR을 찾아가 보면 다음과 같다.

표시된 부분이 변조되어 있다.

순서대로 Byte per Sector, SP, RS, Hidden, Total Partition Size, FAT Size이다.

Hidden, Total Partition Size 부분은 알 수가 있다.

VBR의 위치가 128이기 때문에 Hidden은 80 00 00 00이다.

그리고 Total Partition Size 정보는 MBR에 나와 있다.

SP의 경우 기본적으로 512 바이트를 사용하며, 2048 바이트를 사용하기도 한다.

이를 토대로 수정한 VBR은 다음과 같다.

현재 확인할 수 없는 것들은 SP, RS, 그리고 FAT Size이다.

SP의 값을 찾기 위해 FSINFO 부분을 가면 다음과 같다.

표시된 부분은 남은 클러스터의 수와 다음에 할당할 클러스터에 대한 정보이다.

남은 클러스터의 수를 보면 D8 C0 07 00으로 이 값을 계산하면 508,120이다.

그리고 파티션의 총 크기는 앞서 본 것처럼 00 81 1F 00이며 이 값은 2,064,640이다.

즉, 508,120 을 4배하면 대략 총 크기와 비슷하다는 것을 확인할 수 있다.

이 말은 SP가 4임을 알 수 있다.( Sector 단위는 64바이트이기 때문이다. )

다음에 확인할 것은 Root Directory인데,  RS를 모르기 때문에 Root Directory를 찾아갈 수가 없다.

우선 FAT 테이블을 확인하기 위해 FAT의 시그니처 8F FF FF 0F 를 찾아가 보자.

12459 섹터에 FAT 테이블이 존재한다. VBR에서 FAT이 2개있음을 확인했다. 해당 섹터 이후에 FAT 테이블이 존재하는 지 확인해보자.

해당 시그니처는 더 이상 없는 것을 확인할 수 있다. 따라서 12459 섹터에 있는 FAT 테이블은 2 번째 테이블임을 추측할 수 있다. 즉, 위 어딘가에 FAT 1이 있음을 알 수 있다.

문제에서 USB의 vhd라는 힌트를 줬기 때문에 USB 문자열을 찾아보자.

그러면 위와 같이 16512 섹터가 탐색이 되며, 구조를 보면 Directory Entry의 구조를 갖고 있다.

이를 통해 FAT Size를 구할 수 있는데 계산은 다음과 같이 한다.

16,512( Directory Entry ) - 12,459( FAT 2 ) = 4,053

이제 FAT 1의 위치를 다음과 같이 구할 수 있다.

12,459 - 4,053 = 8406

해당 위치로 가보면 다음과 같은 화면을 볼 수 있다.

FAT 1의 데이터가 모두 변조되어 있음을 알 수 있다.

FAT 2의 데이터를 복사해 FAT 1에 붙여 넣자.

위와 같이 수정을 하고 VBR을 수정한다.

RS와 FAT Size를 수정해야 하는데, FAT Size는 4,053임을 알았다.

RS는 다음과 같이 구할 수 있다.

8,406( FAT 1 ) - 128 = 8,278

4,053과 8,278 을 16진수로 바꾸면 각각 0xFD5, 0x2056이다.

이 값들을 리틀엔디언으로 수정하면 다음과 같다.

이제 파일을 저장한 뒤 FTK Imager로 열어보면 다음과 같은 화면을 확인할 수 있다.

지금까지 살펴본 내용을 바탕으로 데이터 복구 실습을 한다.

지금 할 실습은 FAT32 파일 안에 존재하는 데이터를 긁어 파일을 추출하는 실습이다.

* 실습에 사용할 프로그램은 HxD 에디터와 FTK Imager이다.

FAT32.zip

우선 위 압축 파일을 받아 압축을 해제한다.

그러면 FAT32라는 파일이 나타난다. 이 파일을 복구하도록 한다.

1. MBR 확인

HxD 에디터로 FAT32 파일을 열어 MBR을 보면 위와 같다.

빨간색으로 표시된 부분은 각각 파티션 타입, VBR 위치, 파티션 크기를 나타낸다.

파티션 타입이 00 으로 되어 있는 것을 봐선 변조되어 있음을 알 수 있다. MBR에서 파티션의 타입을 확인할 수 없으니 일단 해당 파티션의 VBR로 가보자,

2. VBR 확인

VBR의 위치는 위 그림에서 빨간색 박스가 있는 부분을 보면 된다.

80 00 00 00 이라고 되어 있으며 이는 Little Endian 방식이다. 계산을 하면 128이 나온다.

VBR에서 확인해야 하는 부분은 위 그림에서 빨간 박스 부분들이다.

순서대로 파티션 시그니처, SP, RS, Hidden, FAT Size 이다. 모두 Little Endian으로 표기되어 있다.

> 파티션 시그니처 ⇒ MSDOS5.0 = FAT32

> SP = 0x04 = 4

> RS = 0xF619 = 6,646

> Hidden = 0x80 = 128

> FAT Size = 0x503 = 773

3. FAT 확인

FAT의 위치는 RS + Hidden 으로 6,646 + 128 = 6,774 이다.

FAT은 파일에 대한 데이터가 어디에 위치하는 지 알려주는데, 하나의 파일에 대한 정보를 4바이트로 담고 있다. 

처음 2개( 8 바이트 )는 사용하지 않으며 일종의 FAT이라는 시그니처를 담고 있다.

4. Root Directory 확인

Root Directory에 대한 정보가 있는 위치는 다음과 같이 계산할 수 있다.

6,774( FAT 1 시작위치 ) + 773×2( FAT 1, FAT 2의 크기 )  = 8,320

계산한 위치로 이동해보면 다음과 같다.

Root Directory를 보면 어떤한 데이터도 존재하지 않는다.

즉, Root Directory가 변조되어 있어 어떤 파일들이 존재하는지 알 수 없다.

이는 Root Directory를 이용해 어떤 파일이 존재하는지 알 수 없음을 의미한다.

파일을 복구하기 위해 FAT을 분석하자.

5. FAT 테이블 분석

FAT 테이블 정보를 보면 다음과 같다.

블럭영역이 첫번째 파일에 대한 정보이다.

FAT 테이블에는 파일에 대한 정보가 4바이트씩 저장된다고했다. 이를 이용해 분석을 하자.

우선 파일의 데이터가 11번째 ~ 35번째 까지 있음을 알 수 있다.

파일의 시작위치와 끝 위치를 계산하는 법은 다음과 같다.

- 시작위치

11 - 2( 시그니처 ) = 9

9 × 4( SP ) = 36

36 + 8320( Root Directory ) = 8356

- 끝 위치

35 - 2( 시그니처 ) = 33

33 × 4( SP ) = 132

132 + 8320( Root Directory ) = 8452

파일의 시작위치로 가보면 다음과 같다.

해당 파일이 PNG 파일임을 알 수 있다.

파일의 끝은 8452 섹터인데, 이 값은 해당 클러스터의 시작 위치이기 때문에 클러스터 크기만큼 더해줘야 한다. 클러스터 크기가 4이기 때문에 8452부터 4섹터인 8455 섹터까지 블럭지정을 한다.

위와 같이 [Edit] - [Select block] 을 이용하면 오프셋을 이용해 블럭 지정할 수 있다.

블럭지정한 데이터 부분을 복사해서 [새파일]을 눌러 붙여넣기 한다.

그리고 다음과 같이 'File1.png' 로 저장한다.

그리고 해당 파일이 제대로 열리는지 확인해보자.

위와 같은 이미지 파일이 열리는 것을 확인할 수 있다.

이제 두 번째 파일을 보도록하자.

두 번째 파일은 39번째 ~ 41번째에 있다.

첫번째 파일을 찾은 것과 같은 방식으로 계산을 하면 다음과 같다.

두 번째 파일의 시작 위치는 8468, 파일의 끝 위치는 8476 이다.

두 번재 파일은 jpg 파일임을 알 수 있다.

해당 데이터를 모두 복사해서 'File2.jpg' 파일로 저장하자.

해당 파일을 열어보면 다음과 같다.

다음 파일을 찾아보면 다음과 같다.

42번째 ~ 126번째

파일의 시작 위치와 끝 위치는 각각 8480, 8816이다.

해당 파일의 시작위치를 보면 다음과 같다.

이 파일도 PNG 파일임을 알 수 있다.

해당 데이터를 추출해 'File3.png'로 저장하면 다음과 같다.

이와 같은 방식으로 데이터를 추출해 낼 수 있다.

1. 타임라인 분석이란 ?

타임라인 분석은 파일시스템의 메타데이터( 할당/비할당 포함 )에 있는 파일 시간을 기준으로 각 파일 시간별 정렬을 통해 가장 최근시간, 가장 오래된 시간, 사용빈도 등의 분석을 통해 시계열 분석을 하는 것이다.

타임라인 분석 대상은 상당히 다양하게 존재한다. NTFS, FAT 파일시스템의 파일 스템프값, 레지스트리 상의 운영체제 설치 시간, USB 연결시간, 레지스트리의 마지막 쓰기 값, 이벤트 로그 생성/기록 값, 프리패치의 마지막 실행 값 등 타임라인 분석에 포함시켜야 할 대상은 이보다 더 많이 존재한다. 분석가는 타임라인 분석에 포함시켜야 할 대상을 선별하고 각 타임라인 분석대상에 대한 특성을 파악하고 있어야 원활한 분석을 수행할 수 있다.

타임라인 분석 대상 중 가장 비중이 큰 파일시스템에 존재하는 시간값도 파일시스템 종류에 따른 특성 등을 이해하고 있어야만 제대로 된 타임라인 분석을 수행할 수 있다.

2. 파일 타임 시스템이란 ?

파일타임은 1601년 1월 1일 12:00 AM, UTC를 시작으로 100 나노세컨드 단위로 64비트 값으로 저장된다. 시스템은 프로그램이 파일을 생성, 접근, 수정했을 경우 파일타임을 기록한다.

NTFS 파일시스템은 UTC 포맷으로 시간값을 저장하며, 타임존이 변경되더라도 영향을 받지 않는다. 이는 타임존에 따라 저장되는 시간값이 달라지지 않는다는 것을 의미한다.

(ex)

타임존이 Asis/Seoul(+9) 일때 NTFS 파일시스템에 저장되어 있는 파일의 시간값이 2016/1/1 10:00 AM이면, 저장될 때에는 UTC 기준으로 2016/1/1 01:00 AM 으로 저장된다.

타임스탬프는 다양한 이유에 의해 업데이트 되며, 변경이 종료된 후 파일시간이 변경된다.

모든 파일시스템이 생성시간, 마지막 접근 시간을 기록하지 않으며, 방식 또한 다르다.

(ex)

FAT 파일시스템에서의 파일 생성시간은 10 밀리세컨드 단위로 되는 반면, 수정시간은 2초 단위로, 접근시간은 1일 단위로 기록된다.

(ex)

NTFS 파일시스템은 마지막 접근시간에 대한 기록을 마지막 접근 시간의 한시간이 지난 후에 기록한다.

3. 일반적인 타임스탬프별 특성

- 수정시간

수정시간이란, 파일이 마지막으로 쓰여진 시간( 내용이 마지막으로 업데이트 된 시간 )으로 파일명이 변경되는 것은 파일의 시간값에 영향을 주지 않으며, 파일을 단지 열기만 하는 것은 영향을 주지 않는다.

- 접근시간

접근시간이란, 볼륨에서 파일이 열리거나 수정된 시간이다. FAT 파일시스템에서는 접근시간은 날짜로만 기록된다.

- 생성시간

파일 또는 폴더가 해당 볼륨에 최초 생성된 시간이다. 

4. 타임라인 분석 대상 및 정보

5. 타임라인 분석 문제

[01-2]_타임라인 포렌식 분석 기초 테스트.docx

위 파일을 받아 문제를 풀어 보자.

문제는 전체적으로 복사와 이동에 대한 차이를 알고 있는지를 묻고 있다.

복사와 이동에 대해서는 다음 표에서 설명한다.

위 표에 대한 정보를 가지고 문제를 풀면 쉽게 풀 수 있다.

6. 타임라인 분석 문제 - 해설

[01-2]_타임라인 포렌식 분석 기초 테스트 - 해설.docx

1. LFN 분석

LFN( Long File Name )은 SFN과 달리 파일의 이름을 255자까지 사용할 수 있다.

LFN 파일을 만들기 전에 우선 LFN의 구조부터 알아보자.

Seq Num : Sequence Number로 순서가 있으며, 이 순서대로 파일의 이름을 적용한다. 시작 번호는 0x01이고 마지막 번호에는 0x40이 OR된 값이 오며, 이 값을 보고 마지막 LFN임을 판단한다.

Name 1 : 1~5 번째 문자열을 기록한다. 유니코드로 기록하며 한 문자에 2바이트를 차지한다.

Attribute : 이 값은 항상 0x0F로 고정되어 있다.

Type : 항상 0x00으로 채워져 있다.

CheckSum : 해당 LFN과 대응되는 SFN의 체크섬이 저장된다.

Name 2 : 6 ~ 11 번째 문자열을 기록한다.

First Cluster Low : 반드시 0이 들어간다.

Name 3 : 12 ~ 13번째 문자열을 기록한다.

실제로 파일명이 긴 파일을 하나 생성해 보면 Directory Entry는 다음과 같다.

* 파일은 'HelloMyFriendImp3rio.txt'로 한다.

제일 아래를 보면 SFN이 있고 그 위로 LFN이 오는 것을 볼 수 있다.

그리고 LFN은 위로 가면서 Seq Num이 증가하며 마지막 LFN은 0x42임을 알 수 있다.

우선 이를 분석해 보도록 하자.

SFN을 보면 파일 명이 'HELLOM~1' 임을 알 수 있다. 파일명의 길이가 8자 이상일 경우 파일명의 앞 6자리 + '~1'이 붙는다.

LFN을 보면 처음에 Seq Num이 오고, 2바이트씩 파일명이 온다. 속성 값은 0x0F, Type 값은 0x00 체크섬은 0x8B로 되어 있다.

LFN에서 이 세 값과 First Cluster 값이 다르거나 이상하면 인식되지 않는다.

LFN에서 CheckSum은 SFN을 이용하며 그 방법은 아래와 같다.

① 'HELLOM~1TXT'의 각 문자를 2진수로 표현한다.

② 'H' 문자의 2진수 값을 오른쪽으로 Shift한다.

③ 다음 문자인 'E'의 2진수 값과 더한다.

④ 결과 값을 오른쪽으로 Shift한다.

⑤ ③과 ④를 마지막 문자까지 반복한다.

⑥ 결과 값을 16진수로 표현한다.

* LFN CheckSum을 구하는 프로그램

LFN_CheckSum.py

> 해당 파일은 python 2.7 버전으로 만든 것이다. 실행하면 다음과 같이 결과를 확인할 수 있다.

2. LFN 실습

분석을 한 결과를 응용해서 HxD 에디터로 LFN 파일을 생성해보자.

파일은 'goodbymyfriendImp3rio.txt' 로 한다.

파일을 만들기 위해 수정해야 하는 부분을 살펴보면 다음과 같다.

- FSINFO에서 남은 클러스터 수와 다음에 사용할 클러스터를 수정한다. ( Option )

- FAT #1 수정한다.

- Root Directory Entry에서 SFN과 LFN을 추가한다.

- 실제 데이터가 들어있어야 하는 섹터로 이동해 데이터를 넣는다.

* FSINFO를 수정하는 것은 선택사항이기 때문에 본 실습에서는 하지 않는다.

위의 과정을 수행하면 파일이 생성이 되고 파일을 읽을 수 있다.

하지만 어느 하나 잘못 입력하거나 값이 다르면 LFN으로 인식되지 않는다.

그럼 실습을 해보자.

> FAT #1 을 수정한다.

* FAT #1의 위치는 다음과 같이 찾을 수 있다.

RS( Reserved Sector ) F6 19( Little Endian ) ==> 6,646

Hidden 80 00 00 00( Little Endian ) ==> 128

RS + Hidden = 6,774

> Root Directory를 수정한다.

* LFN에서 CheckSum을 구하기 위해 위 파이썬 파일을 이용한다.

구한 CheckSum 값을 이용해 다음과 같이 수정한다.

* 파일명을 다 입력한 뒤 남은 Name 부분은 'FF'로 채워준다.

데이터를 넣기 위해서 만든 파일의 시작 위치를 구한다.

0E 00 ==> 14

(14-2) * 4( SP ) = 48

8320 + 48 = 8368

8368섹터를 위와 같이 수정한다.

그리고 vhd를 마운트 시켜서 탐색기로 보게 되면 다음과 같이 파일이 존재하는 것을 확인할 수 있고

파일 또한 제대로 열리는 것을 확인할 수 있다.

HxD 에디터를 이용해 디스크에 임의의 파일을 생성해보자.

우선 디스크관리자를 실행하고 다음과 같이 FAT32라는 이름의 vhd를 하나 생성한다.

디스크의 크기는 200MB, 디스크 포맷은 VHD, 디스크 유형은 고정크기로 한다.

디스크가 만들어지면 위와 같이 파티션 형식을 MBR로 디스크를 초기화한다.

해당 디스크에 볼륨을 위와 같이 설정하여 생성한다.

우선 HxD 에디터로 파일을 생성하기 위해서는 FAT32 파일시스템 구조에 대해 알아야 한다.

FAT32 파일시스템 구조는 이전 블로그를 참고하길 바란다.

다음 파일을 한번 생성해보자.

- 파일명 : hack.txt

- 파일위치 : 루트 디렉터리

- 파일내용 : this file is created by hacktool

- 파일크기 : 20bytes

- 파일생성 시간 : 2000.12.31 23:59:59

- 파일수정 시간 : 1999.9.30 15:30:12

- 파일접근 날짜 : 1998.11.10

이를 위해 수정해야 하는 것은 다음과 같다.

> FSINFO에서 다음 사용할 클러스터 확인 및 수정

> Directory Entry 수정

> FAT 수정

우선 HxD 에디터를 관리자권한으로 열고 다음과 같이 [기타설정]-[디스크 열기]를 클릭해 생성한 하드디스크2를 선택한다. 이때 [읽기전용으로 열기]에 체크를 해제한다.

* [기타설정]-[디스크 열기]를 이용해 vhd를 열었을 경우 해당 vhd가 연결되어 있는 상태이기 때문에 vhd를 수정할 수가 없다. 따라서 vhd를 인식하지 못하도록 MBR 파티션 테이블에서 파티션 타입을 '00'으로 설정한 뒤 디스크 관리자를 새로고침하면 해당 vhd가 연결해제된다. 이 상태로 작업을 한 뒤 vhd를 인식하기 위해 수정한 MBR 파티션 테이블을 복구하고 디스크 관리자를 새로고침해야 한다.

* [기타설정]-[디스크 이미지 열기]를 이용할 경우 해당 vhd를 분리한 뒤 작업을 하면 된다.

필자는 [기타설정]-[디스크 열기]를 이용했기 때문에 다음과 같이 MBR 파티션 테이블 값을 변경한다.

디스크 관리자를 새로고침하면 다음과 같이 FAT32 vhd가 인식되지 않는다.

위의 MBR 캡처화면의 ①을 통해 VBR의 위치가 '80 00 00 00'으로 128임을 알 수 있다.

해당 위치로 가면 다음과 같은 화면을 볼 수 있다.

이를 분석하면 다음과 같다.

① : SP( 클러스터 당 섹터 수 ) : 4

② : RS( 예약 섹터 ) : 6,646

③ : Hidden Sector : 128

④ : FAT Size : 773

이를 통해 다음을 계산할 수 있다.

- FAT 1의 시작 위치 : 128( Hidden Sector ) + 6,646( RS ) : 6,774

- FAT 2의 시작 위치 : 6,774 + 773( FAT 1 Size ) = 7,547

- 루트 디렉터리 시작 위치 : 7,547 + 773( FAT 2 Size ) = 8,320

파일의 시작 위치를 알기 위해 FSINFO 부분을 보면 다음과 같다.

* FSINFO는 VBR+1 위치에 있다.

① : 남은 클러스터 수

② : 다음 사용할 클러스터 번호

이를 통해 다음 사용할 클러스터는 6임을 알 수 있다.

파일의 시작위치는 다음과 같이 계산할 수 있다.

- ( 6  - 2( 예약 클러스터의 수 ) ) * 4( 클러스터 당 섹터 수 ) + 8,320( 루트 디렉터리 시작 위치 ) = 8,336

지금까지 확인한 내용을 보면 다음과 같다.

- FAT 1 위치 : 6,774

- 루트디렉터리 위치 : 8,320

- 파일의 시작 위치 : 8,336

이를 이용해 파일을 한번 만들어 보자.

먼저 실제 데이터가 들어가는 8,336 섹터에 다음과 같이 데이터를 넣는다.

루트 디렉터리에 파일에 대한 정보를 기입한다.

* 파일에 대한 정보를 계산하는 법은 이전 포스트를 참고하길 바란다.

FAT 1 정보를 다음과 같이 수정한다.

* FAT 1 정보에 대한 내용은 이전 포스트를 참고하길 바란다.

FSINFO에 대한 정보를 다음과 같이 수정한다.

* 클러스터 하나를 사용했기 때문에 FSINFO에 반영해 주어야한다.

정보를 모두 변경했다면 MBR에서 수정한 파티션 타입을 FAT32로 다시 변경해 준다.

저장을 한 뒤에 디스크 관리에서 새로고침을 누르면 다음과 같이 FAT32 볼륨이 연결이 된다.

파일 탐색기를 이용해 FAT32 볼륨에 들어가 보면 다음과 같이 HACK.TXT 파일이 생성된 것을 볼 수 있다.

FTK Imager를 이용해 해당 디스크를 보면 다음과 같이 정보와 저장된 데이터를 볼 수 있다.

* 파일 탐색기에서 HACK.TXT 파일의 속성을 보게 되면 접근 날짜가 현재로 변경이 된다. 그렇기 때문에 FTK Imager를 이용해 속성들을 보아야 정확하게 확인할 수 있다.

* 데이터를 보면 실제 입력했던 데이터가 모두 출력되지 않는다. 그 이유는 파일의 크기를 20 bytes로 했기 때문에 20 bytes까지만 확인할 수 있다.

1. FAT( File Allocation Table )

FAT은 디지털 카메라 등에 장착되는 대부분의 메모리 카드와 수많은 컴퓨터 시스템에 널리 쓰이는 컴퓨터 파일 시스템 구조이다. FAT 파일 시스템은 상대적으로 간단하기 때문에 플로피 디스크, 플래시 메모리 카드, 디지털 카메라 및 다른 수많은 휴대용 기기에서 흔하게 볼 수 있다. FAT의 성능은 다른 대부분의 파일 시스템에 견주어 좋지 않은 평을 받는다. 그 까닭은 운영 시간을 낭비하게 만드는 너무나도 단순한 자료 구조를 이용하고 조그마한 파일이 많이 있으면 디스크 공간을 잘 활용하지 못하기 때문이다.

2. FAT32

2기가바이트 이상의 하드디스크를 지원하며, 윈도우 95 OSR2부터 이 파일 시스템을 사용할 수 있다.

FAT32에서는 하나의 파일은 최대 4기가바이트 - 1바이트의 용량을 가질 수 있다. 하나의 파티션이 최대 8테라바이트의 용량을 가질 수 있고, 최대 268,435,437개의 파일을 담을 수 있다. 윈도우 98, 윈도우 Me와 같은 구형 운영체제나, 리눅스, OS X와 같은 운영 체제에서 윈도우와 호환성이 필요할 때, 또는 디지털카메라, 게임기 등에서도 이용된다.

3. FAT32 파티션 구조

FAT32의 파티션 구조는 아래 그림과 같으며 여기서는 Boot Sector의 구조에 대해 알아보고 실제 데이터가 있는 위치까지 추적하는 방법에 대해 알아보자.

Boot Sector는 MBR 구조와 같이 특정 오프셋 별로 가리키는 의미가 다르다.

① Boot Code : 0 ~ 2 byte

② BIOS Parameter Block : 3 ~ 8 byte

③ Boot Code와 Error Message : 90 ~ 509 byte

④ 시그니처 2byte : 510 ~ 511 byte

이제 FAT32의 BR 영역에 대해 알아보자.( 사용하지 않는 영역에 대해서는 따로 언급하지 않겠다. )

FAT 32의 BR 구조는 위와 같이 나타낼 수 있다. 각 영역의 의미는 다음 표와 같다.

Reserved 영역은 예약된 파일시스템에 대한 정보를 구조체로 저장하고 있으며, BR에 대한 백업 본을 저장하고 있다. FAT 영역의 경우 클러스터의 상태 값을 가지고 있는 영역으로써, 각각의 클러스터 정보는 4byte로 나타나게 된다.

- FAT 영역

① 4byte는 미디어 타입을 나타내며, F8 FF FF 0F는 하드디스크를 나타낸다.

② 4byte는 파티션의 상태를 나타낸다. 파티션의 상태는 보통 FF FF FF FF로 나타나게 된다.

③ 4byte는 루트 디렉터리의 클러스터 정보를 나타낸다.

④ 실제 데이터의 연속된 클러스터 공간할당 영역을 나타낸다.

4. 루트 디렉터리 추적

FAT32.vhd.zip

위 실습 파일을 다운로드 하여 압축을 푼다. 그리고 HxD의 '기타설정 > 디스크 이미지 열기' 메뉴로 열고 첫 번째 파티션의 시작 위치로 이동하면 다음과 같은 화면을 볼 수 있다.

실제 데이터 정보를 담고 있는 루트 디렉터리의 위치를 알아내기 위한 정보만 짚고 넘어가자.

FAT32의 BR 영역에서 필요한 정보만 분석해보면 아래 표와 같다.

루트 디렉터리로 가기 위해서는 FAT Area의 위치를 알아야 한다. FAT Area의 주소는 다음과 같이 구할 수 있다.

128 ( BR 주소 ) + 6,646( Reserved Sector( 0x19F6 ) ) = 6,774 섹터

6,774번 섹터로 이동하게 되면 FAT의 구조를 볼 수 있다. 아래 그림에서 00으로 채워진 공간은 사용하지 않는 FAT Area 영역이다.

루트 디렉터리로 가기 위해서는 FAT 주소에 FAT 크기의 2를 곱한 값을 더해주면 된다. 2를 곱해주는 이유는 FAT의 개수가 기본적으로 2개이기 때문이다.

6,774 + ( 773( 0x0305 ) * 2 ) = 8,320 섹터

8,320 섹터로 이동하게 되면 우리가 원하던 데이터에 대한 정보를 저장하고 있는 루트 디렉터리를 볼 수 있다. 이제 루트 디렉터리의 구조에 대해 알아보자.

- Name : 파일에 대한 이름을 나타낸다. 첫 번째 byte가 0xE5로 시작되면 삭제된 파일을 나타낸다. 삭제된 파일을 나타내는 0xE5를 다른 문자열로 바꾸면 해당 파일은 복구할 수 있다. 0x00이면 사용하지 않는 영역이다.

- Extension : 파일 확장자

- Attr : 파일에 대한 속성이다.

- Reserved : 예약된 영역

- Create Time Tenth : 생성 시간을 1/100초 단위까지 측정. 0~199의 값을 사용

- Create time : 파일이 생성된 시간을 나타낸다. 시간 변환은 A6 93이라는 정보가 저장되어 있다고 하면, 93 A6( 리틀엔디안 방식 )을 2진수로 변환하여 각각의 2진수를 우측에서 좌측으로 5자리, 6자리, 5자리씩 끊어주면 된다. 초단위의 경우 5비트를 사용한다. 즉, 0 ~ 31까지 표현할 수 있기 때문에 60초를 표현하기 위해 2를 곱해주어야 한다. 

- Create Date : 파일이 생성된 날짜를 나타낸다. 날짜 변환은 82 48이라는 정보가 저장되어 있다고 하면, 48 82( 리틀엔디안 방식 )를 2진수로 변환하여 각각의 2진수를 우측에서 좌측으로 7자리, 4자리, 5자리로 끊어주면 된다. 년단위의 경우 기준이 1980년이기 때문에 계산한 값에 1980을 더해주면 된다.

- Last Accessed Date : 파일에 마지막 접근된 날짜

- Starting Cluster Hi : 파일에 대한 클러스터 상위 값

- Last Written Time : 파일에 대한 마지막 수정시간

- Last Written Date : 파일에 대한 마지막 수정 날짜

- Starting Cluster Low : 파일에 대한 클러스터 하위 값

- File Size : 파일에 대한 크기

8,320 섹터에 있는 실제 데이터를 루트 디렉터리 클러스터 오프셋 별로 분석해보면 NCS.txt 파일과 DISK.jpg 파일이 존재한다는 것을 알 수 있다. NCS.txt 파일을 살펴보면 파일의 크기는 0x0D로 13 바이트이고, 파일의 생성 시간은 0x7490으로 14시 36분 16초다. 그리고 생성 날짜는 각각 0x4A9C로 2017년 4월 28일 임을 알 수 있다.

마지막으로 실제 데이터가 있는 위치를 찾아가기 위해서는 다음과 같이 계산하면 된다.

Cluster Hi + Cluster Low = 00 00 + 00 08 = 8

( 8 - 2 ) * 4 ( SP ) = 24

8,320 + 24 = 8,344

Hello world!! 라고 데이터가 저장되어 있음을 확인할 수 있다.

1. 윈도우 포렌식 분석 개요

윈도우 컴퓨터의 하드디스크에는 악성코드, 레지스트리, 로그 파일 같은 악성 코드의 흔적뿐만 아니라, Prefetch와 같은 실행 또는 조작여부를 알 수 있는 다양한 정보가 존재한다.

2. 윈도우 시스템에서 악성코드 식별 및 추출

- 알려진 악성코드 검색

* HashMyFiles( Link )

> 보통 공격자들은 공개된 RootKit이나 Sniffer와 같은 공개된 프로그램을 사용한다.

> 안티 바이러스 프로그램 또는 Hash 식별을 이용하여 알려진 악성코드를 식별한다.

- 설치된 프로그램 조사

> 감염된 컴퓨터에 설치된 프로그램에 대해 설치 날짜와 이름을 조사함으로써, 의심스러운 프로그램뿐만 아니라 원격 접속, 데이터 유출 등에 악용된 관련 프로그램 탐지

> 'Program Files' 폴더 하부 및 레지스트리에서 설치된 프로그램의 목록 확인

- 실행파일 점검

> 공격자들은 보통 악성코드를 발견 및 탐지하기 어렵게 하기 위해 노력한다.

> 확장자 변경 : 확장자를 변경해도 실제 데이터는 변경되지 않는다.

> 패킹 : 탐지 및 포렌식 분석을 무력화하기 위해 인코딩을 한다.

> ADS : 다른 파일이나 폴더의 대체 데이터 스트림에 존재하는 실행파일을 찾는다.

- 서비스, 드라이버, 자동 실행 위치, 예약된 작업 점검

> 악성코드는 재부팅 후에도 동작할 수 있도록 서비스, 드라이버, 예약된 작업과 같은 다양한 시작 루틴에 악성코드를 적용한다.

> 예약된 작업 : %SystemRoot%\Tasks 폴더 내에 예약된 작업을 조사

> 서비스 : 악성코드는 보통 새로운 서비스로 자신을 등록하거나, 기존 서비스에 자신을 추가한다.

> 자동실행

- 로그 조사

> 로그 파일을 바탕으로 악성코드 사고와 관련된 기록을 확인할 수 있다.

> 윈도우 이벤트 로그 : 보안 이벤트 로그 기록을 통해 외부 침입자가 내부 접근 권한을 획득한 정보를 확인할 수 있다.

> 웹 브라우저 히스토리 : 악성 웹사이트 접근 여부나 악성코드가 다운로드 된 사실을 확인할 수 있다.

> Desktop 방화벽 로그 : 감염된 시스템으로의 접근 시도 및 다양한 행동이 기록된다.

- 사용자 계정과 로그인 활동 검토

> 감염된 시스템에 새로운 비인가 계정이 생성됐는지, 패스워드가 없는 계정이 존재하는지, 관리자 그룹에 추가된 계정이 어느 것인지 등을 확인한다.

> 비인가 계정 생성 : 알려진 비인가 이벤트 발생 전후 생성된 사용자명이나 계정 확인

> 관리자 그룹 : 로컬 또는 도메인 레벨의 관리자 그룹에 있어서는 안되는 사용자 계정 확인

> 취약한 패스워드 : 패스워드가 없거나 쉽게 예측 가능한 패스워드가 설정되어 있는 계정 확인

3. 윈도우 레지스트리 조사

- 레지스트리

> 운영체제 내에서 작동하는 모든 하드웨어, 소프트웨어, 사용자 정보 및 시스템 구성 요소 등을 담고 있는 데이터 베이스

> 구성

> HKEY_CLASSES_ROOT를 비록하여 5개의 가장 상위키( =루트키 )를 갖는다.

> 각 루트키 아래의 서브키부터 아래의 모든 세부 서브키를 포함하는 트리구조를 레지스트리 하이브라고 한다.

> 각각의 하이브는 저마다 고유한 저장장소( 파일 )와 로그 파일을 갖고 있다.

- HKEY_CLASSES_ROOT

> 파일 확장자에 대한 정보, 각 파일과 프로그램간의 연결에 대한 정보, 마우스 오른쪽 단추의 등록 정보 등

> 모든 형식의 파일 확장자가 서브키 형태로 구성된다.

> HKLM\SOFTWARE\Classes 키에 동일하게 저장되어 두 곳이 연동된다.

- HKEY_CURRENT_USER

> 현재 로그인중인 사용자들에 대한 등록 정보

( 사용자 배경화면, 디스플레이 설정이나 단축 아이콘 정보 등 )

> 응용 프로그램의 우선 순위, 보안 접근 허용 여부

- HKEY_LOCAL_MACHINE

> 하드웨어 구성 초기화 파일, 제어판과 밀접하다.

> 사용중인 하드웨어 및 소프트웨어에 대한 정보

> 로그온 한 사용자와 관계없이 컴퓨터에 등록된 모든 사용자에게 동일

- HKEY_USERS

> 이전 사용자 초기화 파일을 보관

> 두 키 사이가 겹치면 HKEY_CURRENT_USER가 우선

- HKEY_CURRENT_CONFIG

> 현재 사용중인 윈도우의 디스플레이( 화면 글꼴이나 해상도 )정보와 프린터 관련 정보

> HKLM\Config 키의 내용과 같다.

- 하이브 파일

> %SystemRoot%\System32\config\

> C:\Users\{사용자명}\

- UserAssist( Link )

> 사용자 계정에 의해 실행된 프로그램 목록이 저장된다.

> UserAssist 키에는 가장 최근에 실행된 프로그램의 날짜/시간 스탬프와 같은 악성 행위에 대한 세부 정보를 제공한다.

- 이 키에 존재하는 값들은 "ROT13" 암호화 알고리즘으로 암호화 되어 있다.

- 사용자 계정 확인

> 사용자 별로 다른 계정이 존재한다.

> HKLM\SOFTWARE\Microsoft\CurrentVersion\ProfileList 이하에 각 사용자에 대한 Profile 정보가 포함되어 있다.

> 특정인에 의한 해킹이 시도된 경우로 새로운 사용자를 생성

- 특정 작업을 수행 후 사용자를 삭제한 경우 계정 정보 확인이 가능하다.

- 사용자 계정 확인 - 세부정보 확인

* AccessData Registry Viewer( Link )

> HKLM\SAM\Domains\Users\

- User Name, 로그온 횟수, 패스워드 변경시간 등을 확인 할 수 있다.

- 최근 열어본 문서

> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs

- Windows Explorer를 통해서 최근에 Open된  파일의 목록을 기록하고 있다.

- 파일 확장자로 구분되어 있으며, "Folder"는 최근에 Open한 파일의 폴더 목록을 유지한다.

- 자동 실행 프로그램

> HKU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

>%SystemRoot%\System32\Tasks\

- 컴퓨터가 부팅 후 자동으로 실행되는 프로그램 리스트

- 설치된 프로그램

> HKU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

> HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CureentVersion\Uninstall\

- 컴퓨터에 설치되어 있는 프로그램 리스트

- 최근 실행 명령어

> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

- [시작] -> [실행]에서 수행하여 기억하고 있는 명령어 목록

- 사용자가 실행한 명령어 목록을 확인 가능

- 컴퓨터 정보

> HKLM\SOFTWARE\Microsoft\WindowsNT\CureentVersion

- CSDVersion : Service Pack

- RegisteredOwner : 등록된 사용자

- SystemRoot : 시스템 기본 경로

- ProductName : OS 기본 정보

- InstallDate : 설치 일자

4. 기타 포렌식 분석

- 자동실행 프로그램 조사

* AutoRuns( Link )

> 컴퓨터가 시작할 때 자동으로 프로그램을 실행시키기 위해 참조하는 윈도우 시스템의 다양한 위치에서 상세 정보를 추출한다.

> 서명되지 않은 실행파일 목록 확인 가능

> 디스크에 존재하지 않는 실행 파일과 관련된 자동 실행 항목 확인 가능

- Prefetch 분석

> 윈도우의 부팅 커널까지 포함하여 응용 프로그램 실행 정보를 저장한 파일을 메모리에 올려두어 실행속도를 빠르게 하기 위한 기능이다.

> 침해사고 발생 시 사용자가 실행한 응용프로그램을 확인할 수 있다.

> 프로그램을 한번이라도 실행할 경우 '%SystemRoot%\Prefetch' 폴더에 .pf 확장자로 저장된다.

* WinPrefetchView( Link )

> 실행한 응용프로그램의 이름, 실행 횟수, 마지막 실행 시간, 참조 목록( dll / ini ) 확인

- 외장형 저장장치 분석

* USBDeviceForensics( Link )

> 사용자가 연결한 외장형 저장장치의 정보를 확인할 수 있다.

> HKLM\SYSTEM\ControlSet00x\Enum\USBTOR

- USB장치 정보 저장

- Device Class ID : Disk&Ven_XXX&Prod_YYY&Rev_ZZZ

- XXX( Vender ), YYY( Product ), ZZZ( Version )

> HKLM\SYSTEM\MountedDevices를 참조하여 어떤 USB 장치가 어떤 드라이브에 연결되었는지 확인 가능하다.

- 외장형 저장자치 분석 - 연결 기록

> %SystemRoot%\System32\winevt\Logs\ 폴더에 존재하는 Microsoft-Windows-DriverFrameworks-UserMode%40perational.evtx

- 이벤트 로그 분석을 통하여 외장형 저장장치의 연결/해제 관련 로그 확인 가능

- Security Identifier ( SID )

① 해당 시스템이 윈도우 시스템임을 말한다.

② 시스템이 도메인 컨트롤러이거나 단독 시스템임을 표시한다.

③ 시스템의 고유한 숫자. 이 고유한 숫자는 시스템을 설치할 때 시스템의 특성을 수집하여 생성한다.

④ 각 사용자 별 숫자로 표현되는 고유한 ID. 관리자는 500번, Guest는 501번, 일반 사용자는 100번 이상의 숫자를 갖는다.

> 시스템 고유 숫자를 이용하여 장치의 연결이력을 확인할 수 있다.

> 외장형 저장장치 및 HDD가 다른 윈도우 시스템에 연결될 경우 해당 시스템의 SID 값으로 휴지통 폴더가 생성된다.

> 휴지통 폴더 정보를 통해 장치의 연결 기록을 확인할 수 있다.

1. 메모리 포렌식 개요

메모리 덤프에는 악성 실행파일, 시스템 연관 데이터 구조, 관련된 사용자 활동 정보와 악성 이벤트 등 다양한 데이터가 내포되어 있다.

메모리 포렌식의 주된 목적은 악성코드와 직접적으로 관련이 있는 데이터를 추출하고 어떠한 이벤트가 발생했는지, 어떻게 악성코드가 설치됐는지와 같은 맥락 정보를 식별하는데 있다.

2. 윈도우 메모리 포렌식 도구

메모리 포렌식 도구의 내부 작동 원리를 이해하는 것은 특정 작업에 맞는 도구를 선택하고 결과의 정확도와 완성도를 평가하는데 도움이 된다.

주요 메모리 포렌식 도구가 공통적으로 제공하는 정보의 목록은 아래와 같다.

> Process와 Thread

> 모듈과 라이브러리

> 열린 파일과 소켓

> 다양한 데이터 구조체

- Process와 Thread 

* Volatility ( Link )

> 숨겨져 있거나 종료된 Process를 포함한 Process와 Thread 정보를 수집하고, 상세 분석을 바탕으로 어떤 Process가 악성코드와 연관되어 있는지 판단하는데 도움을 준다.

> 관련 Volatility 플러그인 정보

- psscan : 전체 Process 구조체를 카빙

- pslist : 동작중인 Process 목록 확인

- psdiff : psscan과 plist 목록을 비교

- dlllist : 해당 Process에 로드된 DLL목록 확인

- csrpslist : Process의 세부 정보를 추출해 숨겨진 Process 확인

> pslist 옵션 결과와 psscan 출력 결과를 비교해 악성코드에 의해 불일치 되는 부분을 찾아내거나 악성코드 행위와 관련된 비정상 상태 탐지 가능하다. ( psxview )

* Responder ( Link ) -> 유료이기 때문에 30일 동안만 무료로 사용할 수 있다.

> Process와 열린 Handle 목록 뿐만 아니라 메모리 덤프에서 URL, 사용자 명, 패스워드, 키, 그 외 기타 정보 등을 추출해 준다.

- 모듈과 라이브러리

> 악성코드는 자신을 은폐하거나 키로깅 하는 등의 주요 기능을 수행하기 위해 드라이버를 생성하거나 라이브러리를 로드한다.

> 관련 Volatility 플러그인 정보

- modules : 시스템에서 동작 중인 모듈 목록 제공

- driverscan : 특정 드라이버 객체를 메모리에서 검색

- moddump : 특정 모듈에 대해 실행 파일 포맷 형태로 파일을 추출

- dlldump : 메모리 덤프에서 특정 DLL 추출

> Responder를 이용하여 로드된 라이브러리와 드라이버 목록을 확인하고, 특정 개체에 대한 더욱 더 자세한 정보를 조사 가능하다.

1. 휘발성 데이터 수집

- 휘발성 데이터

전원이 끊어지면 손실되는 데이터 -> 초기 분석 수행해야 한다.

동작중인 시스템의 메모리에 존재한다.

Process, Password, IP address, event log 등 악성 코드와 관련된 내용 포함이 가능하다.

휘발성 데이터들의 수명은 그 특성으로 인해 모두 다르기 때문에 우선 순위를 고려해야 한다.

- 휘발성 순위

> Register, Cache

> Routing Table, ARP cache, Process Table, Kernel Statistics, Memory

> Temporary file system

> Disk

> Remote logging and monitoring data

> Physical configuration, network topology

> Archival media

휘발성 순위는 RFC3227 문서에 잘 정리되어 있다.

https://www.ietf.org/rfc/rfc3227.txt

- 디지털 증거의 무결성

라이브 시스템에서 데이터를 수집하는 행위는 해당 시스템( 디지털 증거 )에 영향을 줄 수 있다.

> 수집을 위한 외장형 저장장치 연결, 프로그램 설치 및 실행 등

수집 과정에서 일부 변경이 일어날 수 있으나, 보존과 처리 과정에서 변경이 발생하지 않음을 객관적 방법으로 진술 성립의 진정함이 증명되는 때에 증거로 할 수 있다.

- 휘발성 데이터 수집

시스템의 날짜 / 시간을 확인 후, 대상 시스템의 물리 메모리를 획득해야 한다.

> Windows 각 버전마다 메모리 구조가 다르기 때문에 도구에 따라 제대로 해석하지 못하는 경우가 발생한다.

> 따라서 물리 메모리 획득 및 라이브 시스템의 정보를 저장해 두어야 한다.

로컬에서 물리 메모리 획득

> 명령프롬프트나 GUI 유틸리티를 사용해 물리 메모리 덤프를 생성한다.

* 무료 물리 메모리 획득 툴

> MDD

> DumpIt

> FTK Imager

- 시스템 정보 수집

시스템 정보는 라이브 대응과 사후 포렌식 과정에서 타임 라인 생성, 로그와 기타 포렌식 아티팩트와 함께 대상 시스템을 식별하는데 활용된다.

* 주요 수집 대상 시스템 정보

> 시스템 날짜와 시간

라이브 대응 조사를 수행하는 과정에서 처음과 마지막에 수집하는 항목이다.

시스템 분석 시 타임라인 생성과 모든 문서의 기초이다.

대상 시스템의 날짜와 시간을 확인 후 정확한 검증을 위해 신뢰할 수 있는 시간 출처와 비교가 필요하다.

> 시스템 식별자

set user : 로그인한 사용자의 도메인, 이름, 프로필

net user [계정명] : 로컬 컴퓨터의 사용자 정보 수집

> 네트워크 구성

ipconfig : 로컬 컴퓨터에 설정된 IP 정보 및 MAC 주소 확인

netstat -ano : 프로토콜 연결, 연결 상태, 트래픽, 통계 등을 확인

> 서비스 정보

net start : 현재 윈도우 시스템에서 실행되고 있는 서비스 정보 수집

- 제공되지 않는 서비스 또는 유사한 서비스 명으로 등록된 것은 악성코드일 수 있다.

> 시스템 환경

systeminfo : 시스템 uptime, 종류, 프로세서, 메모리, 핫픽스, 네트워크 카드 정보 등 확인

> 공유폴더 정보

net share [공유 이름] : 로컬 컴퓨터의 모든 네트워크 공유 자원에 대한 정보

- 알지 못하는 공유 자원이 있는지 점검해야 한다.( NETBIOS 취약점 )

> 예약된 작업 확인

schtasks : 예약된 작업에 대한 자세한 정보를 제공

- 일부 악성코드 변종은 특정 날짜나 이벤트가 발생할 때까지 휴면상태로 남아있는 '이벤트 기반' 방식을 사용한다.

- 예약된 목록을 확인하여 휴면상태의 악성코드 등을 확인한다.

> 배치파일 제작

대상 시스템상에서 직접 명령어를 이용해 살펴볼 수 있으나, 실수와 누락을 피하기 위해 자동화 도구 등을 이용하는 것이 효율적이다.

2. 비 휘발성 데이터 수집

가용성이 중요한 서버 및 종료할 수 없는 시스템을 다룰 때에는 컴퓨터가 동작하는 동안 전체 시스템의 포렌식 사본을 생성해야 한다.

아래와 같이 주요 비활성 데이터에 대한 수집 및 분석을 수행한다.

> 보안 구성 평가

> 호스트 파일 획득

> Prefetch 파일 조사

> 자동시작 리스트 조사

> 이벤트 로그 조사

> 사용자 계정 조사

> 파일 시스템 조사

> 레지스트리 조사

- 보안구성 평가

* WinUpdateList( Link )

> 시스템이 안전하게 구성됐는지 점검하는 일은 호스트에서 발생할 수 있는 오용, 취약점, 가능한 공격 벡터의 위험 수준을 평가하는데 도움을 준다.

- 호스트 파일 획득

> %SystemRoot%\system32\drivers\etc\

> 해당 위치에 있는 파일들에는 신뢰된 호스트와 네트워크 정보가 존재한다.

> hosts : IP와 호스트 이름 사이의 관계

> networs : IP 주소 범위와 네트워크 이름 사이의 관계

> lmhosts : IP 주소와 NetBIOS 이름 사이의 관계

- Prefetch 파일 조사

> %SystemRoot%\Prefetch

> 윈도우 운영체제는 프로그램 실행 성능을 개선할 목적으로 'Prefetch' 파일을 생성한다.

> 비 정상적인 실행파일명을 포함하는 Prefetch 파일은 대상 시스템의 감염을 증명할 수 있는 잠재적 흔적이다.

- 자동 시작 리스트 조사

* AutoRuns( Link )

> 윈도우의 자동 시작 위치는 시스템을 재부팅해도 악성코드가 지속적으로 존재할 수 있도록 도와준다.

> 자동 시작 위치는 특정 폴더, 레지스트리, 시스템 파일을 비롯해 운영체제의 다양한 곳에 존재한다.

- 파일 시스템 조사

* HFind( Link )

> 일반 사용자는 보지 못하도록 숨겨진 파일이나 ADS의 위치 탐지 및 관련된 목록 출력해준다.

- 레지스트리 덤프

* regdump(  Link )

> 운영체제 내에서 작동하는 모든 하드웨어, 소프트웨어, 사용자 정보 및 시스템 구성 요소 등이 레지스트리에 저장된다.

3.20 전산대란에 대한 내용은 아래 링크를 참고하길 바란다.

https://ko.wikipedia.org/wiki/3·20_전산_대란

3.20 전산대란에 발생했던 것과 비슷한 상황의 vmdk를 이용해 실습을 진행한다.

* vmdk는 VMware용 가상 운영체제의 디스크 파일이다.

우선 HxD 에디터로 실습 파일을 실행해보면 다음과 같다.

이전에 봤던 다른 실습파일들과 구조가 다른것을 볼 수 있다. 예전 실습 파일들의 구조는 0번 섹터에 바로 MBR이 존재했지만 이번 실습파일은 0번 섹터에 MBR이 존재하지 않는다. 이는 vmdk 파일이기 때문에 vmdk 파일의 헤더가 가장 먼저 등장하기 때문이다. 이 헤더의 구조는 나중에 살펴보기로 하고 일단 MBR을 찾아 보자.

MBR을 찾기 위해서는 offset 40에서 00 ~ 07 위치에 있는 데이터가 실제 저장된 데이터의 시작 주소다. 따라서 '80 28 00 00 00 00 00 00'은 10,368이기 때문에 이 섹터로 이동하면 다음과 같다.

가장 먼저 등장하는 곳이 MBR인데 데이터가 모두 HASTATI.로 바뀌어 있음을 확인할 수 있다.

* MBR의 위치는 10,368

실습파일을 FTK 프로그램으로 열면 다음과 같다.

FTK는 헤더 정보는 모두 걸러내고 실제 MBR부터 표시를 해준다. 이 부분이 MBR 부분이라는 것을 쉽게 유추할 수 있다. 그리고 데이터가 모두 HASTATI.로 변경된 것을 이용해 다음 VBR의 위치를 찾아보면 다음과 같다.

아래 부분을 보면 'phy sec = 2048' 부분이 보이는데 실제 VBR의 위치가 2048 섹터임을 알 수 있다. 즉, 첫 번째 파티션의 위치가 2048 섹터임을 알 수 있다. 이는 예약 크기가 2048 섹터임을 알 수 있고 이를 통해 Windows vista 이상 버전임을 알 수 있다. Windows XP의 경우 예약 크기가 63 섹터이다.

HxD 에디터로 'HASTATI'를 검색하면 다음과 같이 다음 섹터를 알 수 있다.

위 캡쳐화면을 보면 10496 섹터에 첫 VBR이 나오는데, 이 위치는 실제 위치라고 보기 힘들다. 따라서 FTK를 이용해서 위치를 찾는 것이 포인트이다.

* 첫번째 파티션의 시작 위치는 10496

첫 번째 파티션의 타입이 무엇인지 모르기 때문에 해당 섹터에서부터 6 섹터 밑으로 갔을 때 VBR 백업본이 있으면 FAT32, 그렇지 않으면 NTFS임을 유추할 수 있다.

우선 10502 섹터에 가보면 다음과 같다.

해당 섹터에 가보니 알 수 없는 데이터만 있는 것을 확인할 수 있다. 따라서 FAT32 타입이 아니라 NTFS 타입임을 알 수 있다. NTFS의 경우 VBR 백업본이 해당 파티션 끝에 존재하기 때문에 찾기가 힘들다. 하지만 BR이 'HASTATI.' 라는 문자열로 모두 바뀐 것을 이용해 FTK 프로그램으로 찾아보면 다음과 같다.

206848 섹터에서 'HASTATI' 문자열이 등장하였고 그 위 섹터에 NTFS 백업본이 있는 것을 확인할 수 있다. 이 VBR 데이터를 따로 저장해 놓자. 이름은 'partition1'로 하도록 하자.

현재 위치에 있는 VBR의 타입을 모르기 때문에 마찬가지로 6섹터 밑으로 가보면 다음과 같다.

역시 마찬가지로 VBR이 아닌 알 수 없는 데이터만 존재하는 것을 볼 수 있다. 따라서 두번째 파티션 또한 NTFS 임을 확인할 수 있다.

파티션이 더 있는지 확인하기 위해 'HASTATI' 문자열을 이용해 검색을 해보면 다음과 같이 찾지 못했다는 메시지가 뜨는 것을 확인할 수 있다.

즉, 두번째 파티션이 마지막 파티션이라는 것을 유추할 수 있다. 하지만 백업본의 위치는 찾지 못했다. 백업본의 위치를 찾기 위해 시그니처를 이용한다. NTFS의 시그니처는 "EB 52 90 4E 54 46 53 20"이다. 이 시그니처를 이용해서 하나 하나 찾아가다보면 VBR 형식의 데이터가 여럿 존재하는 것을 확인할 수 있다. 

다음 캡쳐파일을 보자.

위의 캡쳐파일을 보면 NTFS의 VBR 형식이 맞는 것 같다. 하지만 데이터를 조금만 분석해보면 백업본 VBR이 아님을 알 수 있다.  캡쳐파일이 잘 안보이기 때문에 HxD로 옮겨서 보도록 하자.

일단 offset 0의 0D( 13 )번째 바이트를 보면 '01'로 되어 있는데 이는 클러스터의 크기가 1섹터라는 의미이다. 하지만 기본적으로 클러스터의 크기는 8 섹터이다. 이것만 봐도 VBR이 아님을 알 수 있지만 이 값이 '08'인 경우도 있다. 그럴 경우 offset 10의 0C~0F( 12 ~ 15 )번째 바이트를 보면 "02 00 00 00" 으로 되어 있다. 이는 Hidden Sector 부분으로 현재 섹터 앞에 있는 모든 섹터의 수가 2 섹터임을 의미하는데, 위의 FTK 파일 캡쳐화면을 보면 나오는 섹터 수와 다름을 알 수 있다. 이렇듯 데이터를 분석했을 때 납득이 되지 않는 부분이 존재한다면 백업 VBR이 아니라는 것을 알 수 있다. 

실제 백업 VBR을 보면 다음과 같다.

위 부분이 바로 두번째 파티션의 백업 VBR이다. 이를 'partition2'라는 이름으로 따로 저장해 놓자.

HxD 에디터를 이용해서 VBR을 복구해보자.

HxD에서 'HASTATI' 문자열을 검색했을 때 두번째 나오는 섹터가 첫 번째 파티션의 VBR 부분이고, 세번째 나오는 섹터가 두번째 파티션의 VBR이라는 것을 앞서 확인했다. 따라서 첫 번째 파티션의 VBR 부분에 'partition1'으로 저장한 데이터를 붙여 넣으면 다음과 같다.

똑같은 방법으로 두번째 파티션의 VBR을 복구해보면 다음과 같다.

여기까지 두개의 파티션에 대한 VBR을 복구했다. 하지만 MBR이 복구가 되지 않았으므로 여전히 부팅이 되지 않는다. 그렇기 때문에 이제 MBR을 복구해보도록 하자.

우선 위와 같이 디스크 관리에 들어가 VHD 만들기 메뉴를 선택하면 다음과 같이 나타난다.

위치는 VHD를 저장할 위치를 지정하고 디스크 크기는 적당하게 잡아준다. 여기서는 3GB로 잡았다. 디스크 포맷으 VHD, 디스크 유형은 고정 크기로 설정하고 확인을 선택한다.

그러면 위와 같이 디스크가 추가가 되며 해당 디스크를 우클릭해 디스크를 초기화 한다.

디스크를 초기화할 때 파티션 형식을 MBR로 선택하고 확인을 누른다.

위 화면과 같이 디스크 1은 온라인으로 바뀌고 디스크를 우클릭해서 새단순 볼륨을 선택해 디폴트로 설정된 값으로 진행을 한다.

포맷이 완료가 되면 디스크1의 연결을 해제하고 HxD 에디터로 방금 생성한 VHD을 열어보면 다음과 같다.

블록박스 처리된 부분( 0 ~ 439 바이트 )까지의 값을 복사하여 복구할 MBR에 붙여넣어 준다. 

위와 같이 변경을 하고나서 FTK로 복구한 파일을 열면 다음과 같이 나타난다.

파티션은 복구가 된 것을 확인할 수 있다. 하지만 여전히 부팅이 되지는 않는다. 이유는 data signature를 수정해주지 않았기 때문이다. data signature는 기기마다 다르다고 보면 되기 때문에 이 값이 다르면 당연히 부팅이 되지 않는다. 이 값은 레지스트리에 존재하며 복구된 파티션에서 'NONAME > [root] > Windows > System32 > config > SYSTEM' 파일을 우클릭으로 추출한다.

추출한 SYSTEM 파일을 레지스트리 편집기를 이용해 하이브 로드하여 data signature를 확인한다.

하이브 로드를 선택하여 SYSTEM 파일을 선택하고 사용할 키 값을 입력한다. 여기서 키 값은 '320'으로 했다.

그러면 위와 같이 '320 > MountedDevices'에 가보면 C 드라이브의 데이터를 앞에서 4바이트 만 기억하고 이 값을 MBR의 440 ~ 443 번째 바이트에 넣어주면 된다.

위와 같이 값을 넣어주면 복구가 모두 완료가 됐다. 여기까지 완료가 됐다면 해당 이미지 파일을 가지고 VMware에서 부팅이 가능해야 한다. 하지만 부팅이 되지 않는다. $BOOTMSG 파일이 존재하지 않기 때문에 부팅 코드가 메모리에 로드되지 않는다. 따라서 부팅시키기 위해서는 윈도우 cd를 이용해 복구 모드로 들어가야 한다.