TOD-Forensics

학교 수업 후 미리 실습을 해보라고 교수님이 준 damaged_image.bmp 파일이다.

역시나 열리지 않는다. 그래서 습관적으로 HxD에서 파일을 확인해보니 파일 헤더 부분이 뭔가 엉성하다는 느낌을 받았다. 제일 먼저 .bmp 파일 시그니처가 보이지 않았다. 그래서 Offset 00 ~ 01 부분에 .bmp 파일의 시그니처인 0x42 0x4D 를 넣어서 열어봤지만 역시나 지원하지 않는다고 한다. 그래서 결국 .bmp 파일 구조를 알아보기로 했다.

.bmp 파일이 무엇인지, 자세한 구조가 어떻게 구성되어 있는지는 구글링을 해보시길 바란다. 이 글보다 훨씬 더 좋은 글이 많다.

.bmp 구조를 간략하게 정리하면 아래와 같다.

그리고 저 문제를 풀기 위해서는 File Header 부분이 필요하기 때문에 해당 영역에 대해서만 자세히 기술했다. 그리고 설명을 위해 정상 파일인 제목없음.bmp를 생성했다.

네모 박스 순서대로 아래 표와 같은 의미를 같는다.

- bfType : 빨간색의 네모 박스가 인코딩 된 문자열을 보면 BM으로 나와있는 것을 확인할 수 있다. 

- bfSize : 0x59AB79 (리틀 엔디안) = 5876598 Bytes 다. 해당 파일의 속성에서 파일 크기랑 같은 것을 볼 수 있다.

- bfOffBits : 0x36 Offset으로 이동하면 해당 파일의 실질적인 데이터의 시작 위치다.

여기까지 기본적인. bmp의 File Header 설명이다. 이제 문제로 돌아가서 상황을 요약했다.

1. 파일 시그니처가 없다.

2. 파일 사이즈에 대한 값이 없다.

3. 내가 예시로 만든 파일보다 File Header가 짧다.

내가 문제를 풀면서 고민을 했던 게 File Header 길이였다. 그림판으로 여러 bmp 파일을 만들었다. 하지만 아래의 그림처럼 비트맵 종류가 많았고, 해당 데이터를 HxD로 열어보니 File Header 길이도 제각각이었다. 그래서 개인적으로 일반적이라고 생각하는 24비트 비트맵이라고 가정하고 문제를 풀었고 풀렸다...

일단 24비트 비트맵이라고 가정하고 문제를 풀었기 때문에 File Header 길이가 부족한 것으로 생각하고 헤더에 데이터를 덮어쓴 것이 아니라 삭제했다고 생각이 들었다. 그래서 파일 시그니처를 표시하는 bfType부터 bfOffBits를 해당 파일에 썼다.

1. bfType : 파일 시그니처인 0x42 0x4D

2. bfSize : 해당 파일 속성에서 파일 크기는 29,992 bytes이다. 그래서 29,992(10진수)를 그대로 16진수로 변환을 해서 0x7528이라는 값이 나왔고 이것을 리틀 엔디안으로 바꿔주면 0x28 0x75 0x00 0x00 

3. bfReserved1 : 예약된 영역으로 사용하지 않는다고 했으니 0x00 0x00

4. bfReserved2 : 3번과 마찬가지로 0x00 0x00

5. bfOffBits : [그림 6]과 개인적으로 생각하는 일반적인 bmp 파일의 실질적인 데이터 시작 위치인 Offset 값을 가져와서 0x36 0x00 0x00 0x00

해당 데이터를 입력한 파일을 저장하고 열면 아래와 같은 그림이 나온다.

실제로 내가 이 문제를 풀 때 Image Header 부분까지 확인하고 일일이 데이터 값을 보면서 구조가 맞는지 확인했지만 해당 문제를 푸는데 제일 중요한 부분은 File Header 부분이라고 생각을 했다. Image Header 부분을 추가한다고 하면 글이 매우 길어... 아니 귀찮았다. 

Windows에서 자주 사용하는 폴더가 하나 이상은 있을 겁니다. 그러면 Windows는 자주 사용하는 폴더라고 파일 탐색기에 생성을 합니다. 또는 사용자가 파일 탐색기에 쉽게 폴더를 들어갈 수 있게 바로 가기 설정하는 경우도 있습니다. 아래 사진 처럼요.

사진처럼 자주 사용하는 볼더와 바로 가기에 대한 정보는 다음과 같은 경로에 저장되어 있습니다.

C:\Users\{사용자 계정}\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms

f01b4d95cf55d32a.automaticDestinations-ms 라는 파일을 삭제해주면 자주 사용하는 폴더 내용과 바로 가기 설정한 기록들이 사라집니다. 참고로 AutomaticDestinations 폴더는 파일 탐색기에서 보이지 않기 때문에 경로 입력 공간에 직접 입력해주셔야 합니다.

* 삭제한 파일을 다시 같은 경로에 넣어주면 삭제 전 설정한 내용들이 그대로 다시 생깁니다.

참고로 위에 보이는 4개의 폴더는 Windows의 기본 설정이기 때문에 지워지지 않습니다.

친절하신 분이 이미 만들어 놓으셨음... 자세한 설명까지... 친철해~

http://ios7hash.derson.us/

android-sdk-windows에서 fastboot.exe 프로그램으로 Android LOCK STATE Unlock이 가능하다.

1. 개발자 모드에서 Android Debugging을 활성화 시킨다.

2. 단말기를 종료 후, fastboot mode로 진입한다.(fastboot mode 진입 방법은 단말기마다 다를 수 있기 때문에 구글에 물어보시면 됩니다.)

3. PC와 단말기를 연결하고 fastboot.exe devices 명령어로 연결 상태 확인한다.

4. fastboot.exe oem unlock 명령어 실행 시키고, Unlock bootloader를 선택한다.(단말기에서 아래와 같은 그림이 나옵니다.)

5. LOCK STATE unlocked 상태를 확인 가능하다.

6. fastboot.exe reboot 명령어로 재부팅

* 반대로 Lock 방법은 fastboot.exe oem lock 입니다.

컴퓨터를 강제로 종료하게 되면 RAM에 있는 중요한 정보는 사라진다. 그러나 RAM에 저장된 데이터는 종종 스왑 파일(swap file)이라고 하는 파일 형태로 하드 디스크에 저장되기 때문에 모든 데이터가 사라진다고는 할 수 없다. 이 스왑 파일은 기본 설정(default configuration)으로 대부분의 마이크로소프트 윈도우 시스템에 저장되며, RAM의 데이터는 스왑 파일 자체로 저장되기 때문에 스왑 파일 크기가 바뀌면 비할당 클러스터와 파일 슬랙에 남아있을 수 있다. 비할당 클러스터와 파일 슬랙은 할당된 파일에 포함되지 않은 데이터가 있는 영역이다.

또한, 컴퓨터가 절전 모드에 있는 경우에는 RAM에 있는 모든 내용이 hiberfil.sys 파일에 저장되기 때문에 RAM의 내용은 디스크에서 복원할 수 있다. 

hiberfile.sys의 파일 경로는 C:\ 경로에 존재한다. (보호된 운영 체제 파일 숨기기 체크 해제하면 확인 가능)

1. DOC ?

컴퓨터에서 DOC 또는 doc (Document의 준말)은 워드 처리 문서를 위한 파일 확장자이다. 대개 Microsoft Word에 쓰인다. 역사적으로 이 확장자는 다양한 운영 체제에서, 특히 프로그램이나 컴퓨터 하드웨어의 플레인 텍스트 형식으로 사용되었다. 1980년대에 워드퍼펙트는 DOC을 저들의 사유 포맷 확장자로 사용하였다. 나중에 1990년대 말에 이르러 Microsoft는 DOC 확장자를 자신의 Microsoft Word 처리 포맷으로 사용하였다. 전자의 경우는 PC 세상에서 대부분 사라진 상황이다. - Wikipedia -

MS Word 바이너리 파일 포맷의 기본 스트림(WordDocument 스트림)은 파일 정보 블록(FIB, File Information Block)으로 시작한다. FIB는 파일의 각 부분에서 참조하는 문서 텍스트 및 기타 정보를 포함하는 가변 길이의 형식의 구조이며, 최대 크기는 0x7FFFFFFF 이다.

2. BIFF 파일 형식

DOC 파일은 "D0 CF 11 E0 ..." 으로 시작되는 BIFF 파일 형식이다.

3. DOC 파일 구분할 수 있는 문자열

파일 중간에 "WordDocument" 문자열이 존재한다면 DOC 파일로 볼 수 있다.

4. FibBase 구조

FIB는 MS Word 바이너리 파일에 포함된 구성요소의 정보를 한 쌍의 정수 형태로 가지고 있다. 최상위 32바이트에 저장된 FibBase 고정된 크기이며 포맷 분석에 사용되는 주요 정보를 포함된다. 다음 그림은 FibBase 전체 구조이다. 아래 구조 설명은 MS에서 제공하기 때문에 MS에서도 확인 가능하다.

(아래 글은 거의 다 MS에서 제공하는 문서를 참고 했어요... 확실한 것을 원한다 싶은 사람은 MS 문서를 참고해주세요.)

- wIdent

Word 바이너리 파일의 시그니처 (0xA5EC)

- nFib

사용되는 파일 포맷의 버전 (0x00C1). FibRgCswNew의 nFib 속성 값이 있는 경우 그 값이 사용된다. 이 값은 설치 언어를 지정하는데 사용되기도 한다.

nFib 값     cswNew 값

0x00C1 -> 0

0x00D9 -> 0x0002

0x0101 -> 0x0002

0x010C -> 0x0002

0x0112 -> 0x0005

- unused 

사용되지 않는 값이다.

- lib

문서를 생성하는 응용프로그램의 설치 언어를 지정하는 값이다.

nFib 값이 0x00D9 이거나 크면 동아시아, 스페인어, 독일어, 불어이다. 0x0101 이상이면 베트남어, 태국어 또는 힌디어이다.

- pnText

WordDocument 스트림에 포함된 모든 상용구 항목을 지칭하는 오프셋으로 부호 없는 정수. 이 값이 0이면 연결된 상용구 항목이 없다.

- A ~ M

문서 속성 값을 나타낸다. 

해당 값을 비트로 나타내면 0x52F0 = 0101 0010 1111 0000과 같다. 0이 yes, 1이 no 이다.

A - fDot : 템플릿 여부

B - fGlsy : 상용구만 포함되어 있는지 여부

C - fComplex : 증분 저장을 사용하는지 여부

D - fHasPic : 문서에 그림을 포함하는지 여부

E - cQuickSave(4 bit) : nFib가 0x00D9 보다 작은 경우 자동 저장 시간을 의미

F - fEncrypted : 암호화 및 난독화가 지정되었는지 여부

G - fWhichTblStm : FIB가 참조하는 테이블 스트림(0 -> 0Table, 1 -> 1Table)

H - fReadOnlyRecommended : 문서 작성자가 읽기전용 모드로 지정했는지 여부

I - fWriteReservation : 문서에 쓰기 예약 암호가 있는지 여부

J - fExtChar : 반드시 1

K - fLoadOverride : 기본 단락 스타일에 지정된 언어 정보와 글꼴을 응용 프로그램의 설치 언어에 적합한 기본 값으로 대체할지 여부

L - fFarEast : 문서를 만든 응용 프로그램의 설치 언어가 동아시아 언어인지 여부

M - fObfuscated : fEncrypted가 1이면 비트는 XOR 난독화를 사용하여 문서가 난독화 되는지 여부를 지정

- nFibBack

파일 포맷 버전에 따라 값이 달라진다. 0x00BF은 Word 97 버전이다.

- IKey

fEncrypted가 1이고, fObfuscated 1이면 XOR 난독화 암호 확인자(password verifier)를 지칭한다.

- envr

사용되지 않으며 값은 0이다.

- N ~ S

기타 속성 값을 나타낸다.

해당 값을 비트로 나타내면 0x10 = 0001 0000과 같다. 

N - fMac : 사용되지 않으며 값은 0이다.

O - fEmptySpecial : 사용되지 않으며 값은 0이다.

P - fLoadOverridePage : 페이지 크기, 방향 및 여백의 섹션 속성을 응용프로그램 설치 언어에 적합한 기본 값으로 대체할지 여부

Q - reserved : 사용되지 않으며 값은 0이다.

R - reserved : 사용되지 않으며 값은 0이다.

S - fSpare0(3 bit) : 사용되지 않으며 값은 0이다.

- reserved3 ~ 4

사용되지 않으며 값은 0이다.

- reserved5 ~ 6

사용되지 않으며 값은 0이다. 

1. BIFF?

BIFF은 다른 회사에서 제작한 소프트웨어 간 데이터를 쉽게 전송할 수 있도록 고안된 범용적인 컨테이너파일 형식인 IFF형식을 기반으로 한다. 여러 시트를 포함하는 통합 문서(BIFF5~8)는 일반적으로 복합문서파일(Compound Document File, OLE 파일) 형식으로 저장한다. 이러한 파일 형식은 "OLE2 저장 파일 형식" 또는 "Microsoft Office 호환 저장 파일 형식" 이라고도 한다. BIFF 구조를 확인하기 위해서 doc 파일 문서로 예를 들어보자!

2. BIFF 파일 시그니처

BIFF 파일 시그니처는 "D0 CF 11 E0 ..." 으로 시작한다.

3. OLE 파일 구조

OLE 파일은 그림과 같이 헤더와 데이터 블록으로 구성이 된다. 헤더는 OLE 파일 전체 주요 정보를 가지고 있고, 데이터 블록은 다음과 같다.

- Property : 저장소(폴더) 및 스트림(파일) 정보를 보관

- 스트림 데이터

- BBAT(Big Block Allocation Table)

- SBAT(Small Block Allocation Table)

데이터 블록은 주로 스트림 데이터가 주로 차지하고 있다. 이 데이터는 흩어져 있어 특정 스트림 블록 위치는 Big/Small Block Allocation Table에 링크로 저장되어 있다.

OLE 파일을 512 Byte 단위로 나누어 도식화를 하면 위 그림과 같다. -1 블록이 헤더 블록이며, 0 .. n 블록이 데이터 블록이다.

4. BBAT, SBAT 및 BBAT Depot

BBAT/SBAT는 OLE 내부의 데이터 스트림(파일)의 위치 정보를 링크 형태로 저장하고 있다. Property(저장소/스트림)의 크기가 4096 Byte 보다 작으면 SBAT, 크면 BBAT를 참조하여 링크 구조를 생성한다. 파일의 크기가 커지면 BBAT가 저장된 저장소(Depot)의 크기도 증가하게 된다. BBAT 저장소 헤더에는 BBAT 저장소의 개수(n)가 명시되어 있다.

5. 분석

- BBAT Depot 개수

헤더의 0x2C ~ 0x2F 위치에 값은 BBAT Depot의 개수를 나타낸다. 리틀 엔디안 방식으로 읽는다. 그러므로 값은 8이다. 8개의 Depot이 존재한다는 뜻.

- Property 시작 위치

헤더의 0x30 ~ 0x33 위치에 값은 Property의 시작 offset이다. 0x386는 10진수로 902이다. 즉 902번째 블록에 위치한다는 뜻이다. 512 Byte 기준이므로 512를 곱해주고 헤더가 -1이므로 512를 더하면 정확한 위치 값이 나온다. (902*512+512 = 462,336)

해당 위치로 가면 Root Entry 라는 내용이 보일 것이다. Property 영역의 시작을 알리는 문자열이다.

- SBAT 시작 위치

헤더의 0x3C ~ 0x3F 위치에 값은 SBAT의 시작 offset이다. Property와 같은 방법으로 이동하면 된다.

- SBAT Depot 개수

헤더의 0x40 ~ 0x43 위치에 값은 SBAT Depot 개수를 나타낸다.

-Extra BBAT Depot 위치

헤더의 0x44 ~ 0x47 위치에 값은 Extra BBAT Depot의 시작 offset이다. 0xFFFFFFFE Extra BBAT Depot이 존재하지 않는다는 뜻이다. 존재하게 되면 해당 위치 offset 값으로 설정이 된다. BBAT Depot이 확장이 되는 이유는 헤더는 아래에서 나중에 설명하겠다.

- Extra BBAT Depot 개수

헤더의 0x48 ~ 0x4B 위치에 값은 Extra BBAT Depot의 개수를 나타낸다.

- BBAT Depot 위치

헤더의 0x4C ~ 0x1FF 위치에 값은 BBAT Depot의 시작 offset이다. 4 Byte씩 읽고, 0xFFFFFFFF 값은 비어있다는 뜻이다. 헤더에서는 총 109개의 Depot offset이 존재한다. 109개가 넘어가면 Extra BBAT Depot 시작 위치 offset과, Extra BBAT Depot 개수 offset값이 변한다. Extra BBAT Depot 개수가 2개 이상이면, 다음 Depot 위치는 해당 Extra BBAT Depot 마지막 4 Byte에 저장이 된다. offset에 해당하는 데이터 블록을 512 Byte 씩 읽어서 순차적으로 연결하면 하나의 OLE 데이터 스트림을 구성할 수 있다. 이 때 마지막 블록은 실제 데이터 크기가 512 Byte 미만일 경우를 고려하여 전체 스트림 크기를 조정한다.

6. 파일 버전에 따른 프로그램 버전과 포맷 구조

만약 버전 정보가 없다면, BIFF 포맷 정보를 확인한다.