TOD-Forensics

1. smartmontools 설치

~ % brew install smartmontools

2. diskutil 명령어로  Physical disk 번호 확인

~ % diskutil list

3. 아까 설치한 smartmontools로 Serial Number 확인

~ % sudo smartctl -a /dev/disk0

/HealthDomain/Health/healthdb.sqlite
69B2014F1942434DB03248CC360A163C 아이폰
EF1E706D9C564D8DB6DC448EBB44CC6F 애플워치
8DFC9743AABA48B5AAECCAEDFC7686DE 수면

key_value_secure -> 개인 정보

date_type 2 -> height
date_type 237 -> 손씻기
date_type 173 -> 헤드폰 오디오 레벨 (단위 db)
date_type 63 -> 수면시간
date_type 195 -> 계단 올라가기 속도 (단위 m/s or ft/s)
date_type 196 -> 계단 내려가기 속도 (단위 m/s or ft/s) 
date_type 186 -> 일어서기 시간 (분)

when 3 then 'Weight'
when 5 then 'Heart Rate'
when 7 then 'Steps'
when 8 then 'Distance'
when 9 then 'Resting Energy'
when 10 then 'Active Energy'
when 12 then 'Flights Climbed'
when 67 then 'Weekly Calorie Goal'
when 70 then 'Watch On'
when 75 then 'Standing' 
when 76 then 'Activity'
when 79 then 'Workout' 운동
when 83 then 'Some workouts'

rowid data_id start_date end_date data_type
109434 109434 625273077.543597 625273077.543597 5


https://www.gstatic.com/images/icons/material/apps/weather/2x/sunny_light_color_64dp.png
16" 16* 12


https://www.gstatic.com/images/icons/material/system/2x/domain_grey600_24dp.png
https://encrypted-tbn2.gstatic.com/favicon-tbn?q=tbn%3AANd9GcRiluQc8VO1_LzDlZgzzhscF6ufjtnfAAgzYOf3jMMUcVTjH9ILkSsAWhQEHwjPnm4Rw6xP6BtcTCdOAd9HPRH_P0kGydYzjq-LQGO4tIYK2tEPubRKDQ.PNG

학교 수업 후 미리 실습을 해보라고 교수님이 준 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 부분을 추가한다고 하면 글이 매우 길어... 아니 귀찮았다. 

제조사가 하드 디스크를 2TB라고 했지만 실제로 컴퓨터에 연결했을 때에는 1.81TB라고 표시되어진다. 그 이유는 왤까?

2TB 하드 디스크를 예를 들어보자. 

- 2TB가 가지고 있는 총 섹터 수는 3,907,029,168

- 하드 디스크의 용량은 3,907,029,168 * 512 = 2,000,398,934,016 바이트 

  (총 하드 디스크 용량 = 총 섹터 수 X 512 바이트)

하드 디스크 제조사는 깔끔하게 숫자가 되어지는 것을 원하기 때문에 하드 디스크 사용 단위로 반올림을 한다. (지금은 TB 단위로 예를 들어서 1TB 기준)

2TB 하드 디스크 기준 제조사는 단순히 소수점을 12 자리로 옮겨 소수점 이하는 반올림 처리해 2TB 하드 디스크라고 부른다.

하지만 컴퓨터는 이를 신경쓰지 않고 1TB가 1,099,511,627,776(2^40)바이트인 2진수 체계를 사용한다. 그래서 하드 디스크 용량 / 1TB를 한다.

2,000,398,934,016 / 1,099,511,627,776 = 약 1.81TB

따라서 컴퓨터는 제조사에서 명시한 2TB 크기를 1.81TB로 인식해 보여준다. 

대부분의 사람들은 제조사에서 적어준 용량과 다른 이유를 컴퓨터에서 HPA(Host Protected Area)나 DCO(Device Configuration Overlay) 영역 때문 혹은 시스템에서 잡는 예약 영역이라고 하는 분도 있다. 하지만 실질적으로 디스크의 모든 섹터를 본다면 완벽한 정답은 아니다. 

아무튼 표기가 다른 이유는 위 처럼 제조사에서 단위를 반올림을 하지만 컴퓨터는 하드 디스크 있는 그대로 표시하기 때문이다.

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:\ 경로에 존재한다. (보호된 운영 체제 파일 숨기기 체크 해제하면 확인 가능)

레지스트리 편집기에서 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 경로를 찾는다.

DWORD 키를 생성한다. 생성 내용은 다음과 같이 한다.

- 이름 : EnableLinkedConnections

- 값 : 1

마지막으로 재부팅을 한다.

- 레지스트리 파일 생성시 내용

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

"EnableLinkedConnections"=dword:00000001

메모장으로 위 내용을 입력하고 .reg 확장자로 저장!!

- xcopy

파일의 속성 값까지 복사 하기 위한 방법 중 하나는 cmd 창에서 xcopy 명령어를 실행하면 된다. 

xcopy [원본 경로] [복사 경로] [옵션]

옵션

/e : 비어 있는 하위 디렉토리까지 복사

/h : 히든 파일과 시스템 속성의 파일까지 복사

/k : 파일 속성 복사 (이 옵션이 없으면 속성이 없어져 버림)