Test

[ * ] 문제 확인

문제를 확인하기에 앞서, 해당 문제는 아래 블로그에서 가져온 연습 문제임을 밝힙니다 :)

http://eniac-security.tistory.com/83

주어진 파일은 위와 같으며 vmdk 파일은 가상 머신에서 데이터를 저장하기 위한 용도로 사용되는 가상의 디스크이며 vmdk 파일이 있다면 디스크를 인식시켜 데이터를 가져올 수 있고, 주어진 지문은 다음과 같다

1. 총 파티션의 개수

2. FAT32 파티션은 존재 하는가

3. NTFS 파티션은 존재 하는가

4. 각 파티션의 크기는 얼마인가

5. 첫 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가

6. 두 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가

7. BR 영역에서 올바르지 않은 점은 무엇인가

8. KEY 값은 무엇인가 (Key is로 시작)

[ * ] 해결 방향

해당 문제는 파일 시스템인 NTFS와 FAT32의 구조에 대한 해석이며 해당 문제를 해결하기 위한 기본 지식은 http://forensic-proof.com의 체계적으로 잘 정리되어 있는 자료에서 얻을 수 있다.

[ * ] 해결 과정

주어진 vmdk 파일을 하나의 디스크로 인식시키기 위해 Forensic Tool Kit를 이용하여 마운트 하였고 해당 과정은 아래의 사진과 같다

해당 가상 디스크를 마운트 하기 전 주의사항은 지문에서 주어진 문제를 해결하는 과정에서 디스크의 데이터를 변경해야하기 때문에, 디스크 보호를 위해 기본값으로 되어 있던 Read Only 부분을 Writable로 수정해주어야 한다. 마운트를 하게 되면 아래의 사진과 같이 마운트 과정에서 지정해주었던 드라이브 문자와 함께 X와 Y파티션이 인식 됨으로써 해당 vmdk 파일에는 2개의 논리 파티션이 있음을 알 수 있다

 현재 사용하던 C,F,K 드라이브 이외에 X,Y가 마운트 됨을 확인할 수 있었고, 아래와 같이 디스크가 인식 되지 않음으로 보아 해당 디스크에 손상된 부분이 있음을 알 수 있다

해당 디스크에서 가지고 있는 문제점을 찾아 Trouble-Shooting을 위해 Hxd Editor로 해당 디스크를 열어주었다

주의 점은 디스크를 열기 위해서는 Hex Editor를 관리자 모드로 실행시켜야 하며 데이터를 쓰기 위해서는 읽기전용 항목에 체크를 해제 해주어야 함

가상 디스크 파일을 열어 주었고 첫 번째로 X와 Y 파티션이 가지는 문제점을 찾기 위해 MBR 부분의 구조 분석을 통해 BR이 시작되는 즉, 파티션의 시작 섹터를 찾아야 한다

위의 자료는 MBR이 가지는 전체적인 구조이며 현재 문제를 이해하고 풀기 위해서 필요한 부분은 아래와 같이 Partition Table 부분이다

Partition Table은 총 64바이트를 가지며 각 파티션은 16바이트 씩 사용, 총 4개의 파티션을 만들 수 있고, 하나의 파티션 테이블이 가지는 구조는 아래와 같다

1. 첫 번째 필드는 Boot Flag가 오며 부팅 가능 여부를 나타내고 0x80은 부팅가능, 나머지 값은 부팅 불가능이다

2. 두 번째 필드는 CHS 주소지정 방식을 사용할 경우 파티션의 시작 부분을 나타내며, 528MB라는 저장 공간의 한계로 대개 사용하지 않음

3. 세 번째 필드는 Partition Type을 나타내며 0x07일 경우 NTFS를 나타내며 0x0B 또는 0x0C일 경우 FAT을 나타낸다

4. 네 번째 필드는 CHS 주소지정 방식을 사용할 경우 파티션의 끝 부분을 나타낸다

5. 다섯 번째 필드는 LBA 주소지정방식을 사용할 경우 파티션의 시작 섹터를 나타낸다

6. 여섯 번째 필드는 LBA 주소지정방식을 사용하는 파티션의 총 크기 즉, 총 용량을 나타낸다

파티션 테이블의 각각의 필드가 의미하는 정보를 알아 보았으니 해당 문제의 파티션 구조를 알아보자

마운트 되었던 두 개의 디스크를 통해 알 수 있었던, 파티션 테이블에 두 개의 파티션 정보가 들어가 있음을 확인할 수 있다 

첫 번째 파티션 = 부팅 불가, 파티션 타입 없음, 파티션의 시작 섹터 : 0x0000003F,  파티션의 총 섹터 수 : 0x00A0120E

위의 두 사진처럼 값을 수정해 주었다니 아래와 같이 첫 번째 논리 디스크였던 X 파티션이 인식 되었다

X파티션에 들어갔더니 아래와 같이 파일이 하나 있었고 해당 파일은 확장자를 가지고 있지 않아 파일을 특정짓기 어려웠기에 Hex Editor로 시그니쳐 값을 보았다

png 파일임을 의미하는 시그니쳐 값 "89 50 4E"를 볼 수 있었고 해당 파일의 확장자를 png로 바꾸어 주었더니 아래와 같은 사진 파일을 확인할 수 있었다

여기까지가 첫 번째 파티션의 BR영역 수정을 통한 첫 번째 파티션의 인식 과정과 해당 파티션에 있던 파일을 확인하는 과정이었고 이어서 두번째 파티션 분석을 이어가겠다

두 번째 파티션 = 부팅 불가, 파티션 타입 없음, 파티션의 시작 섹터 : 0x00A0124D, 파티션의 총 섹터의 수 : 0x009FD38C

두 번째 파티션의 시작은 10490445번째 섹터에서 시작하므로 시작주소로 이동했고 FAT32라 적힌 BR영역을 확인할 수 있다

다시 한번 해당 BR영역이 올바른 파일시스템을 가지고 있는지의 확인이 필요하므로 FAT32의 백업본의 위치인 파티션의 시작섹터 +6 섹터 즉, 10490451로 이동해보았다

FAT32 파일시스템이라면 백업본이 위치해야할 섹터에 BR영역으로 보이는 데이터는 보이지 않음을 통해 해당 파일시스템은 FAT32가 아니며 첫 번째 파티션과 반대인 NTFS라고 생각할 수 있고 실제로 백업본의 위치에 가본다면 사실을 알 수 있기에 NTFS의 백업본이 존재하는 파티션의 제일 끝으로 가기 위한 계산식을 이용해서 해당 섹터에 가보았다

"Start LBA Addr + Size of Sector - 1" 

10490445(0xA0124D) + 10474380(0x009FD38C) -1 = 20964824

해당 20964824번째 섹터에 있던 NTFS 파일시스템의 BR 백업본을 복사해 NTFS 파일시스템의 시작 파티션인 10490445번째 섹터에 붙여 넣어 준 뒤 MBR 영역의 Partition Type에 0x07로 값을 수정해 주었다

위의 두 사진처럼 값을 수정해 주었다니 아래와 같이 두 번째 논리 디스크였던 Y 파티션이 인식 되었다

해당 Y파티션에 들어가 보았더니 아래와 같은 Tail이라는 이름의 파일을 확인할 수 있었다

마찬가지로 파일 확장자가 없음으로 인해 파일을 특정짓기 어려웠기에 Hex Editor로 시그니쳐 부분을 확인해 보았고 해당 부분이 비어있음을 확인할 수 있었다

파일의 헤더 시그니쳐 부분이 비워져 있음을 통해 어떻게 특징을 구분짓나 하며 생각하던 도중 해당 데이터의 끝 부분에서 ZIP파일의 시그니쳐를 의미하는 부분이 보였고 헤더를 "50 4B 03 04"로 만들어 주고 확장자를 zip으로 만들어 주었더니 아래와 같이 rtf 파일이 하나 있음을 확인할 수 있었고 해당 파일을 열람하니 문자열을 확인할 수 있었다

해당 문자열은 대소문자와 숫자의 조합을 통해 BASE64 암호화가 되었음을 추측했고 BASE64 복호화를 지원하는 크롬 확장프로그램인 Hasher를 통해 해당 문제의 지문에서 요구하는 Key 값을 구할 수 있었다

1. 총 파티션의 개수 = 2개

2. FAT32 파티션은 존재 하는가 = 존재 함

3. NTFS 파티션은 존재 하는가 = 존재 함

4. 각 파티션의 크기는 얼마인가 = 4.99GB & 4.94GB

5. 첫 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가 = KEEEEEEEEEEEEEY.png

6. 두 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가 = Tail.zip

7. BR 영역에서 올바르지 않은 점은 무엇인가 = 백업 영역에서 NTFS와 FAT32가 서로 바뀌어 있음

8. KEY 값은 무엇인가 (Key is로 시작) = Key is :)_Start_Forensic

참조 사이트

http://jh8992.tistory.com/entry/Day1-WarmingUp-%ED%92%80%EC%9D%B4

http://forensic-proof.com