정보보안 엔지니어링

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

지금 할 실습은 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를 마운트 시켜서 탐색기로 보게 되면 다음과 같이 파일이 존재하는 것을 확인할 수 있고

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