정보보안 엔지니어링

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

앞선 포스팅에서는 MBR, VBR을 분석하는 정도로 실습을 했다. 하지만 이번 포스팅에서는 MBR이 날아간 경우와 VBR이 날아간 경우 그리고 MBR와 VBR이 함께 날아간 경우에 대해 분석하고 복구하는 실습을 한다.

실습에 앞서 먼저 파일시스템의 BR에 대해 간단하게 설명하고자 한다.

- FAT32 구조

FAT32는 위와 같은 구조를 갖는다. FAT32의 BR은 Boot Sector에 존재한다.

- FAT32의 BR

FAT32의 BR은 위와 같은 구조를 갖으며, 각 영역의 의미는 다음 표와 같다.

- NTFS 구조

NTFS는 위와 같은 구조를 갖는다.

- NTFS의 BR

NTFS의 BR 구조는 위와 같으며 각 영역의 의미는 다음 표와 같다.

FAT32와 NTFS의 구조 중 BR에 대한 부분만을 살펴봤다. 이를 참고하여 다음 예제를 실습해보자.

- MBR Test #3

예제 파일을 HxD 에디터로 열어보면 위와 같다. Partition Table이 위치한 446 ~ 509 바이트를 보면 00으로 비어있는 것을 알 수 있다. 즉 MBR이 손상된 경우이다. 

예제 파일을 FTK 프로그램으로 실행시켜보면 다음과 같다.

Evidence Tree에 보면 파티션이 나눠지지 않는 것을 확인할 수 있으며 해당 디스크가 손상되어 있음을 확인할 수 있다.

이를 복구하기 위해선 다음과 같은 절차를 거친다.

1. VBR의 위치를 찾는다.

2. 해당 파티션의 총 크기를 구한다.

3. MBR의 Partition Table에 구한 값을 수정한다.

4. 제대로 복구가 됐는지 확인하기 위해 FTK 프로그램으로 해당 디스크 구조를 열어 확인한다.

그럼 이제 실습파일을 이용해 분석을 해보도록 하자. 우선 실습파일을 HxD 에디터를 이용해 로드한다. 

첫번째 VBR은 윈도우 XP의 경우 VBR의 위치는 63섹터, Vista 이상의 버전에서는 2048 섹터에 위치한다. 이를 이용해 해당 섹터에 이동해보면 VBR이 존재하지 않는 것을 볼 수 있다. 이는 vhd를 분석할 때 종종 나타나며 보통 128 섹터에 첫번째 VBR이 위치한다.

FAT32 BR 구조를 참고하여 위 VBR을 분석해보면 Hidden Sector는 '80 00 00 00'으로 128, 즉 0번 섹터부터 127 섹터까지를 의미한다. 그리고 Total Sector는 '00 98 07 00'으로 497,664이다. 두번째 VBR의 위치는 497,664 + 128인 497,792 섹터로 이동해 보면 다음과 같다.

NTFS BR 구조를 참고하여 위 VBR을 분석해보면 Hidden Sector는 '80 98 07 00'으로 497,792, 즉 0번 섹터부터 497,791 섹터까지를 의미한다. 그리고 Total Sector는 'FF 9F 05 00'으로 368,639이다. 세번째 VBR의 위치는 497,792 + 368,639 + 1인 866,432 섹터로 이동해 보면 다음과 같다.

* 여기서 1을 더한 이유는 NTFS의 Backup VBR의 위치는 해당 파티션 끝에 위치하여 Backup VBR 바로 이전의 섹터까지만 Total Sector에 포함되기 때문에 더해준다.

위와 마찬가지로 NTFS 파일시스템임을 알 수 있다. VBR을 분석해보면 Hidden Sector는 '80 38 0D 00'으로 866,432, 즉 0번 섹터부터 866,431 섹터까지를 의미한다. 그리고 Total Sector는 'FF DF 06 00'으로 450,559이다. 네번째 VBR의 위치는 866,432 + 450,559 + 1인 1,316,992 섹터로 이동해보면 다음과 같다.

Partition Table의 정보를 보면 Partition Type이 '0B'로 FAT32임을 알 수 있고 시작 위치가 '80 00 00 00'으로 128이다. MBR의 특성상 4번째 파티션부터는 Extended Boot Record( EBR )로 상대적인 위치를 나타낸다. 따라서 해당 파티션의 실제 위치는 1,316,992 + 128인 1,317,120 섹터이다. EBR의 특성에 따라 파티션 테이블은 최대 2개가 존재한다. 2번째 테이블을 분석해보면 Partition Type은 '05'로 Ext이고 해당 파티션의 시작 위치는 '80 40 06 00'으로 409,728이다. 이 파티션 역시 실제 위치는 1,316,992 + 409,728인 1,726,720 섹터로 이동해보면 각각 다음과 같다.

* EBR은 MBR과 비슷한 구조를 갖지만 MBR과 달리 파티션 테이블을 제외한 곳은 모두 0으로 채워져 있다.

EBR 부분을 이전에 만든 python 코드로 돌려보면 위와 같이 분석이 되는 것을 알 수 있다.

FAT32 파일시스템임을 알 수 있다. 해당 파티션의 총 크기는 '00 40 06 00'으로 409,600 * 512 / 1024 / 1024 = 200MB 임을 계산할 수 있다.

Partition Table 정보를 보면 하나의 정보만 존재하는 것을 확인할 수 있다. 이는 더 이상의 파티션이 존재하지 않음을 의미한다. Partition Type이 '0B'로 FAT32임을 알 수 있고 시작 위치가 '80 00 00 00'으로 128이다. 이 파티션 또한 실제 위치는 1,726,720 + 128인 1,726,848 섹터로 이동해보면 다음과 같다.

앞서 분석한 내용을 정리하면 다음과 같다.

> 첫번째 파티션

① 시작 섹터 : 128

② 파티션 타입 : FAT32

③ 파티션 총 섹터 수 : 497,664

> 두번째 파티션

① 시작 섹터 : 497,792

② 파티션 타입 : NTFS

③ 파티션 총 섹터 수 : 368,639

> 세번째 파티션

① 시작 섹터 : 866,432

② 파티션 타입 : NTFS

③ 파티션 총 섹터 수 : 450,559

> 네번째 파티션( EBR )

① 시작 섹터 : 1,316,992

② Current 파티션 타입 : FAT32

③ 시작 섹터 : 1,316,992 + 128 = 1,317,120

④ 파티션 총 섹터 수 : 409,600

⑤ Next 파티션 타입 : Extended

⑥ 시작 섹터 : 1,726,720

⑦ 파티션 총 섹터 수 : 362,624

> 다섯번째 파티션( EBR )

① 시작 섹터 : 1,726,720

② Current 파티션 타입 : FAT32

③ 시작 섹터 : 1,726,720 + 128 = 1,726,848

④ 파티션 총 섹터 수 : 362,496

앞서 분석한 것을 바탕으로 본격적으로 Partition table이 손상된 MBR을 수정한다.

위와 같이 수정한 후 FTK Imager 프로그램으로 실습 파일을 로드하면 다음과 같이 복구가 된 것을 확인할 수 있다.

파티션 복구 실습을 하기 전에 계산 방법에 대해 알아보자.

우선, 샘플 예제를 HxD 에디터로 열어보면 다음과 같다.

파티션과 관련된 파티션 테이블 부분은 446byte부터 509byte까지 총 64byte이며, 16바이트씩 총 4개의 파티션 정보가 담긴다. 

Boot flag( 1 byte ), Starting CHS( 3 byte ), Partition type( 1 byte ), Ending CHS( 3byte ), Starting LBA( 4 byte ),  Total Sector(4byte)로 구성된다.

•Boot flag: 부팅 가능여부를 나타내며, 0x00은 부팅 불가능, 0x80은 부팅 가능

•Starting CHS: CHS 주소지정방식의 시작 위치이며 더이상 사용하지 않는다.

•Partition type: 해당 파티션의 파일시스템 타입을 알 수 있다.

•Ending CHS: CHS 주소지정방식의 끝나는 위치 정보이며 더이상 사용하지 않는다.

•Starting LBA: LBA 주소지정방식에 의한 파티션 시작주소이다.

•Total Sector: 해당 파티션의 총 섹터 개수에 대한 정보를 담고 있다.

* 파티션 타입에 대한 정보는 아래 링크에서 확인할 수 있다.

https://en.wikipedia.org/wiki/Partition_type

* 데이터는 리틀 엔디언 방식으로 저장되어 있다.

위 샘플예제를 엑셀로 열면 다음과 같다.

우선 446 번째 바이트를 보면 0x00으로 부팅가능한 파티션이 아님을 알 수 있다. 그리고 CHS 방식은 더이상 사용하지 않기 때문에 447 ~ 449 바이트와 451 ~ 453 바이트는 보지 않아도 된다. 

450 번째 바이트를 보면 0B로 파티션 타입이 FAT32임을 알 수 있다. 

454 ~ 457 바이트를 보면 80 00 00 00 이지만 리틀 엔디안 방식으로 저장되어 있기 때문에 실제로는 00 00 00 80으로 LBA 시작 위치는 128 섹터임을 알 수 있다. 

458 ~ 461 바이트를 보면 00 08 03 00 이지만 이 또한 리틀 엔디안 방식으로 저장되어 있기 때문에 00 03 08 00 으로 총 섹터의 개수는 198,656개 임을 알 수 있다.

그리고 파티션의 총 용량은 총 섹터의 개수 x 512( 섹터 크기 )를 곱한 값으로 101,711,872 바이트 임을 알 수 있고 이를 MB 단위로 표시하기 위해서는 1024로 두번 나누어 주면( 2^20 ) 되며 그 값은 97 MB임을 알 수 있다.

분석 및 계산 방법은 위와 같이 하지만 일일이 계산하는 것이 불편하고 시간이 오래 걸리기 때문에 python을 이용하여 프로그램을 하나 만들었다. 

simple_MBR.py

* 위 파일은 python 2.7 버전으로 작성되어 있으며 windows 용으로 만들었다. 이를 실행하기 위해서는 python 2.7 버전이 설치되어 있어야 한다.

* 간단한 프로그램으로 파티션 타입을 확인할 수 있는 것이 제한적이다. FAT32, NTFS, Ext만 확인할 수 있다.

MBR.py

* 위 파일은 simple_MBR.py 프로그램의 MAC용이다. 저자가 맥북을 사용하기 때문에 따로 만들었다. 거창하지만 실제로는 파일을 찾는 경로에 차이가 있을 뿐이다.

* simple_MBR.py 사용법

1. HxD 에디터로 데이터를 연다.

2. 데이터를 전체 선택 후 복사한다.

3. 메모장을 열어 데이터를 붙여넣고 저장한다.

4. simple_MBR.py 프로그램을 실행시켜 저장한 txt 파일을 불러온다.

5. 결과를 확인한다.

위에서 살펴본 샘플 예제를 분석한 것과 결과가 같은 것을 확인할 수 있다.

앞서 살펴본 샘플 예제는 파티션이 1개인 경우를 살펴보았다. 이제 확장 파티션이 있는 샘플 파일을 분석해 보자.

위 파일을 분석하기 위해 simple_MBR 프로그램을 사용하면 다음과 같다.

파티션 1은 FAT32 방식이고 시작 섹터가 128 섹터, 총 섹터는 512,000, 총용량은 250MB

파티션 2는 FAT32 방식이고 시작 섹터가 512,128 섹터, 총 섹터는 512,000, 총용량은 250MB

파티션 3은 FAT32 방식이고 시작 섹터가 1,024,128 섹터, 총 섹터는 512,000, 총용량은 250MB

파티션 4는 Ext 방식이고 시작 섹터가 1,536,128 섹터, 총 섹터는 557,056, 총용량은 272MB

위와 같이 확인할 수 있다.

다양한 예제를 분석해보자.

- MBR test #1

위 파일을 simple_MBR 프로그램으로 돌려보자.

위와 같이 분석이 되었다. 분석이 제대로 되었는지 확인하는 방법은 HxD 에디터로 파티션의 시작 섹터 부분으로 이동했을 때 VBR이 나타나는지 보면 된다. 이는 다음과 같다.

에디터 상단에 '섹터' 부분에 128을 입력하고 엔터를 치면 다음과 같이 섹터 128로 이동하게 되며 VBR이 나타남을 볼 수 있다. 이와 같이 409,728 섹터와 716,928 섹터로 이동해보면 다음과 같다.

- MBR test #2

이를 simple_MBR 파일로 열면 다음과 같다.

4번째 파티션을 보면 Ext방식이고 시작 주소가 1,316,992 임을 알 수 있다.

이 주소로 가면 다음과 같다.

boot code 부분이 비어있는 것을 확인 할 수 있으며 이는 Extended Boot Record( EBR )의 특성이다. 이를 다시 simple_MBR 파일로 돌려보자.

파티션 정보가 2개만 있는 것을 확인할 수 있다. 이 또한 EBR의 특성이며 파티션 1은 현재 파티션의 정보를 나타내며 파티션 2는 다음 파티션의 위치를 나타낸다. EBR의 경우 상대적 위치를 나타내기 때문에 앞서 봤던 Ext의 시작 주소를 각 파티션의 시작 주소에 더해주어야 실제 파티션의 시작 주소를 알 수 있다.

위와 같은 방식으로 분석을 하면 된다.

다음 포스팅은 실제 파티션을 복구하는 방법에 대해서 알아보자.