[Forensics] 3.20 전산대란 디스크 복구 실습

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를 이용해 복구 모드로 들어가야 한다.